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 -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html