From: Igor Djordjevic <email@example.com>
To: firstname.lastname@example.org, Alexei Lozovsky <email@example.com>
Cc: Junio C Hamano <firstname.lastname@example.org>, Johannes Sixt <email@example.com>,
Git Mailing List <firstname.lastname@example.org>,
Nikolay Shustov <email@example.com>,
Johannes Schneider <firstname.lastname@example.org>,
Patrik Gornicz <email@example.com>,
Martin Waitz <firstname.lastname@example.org>,
Shawn Pearce <email@example.com>, Sam Vilain <firstname.lastname@example.org>,
Jakub Narebski <email@example.com>
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: <firstname.lastname@example.org> (raw)
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` 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 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 :)
next prev parent 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] setup.sh 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] git-commit--onto-parent.sh 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
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: http://vger.kernel.org/majordomo-info.html
* 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).