{"thread":{"id":"37953","subject":"Git archiving only branch work","startedAt":"2014-11-13T12:32:40Z","lastAt":"2014-11-14T20:35:22Z","messageCount":13,"participants":["Graeme Geldenhuys","Peter Krefting","Duy Nguyen","Thomas Koch","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"251814","messageId":"5464a4e8.4a0.2bfa0e00.3067f800@geldenhuys.co.uk","threadId":"37953","inReplyTo":null,"subject":"Git archiving only branch work","fromName":"Graeme Geldenhuys","fromEmail":"mailinglists@geldenhuys.co.uk","sentAt":"2014-11-13T12:32:40Z","receivedAt":"2014-11-13T12:32:40Z","isPatch":false,"sender":{"key":"mailinglists@geldenhuys.co.uk","avatar":null},"body":"Hi,\n\nI've strung together the following git alias command for our company. \nThis command allows us to create a deployment package (archive) for a \nspecific feature. The archive will contain only the files that changed \nduring the development of that feature. We then deploy that archive to \nour client's web/database server for example.\n\n[alias]\n deploy = !sh -c 'git archive --prefix=$1/ -o deploy_$1.zip HEAD \n$(git diff --name-only -D $2)' -\n\n\nusage:\n git deploy OPS123 develop..ops-123\n\n\n'OPS123' is the prefix directory to store the changes in\n'ops-123' is the feature branch the work was done in.\n\nThis works very well. The only problem we have so far is that if we \nhave files with spaces in the name (eg: SQL update scripts), then the \ncommand breaks.\n\nDoes anybody have an idea on how this can be resolved? Any help would \nbe much appreciated.\n\nNot sure if this is useful, but we are working on Windows systems and \nuse Git Bash consoles.\n\nRegards,\n Graeme\n"},{"id":"251815","messageId":"alpine.DEB.2.02.1411131416010.8007@perkele.intern.softwolves.pp.se","threadId":"37953","inReplyTo":"5464a4e8.4a0.2bfa0e00.3067f800@geldenhuys.co.uk","subject":"Re: Git archiving only branch work","fromName":"Peter Krefting","fromEmail":"peter@softwolves.pp.se","sentAt":"2014-11-13T13:19:37Z","receivedAt":"2014-11-13T13:19:37Z","isPatch":false,"sender":{"key":"peter@softwolves.pp.se","avatar":"https://avatars.githubusercontent.com/u/990764?v=4"},"body":"Graeme Geldenhuys:\n\n> This works very well. The only problem we have so far is that if we have \n> files with spaces in the name (eg: SQL update scripts), then the command \n> breaks.\n\nIf you add -z to the git diff command-line, it will give you the names \nwith nul terminators instead. If you couple that with xargs -0, you \nshould be able to do something like this (untested):\n\ndeply = !sh -c 'git diff --name-only -z -D $2 | xargs -x -0 git archive --prefix=$1/ -o \ndeploy_$1.zip HEAD'\n\n-- \n\\\\// Peter - http://www.softwolves.pp.se/\n"},{"id":"251816","messageId":"20141113133615.GA28346@lanh","threadId":"37953","inReplyTo":"5464a4e8.4a0.2bfa0e00.3067f800@geldenhuys.co.uk","subject":"Re: Git archiving only branch work","fromName":"Duy Nguyen","fromEmail":"pclouds@gmail.com","sentAt":"2014-11-13T13:36:16Z","receivedAt":"2014-11-13T13:36:16Z","isPatch":false,"sender":{"key":"pclouds@gmail.com","avatar":"https://avatars.githubusercontent.com/u/720?v=4"},"body":"On Thu, Nov 13, 2014 at 12:32:40PM +0000, Graeme Geldenhuys wrote:\n> [alias]\n> deploy = !sh -c 'git archive --prefix=$1/ -o deploy_$1.zip HEAD \n> $(git diff --name-only -D $2)' -\n> \n> This works very well. The only problem we have so far is that if we \n> have files with spaces in the name (eg: SQL update scripts), then the \n> command breaks.\n> \n> Does anybody have an idea on how this can be resolved? Any help would \n> be much appreciated.\n\nI wonder if it's overkill to do something like this patch (\"git\narchive\" may need some more updates for it to work though). With it\nyou can do:\n\n git diff --name-only ... | git archive ... HEAD -- \":(file)-\"\n\nThe good thing is it works for other commands as well. But is it\nreally a good thing..\n\n-- 8<--\nSubject: [PATCH] pathspec: support :(file)\n\nThis pathspec magic must be used alone. It reads the actual pathspec\nfrom a given file whose path is specified after :(file). E.g.\n\n git ls-files :(file)foo\n\nlist files specified by pathspec in file \"foo\". Reading from stdin is\npossible to:\n\n git ls-fiels :(file)-\n\nTODO: specify line terminator..\n---\n pathspec.c | 38 ++++++++++++++++++++++++++++++++++++++\n pathspec.h | 4 +++-\n 2 files changed, 41 insertions(+), 1 deletion(-)\n\ndiff --git a/pathspec.c b/pathspec.c\nindex 9304ee3..ba34f9b 100644\n--- a/pathspec.c\n+++ b/pathspec.c\n@@ -1,6 +1,7 @@\n #include \"cache.h\"\n #include \"dir.h\"\n #include \"pathspec.h\"\n+#include \"argv-array.h\"\n \n /*\n * Finds which of the given pathspecs match items in the index.\n@@ -72,6 +73,7 @@ static struct pathspec_magic {\n \t{ PATHSPEC_GLOB, '\\0', \"glob\" },\n \t{ PATHSPEC_ICASE, '\\0', \"icase\" },\n \t{ PATHSPEC_EXCLUDE, '!', \"exclude\" },\n+\t{ PATHSPEC_FROMFILE, 0, \"file\" },\n };\n \n static void prefix_short_magic(struct strbuf *sb, int prefixlen,\n@@ -235,6 +237,9 @@ static unsigned prefix_pathspec(struct pathspec_item *item,\n \t} else if (magic & PATHSPEC_FROMTOP) {\n \t\tmatch = xstrdup(copyfrom);\n \t\tprefixlen = 0;\n+\t} else if ((magic & PATHSPEC_FROMFILE) && !strcmp(copyfrom, \"-\")) {\n+\t\tmatch = xstrdup(copyfrom);\n+\t\tprefixlen = 0;\n \t} else {\n \t\tmatch = prefix_path_gently(prefix, prefixlen, &prefixlen, copyfrom);\n \t\tif (!match)\n@@ -354,6 +359,31 @@ static void NORETURN unsupported_magic(const char *pattern,\n \t pattern, sb.buf);\n }\n \n+static void pathspec_fromfile(struct pathspec *pathspec,\n+\t\t\t unsigned magic_mask, unsigned flags,\n+\t\t\t const char *prefix, const char *path)\n+{\n+\tstruct strbuf buf, nbuf;\n+\tint line_termination = '\\n'; /* FIXME: support :(file:) */\n+\tstruct argv_array av = ARGV_ARRAY_INIT;\n+\tFILE *fp = !strcmp(path, \"-\") ? stdin : fopen(path, \"r\");\n+\n+\tif (!fp)\n+\t\tdie_errno(_(\"fail to open %s\"), path);\n+\n+\tstrbuf_init(&buf, 0);\n+\tstrbuf_init(&nbuf, 0);\n+\twhile (strbuf_getline(&buf, fp, line_termination) != EOF)\n+\t\targv_array_push(&av, buf.buf);\n+\tstrbuf_release(&buf);\n+\tstrbuf_release(&nbuf);\n+\tif (fp != stdin)\n+\t\tfclose(fp);\n+\tparse_pathspec(pathspec, magic_mask | PATHSPEC_FROMFILE,\n+\t\t flags, prefix, av.argv);\n+\t/* cannot free av because pathspec keeps references to it */\n+}\n+\n /*\n * Given command line arguments and a prefix, convert the input to\n * pathspec. die() if any magic in magic_mask is used.\n@@ -427,6 +457,14 @@ void parse_pathspec(struct pathspec *pathspec,\n \t\t\t\t\t item[i].magic & magic_mask,\n \t\t\t\t\t short_magic);\n \n+\t\tif (item[i].magic & PATHSPEC_FROMFILE) {\n+\t\t\tif (n != 1)\n+\t\t\t\tdie(_(\":(file) can only be used alone\"));\n+\t\t\tpathspec_fromfile(pathspec,\n+\t\t\t\t\t magic_mask | PATHSPEC_FROMFILE,\n+\t\t\t\t\t flags, prefix, item[i].match);\n+\t\t\treturn;\n+\t\t}\n \t\tif ((flags & PATHSPEC_SYMLINK_LEADING_PATH) &&\n \t\t has_symlink_leading_path(item[i].match, item[i].len)) {\n \t\t\tdie(_(\"pathspec '%s' is beyond a symbolic link\"), entry);\ndiff --git a/pathspec.h b/pathspec.h\nindex 0c11262..84de102 100644\n--- a/pathspec.h\n+++ b/pathspec.h\n@@ -8,13 +8,15 @@\n #define PATHSPEC_GLOB\t\t(1<<3)\n #define PATHSPEC_ICASE\t\t(1<<4)\n #define PATHSPEC_EXCLUDE\t(1<<5)\n+#define PATHSPEC_FROMFILE\t(1<<6)\n #define PATHSPEC_ALL_MAGIC\t \\\n \t(PATHSPEC_FROMTOP\t| \\\n \t PATHSPEC_MAXDEPTH\t| \\\n \t PATHSPEC_LITERAL\t| \\\n \t PATHSPEC_GLOB\t\t| \\\n \t PATHSPEC_ICASE\t\t| \\\n-\t PATHSPEC_EXCLUDE)\n+\t PATHSPEC_EXCLUDE\t| \\\n+\t PATHSPEC_FROMFILE)\n \n #define PATHSPEC_ONESTAR 1\t/* the pathspec pattern satisfies GFNM_ONESTAR */\n \n-- \n2.1.0.rc0.78.gc0d8480\n\n-- 8< --\n"},{"id":"251822","messageId":"201411131710.12409.thomas@koch.ro","threadId":"37953","inReplyTo":"5464a4e8.4a0.2bfa0e00.3067f800@geldenhuys.co.uk","subject":"Re: Git archiving only branch work","fromName":"Thomas Koch","fromEmail":"thomas@koch.ro","sentAt":"2014-11-13T16:10:11Z","receivedAt":"2014-11-13T16:10:11Z","isPatch":false,"sender":{"key":"thomas@koch.ro","avatar":null},"body":"If your servers run a Unix and you can install Git on the servers than you \nmight want to try the install script we use in our company:\n\nhttps://github.com/comsolit/comsolit_deploy\n\nThere's a bare git repository on the server and a post-receive hook that \nexports the content of the git repository in a predefined folder. After that a \nsymlink is switched to the new version.\n\nYou can run hook scripts after the export (checkout) and after the switch.\n\nThe script lacks documentation... (PRs welcome!) But it is unit tested!\n\nRegards, Thomas Koch\n"},{"id":"251826","messageId":"xmqqlhnf2ghc.fsf@gitster.dls.corp.google.com","threadId":"37953","inReplyTo":"20141113133615.GA28346@lanh","subject":"Re: Git archiving only branch work","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-11-13T16:49:19Z","receivedAt":"2014-11-13T16:49:19Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Duy Nguyen writes:\n\n> On Thu, Nov 13, 2014 at 12:32:40PM +0000, Graeme Geldenhuys wrote:\n>> [alias]\n>> deploy = !sh -c 'git archive --prefix=$1/ -o deploy_$1.zip HEAD \n>> $(git diff --name-only -D $2)' -\n>> \n>> This works very well. The only problem we have so far is that if we \n>> have files with spaces in the name (eg: SQL update scripts), then the \n>> command breaks.\n>> \n>> Does anybody have an idea on how this can be resolved? Any help would \n>> be much appreciated.\n\nSet $IFS to newline, so that $(git diff --name-only ...) output is\nsplit at record boundaries, not inside pathnames?\n\nA quick experiment you can do to convince yourself may be:\n\n-- >8 --\n#!/bin/sh\n\ndata () {\n\techo \"a\"\n\techo \"b c\" ;# SP in between\n\techo \"d\te \" ;# HT and trailing SP\n}\n\nshow () {\n\tfor i\n\tdo\n\t\techo \"<<$i>>\"\n\tdone\n}\n\necho ONE\nshow $(data)\n\nIFS='\n'\n\necho TWO\nshow $(data)\n-- 8< --\n\nOn the \"git archive\" invocation, there may be something that tells\nthe pathspecs are literal, like '--literal-pathspecs' option, to\navoid metacharacters from being expanded, though.\n"},{"id":"251846","messageId":"20141113200640.GB3869@peff.net","threadId":"37953","inReplyTo":"20141113133615.GA28346@lanh","subject":"Re: Git archiving only branch work","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-13T20:06:40Z","receivedAt":"2014-11-13T20:06:40Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 13, 2014 at 08:36:16PM +0700, Duy Nguyen wrote:\n\n> On Thu, Nov 13, 2014 at 12:32:40PM +0000, Graeme Geldenhuys wrote:\n> > [alias]\n> > deploy = !sh -c 'git archive --prefix=$1/ -o deploy_$1.zip HEAD \n> > $(git diff --name-only -D $2)' -\n> > \n> > This works very well. The only problem we have so far is that if we \n> > have files with spaces in the name (eg: SQL update scripts), then the \n> > command breaks.\n> > \n> > Does anybody have an idea on how this can be resolved? Any help would \n> > be much appreciated.\n> \n> I wonder if it's overkill to do something like this patch (\"git\n> archive\" may need some more updates for it to work though). With it\n> you can do:\n> \n> git diff --name-only ... | git archive ... HEAD -- \":(file)-\"\n> \n> The good thing is it works for other commands as well. But is it\n> really a good thing..\n\nI like the idea of taking paths from stdin (and especially if there is a\n\"-z\" option). But using a pathspec that reads from stdin seems like it\ncreates a lot of corner cases. What would:\n\n git rev-list --stdin -- \":(file)-\"\n\ndo? It is kind of neat that you could read from multiple files (besides\nstdin), but I'm not sure it is all that useful in practice (you can\nalways cat them to its stdin).\n\nHow about just adding --stdin, which matches other git commands?\n\n-Peff\n"},{"id":"251851","messageId":"xmqqvbmizu12.fsf@gitster.dls.corp.google.com","threadId":"37953","inReplyTo":"20141113200640.GB3869@peff.net","subject":"Re: Git archiving only branch work","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-11-13T21:10:17Z","receivedAt":"2014-11-13T21:10:17Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Nov 13, 2014 at 08:36:16PM +0700, Duy Nguyen wrote:\n>\n>> On Thu, Nov 13, 2014 at 12:32:40PM +0000, Graeme Geldenhuys wrote:\n>> > [alias]\n>> > deploy = !sh -c 'git archive --prefix=$1/ -o deploy_$1.zip HEAD \n>> > $(git diff --name-only -D $2)' -\n>> > \n>> > This works very well. The only problem we have so far is that if we \n>> > have files with spaces in the name (eg: SQL update scripts), then the \n>> > command breaks.\n>> > \n>> > Does anybody have an idea on how this can be resolved? Any help would \n>> > be much appreciated.\n>> \n>> I wonder if it's overkill to do something like this patch (\"git\n>> archive\" may need some more updates for it to work though). With it\n>> you can do:\n>> \n>> git diff --name-only ... | git archive ... HEAD -- \":(file)-\"\n>> \n>> The good thing is it works for other commands as well. But is it\n>> really a good thing..\n>\n> I like the idea of taking paths from stdin (and especially if there is a\n> \"-z\" option). But using a pathspec that reads from stdin seems like it\n> creates a lot of corner cases. What would:\n>\n> git rev-list --stdin -- \":(file)-\"\n>\n> do? It is kind of neat that you could read from multiple files (besides\n> stdin), but I'm not sure it is all that useful in practice (you can\n> always cat them to its stdin).\n>\n> How about just adding --stdin, which matches other git commands?\n\nHow about doing nothing and use the correct $IFS instead?\n"},{"id":"251857","messageId":"20141113213318.GA7563@peff.net","threadId":"37953","inReplyTo":"xmqqvbmizu12.fsf@gitster.dls.corp.google.com","subject":"Re: Git archiving only branch work","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-13T21:33:18Z","receivedAt":"2014-11-13T21:33:18Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 13, 2014 at 01:10:17PM -0800, Junio C Hamano wrote:\n\n> > How about just adding --stdin, which matches other git commands?\n> \n> How about doing nothing and use the correct $IFS instead?\n\nCan you cover all cases with $IFS, including filenames with newlines?\n\nI agree it is probably OK in practice and for the OP's question, but it\nis nice to have \"-z\" variants so you do not have to worry about quoting\nat all. I'd argue that a \"--stdin -z\" should probably also accept raw\nfilenames, not pathspecs, too (so you do not have to use\n\"--literal-pathspecs\" elsewhere).\n\n-Peff\n"},{"id":"251859","messageId":"xmqqa93uzssv.fsf@gitster.dls.corp.google.com","threadId":"37953","inReplyTo":"20141113213318.GA7563@peff.net","subject":"Re: Git archiving only branch work","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-11-13T21:36:48Z","receivedAt":"2014-11-13T21:36:48Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Nov 13, 2014 at 01:10:17PM -0800, Junio C Hamano wrote:\n>\n>> > How about just adding --stdin, which matches other git commands?\n>> \n>> How about doing nothing and use the correct $IFS instead?\n>\n> Can you cover all cases with $IFS, including filenames with newlines?\n\nYou didn't say \"--stdin -z\", so I presume --stdin is not solving\nanything ;-)\n\n> I agree it is probably OK in practice and for the OP's question, but it\n> is nice to have \"-z\" variants so you do not have to worry about quoting\n> at all. I'd argue that a \"--stdin -z\" should probably also accept raw\n> filenames, not pathspecs, too (so you do not have to use\n> \"--literal-pathspecs\" elsewhere).\n\nI agree \"--stdin -z\" is a good thing but what makes you think that\nthe producer of the data is _always_ walking the directory hierarchy\nand showing the pathnames it sees? I think use of literal-pathspecs\nshould not be tied to the use of either --stdin or -z.\n"},{"id":"251862","messageId":"20141113213937.GD7563@peff.net","threadId":"37953","inReplyTo":"xmqqa93uzssv.fsf@gitster.dls.corp.google.com","subject":"Re: Git archiving only branch work","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2014-11-13T21:39:38Z","receivedAt":"2014-11-13T21:39:38Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Nov 13, 2014 at 01:36:48PM -0800, Junio C Hamano wrote:\n\n> > I agree it is probably OK in practice and for the OP's question, but it\n> > is nice to have \"-z\" variants so you do not have to worry about quoting\n> > at all. I'd argue that a \"--stdin -z\" should probably also accept raw\n> > filenames, not pathspecs, too (so you do not have to use\n> > \"--literal-pathspecs\" elsewhere).\n> \n> I agree \"--stdin -z\" is a good thing but what makes you think that\n> the producer of the data is _always_ walking the directory hierarchy\n> and showing the pathnames it sees? I think use of literal-pathspecs\n> should not be tied to the use of either --stdin or -z.\n\nI agree they are technically orthogonal, but I cannot think of a case\nwhere I have ever generated actual _pathspecs_, which might have\nwildcards, and needed to use \"-z\". The point of using \"-z\" is that you\ndo not know what crap you are feeding.\n\nNormally I'm in favor of keeping things as flexible as possible, but it\nseems very likely that somebody would forget pathspecs in such a case\n(the OP did in his example, and I know I have many times in the past).\nI don't feel too strongly about it, though.\n\n-Peff\n"},{"id":"251864","messageId":"xmqq61eizs9v.fsf@gitster.dls.corp.google.com","threadId":"37953","inReplyTo":"20141113213937.GD7563@peff.net","subject":"Re: Git archiving only branch work","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-11-13T21:48:12Z","receivedAt":"2014-11-13T21:48:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I agree they are technically orthogonal, but I cannot think of a case\n> where I have ever generated actual _pathspecs_, which might have\n> wildcards, and needed to use \"-z\". The point of using \"-z\" is that you\n> do not know what crap you are feeding.\n\nYou do not have to generate, i.e. you should be allowed to do this:\n\n $ git cmd --stdin -z Jeff King writes:\n> \n> > I agree they are technically orthogonal, but I cannot think of a case\n> > where I have ever generated actual _pathspecs_, which might have\n> > wildcards, and needed to use \"-z\". The point of using \"-z\" is that you\n> > do not know what crap you are feeding.\n> \n> You do not have to generate, i.e. you should be allowed to do this:\n> \n> $ git cmd --stdin -z And this is not about \"flexibility\". Unless your plan is to forbid\n> a corner case you do not anticipate and always disable pathspec\n> globbing, you would need to say something like:\n\nI had just assumed we would forbid, but yeah, you could have a switch to\nhandle either case. That is much nicer to the corner case people.\n\n> Which is awkward. And \"--stdin -z\" is most likely used in scripts;\n> we are not forcing people to keep typing --literal-pathspecs by\n> leaving them orthogonal *and* people do not have to remember one\n> more exception (the default of --literal-pathspecs is flipped only\n> when --stdin -z is in use) to the rule.\n\nIt is not about \"forcing to type\". It is about \"did not realize this was\na potential pitfall and did not write it in the script in the first\nplace\".\n\n-Peff\n"},{"id":"251910","messageId":"xmqq7fyx34hh.fsf@gitster.dls.corp.google.com","threadId":"37953","inReplyTo":"20141114153222.GA23077@peff.net","subject":"Re: Git archiving only branch work","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2014-11-14T20:35:22Z","receivedAt":"2014-11-14T20:35:22Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Thu, Nov 13, 2014 at 01:48:12PM -0800, Junio C Hamano wrote:\n>\n>> Jeff King writes:\n>> \n>> > I agree they are technically orthogonal, but I cannot think of a case\n>> > where I have ever generated actual _pathspecs_, which might have\n>> > wildcards, and needed to use \"-z\". The point of using \"-z\" is that you\n>> > do not know what crap you are feeding.\n>> \n>> You do not have to generate, i.e. you should be allowed to do this:\n>> \n>> $ git cmd --stdin -z \n> Right. My point is that I am not sure anybody ever really _wants_ to do\n> this, versus:\n>\n> git cmd -- \"$pattern1\" \"$pattern2\"\n>\n> Because patterns tend to be small in number and made with predictable\n> characters known to the script writer. It is sets of arbitrary filenames\n> that tend to be long and contain random junk.\n\nPerhaps \"> And this is not about \"flexibility\". Unless your plan is to forbid\n>> a corner case you do not anticipate and always disable pathspec\n>> globbing, you would need to say something like:\n>\n> I had just assumed we would forbid,\n\nThat design is perfectly fine by me, actually.\n\nI somehow hoped that \"--stdin\" is (uniformly across subcommands) a\nmechanism to let us throw the remainder of what we would have liked\nto place on the command line at the command but we couldn't\n(e.g. because we feared that too many of them might overflow the\ncommand line length limit) from the standard input stream instead.\nAs long as you are feeding pathspecs, we should uniformly treat them\nas pathspecs no matter where they come from, either from the command\nline or the standard input stream. Special casing \"--stdin\" with or\nwithout \"-z\" did not make sense to me in that mindset.\n\nBut existing use of \"--stdin\" is not necessarily \"you can feed what\nyou would otherwise place on command line\". \"hash-object --stdin\"\nis not about reading the name of path that contains the data to be\nhashed (the option is \"--stdin-path\" there). \"update-index --stdin\"\nis sort of like that but different, in that the underlying command\ndoes not take pathspec in the first place and it takes a \"list of\npaths\" the same way from it takes them from the command line, which\nmakes it a bad comparison.\n\nSo I think \"git archive --stdin [-z]\" that takes list of paths, not\npathspec, is perfectly fine. \n"}]}