graft/rebase without changing the hash

[Uwe Brauer]

Hi

Is there any possibility to graft/rebase a change set from say the
default branch to another named branch, say main, *without* changing the
hash?

Rationale

When using the hg-git extension, I prefer to use named branches (say
main or feature) not bookmarks for my workflow,

Now it is possible to export changesets on named branches to git
branches, thanks to one of the following changesets in hg-git (although
they are not merged into the release hg-git branch)


1. 4b51ff13e8f5

2. Or 6942fb0a8c9d



However importing commits, pushed by git users and pulled by me, end up on
the default branch with a bookmark.

So I hoped I could graft or rebase those changesets to my named branch (feature)

I can rebase them, (with or without evolve enabled) but the rebased changeset
gets a new hash which means that if I push it, it will confuse git
users.

So I have the feeling that what I am looking for is impossible, right?


Regards

Uwe Brauer
--
Warning: Content may be disturbing to some audiences
I strongly condemn Putin's war of aggression against the Ukraine.
I support to deliver weapons to Ukraine's military.
I support the ban of Russia from SWIFT.
I support the EU membership of the Ukraine.
https://addons.thunderbird.net/en-US/thunderbird/addon/gmail-conversation-view/

[Dr. Arne Babenhauserheide]

Hi Uwe,

Uwe Brauer <o...@mat.ucm.es> writes:

> [[S/MIME Signed Part:Good signature from D472940B79E53E815167CEC95E244FB27DD2E8DB /CN=BRAUER UWE RICHARD OTTO - X2064123B/C=ES/SN=BRAUER/GN=UWE RICHARD OTTO/SerialNumber=IDCES-X2064123B (trust undefined)]]

> Is there any possibility to graft/rebase a change set from say the
> default branch to another named branch, say main, *without* changing the
> hash?

No, because the branch name is part of the hash calculation.

> I can rebase them, (with or without evolve enabled) but the rebased changeset
> gets a new hash which means that if I push it, it will confuse git
> users.

It sounds like what you want is to have the resulting git-hash equal,
not to have the Mercurial-hash equal. This could in theory be possible
(because the branch name is not part of the hash-generation in git), but
I do not know whether it is possible in practice.

Best wishes,
Arne
--
Unpolitisch sein
heißt politisch sein,
ohne es zu merken.
draketo.de

[Uwe Brauer]

>>> "AB" == Arne Babenhauserheide <arne...@web.de> writes:

Hi Arne

> Hi Uwe,
> Uwe Brauer <o...@mat.ucm.es> writes:

>> [[S/MIME Signed Part:Good signature from
>> D472940B79E53E815167CEC95E244FB27DD2E8DB /CN=BRAUER UWE RICHARD OTTO
>> - X2064123B/C=ES/SN=BRAUER/GN=UWE RICHARD
>> OTTO/SerialNumber=IDCES-X2064123B (trust undefined)]]
>> Is there any possibility to graft/rebase a change set from say the
>> default branch to another named branch, say main, *without* changing the
>> hash?

> No, because the branch name is part of the hash calculation.

Ok, that makes sense.

>> I can rebase them, (with or without evolve enabled) but the rebased changeset
>> gets a new hash which means that if I push it, it will confuse git
>> users.

> It sounds like what you want is to have the resulting git-hash equal,
> not to have the Mercurial-hash equal. This could in theory be possible
> (because the branch name is not part of the hash-generation in git), but
> I do not know whether it is possible in practice.

I just realised with *evolve enabled*, the rebase results in no githash at
all, a bug?

Hg log -G --follow --template "\x1B[33mcommit {rev}:{gitnode}\nAuthor: {author}\nDate: {date|rfc822date}\n\n{desc}\n{nofiles}\n"

Before the rebase gave

◍ commit 2:1b0c5dd30a1d0ab00b3f56b2b1202bc4cbc1cb00
│ Author: Uwe Brauer <o...@mat.ucm.es>
│ Date: Sat, 26 Nov 2022 14:19:58 +0100
│
│ Git test ode15t non linear blows up

But after the rebase
@ commit 3:
│ Author: Uwe Brauer <o...@mat.ucm.es>
│ Date: Sat, 26 Nov 2022 14:19:58 +0100
│
│ Git test ode15t non linear blows up

But without evolve
@ commit 1:28f81e628e71ca993da2d5184a5c5c31fa1cef87
│ Author: Uwe Brauer <o...@mat.ucm.es>
│ Date: Sat, 26 Nov 2022 14:18:26 +0100
│
│ Add ode15s for the nonlinear equation
│
○ commit 0:3c82db0a937415e0ffc067c7a7d1891109db021f
Author: Uwe Brauer <o...@mat.ucm.es>
Date: Sat, 26 Nov 2022 14:17:54 +0100

First commit to the main branch

In any case this is not good at all.
I could force a push, but this would make things worse

Any comments from the hg-git team?

[Uwe Brauer]

> Hi Uwe,
> Uwe Brauer <o...@mat.ucm.es> writes:


> No, because the branch name is part of the hash calculation.

> It sounds like what you want is to have the resulting git-hash equal,
> not to have the Mercurial-hash equal. This could in theory be possible
> (because the branch name is not part of the hash-generation in git), but
> I do not know whether it is possible in practice.

> Best wishes,
> Arne

The following surprisingly works, how stable it is I am not sure

* Workflow

The following works

** HG
1) create a hg repository.
2) create a named branch main (because this is what github uses now)
3) hg addremove
4) hg commit -m "First changeset"
5) hg book main_bookmark
6) hg push (to an empty git repository in github)

** GIT
1) git clone
2) git edit commit and push

** HG
Git's changeset is on the default branch not on the main branch, so
1) hg phase -d -f -r 2
2) with evolve enabled hg rebase -s 4 -d 3 (it does not work without evolve)
3) add more changesets
4) actualise the bookmark
5) hg push -f

** GIT

Git pull results in


hint: You have divergent branches and need to specify how to reconcile them.
hint: You can do so by running one of the following commands sometime before
hint: your next pull:
hint:
hint: git config pull.rebase false # merge
hint: git config pull.rebase true # rebase
hint: git config pull.ff only # fast-forward only

So the best option seems
git config pull.rebase true # rebase

Then
Git pull

And then everything works smoothly.

Not sure how stable that is however!

[Dr. Arne Babenhauserheide]

Uwe Brauer <o...@mat.ucm.es> writes:

>> It sounds like what you want is to have the resulting git-hash equal,
>> not to have the Mercurial-hash equal. This could in theory be possible
>> (because the branch name is not part of the hash-generation in git), but
>> I do not know whether it is possible in practice.
>

> The following surprisingly works, how stable it is I am not sure
>
> * Workflow
>
> The following works
>
> ** HG
> 1) create a hg repository.
> 2) create a named branch main (because this is what github uses now)

Could you just set a bookmark named main?
That way you would still be on the branch used by hg-git as target for
the default branch.

[Uwe Brauer]

>>> "AB" == Arne Babenhauserheide <arne...@web.de> writes:

> Uwe Brauer <o...@mat.ucm.es> writes:

>>> It sounds like what you want is to have the resulting git-hash equal,
>>> not to have the Mercurial-hash equal. This could in theory be possible
>>> (because the branch name is not part of the hash-generation in git), but
>>> I do not know whether it is possible in practice.
>>
>> The following surprisingly works, how stable it is I am not sure
>>
>> * Workflow
>>
>> The following works
>>
>> ** HG
>> 1) create a hg repository.
>> 2) create a named branch main (because this is what github uses now)

> Could you just set a bookmark named main?
> That way you would still be on the branch used by hg-git as target for
> the default branch.

That is a misunderstanding, I do want to use named branch, especially I
want to know how to interact with git if more branches are going to be
used, either from my side or from git's side.
I really dislike bookmarks and find them confusing.

That is why I am also flirting with the changesets in hg-git I mentioned
that allow to export named branches. The real challenge is to import git
branches into named branches, rebasing with evolve seems to work, I wounder how
stable that workflow will be.



Uwe

> Best wishes,
> Arne