Re: obnoxious CLI complaints
- From
- demerphq <demerphq@gmail.com>
- Date
- Sep 10, 2009, 23:19 UTC
- Message-ID
- <9b18b3110909101619n6904a75dm10dd0b5717fb0d76@mail.gmail.com>
- In-Reply-To
- <7v4ora76vr.fsf@alter.siamese.dyndns.org>
2009/9/11 Junio C Hamano <gitster@pobox.com>:
Show 26 quoted lines
> John Tapsell <johnflux@gmail.com> writes: > >> 2009/9/10 Jakub Narebski <jnareb@gmail.com>: >>> Dnia czwartek 10. września 2009 21:46, John Tapsell napisał: >>>> 2009/9/10 Jakub Narebski <jnareb@gmail.com>: >>> >>>> > 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?
Show 18 quoted lines
> 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/"