Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking tree file changes)
On Dec 11, 2017, at 01:17, Igor Djordjevic wrote: > On 10/12/2017 13:22, Phillip Wood wrote: >> 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. I'm not really good at remembering the exact details, so if you ask for a testimony then I'm not sure whether it's the conflicts in the fixups or the later commits that I was annoyed by :) I'm also not really versed in the technical details of rebasing, so I cannot give an educated guess on which one is more likely to cause conflicts. > Still, I hope for that example...! :D I keep this thread pinned, so I hope to provide a more concrete example as soon as I encounter the conflicting situation again in the wild. I'm not sure that I am able to construct a relevant example artificially.
Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking tree file changes)
On Dec 10, 2017, at 14:22, Phillip Wood wrote: > > 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 ' to make this easier Hm... I just realized that using "edit" command during interactive rebase should probably be the same as the strategy with a temporary branch and rebase --onto I described earlier. I should fix my habits, I guess.
Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking tree file changes)
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 ' to make this easier
This is useful, thanks. I have something like `git commit --amend
` 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
Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking tree file changes)
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 ' 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
Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, noworking tree file changes)
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-100525011...@talktalk.net/T/#m72f45ad7a8f1c733266a875bca087ee82cc781e7
Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking tree file changes)
Hi Igor On 09/12/17 03:03, Igor Djordjevic wrote: > > Hi Alexei, > > On 09/12/2017 03:18, Alexei Lozovsky wrote: >> >>> Chris reported in this very topic[1] that sometimes, due to >>> conflicts with later commits, "checkout > commit > [checkout >] >>> rebase --onto" is "much easier to do", where "commit --fixup > >>> rebase -i" "breaks" (does not apply cleanly). >> >> It was more of a rant about conflict resolution by rebase rather than >> a concern about modification time of files. While I'd prefer git to >> not touch the source tree unnecessarily, it's not really a big deal >> for me if it does and some parts of the project need to be rebuilt. > > Nevertheless, I found it valuable in supporting the case where > "commit --fixup > rebase -i" seems to require even more work than > otherwise necessary :) > > 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 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. Best Wishes Phillip > > Even though your explanation seems clear, having a real, easily > reproducible case would help as well, I guess. > >> I kinda hoped that you may know this magic and incorporate it into >> "commit --onto" which will allow to immediately get to the result of >> the rebase: >> >> ---A---f!A---B' >> >> without spelling it all manually. > > 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' > > You could even do this instead: > > git commit --onto-parent A --amend > > ending up with: > > ---A'---B' > > as that is basically what you wanted in the first place ;) > >> (And yeah, I'm actually Alexei, not Chris. That was my MUA being >> dumb and using an old pseudonym than Google insists I'm called by.) > > Ah, sorry for the confusion :) > > Regards, Buga >
Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, noworking tree file changes)
Hi Igor On 09/12/17 03:03, Igor Djordjevic wrote: > > Hi Alexei, > > On 09/12/2017 03:18, Alexei Lozovsky wrote: >> >>> Chris reported in this very topic[1] that sometimes, due to >>> conflicts with later commits, "checkout > commit > [checkout >] >>> rebase --onto" is "much easier to do", where "commit --fixup > >>> rebase -i" "breaks" (does not apply cleanly). >> >> It was more of a rant about conflict resolution by rebase rather than >> a concern about modification time of files. While I'd prefer git to >> not touch the source tree unnecessarily, it's not really a big deal >> for me if it does and some parts of the project need to be rebuilt. > > Nevertheless, I found it valuable in supporting the case where > "commit --fixup > rebase -i" seems to require even more work than > otherwise necessary :) > > 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 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. Best Wishes Phillip > > Even though your explanation seems clear, having a real, easily > reproducible case would help as well, I guess. > >> I kinda hoped that you may know this magic and incorporate it into >> "commit --onto" which will allow to immediately get to the result of >> the rebase: >> >> ---A---f!A---B' >> >> without spelling it all manually. > > 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' > > You could even do this instead: > > git commit --onto-parent A --amend > > ending up with: > > ---A'---B' > > as that is basically what you wanted in the first place ;) > >> (And yeah, I'm actually Alexei, not Chris. That was my MUA being >> dumb and using an old pseudonym than Google insists I'm called by.) > > Ah, sorry for the confusion :) > > Regards, Buga >
