mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Jeff King <>
To: Junio C Hamano <>
Cc: Dakota Hawkins <>,
Subject: Re: Issue with global config defaults "user.useConfigOnly = true" + "pull.rebase = preserve" - ""
Date: Fri, 29 Jul 2016 14:11:22 -0400	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On Fri, Jul 29, 2016 at 10:47:27AM -0700, Junio C Hamano wrote:

> > In those cases specifically, I never have local commits that differ
> > from the remote, so a "pull --ff-only" should leave me in the same
> > state as a "pull --rebase".
> >
> > Is this a case of rebase trying to make sure it has enough information
> > for me to be a committer before knowing whether I even need to rewrite
> > any commits, and could/should that be avoided?  Alternatively (or also)
> > could/should rebase detect that a fast-forward is possible and prefer
> > to do that instead?
> I think that is a reasonable argument, but to solve this for a more
> general case, shouldn't we be discussing a solution that would also
> work when rebase _does_ need to create a new commit?  And when the
> latter is solved, I would imagine that "this rebase happens to be
> fast-forward, and not having an ident shouldn't be an issue for this
> special case" would become moot.

Wouldn't it be wrong to create a commit with non-config ident when
user.useConfigOnly is set, though? That is the exact point when it
should kick in, to tell the user "you thought it would not matter here,
but in this case we _do_ need your real ident; what should we do?"

If the user is doing a one-off thing where they do not care if their
crappy, fake ident makes it into a commit object, then the right thing

  git -c user.useConfigOnly=false pull --rebase

or even:

  git -c pull --rebase

And they can do that preemptively for commands like the golang example
here. They shouldn't _have_ to do that, though, if the command wouldn't
actually create a commit. So I do think there may be a bug to be fixed,
but it is simply commands being over-eager to make sure we have an
ident when they might not need it.


  reply	other threads:[~2016-07-29 18:11 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" - "" Dakota Hawkins
2016-07-29 17:47 ` Junio C Hamano
2016-07-29 18:11   ` Jeff King [this message]
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
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:

  List information:

* 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).