On Wed, 16 Sep 2015 09:17:38 -0700, Nikolaus Rath <nikol...@rath.org> wrote: > On Sep 16 2015, "R. David Murray" <rdmur...@bitdance.com> wrote: > > The DAG plus git branches-as-labels *fits in my head* in a way that the > > DAG plus named-branches-and-other-things does not. > > Hmm, that's odd. As far as I know, the difference between the hg and git > DAG model can be summarized like this: > > * In git, leaves of the DAG must be assigned a name. If they don't have > a name, they will be garbage collected. If they have a name, they are > called a branch. > > * In hg, leaves of the DAG persist. If you want to remove them, you > have to do so explicitly (hg strip), if you want them to have a name, > you must do so explicitly (hg bookmark). A node of the DAG with a > name is called a bookmark. > > * hg named branches have no equivalent in git. > > Does that help?
Well, that last bullet kind of complicates the model, doesn't it? :) Especially when you add the fact that (IIUC) which named branch a commit is on is recorded in the commit or something, which means the DAG is more complicated than just being a DAG of commits. The fact that I have to worry about (remember to delete) branches I no longer want is also an additional mental load, especially since (again, IIUC) I'd have to figure out which commit I wanted to strip *from* in order to get rid of an abandoned branch. This is what I mean by hg not being *oriented* toward the simple model: if I end up with extra heads in my cpython repo I treat this as a bug that needs to be fixed. In git, it's just a branch I'm working with and later do something with...or delete, and git takes care of cleaning up the orphaned commits for me. I'm leery (wrongly, I suspect) of creating branches in hg because they don't fit into my mental model of how I'm working with the cpython repository and its named branches. Now, is that just a consequence of having learned mercurial in the context of how CPython uses it? I don't know. As another example of this orientation issue, rebase was a big no-no in hg when we started with it, and so I would only deal with patch sets (hg diff to save a work in progress, reapply it later...a pattern I still follow with cpython/hg) so that I didn't screw up my history. In git, it is the most natural thing in the world to take a branch you've been working on and rebase it on to the point in the tree where you want to commit it. Even now I have to read carefully and think hard every time I use the hg rebase command...I'm not sure why it is, but again it doesn't fit in my head the way the git rebase does[*]. None of these things that mercurial does is *wrong*, and in fact they are very useful in the right context. The point is that the git model is *simple*. Like I said, it fits in my head. I guess I have a small head :) But, now the thread is again drifting away from how mercurial and git relate to cpython development into simply how mercurial and git differ. --David [*] Note also that the hg help lacks the DAG examples that the current git help has, and that it talks about "repeated merging" when what I want to do is *move* the commits, I don't want to merge. I think it means exactly the same thing, but again it doesn't fit into my simple git mental model of moving a branch of the DAG from here to there. _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
