git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Junio C Hamano <junkio@cox.net>
To: "René Scharfe" <rene.scharfe@lsrfire.ath.cx>
Cc: Nick Williams <njw@jarb.freeserve.co.uk>, git@vger.kernel.org
Subject: Re: [PATCH] git-archive: document CWD effect
Date: Sun, 08 Apr 2007 16:21:02 -0700	[thread overview]
Message-ID: <7virc68nc1.fsf@assigned-by-dhcp.cox.net> (raw)
In-Reply-To: <4618DFEE.8080707@lsrfire.ath.cx> (René Scharfe's message of "Sun, 08 Apr 2007 14:28:30 +0200")

René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:

> Nick Williams schrieb:
>> git-archive only archives the current working dir (and sub dirs) even
>> when no paths are specified. For example, if I do
>> 
>> git archive --format=tar --prefix=git-1.5.0.2/ HEAD > ~/test/test.tar
>> 
>> from with in the Documentation dir, then I only get part of the tree.
>> 
>> Is this the intended behavior?
>> 
>> The reason I ask is that from my (mis)reading of the man page I expect
>> to get all of the tree unless paths are specified.
>
> Sorry about the late reply.  Would these two additional manpage lines
> clear things up for you?

While the updated description reflects what the command does
more accurately, I am not sure if it is a desired behaviour.
For one thing, --format=tar (by the way, maybe we would want to
make this the default when none is specified?) adds the comment
that is readable by get-tar-commit-id that claims the tarball
contains the named commit, giving a false impression that it is
the whole thing.  Since people who _really_ want a subtree can
just say "git archive --format=tar HEAD:Documentation", I
suspect we may be better off not doing "current directory only"
by default.  This changes the behaviour, but (1) it affects only
people who run from a subdirectory, (2) it is counterintuitive
that your location in the working tree matters when you say "I
want a tarball of that commit", and (3) it is an undocumented
behaviour anyway.

So my suggestions are:

 (1) When no pathspec is given, archive the whole tree, even
     when you are in a subdirectory.

 (2) When a pathspec is given, produce a partial tarball limited
     to the named spec like we do now, but do not say it is a
     tarball of the named commit (i.e. get-tar-commit-id would
     say empty).

An alternative to (2) would be to say "$commit:Documentation"
instead, but that has a little issue of what to do when more
than one pathspecs are given.

  reply	other threads:[~2007-04-08 23:21 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2007-03-03 16:07 bug in git-archive? Nick Williams
2007-03-03 16:09 ` Johannes Schindelin
2007-04-08 12:28 ` [PATCH] git-archive: document CWD effect René Scharfe
2007-04-08 23:21   ` Junio C Hamano [this message]
2007-04-09 15:04     ` René Scharfe
2007-04-09 20:00       ` Junio C Hamano
2007-04-09 20:37       ` Andy Parkins
2007-04-10 14:24         ` René Scharfe
2007-04-10 21:49           ` Junio C Hamano
2007-04-11 20:36             ` René Scharfe

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=7virc68nc1.fsf@assigned-by-dhcp.cox.net \
    --to=junkio@cox.net \
    --cc=git@vger.kernel.org \
    --cc=njw@jarb.freeserve.co.uk \
    --cc=rene.scharfe@lsrfire.ath.cx \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).