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

[Phillip Wood <phillip.wood@talktalk.net>]

Hi Igor

On 09/12/17 03:03, Igor Djordjevic wrote:
> 
> Hi Alexei,
> 
> On 09/12/2017 03:18, Alexei Lozovsky wrote:
>>
>>> Chris reported in this very topic[1] that sometimes, due to
>>> conflicts with later commits, "checkout > commit > [checkout >]
>>> rebase --onto" is "much easier to do", where "commit --fixup >
>>> rebase -i" "breaks" (does not apply cleanly).
>>
>> It was more of a rant about conflict resolution by rebase rather than
>> a concern about modification time of files. While I'd prefer git to
>> not touch the source tree unnecessarily, it's not really a big deal
>> for me if it does and some parts of the project need to be rebuilt.
> 
> Nevertheless, I found it valuable in supporting the case where 
> "commit --fixup > rebase -i" seems to require even more work than 
> otherwise necessary :)
> 
> But thanks for clarifying, anyway, it does feel like `git rebase -i 
> --autosquash` could be smarter in this regards, if `git rebase 
> --onto` does it better...?

Creating the fixup directly on A rather than on top of B avoids the
conflicting merge B f!A A. Creating the fixup on top of B and then using
git commit --onto A would suffer from the same conflicts as rebase does.
I don't think there is any way for 'git rebase --autosquash' to avoid
the conflicts unless it used a special fixup merge strategy that somehow
took advantage of the DAG to resolve the conflicts by realizing they
come from a later commit. However I don't think that could be
implemented reliably as sometimes one wants those conflicting lines from
the later commit to be moved to the earlier commit with the fixup.

Best Wishes

Phillip

> 
> Even though your explanation seems clear, having a real, easily 
> reproducible case would help as well, I guess.
> 
>> I kinda hoped that you may know this magic and incorporate it into 
>> "commit --onto" which will allow to immediately get to the result of 
>> the rebase:
>>
>>   ---A---f!A---B'
>>
>> without spelling it all manually.
> 
> If you mind enough to be bothered testing it out, might be even 
> existing/initial state of originally proposed `git commit 
> --onto-parent` script would work for you, as it does incorporate some 
> trivial three-way merge resolution.
> 
> In your starting situation:
> 
>     ---A---B
> 
> .... you would just do something like:
> 
>     git commit --onto-parent A
> 
> .... hopefully ending up in the desired state (hopefully = conflicts 
> automatically resolved):
> 
>     ---A---C---B'
> 
> You could even do this instead:
> 
>     git commit --onto-parent A --amend
> 
> .... ending up with:
> 
>     ---A'---B'
> 
> .... as that is basically what you wanted in the first place ;)
> 
>> (And yeah, I'm actually Alexei, not Chris. That was my MUA being
>> dumb and using an old pseudonym than Google insists I'm called by.)
> 
> Ah, sorry for the confusion :)
> 
> Regards, Buga
>