{"thread":{"id":"17271","subject":"CR codes from git commands","startedAt":"2009-01-20T16:26:32Z","lastAt":"2009-02-02T07:09:38Z","messageCount":24,"participants":["Brent Goodrick","Johannes Schindelin","Daniel Barkalow","Junio C Hamano","Mike Ralphson","Boyd Stephen Smith Jr."],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"101264","messageId":"18805.64312.289059.660023@hungover.brentg.com","threadId":"17271","inReplyTo":null,"subject":"CR codes from git commands","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-01-20T16:26:32Z","receivedAt":"2009-01-20T16:26:32Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"\nHi,\n\nI am considering converting from CVS over to using git. I'm currently\nusing git version 1.5.6.5 on Debian Linux \"testing\". One of the first\nthings I ran into was having to set PAGER to \"cat\" to avoid the\nproblems when running git from anything other than a terminal.  The\nsecond thing is that \"git pull\" (and possibly other commands) are\nemitting ^M (octal 013) codes on output, possibly caused by the same\nassumption as causes the problem that is fixed by setting PAGER to\n\"cat\".  This is not a big deal on small repos, but on larger ones I\nactually do want to see status line output (or be given some option to\nsee them), so that I can then run \"tail -1lf\" on the log file that is\nwritten during a long \"git pull\" operation.\n\nIs there some configuration option or some environment variable I can\nset that tells git to stop treating every invocation as if it is\ncoming from a terminal?\n\nYou can reproduce this on Linux with the following script (look for\nthe CR codes on the final git pull at the end of the script):\n\n-- cut below this line ---\n#!/bin/sh\n\n# I could have simply used \"set -x\" here but then I wouldn't see the\n# redirection syntax like \">file1\", so instead use a PrintRun\n# function:\nPrintRun ()\n{\n    echo \"COMMAND: $*\"\n    eval \"$*; exitcode=\\$?\"\n    if [ $exitcode != 0 ]\n    then\n        echo \"ERROR: Command failed: $*\"\n        exit 1\n    fi\n}\n\n# Failed attempt at hacking around git insisting on using ^M codes on stderr:\n# cat >/tmp/git_pager <<EOF\n# sed 's%^% >> %g'\n# # This doesn't work either since the output I want to filter is on stderr\n# # tr '\\013' '\\012'\n# EOF\n# chmod a+x /tmp/git_pager\n# GIT_PAGER=/tmp/git_pager; export GIT_PAGER\n\n# Clear out the scratch areas:\nPrintRun rm -rf /tmp/git_area1\nPrintRun rm -rf /tmp/git_area2\n# Populate the initial area:\nPrintRun mkdir -p /tmp/git_area1\nPrintRun cd /tmp/git_area1\nPrintRun git init\nPrintRun \"echo a new file 1 >file1\"\nPrintRun \"echo a new file 2 >file2\"\nPrintRun git add file1\nPrintRun git add file2\nPrintRun git status\nPrintRun \"git commit -m \\\"first commit in git_area1\\\"\"\nPrintRun find .\n# Clone from the first area into a second area and add a file there:\nPrintRun rm -rf /tmp/git_area2\nPrintRun cd /tmp\nPrintRun git clone /tmp/git_area1 git_area2\nPrintRun cd /tmp/git_area2\nPrintRun find .\nPrintRun \"echo a new file 3 >file3\"\nPrintRun git add file3\nPrintRun git status\nPrintRun \"git commit -m \\\"second commit but in git_area2\\\"\"\nPrintRun \"git status; true\" # true means don't fail inside PrintRun\nPrintRun \"git status; true\" # true means don't fail inside PrintRun\n# Now attempt to somehow refresh (what is the \"git\" word for \"cvs update\"?) into the first area:\nPrintRun cd /tmp/git_area1\nPrintRun \"git status; true\" # true means don't fail inside PrintRun\nPrintRun \"git diff; true\" # true means don't fail inside PrintRun\n# PrintRun \"git pull /tmp/git_area2 master 2>&1\"\n# PrintRun \"git pull /tmp/git_area2 master 2>&1 | tr '\\013' '\\012'\"\nPrintRun git pull /tmp/git_area2 master\n-- cut above this line ---\n\n\nAttempts at hacking around the problem: Redirecting stderr output from\ngit and then manually translating CR codes into LF codes yeilds the\nfollowing output (but I can't do this in practice and, no, I can't use\naliases in Bourne scripts (Bash/KSH yes, Bourne no)):\n\ngit> COMMAND: git pull /tmp/git_area2 master 2>&1\ngit> remote: Counting objects: 4, done.        \ngit> remote: Compressing objects:  50% (1/2)           \ngit>  --> remote: Compressing objects: 100% (2/2)           \ngit>  --> remote: Compressing objects: 100% (2/2        )Unpacking objects:  33% (1/3)   \ngit>  --> Unpacking objects:  66% (2/3)   \ngit>  --> Unpacking objects: 100% (3/3)   \ngit>  --> Unpacking objects: 100% (3/3), done.\ngit> remote: , done.        \ngit> remote: Total 3 (delta 0), reused 0 (delta 0)        \ngit> From /tmp/git_area2\ngit>  * branch            master     -> FETCH_HEAD\ngit> Updating b2f942d..4f9ba90\ngit> Fast forward\ngit>  file3 |    1 +\ngit>  1 files changed, 1 insertions(+), 0 deletions(-)\ngit>  create mode 100644 file3\n\nTrying to automatically filter this with redirection and use of tr\nfails to show the progress output completely which is a non-option\neither:\n\ngit> COMMAND: git pull /tmp/git_area2 master 2>&1 | tr '\\013' '\\012'\ngit> From /tmp/git_area2\ngit>  * branch            master     -> FETCH_HEAD\ngit> Updating 49b1897..bb5f57c\ngit> Fast forward\ngit>  file3 |    1 +\ngit>  1 files changed, 1 insertions(+), 0 deletions(-)\ngit>  create mode 100644 file3\n\nThanks,\nbgoodr\n"},{"id":"101272","messageId":"alpine.DEB.1.00.0901201757520.5159@intel-tinevez-2-302","threadId":"17271","inReplyTo":"18805.64312.289059.660023@hungover.brentg.com","subject":"Re: CR codes from git commands","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-20T17:08:22Z","receivedAt":"2009-01-20T17:08:22Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 20 Jan 2009, Brent Goodrick wrote:\n\n> I am considering converting from CVS over to using git. I'm currently\n> using git version 1.5.6.5 on Debian Linux \"testing\".\n\nFirst of all, 1.5.6.5 is from last August, so chances are that the \nbehavior you complain about was fixed in the meantime.  We're at 1.6.1 at \nthe moment.\n\n> One of the first things I ran into was having to set PAGER to \"cat\" to \n> avoid the problems when running git from anything other than a terminal.  \n> The second thing is that \"git pull\" (and possibly other commands) are \n> emitting ^M (octal 013) codes on output, possibly caused by the same \n> assumption as causes the problem that is fixed by setting PAGER to \n> \"cat\".\n\nThe only place I can think about where a CR is output is when showing the \nprogress of downloading. \n\nUsually, our code checks if stdout is a tty, and does not show progress.\n\nAs a work-around, piping into cat should work, though.\n\nCiao,\nDscho\n"},{"id":"101390","messageId":"18807.13411.984420.252378@hungover.brentg.com","threadId":"17271","inReplyTo":"alpine.DEB.1.00.0901210930370.7929@racer","subject":"Re: CR codes from git commands","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-01-21T14:42:43Z","receivedAt":"2009-01-21T14:42:43Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"\nJohannes Schindelin writes:\n > Hi,\n > \n > is there a special reason you un-Cc:ed the list?\n\nNo, my mistake.  CCing the mailing list now. I was foiled into\nthinking that the reply operation in my email client meant reply-all,\nbut instead it was set to reply-to-sender-only. Now fixed.\n\n > \n > On Tue, 20 Jan 2009, Brent Goodrick wrote:\n > \n > > Johannes Schindelin writes:\n > > \n > >  > On Tue, 20 Jan 2009, Brent Goodrick wrote:\n > >  > \n > >  > > I am considering converting from CVS over to using git. I'm \n > >  > > currently using git version 1.5.6.5 on Debian Linux \"testing\".\n > >  > \n > >  > First of all, 1.5.6.5 is from last August, so chances are that the \n > >  > behavior you complain about was fixed in the meantime.  We're at \n > >  > 1.6.1 at the moment.\n > > \n > > Yes, I thought that was a good point, so I rebuilt from the source \n > > tarball git version 1.6.1 and retried my script and got the same \n > > behavior.\n > > \n > >  > The only place I can think about where a CR is output is when showing \n > >  > the progress of downloading.\n > >  > \n > >  > Usually, our code checks if stdout is a tty, and does not show \n > >  > progress.\n > >  >\n > >  > As a work-around, piping into cat should work, though.\n > > \n > > Actually only redirecting stderr and then piping to cat seems to work, \n > > e.g.,:\n > > \n > >   get pull 2>&1 | cat\n > > \n > > \n > > I don't mind seeing the progress lines, I just don't want git to emit \n > > any CR codes at all.\n > > \n > > How about a config option to just turn off any tty-detecting logic \n > > entirely, so that I don't have to wrap git with a lot of silly scripts \n > > that set environment variables and redirect stdout and stderr and piped \n > > into \"cat\"?\n > \n > Nope, the config option is not needed.  This is just a Plain Old Bug which \n > needs fixing, that's all.\n > \n > Let's see what I can do today.\n\nThanks.  The fix should be to arrange it so that I can set something\nso that a bare call such as (but just \"git pull\"):\n\n  git pull\n\nwill emit no CR codes at all, ever, regardless of if there is a tty.\nEven if it is an env var, but a config setting would be ok too.\n\nThanks,\nBrent\n"},{"id":"101394","messageId":"alpine.DEB.1.00.0901211636340.3586@pacific.mpi-cbg.de","threadId":"17271","inReplyTo":"18807.13411.984420.252378@hungover.brentg.com","subject":"Re: CR codes from git commands","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-21T15:38:56Z","receivedAt":"2009-01-21T15:38:56Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Wed, 21 Jan 2009, Brent Goodrick wrote:\n\n> Johannes Schindelin writes:\n> \n>  > On Tue, 20 Jan 2009, Brent Goodrick wrote:\n>  > \n>  > > Johannes Schindelin writes:\n>  > > \n>  > >  > On Tue, 20 Jan 2009, Brent Goodrick wrote:\n>  > >  > \n>  > >  > > I am considering converting from CVS over to using git. I'm \n>  > >  > > currently using git version 1.5.6.5 on Debian Linux \"testing\".\n>  > >  > \n>  > >  > First of all, 1.5.6.5 is from last August, so chances are that \n>  > >  > the behavior you complain about was fixed in the meantime.  \n>  > >  > We're at 1.6.1 at the moment.\n>  > > \n>  > > Yes, I thought that was a good point, so I rebuilt from the source \n>  > > tarball git version 1.6.1 and retried my script and got the same \n>  > > behavior.\n>  > > \n>  > >  > The only place I can think about where a CR is output is when \n>  > >  > showing the progress of downloading.\n>  > >  > \n>  > >  > Usually, our code checks if stdout is a tty, and does not show \n>  > >  > progress.\n>  > >  >\n>  > >  > As a work-around, piping into cat should work, though.\n>  > > \n>  > > Actually only redirecting stderr and then piping to cat seems to work, \n>  > > e.g.,:\n>  > > \n>  > >   get pull 2>&1 | cat\n\nIn my test I performed one minute ago, \"git pull | cat\" did not show any \nCR.  Maybe it is the \"git\" instead of \"get\" :-)\n\n>  > > I don't mind seeing the progress lines, I just don't want git to \n>  > > emit any CR codes at all.\n>  > > \n>  > > How about a config option to just turn off any tty-detecting logic \n>  > > entirely, so that I don't have to wrap git with a lot of silly \n>  > > scripts that set environment variables and redirect stdout and \n>  > > stderr and piped into \"cat\"?\n>  > \n>  > Nope, the config option is not needed.  This is just a Plain Old Bug \n>  > which needs fixing, that's all.\n>  > \n>  > Let's see what I can do today.\n> \n> Thanks.  The fix should be to arrange it so that I can set something so \n> that a bare call such as (but just \"git pull\"):\n> \n>   git pull\n> \n> will emit no CR codes at all, ever, regardless of if there is a tty. \n> Even if it is an env var, but a config setting would be ok too.\n\nI would actually think that it should not be an env var or config setting \nif piping it to \"cat\" does what you want: if the output is a tty, I think \nit is safe to assume that you want to see the progress, and if you don't, \n\"| cat\" is not an unreasonable thing to ask for.\n\nCiao,\nDscho\n"},{"id":"101493","messageId":"e38bce640901212000w5b1b8a91tfdd0abbebde162a0@mail.gmail.com","threadId":"17271","inReplyTo":"alpine.DEB.1.00.0901211636340.3586@pacific.mpi-cbg.de","subject":"Re: CR codes from git commands","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-01-22T04:00:45Z","receivedAt":"2009-01-22T04:00:45Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"On Wed, Jan 21, 2009 at 7:38 AM, Johannes Schindelin\n> In my test I performed one minute ago, \"git pull | cat\" did not show any\n> CR.  Maybe it is the \"git\" instead of \"get\" :-)\n<snip>\n> > Thanks.  The fix should be to arrange it so that I can set something so\n> > that a bare call such as (but just \"git pull\"):\n> >\n> >   git pull\n> >\n> > will emit no CR codes at all, ever, regardless of if there is a tty.\n> > Even if it is an env var, but a config setting would be ok too.\n>\n> I would actually think that it should not be an env var or config setting\n> if piping it to \"cat\" does what you want: if the output is a tty, I think\n> it is safe to assume that you want to see the progress, and if you don't,\n> \"| cat\" is not an unreasonable thing to ask for.\n\nYou might not be able to see those CR codes from your terminal,\nbecause ... well ... its a terminal which will process them.  And if\nyou can't reproduce it in your environment, you'll have to duplicate\nmy environment, and at that is well beyond what I would ask anyone to\ndo. Thanks for your effort in looking into it.  If I get annoyed\nenough with it, I'll debug the code myself and propose a patch (but\ndon't hold your breath because I'm still learning this complex tool).\n\nThanks!\nBrent\n"},{"id":"101495","messageId":"alpine.LNX.1.00.0901212319310.19665@iabervon.org","threadId":"17271","inReplyTo":"18805.64312.289059.660023@hungover.brentg.com","subject":"Re: CR codes from git commands","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-01-22T04:47:39Z","receivedAt":"2009-01-22T04:47:39Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Tue, 20 Jan 2009, Brent Goodrick wrote:\n\n> \n> Hi,\n> \n> I am considering converting from CVS over to using git. I'm currently\n> using git version 1.5.6.5 on Debian Linux \"testing\". One of the first\n> things I ran into was having to set PAGER to \"cat\" to avoid the\n> problems when running git from anything other than a terminal.  The\n> second thing is that \"git pull\" (and possibly other commands) are\n> emitting ^M (octal 013) codes on output, possibly caused by the same\n> assumption as causes the problem that is fixed by setting PAGER to\n> \"cat\".  This is not a big deal on small repos, but on larger ones I\n> actually do want to see status line output (or be given some option to\n> see them), so that I can then run \"tail -1lf\" on the log file that is\n> written during a long \"git pull\" operation.\n\nIt's kind of unclear what you're trying to do here. I'm guessing that \nyou're trying to run git with stdio directed to a /dev/tty device, where \nisatty() is true, but which doesn't interpret ASCII control characters as \nsuch. We're not detecting that you can't use a pager on this, and so you \nhave to use PAGER=cat (which might not be a bad idea for things like \n\"man\", either). With some clues about the environment, we should be able \nto do something about this.\n\nYou're also trying to send the progress output to a log file that you can \nlook at the end of (presumably in a more capable terminal). It should be \npossible (with an option) to get git to output progress info to a non-tty, \nand not use the CRs if the output isn't a tty.\n\nOr do you want to use a tty that can't handle CRs, and get newlines \ninstead of CRs? (If I'd git on the first computer I used, it would have \nprinted the progress bar over and over in place and probably torn a hole \nin the paper, but I haven't used that one in over 20 years.)\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"101508","messageId":"e38bce640901212334v1e672d48t81d5c81fecd929eb@mail.gmail.com","threadId":"17271","inReplyTo":"alpine.LNX.1.00.0901212319310.19665@iabervon.org","subject":"Re: CR codes from git commands","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-01-22T07:34:37Z","receivedAt":"2009-01-22T07:34:37Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"On Wed, Jan 21, 2009 at 8:47 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:\n> It's kind of unclear what you're trying to do here. I'm guessing that\n> you're trying to run git with stdio directed to a /dev/tty device, where\n> isatty() is true, but which doesn't interpret ASCII control characters as\n> such. We're not detecting that you can't use a pager on this, and so you\n> have to use PAGER=cat (which might not be a bad idea for things like\n> \"man\", either). With some clues about the environment, we should be able\n> to do something about this.\n>\n> You're also trying to send the progress output to a log file that you can\n> look at the end of (presumably in a more capable terminal). It should be\n> possible (with an option) to get git to output progress info to a non-tty,\n> and not use the CRs if the output isn't a tty.\n>\n> Or do you want to use a tty that can't handle CRs, and get newlines\n> instead of CRs? (If I'd git on the first computer I used, it would have\n> printed the progress bar over and over in place and probably torn a hole\n> in the paper, but I haven't used that one in over 20 years.)\n\nHi Daniel,\n\nIdeally, yes I would want no CR's but LF's instead (but others who do\nnot use my environment may actually like the way it is now, and I seek\nnot to disturb that use case).  I could live without the progress\nlines (lines that print repeatedly over in one place on normal\nterminals), but adding \" 2>&1 | cat\" to every command line just to get\nthe CR's to go away, is non-workable for me.\n\nThe environment I'm running git under is the Shell mode inside GNU\nEmacs. I can't tell you what type of terminal it is, because I believe\nthat is defined deep in the guts of Emacs. Having read your reply\nabove, I'm now wondering whether this is an Emacs issue versus a git\nissue. If it is an Emacs issue, then I am truly embarrassed for having\nwasted everyones time with it.\n\nBrent\n"},{"id":"101509","messageId":"alpine.LNX.1.00.0901220238380.19665@iabervon.org","threadId":"17271","inReplyTo":"e38bce640901212334v1e672d48t81d5c81fecd929eb@mail.gmail.com","subject":"Re: CR codes from git commands","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-01-22T07:46:57Z","receivedAt":"2009-01-22T07:46:57Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Wed, 21 Jan 2009, Brent Goodrick wrote:\n\n> On Wed, Jan 21, 2009 at 8:47 PM, Daniel Barkalow <barkalow@iabervon.org> wrote:\n> > It's kind of unclear what you're trying to do here. I'm guessing that\n> > you're trying to run git with stdio directed to a /dev/tty device, where\n> > isatty() is true, but which doesn't interpret ASCII control characters as\n> > such. We're not detecting that you can't use a pager on this, and so you\n> > have to use PAGER=cat (which might not be a bad idea for things like\n> > \"man\", either). With some clues about the environment, we should be able\n> > to do something about this.\n> >\n> > You're also trying to send the progress output to a log file that you can\n> > look at the end of (presumably in a more capable terminal). It should be\n> > possible (with an option) to get git to output progress info to a non-tty,\n> > and not use the CRs if the output isn't a tty.\n> >\n> > Or do you want to use a tty that can't handle CRs, and get newlines\n> > instead of CRs? (If I'd git on the first computer I used, it would have\n> > printed the progress bar over and over in place and probably torn a hole\n> > in the paper, but I haven't used that one in over 20 years.)\n> \n> Hi Daniel,\n> \n> Ideally, yes I would want no CR's but LF's instead (but others who do\n> not use my environment may actually like the way it is now, and I seek\n> not to disturb that use case).  I could live without the progress\n> lines (lines that print repeatedly over in one place on normal\n> terminals), but adding \" 2>&1 | cat\" to every command line just to get\n> the CR's to go away, is non-workable for me.\n> \n> The environment I'm running git under is the Shell mode inside GNU\n> Emacs. I can't tell you what type of terminal it is, because I believe\n> that is defined deep in the guts of Emacs. Having read your reply\n> above, I'm now wondering whether this is an Emacs issue versus a git\n> issue. If it is an Emacs issue, then I am truly embarrassed for having\n> wasted everyones time with it.\n\nThe terminal type, at least in my version of Emacs, is \"dumb\", which ought \nto be sufficient to tell git that a pager isn't going to be useful is most \ncases (might be worthwhile to keep \"git log\" from eating all your memory, \nthough), and that using CR to rewrite lines isn't going to work.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"101512","messageId":"7vbptzahra.fsf@gitster.siamese.dyndns.org","threadId":"17271","inReplyTo":"alpine.LNX.1.00.0901220238380.19665@iabervon.org","subject":"Re: CR codes from git commands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-22T08:04:41Z","receivedAt":"2009-01-22T08:04:41Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Daniel Barkalow <barkalow@iabervon.org> writes:\n\n> The terminal type, at least in my version of Emacs, is \"dumb\", which ought \n> to be sufficient to tell git that a pager isn't going to be useful is most \n> cases (might be worthwhile to keep \"git log\" from eating all your memory, \n> though), and that using CR to rewrite lines isn't going to work.\n\nI think we pay attention to \"dumb\" when deciding if pager is useful and if\nwe can do color, but I do not think we check anything beyond \"is it a tty\"\nwhen deciding to show progress or not.  The only thing we do differently\nfor \"dumb\" terminal is if we use ANSI clear-to-eol escape sequence or fill\nwith a run of SPs to overwrite trailing part of a line, and we assume even\ndumb terminals know how to do a carriage-return.\n"},{"id":"101517","messageId":"e2b179460901220204x7b6a43b5hddfee623d2425429@mail.gmail.com","threadId":"17271","inReplyTo":"7vbptzahra.fsf@gitster.siamese.dyndns.org","subject":"Re: CR codes from git commands","fromName":"Mike Ralphson","fromEmail":"mike.ralphson@gmail.com","sentAt":"2009-01-22T10:04:16Z","receivedAt":"2009-01-22T10:04:16Z","isPatch":false,"sender":{"key":"mike.ralphson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/21603?v=4"},"body":">2009/1/22 Brent Goodrick <bgoodr@gmail.com>:\n> The environment I'm running git under is the Shell mode inside GNU\n> Emacs. I can't tell you what type of terminal it is, because I believe\n> that is defined deep in the guts of Emacs. Having read your reply\n> above, I'm now wondering whether this is an Emacs issue versus a git\n> issue. If it is an Emacs issue, then I am truly embarrassed for having\n> wasted everyones time with it.\n\n2009/1/22 Junio C Hamano <gitster@pobox.com>:\n> I think we pay attention to \"dumb\" when deciding if pager is useful and if\n> we can do color, but I do not think we check anything beyond \"is it a tty\"\n> when deciding to show progress or not.  The only thing we do differently\n> for \"dumb\" terminal is if we use ANSI clear-to-eol escape sequence or fill\n> with a run of SPs to overwrite trailing part of a line, and we assume even\n> dumb terminals know how to do a carriage-return.\n\nI think this earlier discussion is probably relevant... I'm guessing\nthough, $EDITOR is set correctly here 8-)\n\n2008/12/17 Junio C Hamano <gitster@pobox.com>:\n> Any semi-good emacs users (let alone hackers) export PAGER=cat to be used\n> in compilation mode (and possibly shell mode), so this is not a problem in\n> practice.\n>\n> I have something like this in my .emacs:\n>\n>    (setenv \"PAGER\" \"cat\")\n>\n> I suspect (I am just a user not a hacker) this will have bad interaction\n> with emacs terminal emulation mode, but I do not use the mode, so it is\n> enough for me.\n\nMike\n"},{"id":"101534","messageId":"18808.39712.351656.138702@hungover.brentg.com","threadId":"17271","inReplyTo":"e2b179460901220204x7b6a43b5hddfee623d2425429@mail.gmail.com","subject":"Re: CR codes from git commands","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-01-22T16:13:20Z","receivedAt":"2009-01-22T16:13:20Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"\nMike Ralphson writes:\n > >2009/1/22 Brent Goodrick <bgoodr@gmail.com>:\n > > The environment I'm running git under is the Shell mode inside GNU\n > > Emacs. I can't tell you what type of terminal it is, because I believe\n > > that is defined deep in the guts of Emacs. Having read your reply\n > > above, I'm now wondering whether this is an Emacs issue versus a git\n > > issue. If it is an Emacs issue, then I am truly embarrassed for having\n > > wasted everyones time with it.\n > \n > 2009/1/22 Junio C Hamano <gitster@pobox.com>:\n > > I think we pay attention to \"dumb\" when deciding if pager is useful and if\n > > we can do color, but I do not think we check anything beyond \"is it a tty\"\n > > when deciding to show progress or not.  The only thing we do differently\n > > for \"dumb\" terminal is if we use ANSI clear-to-eol escape sequence or fill\n > > with a run of SPs to overwrite trailing part of a line, and we assume even\n > > dumb terminals know how to do a carriage-return.\n > \n > I think this earlier discussion is probably relevant... I'm guessing\n > though, $EDITOR is set correctly here 8-)\n\nI do have EDITOR set to a home-built version of gnuclient, and git\ntalks to Emacs by way of that gnuclient just fine when I'm not using the\n-m \"commit_message\" git-commit option.\n\n > \n > 2008/12/17 Junio C Hamano <gitster@pobox.com>:\n > > Any semi-good emacs users (let alone hackers) export PAGER=cat to be used\n > > in compilation mode (and possibly shell mode), so this is not a problem in\n > > practice.\n > >\n > > I have something like this in my .emacs:\n > >\n > >    (setenv \"PAGER\" \"cat\")\n > >\n > > I suspect (I am just a user not a hacker) this will have bad interaction\n > > with emacs terminal emulation mode, but I do not use the mode, so it is\n > > enough for me.\n\nI have PAGER set to \"cat\" in the environment before I run Emacs for\nthe same reason.\n\nUnfortunately, this morning when I rebooted and reloaded from scratch,\nI am now unable to reproduce the CR codes output from \"git pull\" no\nmatter what I do. I even tried the older git installed on Debian Linux\n\"testing\", and tried unsetting PAGER and GIT_PAGER, and saw the pager\nprompts and the terminal escape sequence output as I expected to\n(which is not the issue here).  I can't expect anyone else to help me\ndebug this problem further if I can't even reproduce it\nanymore. Frustrating.\n\nI do have automatic updates turned on, so perhaps something changed in\nthe termcap or how terminal I/O is being done outside of git in my\nsystem.  Emacs would not have changed since I build Emacs from top of\ntrunk CVS, and it only uses local Elisp packages AFAIK.\n\nI don't suppose git has any logic that emits the progress messages\nbased upon some estimate of amount of work it has to do, or has done,\ndoes it?\n\nThanks,\nBrent\n\nP.S., for your reference, below is my evaluation script that\npreviously showed the CR code from git pull output. I even increased\nthe number of files added to the second repo up to 50 to see if the\nquantity of files being pulled had any effect on the progress messages\noutput, but that didn't seem to have any effect. If anyone sees\nanything bone-headed there, I'm all ears:\n\n--- cut below this line --- \n#!/bin/sh\n# -*-mode: Shell-script; indent-tabs-mode: nil; -*-\n\n# I could have simply used \"set -x\" here but then I wouldn't see the\n# redirection syntax like \">file1\", so instead use a PrintRun\n# function:\nPrintRun ()\n{\n    echo \"COMMAND: $*\"\n    eval \"$*; exitcode=\\$?\"\n    if [ $exitcode != 0 ]\n    then\n        echo \"ERROR: Command failed: $*\"\n        exit 1\n    fi\n}\n\ngit_term_redirect=\"\"\nif [ \"$USE_GIT_TERM_REDIRECT\" = 1 ]\nthen\n    git_term_redirect=\" 2>&1 | cat\"\n    echo \"Note: using git redirect on some git git commands: \\\"$git_term_redirect\\\"\"\nfi\n\nif [ \"$USE_LOCALLY_BUILT_GIT\" = 1 ]\nthen\n    git_bin_dir=\"$HOME/git_from_source/install/bin\"\n    if [ -d \"$git_bin_dir\" ]\n    then\n        PATH=\"$HOME/git_from_source/install/bin:$PATH\"; export PATH\n    fi\nfi\n\nif [ \"$SKIP_PAGER_HACK\" = 1 ]\nthen\n    unset PAGER\n    echo \"Note: setting PAGER to $PAGER\"\nelse\n    echo \"Note: unsetting PAGER\"\n    PAGER=cat; export PAGER\nfi\n\n# Print out the git version as a double check on the above logic:\nPrintRun git --version\n# Clear out the scratch areas:\nPrintRun rm -rf /tmp/git_area1\nPrintRun rm -rf /tmp/git_area2\n# Populate the initial area:\nPrintRun mkdir -p /tmp/git_area1\nPrintRun cd /tmp/git_area1\nPrintRun git init\nPrintRun \"echo a new file 1 >file1\"\nPrintRun \"echo a new file 2 >file2\"\nPrintRun git add file1\nPrintRun git add file2\nPrintRun git status\nPrintRun \"git commit -m \\\"first commit in git_area1\\\"\"\nPrintRun find .\n# Clone from the first area into a second area and add files there:\nPrintRun rm -rf /tmp/git_area2\nPrintRun cd /tmp\nPrintRun git clone /tmp/git_area1 git_area2\n\nPrintRun cd /tmp/git_area2\nPrintRun find .\ni=1\nwhile [ $i -le 50 ]\ndo\n    file=\"file_$i\"\n    echo \"file==\\\"${file}\\\"\"\n    PrintRun \"echo a new file >$file\"\n    PrintRun git add $file\n    PrintRun git status\n    PrintRun \"git commit -m \\\"committing new file $file but in git_area2\\\"\"\n    #    PrintRun \"git status; true\" # true means don't fail inside PrintRun\n    i=`expr $i + 1`\ndone\n\n# Now attempt to pull the second repo changes back into into the first repo with a \"git pull\" operation:\n\nPrintRun cd /tmp/git_area1\nPrintRun \"git status; true\" # true means don't fail inside PrintRun\nPrintRun \"git diff; true\" # true means don't fail inside PrintRun\nif [ \"$INJECT_TERM\" != \"\" ]\nthen\n    echo \"Note: Exporting environment variable: TERM=\\\"$INJECT_TERM\\\"\"\n    TERM=\"$INJECT_TERM\"; export TERM\nfi\nPrintRun \"git pull /tmp/git_area2 master $git_term_redirect\"\n# if [ \"$STOP_AFTER_FIRST_GIT_PULL\" = 1 ]\n# then\n#     echo \"Note: Stopping after first git pull\"\n#     env | grep -i term\n#     exit 0\n# fi\nPrintRun \"git status; true\" # true means don't fail inside PrintRun\nPrintRun cat file_3\nPrintRun \"echo conflict1 >>file_3\"\nPrintRun git add file_3\nPrintRun git status\nPrintRun \"git commit -m \\\"conflict1 added in git_area1\\\"\"\n\nPrintRun cd /tmp/git_area2\nPrintRun \"echo conflict2 >>file_3\"\nPrintRun git add file_3\nPrintRun git status\nPrintRun \"git commit -m \\\"conflict2 added in git_area2\\\"\"\n\n\nPrintRun cd /tmp/git_area1\nPrintRun \"git status; true\" # true means don't fail inside PrintRun\nPrintRun \"git diff; true\" # true means don't fail inside PrintRun\n# This git pull should show the conflict:\nPrintRun \"git pull /tmp/git_area2 master $git_term_redirect\"\nPrintRun cat file_3\nPrintRun \"echo conflict resolved > file_3\"\n# Running git commit now will fail:\n### PrintRun \"git commit -m \\\"conflict resolved\\\"\"\n# Running git add on the file I just \"resolved\" by editing it directly above\nPrintRun git add file_3\nPrintRun \"git status; true\" # true means don't fail inside PrintRun\nPrintRun \"git commit -m \\\"conflict resolved\\\"\"\nPrintRun \"git log\"\n--- cut above this line --- \n"},{"id":"101540","messageId":"e2b179460901220841h17c9eda2h38e8baff2964dac3@mail.gmail.com","threadId":"17271","inReplyTo":"18808.39712.351656.138702@hungover.brentg.com","subject":"Re: CR codes from git commands","fromName":"Mike Ralphson","fromEmail":"mike.ralphson@gmail.com","sentAt":"2009-01-22T16:41:10Z","receivedAt":"2009-01-22T16:41:10Z","isPatch":false,"sender":{"key":"mike.ralphson@gmail.com","avatar":"https://avatars.githubusercontent.com/u/21603?v=4"},"body":"2009/1/22 Brent Goodrick <bgoodr@gmail.com>:\n> Mike Ralphson writes:\n>  > I think this earlier discussion is probably relevant... I'm guessing\n>  > though, $EDITOR is set correctly here 8-)\n>\n> I do have EDITOR set to a home-built version of gnuclient...\n\nSorry, I was being too subtle. My $EDITOR is set to vim, as god intended. 8-)\n\nMike\n"},{"id":"101541","messageId":"alpine.LNX.1.00.0901221117110.19665@iabervon.org","threadId":"17271","inReplyTo":"18808.39712.351656.138702@hungover.brentg.com","subject":"Re: CR codes from git commands","fromName":"Daniel Barkalow","fromEmail":"barkalow@iabervon.org","sentAt":"2009-01-22T16:44:03Z","receivedAt":"2009-01-22T16:44:03Z","isPatch":false,"sender":{"key":"barkalow@iabervon.org","avatar":"https://avatars.githubusercontent.com/u/55364219?v=4"},"body":"On Thu, 22 Jan 2009, Brent Goodrick wrote:\n\n> Mike Ralphson writes:\n>  > >2009/1/22 Brent Goodrick <bgoodr@gmail.com>:\n>  > > The environment I'm running git under is the Shell mode inside GNU\n>  > > Emacs. I can't tell you what type of terminal it is, because I believe\n>  > > that is defined deep in the guts of Emacs. Having read your reply\n>  > > above, I'm now wondering whether this is an Emacs issue versus a git\n>  > > issue. If it is an Emacs issue, then I am truly embarrassed for having\n>  > > wasted everyones time with it.\n>  > \n>  > 2009/1/22 Junio C Hamano <gitster@pobox.com>:\n>  > > I think we pay attention to \"dumb\" when deciding if pager is useful and if\n>  > > we can do color, but I do not think we check anything beyond \"is it a tty\"\n>  > > when deciding to show progress or not.  The only thing we do differently\n>  > > for \"dumb\" terminal is if we use ANSI clear-to-eol escape sequence or fill\n>  > > with a run of SPs to overwrite trailing part of a line, and we assume even\n>  > > dumb terminals know how to do a carriage-return.\n>  > \n>  > I think this earlier discussion is probably relevant... I'm guessing\n>  > though, $EDITOR is set correctly here 8-)\n> \n> I do have EDITOR set to a home-built version of gnuclient, and git\n> talks to Emacs by way of that gnuclient just fine when I'm not using the\n> -m \"commit_message\" git-commit option.\n> \n>  > \n>  > 2008/12/17 Junio C Hamano <gitster@pobox.com>:\n>  > > Any semi-good emacs users (let alone hackers) export PAGER=cat to be used\n>  > > in compilation mode (and possibly shell mode), so this is not a problem in\n>  > > practice.\n>  > >\n>  > > I have something like this in my .emacs:\n>  > >\n>  > >    (setenv \"PAGER\" \"cat\")\n>  > >\n>  > > I suspect (I am just a user not a hacker) this will have bad interaction\n>  > > with emacs terminal emulation mode, but I do not use the mode, so it is\n>  > > enough for me.\n> \n> I have PAGER set to \"cat\" in the environment before I run Emacs for\n> the same reason.\n> \n> Unfortunately, this morning when I rebooted and reloaded from scratch,\n> I am now unable to reproduce the CR codes output from \"git pull\" no\n> matter what I do. I even tried the older git installed on Debian Linux\n> \"testing\", and tried unsetting PAGER and GIT_PAGER, and saw the pager\n> prompts and the terminal escape sequence output as I expected to\n> (which is not the issue here).  I can't expect anyone else to help me\n> debug this problem further if I can't even reproduce it\n> anymore. Frustrating.\n> \n> I do have automatic updates turned on, so perhaps something changed in\n> the termcap or how terminal I/O is being done outside of git in my\n> system.  Emacs would not have changed since I build Emacs from top of\n> trunk CVS, and it only uses local Elisp packages AFAIK.\n> \n> I don't suppose git has any logic that emits the progress messages\n> based upon some estimate of amount of work it has to do, or has done,\n> does it?\n\nIt does have logic to only emit progress messages at a reasonable rate \n(otherwise, you might be waiting for the progress messages to be printed \ninstead of just waiting for the data to arrive). So it's possible that you \nnow have things going fast enough that it only needs to print one message. \nIt can also estimate that something hasn't taken long enough for the user \nto get impatient yet, and therefore not show progress at all (so the \noutput won't be littered with progress output for every operation that \ncould have taken a long time for some data, but didn't for this data).\n\nIn any case, it's all done in progress.c, so it should be easy enough to \nmake changes to if you can come up with something better to do with \nprogress messages and some way to determine when it should be done.\n\n\t-Daniel\n*This .sig left intentionally blank*\n"},{"id":"101545","messageId":"alpine.DEB.1.00.0901221749030.3586@pacific.mpi-cbg.de","threadId":"17271","inReplyTo":"e2b179460901220841h17c9eda2h38e8baff2964dac3@mail.gmail.com","subject":"Re: CR codes from git commands","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-22T16:50:49Z","receivedAt":"2009-01-22T16:50:49Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Jan 2009, Mike Ralphson wrote:\n\n> My $EDITOR is set to vim, as god intended. 8-)\n\nSorry, that is not true: from\n\nhttp://www.biblegateway.com/passage/?book_id=50&chapter=1&verse=1&version=31&context=verse\n\nwe know that in the beginning was the Word.\n\nCiao,\nDscho\n"},{"id":"101546","messageId":"alpine.DEB.1.00.0901221751320.3586@pacific.mpi-cbg.de","threadId":"17271","inReplyTo":"alpine.LNX.1.00.0901221117110.19665@iabervon.org","subject":"Re: CR codes from git commands","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-22T16:52:27Z","receivedAt":"2009-01-22T16:52:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 22 Jan 2009, Daniel Barkalow wrote:\n\n> In any case, it's all done in progress.c, so it should be easy enough to \n> make changes to if you can come up with something better to do with \n> progress messages and some way to determine when it should be done.\n\nMaybe \"git --no-progress <program>\" would be a sensible user interface?\n\nCiao,\nDscho\n"},{"id":"101662","messageId":"18809.60512.654436.59819@hungover.brentg.com","threadId":"17271","inReplyTo":"alpine.DEB.1.00.0901221751320.3586@pacific.mpi-cbg.de","subject":"Re: CR codes from git commands","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-01-23T16:12:16Z","receivedAt":"2009-01-23T16:12:16Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"\n\nJohannes Schindelin writes:\n > Hi,\n > \n > On Thu, 22 Jan 2009, Daniel Barkalow wrote:\n > \n > > In any case, it's all done in progress.c, so it should be easy enough to \n > > make changes to if you can come up with something better to do with \n > > progress messages and some way to determine when it should be done.\n > \n > Maybe \"git --no-progress <program>\" would be a sensible user\n > interface?\n\nThanks. I now see the \\r reference inside the \"display\" file-static\nfunction inside progress.c.\n\nHowever, I propose to add two options, the first being, IMO, the\nminimal one to implement, and the second being \"nice-to-have\":\n\n - Bare minimum: Add a new --no-cr option (e.g., \"git --no-cr\n   <program>\") that would prevent any git code (inside progress.c or\n   elsewhere) from emitting a CR code from stdout or stderr.  This has\n   the effect of allowing progress messages, but not asking too much\n   of terminals-that-are-not-really-terminals such as the GNU Emacs\n   shell mode.\n\n - Nice-to-have: Add a \"git --no-progress\" message that would never\n   show progress at all (e.g., perhaps by not installing a signal\n   handler inside progress.c such that no messages would not be\n   emitted at all.\n\nBoth options are intended to be independent of each other.\n\nAnd for both options, I would like there to be a config option to\nallow the user to enable said behavior globally across all git\noperations covered by that config file.\n\nI might be willing to take a swipe at this myself and submit a patch,\nprovided I receive adequate noobie hand-holding (or hand-slapping) on\npatch submission and test case development.\n\nbg\n"},{"id":"101664","messageId":"7v63k6x8j7.fsf@gitster.siamese.dyndns.org","threadId":"17271","inReplyTo":"18809.60512.654436.59819@hungover.brentg.com","subject":"Re: CR codes from git commands","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-23T16:59:56Z","receivedAt":"2009-01-23T16:59:56Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brent Goodrick <bgoodr@gmail.com> writes:\n\n>  - Bare minimum: Add a new --no-cr option (e.g., \"git --no-cr\n>    ...\n>  - Nice-to-have: Add a \"git --no-progress\" message that would never\n>  ...\n> Both options are intended to be independent of each other.\n\nI do not think so.  --no-progress should imply --no-cr ;-)\n\nI do not think it makes much sense to pollute your non-terminal with 100\nlines of 1%,2%,3%,...100% if it cannot sensibly do carriage-returns.  It\nmay be another knob to tweak, but it's a kind of thing you implement\nbecause you could, not because it makes sense.  I would be mildly against\nno-cr.\n\nI suspect we may even be able to solve it without adding --no-progress.\nPerhaps some commands do not have --quiet to squelch progress and teaching\nthem --quiet will solve the issue for you?\n"},{"id":"101678","messageId":"alpine.DEB.1.00.0901231747340.21467@intel-tinevez-2-302","threadId":"17271","inReplyTo":"18809.60512.654436.59819@hungover.brentg.com","subject":"Re: CR codes from git commands","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-23T18:41:27Z","receivedAt":"2009-01-23T18:41:27Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Fri, 23 Jan 2009, Brent Goodrick wrote:\n\n>  - Bare minimum: Add a new --no-cr option\n\nI do not see any value of this over \"--progress | tr '\\r' '\\n'\".  (The \n--progress option being the natural counterpart to --no-progress, \n_forcing_ the display of the progress.)\n\nAnd I disagree that --no-progress would be hard to implement.  Just have a \nlook at 7d1864c(Introduce is_bare_repository() and core.bare configuration \nvariable).\n\nBasically, you'll have to\n\n- introduce a global variable to both environment.c and cache.h,\n\n- set it to -1 by default,\n\n- handle a \"--progress\" and \"--no-progress\" option in git.c, setting the \n  global variable git_show_progress to 1 or 0, respectively,\n\n- teach start_progress_delay() to return NULL if git_show_progress == 0,\n\n- modify all users of start_progress*() to respect git_show_progress == 1,\n  which probably means to look for \"isatty\" in builtin-pack-objects.c and \n  builtin-unpack-objects.c\n\n- add documentation to Documentation/git.txt what --progress and \n  --no-progress do,\n\n- add a simple test script to t/ (maybe t/t0005-progress.sh) that tests \n  that --progress works -- maybe you find a clever way to test \n  --no-progress, too, but that would be harder, as the progress is turned \n  off by default for the scripts anyway...)\n\nHth,\nDscho\n"},{"id":"101781","messageId":"18811.32772.728276.923430@hungover.brentg.com","threadId":"17271","inReplyTo":"alpine.DEB.1.00.0901231747340.21467@intel-tinevez-2-302","subject":"Re: CR codes from git commands","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-01-24T20:54:28Z","receivedAt":"2009-01-24T20:54:28Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"\nJunio C Hamano writes:\n > I do not think so.  --no-progress should imply --no-cr ;-)\n > \n > I do not think it makes much sense to pollute your non-terminal with 100\n > lines of 1%,2%,3%,...100% if it cannot sensibly do carriage-returns.  It\n > may be another knob to tweak, but it's a kind of thing you implement\n > because you could, not because it makes sense.  I would be mildly against\n > no-cr.\n\nGood point. I'll drop the --no-cr as redundant.\n\nJohannes Schindelin writes:\n > Hi,\n > \n > On Fri, 23 Jan 2009, Brent Goodrick wrote:\n > \n > >  - Bare minimum: Add a new --no-cr option\n > \n > I do not see any value of this over \"--progress | tr '\\r' '\\n'\".  (The \n > --progress option being the natural counterpart to --no-progress, \n > _forcing_ the display of the progress.)\n\nAgreed. Both --progress and --no-progress are the only options to be\nimplemented for this.  \n\n > Just have a \n > look at 7d1864c(Introduce is_bare_repository() and core.bare configuration \n > variable).\n\nNote that I'm coming from a CVS and Perforce user background but am\nstill new to git usage. How do I \"take a look\" at \"7d1864c\"?\n\nI will take a closer look at the list of things you explained in your\n\"Basically, you'll have to\" list.\n\nWhile I'm at it, what is the standard procedure for submitting git\npatches for review once I've cooked up and validated it on my end? I'm\nguessing posting the patch into this mailing list is part of the\nanswer to that question.\n\nThanks,\nBrent\n"},{"id":"101784","messageId":"alpine.DEB.1.00.0901242213020.14855@racer","threadId":"17271","inReplyTo":"18811.32772.728276.923430@hungover.brentg.com","subject":"Re: CR codes from git commands","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2009-01-24T21:14:34Z","receivedAt":"2009-01-24T21:14:34Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Sat, 24 Jan 2009, Brent Goodrick wrote:\n\n> Note that I'm coming from a CVS and Perforce user background but am \n> still new to git usage. How do I \"take a look\" at \"7d1864c\"?\n\nDo this in a checkout of git.git:\n\n$ git show 7d1864c\n\nAlternatively, you can follow this URL:\n\n\thttp://repo.or.cz/w/git.git?a=commitdiff;h=7d1864c\n\nCiao,\nDscho\n"},{"id":"101822","messageId":"200901250319.05665.bss@iguanasuicide.net","threadId":"17271","inReplyTo":"18811.32772.728276.923430@hungover.brentg.com","subject":"Re: CR codes from git commands","fromName":"Boyd Stephen Smith Jr.","fromEmail":"bss@iguanasuicide.net","sentAt":"2009-01-25T09:19:00Z","receivedAt":"2009-01-25T09:19:00Z","isPatch":false,"sender":{"key":"bss@iguanasuicide.net","avatar":"https://gravatar.com/avatar/84b95eeff194b816c1568b1339e63e4b229825298664a9037b9f1ec713ead1e3?d=mp&s=160"},"body":"On Saturday 24 January 2009, Brent Goodrick <bgoodr@gmail.com> wrote \nabout 'Re: CR codes from git commands':\n>While I'm at it, what is the standard procedure for submitting git\n>patches for review once I've cooked up and validated it on my end? I'm\n>guessing posting the patch into this mailing list is part of the\n>answer to that question.\n\nIf you've got a patch, I assume you've got a checkout.  Look in \nDocumentation/SubmittingPatches.\n-- \nBoyd Stephen Smith Jr.                     ,= ,-_-. =. \nbss@iguanasuicide.net                     ((_/)o o(\\_))\nICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-' \nhttp://iguanasuicide.net/                      \\_/     \n"},{"id":"101852","messageId":"18812.46001.81309.374547@hungover.brentg.com","threadId":"17271","inReplyTo":"200901250319.05665.bss@iguanasuicide.net","subject":"Re: CR codes from git commands","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-01-25T18:47:13Z","receivedAt":"2009-01-25T18:47:13Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"\nBoyd Stephen Smith Jr. writes:\n > On Saturday 24 January 2009, Brent Goodrick <bgoodr@gmail.com> wrote \n > about 'Re: CR codes from git commands':\n > >While I'm at it, what is the standard procedure for submitting git\n > >patches for review once I've cooked up and validated it on my end? I'm\n > >guessing posting the patch into this mailing list is part of the\n > >answer to that question.\n > \n > If you've got a patch, I assume you've got a checkout.  Look in \n > Documentation/SubmittingPatches.\n\nThanks I see that now. No, I don't have a patch yet, was struggling to\nfind that basic info that really should be front and center somewhere\non the wiki (and also access to the wiki is very slow).\n\nbg\n"},{"id":"101872","messageId":"7v3af7dsz1.fsf@gitster.siamese.dyndns.org","threadId":"17271","inReplyTo":"18811.32772.728276.923430@hungover.brentg.com","subject":"The lifecycle of a patch and the maintainer involvement","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-01-25T20:35:30Z","receivedAt":"2009-01-25T20:35:30Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Brent Goodrick <bgoodr@gmail.com> writes:\n\n> While I'm at it, what is the standard procedure for submitting git\n> patches for review once I've cooked up and validated it on my end? I'm\n> guessing posting the patch into this mailing list is part of the\n> answer to that question.\n\nYes, a guideline is in Documentation/SubmittingPatches for the initial\nsubmission.  After that, the lifecycle of a patch submitted on the list\ngoes like this:\n\n (1) A patch is shown to the list participants.\n\n (2) People may like it, or may have issues with it, and responds with\n     their comments describing problems, suggestions for improvements,\n     etc.  People who are not interested in the topic may stay silent.\n\n (3) The original author responds with updated patch.  Sometimes people\n     who commented on in step 2 may even send \"here is how I would do this\n     one; don't you think this is better?\", and the original author may\n     say \"Yeah, let's use yours instead\".\n\n (4) After steps 2 and 3 repeats zero or more times, the latest patch may\n     become one that everyone likes, or at least nobody has trouble with\n     inclusion.  The author sends such a patch saying \"this is meant for\n     inclusion based on discussion and refinements in these threads...\".\n\n (5) The maintainer picks it up when it looks polished enough.\n\nYour patch may appear in the periodical \"What's cooking\" or \"What's in\"\nsummary with zero iteration of steps 2 and 3 if it is obvious enough.\n\nI act as just one of the list participant during steps 1-3.  I may stay\nsilent during this period but that only means the topic is not interesting\nto me and nothing more.  It does not mean that the topic has no chance of\ngetting included.\n\nI act as the maintainer for steps 4 and 5.  If you do not hear from me\nafter step 4, then I am either being lazy, busy, or sick, or the patch got\nlost in the noise and I need a reminder.  Note that I may reject or ask\nfurther refinement at step 4 to ensure overall quality throughout the\nsystem even in areas I am not interested in and didn't say anything during\nsteps 1-3.\n"},{"id":"102830","messageId":"e38bce640902012309o25d64d1fs6c0bed04169a44e6@mail.gmail.com","threadId":"17271","inReplyTo":"200901250319.05665.bss@iguanasuicide.net","subject":"Re: CR codes from git commands","fromName":"Brent Goodrick","fromEmail":"bgoodr@gmail.com","sentAt":"2009-02-02T07:09:38Z","receivedAt":"2009-02-02T07:09:38Z","isPatch":false,"sender":{"key":"bgoodr@gmail.com","avatar":"https://gravatar.com/avatar/2399bf5a3468b3516a892183edfd43a7fa0300a2e9d5072189020186961150bc?d=mp&s=160"},"body":"I'm nearing completion on the patch for the --progress and\n--no-progress command-line options.  I am able to manually validate\nthe behavior, but am a bit stumped as to how to efficiently code up\nthe test script.  My manual test involves doing a git clone of the git\nrepository, which produces the volume of I/O sufficiently bulky to\ntrigger the progress message code.  But that bulk means that the test\ncase will take a long time to complete, hence making using a git clone\nof the git code in the test case impractical.\n\nAlso, in order for the script to do its job, it will need to tell the\ndifference between a git run that has progress from one that does not.\n The first idea would be to simply use shell command redirection on\nthe git command itself, but that defeats the tty detection logic, so I\ndon't think that is an option either.\n\nDoes anyone have any recommendations here? If not, then I guess I will\nhave to forgo the test script and just submit the patch without it.\n\nThanks,\nBrent\n\nOn Sun, Jan 25, 2009 at 1:19 AM, Boyd Stephen Smith Jr.\n<bss@iguanasuicide.net> wrote:\n>\n> On Saturday 24 January 2009, Brent Goodrick <bgoodr@gmail.com> wrote\n> about 'Re: CR codes from git commands':\n> >While I'm at it, what is the standard procedure for submitting git\n> >patches for review once I've cooked up and validated it on my end? I'm\n> >guessing posting the patch into this mailing list is part of the\n> >answer to that question.\n>\n> If you've got a patch, I assume you've got a checkout.  Look in\n> Documentation/SubmittingPatches.\n> --\n> Boyd Stephen Smith Jr.                     ,= ,-_-. =.\n> bss@iguanasuicide.net                     ((_/)o o(\\_))\n> ICQ: 514984 YM/AIM: DaTwinkDaddy           `-'(. .)`-'\n> http://iguanasuicide.net/                      \\_/\n"}]}