All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Matthieu Moy <Matthieu.Moy@imag.fr>
Cc: git@vger.kernel.org, Jonathan Nieder <jrnieder@gmail.com>,
	Eric James Michael Ritz <lobbyjones@gmail.com>,
	Tomas Carnecky <tomas.carnecky@gmail.com>
Subject: Re: [RFC/PATCH] add: warn when -u or -A is used without filepattern
Date: Mon, 21 Jan 2013 11:12:44 -0800	[thread overview]
Message-ID: <7vwqv6fiz7.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1358769611-3625-1-git-send-email-Matthieu.Moy@imag.fr> (Matthieu Moy's message of "Mon, 21 Jan 2013 13:00:11 +0100")

Matthieu Moy <Matthieu.Moy@imag.fr> writes:

> Most git commands that can be used with our without a filepattern are
> tree-wide by default, the filepattern being used to restrict their scope.
> A few exceptions are: 'git grep', 'git clean', 'git add -u' and 'git add -A'.
>
> The inconsistancy of 'git add -u' and 'git add -A' are particularly
> problematic since other 'git add' subcommands (namely 'git add -p' and
> 'git add -e') are tree-wide by default.
>
> Flipping the default now is unacceptable, so this patch starts training
> users to type explicitely 'git add -u|-A :/' or 'git add -u|-A .', to prepare
> for the next steps:
>
> * forbid 'git add -u|-A' without filepattern (like 'git add' without
>   option)
>
> * much later, maybe, re-allow 'git add -u|-A' without filepattern, with a
>   tree-wide scope.
>
> A nice side effect of this patch is that it makes the :/ special
> filepattern easier to discover for users.

Nicely explained.

> The first step should look like this patch. The message remains vague
> about the next steps ("change in a future Git version", no mention of
> the exact change nor of the exact version in which it will happen),
> but I'm fine with refining it (perhaps this could be a 2.0 change,
> like the change to push.default?).

I think rolling big changes line these to a single version bump
would make sense, if we were to do it.

I have to wonder if "git add -p" and "git add -e" are the ones that
are broken, and the migration suggested here is going in the wrong
direction, though.  After all "add -p" and "add -e" are interactive
by their nature, so it is a _lot_ easier to change their default
behaviour in the name of "usability fix", "consistency fix", or
whatever.  Wouldn't we achieve the same consistency across modes of
"add" if we made them relative to the current directory?

  parent reply	other threads:[~2013-01-21 19:13 UTC|newest]

Thread overview: 53+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-19 21:35 [RFC] git rm -u Eric James Michael Ritz
2013-01-19 21:47 ` Tomas Carnecky
2013-01-19 21:49   ` Antoine Pelisse
2013-01-19 21:56     ` Eric James Michael Ritz
2013-02-25  6:54       ` Junio C Hamano
2013-02-25 18:54         ` Antoine Pelisse
2013-02-25 19:07           ` Matthieu Moy
2013-02-25 19:21             ` Antoine Pelisse
2013-02-25 19:39               ` Matthieu Moy
2013-02-25 19:47                 ` Junio C Hamano
2013-01-19 21:49 ` Jonathan Nieder
2013-01-19 22:01   ` Eric James Michael Ritz
2013-01-20 11:32   ` Matthieu Moy
2013-01-20 18:42     ` Junio C Hamano
2013-01-20 21:27       ` Junio C Hamano
2013-01-20 22:17         ` Martin von Zweigbergk
2013-01-21  8:44       ` Matthieu Moy
2013-01-20 18:53     ` Junio C Hamano
2013-01-20 19:21       ` Eric James Michael Ritz
2013-01-21  8:09       ` Piotr Krukowiecki
2013-01-21  8:37         ` Matthieu Moy
2013-01-21  9:23         ` Junio C Hamano
2013-01-21 19:01           ` Junio C Hamano
2013-01-21 20:03             ` Matthieu Moy
2013-01-21 23:18               ` Junio C Hamano
2013-01-21 19:10           ` Piotr Krukowiecki
2013-01-21 12:00       ` [RFC/PATCH] add: warn when -u or -A is used without filepattern Matthieu Moy
2013-01-21 15:00         ` Robin Rosenberg
2013-01-21 15:16           ` Matthieu Moy
2013-01-21 20:29             ` Robin Rosenberg
2013-01-21 19:12         ` Junio C Hamano [this message]
2013-01-21 19:34           ` Piotr Krukowiecki
2013-01-21 20:06             ` Matthieu Moy
2013-01-21 20:10           ` Matthieu Moy
2013-01-21 22:22         ` Jonathan Nieder
2013-01-22  7:39           ` Matthieu Moy
2013-01-25 10:49             ` [PATCH v2] " Matthieu Moy
2013-01-25 19:27               ` Junio C Hamano
2013-01-27 16:10                 ` Matthieu Moy
2013-01-27 20:33                   ` Junio C Hamano
2013-01-28  8:48                     ` Matthieu Moy
2013-01-28  9:16                       ` [PATCH v3] " Matthieu Moy
2013-01-28  9:20                         ` Jonathan Nieder
2013-01-28 12:47                         ` Michael J Gruber
2013-01-28 18:07                           ` Junio C Hamano
2013-01-28 18:25                             ` Matthieu Moy
2013-01-28 18:31                               ` Junio C Hamano
2013-02-14 23:36                             ` Junio C Hamano
2013-02-14 23:55                               ` Junio C Hamano
2013-02-15 10:00                                 ` Matthieu Moy
2013-01-27 12:22               ` [PATCH v2] " Jonathan Nieder
2013-01-22  1:10         ` [RFC/PATCH] " Duy Nguyen
2013-01-22  1:51           ` Junio C Hamano

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=7vwqv6fiz7.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@imag.fr \
    --cc=git@vger.kernel.org \
    --cc=jrnieder@gmail.com \
    --cc=lobbyjones@gmail.com \
    --cc=tomas.carnecky@gmail.com \
    /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.