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