All of lore.kernel.org
 help / color / mirror / Atom feed
From: Johannes Schindelin <Johannes.Schindelin@gmx.de>
To: Junio C Hamano <gitster@pobox.com>
Cc: Jeff King <peff@peff.net>,
	Dakota Hawkins <dakotahawkins@gmail.com>,
	git@vger.kernel.org
Subject: Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email"
Date: Fri, 9 Sep 2016 17:32:28 +0200 (CEST)	[thread overview]
Message-ID: <alpine.DEB.2.20.1609091731540.129229@virtualbox> (raw)
In-Reply-To: <xmqqvaz7x6vv.fsf@gitster.mtv.corp.google.com>

Hi Junio,

On Thu, 11 Aug 2016, Junio C Hamano wrote:

> Earlier, Peff sent this patch (slightly buried in a discussion) on
> "rebase -i" in <20160729223134.GA22591@sigill.intra.peff.net>.
> 
> > Subject: rebase-interactive: drop early check for valid ident
> >
> > Since the very inception of interactive-rebase in 1b1dce4
> > (Teach rebase an interactive mode, 2007-06-25), there has
> > been a preemptive check, before looking at any commits, to
> > see whether the user has a valid name/email combination.
> >
> > This is convenient, because it means that we abort the
> > operation before even beginning (rather than just
> > complaining that we are unable to pick a particular commit).
> >
> > However, it does the wrong thing when the rebase does not
> > actually need to generate any new commits (e.g., a
> > fast-forward with no commits to pick, or one where the base
> > stays the same, and we just pick the same commits without
> > rewriting anything). In this case it may complain about the
> > lack of ident, even though one would not be needed to
> > complete the operation.
> >
> > This may seem like mere nit-picking, but because interactive
> > rebase underlies the "preserve-merges" rebase, somebody who
> > has set "pull.rebase" to "preserve" cannot make even a
> > fast-forward pull without a valid ident, as we bail before
> > even realizing the fast-forward nature.
> >
> > This commit drops the extra ident check entirely. This means
> > we rely on individual commands that generate commit objects
> > to complain. So we will continue to notice and prevent cases
> > that actually do create commits, but with one important
> > difference: we fail while actually executing the "pick"
> > operations, and leave the rebase in a conflicted, half-done
> > state.
> >
> > In some ways this is less convenient, but in some ways it is
> > more so; the user can then manually commit or even "git
> > rebase --continue" after setting up their ident (or
> > providing it as a one-off on the command line).
> >
> > Reported-by: Dakota Hawkins <dakotahawkins@gmail.com>
> > Signed-off-by: Jeff King <peff@peff.net>
> > ---
> 
> To which, I responded (referring to the last paragraph):
> 
>     Yup, that is the controvercial bit, and I suspect Dscho's original
>     was siding for the "set up ident first, as you will need it anyway
>     eventually", so I'll let others with viewpoints different from us to
>     chime in first before picking it up.
> 
> Do you have a preference either way to help us decide if we want to
> take this change or not?

I have no strong preference. I guess that it does not hurt to go with the
patch, and it would probably help in a few cases.

Ciao,
Dscho

  reply	other threads:[~2016-09-09 15:32 UTC|newest]

Thread overview: 18+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-29  9:17 Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - "user.email" Dakota Hawkins
2016-07-29 17:47 ` Junio C Hamano
2016-07-29 18:11   ` Jeff King
2016-07-29 18:32     ` Junio C Hamano
2016-07-29 18:39       ` Jeff King
2016-07-29 18:52         ` Jeff King
2016-07-29 18:37     ` Junio C Hamano
2016-07-29 22:31       ` Jeff King
2016-07-29 22:45         ` Junio C Hamano
2016-07-29 22:49           ` Jeff King
2016-07-30 16:41             ` Dakota Hawkins
2016-08-11 22:44         ` Junio C Hamano
2016-09-09 15:32           ` Johannes Schindelin [this message]
2016-09-09 16:09             ` Junio C Hamano
2016-09-09 19:00               ` Junio C Hamano
2016-09-09 23:31                 ` Dakota Hawkins
2016-07-29 18:20   ` Junio C Hamano
2016-07-29 18:31     ` Jeff King

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=alpine.DEB.2.20.1609091731540.129229@virtualbox \
    --to=johannes.schindelin@gmx.de \
    --cc=dakotahawkins@gmail.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=peff@peff.net \
    /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.