graft/rebase without changing the hash

[Georges Racinet]

Hi Uwe,

On 11/26/22 13:44, Dr. Arne Babenhauserheide wrote:
> Hi Uwe,
>
> Uwe Brauer <oub at 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.
The parents are also 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.

Besides, hg-git includes the branch name into the resulting Git commit, 
unless it is `default`. I don't remember how configurable that is (nor 
even if it works the same way with the most recent hg-git versions), BUT 
this is not the fundamental problem:

In Git, the parent commits hashes are also part of a given commit hash.

The bottom line would be that what you are asking is conceptually 
contradictory with this whole class of DVCSes where any change set is 
anchored in the strongest possible way to the context (i.e., its 
parents) in which it was produced. For completeness, this is not the 
case of Pijul (https://pijul.org, one of the youngest systems around) 
nor darcs (patch-based, 2 years older than Git and Mercurial).


Best,


-- 
Georges Racinet
https://octobus.net, https://about.heptapod.host, https://heptapod.net
GPG: BF5456F4DC625443849B6E58EE20CA44EF691D39, sur serveurs publics