mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Phillip Wood <>
To: Igor Djordjevic <>,,
	Alexei Lozovsky <>
Cc: Junio C Hamano <>, Johannes Sixt <>,
	Git Mailing List <>,
	Nikolay Shustov <>,
	Johannes Schneider <>,
	Patrik Gornicz <>,
	Martin Waitz <>,
	Shawn Pearce <>, Sam Vilain <>,
	Jakub Narebski <>
Subject: Re: [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking tree file changes)
Date: Sun, 10 Dec 2017 12:22:35 +0000	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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

Best Wishes


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

  reply	other threads:[~2017-12-10 12:22 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-26 22:35 [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes) Igor Djordjevic
2017-11-26 22:36 ` [SCRIPT/RFC 1/3] Igor Djordjevic
2017-11-26 22:36 ` [SCRIPT/RFC 2/3] git-merge-one-file--cached Igor Djordjevic
2017-11-26 22:45 ` [SCRIPT/RFC 3/3] Igor Djordjevic
2017-11-27 21:54 ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working tree file changes) Johannes Sixt
2017-11-28  1:15   ` Igor Djordjevic
2017-11-29 19:11     ` Johannes Sixt
2017-11-29 23:10       ` Igor Djordjevic
2017-12-01 17:23         ` Johannes Sixt
2017-12-04  2:33           ` Igor Djordjevic
2017-12-06 18:34             ` Johannes Sixt
2017-12-06 18:40               ` Junio C Hamano
2017-12-08  0:15                 ` Igor Djordjevic
2017-12-08 16:24                   ` Junio C Hamano
2017-12-08 23:54                     ` Igor Djordjevic
2017-12-09  2:18                       ` Alexei Lozovsky
2017-12-09  3:03                         ` Igor Djordjevic
2017-12-09 19:00                           ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking " Phillip Wood
2017-12-09 19:01                           ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, noworking " Phillip Wood
2017-12-10  1:20                             ` Igor Djordjevic
2017-12-10 12:22                               ` Phillip Wood [this message]
2017-12-10 23:17                                 ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking " Igor Djordjevic
2017-12-11  1:13                                   ` Alexei Lozovsky
2017-12-11  1:00                                 ` Alexei Lozovsky
2017-11-30 22:40 ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge, no working " Chris Nerwert
2017-12-03 23:01   ` Igor Djordjevic

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

  List information:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \ \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).