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

From: Igor Djordjevic <igor.d.djordjevic@gmail.com>
Date: Dec 10, 2017, 01:20 UTC
Message-ID: <da74fb2c-c452-4716-91d2-182f945b4254@gmail.com>
In-Reply-To: <4a92e34c-d713-25d3-e1ac-100525011d3f@talktalk.net>

Hi Philip,

On 09/12/2017 20:01, Phillip Wood wrote:

Show 9 quoted lines

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

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

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

Show 7 quoted lines

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

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