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

[Jeff King <peff@peff.net>]

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