{"thread":{"id":"15830","subject":"git status options feature suggestion","startedAt":"2008-10-09T05:34:41Z","lastAt":"2008-10-26T04:59:32Z","messageCount":29,"participants":["Caleb Cushing","Jeff King","Johannes Schindelin","Michael J Gruber","James Cloos","Shawn O. Pearce","Jeremy Ramer","Elijah Newren","Junio C Hamano","Jakub Narebski","Wincent Colaiuta","Teemu Likonen","Andreas Ericsson"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"92640","messageId":"81bfc67a0810082234p55e2fb9jb2a10f837eea7de0@mail.gmail.com","threadId":"15830","inReplyTo":null,"subject":"git status options feature suggestion","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2008-10-09T05:34:41Z","receivedAt":"2008-10-09T05:34:41Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"I was just doing a git status for a large add and all I really wanted\nto see was the untracked files maybe git status could have options\nlike --new --untracked --modified to only show those.\n\nI'm not on the list.\n\n--\nCaleb Cushing\n"},{"id":"92648","messageId":"20081009061136.GA24288@coredump.intra.peff.net","threadId":"15830","inReplyTo":"81bfc67a0810082234p55e2fb9jb2a10f837eea7de0@mail.gmail.com","subject":"Re: git status options feature suggestion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-09T06:11:37Z","receivedAt":"2008-10-09T06:11:37Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 09, 2008 at 01:34:41AM -0400, Caleb Cushing wrote:\n\n> I was just doing a git status for a large add and all I really wanted\n> to see was the untracked files maybe git status could have options\n> like --new --untracked --modified to only show those.\n\nHow about \"git ls-files -o\"?\n\n-Peff\n"},{"id":"92650","messageId":"81bfc67a0810082327q71b9d6apf2787eb8519031bb@mail.gmail.com","threadId":"15830","inReplyTo":"81bfc67a0810082327p421ca4e9v84f4b33023bc6fe6@mail.gmail.com","subject":"Fwd: git status options feature suggestion","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2008-10-09T06:27:49Z","receivedAt":"2008-10-09T06:27:49Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"> How about \"git ls-files -o\"?\n\ndoh... hadn't even heard of that command.\n\n-- \nCaleb Cushing\n"},{"id":"92655","messageId":"alpine.DEB.1.00.0810091101230.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"15830","inReplyTo":"81bfc67a0810082327q71b9d6apf2787eb8519031bb@mail.gmail.com","subject":"Re: Fwd: git status options feature suggestion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-09T09:03:31Z","receivedAt":"2008-10-09T09:03:31Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 9 Oct 2008, Caleb Cushing wrote:\n\n> > How about \"git ls-files -o\"?\n> \n> doh... hadn't even heard of that command.\n\nWhich is good! As ls-files is listed as plumbing. Users should not need \nto call ls-files, so I like your idea about adding --new, --untracked etc. \nto \"git status\" (I do not agree with others that \"git status\" has to stay \nthat non-existant \"git commit --dry-run\").\n\nCould you list exactly which options you want implemented?\n\nCiao,\nDscho\n"},{"id":"92678","messageId":"48EE1F58.2060707@drmicha.warpmail.net","threadId":"15830","inReplyTo":"alpine.DEB.1.00.0810091101230.22125@pacific.mpi-cbg.de.mpi-cbg.de","subject":"Re: Fwd: git status options feature suggestion","fromName":"Michael J Gruber","fromEmail":"git@drmicha.warpmail.net","sentAt":"2008-10-09T15:12:24Z","receivedAt":"2008-10-09T15:12:24Z","isPatch":false,"sender":{"key":"git@grubix.eu","avatar":"https://avatars.githubusercontent.com/u/233215?v=4"},"body":"Johannes Schindelin venit, vidit, dixit 09.10.2008 11:03:\n> Hi,\n> \n> On Thu, 9 Oct 2008, Caleb Cushing wrote:\n> \n>>> How about \"git ls-files -o\"?\n>> doh... hadn't even heard of that command.\n> \n> Which is good! As ls-files is listed as plumbing. Users should not need \n> to call ls-files, so I like your idea about adding --new, --untracked etc. \n> to \"git status\" (I do not agree with others that \"git status\" has to stay \n> that non-existant \"git commit --dry-run\").\n> \n> Could you list exactly which options you want implemented?\n\nRequests for stuff like that keep appearing recently (I'm to blame\npartially only ;) ). There are 3 issues at hand:\n\n- people are used to \"svn status [-v]\" like output which can include\nuntracked as well as tracked unmodified files; there are other valid\nreasons why you would want that info\n\n- porc can't do it: git status can't show ignored files, doesn't use\nstatus letters, can't show files with specific status; git diff\n--name-status can't show ignored nor untracked files\n[In fact, the description of \"git diff\" says \"files which you could\nadd\", which should include untracked files, but doesn't.]\n\n- plumb uses conflicting letters: git ls-files output conflicts with git\ndiff --name-status output\n\nSo I guess it's time for a usability effort in this area. A few\nquestions before going about that:\n\n- I think change of existing behaviour is unavoidable (make ls-files and\ndiff --name-status consistent). Is that something to do now or rather\nbefore 1.7? Is porc (diff) supposed to be changed or plumb (ls-files)?\n\n- How strong should the tie between git status and git commit be?\nCurrent git status is basically git commit -n, with the usual meaning of\n\"-n\" (such as for prune etc.\"), not with the current meaning of git\ncommit -n, sigh...\n\nA few radical suggestions might be:\n\n1. make ls-files and diff --name-status use compatible letters\n\n2. rename git commit -n to git commit -b (as in bypass), make git commit\n-n do what's expected (\"--dry-run\", n as in duNNo yet)\n\n3. rename git status to git commit -n\n\n4. make git status generate git diff --name-status like output\n\n(3+4)'. make git status -l generate git diff --name-status like output\n(l as in status Letter) as an alternative to 3+4\n\nMichael\n"},{"id":"92709","messageId":"m3ej2p4g3r.fsf_-_@lugabout.jhcloos.org","threadId":"15830","inReplyTo":"alpine.DEB.1.00.0810091101230.22125@pacific.mpi-cbg.de.mpi-cbg.de","subject":"ls-files [Was: Re: Fwd: git status options feature suggestion]","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2008-10-09T21:23:45Z","receivedAt":"2008-10-09T21:23:45Z","isPatch":false,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":">>>>> \"Johannes\" == Johannes Schindelin writes:\n\n>> > How about \"git ls-files -o\"?\n>> \n>> doh... hadn't even heard of that command.\n\nJohannes> Which is good! As ls-files is listed as plumbing.\nJohannes> Users should not need to call ls-files,\n\nThat is a bug, then. ls-files is one of the more important user-level\ncommands in git.\n\nIt is vastly more efficient than find(1) or a --recursive call to\ngrep(1).\n\nSearching through a repository to find which file(s) define or use some\nfunction, struct, class or similar is a common occurance. Or to find\nwhich dir(s) contain(s) file(s) matching a given regexp. Or a number\nof other uses. (Tags might be useful if one does a lot of searching\nin a given repo, but grep is quicker for infrequent searches and the\ntags utils do not support all file types.)\n\nls-files is definitely dual-use.\n\n-JimC\n-- \nJames Cloos OpenPGP: 1024D/ED7DAEA6\n"},{"id":"92710","messageId":"20081009214118.GZ8203@spearce.org","threadId":"15830","inReplyTo":"m3ej2p4g3r.fsf_-_@lugabout.jhcloos.org","subject":"Re: ls-files [Was: Re: Fwd: git status options feature suggestion]","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-10-09T21:41:18Z","receivedAt":"2008-10-09T21:41:18Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"James Cloos wrote:\n> >>>>> \"Johannes\" == Johannes Schindelin writes:\n> \n> >> > How about \"git ls-files -o\"?\n> >> \n> >> doh... hadn't even heard of that command.\n> \n> Johannes> Which is good! As ls-files is listed as plumbing.\n> Johannes> Users should not need to call ls-files,\n> \n> That is a bug, then. ls-files is one of the more important user-level\n> commands in git.\n> \n> It is vastly more efficient than find(1) or a --recursive call to\n> grep(1).\n\nHow about using \"git grep\" then? No need for ls-files...\n\n-- \nShawn.\n"},{"id":"92717","messageId":"b9fd99020810091513j21d37e0y94a387cd6d72bd2@mail.gmail.com","threadId":"15830","inReplyTo":"20081009214118.GZ8203@spearce.org","subject":"Re: ls-files [Was: Re: Fwd: git status options feature suggestion]","fromName":"Jeremy Ramer","fromEmail":"jdramer@gmail.com","sentAt":"2008-10-09T22:13:07Z","receivedAt":"2008-10-09T22:13:07Z","isPatch":false,"sender":{"key":"jdramer@gmail.com","avatar":null},"body":"On Thu, Oct 9, 2008 at 3:41 PM, Shawn O. Pearce wrote:\n> James Cloos wrote:\n>> >>>>> \"Johannes\" == Johannes Schindelin writes:\n>>\n>> >> > How about \"git ls-files -o\"?\n>> >>\n>> >> doh... hadn't even heard of that command.\n>>\n>> Johannes> Which is good! As ls-files is listed as plumbing.\n>> Johannes> Users should not need to call ls-files,\n>>\n>> That is a bug, then. ls-files is one of the more important user-level\n>> commands in git.\n>>\n>> It is vastly more efficient than find(1) or a --recursive call to\n>> grep(1).\n>\n> How about using \"git grep\" then? No need for ls-files...\n\nI use git-grep for searching the contents of files in the repo, but it\nseems to me that git ls-files is necessary for quickly parsing the\nfile names themselves.\n\n>\n> --\n> Shawn.\n> --\n> To unsubscribe from this list: send the line \"unsubscribe git\" in\n> the body of a message to majordomo@vger.kernel.org\n> More majordomo info at http://vger.kernel.org/majordomo-info.html\n>\n"},{"id":"92719","messageId":"m3od1t2xfv.fsf@lugabout.jhcloos.org","threadId":"15830","inReplyTo":"20081009214118.GZ8203@spearce.org","subject":"Re: ls-files","fromName":"James Cloos","fromEmail":"cloos@jhcloos.com","sentAt":"2008-10-09T22:52:13Z","receivedAt":"2008-10-09T22:52:13Z","isPatch":false,"sender":{"key":"cloos@jhcloos.com","avatar":"https://gravatar.com/avatar/ec9a05787d29afe41e243e4b60bd0e2f69d757688e8f0bfe5e78bc185a3e317f?d=mp&s=160"},"body":">>>>> \"Shawn\" == Shawn O Pearce writes:\n\n>> [ls-files] is vastly more efficient than find(1) or a --recursive\n>> call to grep(1).\n\nShawn> How about using \"git grep\" then? No need for ls-files...\n\nI often filter the list of files before passing them to xargs, so git\ngrep helps for some use cases, but not all.\n\nAlso, (at least as of 1.6.0.2.307.gc427), git grep does not support -P\n(Perl compatible regexps) or --color.\n\n-JimC\n-- \nJames Cloos OpenPGP: 1024D/ED7DAEA6\n"},{"id":"92727","messageId":"81bfc67a0810091920gfec5f19j6828a3e5ec7b7065@mail.gmail.com","threadId":"15830","inReplyTo":"48EE1F58.2060707@drmicha.warpmail.net","subject":"Re: Fwd: git status options feature suggestion","fromName":"Caleb Cushing","fromEmail":"xenoterracide@gmail.com","sentAt":"2008-10-10T02:20:25Z","receivedAt":"2008-10-10T02:20:25Z","isPatch":false,"sender":{"key":"xenoterracide@gmail.com","avatar":"https://gravatar.com/avatar/af3f0745dfa0ea9c4ee551d7d0a3cfe7ba8d229754c11678ab2ed23c3fa57065?d=mp&s=160"},"body":"> Could you list exactly which options you want implemented?\n--new --untracked --modified\n\nI believe there are other states as well that I'm not thinking of off\nthe top of my head. Those should probably be included as well. another\noption could be to have an option --filter=modified for example.\n\n\n> Requests for stuff like that keep appearing recently\n> ...\n> Michael\n\nall way over my head\n\n\n-- \nCaleb Cushing\n"},{"id":"92729","messageId":"51419b2c0810092125w38c2eaffgc023cec207731a3e@mail.gmail.com","threadId":"15830","inReplyTo":"48EE1F58.2060707@drmicha.warpmail.net","subject":"Re: Fwd: git status options feature suggestion","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2008-10-10T04:25:29Z","receivedAt":"2008-10-10T04:25:29Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Thu, Oct 9, 2008 at 9:12 AM, Michael J Gruber\n wrote:\n\n> A few radical suggestions might be:\n>\n> 1. make ls-files and diff --name-status use compatible letters\n>\n> 2. rename git commit -n to git commit -b (as in bypass), make git commit\n> -n do what's expected (\"--dry-run\", n as in duNNo yet)\n\nOuch. Please not -b. I guess I need to get my other suggestions\nupstream if I want to avoid option conflicts like this...\n\n> 3. rename git status to git commit -n\n>\n> 4. make git status generate git diff --name-status like output\n\nI'd really prefer to be able to get staged vs. unstaged information\nout of status. And the single-letter output, like what cvs/svn/hg\nhave, is less descriptive here. (Sure, git status could use some\ncleanup IMO, but a word instead of a letter for modification status is\na usability improvement in git over those other systems for new VCS\nusers.)\n\n> (3+4)'. make git status -l generate git diff --name-status like output\n> (l as in status Letter) as an alternative to 3+4\n\nThat seems nicer.\n\n\nAnd another radical suggestion (wasn't this brought up before too?):\n\n5. Allow limiting the status output to a set of paths. diff, log,\nadd, grep, etc. can all take a subdirectory name and limit their\noperation to files recursively underneath that path, but git status\ndoesn't do so when you run 'git status DIR'. I know why it currently\nbehaves as it does, but it sure seems like unnecessary UI\ninconsistency.\n\n\nJust my $0.02,\nElijah\n"},{"id":"92743","messageId":"alpine.DEB.1.00.0810101312360.22125@pacific.mpi-cbg.de.mpi-cbg.de","threadId":"15830","inReplyTo":"48EE1F58.2060707@drmicha.warpmail.net","subject":"Re: Fwd: git status options feature suggestion","fromName":"Johannes Schindelin","fromEmail":"johannes.schindelin@gmx.de","sentAt":"2008-10-10T11:13:42Z","receivedAt":"2008-10-10T11:13:42Z","isPatch":false,"sender":{"key":"johannes.schindelin@gmx.de","avatar":"https://avatars.githubusercontent.com/u/127790?v=4"},"body":"Hi,\n\nOn Thu, 9 Oct 2008, Michael J Gruber wrote:\n\n> 1. make ls-files and diff --name-status use compatible letters\n\nls-files and diff (at least partially) are plumbing. Breaking backwards \ncompatibility in these is out of the question.\n\nCiao,\nDscho\n"},{"id":"92819","messageId":"20081012044900.GA27845@coredump.intra.peff.net","threadId":"15830","inReplyTo":"48EE1F58.2060707@drmicha.warpmail.net","subject":"Re: Fwd: git status options feature suggestion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-12T04:49:00Z","receivedAt":"2008-10-12T04:49:00Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Thu, Oct 09, 2008 at 05:12:24PM +0200, Michael J Gruber wrote:\n\n> - people are used to \"svn status [-v]\" like output which can include\n> untracked as well as tracked unmodified files; there are other valid\n> reasons why you would want that info\n> \n> - porc can't do it: git status can't show ignored files, doesn't use\n> status letters, can't show files with specific status; git diff\n> --name-status can't show ignored nor untracked files\n> [In fact, the description of \"git diff\" says \"files which you could\n> add\", which should include untracked files, but doesn't.]\n> \n> - plumb uses conflicting letters: git ls-files output conflicts with git\n> diff --name-status output\n> \n> So I guess it's time for a usability effort in this area. A few\n> questions before going about that:\n\nA week or two ago I came across yet another git-status annoyance: it\nneeds write access to the repository to run (I was helping somebody with\na task on a shared box, and I wanted to run status in their repository\nusing my account).\n\nI considered submitting a patch to fix this, but I think it is really\nmore fundamental. I use status to get an overview of what's going on in\na repo, but it is intimately related to a potential commit.\n\nAnd this bleeds into other areas, too. Why should the \"what's going on\nin this repo\" command prefix all lines with \"#\"? We would have more\nfreedom to change the format if it weren't required to be a comment\nline in a commit message.\n\nSo I think it is probably reasonable to think about a new command (which\nwould not be called status) that shows this information. What do people\nwant to see? And in what format? Some things I would want or have seen\nrequested are:\n\n - staged and unstaged changes in --name-status format\n\n - files without changes (with a -v flag).\n\n - untracked files\n\n - current branch / detached HEAD (with relationship to tracked branch,\n if any)\n\nAnd maybe after hashing it out, it turns out it's not that different\nfrom \"git status\" and we should just stick with that. But I would be\ncurious to hear proposals.\n\n> - I think change of existing behaviour is unavoidable (make ls-files and\n> diff --name-status consistent). Is that something to do now or rather\n> before 1.7? Is porc (diff) supposed to be changed or plumb (ls-files)?\n\nI don't think you would want to just change the default; you would\nprobably add a new option to ls-files to use the --name-status letters,\nand then use that in your new porcelain.\n\n> - How strong should the tie between git status and git commit be?\n> Current git status is basically git commit -n, with the usual meaning of\n> \"-n\" (such as for prune etc.\"), not with the current meaning of git\n> commit -n, sigh...\n\nI think the theoretical tool I mentioned would benefit from breaking\nthis connection. But I don't know whether it is prudent to take the\n\"status\" name in doing so. Even if we decided to do so, it would\nprobably happen something like:\n\n 1. Introduce git-wtf, a new status-like tool. Deprecate git-status in\n its current form.\n\n 2. Wait a really long time.\n\n 3. Rename git-wtf to git-status.\n\nSo either way, the first step is an alternative replacement command.\n\n-Peff\n"},{"id":"92823","messageId":"7vwsgegvsh.fsf@gitster.siamese.dyndns.org","threadId":"15830","inReplyTo":"20081012044900.GA27845@coredump.intra.peff.net","subject":"Re: Fwd: git status options feature suggestion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-12T06:41:18Z","receivedAt":"2008-10-12T06:41:18Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> So I think it is probably reasonable to think about a new command (which\n> would not be called status) that shows this information.\n\nI was going to suggest the same. \"git st\" for people who come from \"svn st\"\nso that \"git status\" can be kept as traditional \"preview of 'git commit'\".\n\nAnd just make it mimic whatever folks accustomed to \"svn st\" would expect,\nmodulo we would need two status letters to signal difference between\n(HEAD, index), and (index, worktree). Perhaps three if you want to show\ndifference between (HEAD, worktree) while at it.\n\nAnd no, I have not seen any argument good enough to change ls-files nor\ndiff-$lowlevel output and break people's existing scripts.\n"},{"id":"92824","messageId":"20081012064512.GA32597@coredump.intra.peff.net","threadId":"15830","inReplyTo":"7vwsgegvsh.fsf@gitster.siamese.dyndns.org","subject":"Re: Fwd: git status options feature suggestion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-12T06:45:13Z","receivedAt":"2008-10-12T06:45:13Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 11, 2008 at 11:41:18PM -0700, Junio C Hamano wrote:\n\n> And just make it mimic whatever folks accustomed to \"svn st\" would expect,\n> modulo we would need two status letters to signal difference between\n> (HEAD, index), and (index, worktree). Perhaps three if you want to show\n> difference between (HEAD, worktree) while at it.\n\nI remember a long time ago you started on a parallel diff walker that\ncould diff the working tree, the index, and a tree at once. Do you\nremember the issues with it?\n\nI think that would be the right tool here to show each file only once,\nbut with multiple status flags. Something like:\n\n A M foo\n\nto show that \"foo\" has been added since the last commit, but there are\nmodifications in the working tree that have not yet been staged.\n\n-Peff\n"},{"id":"92825","messageId":"7v1vymgrom.fsf@gitster.siamese.dyndns.org","threadId":"15830","inReplyTo":"20081012064512.GA32597@coredump.intra.peff.net","subject":"Re: Fwd: git status options feature suggestion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-12T08:10:01Z","receivedAt":"2008-10-12T08:10:01Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I remember a long time ago you started on a parallel diff walker that\n> could diff the working tree, the index, and a tree at once. Do you\n> remember the issues with it?\n\nSorry, I don't.\n\n> I think that would be the right tool here to show each file only once,\n> but with multiple status flags. Something like:\n>\n> A M foo\n>\n> to show that \"foo\" has been added since the last commit, but there are\n> modifications in the working tree that have not yet been staged.\n\nOne thing to keep in mind is what to do when you would want to detect\nrenames. The parallel walk would be Ok but between HEAD and index there\ncould be renames involved, and at that point it would get quite tricky.\nOnce the index is in-core, I think it hurts us much to walk HEAD vs index\nand index vs working tree in separate passes.\n\nI think it is perfectly fine to run the diff-index first, and keep the\nresult from it in a string_list, and then run \"diff-files\" and annotate\nthe string_list with the output from it.\n\nSomething like...\n\n\tstruct git_st_data {\n \tconst char *head_path;\n char head_to_index_status;\n char index_to_worktree_status;\n\t};\n\n\tstatic int cmp_head_path(const void *a_, const void *b_)\n {\n\t\tstruct git_st_data *a = (struct git_st_data *)a_;\n\t\tstruct git_st_data *b = (struct git_st_data *)b_;\n\t\treturn strcmp(a->head_path, b->head_path);\n }\n\n\tstatic void git_st_inspect_index_cb(struct diff_queue_struct *q,\n \t\t\tstruct diff_options *opts, void *data)\n\t{\n\t\tstruct string_list *git_st_list = data;\n\t\tint i;\n\t\tfor (i = 0; i < q->nr; i++) {\n \tstruct git_st_data *d;\n struct string_list_item *e;\n\t\t\tstruct diff_filepair *fp = &q->queue[i];\n\t\t\td = xcalloc(1, sizeof(*d));\n d->head_path = xstrdup(fp->one->path);\n e = string_list_insert(fp->two->path, git_st_list);\n\t\t\te->util = d;\n d->head_to_index_status = fp->status;\n }\n\t}\n\n\tstatic void git_st_inspect_file_cb(struct diff_queue_struct *q,\n \t\t\tstruct diff_options *opts, void *data)\n\t{\n\t\tstruct string_list *git_st_list = data;\n\t\tint i;\n\t\tfor (i = 0; i < q->nr; i++) {\n \tstruct git_st_data *d;\n struct string_list_item *e;\n\t\t\tstruct diff_filepair *fp = &q->queue[i];\n\t\t\te = string_list_lookup(fp->one->path, git_st_list);\n\t\t\tif (!e)\n \tdie(\"Oops -- shouldn't happen\");\n\t\t\td = e->util;\n d->index_to_worktree_status = fp->status;\n }\n\t}\n\n\tvoid git_st_inspect(struct string_list *git_st_list)\n {\n \tstruct rev_info rev;\n\n\t\tgit_st_list->items = NULL;\n git_st_list->nr = git_st_list->alloc = 0;\n git_st_list->strdup_strings = 1;\n\n\t\t/*\n * run \"diff-index -B -M HEAD\" and keep the result in a\n * string list, keyed by the path in the index.\n */\n init_revisions(&rev, NULL);\n setup_revisions(0, NULL, &rev, \"HEAD\");\n rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;\n rev.diffopt.format_callback = git_st_inspect_index_cb;\n rev.diffopt.format_callback_data = git_st_list;\n rev.diffopt.detect_rename = 1;\n rev.diffopt.rename_limit = 200;\n rev.diffopt.break_opt = 0;\n run_diff_index(&rev, 1);\n\n\t\t/*\n * run \"diff-files\" and update the previous with the result.\n\t\t */\n\t\tinit_revisions(&rev, NULL);\n setup_revisions(0, NULL, &rev, NULL);\n rev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;\n rev.diffopt.format_callback = git_st_inspect_file_cb; \n rev.diffopt.format_callback_data = git_st_list;\n run_diff_files(&rev, 0);\n\n\t\t/*\n * sort the string-list entries in HEAD path order\n */\n\t\tqsort(git_st_list->items, git_st_list->nr,\n sizeof(struct string_list_item),\n cmp_head_path);\n\t}\n\nThen git_st_inspect() can also be called by wt_status_print(), making it\nunnecessary to do the equivalent of the above in wt_status_print_updated()\nand wt_status_print_changed().\n"},{"id":"92826","messageId":"20081012082607.GA17852@sigill.intra.peff.net","threadId":"15830","inReplyTo":"20081012044900.GA27845@coredump.intra.peff.net","subject":"Re: Fwd: git status options feature suggestion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-12T08:26:08Z","receivedAt":"2008-10-12T08:26:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Oct 12, 2008 at 12:49:00AM -0400, Jeff King wrote:\n\n> A week or two ago I came across yet another git-status annoyance: it\n> needs write access to the repository to run (I was helping somebody with\n> a task on a shared box, and I wanted to run status in their repository\n> using my account).\n> \n> I considered submitting a patch to fix this, but I think it is really\n> more fundamental. I use status to get an overview of what's going on in\n> a repo, but it is intimately related to a potential commit.\n\nBTW, in case anybody is interested, here is the patch. Like I said, I\nthink we are better off with an alternative to \"status\", but maybe this\nis useful to somebody anyway.\n\n---\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex b01ad9f..8951364 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -217,7 +217,8 @@ static void create_base_index(void)\n \t\texit(128); /* We've already reported the error, finish dying */\n }\n \n-static char *prepare_index(int argc, const char **argv, const char *prefix)\n+static char *prepare_index(int argc, const char **argv, const char *prefix,\n+\t\tint status_only)\n {\n \tint fd;\n \tstruct string_list partial;\n@@ -270,7 +271,13 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)\n \t * We still need to refresh the index here.\n \t */\n \tif (!pathspec || !*pathspec) {\n-\t\tfd = hold_locked_index(&index_lock, 1);\n+\t\tfd = hold_locked_index(&index_lock, 0);\n+\t\tif (fd < 0) {\n+\t\t\tif (!status_only)\n+\t\t\t\tdie(\"unable to lock index: %s\",\n+\t\t\t\t\t\tstrerror(errno));\n+\t\t\treturn get_index_file();\n+\t\t}\n \t\trefresh_cache(REFRESH_QUIET);\n \t\tif (write_cache(fd, active_cache, active_nr) ||\n \t\t commit_locked_index(&index_lock))\n@@ -869,7 +876,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \n \targc = parse_and_validate_options(argc, argv, builtin_status_usage, prefix);\n \n-\tindex_file = prepare_index(argc, argv, prefix);\n+\tindex_file = prepare_index(argc, argv, prefix, 1);\n \n \tcommitable = run_status(stdout, index_file, prefix, 0);\n \n@@ -953,7 +960,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)\n \n \targc = parse_and_validate_options(argc, argv, builtin_commit_usage, prefix);\n \n-\tindex_file = prepare_index(argc, argv, prefix);\n+\tindex_file = prepare_index(argc, argv, prefix, 0);\n \n \t/* Set up everything for writing the commit object. This includes\n \t running hooks, writing the trees, and interacting with the user. */\n"},{"id":"92827","messageId":"gcseoi$790$1@ger.gmane.org","threadId":"15830","inReplyTo":"7vwsgegvsh.fsf@gitster.siamese.dyndns.org","subject":"Re: Fwd: git status options feature suggestion","fromName":"Jakub Narebski","fromEmail":"jnareb@gmail.com","sentAt":"2008-10-12T09:07:29Z","receivedAt":"2008-10-12T09:07:29Z","isPatch":false,"sender":{"key":"jnareb@gmail.com","avatar":"https://avatars.githubusercontent.com/u/2706?v=4"},"body":"Junio C Hamano wrote:\n\n> Jeff King writes:\n> \n>> So I think it is probably reasonable to think about a new command (which\n>> would not be called status) that shows this information.\n> \n> I was going to suggest the same.  \"git st\" for people who come from \"svn st\"\n> so that \"git status\" can be kept as traditional \"preview of 'git commit'\".\n\nOr \"git inspect\". Or \"git info\".\n\n-- \nJakub Narebski\nWarsaw, Poland\nShadeHawk on #git\n"},{"id":"92828","messageId":"7vwsgef83n.fsf@gitster.siamese.dyndns.org","threadId":"15830","inReplyTo":"20081012082607.GA17852@sigill.intra.peff.net","subject":"Re: Fwd: git status options feature suggestion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-12T09:58:20Z","receivedAt":"2008-10-12T09:58:20Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> BTW, in case anybody is interested, here is the patch. Like I said, I\n> think we are better off with an alternative to \"status\", but maybe this\n> is useful to somebody anyway.\n>\n> ---\n> diff --git a/builtin-commit.c b/builtin-commit.c\n> index b01ad9f..8951364 100644\n> --- a/builtin-commit.c\n> +++ b/builtin-commit.c\n> @@ -217,7 +217,8 @@ static void create_base_index(void)\n> \t\texit(128); /* We've already reported the error, finish dying */\n> }\n> \n> -static char *prepare_index(int argc, const char **argv, const char *prefix)\n> +static char *prepare_index(int argc, const char **argv, const char *prefix,\n> +\t\tint status_only)\n> {\n> \tint fd;\n> \tstruct string_list partial;\n> @@ -270,7 +271,13 @@ static char *prepare_index(int argc, const char **argv, const char *prefix)\n> \t * We still need to refresh the index here.\n> \t */\n> \tif (!pathspec || !*pathspec) {\n> -\t\tfd = hold_locked_index(&index_lock, 1);\n> +\t\tfd = hold_locked_index(&index_lock, 0);\n> +\t\tif (fd < 0) {\n> +\t\t\tif (!status_only)\n> +\t\t\t\tdie(\"unable to lock index: %s\",\n> +\t\t\t\t\t\tstrerror(errno));\n> +\t\t\treturn get_index_file();\n> +\t\t}\n> \t\trefresh_cache(REFRESH_QUIET);\n\nYou would probably want to refresh_cache() here even if you are not going\nto write the resulting index out, so that you won't show the stat-only\ndifferences to the end user. Other than that, I think this is a good\nchange.\n"},{"id":"92830","messageId":"971DCAD3-3274-4507-AE3D-5BDCEDB8513C@wincent.com","threadId":"15830","inReplyTo":"7vwsgegvsh.fsf@gitster.siamese.dyndns.org","subject":"Re: git status options feature suggestion","fromName":"Wincent Colaiuta","fromEmail":"win@wincent.com","sentAt":"2008-10-12T10:47:11Z","receivedAt":"2008-10-12T10:47:11Z","isPatch":false,"sender":{"key":"greg@hurrell.net","avatar":"https://avatars.githubusercontent.com/u/7074?v=4"},"body":"El 12/10/2008, a las 8:41, Junio C Hamano escribió:\n\n> Jeff King writes:\n>\n>> So I think it is probably reasonable to think about a new command \n>> (which\n>> would not be called status) that shows this information.\n>\n> I was going to suggest the same. \"git st\" for people who come from \n> \"svn st\"\n> so that \"git status\" can be kept as traditional \"preview of 'git \n> commit'\".\n>\n> And just make it mimic whatever folks accustomed to \"svn st\" would \n> expect,\n> modulo we would need two status letters to signal difference between\n> (HEAD, index), and (index, worktree). Perhaps three if you want to \n> show\n> difference between (HEAD, worktree) while at it.\n\nOne of the first aliases I set up when I started using git was \"st\" \nfor status, and I'd imagine that's a pretty common thing for people \ncoming from other SCMs like svn and cvs. But I very quickly became \nused to git's notion of what \"status\" means and I wouldn't want \"git \nst\" to start giving me a different behaviour.\n\nI think if you're introducing a different command then you should make \nsure it doesn't happen to be an abbreviation of an existing one. It \nwould be better to give it some other name (info, foo, whatever). If \nsvn people then want to make an \"st\" alias pointing to it they're free \nto do so.\n\nJust my 2c.\n\nCheers,\nWincent\n"},{"id":"92833","messageId":"87od1qrqhi.fsf@iki.fi","threadId":"15830","inReplyTo":"971DCAD3-3274-4507-AE3D-5BDCEDB8513C@wincent.com","subject":"Re: git status options feature suggestion","fromName":"Teemu Likonen","fromEmail":"tlikonen@iki.fi","sentAt":"2008-10-12T11:40:25Z","receivedAt":"2008-10-12T11:40:25Z","isPatch":false,"sender":{"key":"tlikonen@iki.fi","avatar":null},"body":"Wincent Colaiuta writes:\n\n> I think if you're introducing a different command then you should make\n> sure it doesn't happen to be an abbreviation of an existing one. It\n> would be better to give it some other name (info, foo, whatever). If\n> svn people then want to make an \"st\" alias pointing to it they're free\n> to do so.\n\nIn Subversion and Bazaar \"info\" command gives mostly information about\nthe repository itself. They don't talk about individual files at all.\n\"status\" is the command (also in Mercurial) for getting information\nabout the current state of files in the tree.\n\nI think it would be really sad if \"git status\" can't be extended to\nmatch people's needs. I don't like the idea of a new name for such\nstatus command. It's a kind of \"why git people always invent new names\nfor familiar commands?\" thing.\n"},{"id":"92840","messageId":"48F20120.1070602@op5.se","threadId":"15830","inReplyTo":"87od1qrqhi.fsf@iki.fi","subject":"Re: git status options feature suggestion","fromName":"Andreas Ericsson","fromEmail":"ae@op5.se","sentAt":"2008-10-12T13:52:32Z","receivedAt":"2008-10-12T13:52:32Z","isPatch":false,"sender":{"key":"ae@op5.se","avatar":"https://gravatar.com/avatar/426e89595c75a8f5252dd0c989e5fabe5bcac616e68557427ad9aef6b0ca342a?d=mp&s=160"},"body":"Teemu Likonen wrote:\n> Wincent Colaiuta writes:\n> \n>> I think if you're introducing a different command then you should make\n>> sure it doesn't happen to be an abbreviation of an existing one. It\n>> would be better to give it some other name (info, foo, whatever). If\n>> svn people then want to make an \"st\" alias pointing to it they're free\n>> to do so.\n> \n> In Subversion and Bazaar \"info\" command gives mostly information about\n> the repository itself. They don't talk about individual files at all.\n> \"status\" is the command (also in Mercurial) for getting information\n> about the current state of files in the tree.\n> \n> I think it would be really sad if \"git status\" can't be extended to\n> match people's needs. I don't like the idea of a new name for such\n> status command. It's a kind of \"why git people always invent new names\n> for familiar commands?\" thing.\n\nWell, the solution is fairly simple then. Just make it configurable and\nset it in your ~/.gitconfig. It's not my itch to scratch though. I\nloathe the sparse output from cvs/svn/whatnot and would be just as happy\nif I never had to look at it again. I can understand its usefulness for\nscripting, but 'git status' is porcelain so for that purpose it really\nbelongs somewhere else.\n\n-- \nAndreas Ericsson andreas.ericsson@op5.se\nOP5 AB www.op5.se\nTel: +46 8-230225 Fax: +46 8-230231\n"},{"id":"92860","messageId":"20081012180504.GD4856@spearce.org","threadId":"15830","inReplyTo":"20081012064512.GA32597@coredump.intra.peff.net","subject":"Re: Fwd: git status options feature suggestion","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-10-12T18:05:04Z","receivedAt":"2008-10-12T18:05:04Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jeff King wrote:\n> On Sat, Oct 11, 2008 at 11:41:18PM -0700, Junio C Hamano wrote:\n> \n> > And just make it mimic whatever folks accustomed to \"svn st\" would expect,\n> > modulo we would need two status letters to signal difference between\n> > (HEAD, index), and (index, worktree). Perhaps three if you want to show\n> > difference between (HEAD, worktree) while at it.\n> \n> I remember a long time ago you started on a parallel diff walker that\n> could diff the working tree, the index, and a tree at once. Do you\n> remember the issues with it?\n> \n> I think that would be the right tool here to show each file only once,\n> but with multiple status flags. Something like:\n> \n> A M foo\n\nI have a tool that I'll be open-sourcing later this year, but it does\nsomething like that:\n\n project foo/ branch master\n Am foo\n M- bar\n R- orig => dest ( 95%)\n\nLine coloring is red on lines with unstaged stuff in the working\ndirectory (3rd column, lower case letters) and green on lines that\nare fully staged (3rd column is a '-').\n\nThe tool is in Python, but I'm just scraping the output of\n`diff-index -M --cached HEAD` and diff-files to get that\ndisplay. The status letters are exactly those given out by\ndiff-index/diff-files, but the diff-files output is lowercased.\n\nScott Chacon has seen the tool output and likes it; there's a tech\ntalk that will be posted on YouTube soon where he and I are sort\nof talking about it.\n\nSorry I can't say too much more about it yet. But I'm trying to\nsay that both Scott and I like a denser display like this.\n\n-- \nShawn.\n"},{"id":"92886","messageId":"20081013005934.GA3768@coredump.intra.peff.net","threadId":"15830","inReplyTo":"7vwsgef83n.fsf@gitster.siamese.dyndns.org","subject":"Re: Fwd: git status options feature suggestion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-13T00:59:35Z","receivedAt":"2008-10-13T00:59:35Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Oct 12, 2008 at 02:58:20AM -0700, Junio C Hamano wrote:\n\n> > +\t\tfd = hold_locked_index(&index_lock, 0);\n> > +\t\tif (fd < 0) {\n> > +\t\t\tif (!status_only)\n> > +\t\t\t\tdie(\"unable to lock index: %s\",\n> > +\t\t\t\t\t\tstrerror(errno));\n> > +\t\t\treturn get_index_file();\n> > +\t\t}\n> > \t\trefresh_cache(REFRESH_QUIET);\n> \n> You would probably want to refresh_cache() here even if you are not going\n> to write the resulting index out, so that you won't show the stat-only\n> differences to the end user. Other than that, I think this is a good\n> change.\n\nThat is a good point. However, I think this change is still not a good\none, because it is only halfway there. It makes \"git status\" work, but\nnot \"git status path\", which wants to write out the resulting cache. I\ndon't know what complications are involved with making that work.\nProbably there is a way, but I haven't looked too closely, as I think a\nbetter path forward is a new tool that is not so closely tied to commit.\n\n-Peff\n"},{"id":"92887","messageId":"20081013010415.GB3768@coredump.intra.peff.net","threadId":"15830","inReplyTo":"7v1vymgrom.fsf@gitster.siamese.dyndns.org","subject":"Re: Fwd: git status options feature suggestion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-13T01:04:15Z","receivedAt":"2008-10-13T01:04:15Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Oct 12, 2008 at 01:10:01AM -0700, Junio C Hamano wrote:\n\n> One thing to keep in mind is what to do when you would want to detect\n> renames. The parallel walk would be Ok but between HEAD and index there\n> could be renames involved, and at that point it would get quite tricky.\n> Once the index is in-core, I think it hurts us much to walk HEAD vs index\n> and index vs working tree in separate passes.\n\nAssuming you meant \"I _don't_ think it hurts us much\" then OK, that\nmakes sense. I was just thinking it would be more elegant than holding\neach list in memory and comparing, but really that is not all that\ndifferent than what diffcore does with the output queue.\n\n> I think it is perfectly fine to run the diff-index first, and keep the\n> result from it in a string_list, and then run \"diff-files\" and annotate\n> the string_list with the output from it.\n\nThanks, I think that is a sane direction to go in. And I agree that any\nsolution should be totally split from the actual output format, so we\ncan reuse it in \"git status\" if desired.\n\nHowever, now that Shawn has revealed the existence of his super-secret\nstatus replacement, I am going to wait to see that before moving any\nfurther. :)\n\n-Peff\n"},{"id":"92888","messageId":"20081013010608.GC3768@coredump.intra.peff.net","threadId":"15830","inReplyTo":"20081012180504.GD4856@spearce.org","subject":"Re: Fwd: git status options feature suggestion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-13T01:06:08Z","receivedAt":"2008-10-13T01:06:08Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sun, Oct 12, 2008 at 11:05:04AM -0700, Shawn O. Pearce wrote:\n\n> I have a tool that I'll be open-sourcing later this year, but it does\n> [...]\n> Sorry I can't say too much more about it yet. But I'm trying to\n> say that both Scott and I like a denser display like this.\n\nI like what I saw, and I think a \"denser\" format is what I was trying to\nsuggest in my earlier message (I just didn't think of nearly as clear a\nword). So count me in for your list of people who would like to see this\nthing (and would even work on doing a pure-C version).\n\n-Peff\n"},{"id":"92891","messageId":"20081013013042.GI4856@spearce.org","threadId":"15830","inReplyTo":"20081013010415.GB3768@coredump.intra.peff.net","subject":"Re: Fwd: git status options feature suggestion","fromName":"Shawn O. Pearce","fromEmail":"spearce@spearce.org","sentAt":"2008-10-13T01:30:42Z","receivedAt":"2008-10-13T01:30:42Z","isPatch":false,"sender":{"key":"spearce@spearce.org","avatar":"https://avatars.githubusercontent.com/u/34844?v=4"},"body":"Jeff King wrote:\n> However, now that Shawn has revealed the existence of his super-secret\n> status replacement, I am going to wait to see that before moving any\n> further. :)\n\nI'll talk about it more at the GitTogether. I expect the sources\nto be published and available for download between now and then.\nI'll post a pointer to it here on the Git ML once the sources\ngo live.\n\nSo you shouldn't have to wait too much longer.\n\nBut as I said, it really is just a trivial redisplay of what\ndiff-files and diff-index produces. Anyone could probably code up\nthe same result in 15 minutes in Perl or Python; or slightly longer\nin C.\n\n-- \nShawn.\n"},{"id":"93950","messageId":"7vej246sb4.fsf@gitster.siamese.dyndns.org","threadId":"15830","inReplyTo":"7v1vymgrom.fsf@gitster.siamese.dyndns.org","subject":"Re: Fwd: git status options feature suggestion","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-10-26T01:47:27Z","receivedAt":"2008-10-26T01:47:27Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Junio C Hamano writes:\n\n> Jeff King writes:\n>\n>> I remember a long time ago you started on a parallel diff walker that\n>> could diff the working tree, the index, and a tree at once. Do you\n>> remember the issues with it?\n>\n> Sorry, I don't.\n>\n>> I think that would be the right tool here to show each file only once,\n>> but with multiple status flags. Something like:\n>>\n>> A M foo\n>>\n>> to show that \"foo\" has been added since the last commit, but there are\n>> modifications in the working tree that have not yet been staged.\n>\n> One thing to keep in mind is what to do when you would want to detect\n> renames. The parallel walk would be Ok but between HEAD and index there\n> could be renames involved, and at that point it would get quite tricky.\n> Once the index is in-core, I think it hurts us much to walk HEAD vs index\n> and index vs working tree in separate passes.\n>\n> I think it is perfectly fine to run the diff-index first, and keep the\n> result from it in a string_list, and then run \"diff-files\" and annotate\n> the string_list with the output from it.\n>\n> Something like...\n\nBecause I was bored thinking about what to talk about in Gittogether and\nlacked enough concentration to do anything productive, I did this that:\n\n (1) introduces the \"find and summarize changes in a single string list\"\n infrastructure;\n\n (2) rewrites wt_status_print_{updated,changed} to use it; and\n\n (3) adds \"git shortstatus\" that does not take any parameter (so it is not\n about \"preview of commit with the same paths arguments\" anymore) to\n give the status in:\n\n XsssY PATH1 -> PATH2\n\n format, where X is the diff status between HEAD and the index, sss is the\n rename/copy score of the change (if X is rename or copy --- otherwise\n it is blank), Y is the diff status between the index and the worktree. \n PATH1 is the path in the HEAD, and \" -> PATH2\" part is shown only when\n PATH1 corresponds to a different path in the index/worktree.\n\nThis was done primarily for fun and killing-time, so I won't be committing\nit to my tree, but it seems to pass all the existing tests.\n\nIf you apply this patch with \"git apply\" (no --index) and then\n\n $ git mv COPYING RENAMING\n\nthen you would see:\n\n $ ./git-shortstatus\n M Makefile\n R100 COPYING -> RENAMING\n M builtin-commit.c\n M builtin-revert.c\n M builtin.h\n M git.c\n M wt-status.c\n M wt-status.h \n\nIt is very much welcomed if somebody wants to build on top of this. A few\nobvious things, aside from bikeshedding to drop the score value (which I\njust did as a sanity check measure and for nothing else --- I won't feel\nhurt if we lost that field from the output) and such are:\n\n * We can also rewrite wt_status_print_untracked() using the collected\n data by making the collector pay attention to untracked files quite\n easily;\n\n * I did not bouther touching wt_status_print_initial() but I think it\n should be straightforward to produce its output from the collected\n data, as the collector already knows how to handle the initial commit.\n\nSigned-off-by: Junio C Hamano \n---\n\n Makefile | 1 +\n builtin-commit.c | 45 ++++++++++-\n builtin-revert.c | 1 +\n builtin.h | 1 +\n git.c | 1 +\n wt-status.c | 240 +++++++++++++++++++++++++++++++++++++++++-------------\n wt-status.h | 9 ++\n 7 files changed, 239 insertions(+), 59 deletions(-)\n\ndiff --git c/Makefile w/Makefile\nindex d6f3695..36afaa3 100644\n--- c/Makefile\n+++ w/Makefile\n@@ -316,6 +316,7 @@ BUILT_INS += git-merge-subtree$X\n BUILT_INS += git-peek-remote$X\n BUILT_INS += git-repo-config$X\n BUILT_INS += git-show$X\n+BUILT_INS += git-shortstatus$X\n BUILT_INS += git-status$X\n BUILT_INS += git-whatchanged$X\n \ndiff --git c/builtin-commit.c w/builtin-commit.c\nindex 93ca496..99c6409 100644\n--- c/builtin-commit.c\n+++ w/builtin-commit.c\n@@ -14,6 +14,7 @@\n #include \"diffcore.h\"\n #include \"commit.h\"\n #include \"revision.h\"\n+#include \"string-list.h\"\n #include \"wt-status.h\"\n #include \"run-command.h\"\n #include \"refs.h\"\n@@ -21,7 +22,6 @@\n #include \"strbuf.h\"\n #include \"utf8.h\"\n #include \"parse-options.h\"\n-#include \"string-list.h\"\n #include \"rerere.h\"\n #include \"unpack-trees.h\"\n \n@@ -856,6 +856,49 @@ static int parse_and_validate_options(int argc, const char *argv[],\n \treturn argc;\n }\n \n+int cmd_shortstatus(int argc, const char **argv, const char *prefix)\n+{\n+\tstruct wt_status s;\n+\tint i;\n+\n+\tread_cache();\n+\trefresh_cache(REFRESH_QUIET);\n+\twt_status_prepare(&s);\n+\twt_status_collect_changes(&s);\n+\tfor (i = 0; i < s.change.nr; i++) {\n+\t\tstruct wt_status_change_data *d;\n+\t\tstruct string_list_item *it;\n+\t\tchar pfx[1 + 3 + 1 + 1];\n+\n+\t\tit = &(s.change.items[i]);\n+\t\td = it->util;\n+\t\tswitch (d->index_status) {\n+\t\tcase DIFF_STATUS_COPIED:\n+\t\tcase DIFF_STATUS_RENAMED:\n+\t\t\tsprintf(pfx, \"%c%3d\",\n+\t\t\t\td->index_status,\n+\t\t\t\t(int)(d->index_score * 100 / MAX_SCORE));\n+\t\t\tbreak;\n+\t\tcase 0:\n+\t\t\tmemcpy(pfx, \" \", 4);\n+\t\t\tbreak;\n+\t\tdefault:\n+\t\t\tsprintf(pfx, \"%c \", d->index_status);\n+\t\t\tbreak;\n+\t\t}\n+\t\tif (!d->worktree_status)\n+\t\t\tpfx[4] = ' ';\n+\t\telse\n+\t\t\tpfx[4] = d->worktree_status;\n+\t\tpfx[5] = '\\0';\n+\t\tprintf(\"%s \", pfx);\n+\t\tif (d->head_path)\n+\t\t\tprintf(\"%s -> \", d->head_path);\n+\t\tprintf(\"%s\\n\", it->string);\n+\t}\n+\treturn 0;\n+}\n+\n int cmd_status(int argc, const char **argv, const char *prefix)\n {\n \tconst char *index_file;\ndiff --git c/builtin-revert.c w/builtin-revert.c\nindex 4725540..060453f 100644\n--- c/builtin-revert.c\n+++ w/builtin-revert.c\n@@ -3,6 +3,7 @@\n #include \"object.h\"\n #include \"commit.h\"\n #include \"tag.h\"\n+#include \"string-list.h\"\n #include \"wt-status.h\"\n #include \"run-command.h\"\n #include \"exec_cmd.h\"\ndiff --git c/builtin.h w/builtin.h\nindex 1495cf6..f054fc7 100644\n--- c/builtin.h\n+++ w/builtin.h\n@@ -94,6 +94,7 @@ extern int cmd_shortlog(int argc, const char **argv, const char *prefix);\n extern int cmd_show(int argc, const char **argv, const char *prefix);\n extern int cmd_show_branch(int argc, const char **argv, const char *prefix);\n extern int cmd_status(int argc, const char **argv, const char *prefix);\n+extern int cmd_shortstatus(int argc, const char **argv, const char *prefix);\n extern int cmd_stripspace(int argc, const char **argv, const char *prefix);\n extern int cmd_symbolic_ref(int argc, const char **argv, const char *prefix);\n extern int cmd_tag(int argc, const char **argv, const char *prefix);\ndiff --git c/git.c w/git.c\nindex 89feb0b..55e6cc9 100644\n--- c/git.c\n+++ w/git.c\n@@ -342,6 +342,7 @@ static void handle_internal_command(int argc, const char **argv)\n \t\t{ \"rm\", cmd_rm, RUN_SETUP },\n \t\t{ \"send-pack\", cmd_send_pack, RUN_SETUP },\n \t\t{ \"shortlog\", cmd_shortlog, USE_PAGER },\n+\t\t{ \"shortstatus\", cmd_shortstatus, RUN_SETUP | NEED_WORK_TREE },\n \t\t{ \"show-branch\", cmd_show_branch, RUN_SETUP },\n \t\t{ \"show\", cmd_show, RUN_SETUP | USE_PAGER },\n \t\t{ \"status\", cmd_status, RUN_SETUP | NEED_WORK_TREE },\ndiff --git c/wt-status.c w/wt-status.c\nindex c3a9cab..3d2287b 100644\n--- c/wt-status.c\n+++ w/wt-status.c\n@@ -1,4 +1,5 @@\n #include \"cache.h\"\n+#include \"string-list.h\"\n #include \"wt-status.h\"\n #include \"color.h\"\n #include \"object.h\"\n@@ -56,6 +57,7 @@ void wt_status_prepare(struct wt_status *s)\n \ts->reference = \"HEAD\";\n \ts->fp = stdout;\n \ts->index_file = get_index_file();\n+\ts->change.strdup_strings = 1;\n }\n \n static void wt_status_print_cached_header(struct wt_status *s)\n@@ -98,18 +100,22 @@ static void wt_status_print_trailer(struct wt_status *s)\n \n #define quote_path quote_path_relative\n \n-static void wt_status_print_filepair(struct wt_status *s,\n-\t\t\t\t int t, struct diff_filepair *p)\n+static void wt_status_print_change_data(struct wt_status *s,\n+\t\t\t\t\tint t,\n+\t\t\t\t\tint status,\n+\t\t\t\t\tchar *one_name,\n+\t\t\t\t\tchar *two_name,\n+\t\t\t\t\tint score)\n {\n \tconst char *c = color(t);\n \tconst char *one, *two;\n \tstruct strbuf onebuf = STRBUF_INIT, twobuf = STRBUF_INIT;\n \n-\tone = quote_path(p->one->path, -1, &onebuf, s->prefix);\n-\ttwo = quote_path(p->two->path, -1, &twobuf, s->prefix);\n+\tone = quote_path(one_name, -1, &onebuf, s->prefix);\n+\ttwo = quote_path(two_name, -1, &twobuf, s->prefix);\n \n \tcolor_fprintf(s->fp, color(WT_STATUS_HEADER), \"#\\t\");\n-\tswitch (p->status) {\n+\tswitch (status) {\n \tcase DIFF_STATUS_ADDED:\n \t\tcolor_fprintf(s->fp, c, \"new file: %s\", one);\n \t\tbreak;\n@@ -135,56 +141,13 @@ static void wt_status_print_filepair(struct wt_status *s,\n \t\tcolor_fprintf(s->fp, c, \"unmerged: %s\", one);\n \t\tbreak;\n \tdefault:\n-\t\tdie(\"bug: unhandled diff status %c\", p->status);\n+\t\tdie(\"bug: unhandled diff status %c\", status);\n \t}\n \tfprintf(s->fp, \"\\n\");\n \tstrbuf_release(&onebuf);\n \tstrbuf_release(&twobuf);\n }\n \n-static void wt_status_print_updated_cb(struct diff_queue_struct *q,\n-\t\tstruct diff_options *options,\n-\t\tvoid *data)\n-{\n-\tstruct wt_status *s = data;\n-\tint shown_header = 0;\n-\tint i;\n-\tfor (i = 0; i < q->nr; i++) {\n-\t\tif (q->queue[i]->status == 'U')\n-\t\t\tcontinue;\n-\t\tif (!shown_header) {\n-\t\t\twt_status_print_cached_header(s);\n-\t\t\ts->commitable = 1;\n-\t\t\tshown_header = 1;\n-\t\t}\n-\t\twt_status_print_filepair(s, WT_STATUS_UPDATED, q->queue[i]);\n-\t}\n-\tif (shown_header)\n-\t\twt_status_print_trailer(s);\n-}\n-\n-static void wt_status_print_changed_cb(struct diff_queue_struct *q,\n- struct diff_options *options,\n- void *data)\n-{\n-\tstruct wt_status *s = data;\n-\tint i;\n-\tif (q->nr) {\n-\t\tint has_deleted = 0;\n-\t\ts->workdir_dirty = 1;\n-\t\tfor (i = 0; i < q->nr; i++)\n-\t\t\tif (q->queue[i]->status == DIFF_STATUS_DELETED) {\n-\t\t\t\thas_deleted = 1;\n-\t\t\t\tbreak;\n-\t\t\t}\n-\t\twt_status_print_dirty_header(s, has_deleted);\n-\t}\n-\tfor (i = 0; i < q->nr; i++)\n-\t\twt_status_print_filepair(s, WT_STATUS_CHANGED, q->queue[i]);\n-\tif (q->nr)\n-\t\twt_status_print_trailer(s);\n-}\n-\n static void wt_status_print_initial(struct wt_status *s)\n {\n \tint i;\n@@ -205,13 +168,80 @@ static void wt_status_print_initial(struct wt_status *s)\n \tstrbuf_release(&buf);\n }\n \n-static void wt_status_print_updated(struct wt_status *s)\n+static void wt_status_collect_changed_cb(struct diff_queue_struct *q,\n+\t\t\t\t\t struct diff_options *options,\n+\t\t\t\t\t void *data)\n+{\n+\tstruct wt_status *s = data;\n+\tint i;\n+\n+\tif (!q->nr)\n+\t\treturn;\n+\ts->workdir_dirty = 1;\n+\tfor (i = 0; i < q->nr; i++) {\n+\t\tstruct diff_filepair *p;\n+\t\tstruct string_list_item *it;\n+\t\tstruct wt_status_change_data *d;\n+\n+\t\tp = q->queue[i];\n+\n+\t\td = xcalloc(1, sizeof(*d));\n+\t\td->worktree_status = p->status;\n+\t\tit = string_list_insert(p->one->path, &s->change);\n+\t\tit->util = d;\n+\t}\n+}\n+\n+static void wt_status_collect_updated_cb(struct diff_queue_struct *q,\n+\t\t\t\t\t struct diff_options *options,\n+\t\t\t\t\t void *data)\n+{\n+\tstruct wt_status *s = data;\n+\tint i;\n+\n+\tfor (i = 0; i < q->nr; i++) {\n+\t\tstruct diff_filepair *p;\n+\t\tstruct string_list_item *it;\n+\t\tstruct wt_status_change_data *d;\n+\n+\t\tp = q->queue[i];\n+\t\tit = string_list_insert(p->two->path, &s->change);\n+\t\td = it->util;\n+\t\tif (!d) {\n+\t\t\td = xcalloc(1, sizeof(*d));\n+\t\t\tit->util = d;\n+\t\t}\n+\t\td->index_status = p->status;\n+\t\tswitch (p->status) {\n+\t\tcase DIFF_STATUS_COPIED:\n+\t\tcase DIFF_STATUS_RENAMED:\n+\t\t\td->head_path = xstrdup(p->one->path);\n+\t\t\td->index_score = p->score;\n+\t\t\tbreak;\n+\t\t}\n+\t}\n+}\n+\n+static void wt_status_collect_changes_worktree(struct wt_status *s)\n+{\n+\tstruct rev_info rev;\n+\n+\tinit_revisions(&rev, NULL);\n+\tsetup_revisions(0, NULL, &rev, NULL);\n+\trev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;\n+\trev.diffopt.format_callback = wt_status_collect_changed_cb;\n+\trev.diffopt.format_callback_data = s;\n+\trun_diff_files(&rev, 0);\n+}\n+\n+static void wt_status_collect_changes_index(struct wt_status *s)\n {\n \tstruct rev_info rev;\n+\n \tinit_revisions(&rev, NULL);\n \tsetup_revisions(0, NULL, &rev, s->reference);\n \trev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;\n-\trev.diffopt.format_callback = wt_status_print_updated_cb;\n+\trev.diffopt.format_callback = wt_status_collect_updated_cb;\n \trev.diffopt.format_callback_data = s;\n \trev.diffopt.detect_rename = 1;\n \trev.diffopt.rename_limit = 200;\n@@ -219,15 +249,107 @@ static void wt_status_print_updated(struct wt_status *s)\n \trun_diff_index(&rev, 1);\n }\n \n+static void wt_status_collect_changes_initial(struct wt_status *s)\n+{\n+\tint i;\n+\n+\tfor (i = 0; i < active_nr; i++) {\n+\t\tstruct string_list_item *it;\n+\t\tstruct wt_status_change_data *d;\n+\n+\t\tit = string_list_insert(active_cache[i]->name, &s->change);\n+\t\td = it->util;\n+\t\tif (!d) {\n+\t\t\td = xcalloc(1, sizeof(*d));\n+\t\t\tit->util = d;\n+\t\t}\n+\t\td->index_status = DIFF_STATUS_ADDED;\n+\t}\n+}\n+\n+void wt_status_collect_changes(struct wt_status *s)\n+{\n+\twt_status_collect_changes_worktree(s);\n+\n+\tif (s->is_initial)\n+\t\twt_status_collect_changes_initial(s);\n+\telse\n+\t\twt_status_collect_changes_index(s);\n+}\n+\n+static void wt_status_print_updated(struct wt_status *s)\n+{\n+\tint shown_header = 0;\n+\tint i;\n+\n+\tfor (i = 0; i < s->change.nr; i++) {\n+\t\tstruct wt_status_change_data *d;\n+\t\tstruct string_list_item *it;\n+\t\tit = &(s->change.items[i]);\n+\t\td = it->util;\n+\t\tif (!d->index_status)\n+\t\t\tcontinue;\n+\t\tif (!shown_header) {\n+\t\t\twt_status_print_cached_header(s);\n+\t\t\ts->commitable = 1;\n+\t\t\tshown_header = 1;\n+\t\t}\n+\t\twt_status_print_change_data(s, WT_STATUS_UPDATED,\n+\t\t\t\t\t d->index_status,\n+\t\t\t\t\t d->head_path ? d->head_path : it->string,\n+\t\t\t\t\t it->string,\n+\t\t\t\t\t d->index_score);\n+\t}\n+\tif (shown_header)\n+\t\twt_status_print_trailer(s);\n+}\n+\n+/*\n+ * -1 : has delete\n+ * 0 : no change\n+ * 1 : some change but no delete\n+ */\n+static int wt_status_check_worktree_changes(struct wt_status *s)\n+{\n+\tint i;\n+\tint changes = 0;\n+\n+\tfor (i = 0; i < s->change.nr; i++) {\n+\t\tstruct wt_status_change_data *d;\n+\t\td = s->change.items[i].util;\n+\t\tif (!d->worktree_status)\n+\t\t\tcontinue;\n+\t\tchanges = 1;\n+\t\tif (d->worktree_status == DIFF_STATUS_DELETED)\n+\t\t\treturn -1;\n+\t}\n+\treturn changes;\n+}\n+\n static void wt_status_print_changed(struct wt_status *s)\n {\n-\tstruct rev_info rev;\n-\tinit_revisions(&rev, \"\");\n-\tsetup_revisions(0, NULL, &rev, NULL);\n-\trev.diffopt.output_format |= DIFF_FORMAT_CALLBACK;\n-\trev.diffopt.format_callback = wt_status_print_changed_cb;\n-\trev.diffopt.format_callback_data = s;\n-\trun_diff_files(&rev, 0);\n+\tint i;\n+\tint worktree_changes = wt_status_check_worktree_changes(s);\n+\n+\tif (!worktree_changes)\n+\t\treturn;\n+\n+\twt_status_print_dirty_header(s, worktree_changes < 0);\n+\t\n+\tfor (i = 0; i < s->change.nr; i++) {\n+\t\tstruct wt_status_change_data *d;\n+\t\tstruct string_list_item *it;\n+\t\tit = &(s->change.items[i]);\n+\t\td = it->util;\n+\t\tif (!d->worktree_status)\n+\t\t\tcontinue;\n+\t\twt_status_print_change_data(s, WT_STATUS_CHANGED,\n+\t\t\t\t\t d->worktree_status,\n+\t\t\t\t\t it->string,\n+\t\t\t\t\t it->string,\n+\t\t\t\t\t 0);\n+\t}\n+\twt_status_print_trailer(s);\n }\n \n static void wt_status_print_submodule_summary(struct wt_status *s)\n@@ -347,6 +469,8 @@ void wt_status_print(struct wt_status *s)\n \t\t\twt_status_print_tracking(s);\n \t}\n \n+\twt_status_collect_changes(s);\n+\n \tif (s->is_initial) {\n \t\tcolor_fprintf_ln(s->fp, color(WT_STATUS_HEADER), \"#\");\n \t\tcolor_fprintf_ln(s->fp, color(WT_STATUS_HEADER), \"# Initial commit\");\ndiff --git c/wt-status.h w/wt-status.h\nindex 78add09..00508c3 100644\n--- c/wt-status.h\n+++ w/wt-status.h\n@@ -18,6 +18,13 @@ enum untracked_status_type {\n };\n extern enum untracked_status_type show_untracked_files;\n \n+struct wt_status_change_data {\n+\tint worktree_status;\n+\tint index_status;\n+\tint index_score;\n+\tchar *head_path;\n+};\n+\n struct wt_status {\n \tint is_initial;\n \tchar *branch;\n@@ -33,6 +40,7 @@ struct wt_status {\n \tconst char *index_file;\n \tFILE *fp;\n \tconst char *prefix;\n+\tstruct string_list change;\n };\n \n int git_status_config(const char *var, const char *value, void *cb);\n@@ -40,5 +48,6 @@ extern int wt_status_use_color;\n extern int wt_status_relative_paths;\n void wt_status_prepare(struct wt_status *s);\n void wt_status_print(struct wt_status *s);\n+void wt_status_collect_changes(struct wt_status *s);\n \n #endif /* STATUS_H */\n"},{"id":"93966","messageId":"20081026045932.GB21178@coredump.intra.peff.net","threadId":"15830","inReplyTo":"7vej246sb4.fsf@gitster.siamese.dyndns.org","subject":"Re: Fwd: git status options feature suggestion","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2008-10-26T04:59:32Z","receivedAt":"2008-10-26T04:59:32Z","isPatch":false,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Oct 25, 2008 at 06:47:27PM -0700, Junio C Hamano wrote:\n\n> This was done primarily for fun and killing-time, so I won't be committing\n> it to my tree, but it seems to pass all the existing tests.\n\nI just skimmed the code, but it looks reasonably done. I don't have time\nto work on this at the moment, but I think you have done most of the\nwork that requires a lot of git knowledge. Maybe somebody new can pick\nthis up as a nice starter project to get more involved in git.\n\n-Peff\n"}]}