Ben Finney writes: > Whether that is a *problem* is a matter of debate, but the fact that > Git's common workflow commonly discards information that some consider > valuable, is a simple fact. It *was* a simple fact in git 0.99. Since the advent of reflogs (years ago), it is simply false. Worse, common hg workflows (as developed at the same time as your impression of "Git's common workflow") *also* discard information that some (namely, me) consider valuable, because it *never gets recorded*. Exploring the git reflog has taught me things about my workflow and skills (and lack thereof ;-) that I'd never learn from an hg or bzr branch. In the end, the logs look very similar. I can only conclude that the rebasing that I do in git is implicit in the process of composing a "coherent changeset" in hg or bzr. I also typically have a bunch of "loose commits" lying around in Mercurial queues or bzr stashes, which amount to rebases when reapplied. > If Ethan chooses to make that a factor in his decisions about Git, > the facts are on his side. Hardly. All he needs to do is pretend git is hg, and avoid rebase. The only thing that should matter is the annoyance of learning a new tool.
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4