problems with the hg-git plugin and bookmarks

[Uwe Brauer]

   > On 09/07/2016 04:41 AM, Uwe Brauer wrote:

Thanks for that long and detailed answer, that helped me to understand
things.

   > 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.

Maybe you are right. But till now I thought  I understand the history of a
repo best by looking on its graph and a graph in which rebase has been
used instead of merge, confuses me.

Maybe I should use the --keep option

hg rebase --keep -s 1 -d 3


   > 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).

That will also be true if I used the --keep option?
(Usually for my own repos I would use named branch, which I could not
delete, so in such a case I should strip 

with hg strip -r 'exam %tip'

Is this correct?

   > 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.

   > 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

   > 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.

You are right it should be 

hg rebase --keepbranches -s 2 -d 0

Nothing else (well with or without keepbranches)


Ok you convinced me:

I will not try to perform some sort of inverse operation but maybe I
could use the --keep option, export and then strip when needed. Maybe
this a good compromise? Or would it generate a «bad» patch?

Thanks very your long and detailed answer, it helped me to understand
better the rebase extension which till now tried to avoid. I don't think
I will for the time being try out the evolve or the graft extension but
might try out the --keep option.

Uwe Brauer