From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: Elijah Newren <newren@gmail.com>, git@vger.kernel.org
Subject: Re: [ANNOUNCE] Git v2.26.0-rc1
Date: Tue, 10 Mar 2020 13:40:17 -0400 [thread overview]
Message-ID: <20200310174017.GA549010@coredump.intra.peff.net> (raw)
In-Reply-To: <xmqqo8t4z29k.fsf@gitster-ct.c.googlers.com>
On Tue, Mar 10, 2020 at 07:57:11AM -0700, Junio C Hamano wrote:
> * "git rebase" has learned to use the merge backend (i.e. the
> machinery that drives "rebase -i") by default, while allowing
> "--apply" option to use the "apply" backend (e.g. the moral
> equivalent of "format-patch piped to am"). The rebase.backend
> configuration variable can be set to customize.
I noticed a few behavior changes that I think are related to this
switch. I'm not sure to what degree we'd consider these a problem
(though the second I think may be an existing bug in the merge backend
that's just getting more attention), but it seems like the time to raise
the issue is now, before the release. :)
The first change is that we'll now open an editor when continuing a
conflicted rebase. You can see it by running this:
for backend in apply merge; do
echo "==> Running with rebase.backend=$backend"
# new repo
rm -rf repo
git init -q repo
cd repo
# create two conflicting branches
echo base >base && git add base && git commit -qm base
echo master >file && git add file && git commit -qm master
git checkout -q -b side HEAD^
echo side >file && git add file && git commit -qm side
# rebase on master, hit the conflict, then resolve it
git -c rebase.backend=$backend rebase master
echo resolved >file
git add file
# continue the rebase, noting whether we used the editor
GIT_EDITOR='echo >&2 running editor on:' git rebase --continue
done
We won't run the editor the "apply" backend, but do for "merge". I'm
not sure how big a deal this is. It bit me because I have a script which
runs rebase in a "while read" shell loop, with stdin coming from a pipe
feeding the loop. It auto-continues when rerere is able to fix up the
conflicts, but the editor complains about stdin not being a tty and
dies.
I'd imagine that's a pretty rare situation, and it was easy enough to
fix up. But I wonder if we should be more careful about making sure the
behavior is more identical. On the other hand, I imagine this is the way
the merge backend has always behaved, so it would be a change in
behavior for people who had been using it already. I guess the _most_
compatible thing would be a merge-that-behaves-more-like-apply backend,
but I'm not sure if we want to support that forever.
The second thing I noticed is more clearly a bug, I think. If we have a
patch that is skipped because it was already applied, we get stuck in
"cherry-picking" mode. Try:
for backend in apply merge; do
echo "==> Running with rebase.backend=$backend"
# new repo
rm -rf repo
git init -q repo
cd repo
echo base >file && git add file && git commit -qm base
# do this in two steps so we don't match patch-id
echo one >file && git commit -qam master-1
echo two >file && git commit -qam master-2
git checkout -q -b side HEAD~2
echo two >file && git commit -qam side
# start a rebase, which should realize that the patch is a noop
git -c rebase.backend=$backend rebase master
# see what state "status" reports us in
git status
done
For the "apply" case, I get:
==> Running with rebase.backend=apply
First, rewinding head to replay your work on top of it...
Applying: side
Using index info to reconstruct a base tree...
M file
Falling back to patching base and 3-way merge...
No changes -- Patch already applied.
On branch side
nothing to commit, working tree clean
So we complete the rebase, and git-status shows nothing. But for the
merge backend:
==> Running with rebase.backend=merge
dropping f8b25a2cd2a3a0e64d820efe2fcbae81dec98616 side -- patch contents already upstream
Successfully rebased and updated refs/heads/side.
On branch side
You are currently cherry-picking commit f8b25a2.
nothing to commit, working tree clean
Oops. If I "git rebase --continue" from there, I get "No rebase in
progress?". Doing "git cherry-pick --skip" clears it. I guess the issue
is the continued presence of .git/CHERRY_PICK_HEAD.
As you can see from the output above (and the earlier snippet, if you
run it), there are also a bunch of minor stderr output changes. I think
these probably aren't worth caring about.
-Peff
next prev parent reply other threads:[~2020-03-10 17:40 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-03-10 14:57 [ANNOUNCE] Git v2.26.0-rc1 Junio C Hamano
2020-03-10 17:40 ` Jeff King [this message]
2020-03-10 19:08 ` Junio C Hamano
2020-03-10 19:27 ` Elijah Newren
2020-03-10 19:48 ` Jeff King
2020-03-10 20:58 ` Junio C Hamano
2020-03-11 16:28 ` Jeff King
2020-03-11 5:25 ` Elijah Newren
2020-03-11 13:54 ` Randall S. Becker
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:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
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 \
--in-reply-to=20200310174017.GA549010@coredump.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=newren@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* 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
https://80x24.org/mirrors/git.git
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).