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

[Johannes Sixt <j6t@kdbg.org>]

Am 30.11.2017 um 00:10 schrieb Igor Djordjevic:
> 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 :)

Ohh..kay.

> 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

This is a very, VERY exotic workflow, I would say. How would you 
construct commit I when three or more topics have conflicts? 
merge-octopus does not support this use-case.

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

I am not used to this picture. I would not think that it is totally 
unacceptable, but it still has a hmm-factor.

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

This is very acceptable.

Nevertheless, IMO, it is not the task of git-commit to re-compute a 
merge commit. It would be OK that it commits changes on top of a branch 
that is not checked out. Perhaps it would even be OK to remove the 
change from the current workspace (index and worktree), because it will 
return in the form of a merge later, but producing that merge is 
certainly not the task of git-commit.

-- Hannes