All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Johannes Sixt <j6t@kdbg.org>
Cc: Git Mailing List <git@vger.kernel.org>
Subject: Re: Small rerere in rebase regression
Date: Mon, 23 May 2016 15:11:16 -0700	[thread overview]
Message-ID: <xmqqk2ik77cr.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <57437693.3030106@kdbg.org> (Johannes Sixt's message of "Mon, 23 May 2016 23:30:59 +0200")

Johannes Sixt <j6t@kdbg.org> writes:

> I also come to the conclusion that die_with_patch shouldn't have to
> have a call to "git rerere". die_with_patch can be called after "git
> cherry-pick", "git merge", "git commit", all of which have their own
> rerere() invocation.
>
> However, calling "git rerere" after a failed "git commit" may be
> destructive: it would record a resolution even though the commit has
> not be completed. Think of an squash commit being aborted because the
> user notices an error in the last minute. If that error is in a
> conflict resolution, that wrong resolution would be recorded.

So, the behaviour change you observed uncovered a small bug in
"rebase -i" that was covered by the old limitation of "rerere" that
refrained from creating preimage when there already is one?

I think removing the call to "git rerere" there is a safe and
sensible thing regardless, but perhaps authors of "rebase -i" had
their own reasons.  I dunno (it is unlikely I'll have a chance to do
blame and digging today).

  reply	other threads:[~2016-05-23 22:11 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 [this message]
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
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=xmqqk2ik77cr.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=j6t@kdbg.org \
    /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.