Nanako Shiraishi <nanako3@xxxxxxxxxxx> writes: > Quoting Junio C Hamano <gitster@xxxxxxxxx> > >> 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 >> '.'? > > 'git-archive' behaves relative to your current directory. > > http://thread.gmane.org/gmane.comp.version-control.git/41300/focus=44125 > > You can limit it to the current directory with a dot. Thanks. If you want to make a tarball of the Documentation directory from your work tree, you do this: $ cd Documentation $ tar cf - . >/tmp/docs.tar If you want to do the same but from your committed content, you do this: $ cd Documentation $ git archive HEAD >/tmp/docs.tar and you do not have to say: $ cd Documentation $ git archive HEAD . >/tmp/docs.tar So in that sense it does make sense to archive the current directory. It matches what the users expect from their archivers. The traditional archivers may not default to "." but we do. That is about giving a sensible default [*1*]. Perhaps defaulting to the cwd behaviour for one command may seem a sensible thing when looking at that particular command alone; archive and grep fall into that category. But as this "add -u" discussion showed us [*2*], people may expect different "sensible default", and as a suite of commands as the whole, it becomes messy. People have to remember which ones obey cwd, and to some people the choice is not intuitive. To avoid confusion, I am beginning to agree with people who said in the thread that it is a good idea to consistently default to the root of the contents. When we use "everything" as the default due to lack of command line pathspec, we would use "everything from root" no matter where you are, regardless of what command we are talking about. That would make the rule easier to remember [*3*]. This changes the way how "git (add -u|grep|clean|archive)" without pathspec and "git (add -u|grep|clean|archive) ." with an explicit dot work. The former (adds all changed files in, finds hits in, removes untracked paths in, creates a tarball for) the whole tree, while the latter limits the operation explicitly to the current directory. If this were going to happen as a list concensus, I am very tempted to suggest that we at least _consider_ applying the same rule even to ls-files and ls-tree. That would impact scripts, so we need to be extra careful, though. Also this takes us to a tangent. If we try to give a sensible default to make it easier for the user, perhaps we should also default to HEAD when the user did not specify which tree-ish to archive from. This is a topic in a separate thread. [Footnote] *1* Actually we don't allow "git archive HEAD ..", which I think is a bug. Also we do not have --full-tree workaround, which makes it slightly cumbersome to use. *2* And the thread you quoted shows us that the argument applies equally to "git archive" as well; you see me complaining that it is unintuitive for me to care about "archive", and the counterargument was that ls-tree does so. I however think it is more important for archive to behave in a way that is easier for the users to understand, than mimick the historical mistake in a plumbing command. *3* Command line pathspec of course should honor cwd as before. When you say "git distim Makefile" inside t/ directory, we distim t/Makefile, not the toplevel Makefile. This discussion is only about the case where the user didn't give us any pathspec. -- 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