{"thread":{"id":"11471","subject":"[PATCH] git stash: one bug and one feature request","startedAt":"2008-01-04T16:14:42Z","lastAt":"2008-01-05T09:06:23Z","messageCount":19,"participants":["Marco Costalba","Brandon Casey","Pascal Obry","Jakub Narebski","Brian Swetland","Jeff King","Junio C Hamano","Wayne Davison"],"isPatch":true,"patchVersion":1,"patchTotal":null},"messages":[{"id":"64440","messageId":"e5bfff550801040814n82f34b2g17c485a207093440@mail.gmail.com","threadId":"11471","inReplyTo":null,"subject":"[PATCH] git stash: one bug and one feature request","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-01-04T16:14:42Z","receivedAt":"2008-01-04T16:14:42Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"Currently git-stash writes to stderr also if there is nothing to error\nout, also it would be very nice ;-) if git 'stash clear command' would\nsupport deleting of only one patch, so as example to write\n\nstg stash clear stash@{0}\n\nTo remove only the last added.\n\n\n------------------ cut --------------------------\n\nFrom: Marco Costalba \nDate: Fri, 4 Jan 2008 17:08:01 +0100\nSubject: [PATCH] git-stash: avoid writing to stderr when is not an error\n\nOtherwise git-stash is unusable by scripts that check\nstderr to detect fail/success of launched command.\n\nSigned-off-by: Marco Costalba \n---\n git-stash.sh | 6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/git-stash.sh b/git-stash.sh\nindex 06cb177..a05a47a 100755\n--- a/git-stash.sh\n+++ b/git-stash.sh\n@@ -86,7 +86,7 @@ save_stash () {\n\n \tif no_changes\n \tthen\n-\t\techo >&2 'No local changes to save'\n+\t\techo > 'No local changes to save'\n \t\texit 0\n \tfi\n \ttest -f \"$GIT_DIR/logs/$ref_stash\" ||\n@@ -99,7 +99,7 @@ save_stash () {\n\n \tgit update-ref -m \"$stash_msg\" $ref_stash $w_commit ||\n \t\tdie \"Cannot save the current status\"\n-\tprintf >&2 'Saved working directory and index state \"%s\"\\n' \"$stash_msg\"\n+\tprintf > 'Saved working directory and index state \"%s\"\\n' \"$stash_msg\"\n }\n\n have_stash () {\n@@ -229,7 +229,7 @@ create)\n \tif test $# -eq 0\n \tthen\n \t\tsave_stash &&\n-\t\techo >&2 '(To restore them type \"git stash apply\")' &&\n+\t\techo > '(To restore them type \"git stash apply\")' &&\n \t\tgit-reset --hard\n \telse\n \t\tusage\n-- \n1.5.4.rc2.18.g530e6\n"},{"id":"64444","messageId":"Pine.LNX.4.64.0801041030420.31161@torch.nrlssc.navy.mil","threadId":"11471","inReplyTo":"e5bfff550801040814n82f34b2g17c485a207093440@mail.gmail.com","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-01-04T16:36:01Z","receivedAt":"2008-01-04T16:36:01Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"On Fri, 4 Jan 2008, Marco Costalba wrote:\n\n> Currently git-stash writes to stderr also if there is nothing to error\n> out, also it would be very nice ;-) if git 'stash clear command' would\n> support deleting of only one patch, so as example to write\n>\n> stg stash clear stash@{0}\n>\n> To remove only the last added.\n\nMaybe it should be named 'drop'. 'drop' sounds better than\n'clear' for this usage.\n\n git stash drop []\n\nNot sure how often such a command would be used though, so\nit may not be worth it.\n\n-brandon\n"},{"id":"64445","messageId":"477E6D26.9020809@obry.net","threadId":"11471","inReplyTo":"Pine.LNX.4.64.0801041030420.31161@torch.nrlssc.navy.mil","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Pascal Obry","fromEmail":"pascal@obry.net","sentAt":"2008-01-04T17:30:14Z","receivedAt":"2008-01-04T17:30:14Z","isPatch":true,"sender":{"key":"pascal@obry.net","avatar":"https://avatars.githubusercontent.com/u/467069?v=4"},"body":"Brandon Casey a écrit :\n> Not sure how often such a command would be used though, so\n> it may not be worth it.\n\nI've missed it many times. Especially in some scripts when I want to use\nthe stash-stack to store current working tree and clear it before\nexiting. This is not possible today as all the stash-stack would be cleared.\n\nI agree that drop seems better.\n\nPascal.\n\n-- \n\n--|------------------------------------------------------\n--| Pascal Obry Team-Ada Member\n--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE\n--|------------------------------------------------------\n--| http://www.obry.net\n--| \"The best way to travel is by means of imagination\"\n--|\n--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595\n"},{"id":"64447","messageId":"m3abnlo4xv.fsf@roke.D-201","threadId":"11471","inReplyTo":"477E6D26.9020809@obry.net","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-01-04T17:51:05Z","receivedAt":"2008-01-04T17:51:05Z","isPatch":true,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Pascal Obry writes:\n> Brandon Casey a écrit :\n> >\n> > Not sure how often such a command would be used though, so\n> > it may not be worth it.\n> \n> I've missed it many times. Especially in some scripts when I want to use\n> the stash-stack to store current working tree and clear it before\n> exiting. This is not possible today as all the stash-stack would be cleared.\n> \n> I agree that drop seems better.\n\nor \"git stash delete\"\n\nThis probably would require the command to delete single reflog,\nwhich was posted some time ago and is in either pu or in offcuts,\nor in next.\n\nBut I guess this is post 1.5.4\n-- \nJakub Narebski\nPoland\nShadeHawk on #git\n"},{"id":"64448","messageId":"477E7439.9090209@nrlssc.navy.mil","threadId":"11471","inReplyTo":"e5bfff550801040944p7f8e722asfa726b34a4a712fa@mail.gmail.com","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-01-04T18:00:25Z","receivedAt":"2008-01-04T18:00:25Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Marco Costalba wrote:\n> Ok, drop is better then clear, but, if we need to add a new command I\n> vote for 'delete' or 'rm' to be consistent with git naming.\n\nIf the stash list is thought of as a stack, then drop makes sense.\n\nI imagine using it like\n\n git stash apply\n git stash drop\n git stash apply stash@{3}\n git stash drop stash@{3}\n\n'git stash delete' and 'git stash rm' when used without arguments\nboth sound like 'git stash clear' to me.\n\n-brandon\n"},{"id":"64449","messageId":"e5bfff550801041005x3ab682dam8535c7bde75038dc@mail.gmail.com","threadId":"11471","inReplyTo":"477E7439.9090209@nrlssc.navy.mil","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-01-04T18:05:35Z","receivedAt":"2008-01-04T18:05:35Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Jan 4, 2008 7:00 PM, Brandon Casey wrote:\n> Marco Costalba wrote:\n> > Ok, drop is better then clear, but, if we need to add a new command I\n> > vote for 'delete' or 'rm' to be consistent with git naming.\n>\n> If the stash list is thought of as a stack, then drop makes sense.\n>\n\nYes, but is _not_ as a stack because you can say\n\ngit stash apply stash@{3}\ngit stash apply stash@{1}\ngit stash apply stash@{4}\n\ni.e. you can access reflogs in any order, so thinking to a stack is\nmisleading IMHO.\n\nMarco\n"},{"id":"64451","messageId":"477E7C3D.8030501@nrlssc.navy.mil","threadId":"11471","inReplyTo":"e5bfff550801041005x3ab682dam8535c7bde75038dc@mail.gmail.com","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Brandon Casey","fromEmail":"casey@nrlssc.navy.mil","sentAt":"2008-01-04T18:34:37Z","receivedAt":"2008-01-04T18:34:37Z","isPatch":true,"sender":{"key":"drafnel@gmail.com","avatar":"https://avatars.githubusercontent.com/u/921167?v=4"},"body":"Marco Costalba wrote:\n> On Jan 4, 2008 7:00 PM, Brandon Casey wrote:\n>> Marco Costalba wrote:\n>>> Ok, drop is better then clear, but, if we need to add a new command I\n>>> vote for 'delete' or 'rm' to be consistent with git naming.\n>> If the stash list is thought of as a stack, then drop makes sense.\n>>\n> \n> Yes, but is _not_ as a stack because you can say\n> \n> git stash apply stash@{3}\n> git stash apply stash@{1}\n> git stash apply stash@{4}\n> \n> i.e. you can access reflogs in any order, so thinking to a stack is\n> misleading IMHO.\n\nI think it is like a stack because new things are always added to the top\nand shift everything else down.\ni.e. we can't say 'git stash replace stash@{3}' and we probably wouldn't\nwant to.\n\nWhen we call git stash, the previous item on 'top' is pushed down\nso that it is the second item stash@{1}. The new item just stashed\n(pushed), is now on top at stash@{0}.\n\nDoesn't seem like too far of a stretch.\n\n-brandon\n"},{"id":"64454","messageId":"e5bfff550801041046p534b4869l2919494a8e4ef711@mail.gmail.com","threadId":"11471","inReplyTo":"477E7C3D.8030501@nrlssc.navy.mil","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-01-04T18:46:51Z","receivedAt":"2008-01-04T18:46:51Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Jan 4, 2008 7:34 PM, Brandon Casey wrote:\n>\n> Doesn't seem like too far of a stretch.\n>\n\nI'm very bad at naming, so I don't argue any more.\n\nJust one thing (that is the only that matters) call this command as\nyou want but let it take one argument, the name of the reflog to\nremove:\n\ngit stash drop stash@{3}\n\nshould be allowed.\n\ngit stash drop\n\ndefaults to stash@{0}\n\nThanks\nMarco\n"},{"id":"64457","messageId":"20080104193630.GA26843@bulgaria.corp.google.com","threadId":"11471","inReplyTo":"m3abnlo4xv.fsf@roke.D-201","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Brian Swetland","fromEmail":"swetland@google.com","sentAt":"2008-01-04T19:36:30Z","receivedAt":"2008-01-04T19:36:30Z","isPatch":true,"sender":{"key":"swetland@google.com","avatar":"https://gravatar.com/avatar/b26b7c772097c55d8febb0fc027dd2ef577a05994a321819f49ab3c9153ac8b1?d=mp&s=160"},"body":"[Jakub Narebski ]\n> Pascal Obry writes:\n> > Brandon Casey a écrit :\n> > >\n> > > Not sure how often such a command would be used though, so\n> > > it may not be worth it.\n> > \n> > I've missed it many times. Especially in some scripts when I want to use\n> > the stash-stack to store current working tree and clear it before\n> > exiting. This is not possible today as all the stash-stack would be cleared.\n> > \n> > I agree that drop seems better.\n> \n> or \"git stash delete\"\n\nSomething like drop or delete would be nice.\n\nI tried to \"clear\" a single stash once. Oops!\n\nIs there a reason that git stash apply couldn't take a small integer\nas the argument (at least as an alternative) instead of stash@{0}, etc?\n\nBrian\n"},{"id":"64466","messageId":"20080104210408.GA26248@coredump.intra.peff.net","threadId":"11471","inReplyTo":"m3abnlo4xv.fsf@roke.D-201","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-01-04T21:04:08Z","receivedAt":"2008-01-04T21:04:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jan 04, 2008 at 09:51:05AM -0800, Jakub Narebski wrote:\n\n> or \"git stash delete\"\n> \n> This probably would require the command to delete single reflog,\n> which was posted some time ago and is in either pu or in offcuts,\n> or in next.\n> \n> But I guess this is post 1.5.4\n\nThere is a \"git reflog delete\" in next (but not in master). See\n552cecc2. Using the same name makes sense, since they are equivalent\nactions (and \"git stash delete\" should be very easy, since it is\nimplemented in terms of reflogs).\n\n-Peff\n"},{"id":"64480","messageId":"7vy7b5glmr.fsf@gitster.siamese.dyndns.org","threadId":"11471","inReplyTo":"e5bfff550801040814n82f34b2g17c485a207093440@mail.gmail.com","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-05T00:29:48Z","receivedAt":"2008-01-05T00:29:48Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> Otherwise git-stash is unusable by scripts that check\n> stderr to detect fail/success of launched command.\n\nSorry, but I happen to disagree with your notion of \"having\nsomething on stderr is an error\" to begin with. I think scripts\nwritten that way are either simply bogus, or are working around\na defect in the underlying command it calls (perhaps it does not\nsignal error with exit status properly).\n\nA command that produces machine parsable output should write\nthat out to stdout, and if it needs to emit other informational\nmessages meant for human consumption (this includes progress\nbars), that should be sent to stderr so that scripts can get the\nmeat of the output without having to filter cruft out.\n\nIf the command does not signal an error by exiting with non-zero\nstatus, that would be a bug indeed and you can fix that instead,\nI think.\n"},{"id":"64481","messageId":"7vtzltglje.fsf@gitster.siamese.dyndns.org","threadId":"11471","inReplyTo":"e5bfff550801041046p534b4869l2919494a8e4ef711@mail.gmail.com","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-05T00:31:49Z","receivedAt":"2008-01-05T00:31:49Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> I'm very bad at naming, so I don't argue any more.\n>\n> Just one thing (that is the only that matters) call this command as\n> you want but let it take one argument, the name of the reflog to\n> remove:\n>\n> git stash drop stash@{3}\n>\n> should be allowed.\n>\n> git stash drop\n>\n> defaults to stash@{0}\n\nI do not care the wording either way, but my prediction is that\npeople will mistype \"stash clear\" when they meant \"stash drop\",\nand we will end up not allowing the implicit \"drop the top one\nonly\" behaviour.\n"},{"id":"64502","messageId":"20080105064156.GA6954@blorf.net","threadId":"11471","inReplyTo":"e5bfff550801040814n82f34b2g17c485a207093440@mail.gmail.com","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Wayne Davison","fromEmail":"wayne@opencoder.net","sentAt":"2008-01-05T06:41:56Z","receivedAt":"2008-01-05T06:41:56Z","isPatch":true,"sender":{"key":"wayne@opencoder.net","avatar":"https://gravatar.com/avatar/d55d81825271b1bfe65e57e4e04297d4119aa03c6a1c71d2ff2812b9b4be9f45?d=mp&s=160"},"body":"On Fri, Jan 04, 2008 at 05:14:42PM +0100, Marco Costalba wrote:\n> -\t\techo >&2 'No local changes to save'\n> +\t\techo > 'No local changes to save'\n\nThat change and the other two following it each put a newline in a\nstrangely named file. You should just drop the >&2 altogether if you\nwant the output to go to stdout.\n\n..wayne..\n"},{"id":"64505","messageId":"7vzlvkepd5.fsf@gitster.siamese.dyndns.org","threadId":"11471","inReplyTo":"20080105064156.GA6954@blorf.net","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-05T06:52:06Z","receivedAt":"2008-01-05T06:52:06Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Wayne Davison writes:\n\n> On Fri, Jan 04, 2008 at 05:14:42PM +0100, Marco Costalba wrote:\n>> -\t\techo >&2 'No local changes to save'\n>> +\t\techo > 'No local changes to save'\n>\n> That change and the other two following it each put a newline in a\n> strangely named file. You should just drop the >&2 altogether if you\n> want the output to go to stdout.\n\nLol... Good eyes. I did not even notice it ;-).\n\nThanks.\n"},{"id":"64510","messageId":"e5bfff550801050025g6758bfb6p751e69e93d4299be@mail.gmail.com","threadId":"11471","inReplyTo":"7vy7b5glmr.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-01-05T08:25:59Z","receivedAt":"2008-01-05T08:25:59Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Jan 5, 2008 1:29 AM, Junio C Hamano wrote:\n> \"Marco Costalba\" writes:\n>\n> > Otherwise git-stash is unusable by scripts that check\n> > stderr to detect fail/success of launched command.\n>\n> Sorry, but I happen to disagree with your notion of \"having\n> something on stderr is an error\" to begin with. I think scripts\n> written that way are either simply bogus, or are working around\n> a defect in the underlying command it calls (perhaps it does not\n> signal error with exit status properly).\n>\n\nI understand your point. The problem is that in git there isn't an\nunique way to test success/fail for any command, as example, regarding\nchecking the exit status:\n\n$ git status; echo $?\n# On branch master\nnothing to commit (working directory clean)\n1\n\n\nYou get a value different from zero also in case of no error. The\nchecking for stderr I have found is more reliable for the git\ncommand/scripts I use.\n\n> A command that produces machine parsable output should write\n> that out to stdout, and if it needs to emit other informational\n> messages meant for human consumption (this includes progress\n> bars), that should be sent to stderr so that scripts can get the\n> meat of the output without having to filter cruft out.\n>\n\nI agree with this, but I fail to see the machine parsable output and\nhuman consumption sideband info in case of git-stash that I would say\ndoes not foreseen machine parsable output at all, so in this case\nchoice of writing to stderr is less clear to me.\n\n> If the command does not signal an error by exiting with non-zero\n> status, that would be a bug indeed and you can fix that instead,\n> I think.\n>\n\nIf we don't want to have general rule for exit status and stderr at\nleast we could add a -q option to git stash, altough I would prefer\ngit stash writing on stdout if is not an error.\n\nPlease let me explain again why I need a reliable way to detect\nsuccess/fail of a command. When a function wants to execute a git\ncommand it passes a string with the command + arguments to a low level\nroutine, say run(), that is command agnostic. This run() function\nadapts and formats the command line according to the OS environment\nthen runs the command, saves the results and check for an error, the\nresult buffer is then passed as is to the caller that has the semantic\nknowledge of what the command have produced.\n\nThis low level run() should know nothing about the semantic of the\ncommand or the outputted data, but should detect command failing,\nbecause failing reporting framework is unified and is the same for\neach type of command.\n\nA good and reliable way is to check for stderr, because it happens to\nbe more reliable then exit codes.\n\nPlease note that also gitk uses the same approach, indeed from\nhttp://ftp.tcl.tk/man/tcl8.5/tutorial/Tcl26.html you can read:\n\n--------------------\n\nThe 'exec' treats any output to standard error to be an indication\nthat the external program failed. This is simply a conservative\nassumption: many programs behave that way and they are sloppy in\nsetting return codes.\n\nSome programs however write to standard error without intending this\nas an indication of an error. You can guard against this from\nupsetting your script by using the catch command:\n\nif { [catch { exec ls *.tcl } msg] } {\n puts \"Something seems to have gone wrong but we will ignore it\"\n}\n\n-------------------------\n\nIndeed in gitk you find something like\n\n # Unfortunately git-cherry-pick writes stuff to stderr even when\n # no error occurs, and exec takes that as an indication of error...\n if {[catch {exec sh -c \"git cherry-pick -r $rowmenuid 2>&1\"} err]} {\n\tnotbusy cherrypick\n\terror_popup $err\n\treturn\n }\n\n\n\nI can also black list not commonly behaving programs, but in case of\ngit-stash a fail to see why to choose a not standard behaviour when\nnot needed.\n\n\nThanks\nMarco\n"},{"id":"64511","messageId":"e5bfff550801050031g17e0217dueaed3ad3a53ddee8@mail.gmail.com","threadId":"11471","inReplyTo":"7vzlvkepd5.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-01-05T08:31:50Z","receivedAt":"2008-01-05T08:31:50Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Jan 5, 2008 7:52 AM, Junio C Hamano wrote:\n>\n> Wayne Davison writes:\n>\n> > On Fri, Jan 04, 2008 at 05:14:42PM +0100, Marco Costalba wrote:\n> >> - echo >&2 'No local changes to save'\n> >> + echo > 'No local changes to save'\n> >\n> > That change and the other two following it each put a newline in a\n> > strangely named file. You should just drop the >&2 altogether if you\n> > want the output to go to stdout.\n>\n> Lol... Good eyes. I did not even notice it ;-).\n>\n\nVery sorry for this, I should have been more careful. Please let me\nknow if you want me to resend the patch.\n\nMarco\n"},{"id":"64512","messageId":"7vbq80d5yp.fsf@gitster.siamese.dyndns.org","threadId":"11471","inReplyTo":"e5bfff550801050025g6758bfb6p751e69e93d4299be@mail.gmail.com","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-05T08:36:30Z","receivedAt":"2008-01-05T08:36:30Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> This low level run() should know nothing about the semantic of the\n> command or the outputted data, but should detect command failing,\n> because failing reporting framework is unified and is the same for\n> each type of command.\n\nThat sounds like a framework generalized in a wrong way to me.\n\n> Please note that also gitk uses the same approach, indeed from\n> http://ftp.tcl.tk/man/tcl8.5/tutorial/Tcl26.html you can read:\n> ...\n\nHeh, as if tcl is a textbook of good programming style.\n\n> I can also black list not commonly behaving programs, but in case of\n> git-stash a fail to see why to choose a not standard behaviour when\n> not needed.\n\nI do not offhand see a reason it would _hurt_ for this\nparticular case (git-stash) to write the diagnostics we\ncurrently spit out to stderr to stdout. My objection is\nprimarily because I do not think \"never writing to stderr if\nthere is no error\" is standard behaviour AT ALL.\n\nIOW, I do have much less objections to what your patch actually\ndoes, than I have problems with the way the reason for the\nchange is stated. The change is not fixing anything to conform\nto some standard behaviour. It is more about bending\n(admittedly only slightly) backwards to help broken callers.\nThat is what I have most trouble with.\n"},{"id":"64515","messageId":"e5bfff550801050057v485a7491qa8997b5b9c3b0f60@mail.gmail.com","threadId":"11471","inReplyTo":"7vbq80d5yp.fsf@gitster.siamese.dyndns.org","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Marco Costalba","fromEmail":"mcostalba@gmail.com","sentAt":"2008-01-05T08:57:24Z","receivedAt":"2008-01-05T08:57:24Z","isPatch":true,"sender":{"key":"mcostalba@gmail.com","avatar":null},"body":"On Jan 5, 2008 9:36 AM, Junio C Hamano wrote:\n>\n> IOW, I do have much less objections to what your patch actually\n> does, than I have problems with the way the reason for the\n> change is stated. The change is not fixing anything to conform\n> to some standard behaviour. It is more about bending\n> (admittedly only slightly) backwards to help broken callers.\n> That is what I have most trouble with.\n>\n>\n\nThanks for your understanding.\n\n--------------------- CUT -----------------------------------\n\nSubject: [PATCH] git-stash: use stdout instead of stderr for not error messages\n\nSome scripts/libraries commonly check stderr to detect a\nfailing command. This is not standard nor good behaviour but\nis quite common and in this case the change does not seem to hurt.\n\nSigned-off-by: Marco Costalba \n---\n git-stash.sh | 6 +++---\n 1 files changed, 3 insertions(+), 3 deletions(-)\n\ndiff --git a/git-stash.sh b/git-stash.sh\nindex 06cb177..4d5e5c0 100755\n--- a/git-stash.sh\n+++ b/git-stash.sh\n@@ -86,7 +86,7 @@ save_stash () {\n\n \tif no_changes\n \tthen\n-\t\techo >&2 'No local changes to save'\n+\t\techo 'No local changes to save'\n \t\texit 0\n \tfi\n \ttest -f \"$GIT_DIR/logs/$ref_stash\" ||\n@@ -99,7 +99,7 @@ save_stash () {\n\n \tgit update-ref -m \"$stash_msg\" $ref_stash $w_commit ||\n \t\tdie \"Cannot save the current status\"\n-\tprintf >&2 'Saved working directory and index state \"%s\"\\n' \"$stash_msg\"\n+\tprintf 'Saved working directory and index state \"%s\"\\n' \"$stash_msg\"\n }\n\n have_stash () {\n@@ -229,7 +229,7 @@ create)\n \tif test $# -eq 0\n \tthen\n \t\tsave_stash &&\n-\t\techo >&2 '(To restore them type \"git stash apply\")' &&\n+\t\techo '(To restore them type \"git stash apply\")' &&\n \t\tgit-reset --hard\n \telse\n \t\tusage\n-- \n1.5.4.rc2.18.g530e6-dirty\n"},{"id":"64516","messageId":"7v7iiod4kw.fsf@gitster.siamese.dyndns.org","threadId":"11471","inReplyTo":"e5bfff550801050025g6758bfb6p751e69e93d4299be@mail.gmail.com","subject":"Re: [PATCH] git stash: one bug and one feature request","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-05T09:06:23Z","receivedAt":"2008-01-05T09:06:23Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Marco Costalba\" writes:\n\n> I understand your point. The problem is that in git there isn't an\n> unique way to test success/fail for any command, as example, regarding\n> checking the exit status:\n>\n> $ git status; echo $?\n> # On branch master\n> nothing to commit (working directory clean)\n> 1\n\nThat is a bad example, with a slight historical background.\n\nWhen you say \"git status $args\", you are asking the command this\nquestion.\n\n\tI am contemplating to issue \"git commit $args\", but will\n\tthere actually be changes if I issued that command?\n\nWhen there will be no changes staged with the given $args (in\nyour case that happens to be empty), there won't be anything to\nbe committed if you issued \"git commit $args\" at that point.\nThe command answers \"Eh, by issuing 'git commit' you will get\nan 'Nothing to commit', which is an error\" --- and that is\nreported with its exit status.\n"}]}