"git add -u" broken in git 1.7.4?

"git add -u" broken in git 1.7.4?

[Sebastian Pipping]

Hello!


I just ran into case where

  git add -u

repetedly did not update the index.  In contrast, picking stuff using

  git add -p

works just fine.

Could it be "git add -u" is broken in git 1.7.4?

Best,



Sebastian

Re: "git add -u" broken in git 1.7.4?

[Jeff King]

On Sun, Feb 06, 2011 at 01:39:32AM +0100, Sebastian Pipping wrote:

> I just ran into case where
> 
>   git add -u
> 
> repetedly did not update the index.  In contrast, picking stuff using
> 
>   git add -p
> 
> works just fine.
> 
> Could it be "git add -u" is broken in git 1.7.4?

It could be. However, I can think of one such case where you might see
that behavior. "git add -u" operates from the current subdirectory,
whereas "git add -p" operates from the top of the project tree (yes,
this inconsistency confusing, but it's not as serious as "git add -u
doesn't work").

You can demonstrate it with:

  mkdir repo && cd repo && git init
  mkdir subdir && echo content >file
  git add . && git commit -m base
  echo more >>file

  mkdir subdir && cd subdir
  git add -u
  git status ;# still not staged for commit

  git add -p ;# finds it

Might you have been in a subdirectory of the project when you saw this
behavior?

-Peff

Re: "git add -u" broken in git 1.7.4?

[Sebastian Pipping]

On 02/06/11 06:13, Jeff King wrote:
> On Sun, Feb 06, 2011 at 01:39:32AM +0100, Sebastian Pipping wrote:
> 
>> I just ran into case where
>>
>>   git add -u
>>
>> repetedly did not update the index.  In contrast, picking stuff using
>>
>>   git add -p
>>
>> works just fine.
>>
>> Could it be "git add -u" is broken in git 1.7.4?
> 
> It could be. However, I can think of one such case where you might see
> that behavior. "git add -u" operates from the current subdirectory,
> whereas "git add -p" operates from the top of the project tree (yes,
> this inconsistency confusing, but it's not as serious as "git add -u
> doesn't work").
> 
> You can demonstrate it with:
> 
>   mkdir repo && cd repo && git init
>   mkdir subdir && echo content >file
>   git add . && git commit -m base
>   echo more >>file
> 
>   mkdir subdir && cd subdir
>   git add -u
>   git status ;# still not staged for commit
> 
>   git add -p ;# finds it
> 
> Might you have been in a subdirectory of the project when you saw this
> behavior?

I was and I can confirm the different behaviour with 1.7.4 over here: it
does work on the root directory of the repo as you supposed.

Is that behavior needed to be as is or could you change it to work from
everywhere?  Could it be it has been working from anywhere before?

Best,



Sebastian

Re: "git add -u" broken in git 1.7.4?

[Matthieu Moy]

Sebastian Pipping <webmaster@hartwork.org> writes:

> I was and I can confirm the different behaviour with 1.7.4 over here: it
> does work on the root directory of the repo as you supposed.

What do you mean by "it does not work"?

"git add -u" adds files under the current directory, and it always
did.

> Is that behavior needed to be as is or could you change it to work from
> everywhere?

I consider it as a design bug that "add -u" is not tree-wide, but it's
not easy to change the existing behavior without breaking expectations
of people used to the current behavior.

> Could it be it has been working from anywhere before?

Can you post an example where Git 1.7.4 and a previous version behave
differently? Up to now, I see difference between your expectations and
what Git does, but not between new and old versions.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: "git add -u" broken in git 1.7.4?

[SZEDER Gábor]

On Sun, Feb 06, 2011 at 09:48:48PM +0100, Matthieu Moy wrote:
> Sebastian Pipping <webmaster@hartwork.org> writes:
> > Is that behavior needed to be as is or could you change it to work from
> > everywhere?
> 
> I consider it as a design bug that "add -u" is not tree-wide, but it's
> not easy to change the existing behavior without breaking expectations
> of people used to the current behavior.

And others are bitten by it every once in a while.  Yes, myself
included ;)  Maybe this is also one of those things that might be
reconsidered for 1.8.0?

> > Could it be it has been working from anywhere before?
> 
> Can you post an example where Git 1.7.4 and a previous version behave
> differently? Up to now, I see difference between your expectations and
> what Git does, but not between new and old versions.

git add -u was tree-wide when it was introduced in dfdac5d (git-add
-u: match the index with working tree., 2007-04-20), but 2ed2c22
(git-add -u paths... now works from subdirectory, 2007-08-16) broke it
while fixing something related.


Best,
Gábor

Re: "git add -u" broken in git 1.7.4?

[Sebastian Pipping]

On 02/07/11 00:19, SZEDER Gábor wrote:
> And others are bitten by it every once in a while.  Yes, myself
> included ;)  Maybe this is also one of those things that might be
> reconsidered for 1.8.0?
> 
>>> Could it be it has been working from anywhere before?
>>
>> Can you post an example where Git 1.7.4 and a previous version behave
>> differently? Up to now, I see difference between your expectations and
>> what Git does, but not between new and old versions.
> 
> git add -u was tree-wide when it was introduced in dfdac5d (git-add
> -u: match the index with working tree., 2007-04-20), but 2ed2c22
> (git-add -u paths... now works from subdirectory, 2007-08-16) broke it
> while fixing something related.

So my memory didn't fool me.  Thanks for digging this out.

Can we have tree-wide "git add -u" back, please?

Thanks,



Sebastian

Re: "git add -u" broken in git 1.7.4?

[Junio C Hamano]

Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:

> Sebastian Pipping <webmaster@hartwork.org> writes:
>
>> I was and I can confirm the different behaviour with 1.7.4 over here: it
>> does work on the root directory of the repo as you supposed.
>
> What do you mean by "it does not work"?
>
> "git add -u" adds files under the current directory, and it always
> did.

As it takes pathspecs (think "git add -u this-file"), it fundamentally
shouldn't be tree-wide.  I think the original implementation didn't take
pathspecs and was mistakenly done as tree-wide operation, but I think it
was fixed rather quickly.

Re: "git add -u" broken in git 1.7.4?

[Jeff King]

On Sun, Feb 06, 2011 at 09:50:37PM -0800, Junio C Hamano wrote:

> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> 
> > Sebastian Pipping <webmaster@hartwork.org> writes:
> >
> >> I was and I can confirm the different behaviour with 1.7.4 over here: it
> >> does work on the root directory of the repo as you supposed.
> >
> > What do you mean by "it does not work"?
> >
> > "git add -u" adds files under the current directory, and it always
> > did.
> 
> As it takes pathspecs (think "git add -u this-file"), it fundamentally
> shouldn't be tree-wide.  I think the original implementation didn't take
> pathspecs and was mistakenly done as tree-wide operation, but I think it
> was fixed rather quickly.

Is "git add -p" broken, then? It takes pathspecs relative to the current
directory, but "git add -p" without arguments operates from the root,
not from the current subdirectory.

-Peff

Re: "git add -u" broken in git 1.7.4?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> Is "git add -p" broken, then? It takes pathspecs relative to the current
> directory, but "git add -p" without arguments operates from the root,
> not from the current subdirectory.

I would say so; "add -p" was an ill-executed afterthought.  The codepath
was originally meant to be used from "-i" as the top-level interface that
was a fully interactive way to prepare for the next commit, which is an
operation that is inherently full-tree.

There are two schools of thought in previous threads discussing full-tree
vs current-directory-relative.  I think each side has merits.

If we defaulted to the current directory (i.e. "git grep"), that would
feel more natural as it is more consistent with how tools that are not git
aware (e.g. "GNU grep" run in the same directory) behave.  A downside is
when you are somewhere deep in a working tree, you have to know how deep
you are and repeat "../" that many times, i.e. "git grep pattern ../../"

If we defaulted to the root-level (i.e. "git diff"), you do not have that
downside (iow, "git diff" run from a deep directory is a full tree
operation), and you can limit the scope to the current directory by a
single dot, i.e. "git diff .".  A huge downside is that this may feel
awkward for new people who do not yet breath git [*1*], as no other git
aware tool would behave like this, limiting its scope to some directory
that is higher above.

In the past, I have took the third position, saying that tools that
semantically needs to be full-tree should be full-tree (i.e. ones that
make or format commits), and others should be relative to the current
directory (i.e. ones that are used to inspect your progress, such as
grep), but that is not a very understandable guideline that people can
easily follow.  If we have to choose between the two and make things
consistent, my personal preference is to make everything relative to the
current working directory.

I actually do not mind too much myself if all commands that can take
pathspecs consistently defaulted to "full-tree" pathspec given no
pathspec.  But if we were to go that route, everybody should join their
voice to defend that decision when outside people say "in 1.8.0 'git grep'
run from a subdirectory shows matches from all the irrelevant parts of the
tree; with all the cruft its output is unreadable". I won't be the sole
champion of such a behaviour when I do not fully believe in it.


[Footnote]

*1* In the case of "git diff", this is largely mitigated as its output is
always relative to the root of the working tree, but other tools may not
have that luxury.

Re: "git add -u" broken in git 1.7.4?

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

> On Sun, Feb 06, 2011 at 09:50:37PM -0800, Junio C Hamano wrote:
>
>> As it takes pathspecs (think "git add -u this-file"), it fundamentally
>> shouldn't be tree-wide.  I think the original implementation didn't take
>> pathspecs and was mistakenly done as tree-wide operation, but I think it
>> was fixed rather quickly.
>
> Is "git add -p" broken, then? It takes pathspecs relative to the current
> directory, but "git add -p" without arguments operates from the root,
> not from the current subdirectory.

It's not just "git add -p". Take "git log", "git status", "git
commit", "git diff" ... well, most Git commands taking pathspecs
optionally:

git foo   => tree-wide
git foo . => the . acts as a path limiter

and this is the right thing to do. Making "git foo" equivalent to "git
foo ." makes it hard to recover the tree-wide behavior from a
subdirectory (git foo ../../../).

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: "git add -u" broken in git 1.7.4?

[Nguyen Thai Ngoc Duy]

On Mon, Feb 7, 2011 at 1:46 PM, Junio C Hamano <gitster@pobox.com> wrote:
> I actually do not mind too much myself if all commands that can take
> pathspecs consistently defaulted to "full-tree" pathspec given no
> pathspec.  But if we were to go that route, everybody should join their
> voice to defend that decision when outside people say "in 1.8.0 'git grep'
> run from a subdirectory shows matches from all the irrelevant parts of the
> tree; with all the cruft its output is unreadable". I won't be the sole
> champion of such a behaviour when I do not fully believe in it.

That could be one more item for the next git survey (i.e. how do you
want the defaults to be?). Most of people in this list more or less
breath git already and therefore are bias (I think).

Personally "git add -u --full-tree" is good enough to me. It does have
the same problem that git --full-tree has: what *.h in "git grep
--full-tree -- '*.h'" means. But I'm OK with not supporting that case
until we agree on something.
-- 
Duy

Re: "git add -u" broken in git 1.7.4?

[Michael J Gruber]

Matthieu Moy venit, vidit, dixit 07.02.2011 07:48:
> Jeff King <peff@peff.net> writes:
> 
>> On Sun, Feb 06, 2011 at 09:50:37PM -0800, Junio C Hamano wrote:
>>
>>> As it takes pathspecs (think "git add -u this-file"), it fundamentally
>>> shouldn't be tree-wide.  I think the original implementation didn't take
>>> pathspecs and was mistakenly done as tree-wide operation, but I think it
>>> was fixed rather quickly.
>>
>> Is "git add -p" broken, then? It takes pathspecs relative to the current
>> directory, but "git add -p" without arguments operates from the root,
>> not from the current subdirectory.
> 
> It's not just "git add -p". Take "git log", "git status", "git
> commit", "git diff" ... well, most Git commands taking pathspecs
> optionally:
> 
> git foo   => tree-wide
> git foo . => the . acts as a path limiter
> 
> and this is the right thing to do. Making "git foo" equivalent to "git
> foo ." makes it hard to recover the tree-wide behavior from a
> subdirectory (git foo ../../../).
> 

First of all, I'd vote for having this work the same way across all
commands - as Junio explained, the destinction we currently have is not
easy to grasp, and is violated by add -p.

Second, we have an established, natural syntax for "base on cwd", namely
".", but we do not have any for "base on worktree root". (I think we
discussed and discarded "/" at some point.)

So, if we go for "relative to cwd by default" we would need a simple way
to specify the root - and by simple I mean taking at most 2 chars in the
pathspec, not a long option!

In summary, I think going for "relative to worktree root by default" is
more in line with git's overall philosophy (so it teaches the right
concept), something the user is exposed to already in most places (but
not all), and limiting to "." already works in most (all?) places, even
with "status" and "status -s". We would only need to change the few
places where we still default to cwd, and make sure they accept "." when
we change their default to repo root.

Cheers,
Michael

Re: "git add -u" broken in git 1.7.4?

[SZEDER Gábor]

Hi,


On Sun, Feb 06, 2011 at 09:50:37PM -0800, Junio C Hamano wrote:
> Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> 
> > Sebastian Pipping <webmaster@hartwork.org> writes:
> >
> >> I was and I can confirm the different behaviour with 1.7.4 over here: it
> >> does work on the root directory of the repo as you supposed.
> >
> > What do you mean by "it does not work"?
> >
> > "git add -u" adds files under the current directory, and it always
> > did.
> 
> As it takes pathspecs (think "git add -u this-file"), it fundamentally
> shouldn't be tree-wide.  I think the original implementation didn't take
> pathspecs and was mistakenly done as tree-wide operation, but I think it
> was fixed rather quickly.

Interesting, when I brought up this issue about one and a half years
ago, you of all people proposed that this change might be worth
addressing in 1.8.0.

  Message-ID: <7veiql1etz.fsf@alter.siamese.dyndns.org>
  http://thread.gmane.org/gmane.comp.version-control.git/127593/focus=127594

There was a longish discussion back then with arguments both for and
against tree-wide operation.


Best,
Gábor

Re: "git add -u" broken in git 1.7.4?

[SZEDER Gábor]

On Sun, Feb 06, 2011 at 10:46:20PM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
> 
> > Is "git add -p" broken, then? It takes pathspecs relative to the current
> > directory, but "git add -p" without arguments operates from the root,
> > not from the current subdirectory.
> 
> I would say so; "add -p" was an ill-executed afterthought.  The codepath
> was originally meant to be used from "-i" as the top-level interface that
> was a fully interactive way to prepare for the next commit, which is an
> operation that is inherently full-tree.
> 
> There are two schools of thought in previous threads discussing full-tree
> vs current-directory-relative.  I think each side has merits.
> 
> If we defaulted to the current directory (i.e. "git grep"), that would
> feel more natural as it is more consistent with how tools that are not git
> aware (e.g. "GNU grep" run in the same directory) behave.  A downside is
> when you are somewhere deep in a working tree, you have to know how deep
> you are and repeat "../" that many times, i.e. "git grep pattern ../../"
> 
> If we defaulted to the root-level (i.e. "git diff"), you do not have that
> downside (iow, "git diff" run from a deep directory is a full tree
> operation), and you can limit the scope to the current directory by a
> single dot, i.e. "git diff .".  A huge downside is that this may feel
> awkward for new people who do not yet breath git [*1*], as no other git
> aware tool would behave like this, limiting its scope to some directory
> that is higher above.
> 
> In the past, I have took the third position, saying that tools that
> semantically needs to be full-tree should be full-tree (i.e. ones that
> make or format commits), and others should be relative to the current
> directory (i.e. ones that are used to inspect your progress, such as
> grep), but that is not a very understandable guideline that people can
> easily follow.  If we have to choose between the two and make things
> consistent, my personal preference is to make everything relative to the
> current working directory.

_Everything_ relative to the current working directory?  I can't
imagine how would that work in practice.  Could you explain what would
the following commands do, for example, when they are relative to the
current working directory?

  $ cd t
  $ git checkout next
  $ git merge somebranch
  $ git reset HEAD^


Best,
Gábor

Re: "git add -u" broken in git 1.7.4?

[Junio C Hamano]

SZEDER Gábor <szeder@ira.uka.de> writes:

> _Everything_ relative to the current working directory?  I can't
> imagine how would that work in practice.  Could you explain what would
> the following commands do, for example, when they are relative to the
> current working directory?
>
>   $ cd t
>   $ git checkout next
>   $ git merge somebranch
>   $ git reset HEAD^

Perhaps I stated things badly.  I was only talking about commands that
take pathspecs, and none of the above are relevant to this thread.  You
don't check out a branch with pathspec, nor merge another branch, nor
reset the index and the HEAD pointer.

I wouldn't point out that "git checkout next -- this-file" is to check out
a file out of a commit, not to check out a branch, as I think you already
know that.

Re: "git add -u" broken in git 1.7.4?

[Jeff King]

On Sun, Feb 06, 2011 at 10:46:20PM -0800, Junio C Hamano wrote:

> I actually do not mind too much myself if all commands that can take
> pathspecs consistently defaulted to "full-tree" pathspec given no
> pathspec.  But if we were to go that route, everybody should join their
> voice to defend that decision when outside people say "in 1.8.0 'git grep'
> run from a subdirectory shows matches from all the irrelevant parts of the
> tree; with all the cruft its output is unreadable". I won't be the sole
> champion of such a behaviour when I do not fully believe in it.

The problem is that I don't feel comfortable writing an RFC that says
"in 1.8.0 we will default to full-tree because it is somehow better".
Because I don't think it is better; it is simply a different way of
thinking about it, and different people will have different preferences.

I think even the same people may different preferences from project to
project. For most of my projects, the scope of the repo is well-defined,
and I want full-tree semantics (e.g., I hack on a bug, go into t/ to
tweak and run the tests, and then want to "git add -u" the whole thing
when everything looks good). But I also recently worked on a gigantic
project that was split into several sub-components. I would cd 3 or 4
levels deep into the sub-component that I was working on, and I would
prefer my "git add -u" to stay in that sub-component, and my "git grep"
to look only in that sub-component.

Which implies to me that the "relative" or "full-tree" view should be a
per-repo configurable thing. But that introduces its own set of
headaches, as people may script around things like "git add", and it
would become predictable to do so only from the top-level of the working
tree.

-Peff

Re: "git add -u" broken in git 1.7.4?

[Matthieu Moy]

Junio C Hamano <gitster@pobox.com> writes:

> I would say so; "add -p" was an ill-executed afterthought.  The codepath
> was originally meant to be used from "-i" as the top-level interface that
> was a fully interactive way to prepare for the next commit, which is an
> operation that is inherently full-tree.

I agree that "git add -i" is a way to prepare the next commit, but you
seem to imply that "git add -u" is not and then I have to disagree.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

Re: "git add -u" broken in git 1.7.4?

[Jeff King]

On Mon, Feb 07, 2011 at 09:57:43PM +0100, Matthieu Moy wrote:

> Junio C Hamano <gitster@pobox.com> writes:
> 
> > I would say so; "add -p" was an ill-executed afterthought.  The codepath
> > was originally meant to be used from "-i" as the top-level interface that
> > was a fully interactive way to prepare for the next commit, which is an
> > operation that is inherently full-tree.
> 
> I agree that "git add -i" is a way to prepare the next commit, but you
> seem to imply that "git add -u" is not and then I have to disagree.

How about "git commit -a"? Shouldn't that be more or less equivalent to
"git add -u && git commit"? But it is full-tree.

So I think there is less "we do it one way, and this is the outlier" and
more "we are horribly inconsistent".

-Peff

Re: "git add -u" broken in git 1.7.4?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> So I think there is less "we do it one way, and this is the outlier" and
> more "we are horribly inconsistent".

Yeah, didn't I say I used to be the third camp which I find is hard to
jusitify, and am open to consistency either way?

Re: Re: "git add -u" broken in git 1.7.4?

[Eric Raible]

On 11:59 AM, Junio C Hamano wrote:

> I actually do not mind too much myself if all commands that can take
> pathspecs consistently defaulted to "full-tree" pathspec given no
> pathspec.  But if we were to go that route, everybody should join their
> voice to defend that decision when outside people say "in 1.8.0 'git grep'
> run from a subdirectory shows matches from all the irrelevant parts of the
> tree; with all the cruft its output is unreadable". I won't be the sole
> champion of such a behaviour when I do not fully believe in it.

IFUC this shouldn't affect any (correctly written) scripts,
and so the only downside is that (when run in a subdir) commands
that are currently spelled:

	git xxx

would with this change need to be spelled:

	git xxx .

One advantage of this approach is that one's fingers would
learn the "only this dir" two char sequence very quickly.

So FWIW, I will do my best to help defend such a decision.

Re: "git add -u" broken in git 1.7.4?

[Junio C Hamano]

Eric Raible <raible@nextest.com> writes:

> IFUC this shouldn't affect any (correctly written) scripts,
> and so the only downside is that (when run in a subdir) commands
> that are currently spelled:
>
> 	git xxx
>
> would with this change need to be spelled:
>
> 	git xxx .

If xxx is grep (or "add -u") and the script is running the former form,
you already broke it, and I think a script that expects "git grep" to
limit its scope to the current directory is "correctly written".  That is
how these commands were defined and documented to work.

"Adding SP plus dot is just a two-byte change" is not a sensible reason to
break people's scripts.  We need to be honest and say "sorry, but with
this release we are breaking your scripts.  Let us convince you that the
benefit of the resulting consistency outweighs that cost".

Re: "git add -u" broken in git 1.7.4?

[SZEDER Gábor]

On Mon, Feb 07, 2011 at 02:50:35PM -0500, Jeff King wrote:
> On Sun, Feb 06, 2011 at 10:46:20PM -0800, Junio C Hamano wrote:
> 
> > I actually do not mind too much myself if all commands that can take
> > pathspecs consistently defaulted to "full-tree" pathspec given no
> > pathspec.  But if we were to go that route, everybody should join their
> > voice to defend that decision when outside people say "in 1.8.0 'git grep'
> > run from a subdirectory shows matches from all the irrelevant parts of the
> > tree; with all the cruft its output is unreadable". I won't be the sole
> > champion of such a behaviour when I do not fully believe in it.
> 
> The problem is that I don't feel comfortable writing an RFC that says
> "in 1.8.0 we will default to full-tree because it is somehow better".
> Because I don't think it is better; it is simply a different way of
> thinking about it, and different people will have different preferences.
> 
> I think even the same people may different preferences from project to
> project. For most of my projects, the scope of the repo is well-defined,
> and I want full-tree semantics (e.g., I hack on a bug, go into t/ to
> tweak and run the tests, and then want to "git add -u" the whole thing
> when everything looks good). But I also recently worked on a gigantic
> project that was split into several sub-components. I would cd 3 or 4
> levels deep into the sub-component that I was working on, and I would
> prefer my "git add -u" to stay in that sub-component, and my "git grep"
> to look only in that sub-component.

It sounds like your work focused solely on the sub-component you cd-d
into.  Did you have any other changes outside of that sub-component?
Because when not, then both the current and the whole-tree "git add -u"
would have the same effect.

The current and the whole-tree "git grep" would behave differently, of
course.  But even then a whole-tree "git grep" would be harmless and
easy to limit in scope, though might be a bit annoying in the "cd deep
down" case.  In that case you would immediately see the matches
outside of cwd, know that you forgot to limit the operation to cwd, so
you hit the up key, simply append the "." to the last command, and you
get what you wanted.

As mentioned in this or other related threads, this is not at all that
simple the other way around, i.e. with current "git grep" when you are
in the sub-component and you happen to need a grep on the whole tree,
because you have to pay attention to use the right number of "../"s.

A whole-tree "git add -u" is just as easy to limit in scope as the
whole-tree "git grep" would be, but certainly more annoying when you
forget to limit it to cwd.  But even in that case there is no harm
done, because all the changes you've made are there, but you have to
unstage changes from the index or split the commit.

Current "git add -u" is worst of all, because it's not just difficult
to circumvent (how many "../" do I need?), but it's downright
dangerous, because you can lose changes when forget that it's limited
in scope.  I managed to do something like this while fixing two
already bisected bugs:

  git checkout deadbeef         # BugA was introduced in that commit
  vim git.c                     # fix BugA
  cd t
  test ; vim test ; test
  git add -u                    # again forgetting that a
                                # fundamentally whole-tree oriented 
                                # tool has operations with
                                # non-whole-tree defaults...
  git commit -m 'Fix BugA'      # will write proper commit msg later
  git branch fix_BugA           # to find the commit later
  git reset --hard babefeed     # instead of "git checkout babefeed"
                                # BugB was introduced there
                                # goodbye bugfix!
  # hack away to fix BugB       # until realisation sets in
  # Damn.

You could argue that there are several ways I could have prevented
shooting myself in the foot, e.g. using "git checkout" instead of "git
reset --hard", or by using plain "git commit" without the "-m" option
I might have noticed the unstaged changes in the commit template.  I
would even tend to agree, but I still think that git should be
consistent with _itself_ in the first place, and since git's
fundamental concepts are whole-tree oriented and there are many
commands that only make sense on the whole tree, defaulting to
whole-tree operations for commands taking a pathspec is indeed better.
And safer too.


Best,
Gábor

Re: "git add -u" broken in git 1.7.4?

[Jeff King]

On Tue, Feb 08, 2011 at 11:05:18AM +0100, SZEDER Gábor wrote:

> > I think even the same people may different preferences from project to
> > project. For most of my projects, the scope of the repo is well-defined,
> > and I want full-tree semantics (e.g., I hack on a bug, go into t/ to
> > tweak and run the tests, and then want to "git add -u" the whole thing
> > when everything looks good). But I also recently worked on a gigantic
> > project that was split into several sub-components. I would cd 3 or 4
> > levels deep into the sub-component that I was working on, and I would
> > prefer my "git add -u" to stay in that sub-component, and my "git grep"
> > to look only in that sub-component.
> 
> It sounds like your work focused solely on the sub-component you cd-d
> into.  Did you have any other changes outside of that sub-component?
> Because when not, then both the current and the whole-tree "git add -u"
> would have the same effect.

Yes, I often did have other changes. They were usually one of two types.
The build infrastructure was in a separate directory, so one type would
be local tweaks to the build that should not end up getting committed.
The other type was required changes to another component that would get
committed separately (e.g., while working on component "foo" you realize
that it depends on a new feature in component "bar"; you leave "foo"
modified in the working tree, work on "bar", commit it, then come back
to "foo").

> The current and the whole-tree "git grep" would behave differently, of
> course.  But even then a whole-tree "git grep" would be harmless and
> easy to limit in scope, though might be a bit annoying in the "cd deep
> down" case.  In that case you would immediately see the matches
> outside of cwd, know that you forgot to limit the operation to cwd, so
> you hit the up key, simply append the "." to the last command, and you
> get what you wanted.

Yeah, grep is not as annoying because it does not have the "oops, I just
pushed this commit and it turns out that I screwed up "git add" five
minutes ago and it only had half of the files I intended" problem.

> As mentioned in this or other related threads, this is not at all that
> simple the other way around, i.e. with current "git grep" when you are
> in the sub-component and you happen to need a grep on the whole tree,
> because you have to pay attention to use the right number of "../"s.

Yes, it is annoying, but that is merely a syntactic issue. If we aliased
"/" to "the root of the project", then most arguments for full-tree
could be reversed for the relative case (e.g., "sure, but it's easy
enough to type 'git add /'").

For the record, I would much prefer full-tree behavior as the default,
and I think the '/' syntax is ugly and confusing. If you were asking at
the beginning of "git add -u" what the behavior should be, I would
absolutely say full-tree. But we're not there; we're talking about
changing existing behavior. And I'm not sure there is a clear-cut,
obvious-to-anybody-who-will-annoyed-with-the-change argument that
full-tree behavior is definitively better.

The most compelling I have seen is "you tend to notice accidental
full-tree sooner than accidental relative behavior". Which you mentioned
in your email. I just don't know if that passes the "will satisfy
annoyed users" test.

I dunno. I would not be sad at all if we moved to full-tree defaults
everywhere. I just don't want to have to be the one that annoyed users
yell at. :)

-Peff

Re: "git add -u" broken in git 1.7.4?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> The most compelling I have seen is "you tend to notice accidental
> full-tree sooner than accidental relative behavior". Which you mentioned
> in your email.

Hmph.  You earlier mentioned "oops, I just pushed this commit and it turns
out that I screwed up "git add" five minutes ago and it only had half of
the files I intended" problem, but "oops, I just pushed this commit and it
turns out that I screwed up "git add" five minutes ago and it had more
changes than I intended" problem would be equally annoying, and I don't
think one is inherently more likely to be noticed than the other; IOW, it
is not compelling, but is just an arbitrary and a biased observation, no?

The most compelling, especially if we _were_ designing from scratch to
make things consistent across the command set, would be "limiting to cwd
with single dot is a lot easier to type than counting ../, using / to mean
the root of the working tree is confusing, and saying --full-tree is
annoying".  I fully agree with that.

Can somebody volunteer to come up with a comprehensive list of operations
that will change their behaviour when we switch to "full-tree without
pathspec" semantics?  We mentioned "grep" and "add -u" already.

Re: "git add -u" broken in git 1.7.4?

[Jeff King]

On Wed, Feb 09, 2011 at 02:40:47PM -0800, Junio C Hamano wrote:

> > The most compelling I have seen is "you tend to notice accidental
> > full-tree sooner than accidental relative behavior". Which you mentioned
> > in your email.
> 
> Hmph.  You earlier mentioned "oops, I just pushed this commit and it turns
> out that I screwed up "git add" five minutes ago and it only had half of
> the files I intended" problem, but "oops, I just pushed this commit and it
> turns out that I screwed up "git add" five minutes ago and it had more
> changes than I intended" problem would be equally annoying, and I don't
> think one is inherently more likely to be noticed than the other; IOW, it
> is not compelling, but is just an arbitrary and a biased observation, no?

Yeah, thinking on it more, it is not so much that you notice sooner[1],
as the behavior may be less destructive when you do notice. That is,
accidentally adding too much has put things into the object db.
Accidentally not adding enough means your changes are susceptible to
"git reset --hard" or other destructive actions.

[1] I seem to remember this argument about noticing sooner coming up in
previous discussions, and so I was taking it for granted. But thinking
on it, I can't really come up with a solid reason why one might notice
errors sooner in full tree rather than relative behavior.

> Can somebody volunteer to come up with a comprehensive list of operations
> that will change their behaviour when we switch to "full-tree without
> pathspec" semantics?  We mentioned "grep" and "add -u" already.

I went through the whole list of "git help -a" and considered each
command. Quite a few don't take pathspecs, or would be very odd to be
not full-tree (e.g., read-tree reads the whole tree, not just some
subset based on where you are in the project. Anything else would be
kind of insane). I omitted those. If you don't see something in this
list, it's either because I thought it was irrelevant, or I just missed
it going through the list; feel free to mention more.

I think everything which takes a pathspec takes it relative to the
current directory. So we are really just considering the behavior when
_no_ pathspecs are provided.

The current behavior is:

  add:    error (and suggest "git add .")
  add -u: relative
  add -A: relative
  add -i: full-tree
  add -p: full-tree
  archive: relative
  checkout: full-tree (e.g., "git checkout -f")[1]
  checkout-index: n/a (only checks out arguments)
  clean: relative
  commit -a: full-tree[2]
  diff: full-tree
  diff-files: full-tree
  grep: relative
  ls-files: relative
  ls-tree: relative[3]
  status: shows full-tree, relative by default, absolute
          with status.relativePaths
  reset --hard: full-tree[4]
  log/show/etc: full-tree[5]
  blame: error[6]

Notes:

[1] checkout being full-tree without pathspecs is mostly due to "git
    checkout" meaning "switch to this branch" and not "checkout some part of
    the index". So naturally it is a full-tree operation.

[2] The inconsistency in "git commit -a" versus "git add -u" is to me
    one of the worst, as I think it is a useful mental model to think of
    "commit -a" as "add -u; commit".

[3] I can understand ls-files being relative, though I don't agree with
    it. But ls-tree looking at a relative subset of the tree is just
    insane (you were the one who pointed this out to me last time this
    subject came up, too).

[4] I think reset --hard is just a tree operation, since it is "set HEAD
    to this ref, check it out into the index, _and_ reset the worktree
    to match". So obviously it should be full-tree. But I think a common
    mental model, especially when resetting to HEAD implicitly, is that
    it is about "reset my working tree to the HEAD state". So I included
    it in this list.

[5] Revision traversal is not about the worktree at all, so it has
    always been about the full project. I don't think there's any
    argument there, but I put it in the list as a contrast to ls-tree,
    to which the same argument should apply.

[6] Blame obviously does nothing without a path right now. In theory it
    could eventually grow whole-directory blame. In that case, I would
    expect it to be full-tree (and "git blame ." would do what you
    want).

Assuming we move from relative to full-tree, I think the possible things
to move are:

  add -u/-A
  archive
  grep
  clean
  ls-files/ls-tree

I don't think it's worth moving ls-files/ls-tree. They're plumbing that
people don't use frequently. So the cost of moving them is high (because
we are breaking something meant to be scriptable) and the benefit is low
(because users don't type them a lot).

Obviously add and grep are the two that people have talked about. The
archive behavior surprised me, and I would think it should be full-tree
by default. But it is sort of plumbing-ish, in that people have probably
scripted around and people _don't_ tend to create archives a lot. So it
may fall into the same category as ls-files/ls-tree.

That leaves clean. I would say from a consistency standpoint that it
should go full-tree to match the other commands. But it is one of the
most destructive commands, and making it full-tree makes it easier to
accidentally delete, instead of accidentally fail to delete. So that
makes me hesitate to switch it to full-tree behavior (though a "clean
reflog" would be a pretty cool feature in general).

So depending on your view of the above, it may just be "add -u/-A" and
"grep" that are worth switching.

-Peff

Re: "git add -u" broken in git 1.7.4?

[Nguyen Thai Ngoc Duy]

On Thu, Feb 10, 2011 at 6:46 AM, Jeff King <peff@peff.net> wrote:
> Assuming we move from relative to full-tree, I think the possible things
> to move are:
>
>  add -u/-A
>  archive
>  grep
>  clean
>  ls-files/ls-tree
>
> I don't think it's worth moving ls-files/ls-tree. They're plumbing that
> people don't use frequently. So the cost of moving them is high (because
> we are breaking something meant to be scriptable) and the benefit is low
> (because users don't type them a lot).

No we should not, but we should add --full-tree to
ls-files/ls-tree/archive. I'd love "ls-files --full-tree
'*somefile*'".
-- 
Duy

Re: "git add -u" broken in git 1.7.4?

[Jeff King]

On Thu, Feb 10, 2011 at 09:24:55AM +0700, Nguyen Thai Ngoc Duy wrote:

> > I don't think it's worth moving ls-files/ls-tree. They're plumbing that
> > people don't use frequently. So the cost of moving them is high (because
> > we are breaking something meant to be scriptable) and the benefit is low
> > (because users don't type them a lot).
> 
> No we should not, but we should add --full-tree to
> ls-files/ls-tree/archive. I'd love "ls-files --full-tree
> '*somefile*'".

ls-tree already has --full-tree (and --full-name, which just gives full
pathnames but still restricts output to files in the current directory).
ls-files. ls-files has --full-name, but AFAIK needs a matching
--full-tree.

-Peff

Re: "git add -u" broken in git 1.7.4?

[Junio C Hamano]

Jeff King <peff@peff.net> writes:

> ls-tree already has --full-tree (and --full-name, which just gives full
> pathnames but still restricts output to files in the current directory).
> ls-files. ls-files has --full-name, but AFAIK needs a matching
> --full-tree.

... and --no-full-tree, if we were to make the default tweakable from the
configuration mechanism for Porcelain commands.  The convoluted logic
would go like this:

 1. 'git clean' can be made default to the full-tree operation by
    setting "porcelain.fullTreeOnNoPathspec = yes";

 2. a script may want to defeat random configuration the user may have and
    'git clean --full-tree' and 'git clean --no-full-tree' are the ways to
    force the semantics it wants;

 3. 'git ls-files' will keep the default of cwd-relativeness, but will gain
    'git ls-files --full-tree'; naturally people expect --no-full-tree to
    work, even though the command will not be affected by the configuration
    variable porcelain.fullTreeOnNoPathspec.

Re: "git add -u" broken in git 1.7.4?

[Johannes Sixt]

Am 2/10/2011 0:46, schrieb Jeff King:
> The current behavior is:
> 
>   add:    error (and suggest "git add .")
>   add -u: relative
>   add -A: relative
>   add -i: full-tree
>   add -p: full-tree
>   archive: relative
>   checkout: full-tree (e.g., "git checkout -f")[1]
>   checkout-index: n/a (only checks out arguments)
>   clean: relative
>   commit -a: full-tree[2]
>   diff: full-tree
>   diff-files: full-tree
>   grep: relative
>   ls-files: relative
>   ls-tree: relative[3]
>   status: shows full-tree, relative by default, absolute
>           with status.relativePaths
>   reset --hard: full-tree[4]
>   log/show/etc: full-tree[5]
>   blame: error[6]

    rerere forget: relative

It is a destructive command, and the rerere cache is precious, IMO.
Therefore, I'd vote to make 'git rerere forget' without a pathspec an error.

-- Hannes

Re: "git add -u" broken in git 1.7.4?

[Joshua Juran]

On Feb 9, 2011, at 3:46 PM, Jeff King wrote:

> The current behavior is:
>
>  add:    error (and suggest "git add .")
>  add -u: relative
>  add -A: relative
>  add -i: full-tree
>  add -p: full-tree

add -e: full-tree

Josh

Re: "git add -u" broken in git 1.7.4?

[Matthieu Moy]

Jeff King <peff@peff.net> writes:

> I don't think it's worth moving ls-files/ls-tree. They're plumbing that
> people don't use frequently. So the cost of moving them is high (because
> we are breaking something meant to be scriptable) and the benefit is low
> (because users don't type them a lot).

Right. At some point, we may want to introduce a porcelain version of
"git ls-files", but we shouldn't change its default behavior.

> The archive behavior surprised me, and I would think it should be full-tree
> by default. But it is sort of plumbing-ish, in that people have probably
> scripted around and people _don't_ tend to create archives a lot.

Right. There are probably more calls to "git archive" in cron jobs and
web interface than directly from the command-line.

> That leaves clean. I would say from a consistency standpoint that it
> should go full-tree to match the other commands. But it is one of the
> most destructive commands, and making it full-tree makes it easier to
> accidentally delete, instead of accidentally fail to delete.

Agreed. That would be really bad surprise for an experience user to
upgrade Git, type "git clean -fdx" from a subdirectory, and to notice
the new behavior afterwards ;-).

> So depending on your view of the above, it may just be "add -u/-A" and
> "grep" that are worth switching.

Agreed.

-- 
Matthieu Moy
http://www-verimag.imag.fr/~moy/

[PATCH] command-list.txt: mark git-archive plumbing

[Nguyen Thai Ngoc Duy]

The command's official status is porcelain. However by the nature of the
command it is frequently used in scripting and therefore its interface
must be strictly backward compatible.

Mark it plumbing to make it clear.

Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
  On Wed, Feb 09, 2011 at 06:46:21PM -0500, Jeff King wrote:
  > Obviously add and grep are the two that people have talked about. The
  > archive behavior surprised me, and I would think it should be full-tree
  > by default. But it is sort of plumbing-ish, in that people have probably
  > scripted around and people _don't_ tend to create archives a lot. So it
  > may fall into the same category as ls-files/ls-tree.
  
  Perhaps a patch like this for the record?

 command-list.txt |    2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/command-list.txt b/command-list.txt
index 95bf18c..7888121 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -5,7 +5,7 @@ git-am                                  mainporcelain
 git-annotate                            ancillaryinterrogators
 git-apply                               plumbingmanipulators
 git-archimport                          foreignscminterface
-git-archive                             mainporcelain
+git-archive                             mainporcelain plumbinginterrogators
 git-bisect                              mainporcelain common
 git-blame                               ancillaryinterrogators
 git-branch                              mainporcelain common
-- 
1.7.3.1.256.g2539c.dirty

Re: [PATCH] command-list.txt: mark git-archive plumbing

[Junio C Hamano]

Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:

>   Perhaps a patch like this for the record?

Hmm, I don't think you can have it two ways.

What does Documentation/cmd-list.perl do to this line?

>  command-list.txt |    2 +-
>  1 files changed, 1 insertions(+), 1 deletions(-)
>
> diff --git a/command-list.txt b/command-list.txt
> index 95bf18c..7888121 100644
> --- a/command-list.txt
> +++ b/command-list.txt
> @@ -5,7 +5,7 @@ git-am                                  mainporcelain
>  git-annotate                            ancillaryinterrogators
>  git-apply                               plumbingmanipulators
>  git-archimport                          foreignscminterface
> -git-archive                             mainporcelain
> +git-archive                             mainporcelain plumbinginterrogators
>  git-bisect                              mainporcelain common
>  git-blame                               ancillaryinterrogators
>  git-branch                              mainporcelain common
> -- 
> 1.7.3.1.256.g2539c.dirty

Re: [PATCH] command-list.txt: mark git-archive plumbing

[Nguyen Thai Ngoc Duy]

On Wed, Feb 16, 2011 at 2:11 AM, Junio C Hamano <gitster@pobox.com> wrote:
> Nguyen Thai Ngoc Duy <pclouds@gmail.com> writes:
>
>>   Perhaps a patch like this for the record?
>
> Hmm, I don't think you can have it two ways.
>
> What does Documentation/cmd-list.perl do to this line?

I see. The first category is used to split commands into a hash.

cmd-list.perl produces cmds-mainporcelain.txt with git-archive and
cmds-plumbinginterrogators.txt without.
-- 
Duy