{"thread":{"id":"7060","subject":"bug in git-archive?","startedAt":"2007-03-03T16:07:49Z","lastAt":"2007-04-11T20:36:16Z","messageCount":10,"participants":["Nick Williams","Johannes Schindelin","René Scharfe","Junio C Hamano","Andy Parkins"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"36180","messageId":"esc64d$d2u$1@sea.gmane.org","threadId":"7060","inReplyTo":null,"subject":"bug in git-archive?","fromName":"Nick Williams","fromEmail":"njw@jarb.freeserve.co.uk","sentAt":"2007-03-03T16:07:49Z","receivedAt":"2007-03-03T16:07:49Z","isPatch":false,"sender":{"key":"njw@jarb.freeserve.co.uk","avatar":null},"body":"Hello everyone\n\ngit-archive only archives the current working dir (and sub dirs) even \nwhen no paths are specified. For example, if I do\n\ngit archive --format=tar --prefix=git-1.5.0.2/ HEAD > ~/test/test.tar\n\nfrom with in the Documentation dir, then I only get part of the tree.\n\nIs this the intended behavior?\n\nThe reason I ask is that from my (mis)reading of the man page I expect \nto get all of the tree unless paths are specified.\n\nthanks\n\nNJW\n"},{"id":"36181","messageId":"Pine.LNX.4.63.0703031707540.22628@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"7060","inReplyTo":"esc64d$d2u$1@sea.gmane.org","subject":"Re: bug in git-archive?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2007-03-03T16:09:19Z","receivedAt":"2007-03-03T16:09:19Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 3 Mar 2007, Nick Williams wrote:\n\n> git-archive only archives the current working dir (and sub dirs) even \n> when no paths are specified. For example, if I do\n> \n> git archive --format=tar --prefix=git-1.5.0.2/ HEAD > ~/test/test.tar\n> \n> > from with in the Documentation dir, then I only get part of the tree.\n> \n> Is this the intended behavior?\n\nIt is. So, the documentation is wrong.\n\nCiao,\nDscho\n"},{"id":"38879","messageId":"4618DFEE.8080707@lsrfire.ath.cx","threadId":"7060","inReplyTo":"esc64d$d2u$1@sea.gmane.org","subject":"[PATCH] git-archive: document CWD effect","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2007-04-08T12:28:30Z","receivedAt":"2007-04-08T12:28:30Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>\n---\n\nNick Williams schrieb:\n> git-archive only archives the current working dir (and sub dirs) even\n> when no paths are specified. For example, if I do\n> \n> git archive --format=tar --prefix=git-1.5.0.2/ HEAD > ~/test/test.tar\n> \n> from with in the Documentation dir, then I only get part of the tree.\n> \n> Is this the intended behavior?\n> \n> The reason I ask is that from my (mis)reading of the man page I expect\n> to get all of the tree unless paths are specified.\n\nSorry about the late reply.  Would these two additional manpage lines\nclear things up for you?\n\nThanks,\nRené\n\n\ndiff --git a/Documentation/git-archive.txt b/Documentation/git-archive.txt\nindex 493474b..b688330 100644\n--- a/Documentation/git-archive.txt\n+++ b/Documentation/git-archive.txt\n@@ -17,6 +17,9 @@ Creates an archive of the specified format containing the tree\n structure for the named tree.  If <prefix> is specified it is\n prepended to the filenames in the archive.\n \n+Only the files and directories in the current working directory are\n+included in archives created locally (i.e. without --remote).\n+\n 'git-archive' behaves differently when given a tree ID versus when\n given a commit ID or tag ID.  In the first case the current time is\n used as modification time of each file in the archive.  In the latter\n"},{"id":"38890","messageId":"7virc68nc1.fsf@assigned-by-dhcp.cox.net","threadId":"7060","inReplyTo":"4618DFEE.8080707@lsrfire.ath.cx","subject":"Re: [PATCH] git-archive: document CWD effect","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-08T23:21:02Z","receivedAt":"2007-04-08T23:21:02Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:\n\n> Nick Williams schrieb:\n>> git-archive only archives the current working dir (and sub dirs) even\n>> when no paths are specified. For example, if I do\n>> \n>> git archive --format=tar --prefix=git-1.5.0.2/ HEAD > ~/test/test.tar\n>> \n>> from with in the Documentation dir, then I only get part of the tree.\n>> \n>> Is this the intended behavior?\n>> \n>> The reason I ask is that from my (mis)reading of the man page I expect\n>> to get all of the tree unless paths are specified.\n>\n> Sorry about the late reply.  Would these two additional manpage lines\n> clear things up for you?\n\nWhile the updated description reflects what the command does\nmore accurately, I am not sure if it is a desired behaviour.\nFor one thing, --format=tar (by the way, maybe we would want to\nmake this the default when none is specified?) adds the comment\nthat is readable by get-tar-commit-id that claims the tarball\ncontains the named commit, giving a false impression that it is\nthe whole thing.  Since people who _really_ want a subtree can\njust say \"git archive --format=tar HEAD:Documentation\", I\nsuspect we may be better off not doing \"current directory only\"\nby default.  This changes the behaviour, but (1) it affects only\npeople who run from a subdirectory, (2) it is counterintuitive\nthat your location in the working tree matters when you say \"I\nwant a tarball of that commit\", and (3) it is an undocumented\nbehaviour anyway.\n\nSo my suggestions are:\n\n (1) When no pathspec is given, archive the whole tree, even\n     when you are in a subdirectory.\n\n (2) When a pathspec is given, produce a partial tarball limited\n     to the named spec like we do now, but do not say it is a\n     tarball of the named commit (i.e. get-tar-commit-id would\n     say empty).\n\nAn alternative to (2) would be to say \"$commit:Documentation\"\ninstead, but that has a little issue of what to do when more\nthan one pathspecs are given.\n"},{"id":"38935","messageId":"461A55FB.6070600@lsrfire.ath.cx","threadId":"7060","inReplyTo":"7virc68nc1.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-archive: document CWD effect","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2007-04-09T15:04:27Z","receivedAt":"2007-04-09T15:04:27Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Junio C Hamano schrieb:\n> While the updated description reflects what the command does\n> more accurately, I am not sure if it is a desired behaviour.\n> For one thing, --format=tar (by the way, maybe we would want to\n> make this the default when none is specified?) adds the comment\n> that is readable by get-tar-commit-id that claims the tarball\n> contains the named commit, giving a false impression that it is\n> the whole thing.\n\nIt marks the archive as being _created_ from this specific commit, not\nnecessarily as containing all of it.  Perhaps this should be noted in\nthe documentation..\n\nMaking '--format=tar' the default is a good idea.  I doubt we'll see the\naddition of a new archive format -- that deserves to be the default one\ninstead of tar -- soon.\n\n> Since people who _really_ want a subtree can\n> just say \"git archive --format=tar HEAD:Documentation\", I\n> suspect we may be better off not doing \"current directory only\"\n> by default.  This changes the behaviour, but (1) it affects only\n> people who run from a subdirectory, (2) it is counterintuitive\n> that your location in the working tree matters when you say \"I\n> want a tarball of that commit\", and (3) it is an undocumented\n> behaviour anyway.\n\nI agree with (1) and (3), meaning that we are free to change the\nbehaviour.  I don't agree with (2), though.  I'd find it strange if\nchanging the working directory wouldn't change the archive contents.\n\nWe should keep consistency with the rest of git here.  Since git-archive\nis just a fancy git-ls-tree, I think we should mirror its behaviour with\nrespect to the working directory.  (Which is what the current code does.\n Modulo bugs, of course.)\n\nRené\n"},{"id":"38971","messageId":"7v7islz5bw.fsf@assigned-by-dhcp.cox.net","threadId":"7060","inReplyTo":"461A55FB.6070600@lsrfire.ath.cx","subject":"Re: [PATCH] git-archive: document CWD effect","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-09T20:00:03Z","receivedAt":"2007-04-09T20:00:03Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:\n\n> Junio C Hamano schrieb:\n> ...\n>> Since people who _really_ want a subtree can\n>> just say \"git archive --format=tar HEAD:Documentation\", I\n>> suspect we may be better off not doing \"current directory only\"\n>> by default.  This changes the behaviour, but (1) it affects only\n>> people who run from a subdirectory, (2) it is counterintuitive\n>> that your location in the working tree matters when you say \"I\n>> want a tarball of that commit\", and (3) it is an undocumented\n>> behaviour anyway.\n>\n> I agree with (1) and (3), meaning that we are free to change the\n> behaviour.  I don't agree with (2), though.  I'd find it strange if\n> changing the working directory wouldn't change the archive contents.\n>\n> We should keep consistency with the rest of git here.  Since git-archive\n> is just a fancy git-ls-tree, I think we should mirror its behaviour with\n> respect to the working directory.  (Which is what the current code does.\n> Modulo bugs, of course.)\n\nI am tempted to say \"fair enough\", but I would wait for others\nto come up with objections I did not think of.\n"},{"id":"38972","messageId":"200704092137.22781.andyparkins@gmail.com","threadId":"7060","inReplyTo":"461A55FB.6070600@lsrfire.ath.cx","subject":"Re: [PATCH] git-archive: document CWD effect","fromName":"Andy Parkins","fromEmail":"andyparkins@gmail.com","sentAt":"2007-04-09T20:37:21Z","receivedAt":"2007-04-09T20:37:21Z","isPatch":true,"sender":{"key":"andyparkins@gmail.com","avatar":null},"body":"On Monday 2007, April 09, René Scharfe wrote:\n\n> I agree with (1) and (3), meaning that we are free to change the\n> behaviour.  I don't agree with (2), though.  I'd find it strange if\n> changing the working directory wouldn't change the archive contents.\n>\n> We should keep consistency with the rest of git here.  Since\n> git-archive is just a fancy git-ls-tree, I think we should mirror its\n> behaviour with respect to the working directory.  (Which is what the\n> current code does. Modulo bugs, of course.)\n\nI don't agree with the supposition that git-archive is a fancy \ngit-ls-tree.  If it were, then you'd be right.  It's not though.  It's \nmore like a git-read-tree or git-checkout-index; those both don't care \nwhere you are in the working tree.\n\nArgument 1)\ngit-archive should have nothing to do with a working tree in fact; it's \nperfectly reasonable to expect that it would work in a bare repository \nin fact - that's almost the definition of a command that shouldn't be \nworking directory aware.\n\nArgument 2)\nConsider the --remote option.  What \"working path\" should be relevant \nwhen \"--remote\" is passed?  For consistency, git-archive should always \nrefer to the repository root.\n\nArgument 3)\ngit-archive is similar to other VCS's \"export\" command; and for those \nthe export command in it's default form will work without a local \ncheckout and they export from the repository root.\n\nArgument 4)\nWhat if the repository has multiple root commits, similar to git's html \nand todo branches.  Now, use git-archive and reference one of those \ncommits.  The working directory you're in now has no relevance at all \nto the commit your targeting - it need not even exist.  The same \nproblem exists of course if you are now in a directory that didn't \nexist in the past.\n\n\n\nAndy\n-- \nDr Andy Parkins, M Eng (hons), MIET\nandyparkins@gmail.com\n"},{"id":"39003","messageId":"461B9E22.5020102@lsrfire.ath.cx","threadId":"7060","inReplyTo":"200704092137.22781.andyparkins@gmail.com","subject":"Re: [PATCH] git-archive: document CWD effect","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2007-04-10T14:24:34Z","receivedAt":"2007-04-10T14:24:34Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Andy Parkins schrieb:\n> On Monday 2007, April 09, René Scharfe wrote:\n> \n>> I agree with (1) and (3), meaning that we are free to change the\n>> behaviour.  I don't agree with (2), though.  I'd find it strange if\n>> changing the working directory wouldn't change the archive contents.\n>>\n>> We should keep consistency with the rest of git here.  Since\n>> git-archive is just a fancy git-ls-tree, I think we should mirror its\n>> behaviour with respect to the working directory.  (Which is what the\n>> current code does. Modulo bugs, of course.)\n> \n> I don't agree with the supposition that git-archive is a fancy \n> git-ls-tree.  If it were, then you'd be right.  It's not though.  It's \n> more like a git-read-tree or git-checkout-index; those both don't care \n> where you are in the working tree.\n>\n> Argument 1)\n> git-archive should have nothing to do with a working tree in fact; it's \n> perfectly reasonable to expect that it would work in a bare repository \n> in fact - that's almost the definition of a command that shouldn't be \n> working directory aware.\n\nIt works in bare repositories, as does git-ls-tree.  There the question\nof what to do in subdirectories doesn't even come up, because there are\nnone. :)\n\nBut just because it works in situations where there are no\nsubdirectories that doesn't mean that it has to ignore them in other\nsituations.\n\n> Argument 2)\n> Consider the --remote option.  What \"working path\" should be relevant \n> when \"--remote\" is passed?  For consistency, git-archive should always \n> refer to the repository root.\n\n'git-archive --remote' passes the options to the remote system, ignoring\nthe local working directory.  What matters in this case is the working\ndirectory on the remote end, which is the repository's root.\n\nBut just because there is currently no way (that I know of) to change\nthe working directory on the remote end that doesn't mean the command\nneeds to ignore the working directory when operating locally, where it\ncan be changed easily.\n\n> Argument 3)\n> git-archive is similar to other VCS's \"export\" command; and for those \n> the export command in it's default form will work without a local \n> checkout and they export from the repository root.\n\nOK, I haven't seen other tools, so I can't really comment on them.\ngit-archive _does_ work without a checkout, though.\n\n> Argument 4)\n> What if the repository has multiple root commits, similar to git's html \n> and todo branches.  Now, use git-archive and reference one of those \n> commits.  The working directory you're in now has no relevance at all \n> to the commit your targeting - it need not even exist.  The same \n> problem exists of course if you are now in a directory that didn't \n> exist in the past.\n\nYes, that's true; git-archive will tell you that your current working\ndirectory is untracked in that case.  (git-ls-tree in that case lists:\nnothing.)  But if you want to create a full archive you need to be in\nthe repository's root directory anyway, so this is no new issue.\n\nWhat it comes down to is the decision between consistency with third\nparty export tools or with its (implementation-wise) brother\ngit-ls-tree, between the convenience of not needing to care where in the\nrepository you are or the convenience of being able to let the working\ndirectory determine the file set that ends up in the archive.\n\nI'd rather keep it consistent from a technical, implementation point of\nview and not care too much about other export tools, and I like my\nworking directory to influence which files I'm working with.  Working\ndirectory sensitivity is just another input method, like parameters and\nenvironment variables.  I still see no benefit in removing it.  But\nperhaps I'm in a rut, unable to see the difficulties with this way to work.\n\nRe(not getting it ;-)né\n"},{"id":"39059","messageId":"7v8xczvr13.fsf@assigned-by-dhcp.cox.net","threadId":"7060","inReplyTo":"461B9E22.5020102@lsrfire.ath.cx","subject":"Re: [PATCH] git-archive: document CWD effect","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2007-04-10T21:49:28Z","receivedAt":"2007-04-10T21:49:28Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:\n\n> But just because there is currently no way (that I know of) to change\n> the working directory on the remote end that doesn't mean the command\n> needs to ignore the working directory when operating locally, where it\n> can be changed easily.\n\nI do not think it has much to do with \"working directory\".  The\nremote one would most often be bare, and especially the public\nones are so.  I think the issue is if I ask a tarball of this\ncommit without giving any specific parameters, what should\nhappen.\n\nAnd I think most people find it natural if you give them the\nwhole tree no matter where they start from.\n\nYou could:\n\n        $ git archive HEAD -- t/howto\n\nto have a narrowed tarball, and even if you make:\n\n\t$ cd t/howto\n\t$ git archive HEAD\n\nto produce the whole tree, the user can still do:\n\n\t$ cd t/howto\n        $ git archive HEAD -- .\n\nto get the narrowed tree if the command understands the prefix\nit receives from git_setup_directory().\n\nSo while I understand when you say this is \"another input\nmethod\", letting people in a deep directory to abbreviate their\ncwd with \".\" would equally a good input method, and probably\nbetter than the current implementation, which leaves people\nwithout a single way to say \"I want the whole tree\" without\ncd'ing up.\n"},{"id":"39131","messageId":"461D46C0.6080702@lsrfire.ath.cx","threadId":"7060","inReplyTo":"7v8xczvr13.fsf@assigned-by-dhcp.cox.net","subject":"Re: [PATCH] git-archive: document CWD effect","fromName":"René Scharfe","fromEmail":"rene.scharfe@lsrfire.ath.cx","sentAt":"2007-04-11T20:36:16Z","receivedAt":"2007-04-11T20:36:16Z","isPatch":true,"sender":{"key":"l.s.r@web.de","avatar":"https://avatars.githubusercontent.com/u/26122331?v=4"},"body":"Junio C Hamano schrieb:\n> And I think most people find it natural if you give them the whole\n> tree no matter where they start from.\n\nWell, I can't argue against that, as I don't have any numbers.  But I\ncan understand this expectation a bit (\"archive HEAD!\" -- \"here is an\near\" might be confusing ;).\n\n> You could:\n> \n> $ git archive HEAD -- t/howto\n> \n> to have a narrowed tarball, and even if you make:\n> \n> $ cd t/howto $ git archive HEAD\n> \n> to produce the whole tree, the user can still do:\n> \n> $ cd t/howto $ git archive HEAD -- .\n> \n> to get the narrowed tree if the command understands the prefix it\n> receives from git_setup_directory().\n> \n> So while I understand when you say this is \"another input method\",\n> letting people in a deep directory to abbreviate their cwd with \".\"\n> would equally a good input method, and probably better than the\n> current implementation, which leaves people without a single way to\n> say \"I want the whole tree\" without cd'ing up.\n\nHmm, switching the feature's default mode around instead of cutting it\noff completely might be a good idea.  Something like this?  Unlike the\ncurrent implementation, it always writes the full path from the repo\nroot for each file.\n\nRené\n\n\ndiff --git a/builtin-archive.c b/builtin-archive.c\nindex 7f4e409..efa8679 100644\n--- a/builtin-archive.c\n+++ b/builtin-archive.c\n@@ -128,18 +128,6 @@ void parse_treeish_arg(const char **argv, struct archiver_args *ar_args,\n \tif (tree == NULL)\n \t\tdie(\"not a tree object\");\n \n-\tif (prefix) {\n-\t\tunsigned char tree_sha1[20];\n-\t\tunsigned int mode;\n-\t\tint err;\n-\n-\t\terr = get_tree_entry(tree->object.sha1, prefix,\n-\t\t\t\t     tree_sha1, &mode);\n-\t\tif (err || !S_ISDIR(mode))\n-\t\t\tdie(\"current working directory is untracked\");\n-\n-\t\ttree = parse_tree_indirect(tree_sha1);\n-\t}\n \tar_args->tree = tree;\n \tar_args->commit_sha1 = commit_sha1;\n \tar_args->time = archive_time;\n@@ -241,6 +229,7 @@ int cmd_archive(int argc, const char **argv, const char *prefix)\n \tstruct archiver ar;\n \tint tree_idx;\n \tconst char *remote = NULL;\n+\tconst char **pathspec;\n \n \tremote = extract_remote_arg(&argc, argv);\n \tif (remote)\n@@ -255,7 +244,11 @@ int cmd_archive(int argc, const char **argv, const char *prefix)\n \n \targv += tree_idx;\n \tparse_treeish_arg(argv, &ar.args, prefix);\n-\tparse_pathspec_arg(argv + 1, &ar.args);\n+\n+\tpathspec = argv + 1;\n+\tif (*pathspec && prefix)\n+\t\tpathspec = get_pathspec(prefix, pathspec);\n+\tparse_pathspec_arg(pathspec, &ar.args);\n \n \treturn ar.write_archive(&ar.args);\n }\n"}]}