hg-git: push -d default seems not to work.

[Uwe Brauer]

   > On Sat, 06 May 2017 12:48:28 -0400, Uwe Brauer <oub at mat.ucm.es> wrote:

Thanks very much for this detailed answer.


   > OK. I'm under the impression that this is a pull request based
   > project. What happens when someone else submits a PR at the same time?
   > (I'd assume the maintainer does a merge, but that doesn't sound like
   > the branch-free commits I picture when you say that.)

Well, the repo sometimes is relatively quiet and sometimes patches or
pushes arrive almost at the same time. If I remember correctly the
situation you asked happened once and the maintainer told me to pull
again, to rebase and then to push again.

   > Rebase will store metadata in the commits that it creates, letting you
   > know where it originally was. The easiest way to see it is to use `hg
   > log -r $rebased_revision --debug`, and look in the 'extras' section.


Ah that is very interesting
this is what I did

hg init
echo Upstream1 > main.txt
hg add main.txt
hg commit -m "Master1"
hg branch feature
echo feature1 > feature.txt
hg add feature.txt
hg commit -m "Feature1"
echo feature2 >> feature.txt
hg commit -m "Feature2"
hg update default
echo uwe-three >> main.txt
hg commit -m "Master2"
hg rebase -d 3 -b 2 --keepbranches
hg log -r 3 --debug


But I see
hg log -r 3 --debug
all_dirs: _parse called with args ['log', '-r', '3', '--debug']
all_dirs: _parse found another command log
invalid branchheads cache (visible): tip differs
changeset:   3:ec317cd8396d45adf8ddd6b05f88b0adf936b024
phase:       draft
parent:      0:bb057aae85867f4739cef10531ba1bdbede66591
parent:      -1:0000000000000000000000000000000000000000
manifest:    3:2d35da9b5b85caba1a5e103800df1c710cd6ae2f
user:        Uwe Brauer <oub at mat.ucm.es>
date:        Mon May 08 16:27:52 2017 +0000
files:       main.txt
extra:       branch=default
description:
Master2

That is not very helpful, I'd say. Moreover if I understand that
approach correctly I have to do that for all the rev I suspect to be rebased? 



   > I hesitate to throw even more concepts at you, but have you tried the
   > evolve extension? It keeps the original commits in the tree (but
   > hidden, so you may not like that). If you mess up, you can recover the
   > originals (though you should be able to do that without evolve, unless
   > you explicitly said --no-backup).

Evolve I have used for renaming branches, but I thought it is only 100
watertight for repos in draft phase not for those which are public. 
A deeper understanding of evolve for sure is on my TODO list.


[Snip]...



   > Well, rebase without --keep will remove the source from the tree. As
   > mentioned, evolve keeps the source, but hides it by default. I don't
   > think the ASCII graph shows the src/dest relationship like that, but
   > other apps can (like TortoiseHg).

I checked that, all I can see is that the rev, which has been rebased is
shown as white ball instead of a blue one. As longer as I think about it
as more I want some graphical indication of a rebase operation in the repo.

   > The point of this step is to apply the latest and greatest upstream to
   > your feature branch. If you already merged the latest default into
   > feature (which is what this message is telling you), then you can skip
   > this step. But you want to be sure that you have the latest upstream
   > in feature before proceeding. Otherwise, the revert command will undo
   > the upstream changes that you don't have.
ok

   > Yes, this looks right. One final step that you should now add is to
   > merge default back into feature, before you do more work on the
   > feature or pull again from upstream.

   > $ hg up feature
   > $ hg merge default
   > $ hg ci -m "merge with my changes in upstream"


Thanks for pointing this out to me. I was wondering already. So in short
I think your advice is very useful and helpful. Thanks


Uwe