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

From: Phillip Wood <phillip.wood@talktalk.net>
Date: Dec 9, 2017, 19:01 UTC
Message-ID: <4a92e34c-d713-25d3-e1ac-100525011d3f@talktalk.net>
In-Reply-To: <92643df4-f54e-cd31-da4a-138ec314655a@gmail.com>

Hi Igor

On 09/12/17 03:03, Igor Djordjevic wrote:

Show 22 quoted lines

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

Show 47 quoted lines

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