git@vger.kernel.org mailing list mirror (one of many)
 help / color / mirror / code / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: Jeff King <peff@peff.net>
Cc: "Clemens Buchacher" <drizzd@aon.at>,
	"SZEDER Gábor" <szeder@ira.uka.de>,
	git@vger.kernel.org
Subject: Re: [BUG] 'add -u' doesn't work from untracked subdir
Date: Sat, 05 Sep 2009 01:23:50 -0700	[thread overview]
Message-ID: <7vy6ot4x61.fsf@alter.siamese.dyndns.org> (raw)
In-Reply-To: <20090905080249.GA8801@coredump.intra.peff.net> (Jeff King's message of "Sat\, 5 Sep 2009 04\:02\:49 -0400")

Jeff King <peff@peff.net> writes:

> I agree that we agreed to disagree. But there is still one open
> question: would you take a patch for a "full-tree" config variable that
> would impact add (and probably grep) for 1.7.0?

Unless there is a simple and sane way for script writers (and by "script",
I do not mean "Porcelain that is supposed to be written using only the
plumbing", but things like scripts you would give to "git bisect run",
which would freely use Porcelains like "git reset" etc.) to defeat the
configuration without much pain, I am fairly negative on adding any
configuration variable of that nature.

We could probably declare "In 1.X.0 everything will be relative to the
root and you have to give an explicit '.' if you mean the cwd".

Three questions:

 #1 What are the commands that will be affected, other than "add -u" and
    "grep"?  Are there others?

 #2 Do all the commands in the answer to #1 currently behave exactly the
    same when run without any path parameter and when run with a single
    '.'?

 #3 Do all the commands that are already relative to the root currently
    limit their action to the cwd when run with a single '.'?

If the number of commands in the answer to #1 is not too excessive, it is
a plus, but even if it is more than just several, we will be getting
consistency and sanity if #2 and #3 hold.  However, if there are even a
single violator in #2 and #3, we would need to fix them first before we
can proceed.  And the transition clock starts ticking after everything is
fixed (if such a fix is indeed needed).  As usual, I'd prefer to keep the
clock running for at least 6 months, preferrably longer, and during that
time, we may need the usual "You invoked me without any paths, but this
command will start behaving differently in 1.X.0, you have been warned."

A command line option to explicitly ask full-tree can be added anytime
without waiting for 1.7.0.  I do not think it will be ready for 1.6.5 but
we can always have 1.6.6 if needed.

  reply	other threads:[~2009-09-05  8:24 UTC|newest]

Thread overview: 35+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-09-02  8:03 [BUG] 'add -u' doesn't work from untracked subdir SZEDER Gábor
2009-09-02  8:19 ` Jeff King
2009-09-04  7:02   ` Clemens Buchacher
2009-09-05  6:18     ` Jeff King
2009-09-05  7:02       ` Junio C Hamano
2009-09-05  7:20         ` Jeff King
2009-09-05  7:58           ` Junio C Hamano
2009-09-05  8:02             ` Jeff King
2009-09-05  8:23               ` Junio C Hamano [this message]
2009-09-06 18:28                 ` Clemens Buchacher
2009-09-09 23:46                 ` Nanako Shiraishi
2009-09-10 19:53                   ` Junio C Hamano
2009-09-10 20:32                     ` Clemens Buchacher
2009-09-05 12:31             ` [PATCH 1/2] grep: accept relative paths outside current working directory Clemens Buchacher
2009-09-05 12:33               ` [PATCH 2/2] add 'scope' config option Clemens Buchacher
2009-09-05 13:10                 ` [PATCH 2/2 v2] " Clemens Buchacher
2009-09-06 22:58               ` [PATCH 1/2] grep: accept relative paths outside current working directory Junio C Hamano
2009-09-07  8:48                 ` [PATCH] grep: fix exit status if external_grep() returns error Clemens Buchacher
2009-09-07 18:13                   ` Junio C Hamano
2009-09-05  8:19           ` [BUG] 'add -u' doesn't work from untracked subdir Jeff King
2009-09-05  7:25         ` Junio C Hamano
2009-09-05  8:46         ` Clemens Buchacher
2009-09-05 17:28           ` Junio C Hamano
2009-09-05 17:58             ` Jakub Narebski
2009-09-05 18:45             ` Clemens Buchacher
2009-09-05 21:46               ` 'add -u' without path is relative to cwd Junio C Hamano
2009-09-06 12:32           ` [BUG] 'add -u' doesn't work from untracked subdir Matthieu Moy
2009-09-06 18:16             ` Clemens Buchacher
2009-09-07  6:23               ` Matthieu Moy
2009-09-07  7:33                 ` SZEDER Gábor
2009-09-07  8:06                   ` Matthieu Moy
2009-09-07  0:07           ` Nanako Shiraishi
2009-09-07  5:07             ` Junio C Hamano
2009-09-07  7:50             ` Clemens Buchacher
2009-09-04  8:32   ` SZEDER Gábor

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

  List information: http://vger.kernel.org/majordomo-info.html

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7vy6ot4x61.fsf@alter.siamese.dyndns.org \
    --to=gitster@pobox.com \
    --cc=drizzd@aon.at \
    --cc=git@vger.kernel.org \
    --cc=peff@peff.net \
    --cc=szeder@ira.uka.de \
    /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.
Code repositories for project(s) associated with this public inbox

	https://80x24.org/mirrors/git.git

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 read-only IMAP folder(s) and NNTP newsgroup(s).