{"thread":{"id":"3557","subject":"git-status too verbose?","startedAt":"2006-03-04T17:52:17Z","lastAt":"2006-03-07T18:26:34Z","messageCount":12,"participants":["Eric Jaffe","Carl Worth","Shawn Pearce","Junio C Hamano","Joshua N Pritikin","Karl Hasselström","Andreas Ericsson","Johannes Schindelin","Linus Torvalds"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"17153","messageId":"38b80e980603040952j15152a21h2c903bd011d7e905@mail.gmail.com","threadId":"3557","inReplyTo":null,"subject":"git-status too verbose?","fromName":"Eric Jaffe","fromEmail":"jaffe.eric@gmail.com","sentAt":"2006-03-04T17:52:17Z","receivedAt":"2006-03-04T17:52:17Z","isPatch":false,"sender":{"key":"jaffe.eric@gmail.com","avatar":null},"body":"I was wondering if anyone else thinks that git-status should be more\nlike \"git-diff --name-status\". That is,\n  # A a/newfile.c\n  # M a/oldfile.c\n\ninstead of\n  # new file: a/newfile.c\n  # modified: a/oldfile.c\n\nThis would be similar to cg-status and \"svn status\", etc.\n\n--\nEric Jaffe <jaffe.eric@gmail.com>\n"},{"id":"17261","messageId":"87irqrzcs7.wl%cworth@cworth.org","threadId":"3557","inReplyTo":"38b80e980603040952j15152a21h2c903bd011d7e905@mail.gmail.com","subject":"Re: git-status too verbose?","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-03-06T17:46:48Z","receivedAt":"2006-03-06T17:46:48Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Sat, 4 Mar 2006 12:52:17 -0500, \"Eric Jaffe\" wrote:\n> I was wondering if anyone else thinks that git-status should be more\n> like \"git-diff --name-status\". That is,\n>   # A a/newfile.c\n>   # M a/oldfile.c\n\nSomething like that does seem appealing.\n\nThere are at least two issues with doing it:\n\n1) It might be tricky coming up with canonical single characters to be\n   used consistently within git. For example, git-ls-files currently\n   does do some single-character state indication, but it can be\n   rather confusing at times. For example:\n\n\tState\t\tOption\tCharacter\n\t-----\t\t------\t---------\n\tModified\t-m\tC\n\tUnmerged\t-u\tM\n\tCached\t\t-c\tH\n\n   And that looks like a permanent problem. For legacy reasons,\n   I don't think we can change either the options or the output\n   characters of git-ls-files. But perhaps we could at least\n   agree on a single, consistent mapping for all future uses.\n\n2) In an important sense, git-status is not verbose enough. For\n   example, given a single line such as the following:\n\n\tmodified: some-file\n\n   This could indicate at least two different states for some-file:\n\n\t1) Modified and updated into the index\n\n\t2) Modified in working tree, but not updated in the index\n\n   Currently, git-status makes this distinction only in the header\n   lines for the separate chunks of its output. But, when there are a\n   lot of files involved, and things start scrolling, it's sometimes\n   \"hard\" to associate the right header with the file of interest.\n\n   So, what I've wanted from git-status is a complete encoding of the\n   file's state on the same line as the output of the filename.  Maybe\n   something that uses two characters per file would work well.\n\n   But I don't have a concrete suggestion for that---I don't think\n   I've even successfully enumerated all possible file states with git\n   yet...\n\n-Carl\n\nPS. If we do tighten up the output of git-status, I'd also vote for\nmaking the per-chunk headers use only 1 line each instead of 2, and\nalso eliminating the second blank line separating each chunk.\n"},{"id":"17262","messageId":"20060306175614.GG27965@spearce.org","threadId":"3557","inReplyTo":"87irqrzcs7.wl%cworth@cworth.org","subject":"Re: git-status too verbose?","fromName":"Shawn Pearce","fromEmail":"spearce@spearce.org","sentAt":"2006-03-06T17:56:14Z","receivedAt":"2006-03-06T17:56:14Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Carl Worth <cworth@cworth.org> wrote:\n> On Sat, 4 Mar 2006 12:52:17 -0500, \"Eric Jaffe\" wrote:\n> > I was wondering if anyone else thinks that git-status should be more\n> > like \"git-diff --name-status\". That is,\n> >   # A a/newfile.c\n> >   # M a/oldfile.c\n> \n> Something like that does seem appealing.\n> \n> There are at least two issues with doing it:\n> \n> 1) It might be tricky coming up with canonical single characters to be\n>    used consistently within git. For example, git-ls-files currently\n>    does do some single-character state indication, but it can be\n>    rather confusing at times. For example:\n> \n> \tState\t\tOption\tCharacter\n> \t-----\t\t------\t---------\n> \tModified\t-m\tC\n> \tUnmerged\t-u\tM\n> \tCached\t\t-c\tH\n> \n>    And that looks like a permanent problem. For legacy reasons,\n>    I don't think we can change either the options or the output\n>    characters of git-ls-files. But perhaps we could at least\n>    agree on a single, consistent mapping for all future uses.\n> \n> 2) In an important sense, git-status is not verbose enough. For\n>    example, given a single line such as the following:\n> \n> \tmodified: some-file\n> \n>    This could indicate at least two different states for some-file:\n> \n> \t1) Modified and updated into the index\n> \n> \t2) Modified in working tree, but not updated in the index\n\nI've played around with this idea a little bit in pg's pg-status\ncommand but I most likely do not have all cases covered.\n\nIn general I try to show HEAD<-->index first using uppercase letters\nthen index<-->working directory second in lowercase letters.\n\nHere's the critical portion of pg-status:\n\n\tgit-diff-index --cached --name-status HEAD | sed -e 's/ / /'\n\tif test $index_only  = n\n\tthen\n\t  git-diff-files --name-status | sed \\\n\t\t-e 's/      / /' \\\n\t\t-e 's/^D /g /' \\\n\t\t-e 's/^M /m /' \\\n\t\t-e '/^U /d'\n\t  pg--ls-others | sed 's/^/x /'\n\tfi\n\nThus far I've found it useful to behave this way and I haven't run\nup against any states which didn't make immediate sense to me.\nHere's the documentation I have in pg-status describing what it\ncan show:\n\nStatus indicators (displayed in column 1):\n\n A : New file has been marked for addition with pg-add.\n D : Existing file has been marked as deleted with pg-rm.\n M : Existing file has been modified (and is known to the index).\n U : File still has unmerged hunks, see pg-resolved.\n\n m : Existing file (maybe) has been modified (use -q to know for sure).\n g : File has been removed from directory but not marked with pg-rm.\n x : File is not known to repository and isn't being ignored.\n\n-- \nShawn.\n"},{"id":"17271","messageId":"7vacc36r4v.fsf@assigned-by-dhcp.cox.net","threadId":"3557","inReplyTo":"38b80e980603040952j15152a21h2c903bd011d7e905@mail.gmail.com","subject":"Re: git-status too verbose?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-07T00:21:52Z","receivedAt":"2006-03-07T00:21:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Eric Jaffe\" <jaffe.eric@gmail.com> writes:\n\n> I was wondering if anyone else thinks that git-status should be more\n> like \"git-diff --name-status\". That is,\n>   # A a/newfile.c\n>   # M a/oldfile.c\n>\n> instead of\n>   # new file: a/newfile.c\n>   # modified: a/oldfile.c\n\nWhy do people think mysterious single letter abbreviation is\nbetter than spelled out words in an output meant for human\nconsumption?\n\nThe tag letters you get from \"ls-files -t\" are inconsistent with\nwhat you would get from all the other git tools for historical\nreasons, so if you want to do a single-letter abbreviation, you\nfirst need to come up with a set of letters and translate the\noutput from ls-files -t into that.\n\nAlthough I personally like Carl's suggestion a lot, I am still\nambivalent about it a bit.\n\nI agree that it would be useful if we had a tool that showed the\ntwo status that matter for each file, grouped together on one\nline, e.g.\n\n\t\t\tHEAD->index\tindex->files\n\t------------------------------------------------\n\thello.c\t\tunmodified      modified\n        world.c\t\tmodified\tunmodified\n\tfrotz.c\t\tnew\t\tunmodified\n        ...\n\tgarbage.c~\t???\t\tn/a\n\nfor the current index file and the current HEAD commit.\n\nYou obviously need to learn how to read it though.  The first\ncolumn means what you _would_ commit if you just said \"git\ncommit\" without doing anything else now; the second column is\nwhat you _could_ commit if you did some update-index and then\nsaid \"git commit\" (or ran \"git commit\" with paths arguments).\n\nI think it is a valid view for people who know how internally\ngit barebone porcelain works using git lowlevel, and to them\n(including me), the above is more concise and appear useful.\n\nBut I am not sure if it is appropriate for \"git status\", which\nis the tool for commit-preview.  The index \"git status\" is\nshowing is the index you would get if you were to run \"git\ncommit\" with the same set of parameters, exactly for that reason\n(e.g. \"git status -a -v\" would see \"unmodified\" for all tracked\npaths in index->files column in the above output). \n"},{"id":"17280","messageId":"20060307053547.GK6346@always.joy.eth.net","threadId":"3557","inReplyTo":"7vacc36r4v.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-status too verbose?","fromName":"Joshua N Pritikin","fromEmail":"jpritikin@pobox.com","sentAt":"2006-03-07T05:35:47Z","receivedAt":"2006-03-07T05:35:47Z","isPatch":false,"sender":{"key":"jpritikin@pobox.com","avatar":"https://gravatar.com/avatar/3f2561fdd7efac4e127dc65ac7e06f044069c115dcc94d0ac540f4126d47759d?d=mp&s=160"},"body":"On Mon, Mar 06, 2006 at 04:21:52PM -0800, Junio C Hamano wrote:\n> \t\t\tHEAD->index\tindex->files\n> \t------------------------------------------------\n> \thello.c\t\tunmodified      modified\n>         world.c\t\tmodified\tunmodified\n> \tfrotz.c\t\tnew\t\tunmodified\n>         ...\n> \tgarbage.c~\t???\t\tn/a\n\nFor what it's worth, this chart immediately made sense to me and I would\nprefer it to the current git-status output.\n"},{"id":"17285","messageId":"20060307091717.GA16645@diana.vm.bytemark.co.uk","threadId":"3557","inReplyTo":"20060307053547.GK6346@always.joy.eth.net","subject":"Re: git-status too verbose?","fromName":"Karl Hasselström","fromEmail":"kha@treskal.com","sentAt":"2006-03-07T09:17:17Z","receivedAt":"2006-03-07T09:17:17Z","isPatch":false,"sender":{"key":"kha@treskal.com","avatar":"https://gravatar.com/avatar/f0120c734b5279b345075a28521e1ac66acb20c9913ffe9bf6ae97e53f7f3f13?d=mp&s=160"},"body":"On 2006-03-07 11:05:47 +0530, Joshua N Pritikin wrote:\n\n> On Mon, Mar 06, 2006 at 04:21:52PM -0800, Junio C Hamano wrote:\n>\n> >                     HEAD->index     index->files\n> >     ------------------------------------------------\n> >     hello.c         unmodified      modified\n> >     world.c         modified        unmodified\n> >     frotz.c         new             unmodified\n> >         ...\n> >     garbage.c~      ???             n/a\n>\n> For what it's worth, this chart immediately made sense to me and I\n> would prefer it to the current git-status output.\n\nI agree. This kind of status information makes the whole index concept\nan order of magnitude less confusing. In a way, it lets you learn what\nthe index is by example, rather than first having to learn what it is\nin order to be able to grok the status information.\n\nFitting this in 80 columns should be a funny excercise, though. :-)\nI'd suggest printing the filename last:\n\n     HEAD->index  index->files\n     ------------------------------------------------\n     unmodified   modified      hello.c\n     modified     unmodified    world.c\n     new          unmodified    frotz.c\n         ...\n     ???          n/a           garbage.c~\n\n-- \nKarl Hasselström, kha@treskal.com\n      www.treskal.com/kalle\n"},{"id":"17286","messageId":"440D503E.8090007@op5.se","threadId":"3557","inReplyTo":"7vacc36r4v.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-status too verbose?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-07T09:19:58Z","receivedAt":"2006-03-07T09:19:58Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> \n> Why do people think mysterious single letter abbreviation is\n> better than spelled out words in an output meant for human\n> consumption?\n> \n\nFamiliarity, I suspect.\n\n> \n> I agree that it would be useful if we had a tool that showed the\n> two status that matter for each file, grouped together on one\n> line, e.g.\n> \n> \t\t\tHEAD->index\tindex->files\n> \t------------------------------------------------\n> \thello.c\t\tunmodified      modified\n>         world.c\t\tmodified\tunmodified\n> \tfrotz.c\t\tnew\t\tunmodified\n>         ...\n> \tgarbage.c~\t???\t\tn/a\n> \n> for the current index file and the current HEAD commit.\n> \n\nCould we have 'same' or some such instead of 'unmodified'? It's a bit \nclose to 'modified' for the eye to find it quickly.\n\n\n> You obviously need to learn how to read it though.  The first\n> column means what you _would_ commit if you just said \"git\n> commit\" without doing anything else now; the second column is\n> what you _could_ commit if you did some update-index and then\n> said \"git commit\" (or ran \"git commit\" with paths arguments).\n> \n\nPretty-printing will be easier if the filename is last, and it will look \na lot neater if all columns are aligned.\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"17288","messageId":"Pine.LNX.4.63.0603071037270.8753@wbgn013.biozentrum.uni-wuerzburg.de","threadId":"3557","inReplyTo":"20060307091717.GA16645@diana.vm.bytemark.co.uk","subject":"Re: git-status too verbose?","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2006-03-07T09:38:47Z","receivedAt":"2006-03-07T09:38:47Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Tue, 7 Mar 2006, Karl Hasselström wrote:\n\n> On 2006-03-07 11:05:47 +0530, Joshua N Pritikin wrote:\n> \n> > On Mon, Mar 06, 2006 at 04:21:52PM -0800, Junio C Hamano wrote:\n> >\n> > >                     HEAD->index     index->files\n> > >     ------------------------------------------------\n> > >     hello.c         unmodified      modified\n> > >     world.c         modified        unmodified\n> > >     frotz.c         new             unmodified\n> > >         ...\n> > >     garbage.c~      ???             n/a\n> >\n> > For what it's worth, this chart immediately made sense to me and I\n> > would prefer it to the current git-status output.\n> \n> I agree. This kind of status information makes the whole index concept\n> an order of magnitude less confusing. In a way, it lets you learn what\n> the index is by example, rather than first having to learn what it is\n> in order to be able to grok the status information.\n\nI beg to differ. The index thing is complex enough as it is. You should \nnot shy away potentially customers by such output at such often used \nplace.\n\nCiao,\nDscho\n"},{"id":"17289","messageId":"7v3bhumvt6.fsf@assigned-by-dhcp.cox.net","threadId":"3557","inReplyTo":"440D503E.8090007@op5.se","subject":"Re: git-status too verbose?","fromName":"Junio C Hamano","fromEmail":"junkio@cox.net","sentAt":"2006-03-07T09:46:29Z","receivedAt":"2006-03-07T09:46:29Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Andreas Ericsson <ae@op5.se> writes:\n\n>> I agree that it would be useful if we had a tool that showed the\n>> two status that matter for each file, grouped together on one\n>> line, e.g.\n>> \t\t\tHEAD->index\tindex->files\n>> \t------------------------------------------------\n>> \thello.c\t\tunmodified      modified\n>>         world.c\t\tmodified\tunmodified\n>> \tfrotz.c\t\tnew\t\tunmodified\n>>         ...\n>> \tgarbage.c~\t???\t\tn/a\n>> for the current index file and the current HEAD commit.\n>\n> Could we have 'same' or some such instead of 'unmodified'? It's a bit\n> close to 'modified' for the eye to find it quickly.\n>\n>> You obviously need to learn how to read it though.  The first\n>> column means what you _would_ commit if you just said \"git\n>> commit\" without doing anything else now; the second column is\n>> what you _could_ commit if you did some update-index and then\n>> said \"git commit\" (or ran \"git commit\" with paths arguments).\n>\n> Pretty-printing will be easier if the filename is last, and it will\n> look a lot neater if all columns are aligned.\n\nSomebody who feels strongly about this can propose a design.\nAlthough I am not particularly fond of the current output, I am\nnot volunteering ;-).\n\nIt would be nicer if the proposal was accompanied by a patch,\nbut that is not a requirement for discussion.\n\nThe points that design would address should include:\n\n - set of labels (full list)\n   modified, same, renamed?, untracked, ...\n - field ordering (good point by Andreas)\n   - what to do _if_ we choose to do rename detection?  you need\n     two pathnames.\n - alignment (good point by Andreas)\n"},{"id":"17290","messageId":"440D5EFF.6050300@op5.se","threadId":"3557","inReplyTo":"7v3bhumvt6.fsf@assigned-by-dhcp.cox.net","subject":"Re: git-status too verbose?","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2006-03-07T10:22:55Z","receivedAt":"2006-03-07T10:22:55Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Junio C Hamano wrote:\n> Andreas Ericsson <ae@op5.se> writes:\n> \n> \n>>>I agree that it would be useful if we had a tool that showed the\n>>>two status that matter for each file, grouped together on one\n>>>line, e.g.\n>>>\t\t\tHEAD->index\tindex->files\n>>>\t------------------------------------------------\n>>>\thello.c\t\tunmodified      modified\n>>>        world.c\t\tmodified\tunmodified\n>>>\tfrotz.c\t\tnew\t\tunmodified\n>>>        ...\n>>>\tgarbage.c~\t???\t\tn/a\n>>>for the current index file and the current HEAD commit.\n>>\n>>Could we have 'same' or some such instead of 'unmodified'? It's a bit\n>>close to 'modified' for the eye to find it quickly.\n>>\n>>\n>>>You obviously need to learn how to read it though.  The first\n>>>column means what you _would_ commit if you just said \"git\n>>>commit\" without doing anything else now; the second column is\n>>>what you _could_ commit if you did some update-index and then\n>>>said \"git commit\" (or ran \"git commit\" with paths arguments).\n>>\n>>Pretty-printing will be easier if the filename is last, and it will\n>>look a lot neater if all columns are aligned.\n> \n> \n> Somebody who feels strongly about this can propose a design.\n> Although I am not particularly fond of the current output, I am\n> not volunteering ;-).\n> \n> It would be nicer if the proposal was accompanied by a patch,\n> but that is not a requirement for discussion.\n> \n\nI'll see if I can get around to it tonight.\n\n> The points that design would address should include:\n> \n>    - what to do _if_ we choose to do rename detection?  you need\n>      two pathnames.\n\nI like the gitk view of these things, \"renamed from\" and \"renamed to\", \nalthough we'll likely want shorter names since the filename part can't \nstart before column max_label_name * 2 + 4 if we assume two spaces \nminimum between word-columns. Perhaps mv-to and mv-from?\n\n-- \nAndreas Ericsson                   andreas.ericsson@op5.se\nOP5 AB                             www.op5.se\nTel: +46 8-230225                  Fax: +46 8-230231\n"},{"id":"17305","messageId":"Pine.LNX.4.64.0603071020530.3573@g5.osdl.org","threadId":"3557","inReplyTo":"440D503E.8090007@op5.se","subject":"Re: git-status too verbose?","fromName":"Linus Torvalds","fromEmail":"torvalds@osdl.org","sentAt":"2006-03-07T18:22:28Z","receivedAt":"2006-03-07T18:22:28Z","isPatch":false,"sender":{"key":"torvalds@linux-foundation.org","avatar":"https://avatars.githubusercontent.com/u/1024025?v=4"},"body":"\n\nOn Tue, 7 Mar 2006, Andreas Ericsson wrote:\n> > \n> > I agree that it would be useful if we had a tool that showed the\n> > two status that matter for each file, grouped together on one\n> > line, e.g.\n> > \n> > \t\t\tHEAD->index\tindex->files\n> > \t------------------------------------------------\n> > \thello.c\t\tunmodified      modified\n> >         world.c\t\tmodified\tunmodified\n> > \tfrotz.c\t\tnew\t\tunmodified\n> >         ...\n> > \tgarbage.c~\t???\t\tn/a\n> > \n> > for the current index file and the current HEAD commit.\n> > \n> \n> Could we have 'same' or some such instead of 'unmodified'? It's a bit close to\n> 'modified' for the eye to find it quickly.\n\nI really _really_ hate that table anyway.\n\nWhat I want to know is \"what is committed\", and \"what is not\".\n\nThat table makes it really really hard to see what you are committing, if \nyou have a hundred files changed that are _not_ being committed. The \nactual committed information will be interspersed in the files you're not \ninterested in, and vice versa.\n\nThe current commit message is a million times superior, even if it might \nnot be as _pretty_.\n\n\t\tLinus\n"},{"id":"17306","messageId":"87zmk2xg9x.wl%cworth@cworth.org","threadId":"3557","inReplyTo":"Pine.LNX.4.64.0603071020530.3573@g5.osdl.org","subject":"Re: git-status too verbose?","fromName":"Carl Worth","fromEmail":"cworth@cworth.org","sentAt":"2006-03-07T18:26:34Z","receivedAt":"2006-03-07T18:26:34Z","isPatch":false,"sender":{"key":"cworth@cworth.org","avatar":"https://gravatar.com/avatar/3746dc28cde609bdbd7f939058356e7e2bbd16d21e32274df0725eb3d998bc5b?d=mp&s=160"},"body":"On Tue, 7 Mar 2006 10:22:28 -0800 (PST), Linus Torvalds wrote:\n> \n> What I want to know is \"what is committed\", and \"what is not\".\n\nAgreed. Me too.\n\n> That table makes it really really hard to see what you are committing, if \n> you have a hundred files changed that are _not_ being committed. The \n> actual committed information will be interspersed in the files you're not \n> interested in, and vice versa.\n\nThe current sorting and grouping should not be changed.\n\nI just want to be able to know if I'm looking at a section of\n\"committed\" vs. \"not committed\" files when the headers have scrolled\noff.\n\nI think it's really just that one bit of information needed. Maybe a\n'*' before the word 'modified' (or 'M' or whatever)?\n\n-Carl\n"}]}