On Sep 16 2015, "R. David Murray" <rdmur...@bitdance.com> wrote:
> 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? :)
Not if you come from git and want to use hg. You can just ignore
bookmarks.
But there is an easy explanation if you want one. Think of a named
branch as automatically appending "this went to <branchname>" to your
commit message.
> 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
No, it's just some extra information in the commit. Like author, date,
or commit message.
> The fact that I have to worry about (remember to delete) branches I no
> longer want is also an additional mental load,
Yes, this is a disadvantage of Mercurial.
> 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.
..but this is not. You can easily automate that (though I don't
recommend typing in the expression by hand every time, the idea is to
tel hg to "delete this changeset and all ancestors until you reach an
ancestor that has more than one child").
> 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.
But why?
> 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.
In hg it's exactly the same, it's just a head you're working with, and
later you can do something with it.. or delete it. If it helps, create a
cronjob that deletes all DAG leaves that don't have bookmarks.
Best,
-Nikolaus
--
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
_______________________________________________
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
