problems with the hg-git plugin and bookmarks

[Kevin Bullock]

> On Sep 7, 2016, at 06:41, Uwe Brauer <oub at mat.ucm.es> wrote:
> 
> Here is a basic repo which reflects my situation
> 
> The result of  hg log -G is 
> 
> @  changeset:   3:62af2f2e8eeb
> |  bookmark:    master
> |
> | o  changeset:   2:96b67c7548e1
> | |  bookmark:    exam
> | |
> | o  changeset:   1:34c977558c2d
> |/
> |
> o  changeset:   0:e8f73d6490e2
> 
> So I want to send a patch of my branch exam.
> 
> So I do
> 
> hg rebase -s 1 -d 3
> [...]
> That is a complete linear history.

[quoted text edited for length]
The rebase is entirely optional. The most basic workflow for submitting upstream changes is:

1. Clone upstream repo.
2. Write/edit code. Commit one or more times.
3. Send patch using `hg email` or `hg export`. Note that you can e-mail or export multiple commits as easily as a single commit.

No pulling, rebasing, or anything else necessary. Your history doesn't need to be linear. Assuming your patch still applies cleanly for the maintainer, there's no reason to pull upstream changes just to update your patch.

If you want to _use_ a newer upstream version with your changes applied, then you can use rebase (or graft, or export+import, or whatever other tools you like). The way to do that with rebase is:

$ hg up exam
$ hg rebase -d master

If that says "nothing to rebase", then your changes are already descended from the current master. (Note that I'm only using 'master' because you've said you're interacting with an upstream Git repo; in Mercurial bookmark terms we spell it '@').

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

When your patch lands upstream, you probably want to pull to get upstream's version of your commit. To do that you do the same as above:

$ hg up exam
$ hg rebase -d master

>    -  if I had to modify the patch I prefer to have my original
>       branches.

If so, then you might consider using graft instead of rebase to apply your changes to a newer upstream.

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

That's a reasonable workflow, but as I point out above it's more complex than strictly necessary.

pacem in terris / мир / शान्ति / ‎‫سَلاَم‬ / 平和
Kevin R. Bullock