Re: [PATCH 1.8.0] add: make "add -u" update full tree without pathspec

From: Jeff King <peff@peff.net>
To: Matthieu Moy <Matthieu.Moy@grenoble-inp.fr>
Cc: "Junio C Hamano" <gitster@pobox.com>,
	"Nguyen Thai Ngoc Duy" <pclouds@gmail.com>,
	git@vger.kernel.org, "Sebastian Pipping" <webmaster@hartwork.org>,
	"SZEDER Gábor" <szeder@ira.uka.de>
Subject: Re: [PATCH 1.8.0] add: make "add -u" update full tree without pathspec
Date: Tue, 1 Mar 2011 15:00:25 -0500	[thread overview]
Message-ID: <20110301200025.GF10082@sigill.intra.peff.net> (raw)
In-Reply-To: <vpq4o7mfzd1.fsf@bauges.imag.fr>

On Tue, Mar 01, 2011 at 07:51:38PM +0100, Matthieu Moy wrote:

> > Once your users (you as a script writer) have an option to set the
> > configuration to participate in the tree-wide party early, you would need
> > to update your scripts immediately so that they don't break on them;
> 
> But "update" should mean "replace git add -u with git add -u .", which
> is the portable way to do the same.
> 
> > so the introduction of the configuration becomes a flag-day event.
> > Hmph...
> 
> The introduction of the config variable is a non-event if you already
> use the portable . notation.

Right. Once this happens, you can never say "git add -u" again portably.
You can't rely on the old behavior, because it's changing. You can't
rely on the new behavior, because you might be using an old version. So
as a script you _must_ say "git add -u .", and if you want top-level
behavior and are not at the top-level, you must cd to the toplevel and
"add .". Which sounds onerous, but it is what scripts have to do
already with the current behavior.

> > Yeah, I think you convinced me that an elaborate configuration wouldn't
> > help us at all.  We just keep warning in 1.7.x series when "add -u" didn't
> > see any pathspec, and flip the default at 1.8.0
> >
> > Simpler and cleaner ;-)
> 
> I think is still makes sense to have a config variable, so that people
> who want the new behavior can get it ASAP. Right after 1.8 is out, I'll
> still have machines where I'm too lazy to install a brand new Git, and
> I'll want to get the 1.8 goodness for free ;-).

Agreed. I also think there should be a setting to keep the current
behavior. I don't want to use it, but given that configuration does not
introduce any existing portability issues, we can help people who really
liked the old behavior. We are inconveniencing them by changing the
default, but it seems doubly mean to leave them with no way of restoring
it short of typing extra characters on every invocation.

-Peff