Hi Philip,
On 10/12/2017 13:22, Phillip Wood wrote:
>
> 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
No problem, and thanks for clarifying, I understand and agree to all
that with you. I was just pointing that it wasn`t something I was
commenting to (nor specially interested in), because of what Alexei
actually wrote - here`s his quote (emphasis mine):
"And then I often find that "rebase -i --autosquash" _fails to apply
the commit B_ because it expects slightly different context around
the changed lines."
>From there, it seemed pretty clear he perceived the failure not
coming from creating A', but applying B on top of it, and that is
what got my attention. But, read below...
> > - 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
Yeah, what I assumed (and agreed to), thanks for confirmation. What
made me a bit uncertain was that you left that part of my earlier
message quoted _after_ your inline reply to it, thus making overall
context a bit difficult to be exactly sure in :P
> 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.
Yes, I understand and agree you might be right, what you are talking
about being what he actually _meant_, but because that is not what he
_wrote_, I wanted to see an example of it, (still?) hoping that he
really did mean what he wrote (commit B being the problematic one),
as then there would be a possibility for improvement.
And your analysis seems correct, and that`s what I was afraid of as
well - but wasn`t really sure, especially as I seem to remember
something similar from my own (humble) experience, thus leaving a
possibility for an example to prove differently.
But if that is absolutely impossible, as you claim, like not even due
to some commit squashing, some edge case, or something - and I don`t
feel like I have enough knowledge/experience to judge that myself at
the moment - then you have to be right, and what he wrote is really
not what he meant... nor what I thought I remembered from my own past
experience, either :/ Nor there is any chance for improvement here,
unfortunately, I guess.
Still, I hope for that example...! :D
> 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
This is useful, thanks. I have something like `git commit --amend
<commit>` on my wish list for quite some time :) Still not getting to
look into it, though.
> > 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.
Yes, and thus the notion of what he mentioned as being a "(very?)
specific case" ;) That initial/draft version of "git commit
--onto-parent" script I sent to the list[1] operates on the first
parent commit only, indeed, though its main point/purpose had nothing
to do with smarter merges, but just not touching the working tree
while at it, if possible.
> > > 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.
Yes, I think we understand each other now (unfortunately, I guess, as
that also means there is nothing more to add to it, in terms of
improving existing situation). Thank you for your thoughts :)
Regards, Buga
[1] https://public-inbox.org/git/4a92e34c-d713-25d3-e1ac-100525011d3f@xxxxxxxxxxxx/T/#m72f45ad7a8f1c733266a875bca087ee82cc781e7
