[Python-Dev] PEP: Collecting information about git

[Paul Moore]

On 16 September 2015 at 17:10, Nikolaus Rath <Nikolaus at rath.org> wrote:
>> I don't know of an equivalent of remote tracking branches in
>> Mercurial. Maybe bookmarks work that way by default?
>
> Where exactly did you run into problems? I think you should have gotten
> the same result with the following hg commands (if your remote is
> non-ancient):

I can't really recall. As I said, it was quite some time ago. And
probably long enough that bitbucket didn't support bookmarks, so your
"if your remote is non-ancient" may well be relevant.

One thing that I think I've got into trouble with:

I'm on revision X, which is at tip (master in git, the default branch
in Mercurial). I do git checkout -b foo (or hg bookmark foo). Now I
check in some changes. In git, I'm on branch foo and I can go back to
master with git checkout master. In Mercurial, I am at bookmark foo,
but where's the place I started from? The main line of development
(the default branch) doesn't have a bookmark, so I have to go hunting
for the revision I first switched to the bookmark at.

Similarly, if I'm at revision X, hg bookmark foo; hg bookmark bar
creates 2 bookmarks. If I then check in a change, I guess *both*
bookmarks move. In git, if I do git checkout -b foo; git checkout -b
bar, I have created two branches, and checkins now only go on bar. The
difference comes from the fact that in git, branches are "real
things", but in hg, bookmarks are names for points on the DAG - and in
this case, the DAG is completely linear so there's no way of capturing
the idea that a bookmark is starting a new branch in the DAG, unless
you actually create two commits based on the branch point.

See what I mean when I say I get confused? ;-)

> The "remote tracking branch" in Mercurial always exists, but it doesn't
> have a special name. In hg, branches do not need to have names, they are
> identified by their commit id. Assigning names is pure convenience, this
> is why they're called "bookmarks".

And yet branches are *not* simply names in git - a branch with no
commits on it is still distinct from its parent branch.

So conceptually, the idea that hg bookmarks and git branches are the
same thing, isn't actually true...

>> Also, my workflow involves 2 separate PCs, and I use my personal
>> github forks to share work in progress between them. Mercurial makes
>> it very difficult to edit "published" history, and I can't tell it
>> that my bitbucket repo doesn't count as "published" (as far as I
>> know).
>
> In general you can do that by configuring the repository with
>
>       [phases]
>       publish = False
>
> However, I believe BitBucket doesn't allow you to do that. But that's
> not hg's fault.

Well, yes and no. The fact that you have to edit the remote repository
before it will allow you to violate its "history is immutable"
principle is a feature of hg. I agree bitbucket limitations are also
relevant here (as I said, github's feature set was a major driver in
my switch, and that's not "the fault" of either tool). But hg is
(deliberately) opinionated on the right way to do things, and I do
find that those opinions get in the way of my preferred ways of
working at times.

>> Git lets me do what I want (with some "are you sure?" prompts
>> when I force-push a rebased/edited branch, for example).
>
> Same with hg. "hg phase -d -f <rev>" forces the status of "rev" to
> 'draft'.

My hg knowledge is out of date. I know phases make history editing
more flexible, but I've never learned it.

Paul