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, 23:17 UTC
Message-ID: <36d2b05b-8b68-a157-99ed-44050ac34ab6@gmail.com>
In-Reply-To: <82da4317-6b50-f60d-6d8f-50fc47579c56@talktalk.net>

Hi Philip,

On 10/12/2017 13:22, Phillip Wood wrote:

Show 6 quoted lines

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

Show 26 quoted lines

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

Show 5 quoted lines

> 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

Show 8 quoted lines

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

Show 11 quoted lines

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

Show 17 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.
> 
> 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@talktalk.net/T/#m72f45ad7a8f1c733266a875bca087ee82cc781e7