[Python-Dev] PEP: Collecting information about git

[R. David Murray]

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.