Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes)

> On 29/11/2017 20:11, Johannes Sixt wrote:
>> With git-post, I make a fixup commit commit on the integration
>> branch, then `git post B && git merge B`:
>>
>>   ...A    ...C                  <- topics A, C
>>       \       \
>>     ---o---o---o---o---f---F    <- integration
>>           /       /       /
>>       ...B    ...D       /      <- topic D
>>           \             /
>>            f'----------'        <- topic B
>>
>> The merge F does not introduce any changes on the integration branch,
>> so I do not need it, but it helps keep topic B off radar when I ask
>> `git branch --no-merged` later.
> 
> But you`re not committing (posting) on your HEAD`s (direct) parent in
> the first place (topic B), so `commit --onto-parent` isn`t right tool
> for the job... yet :)

> To work with `--onto-parent` and be able to commit on top of any of
> the topic branches, you would need a situation like this instead:
> 
>   (1)  ...C      <- topic C
>           |
>      ...A |      <- topic A
>          \|
>        ...o I    <- integration
>          /|
>      ...B |      <- topic B
>           |
>        ...D      <- topic D

> With `commit --onto-parent` you would skip `git post B && git merge
> B` steps, where "fixup commit" would be done with `--onto-parent B`,
> So you end up in situation like this:
> 
>   (2)      ...C      <- topic C
>               |
>          ...A |      <- topic A
>              \|
>            ...o I'   <- integration
>              /|
>      ...B---f |      <- topic B
>               |
>            ...D      <- topic D
> 
> State of index and working tree files in your F and my I' commit is
> exactly the same (I' = I + f), where in my case (2) history looks
> like "f" was part of topic B from the start, before integration
> merge happened.
> 
> BUT, all this said, I understand that your starting position, where
> not all topic branches are merged at the same time (possibly to keep
> conflict resolution sane), is probably more often to be encountered
> in real-life work... and as existing `--onto-parent` machinery should
> be able to support it already, I`m looking forward to make it happen :)
> 
> Once there, starting from your initial position:
> 
>>     ...A    ...C            <- topics A, C
>>         \       \ E
>>       ---o---o---o---o I    <- integration <- HEAD
>>             /       /
>>         ...B    ...D        <- topics B, D
> 
> ... and doing something like `git commit --onto B --merge` would yield:
>   
>   (3) ...A    ...C            <- topics A, C
>           \       \ E
>         ---o---o---o---o I'   <- integration
>               /       /|
>           ...B    ...D |      <- topic D
>               \        |
>                f-------'      <- topic B
> 
> ... where (I' = I + f) is still true.

> If that`s preferred in some
> cases, it could even look like this instead:
> 
>   (4) ...A    ...C             <- topics A, C
>           \       \ E  I
>         ---o---o---o---o---F   <- integration
>               /       /   /
>           ...B    ...D   /     <- topic D
>               \         /
>                f-------'       <- topic B
> 
> ... where F(4) = I'(3), so similar situation, just that we don`t
> discard I but post F on top of it.