Hi Kuba, On Fri, 9 Sep 2016, Jakub Narębski wrote: > Hello Johannes, > > W dniu 09.09.2016 o 17:12, Johannes Schindelin napisał: > > On Thu, 1 Sep 2016, Junio C Hamano wrote: > >> Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > > >> I was sort of expecting that, when you do the preserve-merges mode > >> of "rebase -i", you would need to jump around, doing "we have > >> reconstructed the side branch on a new 'onto', let's give the result > >> this temporary name ':1', and then switch to the trunk (which would > >> call for 'reset <commit>' instruction) and merge that thing (which > >> would be 'merge :1' or perhaps called 'pick :1')", and at that point > >> you no longer validate the object references upfront. > > > > Except that is not how --preserve-merges works: it *still* uses the SHA-1s > > as identifiers, even when the SHA-1 may have changed in the meantime. > > > > That is part of why it was a bad design. > > When preserving merges, there are (as far as I understand it), two > problems: > - what it means to preserve changes (which change to pick, > that is what is the mainline changes rebase is re-applying) > - what are parents of the merge commit (at least one parent > would be usually rewritten) > > Maybe the internal (and perhaps also user-visible) representation > of merge in instruction sheet could use the notation of filter-branch, > that is 'map(<sha-1>)'... it could also imply the mainline. > > That is the instruction in the internal instruction sheet could > look like this: > > merge -m 1 map(2fd4e1c67a2d28fced849ee1bb76e7391b93eb12) da39a3ee5e6b4b0d3255bfef95601890afd80709 \t Merge 'foo' into master > > > Note that it has nothing to do with this series! Right. But I did solve that already. In the Git garden shears [*1*] (essentially my New And Improved attempt at recreating branch structures while rebasing), I generate and process scripts like this: mark onto # Branch: super-cool-feature rewind onto pick 00001 feature pick 00002 documentation mark super-cool-feature # Branch: typo-fix rewind onto pick 0000a fix a tyop rewind onto merge -C cafebabe super-cool-feature merge -C babecafe typo-fix cleanup super-cool-feature typo-fix Of course this will change a little, still, once I get around to implement this on top of the rebase--helper. For example, I am not so hot about the "merge -C ..." syntax. I'll probably split that into a "remerge <SHA-1> <mark>" and a new "merge <mark>" command (the latter asking interactively for the merge commit message). And also: the cleanup stage should not be necessary, as the "mark" commands can accumulate the known marks into a file in the state directory. But you get the idea. No :1 or some such. That's machine readable. But it's utter nonsense for user-facing UIs. Ciao, Dscho Footnote *1*: https://github.com/git-for-windows/build-extra/blob/master/shears.sh