Re: What's cooking in git.git (Apr 2013, #05; Mon, 15)

From: Jeff King <peff@peff.net>
Date: Apr 19, 2013, 04:14 UTC
Message-ID: <20130419041424.GA377@sigill.intra.peff.net>
In-Reply-To: <7vobdb4hii.fsf@alter.siamese.dyndns.org>

On Thu, Apr 18, 2013 at 03:10:29PM -0700, Junio C Hamano wrote:

Show 7 quoted lines

> Jeff King <peff@peff.net> writes:
> 
> > I am expecting a reaction more like "Hmm, I never thought about it
> > before. Does that make sense to me or not? Let me think about which
> > paths it pertains to and decide".
> 
> Let's step back and re-review the main text.

Good idea. I was very caught up in the existing message and what it made me expect, and not in what we are trying to accomplish overall.

Show 28 quoted lines

> It currently says:
> 
>     In Git 2.0, 'git add <pathspec>...' will also update the
>     index for paths removed from the working tree that match
>     the given pathspec. If you want to 'add' only changed
>     or newly created paths, say 'git add --no-all <pathspec>...'
>     instead.
> 
> This was written for the old "we may want to warn" logic that did
> not even check if we would be omitting a removal.  The new logic
> will show the text _only_ when the difference matters, we have an
> opportunity to tighten it a lot, for example:
> 
>     You ran 'git add' with neither '-A (--all)' or '--no-all', whose
>     behaviour will change in Git 2.0 with respect to paths you
>     removed from your working tree.
> 
>     * 'git add --no-all <pathspec>', which is the current default,
>       ignores paths you removed from your working tree.
> 
>     * 'git add --all <pathspec>' will let you also record the
>       removals.
> 
>     The removed paths (e.g. '%s') are ignored with this version of Git.
>     Run 'git status' to remind yourself what paths you have removed
>     from your working tree.
> 
> or something?

Yes, I like that much better. It reads more clearly than the original, and it is more obvious why we are mentioning the path at all.

And I think the hint of "git status" is good. I had considered before that the user would simply run "git status" after the message to get more data, but I didn't want to rely on them knowing to do that. Actually mentioning it is a good solution. :)

Thanks for pointing us in the right direction.

-Peff