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 - 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).
> 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@xxxxxxxxxxxx/T/#m72f45ad7a8f1c733266a875bca087ee82cc781e7
