Hello Dscho,

W dniu 11.09.2016 o 10:33, Johannes Schindelin napisał: 

On Fri, 9 Sep 2016, Jakub Narębski wrote:

[...]

quoted

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(2fd4e1c6...) da39a3ee... \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

There probably should be there

 	mark typo-fix

	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.

Do I understand it correctly that it is user-visible instruction sheet, and
not the internal instruction sheet for sequencer?  This looks very nice
and is well readable.

I guess that it needs to be pre-populated by Git based on topology of the
branch being rebased.

As I see, there are three basic topologies of non-linear branch to be
rebased; all else is combination of thereof, or derivative:

1. Merge commit without branching point, that is we need to go
   from the following situation

   *---*---*---#---o---o---o        <-- old base
               \\
                \\=a===b===M===c    <-- branch being rebased
                          /
         ...---x---x---x-/          <-- side branch

  to the following:

   *---*---*---#---o---o---o        
                            \
                             \-a'--b'--M'--c' 
                                      /
         ...---x---x---x-------------/          

I think this case is the only one supported by `--preserve-merges`,
but I may be mistaken - I never had the need to use this feature IRL.

2. Branching point without accompanying merge commit, or in other words
   rebasing many branches tied together; a shrub if you will.  That is,
   we want to go from the following situation:

   *---*---*---#---o---o---o           <-- old base
               \
                \--a---b---c           <-- branch being rebased
                        \
                         \-1           <-- dependent branch

   to the following one:

   *---*---*---#---o---o---o
                            \
                             \--a'--b'--c'
                                     \
                                      \-1'

I don't think Git supports something like that out of the box, but it
is not hard to create something like that "by hand". It is not much
of a problem... unless you forget to rebase the second dependent branch.

3. Branching point with merge point, that is subbranch created and
   merged - an "eye" (it is not a loop in DAG):

   *---*---*---#---o---o---o             <-- old base
               \
                \--a---b---c---M---d     <-- branch being rebased
                    \         /
                     \-1---2-/         [ <-- possibly a branch ]

   All edges are directed edges, with arrows pointing from right to
   left; that is  *---*  is really  *<---*

   The expected result is:

   *---*---*---#---o---o---o
                            \
                             \--a'--b'--c'--M'--d'
                                 \         /
                                  \-1'--2'/

I guess that is the main purpose of your git-garden-shears script,
isn't it?

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

There is also an additional complication in that merge commit message
may be *partially* automatically generated. First there is the subject
generated by 'git merge' ("Merge branch 'foo'") or 'git pull <URL>'.
It might have been translated, or extended.  Second there is a place
for branch cover letter. Third, subject to merge.log / merge.summary
there is a shortlog.

From those shortlog should be surely updated to correspond to the
post-rebase state.  The first line could be used to pre-populate
mark lines, but during merge it should be, I think, updated to the
new name of internal branch if it was changed.


As to 'merge -C <sha1> <marker>' vs 'remerge <sha1> <marker>',
I don't have specified opinion.  It would be nice to have one
character shortcuts for insn sheet instructions, to which
'm -C <sha1> <marker>' is more amendable... 

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.

Right. No need to make user do something that computer can easily
and without errors do.

No :1 or some such. That's machine readable. But it's utter nonsense for
user-facing UIs.

Of course. It's all right for machine-facing instructions, like the
'todo' file for the sequencer, or for git-fast-import stream...

Ciao,
Dscho

Footnote *1*:
https://github.com/git-for-windows/build-extra/blob/master/shears.sh

 
P.S. I wonder if git-imerge[2] requires for integrated branches to have
both linear history for it to work.

[2]: https://github.com/mhagger/git-imerge
     http://softwareswirl.blogspot.com/2013/05/git-imerge-practical-introduction.html
     https://www.youtube.com/watch?v=FMZ2_-Ny_zc

Best,
-- 
Jakub Narębski