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? > 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? 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. cheers, Yves -- perl -Mre=debug -e "/just|another|perl|hacker/" -- 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