git archive without path

Hi!

I have never run "git archive" inside of a subdirectory but somehow I have always assumed that it creates an archive containing all files in it regardless the current directory. In fact, the git-archive man page says so:

path
    If one or more paths are specified, include only these in the
    archive, otherwise include all files and subdirectories.

But it turned out that "git archive" works as "git archive .", i.e. adds files starting with the current directory. Is any rational for this behavior? It smells to me like a bug rather than a feature. I cannot imagine wanting to create archive containing just part of the whole repository just because he happened to be in that directory, and documentation clearly says that all files should be added unless one or more paths are specified.

Dmitry

Dmitry Potapov venit, vidit, dixit 30.11.2009 13:32:

Depends on the definition of "all" :)

In fact: Two mighty powers are fighting right now for the primacy in the Land of the Git, and both carry the name "consistency" on their flags. One is the "order of the consistency of generations", also named "backwards compatibility", and one is the "order of the consistency of commands", also named "user experience".

Many commands have different defaults with respect to how they behave in a subdirectory (compare status to ls-files, e.g.), and the discussion about how to best change that are underway, most prominently in the case of git grep. I expect that we'll have a gradual migration path towards a "full-tree" default, but that is just my personal interpretation of the current "battle". In the short term the best that we can hope for is a consistent, convenient notation which enforcers a specific behaviour, such as "/" (non-existent) versus "." (existent).

Cheers, Michael

On Mon, Nov 30, 2009 at 4:05 PM, Michael J Gruber <git@drmicha.warpmail.net> wrote:

I don't think it caries any restriction clause in this case....

Well, "order of the consistency" is a noble cause, but I don't think the situations are comparable. The man page for git-grep has never claimed that git grep works on all files. Also, git grep works on the working tree by default, so defaulting to the current working directory at least makes some sense. I cannot say the same about git-archive, which only works on the repository and if I specified some revision without any path then I expect to have the whole archive not some part of it just because I happened to be in some subdirectory.

So, in the case of git-grep, we speak about changing the behavior that was well-known, often used, and documented as such. On contrast, git-archive documented as including all files if path is not specified.

Dmitry

Michael J Gruber <git@drmicha.warpmail.net> writes:

You need to throw in another "work similarly to the counterpart outside git world" and you will have a better picture. This third consistency often sides with the first one.

In the case of "git archive" (and "git grep" in the other thread), it works like you run "tar" (and "grep -r", for "git grep") both because the original implementor wanted a version of "tar" ("grep") that works inside git world, and early adopters and users found the third consistency easy to work with, and that is why the third consistency grew into the first one.

Dmitry Potapov schrieb:

This sentence doesn't specify whose files and subdirectories are to be included -- those in the repository's root or those in the current directory. Let's fix that.

-- >8 --
Subject: archive: clarify description of path parameter

Mention that path parameters are based on the current working directory.

Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
--
 Documentation/git-archive.txt |    5 +++--
 1 files changed, 3 insertions(+), 2 deletions(-)