John Tapsell <johnflux@xxxxxxxxx> writes: > 2009/9/10 Jakub Narebski <jnareb@xxxxxxxxx>: >> Dnia czwartek 10. września 2009 21:46, John Tapsell napisał: >>> 2009/9/10 Jakub Narebski <jnareb@xxxxxxxxx>: >> >>> > First, it would be consistent with how ordinary archivers such as tar >>> > or zip are used, where you have to specify list of files to archive >>> > (in our case this list is HEAD). Second, I'd rather not accidentally >>> > dump binary to terminal: "git archive [HEAD]" dumps archive to standard >>> > output. >>> >>> That could be fixed by outputting to a file. git format-patch outputs >>> to a file, so why wouldn't git achieve? >> >> "git format-patch" outputs to files because it generates _multiple_ >> files; generating single patch is special case. Also git-format-patch >> can generate file names from patch (commit) subject; it is not the case >> for "git archive" (what name should it use?). > > What if it used the current (or topleve) directory name? Wouldn't > that work in most cases? Following along the same line of reasoning, it would work in most cases if the output is literally named "archive.tar". If it is not the name the user wants, the user can "mv" afterwards, or give an explicit filename. What it does _not_ allow is to send the output to a downstream command for postprocessing without introducing some magic token to say "standard output" (e.g. "git archive -f - | (cd ../foo && tar xf -)"). If the default is to write to the standard output, we won't have all of these issues. People who want a file can name the file by git archive >my.file.tar and people who want to pipe (which is 99% of the use pattern for me) can say git archive | down stream commands. Oh, wait. That is exactly what we have, so what's the point of continuing this discussion any further? Can we just stop? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html