All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Sixt <j6t@kdbg.org>
To: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Cc: Junio C Hamano <gitster@pobox.com>,
	Git Mailing List <git@vger.kernel.org>
Subject: Re: Small rerere in rebase regression
Date: Fri, 27 May 2016 18:28:21 +0200	[thread overview]
Message-ID: <574875A5.9040303@kdbg.org> (raw)
In-Reply-To: <alpine.DEB.2.20.1605250710340.4449@virtualbox>

Am 25.05.2016 um 07:38 schrieb Johannes Schindelin:
> In short: yes, the explicit `git rerere` call can be dropped, that is
> essentially what I did in the rebase--helper branch.

Here's a patch to do that.

--- 8< ---
Subject: [PATCH] rebase -i: remove an unnecessary 'rerere' invocation

Interactive rebase uses 'git cherry-pick' and 'git merge' to replay
commits. Both invoke the 'rerere' machinery when they fail due to merge
conflicts. Note that all code paths with these two commands also invoke
the shell function die_with_patch when the commands fail.

Since commit 629716d2 ("rerere: do use multiple variants") the second
operation of the rerere machinery can be observed by a duplicated
message "Recorded preimage for 'file'". This second operation records
the same preimage as the first one and, hence, only wastes cycles.
Remove the 'git rerere' invocation from die_with_patch.

Shell function die_with_patch can be called after the failure of
"git commit", too, which also calls into the rerere machinery, but it
does so only after a successful commit to record the resolution.
Therefore, it is wrong to call 'git rerere' from die_with_patch after
"git commit" fails.

Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
 git-rebase--interactive.sh | 1 -
 1 file changed, 1 deletion(-)

diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 9d2bfb7..6e96abc 100644
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -192,7 +192,6 @@ make_patch () {
 die_with_patch () {
 	echo "$1" > "$state_dir"/stopped-sha
 	make_patch "$1"
-	git rerere
 	die "$2"
 }
 
-- 
2.9.0.rc0.40.gb3c1388

  parent reply	other threads:[~2016-05-27 16:28 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-05-23 18:01 Small rerere in rebase regression Johannes Sixt
2016-05-23 19:43 ` Junio C Hamano
2016-05-23 21:30   ` Johannes Sixt
2016-05-23 22:11     ` Junio C Hamano
2016-05-24 13:18       ` Johannes Schindelin
2016-05-24 19:48         ` Johannes Sixt
2016-05-25  5:38           ` Johannes Schindelin
2016-05-25  5:47             ` Johannes Schindelin
2016-05-27 16:28             ` Johannes Sixt [this message]
2016-05-28  6:39               ` Johannes Schindelin
2016-05-24 20:46       ` Johannes Sixt

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

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

  git send-email \
    --in-reply-to=574875A5.9040303@kdbg.org \
    --to=j6t@kdbg.org \
    --cc=Johannes.Schindelin@gmx.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.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.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.