[Python-Dev] PEP: Collecting information about git
R. David Murray
rdmurray at bitdance.com
Wed Sep 16 19:34:35 CEST 2015
On Wed, 16 Sep 2015 09:17:38 -0700, Nikolaus Rath <Nikolaus at rath.org> wrote:
> On Sep 16 2015, "R. David Murray" <rdmurray at 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.
More information about the Python-Dev
mailing list