{"thread":{"id":"24046","subject":"Git sideband hook output","startedAt":"2010-06-08T20:32:37Z","lastAt":"2010-06-12T04:07:17Z","messageCount":17,"participants":["Scott Chacon","Shawn O. Pearce","Johannes Sixt","Peter Kjellerstedt","Nicolas Pitre","PJ Hyett","Wincent Colaiuta","Erik Faye-Lund","Ævar Arnfjörð Bjarmason","A Large Angry SCM","Junio C Hamano","Jeff King"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"143272","messageId":"AANLkTinLWDFTn7bhcF3Vk-q9aw4lJC2vFj95M9bxLbBT@mail.gmail.com","threadId":"24046","inReplyTo":null,"subject":"Git sideband hook output","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2010-06-08T20:32:37Z","receivedAt":"2010-06-08T20:32:37Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Prior to 6d525d where Shawn made the receive-pack process send hook\noutput over side band #2, how did the hook output get sent to the\nclient?  On older clients (before this commit) and on older servers,\nthe hook output just shows up without the 'remote:' prefix.  After\nthis commit I get the 'remote:' prefix, which is kind of annoying.  Is\nthere a way to suppress this to get the old output format?  Or a\nrecommended way of patching the client/server in future versions to\nget the old format back?\n\nThanks,\nScott\n"},{"id":"143285","messageId":"20100608214632.GN14847@spearce.org","threadId":"24046","inReplyTo":"AANLkTinLWDFTn7bhcF3Vk-q9aw4lJC2vFj95M9bxLbBT@mail.gmail.com","subject":"Re: Git sideband hook output","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-06-08T21:46:32Z","receivedAt":"2010-06-08T21:46:32Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Scott Chacon <schacon@gmail.com> wrote:\n> Prior to 6d525d where Shawn made the receive-pack process send hook\n> output over side band #2, how did the hook output get sent to the\n> client?\n\nIt was sent over stderr, which was proxied down to the client by\nthe SSH daemon.\n\n> On older clients (before this commit) and on older servers,\n> the hook output just shows up without the 'remote:' prefix.\n\nBecause its echoed to the tty by the SSH client, without Git ever\nseeing it.\n\n> After\n> this commit I get the 'remote:' prefix,\n\nNow its being parsed out of the stream by the git client, using\nthe same code that displays the progress messages during clone/fetch.\n\n> which is kind of annoying.\n\nDepends on your perspective.  Its nice to know that the messages\ncame from the server, rather than from your client.  :-)\n\n> Is\n> there a way to suppress this to get the old output format?\n\nNo.  Other than to have the hook not output anything at all.\n\n-- \nShawn.\n"},{"id":"143304","messageId":"4C0F3067.9090501@viscovery.net","threadId":"24046","inReplyTo":"AANLkTinLWDFTn7bhcF3Vk-q9aw4lJC2vFj95M9bxLbBT@mail.gmail.com","subject":"Re: Git sideband hook output","fromName":"Johannes Sixt","fromEmail":"j.sixt@viscovery.net","sentAt":"2010-06-09T06:10:47Z","receivedAt":"2010-06-09T06:10:47Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"Am 6/8/2010 22:32, schrieb Scott Chacon:\n> Prior to 6d525d where Shawn made the receive-pack process send hook\n> output over side band #2, how did the hook output get sent to the\n> client?  On older clients (before this commit) and on older servers,\n> the hook output just shows up without the 'remote:' prefix.  After\n> this commit I get the 'remote:' prefix, which is kind of annoying.  Is\n> there a way to suppress this to get the old output format?  Or a\n> recommended way of patching the client/server in future versions to\n> get the old format back?\n\nWhat happens if your git-receive-pack does not announce side-band-64k?\n\n-- Hannes\n"},{"id":"143313","messageId":"A612847CFE53224C91B23E3A5B48BAC744839BF3DD@xmail3.se.axis.com","threadId":"24046","inReplyTo":"20100608214632.GN14847@spearce.org","subject":"RE: Git sideband hook output","fromName":"Peter Kjellerstedt","fromEmail":"peter.kjellerstedt@axis.com","sentAt":"2010-06-09T08:04:59Z","receivedAt":"2010-06-09T08:04:59Z","isPatch":false,"sender":{"key":"peter.kjellerstedt@axis.com","avatar":"https://gravatar.com/avatar/6d5a0182283c8eccd7b134a54dbfd5f30038f3ad4d38b96f424884b614a61ca2?d=mp&s=160"},"body":"> -----Original Message-----\n> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On\n> Behalf Of Shawn O. Pearce\n> Sent: den 8 juni 2010 23:47\n> To: Scott Chacon\n> Cc: git list\n> Subject: Re: Git sideband hook output\n> \n> Scott Chacon <schacon@gmail.com> wrote:\n> > Prior to 6d525d where Shawn made the receive-pack process send hook\n> > output over side band #2, how did the hook output get sent to the\n> > client?\n> \n> It was sent over stderr, which was proxied down to the client by\n> the SSH daemon.\n> \n> > On older clients (before this commit) and on older servers,\n> > the hook output just shows up without the 'remote:' prefix.\n> \n> Because its echoed to the tty by the SSH client, without Git ever\n> seeing it.\n> \n> > After\n> > this commit I get the 'remote:' prefix,\n\nThis explains the messy output from hooks I have seen since \nupdating to 1.7.1...\n\n> Now its being parsed out of the stream by the git client, using\n> the same code that displays the progress messages during clone/fetch.\n> \n> > which is kind of annoying.\n> \n> Depends on your perspective.  Its nice to know that the messages\n> came from the server, rather than from your client.  :-)\n\nAnd it is very annoying that the output format has suddenly changed\nso that the output from hooks that rely on the previous no-prefix\nformat no longer fit on an 80 char wide terminal where they used to\nfit just fine.\n\n> > Is\n> > there a way to suppress this to get the old output format?\n> \n> No.  Other than to have the hook not output anything at all.\n> \n> --\n> Shawn.\n\nHere is +1 for giving us back the no-prefix output. I would like\nto suggest adding a configuration option to allow users to enable \nthe \"remote: \" prefix if they want it.\n\n//Peter\n"},{"id":"143340","messageId":"alpine.LFD.2.00.1006090934320.30664@xanadu.home","threadId":"24046","inReplyTo":"A612847CFE53224C91B23E3A5B48BAC744839BF3DD@xmail3.se.axis.com","subject":"RE: Git sideband hook output","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-06-09T13:44:13Z","receivedAt":"2010-06-09T13:44:13Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Wed, 9 Jun 2010, Peter Kjellerstedt wrote:\n\n> > -----Original Message-----\n> > From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On\n> > Behalf Of Shawn O. Pearce\n> > Sent: den 8 juni 2010 23:47\n> > To: Scott Chacon\n> > Cc: git list\n> > Subject: Re: Git sideband hook output\n> > \n> > Scott Chacon <schacon@gmail.com> wrote:\n> > > Prior to 6d525d where Shawn made the receive-pack process send hook\n> > > output over side band #2, how did the hook output get sent to the\n> > > client?\n> > \n> > It was sent over stderr, which was proxied down to the client by\n> > the SSH daemon.\n> > \n> > > On older clients (before this commit) and on older servers,\n> > > the hook output just shows up without the 'remote:' prefix.\n> > \n> > Because its echoed to the tty by the SSH client, without Git ever\n> > seeing it.\n> > \n> > > After\n> > > this commit I get the 'remote:' prefix,\n> \n> This explains the messy output from hooks I have seen since \n> updating to 1.7.1...\n> \n> > Now its being parsed out of the stream by the git client, using\n> > the same code that displays the progress messages during clone/fetch.\n> > \n> > > which is kind of annoying.\n> > \n> > Depends on your perspective.  Its nice to know that the messages\n> > came from the server, rather than from your client.  :-)\n> \n> And it is very annoying that the output format has suddenly changed\n> so that the output from hooks that rely on the previous no-prefix\n> format no longer fit on an 80 char wide terminal where they used to\n> fit just fine.\n\nFix your hook output then.\n\n> > > Is\n> > > there a way to suppress this to get the old output format?\n> > \n> > No.  Other than to have the hook not output anything at all.\n> > \n> > --\n> > Shawn.\n> \n> Here is +1 for giving us back the no-prefix output. I would like\n> to suggest adding a configuration option to allow users to enable \n> the \"remote: \" prefix if they want it.\n\nWould be much more logical to fix the hook output, and keep hook \ndevelopers honnest by not confusing the user with output that isn't \nlocal stuff.\n\n-1\n\n\nNicolas\n"},{"id":"143426","messageId":"A612847CFE53224C91B23E3A5B48BAC744839BF6AE@xmail3.se.axis.com","threadId":"24046","inReplyTo":"alpine.LFD.2.00.1006090934320.30664@xanadu.home","subject":"RE: Git sideband hook output","fromName":"Peter Kjellerstedt","fromEmail":"peter.kjellerstedt@axis.com","sentAt":"2010-06-10T12:56:37Z","receivedAt":"2010-06-10T12:56:37Z","isPatch":false,"sender":{"key":"peter.kjellerstedt@axis.com","avatar":"https://gravatar.com/avatar/6d5a0182283c8eccd7b134a54dbfd5f30038f3ad4d38b96f424884b614a61ca2?d=mp&s=160"},"body":"> -----Original Message-----\n> From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org] On\n> Behalf Of Nicolas Pitre\n> Sent: den 9 juni 2010 15:44\n> To: Peter Kjellerstedt\n> Cc: Shawn O. Pearce; Scott Chacon; git list\n> Subject: RE: Git sideband hook output\n> \n> On Wed, 9 Jun 2010, Peter Kjellerstedt wrote:\n> \n> > > -----Original Message-----\n> > > From: git-owner@vger.kernel.org [mailto:git-owner@vger.kernel.org]\n> > > On Behalf Of Shawn O. Pearce\n> > > Sent: den 8 juni 2010 23:47\n> > > To: Scott Chacon\n> > > Cc: git list\n> > > Subject: Re: Git sideband hook output\n> > >\n> > > Scott Chacon <schacon@gmail.com> wrote:\n> > > > Prior to 6d525d where Shawn made the receive-pack process send\n> > > > hook output over side band #2, how did the hook output get \n> > > > sent to the client?\n> > >\n> > > It was sent over stderr, which was proxied down to the client by\n> > > the SSH daemon.\n> > >\n> > > > On older clients (before this commit) and on older servers,\n> > > > the hook output just shows up without the 'remote:' prefix.\n> > >\n> > > Because its echoed to the tty by the SSH client, without Git ever\n> > > seeing it.\n> > >\n> > > > After\n> > > > this commit I get the 'remote:' prefix,\n> >\n> > This explains the messy output from hooks I have seen since\n> > updating to 1.7.1...\n> >\n> > > Now its being parsed out of the stream by the git client, using\n> > > the same code that displays the progress messages during\n> > > clone/fetch.\n> > >\n> > > > which is kind of annoying.\n> > >\n> > > Depends on your perspective.  Its nice to know that the messages\n> > > came from the server, rather than from your client.  :-)\n> >\n> > And it is very annoying that the output format has suddenly changed\n> > so that the output from hooks that rely on the previous no-prefix\n> > format no longer fit on an 80 char wide terminal where they used to\n> > fit just fine.\n> \n> Fix your hook output then.\n\nI can do that for our hooks, but all may not have that option.\n\n> > > > Is\n> > > > there a way to suppress this to get the old output format?\n> > >\n> > > No.  Other than to have the hook not output anything at all.\n> > >\n> > > --\n> > > Shawn.\n> >\n> > Here is +1 for giving us back the no-prefix output. I would like\n> > to suggest adding a configuration option to allow users to enable\n> > the \"remote: \" prefix if they want it.\n> \n> Would be much more logical to fix the hook output, and keep hook\n> developers honnest by not confusing the user with output that isn't\n> local stuff.\n\nWhy should the user care whether the output is generated locally \nor remotely? Shouldn't you prefix local hook output then as well\nto separate it from the output of the git commands themselves \n(and no, I am not suggesting this is added)?\n\n> -1\n> \n> \n> Nicolas\n\nAs I see it this change has taken away a little bit of freedom.\nPreviously I (as a hook writer) could choose to add a prefix like \n\"remote:\" to my hook if I wanted to, to make it more obvious that the\noutput came from the remote server, _or_ I could choose not to and \nhave a standardized output that looked the same regardless of whether\nit was a local hook or a remote one that complained about the \nformatting of a commit message. Now I no longer have that option.\n\nAnd what if my hook output is localized? Now there is an English\n\"remote:\" in front of every line... Or even worse, what if the\n\"remote:\" string is localized in a future version of git, then I \nhave no way of knowing how wide it is and cannot take measures to \nformat my hook output so that it will look right.\n\n//Peter\n"},{"id":"143460","messageId":"alpine.LFD.2.00.1006101344150.30664@xanadu.home","threadId":"24046","inReplyTo":"A612847CFE53224C91B23E3A5B48BAC744839BF6AE@xmail3.se.axis.com","subject":"RE: Git sideband hook output","fromName":"Nicolas Pitre","fromEmail":"nico@fluxnic.net","sentAt":"2010-06-10T18:05:23Z","receivedAt":"2010-06-10T18:05:23Z","isPatch":false,"sender":{"key":"nico@fluxnic.net","avatar":"https://avatars.githubusercontent.com/u/702790?v=4"},"body":"On Thu, 10 Jun 2010, Peter Kjellerstedt wrote:\n\n> Behalf Of Nicolas Pitre\n> > On Wed, 9 Jun 2010, Peter Kjellerstedt wrote:\n> > \n> > > And it is very annoying that the output format has suddenly changed\n> > > so that the output from hooks that rely on the previous no-prefix\n> > > format no longer fit on an 80 char wide terminal where they used to\n> > > fit just fine.\n> > \n> > Fix your hook output then.\n> \n> I can do that for our hooks, but all may not have that option.\n\nWhy not?  If that's a real impossibility then people can enlarge their \nterminal window.  No one mandated that the git commands have to be run \nin a 80x25 terminal to work anyway.\n\n> > > > > Is\n> > > > > there a way to suppress this to get the old output format?\n> > > >\n> > > > No.  Other than to have the hook not output anything at all.\n> > > >\n> > > > --\n> > > > Shawn.\n> > >\n> > > Here is +1 for giving us back the no-prefix output. I would like\n> > > to suggest adding a configuration option to allow users to enable\n> > > the \"remote: \" prefix if they want it.\n> > \n> > Would be much more logical to fix the hook output, and keep hook\n> > developers honnest by not confusing the user with output that isn't\n> > local stuff.\n> \n> Why should the user care whether the output is generated locally \n> or remotely?\n\nThink about things like \"out of disk space\", or \"access permission \ndenied\", or \"repository corrupted\", etc.  You really want to know if \nthose are local or remote.\n\n> Shouldn't you prefix local hook output then as well\n> to separate it from the output of the git commands themselves \n> (and no, I am not suggesting this is added)?\n\nI don't see this being as relevant.  It is way far more confusing if a \nremote message can be confused with a local one.\n\n> As I see it this change has taken away a little bit of freedom.\n> Previously I (as a hook writer) could choose to add a prefix like \n> \"remote:\" to my hook if I wanted to, to make it more obvious that the\n> output came from the remote server, _or_ I could choose not to and \n> have a standardized output that looked the same regardless of whether\n> it was a local hook or a remote one that complained about the \n> formatting of a commit message. Now I no longer have that option.\n\nPreviously you even didn't have the option of generating messages to be \ndisplayed on the client's console at all.  If that happened to work with \nSSH that was by pure accident, and causing lots of confusion as remote \nerrors were displayed like local ones.  If you tried to push using the \nnative Git transport, or the smart HTTP transport, then you would have \ngot nothing at all as the hook output was simply dropped on the floor.  \nNow this has been fixed, and remote messages are formalized with a \n\"remote:\" prefix.\n\n> And what if my hook output is localized? Now there is an English\n> \"remote:\" in front of every line... Or even worse, what if the\n> \"remote:\" string is localized in a future version of git, then I \n> have no way of knowing how wide it is and cannot take measures to \n> format my hook output so that it will look right.\n\nJust don't assume anything about the remote terminal size, because you \nactually don't know what the remote terminal size is.  If you *really* \nneed to know that information, then the best solution is to create a \nprotocol capability for that with the screen width encoded in it, minus \nthe \"remote\" prefix of course.\n\n\nNicolas\n"},{"id":"143466","messageId":"20100610183019.GR14847@spearce.org","threadId":"24046","inReplyTo":"A612847CFE53224C91B23E3A5B48BAC744839BF6AE@xmail3.se.axis.com","subject":"Re: Git sideband hook output","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2010-06-10T18:30:19Z","receivedAt":"2010-06-10T18:30:19Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Peter Kjellerstedt <peter.kjellerstedt@axis.com> wrote:\n> > \n> > Would be much more logical to fix the hook output, and keep hook\n> > developers honnest by not confusing the user with output that isn't\n> > local stuff.\n> \n> Why should the user care whether the output is generated locally \n> or remotely? Shouldn't you prefix local hook output then as well\n> to separate it from the output of the git commands themselves \n> (and no, I am not suggesting this is added)?\n\nBecause, I've been confused by hook output before.  A lot of users\nhave been.  We've also been confused by terminal captures posted\nby users when they are having trouble with Git, it does help to\ndebug the problem by knowing what came from the remote side, and\nwhat was reported locally.\n\nThe use of 'remote:' as a prefix dates back to August 2006,\nin commit 2de196fe by Junio Hamano.  Prior to that we used\nVT100 coloring, which Junio Hamano added that same month in\ncommit dfa46478:\n\n    fetch/clone: mark messages from remote side stand out.\n    \n    When dealing with a corrupt or out of sync remote repository,\n    the user often gets error messages like this:\n    \n        error: refs/heads/devel does not point to a valid commit object!\n    \n    which leaves the user wondering if the breakage is on the local\n    end or on the remote end.  This is unnecessarily alarming.\n    \n    This patch changes the way we display messages received from the\n    remote side over the git protocol sideband (i.e. stderr stream\n    of the remote process).  It shows them with blue background with\n    white letters, but this presentation is subject to proposals of\n    better ways from the list.\n    \n    The problem was pointed out by Andrew Morton.\n\nI guess its a long standing history now that messages from the\nremote side should get echoed with 'remote:' to better describe\nwhat is going on.\n\nAs for why it got picked up by remote hooks, its because I reused\nthe code, because I reused the network protocol.\n\n> As I see it this change has taken away a little bit of freedom.\n\nBut its made the whole thing more honest.\n\nMessages from the remote are now clearly marked as \"this is stuff\nthe other side is trying to tell you\", which is different from the\nstatus update we display later showing the outcome of the push.\n\n> Previously I (as a hook writer) could choose to add a prefix like \n> \"remote:\" to my hook if I wanted to, to make it more obvious that the\n> output came from the remote server, _or_ I could choose not to and \n> have a standardized output that looked the same regardless of whether\n> it was a local hook or a remote one that complained about the \n> formatting of a commit message. Now I no longer have that option.\n\nBut as a user, I really want to know what was hook output, and what\nwas output from Git.  Putting \"remote: \" in front helps me to see\nthe difference.\n\n> And what if my hook output is localized? Now there is an English\n> \"remote:\" in front of every line... Or even worse, what if the\n> \"remote:\" string is localized in a future version of git, then I \n> have no way of knowing how wide it is and cannot take measures to \n> format my hook output so that it will look right.\n\nDon't localize \"remote:\"?  Or pick a shorter translation?\n\nIf its really a problem, maybe \"remote: \" prefix should turn into\nsomething shorter and language agnostic, like \"<< \".  But thus far\nwe hadn't had to worry about it, since we didn't have translation\nsupport in Git...  (though yes, I see that is changing now).\n\n-- \nShawn.\n"},{"id":"143470","messageId":"AANLkTikQQh4sUA7h2k1jvQ7aMgYyq7WFetJvJZvqpVxt@mail.gmail.com","threadId":"24046","inReplyTo":"20100610183019.GR14847@spearce.org","subject":"Re: Git sideband hook output","fromName":"Scott Chacon","fromEmail":"schacon@gmail.com","sentAt":"2010-06-10T18:49:19Z","receivedAt":"2010-06-10T18:49:19Z","isPatch":false,"sender":{"key":"schacon@gmail.com","avatar":"https://gravatar.com/avatar/9b13a8a078e1dcf8588c4eea9554445d51ebed6c41b51f56f4d96738130b05c6?d=mp&s=160"},"body":"Hey,\n\nOn Thu, Jun 10, 2010 at 8:30 PM, Shawn O. Pearce <spearce@spearce.org> wrote:\n>\n> If its really a problem, maybe \"remote: \" prefix should turn into\n> something shorter and language agnostic, like \"<< \".  But thus far\n> we hadn't had to worry about it, since we didn't have translation\n> support in Git...  (though yes, I see that is changing now).\n>\n\nI would heavily be in favor of a change to '>>' or '<<'.  A lot of\nservices use the hook output to add useful info after or during a push\nand the 'remote:' string is distracting for the user.  +1 to '>>'.  Or\nperhaps be configurable, but default to '>>'.\n\nScott\n"},{"id":"143510","messageId":"AANLkTikYBB1DsGRRsu4pSNr1j8fFXD-99c4lRAaBqd3M@mail.gmail.com","threadId":"24046","inReplyTo":"AANLkTikQQh4sUA7h2k1jvQ7aMgYyq7WFetJvJZvqpVxt@mail.gmail.com","subject":"Re: Git sideband hook output","fromName":"PJ Hyett","fromEmail":"pjhyett@gmail.com","sentAt":"2010-06-11T14:34:07Z","receivedAt":"2010-06-11T14:34:07Z","isPatch":false,"sender":{"key":"pjhyett@gmail.com","avatar":"https://gravatar.com/avatar/14ddb30a3ad7207eaf7f99f07c6ba9f0d1d47d9d10bbbd13d06ef1b9b8cdb824?d=mp&s=160"},"body":"Hi,\n\n> On Thu, Jun 10, 2010 at 8:30 PM, Shawn O. Pearce <spearce@spearce.org> wrote:\n>>\n>> If its really a problem, maybe \"remote: \" prefix should turn into\n>> something shorter and language agnostic, like \"<< \".  But thus far\n>> we hadn't had to worry about it, since we didn't have translation\n>> support in Git...  (though yes, I see that is changing now).\n>>\n\nI'm also in favor of making the default '>>' instead of 'remote:' if\nnothing isn't an option.\n\nUsing Heroku as an example, this is what their current hook output looks like:\n\n$ git push origin master\nCounting objects: 9, done.\nDelta compression using up to 2 threads.\nCompressing objects: 100% (5/5), done.\nWriting objects: 100% (5/5), 684 bytes, done.\nTotal 5 (delta 2), reused 0 (delta 0)\n\n-----> Heroku receiving push\n-----> Sinatra app detected\n       Compiled slug size is 3.9MB\n-----> Launching....... done\n       http://fi-quote.heroku.com deployed to Heroku\n\nTo git@heroku.com:fi-quote.git\n   0bb7fa2..2755742  master -> master\n\n\nNow, if you compare that to what it would look like if they were\nrunning a more recent version of git, the verboseness of remote: is\nquite apparent:\n\n\n$ git push origin master\nCounting objects: 9, done.\nDelta compression using up to 2 threads.\nCompressing objects: 100% (5/5), done.\nWriting objects: 100% (5/5), 684 bytes, done.\nTotal 5 (delta 2), reused 0 (delta 0)\nremote:\nremote: -----> Heroku receiving push\nremote: -----> Sinatra app detected\nremote:       Compiled slug size is 3.9MB\nremote: -----> Launching....... done\nremote:       http://fi-quote.heroku.com deployed to Heroku\nremote:\nTo git@heroku.com:fi-quote.git\n   0bb7fa2..2755742  master -> master\n\nIn a perfect world, I think it should be up to the user to determine\nthe amount of information they receive (using a verbose switch\nperhaps), but short of that, at least toning down what is output would\nbe much appreciated.\n\nCheers,\nPJ\n"},{"id":"143512","messageId":"3B9F4351-4608-455E-B433-A5337A946F8A@wincent.com","threadId":"24046","inReplyTo":"AANLkTikYBB1DsGRRsu4pSNr1j8fFXD-99c4lRAaBqd3M@mail.gmail.com","subject":"Re: Git sideband hook output","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2010-06-11T14:45:41Z","receivedAt":"2010-06-11T14:45:41Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 11/06/2010, a las 16:34, PJ Hyett escribió:\n\n> Hi,\n> \n>> On Thu, Jun 10, 2010 at 8:30 PM, Shawn O. Pearce <spearce@spearce.org> wrote:\n>>> \n>>> If its really a problem, maybe \"remote: \" prefix should turn into\n>>> something shorter and language agnostic, like \"<< \".  But thus far\n>>> we hadn't had to worry about it, since we didn't have translation\n>>> support in Git...  (though yes, I see that is changing now).\n>>> \n> \n> I'm also in favor of making the default '>>' instead of 'remote:' if\n> nothing isn't an option.\n\nFunny, as '>>' is basically meaningless. At least 'remote:' has semantic value (ie. it indicates _where_ something is coming from).\n\nWincent\n"},{"id":"143514","messageId":"AANLkTimPI-A_4H-vYtHIyfbSLERDo0vu-kbB3Qu3ZT06@mail.gmail.com","threadId":"24046","inReplyTo":"3B9F4351-4608-455E-B433-A5337A946F8A@wincent.com","subject":"Re: Git sideband hook output","fromName":"Erik Faye-Lund","fromEmail":"kusmabite@googlemail.com","sentAt":"2010-06-11T15:11:18Z","receivedAt":"2010-06-11T15:11:18Z","isPatch":false,"sender":{"key":"kusmabite@gmail.com","avatar":"https://avatars.githubusercontent.com/u/47073?v=4"},"body":"On Fri, Jun 11, 2010 at 4:45 PM, Wincent Colaiuta <win@wincent.com> wrote:\n> El 11/06/2010, a las 16:34, PJ Hyett escribió:\n>\n>> Hi,\n>>\n>>> On Thu, Jun 10, 2010 at 8:30 PM, Shawn O. Pearce <spearce@spearce.org> wrote:\n>>>>\n>>>> If its really a problem, maybe \"remote: \" prefix should turn into\n>>>> something shorter and language agnostic, like \"<< \".  But thus far\n>>>> we hadn't had to worry about it, since we didn't have translation\n>>>> support in Git...  (though yes, I see that is changing now).\n>>>>\n>>\n>> I'm also in favor of making the default '>>' instead of 'remote:' if\n>> nothing isn't an option.\n>\n> Funny, as '>>' is basically meaningless. At least 'remote:' has semantic value (ie. it indicates _where_ something is coming from).\n>\n\nHow about '> ', which often means \"quote\" (e.g in e-mails)? Would that\nbe appropriate?\n\n-- \nErik \"kusma\" Faye-Lund\n"},{"id":"143515","messageId":"AANLkTikONJoDiyxmcmdG8zZkTCLbqXlXhrASae7rAreN@mail.gmail.com","threadId":"24046","inReplyTo":"20100610183019.GR14847@spearce.org","subject":"Re: Git sideband hook output","fromName":"Ævar Arnfjörð Bjarmason","fromEmail":"avarab@gmail.com","sentAt":"2010-06-11T15:18:14Z","receivedAt":"2010-06-11T15:18:14Z","isPatch":false,"sender":{"key":"avarab@gmail.com","avatar":"https://avatars.githubusercontent.com/u/45301?v=4"},"body":"On Thu, Jun 10, 2010 at 18:30, Shawn O. Pearce <spearce@spearce.org> wrote:\n> Peter Kjellerstedt <peter.kjellerstedt@axis.com> wrote:\n>> And what if my hook output is localized? Now there is an English\n>> \"remote:\" in front of every line... Or even worse, what if the\n>> \"remote:\" string is localized in a future version of git, then I\n>> have no way of knowing how wide it is and cannot take measures to\n>> format my hook output so that it will look right.\n>\n> Don't localize \"remote:\"?  Or pick a shorter translation?\n>\n> If its really a problem, maybe \"remote: \" prefix should turn into\n> something shorter and language agnostic, like \"<< \".  But thus far\n> we hadn't had to worry about it, since we didn't have translation\n> support in Git...  (though yes, I see that is changing now).\n\nIs there any reason for why the \"remote:\" output needs to be echoed\nverbatim to the user instead of being passed through some filter.\n\nIf not, then it could be treated as part of a protocol, parsed, and\nlocalized however the user wants.\n\n\">\" isn't as language-agnostic as you might think, in a RTL language\nthe arrow ends up facing the wrong way.\n"},{"id":"143533","messageId":"4C12B0A2.4020205@gmail.com","threadId":"24046","inReplyTo":"3B9F4351-4608-455E-B433-A5337A946F8A@wincent.com","subject":"Re: Git sideband hook output","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2010-06-11T21:54:42Z","receivedAt":"2010-06-11T21:54:42Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Wincent Colaiuta wrote:\n> El 11/06/2010, a las 16:34, PJ Hyett escribió:\n> \n>> Hi,\n>>\n>>> On Thu, Jun 10, 2010 at 8:30 PM, Shawn O. Pearce <spearce@spearce.org> wrote:\n>>>> If its really a problem, maybe \"remote: \" prefix should turn into\n>>>> something shorter and language agnostic, like \"<< \".  But thus far\n>>>> we hadn't had to worry about it, since we didn't have translation\n>>>> support in Git...  (though yes, I see that is changing now).\n>>>>\n>> I'm also in favor of making the default '>>' instead of 'remote:' if\n>> nothing isn't an option.\n> \n> Funny, as '>>' is basically meaningless. At least 'remote:' has semantic value (ie. it indicates _where_ something is coming from).\n\nSeconded.\n"},{"id":"143534","messageId":"4C12B0D0.9000805@gmail.com","threadId":"24046","inReplyTo":"AANLkTikONJoDiyxmcmdG8zZkTCLbqXlXhrASae7rAreN@mail.gmail.com","subject":"Re: Git sideband hook output","fromName":"A Large Angry SCM","fromEmail":"gitzilla@gmail.com","sentAt":"2010-06-11T21:55:28Z","receivedAt":"2010-06-11T21:55:28Z","isPatch":false,"sender":{"key":"gitzilla@gmail.com","avatar":"https://gravatar.com/avatar/354625c442439908ff3dd99757dee330e29e9df7847472384faf7a00add247fb?d=mp&s=160"},"body":"Ævar Arnfjörð Bjarmason wrote:\n> On Thu, Jun 10, 2010 at 18:30, Shawn O. Pearce <spearce@spearce.org> wrote:\n>> Peter Kjellerstedt <peter.kjellerstedt@axis.com> wrote:\n>>> And what if my hook output is localized? Now there is an English\n>>> \"remote:\" in front of every line... Or even worse, what if the\n>>> \"remote:\" string is localized in a future version of git, then I\n>>> have no way of knowing how wide it is and cannot take measures to\n>>> format my hook output so that it will look right.\n>> Don't localize \"remote:\"?  Or pick a shorter translation?\n>>\n>> If its really a problem, maybe \"remote: \" prefix should turn into\n>> something shorter and language agnostic, like \"<< \".  But thus far\n>> we hadn't had to worry about it, since we didn't have translation\n>> support in Git...  (though yes, I see that is changing now).\n> \n> Is there any reason for why the \"remote:\" output needs to be echoed\n> verbatim to the user instead of being passed through some filter.\n> \n> If not, then it could be treated as part of a protocol, parsed, and\n> localized however the user wants.\n> \n> \">\" isn't as language-agnostic as you might think, in a RTL language\n> the arrow ends up facing the wrong way.\n\nAlso seconded.\n"},{"id":"143539","messageId":"7v631pgm9d.fsf@alter.siamese.dyndns.org","threadId":"24046","inReplyTo":"AANLkTimPI-A_4H-vYtHIyfbSLERDo0vu-kbB3Qu3ZT06@mail.gmail.com","subject":"Re: Git sideband hook output","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-06-11T23:52:46Z","receivedAt":"2010-06-11T23:52:46Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Erik Faye-Lund <kusmabite@googlemail.com> writes:\n\n>> Funny, as '>>' is basically meaningless. At least 'remote:' has semantic value (ie. it indicates _where_ something is coming from).\n>\n> How about '> ', which often means \"quote\" (e.g in e-mails)? Would that\n> be appropriate?\n\nNot much better, IMNSHO.  Where do people get the idea that line-noises\nare more descriptive than \"remote:\"?\n"},{"id":"143546","messageId":"20100612040717.GA9419@coredump.intra.peff.net","threadId":"24046","inReplyTo":"7v631pgm9d.fsf@alter.siamese.dyndns.org","subject":"Re: Git sideband hook output","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2010-06-12T04:07:17Z","receivedAt":"2010-06-12T04:07:17Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Fri, Jun 11, 2010 at 04:52:46PM -0700, Junio C Hamano wrote:\n\n> Erik Faye-Lund <kusmabite@googlemail.com> writes:\n> \n> >> Funny, as '>>' is basically meaningless. At least 'remote:' has semantic value (ie. it indicates _where_ something is coming from).\n> >\n> > How about '> ', which often means \"quote\" (e.g in e-mails)? Would that\n> > be appropriate?\n> \n> Not much better, IMNSHO.  Where do people get the idea that line-noises\n> are more descriptive than \"remote:\"?\n\nI also find '>' ugly, but maybe it is worth quelling the bikeshed\ndiscussion with something like the following.\n\ndiff --git a/cache.h b/cache.h\nindex 5e55367..c616513 100644\n--- a/cache.h\n+++ b/cache.h\n@@ -999,6 +999,7 @@ extern int pager_use_color;\n \n extern const char *editor_program;\n extern const char *excludes_file;\n+extern const char *sideband_prefix;\n \n /* base85 */\n int decode_85(char *dst, const char *line, int linelen);\ndiff --git a/config.c b/config.c\nindex 9b6b1df..22a1b04 100644\n--- a/config.c\n+++ b/config.c\n@@ -579,6 +579,9 @@ static int git_default_core_config(const char *var, const char *value)\n \t\treturn 0;\n \t}\n \n+\tif (!strcmp(var, \"core.sidebandprefix\"))\n+\t\treturn git_config_string(&sideband_prefix, var, value);\n+\n \t/* Add other config variables here and to Documentation/config.txt. */\n \treturn 0;\n }\ndiff --git a/sideband.c b/sideband.c\nindex d5ffa1c..be4a785 100644\n--- a/sideband.c\n+++ b/sideband.c\n@@ -12,22 +12,27 @@\n  * the remote died unexpectedly.  A flush() concludes the stream.\n  */\n \n-#define PREFIX \"remote:\"\n+#define DEFAULT_PREFIX \"remote:\"\n \n #define ANSI_SUFFIX \"\\033[K\"\n #define DUMB_SUFFIX \"        \"\n \n #define FIX_SIZE 10  /* large enough for any of the above */\n \n+char *sideband_prefix = DEFAULT_PREFIX;\n+\n int recv_sideband(const char *me, int in_stream, int out)\n {\n-\tunsigned pf = strlen(PREFIX);\n+\tunsigned pf = strlen(sideband_prefix);\n \tunsigned sf;\n \tchar buf[LARGE_PACKET_MAX + 2*FIX_SIZE];\n \tchar *suffix, *term;\n \tint skip_pf = 0;\n \n-\tmemcpy(buf, PREFIX, pf);\n+\tif (pf > FIX_SIZE)\n+\t\tpf = FIX_SIZE;\n+\n+\tmemcpy(buf, sideband_prefix, pf);\n \tterm = getenv(\"TERM\");\n \tif (term && strcmp(term, \"dumb\"))\n \t\tsuffix = ANSI_SUFFIX;\n"}]}