mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Igor Djordjevic <>
To:, 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: Mon, 11 Dec 2017 00:17:32 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

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


  reply	other threads:[~2017-12-10 23:17 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                               ` [SCRIPT/RFC 0/3] git-commit --onto-parent (three-way merge,noworking " Phillip Wood
2017-12-10 23:17                                 ` Igor Djordjevic [this message]
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).