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

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

On 10/12/17 01:20, Igor Djordjevic wrote:
> 
> Hi Philip,
> 
> On 09/12/2017 20:01, Phillip Wood wrote:
>>
>>> 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`m a bit confused here, as you`re replying to the part where we 
> strictly discussed `rebase --autosquash` versus `rebase --onto`, 
> having the latter succeed where the former fails

Sorry I should have been clearer. The point I was somewhat obliquely
making was that 'rebase --onto' succeeds where 'rebase --autosquash'
fails not because it is smarter but because it is doing something
different. Specifically it avoids the conflicting merge to create A' as
the user has already created that commit in the temporary branch


> - but you`re 
> mentioning `git _commit_ --onto` instead, comparing it with `rebase`... 
> and which one of the two ("--autosquash", I assume)?

Yes because in an earlier message you said

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

and I was pointing out that this would involve performing the same merge
as 'rebase --autosquash' which has conflicts

> 
> Even further, while I do seem to understand (and agree with) what 
> you`re talking about with `commit --onto` and `rebase --autosquah` 
> suffering from the same conflicts in attempt to take f!A, originally 
> created on top of B, and apply it on top of A - the thing is that 
> Alexei actually pointed to B being the problematic one, failing to 
> rebase on top of already (successfully) autosquashed A' (where A' = A 
> + f!A, fixup applied through --autosquash), while it doesn`t fail 
> rebasing --onto f!A when f!A is being committed on top of A directly 
> (and not through --autosquash).

I understood Alexei to mean that it was merging the f!A into A that
caused conflicts due to the fact that f!A has conflicting context that
was introduced in B. After all B' the rebased B is merge A A' B whether
it is created by 'rebase --autosquash' or 'rebase --onto'. A' must be
the same in both cases or one is applying a different fix.

I've found conflicts arising from moving fixups can be quite common, so
these days I tend to edit the commit to be fixed up directly. I have a
script git-amend that does something like

target=$(git rev-parse --verify "$1") && GIT_SEQUENCE_EDITOR="sed -i
s/^pick $target/edit $target/" rebase -ik $target^

so I can just type 'git amend <commit>' to make this easier

> 
> In that (very?) specific case, proposed `git commit --onto-parent`[1] 
> doesn`t suffer from this, as once f!A is successfully applied onto A 
> (either squashed in with --amend, or on top of it), we take original 
> f!A _snapshot_ (not patch!) made on top of B, and just "declare" it 
> B` (being equal to B + f!A, which we already know, and being 
> correct), without a need to (try to) apply B patch on top of fixed-up 
> A to create B', as `rebase` does (and fails).

Ah I understand, but that only works when you're fixing up HEAD~1. If
you had A-B-C-f!A you have to recreate B with a merge.

> 
>> 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.
> 
> I think I agree on this part being tricky (if possible at all), but I 
> also think this is not what Alexei was complaining about, nor what we 
> were discussing (as I tried to explain above) - but please do correct 
> me if I misunderstood you.

No, I don't think Alexei was complaining about that directly, but if
such a solution existed he (and everyone else) wouldn't have to bother
with the --onto approach in the case where merging the fixup creates
conflicts.

Best Wishes


Phillip

> 
> That said, and what I mentioned already, we might really benefit from 
> simple test case(s), showing "rebase --autosquash" failing where 
> "rebase --onto" works, as Alexei explained, giving some more (and 
> firm) context to the discussion.
>
> 
> I *think* I`ve experienced this in the past myself, but now I can`t 
> seem to wrap my head around a reproducible example just yet... :$
> 
> Regards, Buga
> 
> [1] https://public-inbox.org/git/4a92e34c-d713-25d3-e1ac-100525011d3f@talktalk.net/T/#m72f45ad7a8f1c733266a875bca087ee82cc781e7
>