problems with the hg-git plugin and bookmarks

[Steve Fink]

On 09/07/2016 04:41 AM, Uwe Brauer wrote:
>    bookmark:    exam
> |  tag:         tip
> |  user:        Uwe Brauer <oub at mat.ucm.es>
> |  date:        Wed Sep 07 11:28:47 2016 +0000
> |  summary:     exam2
> |
> o  changeset:   2:9c310e702a2a
> |  user:        Uwe Brauer <oub at mat.ucm.es>
> |  date:        Wed Sep 07 11:28:47 2016 +0000
> |  summary:     Exam 1
> |
> @  changeset:   1:62af2f2e8eeb
> |  bookmark:    master
> |  user:        Uwe Brauer <oub at mat.ucm.es>
> |  date:        Wed Sep 07 11:28:48 2016 +0000
> |  summary:     Uwe three
> |
> o  changeset:   0:e8f73d6490e2
>     user:        Uwe Brauer <oub at mat.ucm.es>
>     date:        Wed Sep 07 11:28:46 2016 +0000
>     summary:     Up one
>
> That is a complete linear history.
>
>
> BTW I first tried hg rebase -s 2 -d 4 which is not correct but resulted
> in an enigmatic error message I will write about in a different message.
>
> Now I could generate a patch, (if my branch contained more changesets, I
> might either collapse them or could  have used the --amend option)
>
> The central question is:
>
> how could I go back to my original repo? What is
> the «inverse operation»  hg rebase -s 1 -d 3?

Your complexity seems to arise from this desire to have your original 
commits. I think things would be easier if you didn't try to do that.

>
> You might ask why should I need it? The answer is:
>
>
>      -  if I want to pull (my repo is now not sync with the main repo so
>         pulling will cause problems)

I don't understand this. Your repo is perfectly in sync with the main 
repo before your work is accepted upstream. If you pulled some 
additional commits, they would apply on top of the revision that your 
patches are based on, forming a fork in the graph. Which is exactly what 
should happen. Your bookmark would not be affected.

The interesting thing is when upstream *does* accept your patches. Then 
you'll pull, and hg won't be able to tell that the new commits it's 
downloading have anything to do with your bookmarked commit or its 
ancestors, so it'll look the same as above. At that point, you could 
either just delete your bookmark and forget about those commits (hg up 
-r tip; hg book -d exam), or strip out your revisions (hg strip -r 'exam 
% tip'), or -- this is usually what I'd want -- rebase it on top of what 
you pulled (hg rebase -d tip).

Except that I never use 'tip'. I have an extension that gives me the 
latest commit on what I've pulled, and I'd use that. There's probably 
some clever revset to compute it, though for repos that the extension 
doesn't handle, I just look at the log output and copy the hash.
>      -  if I had to modify the patch I prefer to have my original
>         branches.

Why?

I mean, if the rebase mangles things, I'd understand wanting this. (I 
use evolve so my original commits never truly go away.) But until you do 
one of the actions above, you *do* have your original commits. Modify 
them, and only then rebase or whatever.

You seem to want to keep holding onto your original commits plus every 
rebased version. While it's possible to do this (hg graft would be 
easiest), it seems like you'd be taking over a bunch of responsibility 
for managing your different versions. If you really want to have access 
to those old versions just in case (which, personally, is exactly what I 
want), then let the VCS track these things by using the evolve 
extension. But it introduces several new concepts that you'll have to 
learn and deal with. They all make sense (what *should* happen if you 
and upstream change something incompatibly? What do you call an old 
commit after you've rebased it on top of something else?), but they are 
new things to learn.

> I tried
> hg rebase -s 2 -d 1
Why this? 1 is the newly pulled revision. I would expect |hg rebase -s 2 
-d 0|. Which works.

I wouldn't personally do this, since if the rebase had to modify things, 
then this would have to undo those modifications. I don't trust the 
machinery that much.

> «nothing to rebase» and
> hg rebase -s 3 -d 0
>
> But then obtained the wrong tree
>    changeset:   3:c17516b989fd
> |  bookmark:    exam
> |  bookmark:    master
> |  tag:         tip
> |  user:        Uwe Brauer <oub at mat.ucm.es>
> |  date:        Wed Sep 07 11:28:47 2016 +0000
> |  summary:     exam2
> |
> o  changeset:   2:78ede21a2943
> |  parent:      0:e8f73d6490e2
> |  user:        Uwe Brauer <oub at mat.ucm.es>
> |  date:        Wed Sep 07 11:28:47 2016 +0000
> |  summary:     Exam 1
> |
> | o  changeset:   1:62af2f2e8eeb
> |/   user:        Uwe Brauer <oub at mat.ucm.es>
> |    date:        Wed Sep 07 11:28:48 2016 +0000
> |    summary:     Uwe three
> |
> o  changeset:   0:e8f73d6490e2
>     user:        Uwe Brauer <oub at mat.ucm.es>
>     date:        Wed Sep 07 11:28:46 2016 +0000
>     summary:     Up one

Uh, what?

|hg rebase -s 3 -d 0| should scream bloody murder (more specifically, 
"remote changed exam.txt which local deleted") because you're rebasing a 
modification to a file that didn't exist in the revision you're rebasing 
onto.

I think you meant hg rebase -s 2 -d 0, which indeed gives the above 
graph... but that looks correct to me! Well, except for the bookmarks 
getting clumped onto 3, which doesn't happen when I try running your 
test case with those commands. I'm unsure how you ended up with that. At 
any rate, it's the right graph, just the wrong bookmarks. You could put 
'master' back in place.

Oh, wait... are you worrying about those changeset numbers? As in, the 
0, 1, 2, and 3? They're a complete fiction, especially if you're 
rebasing. They're handy short names to refer to commits, but the hashes 
are Truth. (Though the hashes will change too if you rebase, as they 
should.)

> So if it is not possible to do the inverse operation with rebase,
>
>
> the workflow should be.
>
>
>
>      -  clone auctex to auctex-hg
>
>      -  generate branches and write code.
>
>      -  pull for the last time to the master bookmark
>
>      -  clone the repo: hg clone auctex-hg auctex-bridge
>
>      -  rebase auctex-bridge generate a patch submit.
>
>      -  delete auctex-bridge.
>
> If that is the only way to do it I can live with it, but I find it
> cumbersome, I thought mercurial is «one repo to rule them all»

Bleh. If you really really want to keep those stale original commits 
around, use graft. Or evolve. Or bundle/unbundle.