From: Jeff King <peff@peff.net>
To: Junio C Hamano <gitster@pobox.com>
Cc: git@vger.kernel.org, Miles Bader <miles@gnu.org>
Subject: Re: [1.8.0] default "git merge" without argument to "git merge @{u}"
Date: Mon, 31 Jan 2011 15:14:19 -0500 [thread overview]
Message-ID: <20110131201419.GA9070@sigill.intra.peff.net> (raw)
In-Reply-To: <7vsjw957fq.fsf_-_@alter.siamese.dyndns.org>
On Mon, Jan 31, 2011 at 09:06:33AM -0800, Junio C Hamano wrote:
> Existing scripts may prepare what to merge in an array (e.g. in Bourne,
> accumulating them in "$@" by repeatedly doing 'set "$@" "$newbranch"') and
> call 'git merge "$@"', relying on the current behaviour that zero argument
> means no-op. Such scripts will be broken by this change. Driving "git
> merge" with xargs without --no-run-if-empty (not POSIX), feeding the
> branches to merge in an Octopus, will be broken the same way.
I am not sure these things are not already broken. "git merge" without
arguments right now is not a no-op. It is an error that spews usage to
stderr and exits 129. Yes, there can be scripts which stupidly do not
bother to see if the merge succeeded, but I'm not sure how much we
should care about such poorly written junk.
> Migration plan:
>
> Add merge.defaultUpstream configuration variable, which defaults to false
> when unconfigured. Change "git merge" so that when this configuration is
> set and the command is run without the commit to merge to use the
> configured upstream of the current branch (or error out if there isn't
> one). Merge this change in the next 1.7.x series.
One nit: upon reading the name of the variable, I assumed it would be
"the default upstream to merge". Perhaps "merge.defaultToUpstream" is a
more descriptive name?
> One release before 1.8.0, issue a warning when "git merge" is run without
> the commit to merge and this configuration variable is not explicitly set
> either way, and notify the user of upcoming incompatibility.
Don't we already issue a giant warning when "git merge" is run without a
commit, namely:
usage: git merge [options] <remote>...
... etc ...
? If people are already not paying attention to that (either because
they are throwing away stderr and exit code indiscriminately, or because
the no-arguments case is a simply an obscure corner that their script
doesn't usually exercise), why would they pay attention to a new
warning?
> In 1.8.0, flip the default for merge.defaultUpstream to true.
Other than that, I think the proposal and migration plan are fine.
-Peff
next prev parent reply other threads:[~2011-01-31 20:14 UTC|newest]
Thread overview: 126+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-01-31 5:53 What's cooking in git.git (Jan 2011, #06; Sun, 30) Junio C Hamano
2011-01-31 15:08 ` Sverre Rabbelier
2011-02-08 17:48 ` Sverre Rabbelier
2011-02-08 19:27 ` Junio C Hamano
2011-01-31 17:05 ` Planning for 1.7.5 and 1.8.0 Junio C Hamano
2011-01-31 17:06 ` [1.8.0] default "git merge" without argument to "git merge @{u}" Junio C Hamano
2011-01-31 20:14 ` Jeff King [this message]
2011-01-31 20:17 ` Junio C Hamano
2011-01-31 20:32 ` Felipe Contreras
2011-01-31 20:50 ` [1.8.0] (v2) " Junio C Hamano
2011-01-31 22:55 ` Jeff King
2011-02-01 0:01 ` Thomas Adam
2011-02-01 18:34 ` Scott Chacon
2011-02-01 20:11 ` moving to a git-backed wiki Jeff King
2011-02-01 22:36 ` Jay Soffian
2011-02-01 22:48 ` J.H.
2011-02-02 9:55 ` Vincent Hanquez
2011-02-02 10:53 ` Felipe Contreras
2011-02-02 11:14 ` Jakub Narebski
2011-02-03 2:24 ` J.H.
2011-02-03 17:45 ` Jeff King
2011-02-03 19:06 ` Sverre Rabbelier
2011-02-04 6:03 ` Jeff King
2011-02-03 20:34 ` Felipe Contreras
2011-02-04 6:16 ` Jeff King
2011-02-04 17:50 ` Felipe Contreras
2011-02-04 14:34 ` Joey Hess
2011-02-05 7:00 ` david
2011-02-04 7:31 ` [1.8.0] (v2) default "git merge" without argument to "git merge @{u}" Thomas Hochstein
2011-02-04 23:01 ` [PATCH/RFC] Add support for merging from upstream by default Jared Hance
2011-01-31 17:07 ` [1.8.0] Unify "pathspec" semantics Junio C Hamano
2011-02-01 14:56 ` Nguyen Thai Ngoc Duy
2011-01-31 20:28 ` [1.8.0] reorganize the mess that the source tree has become Nicolas Pitre
2011-01-31 20:57 ` Junio C Hamano
2011-01-31 21:08 ` Matthieu Moy
2011-01-31 21:33 ` Nicolas Pitre
2011-01-31 21:19 ` Nicolas Pitre
2011-01-31 21:00 ` Jeff King
2011-01-31 21:28 ` Nicolas Pitre
2011-01-31 22:17 ` Junio C Hamano
2011-01-31 22:36 ` João P. Sampaio
2011-01-31 22:37 ` Nicolas Pitre
2011-01-31 23:12 ` Jeff King
2011-02-01 0:29 ` Nicolas Pitre
2011-02-01 1:48 ` Jeff King
2011-02-01 4:05 ` Nicolas Pitre
2011-02-01 12:42 ` Thomas Rast
2011-02-01 11:14 ` Jonathan Nieder
2011-02-01 11:22 ` Jonathan Nieder
2011-02-01 13:08 ` Nicolas Pitre
2011-02-01 16:02 ` Nguyen Thai Ngoc Duy
2011-02-01 21:53 ` Junio C Hamano
2011-02-01 0:35 ` Erik Faye-Lund
2011-02-01 1:53 ` Jeff King
2011-02-01 1:00 ` Sverre Rabbelier
2011-02-01 1:57 ` Jeff King
2011-02-01 7:24 ` Jay Soffian
2011-02-01 14:42 ` Andreas Ericsson
2011-01-31 21:59 ` [1.8.0] 't/' is standard name for directory with tests Jakub Narebski
2011-01-31 22:32 ` Nicolas Pitre
2011-02-01 0:12 ` Alex Budovski
2011-02-01 0:33 ` Nicolas Pitre
2011-02-01 0:58 ` Jakub Narebski
2011-02-01 1:15 ` Junio C Hamano
2011-02-02 23:55 ` Sam Vilain
2011-02-01 18:26 ` [1.8.0] split largest remaining scripts, gitk and gitweb Jakub Narebski
2011-02-01 22:15 ` Junio C Hamano
2011-02-01 23:20 ` Jakub Narebski
2011-02-05 3:21 ` [1.8.0] reorganize the mess that the source tree has become Martin von Zweigbergk
2011-01-31 21:44 ` [1.8.0] make two-argument fetch update remote branches Thomas Rast
2011-01-31 22:18 ` Matthieu Moy
2011-01-31 22:24 ` Junio C Hamano
2011-01-31 22:27 ` Eugene Sajine
2011-01-31 23:06 ` Junio C Hamano
2011-01-31 23:39 ` Eugene Sajine
2011-02-01 1:13 ` Junio C Hamano
2011-01-31 23:22 ` Jeff King
2011-02-01 7:04 ` Jay Soffian
2011-02-01 15:58 ` Nguyen Thai Ngoc Duy
2011-02-01 22:09 ` Junio C Hamano
2011-02-01 21:05 ` A Large Angry SCM
2011-02-01 22:39 ` Thomas Rast
2011-02-01 23:25 ` A Large Angry SCM
2011-01-31 21:55 ` [1.8.0] forbid full fetchspecs in git-pull Thomas Rast
2011-01-31 22:38 ` Junio C Hamano
2011-01-31 23:15 ` Dmitry Potapov
2011-02-01 15:14 ` Thomas Rast
2011-02-01 20:23 ` Dmitry Potapov
2011-02-01 3:20 ` Planning for 1.7.5 and 1.8.0 Nguyen Thai Ngoc Duy
2011-02-01 4:16 ` Nicolas Pitre
2011-02-01 14:54 ` [1.8.0] Tag namespaces Marc Branchaud
2011-02-01 15:21 ` Nguyen Thai Ngoc Duy
2011-02-01 18:37 ` [1.8.0] Remove deprecated commands René Scharfe
2011-02-01 22:16 ` Junio C Hamano
2011-02-02 0:57 ` Jonathan Nieder
2011-02-10 19:42 ` René Scharfe
2011-02-10 20:56 ` Jonathan Nieder
2011-02-10 21:08 ` Junio C Hamano
2011-02-12 13:24 ` René Scharfe
2011-02-12 21:04 ` Jonathan Nieder
2011-02-13 23:14 ` Junio C Hamano
2011-02-01 21:41 ` [1.8.0] Handle submodule config options consistently in diff plumbing Jens Lehmann
2011-02-02 11:56 ` [1.8.0] Tracking empty directories Jakub Narebski
2011-02-02 23:23 ` Jay Soffian
2011-02-02 23:33 ` David Aguilar
2011-02-02 23:52 ` Jakub Narebski
2011-02-03 2:21 ` Wesley J. Landaker
2011-02-03 5:53 ` Jonathan Nieder
2011-02-03 10:07 ` Matthieu Moy
2011-02-05 7:43 ` Pete Harlan
2011-02-05 18:31 ` Thomas Koch
2011-02-05 19:00 ` Sverre Rabbelier
2011-02-05 22:37 ` Jared Hance
2011-02-06 20:41 ` Junio C Hamano
2011-02-06 20:46 ` Sverre Rabbelier
2011-02-06 4:42 ` Nguyen Thai Ngoc Duy
2011-02-02 17:23 ` [1.8.0] git-stash invocation changes Thomas Rast
2011-02-02 17:35 ` Shawn Pearce
2011-02-02 18:15 ` Matthieu Moy
2011-02-02 18:51 ` Thomas Rast
2011-02-09 14:35 ` Pat Notz
2011-02-23 19:54 ` [1.8.0] Don't copy "submodule.<name>.update" to .git/config on submodule init Jens Lehmann
2011-02-23 20:28 ` Junio C Hamano
2011-02-23 22:43 ` Jens Lehmann
2011-02-24 0:34 ` Junio C Hamano
2011-02-24 23:44 ` Jens Lehmann
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=20110131201419.GA9070@sigill.intra.peff.net \
--to=peff@peff.net \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=miles@gnu.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 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 NNTP newsgroup(s).