All of lore.kernel.org
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Nguyễn Thái Ngọc Duy" <pclouds@gmail.com>
Cc: git@vger.kernel.org, "Sebastian Pipping" <webmaster@hartwork.org>,
	"SZEDER Gábor" <szeder@ira.uka.de>,
	"Matthieu Moy" <Matthieu.Moy@grenoble-inp.fr>,
	"Jeff King" <peff@peff.net>
Subject: Re: [PATCH 1.8.0] add: make "add -u" update full tree without pathspec
Date: Sun, 27 Feb 2011 02:46:45 -0800	[thread overview]
Message-ID: <7vei6t4uwa.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <1297045643-26697-1-git-send-email-pclouds@gmail.com> (=?utf-8?B?Ik5ndXnhu4VuIFRow6FpIE5n4buNYw==?= Duy"'s message of "Mon\,  7 Feb 2011 09\:27\:23 +0700")

Nguyễn Thái Ngọc Duy  <pclouds@gmail.com> writes:

> Migration plan:
>
> I'm bad at this. Can we start with a patch that warns users to do "git
> add -u ." when they do "git add -u"? Hopefully they would have their
> fingers retraied by the time the behavior is changed in 1.8.0.

Perhaps in this order:

Step 1, as soon as possible:

 * Introduce "static int make_update_global;" file scope static to
   builtin/add.c and default to 0;

 * Introduce "add.make_update_global" configuration variable, and toggle
   the above variable when it is explicitly given; also record the fact
   that you actually saw this variable in the config parser regardless of
   the value that is given;

 * Document the configuration variable as a new feature, without
   indicating that that will be the new default in the future, but
   strongly recommending that existing scripts should be updated and new
   scripts should be written the variable in mind---namely, their use of
   "add -u" should use "." if they are relying on the current "limit to
   cwd" behaviour.

 * Ship this as 1.7.X and see how well the new feature is accepted in the
   wider user community.  If the feature is not widely used, there is no
   point in proceeding further.

Step 2, two cycles (i.e. 6-8 months) before 1.8.0, provided if the
previous step is proven positive:

 * When "git add -u" is run without any pathspec, and when the user does
   not have the configuration variable, warn loudly that the default
   behaviour will change in 1.8.0, and tell the users that the current
   behaviour is still available by setting the configuration variable.

Step 3, at 1.8.0 and probably one or two more cycles:

 * When "git add -u" is run without any pathspec, and when the user does
   not have the configuration variable, warn loudly that the default
   behaviour _has_ changed in 1.8.0, to help people who migrated from
   early 1.7.X before Step 2 directly to 1.8.X series.

Step 4, 3 cycles after 1.8.0:

 * Drop the warning.

> PS. What about -A?

I personally think it should change exactly the same way as "-u" for
consistency, but I had the impression that the list concensus was to keep
the current behaviour.

Has anybody been keeping tallies on the discussion around

  http://thread.gmane.org/gmane.comp.version-control.git/166135/focus=166457

We seem to have lost track.  All I recall was that I changed my mind and
migrated from the third camp (the command defaults to whichever somebody
thought would be more convenient, lacking consistency across command set)
to "it would be more convenient to default to full-tree when there is no
pathspec, as limiting to cwd with '.' is easier" camp myself, but the
discussion is not about my personal preference but about seeing if we have
an overwhelming majority consensus, so...

  parent reply	other threads:[~2011-02-27 10:47 UTC|newest]

Thread overview: 25+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2011-02-07  2:27 [PATCH 1.8.0] add: make "add -u" update full tree without pathspec Nguyễn Thái Ngọc Duy
2011-02-07  5:58 ` Junio C Hamano
2011-02-07  6:14   ` Nguyen Thai Ngoc Duy
2011-02-07  6:26     ` Miles Bader
2011-02-09 10:58     ` Joshua Juran
2011-02-07 12:09   ` Matthieu Moy
2011-02-27 10:46 ` Junio C Hamano [this message]
2011-02-27 11:43   ` Matthieu Moy
2011-02-27 17:04     ` Nguyen Thai Ngoc Duy
2011-02-27 13:35   ` Sverre Rabbelier
2011-02-27 17:01     ` Nguyen Thai Ngoc Duy
2011-02-27 16:52   ` Nguyen Thai Ngoc Duy
2011-02-27 19:39     ` Junio C Hamano
2011-02-28  6:37       ` Nguyen Thai Ngoc Duy
2011-02-28  6:56         ` Junio C Hamano
2011-03-01 11:22           ` Nguyen Thai Ngoc Duy
2011-03-01 13:46             ` Junio C Hamano
2011-03-01 14:15               ` Nguyen Thai Ngoc Duy
2011-03-01 14:53           ` Matthieu Moy
2011-03-01 18:40             ` Junio C Hamano
2011-03-01 18:51               ` Matthieu Moy
2011-03-01 19:36                 ` Jakub Narebski
2011-03-01 20:00                 ` Jeff King
2011-03-01 20:12                 ` Junio C Hamano
2011-03-01 20:25                   ` Matthieu Moy

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=7vei6t4uwa.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=Matthieu.Moy@grenoble-inp.fr \
    --cc=git@vger.kernel.org \
    --cc=pclouds@gmail.com \
    --cc=peff@peff.net \
    --cc=szeder@ira.uka.de \
    --cc=webmaster@hartwork.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 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.