demerphq <demerphq@xxxxxxxxx> writes: > 2009/9/11 Junio C Hamano <gitster@xxxxxxxxx>: >> 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. > > Why not $sha1.tar? Why not $(basename $(dirname $(pwd)))-$(date).tar instead? See? archive.tar is as good a compromise (so is a.out from cc). > Is it portable to assume that piping is always in binmode? From a > portability POV i could imagine piping being a problem in this > respect, and might be why tar provides a way to output to a file and > not just to a handle. For example ISTR that on windows piping is by > default in text mode. I think its not a showstopper there as you can > change it, but still, from a portability point of view you might not > want to depend on piping. Windows is not a showstopper to me ;-). But seriously, I am glad that you brought up about a potential issue with pipe. There is one fairly important reason that it is better to say GZIP=-9 tar zcf here.tar.gz . than to say tar cf - . | gzip -9 >here.tar.gz but it has nothing to do with binmode. The reason is error detection. For exactly the same reason, if we can say git archive -9 --output-file=here.tar.gz HEAD it is much better than having to say git archive HEAD | gzip -9 >here.tar.gz In other words, I am not opposed to supporting a "--output-file here.tar" at all. I just do not want it to be mandatory. I think that it is an ugly kludge to force people to work it around with "-f /dev/stdout". Oh wait. That is exactly what we have, so what's the point of continuing this discussion any further? Can we just _really_ stop this time, please? -- 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