Re: [BUG] 'add -u' doesn't work from untracked subdir

[Junio C Hamano <gitster@pobox.com>]

Nanako Shiraishi <nanako3@lavabit.com> writes:

> Quoting Junio C Hamano <gitster@pobox.com>
>
>> 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.