{"thread":{"id":"20810","subject":"unmerged files listed in the beginning of git-status","startedAt":"2009-09-01T14:52:13Z","lastAt":"2009-09-06T08:05:07Z","messageCount":34,"participants":["bill lam","Junio C Hamano","Johannes Sixt","Jeff King","David Aguilar","Mark Brown"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"122243","messageId":"20090901145213.GB4194@debian.b2j","threadId":"20810","inReplyTo":null,"subject":"unmerged files listed in the beginning of git-status","fromName":"bill lam","fromEmail":"cbill.lam@gmail.com","sentAt":"2009-09-01T14:52:13Z","receivedAt":"2009-09-01T14:52:13Z","isPatch":false,"sender":{"key":"cbill.lam@gmail.com","avatar":null},"body":"I noticed in the new git 1.6.4.2 . git-status show unmerged files\nwith a clause of explanation. This is very helpful. However these\nunmerged files are listed in the beginning and followed by modified\nfiles, I imagined the normal case will be there is only a few\nunmerged files but a much large number of other files. Thus it needs\nto shift pageup or redirect to less in order view these unmerges\nfiles. Previously these unmerge files are listed after modified files\nand easily seen or copy-and-paste using mouse. Is there any specific\nreason to change the order of sequence?\n\n-- \nregards,\n====================================================\nGPG key 1024D/4434BAB3 2008-08-24\ngpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3\n"},{"id":"122246","messageId":"7vljkypqfi.fsf@alter.siamese.dyndns.org","threadId":"20810","inReplyTo":"20090901145213.GB4194@debian.b2j","subject":"Re: unmerged files listed in the beginning of git-status","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-01T16:42:25Z","receivedAt":"2009-09-01T16:42:25Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"bill lam writes:\n\n> I noticed in the new git 1.6.4.2 .\n\nI hope you didn't. This is only in 'master' and will appear first in the\nupcoming 1.6.5; it is never meant for 1.6.4.X maintenance series and\n1.6.4.2 does not have this change.\n\n> git-status show unmerged files\n> with a clause of explanation. This is very helpful. However these\n> unmerged files are listed in the beginning and followed by modified\n> files,\n\n\"git status\" is preview of what git commit does. The \"Changes to be\ncommitted\" section is given at the beginning of the output because it is\nthe most important one. But while reviewing the conflicts, you would want\nto notice conflicted paths more than what are already resolved and staged.\n\nIt used to be that unmerged paths were mixed together with locally\nmodified paths in the \"Changed but not updated\" list, after the \"Changes\nto be committed\" list. This made the unmerged paths harder to spot than\nnecessary.\n\nTo remedy this, unmerged ones are now:\n\n (1) placed in a new, separate section that appears only when there are\n unmerged paths, to make the fact that there is something unusual\n going on (i.e. conflicts) stand out; and\n\n (2) the new section is given at the top of the status output to give\n these unmerged paths more prominence.\n\nHaving said all that, the relative importance of the pieces of information\ngiven in \"git status\" output is fairly subjective.\n\nIf you are a confident, know-what-I-am-doing type, you would see the\n\"Changes to be committed\" list the most important, because that is where\nyou make sure you have added all the changes you want to include in the\ncommit. If you are a forgetful type, on the other hand, you would see\n\"Changed but not updated\" and \"Untracked files\" more important, because\nthat is where you make sure there isn't any files you modified and new\nfiles you created that you want to include in the commit but may have\nforgotten. If you are into flipping many branches and often commit your\nchanges on a wrong branch, you may value the \"On branch foo\" information\nat the top the most. So in that sense, there cannot be a single right\norder of these sections.\n\nBut unmerged entries are something you need to deal with _first_ before\nbeing able to go further, so in that sense it is more important than\nanything else in the traditional output.\n\nIn the output, \"the most important part first\" rule is unlikely to change,\nif only because this is what you are shown when committing in the editor,\nand even in 1.7.0 when \"git status\" stops being \"git commit --dry-run\"\nbecause we would still keep consistency of the two outputs,\n\nBy the way, please do not deflect responses to your message away from\nyourself using Mail-Followup-To.\n"},{"id":"122254","messageId":"200909012140.08953.j6t@kdbg.org","threadId":"20810","inReplyTo":"7vljkypqfi.fsf@alter.siamese.dyndns.org","subject":"Re: unmerged files listed in the beginning of git-status","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2009-09-01T19:40:08Z","receivedAt":"2009-09-01T19:40:08Z","isPatch":false,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Dienstag, 1. September 2009, Junio C Hamano wrote:\n> bill lam writes:\n> > git-status show unmerged files\n> > with a clause of explanation. This is very helpful. However these\n> > unmerged files are listed in the beginning and followed by modified\n> > files,\n>\n> \"git status\" is preview of what git commit does. The \"Changes to be\n> committed\" section is given at the beginning of the output because it is\n> the most important one. But while reviewing the conflicts, you would want\n> to notice conflicted paths more than what are already resolved and staged.\n>\n> It used to be that unmerged paths were mixed together with locally\n> modified paths in the \"Changed but not updated\" list, after the \"Changes\n> to be committed\" list. This made the unmerged paths harder to spot than\n> necessary.\n>\n> To remedy this, unmerged ones are now:\n>\n> (1) placed in a new, separate section that appears only when there are\n> unmerged paths, to make the fact that there is something unusual\n> going on (i.e. conflicts) stand out; and\n>\n> (2) the new section is given at the top of the status output to give\n> these unmerged paths more prominence.\n\nBut this is very inconvenient if you merge a branch that touched many files, \nof which only a few have conflicts. In this case, the unmerged entries are \nscrolled out of view. If you want to copy-paste them into a 'git add' command \nthen (at least my) xterm (and Windows's CMD, BTW) keeps scrolling down to the \ncommand line, and since I cannot bulk-select all of them at once, I have to \nscroll up in order select any individual of them.\n\nNote that I do not complain about the \"out of view\" part (because if a list is \nlong there is inevitably something that becomes invisible), but about \nthe \"must scroll around\" part.\n\n> But unmerged entries are something you need to deal with _first_ before\n> being able to go further, so in that sense it is more important than\n> anything else in the traditional output.\n\nThis is actually an argument to place the unmerged entries *last* because this \nis what will be visible after 'git status' finished. Remember that we don't \npass its output through the pager.\n\n> In the output, \"the most important part first\" rule is unlikely to change,\n> if only because this is what you are shown when committing in the editor,\n> and even in 1.7.0 when \"git status\" stops being \"git commit --dry-run\"\n> because we would still keep consistency of the two outputs,\n\nOf course, this argument is irrelevant for the placement of the list of \nunmerged entries because by the time you enter the commit message editor, \nthis list is empty.\n\n-- Hannes\n"},{"id":"122256","messageId":"200909012213.54611.j6t@kdbg.org","threadId":"20810","inReplyTo":"200909012140.08953.j6t@kdbg.org","subject":"[PATCH] status: list unmerged files after staged files","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2009-09-01T20:13:53Z","receivedAt":"2009-09-01T20:13:53Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"The list of unmerged files is considered rather important because after\na conflicted merge they need attention. Since the output of git status does\nnot go through the pager, the end of the output remains immediately visible\nin the terminal window. By placing unmerge entries after staged entries,\nthe user can see them immediately.\n\nMoreover, keeping the unmerge entries at the top is inconvenient if a merge\ntouched many files, but only a few conflicted: After the conflicts were\nresolved, the user will conduct a 'git add' command. In order to do that\nwith copy-and-paste, the user must scroll the terminal window up, and must\ndo so for each individual entry (because terminal windows commonly scroll\ndown automatically on the paste operation to make the cursor visible).\n\nSigned-off-by: Johannes Sixt \n---\n wt-status.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 3395456..85f3fcb 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -561,8 +561,8 @@ void wt_status_print(struct wt_status *s)\n \t\tcolor_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s), \"#\");\n \t}\n \n-\twt_status_print_unmerged(s);\n \twt_status_print_updated(s);\n+\twt_status_print_unmerged(s);\n \twt_status_print_changed(s);\n \tif (s->submodule_summary)\n \t\twt_status_print_submodule_summary(s);\n-- \n1.6.4.2.280.gb16ab\n"},{"id":"122260","messageId":"7vy6oy9z9r.fsf@alter.siamese.dyndns.org","threadId":"20810","inReplyTo":"200909012213.54611.j6t@kdbg.org","subject":"Re: [PATCH] status: list unmerged files after staged files","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-01T20:38:08Z","receivedAt":"2009-09-01T20:38:08Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> Moreover, keeping the unmerge entries at the top is inconvenient if a merge\n> touched many files, but only a few conflicted: After the conflicts were\n> resolved, the user will conduct a 'git add' command. In order to do that\n> with copy-and-paste, the user must scroll the terminal window up, and must\n> do so for each individual entry (because terminal windows commonly scroll\n> down automatically on the paste operation to make the cursor visible).\n\nI actually was expecting that you would move this at the very bottom after\nuntracked list for the above reason, and also because this part is only\nshown while running status (that was a good point you made in the previous\nmessage) and never in commit.\n\n>\n> Signed-off-by: Johannes Sixt \n> ---\n> wt-status.c | 2 +-\n> 1 files changed, 1 insertions(+), 1 deletions(-)\n>\n> diff --git a/wt-status.c b/wt-status.c\n> index 3395456..85f3fcb 100644\n> --- a/wt-status.c\n> +++ b/wt-status.c\n> @@ -561,8 +561,8 @@ void wt_status_print(struct wt_status *s)\n> \t\tcolor_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s), \"#\");\n> \t}\n> \n> -\twt_status_print_unmerged(s);\n> \twt_status_print_updated(s);\n> +\twt_status_print_unmerged(s);\n> \twt_status_print_changed(s);\n> \tif (s->submodule_summary)\n> \t\twt_status_print_submodule_summary(s);\n> -- \n> 1.6.4.2.280.gb16ab\n"},{"id":"122263","messageId":"200909012325.45739.j6t@kdbg.org","threadId":"20810","inReplyTo":"7vy6oy9z9r.fsf@alter.siamese.dyndns.org","subject":"[PATCH v2] status: list unmerged files last","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2009-09-01T21:25:45Z","receivedAt":"2009-09-01T21:25:45Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"The list of unmerged files is considered rather important because after\na conflicted merge they need attention. Since the output of git status does\nnot go through the pager, the end of the output remains immediately visible\nin the terminal window. By placing unmerge entries at the end of the list,\nthe user can see them immediately.\n\nMoreover, keeping the unmerge entries at the top is inconvenient if a merge\ntouched many files, but only a few conflicted: After the conflicts were\nresolved, the user will conduct a 'git add' command. In order to do that\nwith copy-and-paste, the user must scroll the terminal window up, and must\ndo so for each individual entry (because terminal windows commonly scroll\ndown automatically on the paste operation to make the cursor visible).\n\nSigned-off-by: Johannes Sixt \n---\nOn Dienstag, 1. September 2009, Junio C Hamano wrote:\n> Johannes Sixt writes:\n> > Moreover, keeping the unmerge entries at the top is inconvenient if a\n> > merge touched many files, but only a few conflicted: After the conflicts\n> > were resolved, the user will conduct a 'git add' command. In order to do\n> > that with copy-and-paste, the user must scroll the terminal window up,\n> > and must do so for each individual entry (because terminal windows\n> > commonly scroll down automatically on the paste operation to make the\n> > cursor visible).\n>\n> I actually was expecting that you would move this at the very bottom after\n> untracked list for the above reason, and also because this part is only\n> shown while running status (that was a good point you made in the previous\n> message) and never in commit.\n\nSo you would not mind a more \"drastic\" change?\n\nThis version 2 can be regarded as a real improvement with the argument\nabove, whereas version 1 would only correct something of some\nsort of regression, compared to v1.6.4.\n\n(Originally I didn't dare to change too much and thought keeping staged\nfiles together would make sense.)\n\n-- Hannes\n\n wt-status.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 3395456..60d8425 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -561,7 +561,6 @@ void wt_status_print(struct wt_status *s)\n \t\tcolor_fprintf_ln(s->fp, color(WT_STATUS_HEADER, s), \"#\");\n \t}\n \n-\twt_status_print_unmerged(s);\n \twt_status_print_updated(s);\n \twt_status_print_changed(s);\n \tif (s->submodule_summary)\n@@ -570,6 +569,7 @@ void wt_status_print(struct wt_status *s)\n \t\twt_status_print_untracked(s);\n \telse if (s->commitable)\n \t\t fprintf(s->fp, \"# Untracked files not listed (use -u option to show untracked \nfiles)\\n\");\n+\twt_status_print_unmerged(s);\n \n \tif (s->verbose)\n \t\twt_status_print_verbose(s);\n-- \n1.6.4.2.280.gb16ab\n"},{"id":"122274","messageId":"7vtyzmxkpr.fsf@alter.siamese.dyndns.org","threadId":"20810","inReplyTo":"200909012325.45739.j6t@kdbg.org","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-02T00:18:40Z","receivedAt":"2009-09-02T00:18:40Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Johannes Sixt writes:\n\n> The list of unmerged files is considered rather important because after\n> a conflicted merge they need attention. Since the output of git status does\n> not go through the pager, the end of the output remains immediately visible\n> in the terminal window. By placing unmerge entries at the end of the list,\n> the user can see them immediately.\n>\n> Moreover, keeping the unmerge entries at the top is inconvenient if a merge\n> touched many files, but only a few conflicted: After the conflicts were\n> resolved, the user will conduct a 'git add' command. In order to do that\n> with copy-and-paste, the user must scroll the terminal window up, and must\n> do so for each individual entry (because terminal windows commonly scroll\n> down automatically on the paste operation to make the cursor visible).\n>\n> Signed-off-by: Johannes Sixt \n\n> On Dienstag, 1. September 2009, Junio C Hamano wrote:\n>\n>> I actually was expecting that you would move this at the very bottom after\n>> untracked list for the above reason, and also because this part is only\n>> shown while running status (that was a good point you made in the previous\n>> message) and never in commit.\n>\n> So you would not mind a more \"drastic\" change?\n\nWell, it's not really about what _I_ like or mind. It is primarily about\nwhat the list collectively thinks. I'd like to let other eyeballs and\nbrains to weigh in, as I am known to pick the worst layout from the UI\npoint of view as you saw in this thread already ;-).\n\n> (Originally I didn't dare to change too much and thought keeping staged\n> files together would make sense.)\n\nYes, unmerged ones are modified and the index knows about them, but you\nhaven't told git what you want to commit yet, so they are in the same\ncategory as \"changed but not updated\" in that sense, but unlike \"changed\nbut not updated\", you cannot leave them as they are before proceeding, so\nthey are worse.\n\nThe \"keeping related things together\" argument does mean your v1 is better\nthan this patch, as you had \"unmerged\" next to \"changed but not updated\".\nI personally think the \"keep related things together\" argument makes much\nmore sense than the \"close to the bottom is easier to cut and paste\"\nargument, as I tend to focus at the top of the output when looking at the\nstatus output and almost never cut & paste using mouse (screen for\nrectangular cutting and pasting works wonderfully), but it probably is\njust me. And remember that I am only just one of the users, nothing more.\n\nSadly, \"keep related things together\" and \"as close to the bottom as\npossible\" are not quite compatible, and we can pick one or the other, but\nnot both.\n\nIf I were to pick the middle ground, I would probably move it immediately\nafter the call to wt_status_print_changed(), with \"keeping related things\ntogether\" as the primary justification. It would be an incidental benefit\nthat it moves the part slightly closer to the bottom and gives it a better\nchance of staying on the screen.\n\nBut I am not a great UI designer ;-)\n"},{"id":"122275","messageId":"20090902003940.GA23954@debian.b2j","threadId":"20810","inReplyTo":"7vtyzmxkpr.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"bill lam","fromEmail":"cbill.lam@gmail.com","sentAt":"2009-09-02T00:39:40Z","receivedAt":"2009-09-02T00:39:40Z","isPatch":true,"sender":{"key":"cbill.lam@gmail.com","avatar":null},"body":"On Tue, 01 Sep 2009, Junio C Hamano wrote:\n> Sadly, \"keep related things together\" and \"as close to the bottom as\n> possible\" are not quite compatible, and we can pick one or the other, but\n> not both.\n> \n> If I were to pick the middle ground, I would probably move it immediately\n> after the call to wt_status_print_changed(), with \"keeping related things\n> together\" as the primary justification. It would be an incidental benefit\n> that it moves the part slightly closer to the bottom and gives it a better\n> chance of staying on the screen.\n\nI can only speak of my personal experience that during rebase -i,\nthere is no (or very few) untracked files in the list so that the\nsequence \"modified, unmerged, untracked\" is also a good alternative.\n\n(I hope the mail-followup-to is correct this time)\n\n-- \nregards,\n====================================================\nGPG key 1024D/4434BAB3 2008-08-24\ngpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3\n"},{"id":"122277","messageId":"20090902011513.GA3874@coredump.intra.peff.net","threadId":"20810","inReplyTo":"7vtyzmxkpr.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-02T01:15:14Z","receivedAt":"2009-09-02T01:15:14Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 01, 2009 at 05:18:40PM -0700, Junio C Hamano wrote:\n\n> The \"keeping related things together\" argument does mean your v1 is better\n> than this patch, as you had \"unmerged\" next to \"changed but not updated\".\n> I personally think the \"keep related things together\" argument makes much\n> more sense than the \"close to the bottom is easier to cut and paste\"\n> argument, as I tend to focus at the top of the output when looking at the\n> status output and almost never cut & paste using mouse (screen for\n> rectangular cutting and pasting works wonderfully), but it probably is\n> just me. And remember that I am only just one of the users, nothing more.\n> \n> Sadly, \"keep related things together\" and \"as close to the bottom as\n> possible\" are not quite compatible, and we can pick one or the other, but\n> not both.\n\nJust my two cents (and I think I have as good a track record at UI\ndesign as Junio... ;) ):\n\nI think \"related things together\" trumps \"close to the bottom\". Because\nthe former is something that _always_ applies to your output, while the\nlatter is catering to a particular use case and a particular screen\nsetup.\n\nIn other words, why is the _bottom_ reserved for more important things\ninstead of the _top_? If I have a tall terminal that is long enough to\nsee the output, are you potentially making the important thing less\nobvious (because I tend to read the the output from top to bottom)? If I\nuse a pager (either manually, because I have seen that the output is too\nlong, or automatically via the pager.status config variable)? What about\nreading status output into an interface wrapper like \"tig status\"?\n\nSo while you may be helping some users, I tend to think you may be\nhurting others.\n\n-Peff\n\nPS I am also not entirely convinced that unmerged entries are somehow\nmore important to call attention to in the list than other entries. But\nthe above argues that even _if_ you think they are more important, it is\nstill not necessarily a good thing to move them to the bottom.\n"},{"id":"122279","messageId":"7vmy5egefh.fsf@alter.siamese.dyndns.org","threadId":"20810","inReplyTo":"20090902011513.GA3874@coredump.intra.peff.net","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-02T04:26:26Z","receivedAt":"2009-09-02T04:26:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I think \"related things together\" trumps \"close to the bottom\". Because\n> the former is something that _always_ applies to your output, while the\n> latter is catering to a particular use case and a particular screen\n> setup.\n>\n> In other words, why is the _bottom_ reserved for more important things\n> instead of the _top_? If I have a tall terminal that is long enough to\n> see the output, are you potentially making the important thing less\n> obvious (because I tend to read the the output from top to bottom)? If I\n> use a pager (either manually, because I have seen that the output is too\n> long, or automatically via the pager.status config variable)? What about\n> reading status output into an interface wrapper like \"tig status\"?\n\nYes and no.\n\nSure, I always work in a 92x70 screen session with 10k lines of scrollback\nbuffer, and when I cut and paste I do not use a mouse but use screen's cut\nbuffer, so I would have no problem with the list at the top.\n\nNot that I would use \"git status\" while resolving merges---I would use\n\"ls-files -u\" myself, and I may perhaps start using \"status -suno\", so my\npersonal preference does not really count on this topic.\n\nBut not everybody is used to such a set-up. If you rely on terminal's\nscrollback buffer with mouse and a short terminal, I can see cutting and\npasting would be an issue. I do not have a good answer to \"tig status\",\nbut the design principle of supporting the lowest denominator is\nimportant.\n\nJ6t made a good point that this new section won't appear when committing,\nwhich I didn't take account when I was first explained how the ordering\nwas chosen. After thinking about this a bit more, I think \"untracked\" and\n\"modified but not updated\" sections, unlike when recording your own\ncommit, is mostly uninteresting while resolving a merge. You never add\nfiles that you forgot to add to a merge; nor you would add your local\nmodifications to a merge. So the only sections that are interesting are\nthis new \"unmerged\" section and \"updated\" section to see the extent of\ndamage the merge causes to your history by introducing the crap other\npeople dumped on you ;-) [*1*].\n\nThe above suggests me that (1) we would want to have the new \"unmerged\"\nsection next to \"updated\" section, (2) we would want to have it later in\nthe output rather than earlier, and (3) in the traditional output, people\nare used to see unmerged paths in \"changed\" section, so it would be easier\nfor them to transition if \"unmerged\" section were near \"changed\" section.\n\nThat makes the ideal place between updated and changed, no?\n\nIncidentally that is where J6t's first patch was. So I would agree with\nthe patch (but not necessarily with its justification).\n\n[1] It might even make sense to omit other sections and show only\n\"updated\" and \"unmerged\" in this order when the index is unmerged, but\nthat is a lot more drastic change for 1.7.0.\n"},{"id":"122282","messageId":"20090902051248.GB12046@coredump.intra.peff.net","threadId":"20810","inReplyTo":"7vmy5egefh.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-02T05:12:48Z","receivedAt":"2009-09-02T05:12:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 01, 2009 at 09:26:26PM -0700, Junio C Hamano wrote:\n\n> But not everybody is used to such a set-up. If you rely on terminal's\n> scrollback buffer with mouse and a short terminal, I can see cutting and\n> pasting would be an issue. I do not have a good answer to \"tig status\",\n> but the design principle of supporting the lowest denominator is\n> important.\n\nBut I'm not sure it is about \"lowest common denominator\". I think it is\nabout different people having different preferences (as a matter of\nfact, I use an 80x25 terminal most of the time, and I think I prefer the\ncontent at the top. Perhaps it is simply habit, but I do think having it\nright next to \"staged for commit\" items makes the most sense).\n\n> The above suggests me that (1) we would want to have the new \"unmerged\"\n> section next to \"updated\" section, (2) we would want to have it later in\n> the output rather than earlier, and (3) in the traditional output, people\n> are used to see unmerged paths in \"changed\" section, so it would be easier\n> for them to transition if \"unmerged\" section were near \"changed\" section.\n> \n> That makes the ideal place between updated and changed, no?\n\nYes, I think that is fine, and makes more sense than where we have it\nnow. I mainly wanted to argue against sticking it at the very bottom.\n\n> [1] It might even make sense to omit other sections and show only\n> \"updated\" and \"unmerged\" in this order when the index is unmerged, but\n> that is a lot more drastic change for 1.7.0.\n\nI think that is a really bad idea. The mental model of \"git status\"\n(versus individual diff or ls-files commands) is to see _everything_\ngoing on in the repo. Showing a subset breaks that model and gives a\nfalse sense of what is actually happening.\n\nI don't know that it would matter much most of the time anyway. If you\nhave unmerged entries, you probably don't have any (or many) \"changed\nbut not updated\" files, too (since you are not working on a new commit\nbut rather a merge, they would have to be dirty state you are carrying\npermanently, but not related to the merge). If you do, you probably want\nto see them to be aware of what is going on.\n\nYou probably also don't have a lot of untracked files. If you have a\nfew, you might want to be reminded of them to make sure they were not\nsomething you were preparing to help with a tricky merge. And if you are\nthe sort of person who carries around a lot of untracked files, and for\nsome reason you refuse to put them in your .gitignore, then you probably\nhave status.untracked set to \"no\" already (or you should consider\nsetting it), as they will be bugging you in other situations, as well.\n\n-Peff\n"},{"id":"122284","messageId":"7vljkxdiil.fsf@alter.siamese.dyndns.org","threadId":"20810","inReplyTo":"20090902051248.GB12046@coredump.intra.peff.net","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-02T05:26:26Z","receivedAt":"2009-09-02T05:26:26Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> On Tue, Sep 01, 2009 at 09:26:26PM -0700, Junio C Hamano wrote:\n>\n>> But not everybody is used to such a set-up. If you rely on terminal's\n>> scrollback buffer with mouse and a short terminal, I can see cutting and\n>> pasting would be an issue. I do not have a good answer to \"tig status\",\n>> but the design principle of supporting the lowest denominator is\n>> important.\n>\n> But I'm not sure it is about \"lowest common denominator\". I think it is\n> about different people having different preferences (as a matter of\n> fact, I use an 80x25 terminal most of the time, and I think I prefer the\n> content at the top. Perhaps it is simply habit, but I do think having it\n> right next to \"staged for commit\" items makes the most sense).\n> ...\n\nHere is how I would justify the change (the patch is the same as Hannes's\nfirst version.\n\nFrom: Johannes Sixt \nDate: Tue, 1 Sep 2009 22:13:53 +0200\nSubject: [PATCH] status: list unmerged files much later\n\nWhen resolving a conflicted merge, two lists in the status output need\nmore attention from the user than other parts.\n\n - the list of updated paths is useful to review the amount of changes the\n merge brings in (the user cannot do much about them other than\n reviewing, though); and\n\n - the list of unmerged paths needs the most attention from the user; the\n user needs to resolve them in order to proceed.\n\nSince the output of git status does not by default go through the pager,\nthe early parts of the output can scroll away at the top. It is better to\nput the more important information near the bottom. During a merge, local\nchanges that are not in the index are minimum, and you should keep the\nuntracked list small in any case, so moving the unmerged list from the top\nof the output to immediately after the list of updated paths would give us\nthe optimum layout..\n\nSigned-off-by: Johannes Sixt \nSigned-off-by: Junio C Hamano \n---\n wt-status.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n"},{"id":"122285","messageId":"20090902052832.GA13625@coredump.intra.peff.net","threadId":"20810","inReplyTo":"7vljkxdiil.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-02T05:28:32Z","receivedAt":"2009-09-02T05:28:32Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Tue, Sep 01, 2009 at 10:26:26PM -0700, Junio C Hamano wrote:\n\n> Here is how I would justify the change (the patch is the same as Hannes's\n> first version.\n\nMakes sense to me.\n\nAcked-by: Jeff King \n\n> the optimum layout..\n\nDouble period. :)\n\n-Peff\n"},{"id":"122301","messageId":"20090902090401.GA11464@debian.b2j","threadId":"20810","inReplyTo":"200909012140.08953.j6t@kdbg.org","subject":"Re: unmerged files listed in the beginning of git-status","fromName":"bill lam","fromEmail":"cbill.lam@gmail.com","sentAt":"2009-09-02T09:04:01Z","receivedAt":"2009-09-02T09:04:01Z","isPatch":false,"sender":{"key":"cbill.lam@gmail.com","avatar":null},"body":"On Tue, 01 Sep 2009, Johannes Sixt wrote:\n> > But unmerged entries are something you need to deal with _first_ before\n> > being able to go further, so in that sense it is more important than\n> > anything else in the traditional output.\n> \n> This is actually an argument to place the unmerged entries *last* because this \n> is what will be visible after 'git status' finished. Remember that we don't \n> pass its output through the pager.\n\nIf output of git-status is read indirectly such as by gui client, then\nit usually shows the top portion, in such cases, it might be desirable\nto put unmerged file (the most important port) immediately visible.\nBut I don't have that experience.\n\n-- \nregards,\n====================================================\nGPG key 1024D/4434BAB3 2008-08-24\ngpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3\n"},{"id":"122305","messageId":"20090902100730.GA18226@gmail.com","threadId":"20810","inReplyTo":"7vljkxdiil.fsf@alter.siamese.dyndns.org","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2009-09-02T10:07:32Z","receivedAt":"2009-09-02T10:07:32Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Tue, Sep 01, 2009 at 10:26:26PM -0700, Junio C Hamano wrote:\n> \n> Here is how I would justify the change (the patch is the same as Hannes's\n> first version.\n> \n> From: Johannes Sixt \n> Date: Tue, 1 Sep 2009 22:13:53 +0200\n> Subject: [PATCH] status: list unmerged files much later\n> \n> When resolving a conflicted merge, two lists in the status output need\n> more attention from the user than other parts.\n> \n> - the list of updated paths is useful to review the amount of changes the\n> merge brings in (the user cannot do much about them other than\n> reviewing, though); and\n> \n> - the list of unmerged paths needs the most attention from the user; the\n> user needs to resolve them in order to proceed.\n> \n> Since the output of git status does not by default go through the pager,\n> the early parts of the output can scroll away at the top. It is better to\n> put the more important information near the bottom. During a merge, local\n> changes that are not in the index are minimum, and you should keep the\n> untracked list small in any case, so moving the unmerged list from the top\n> of the output to immediately after the list of updated paths would give us\n> the optimum layout..\n\nI agree with all of this but would also add that we can have\nour cake and eat it too with respect to wanting to \"keep\nsimilar things together\" and having \"unmerged near bottom\".\n\nNo one has suggested this, so I figured I would.\nWhat do you think about this layout?\n\n- untracked\n- staged\n- modified\n- unmerged\n\nThis isn't the first thing someone would think of, but here's\nwhy it is intuitive:\n\n- untracked entries come first because in the git world they\n are weird. We don't like to see these things and we tend to\n .gitignore them away.\n\n- staged entries come next, though we know that in practice\n staged is often shown first since we tend to not care about\n untracked files. This often contains entries when merging\n but we do not often do much with these besides review them.\n\n- modified entries come next because they need our attention.\n When merging this list is often small or non-existant,\n thus unmerged often follows immediately after staged.\n\n- unmerged comes last for all of the reasons listed above.\n We give these special treatment because they often\n require even more attention than modified files.\n\nWhat do you guys think?\n\n\nWhile I've got you guys.. I have a patch for the new 1.7\nstatus that makes it:\n\n\tgit status [] [--] [pathspec]\n\t(it adds support for tree-ish)\n\n\nI added that because I thought that the porcelain-ish short\nstatus output could be useful for \"what does commit --amend\ndo\" from a script-writers' pov, and thus adding \nenables git status -s HEAD^.\n\nIs this a good idea? I'll send the patch if others are\ninterested. It seemed useful to me; my rationale was that\nright now git-status is hardcoded to HEAD and thus exposing\nthat variable seemed useful.\n\nBTW is status -s intended to be something plumbing-like;\nsomething we can build upon and expect to be stable?\nI'm just curious because other commands have a --porcelain\noption and I wasn't sure if this was the intent.\n\n\nThanks,\n\n-- \n\n\tDavid\n"},{"id":"122308","messageId":"20090902124832.GC4012@sirena.org.uk","threadId":"20810","inReplyTo":"20090902051248.GB12046@coredump.intra.peff.net","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Mark Brown","fromEmail":"broonie@opensource.wolfsonmicro.com","sentAt":"2009-09-02T12:48:32Z","receivedAt":"2009-09-02T12:48:32Z","isPatch":true,"sender":{"key":"broonie@opensource.wolfsonmicro.com","avatar":"https://gravatar.com/avatar/5fb25e4e0de3255caa21123e2b518c314d26245069221ff55910d5c6ba3343c4?d=mp&s=160"},"body":"On Wed, Sep 02, 2009 at 01:12:48AM -0400, Jeff King wrote:\n> On Tue, Sep 01, 2009 at 09:26:26PM -0700, Junio C Hamano wrote:\n\n> > [1] It might even make sense to omit other sections and show only\n> > \"updated\" and \"unmerged\" in this order when the index is unmerged, but\n> > that is a lot more drastic change for 1.7.0.\n\n> I think that is a really bad idea. The mental model of \"git status\"\n> (versus individual diff or ls-files commands) is to see _everything_\n> going on in the repo. Showing a subset breaks that model and gives a\n> false sense of what is actually happening.\n\nIt would be nice to be able to explicitly ask to suppress some of the\noutput for cases where there's a lot of it and only a small part is\ninteresting (like when resolving a large merge as mentioned earlier) - I\noften end up doing this by hand in those situations. I do agree that\ndoing this by default would be surprising.\n"},{"id":"122323","messageId":"20090902175908.GA5998@coredump.intra.peff.net","threadId":"20810","inReplyTo":"20090902100730.GA18226@gmail.com","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-02T17:59:08Z","receivedAt":"2009-09-02T17:59:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 02, 2009 at 03:07:32AM -0700, David Aguilar wrote:\n\n> I agree with all of this but would also add that we can have\n> our cake and eat it too with respect to wanting to \"keep\n> similar things together\" and having \"unmerged near bottom\".\n\nWell, my point was that the \"bottom\" is not really cake, but I am not\nsure anyone else agrees.\n\n> No one has suggested this, so I figured I would.\n> What do you think about this layout?\n> \n> - untracked\n> - staged\n> - modified\n> - unmerged\n\nWhat about the current branch? Alternate author info? Tracking branch\nrelationship? Should those be at the top or bottom?\n\nI dunno. Maybe it is just me being crotchety and hating change, but I\nlike the current order (though swapping it below \"updated\" is fine with\nme).\n\n> While I've got you guys.. I have a patch for the new 1.7\n> status that makes it:\n> \n> \tgit status [] [--] [pathspec]\n> \t(it adds support for tree-ish)\n> \n> I added that because I thought that the porcelain-ish short\n> status output could be useful for \"what does commit --amend\n> do\" from a script-writers' pov, and thus adding \n> enables git status -s HEAD^.\n\nIf you want to know \"what does commit --amend do\", then shouldn't you be\nusing \"git commit --amend --dry-run\" (which is what \"git status\" is now,\nbut will not be in v1.7.0)?\n\nAre there other uses cases for arbitrary tree-ish's?\n\n> BTW is status -s intended to be something plumbing-like;\n> something we can build upon and expect to be stable?\n> I'm just curious because other commands have a --porcelain\n> option and I wasn't sure if this was the intent.\n\nWe mentioned a --porcelain option in other discussion, but I don't think\nthere is a patch. I would be in favor of --porcelain, even if it is\ncurrently identical to --short, because then it gives us freedom to\ndiverge later (and in particular it gives us the freedom to let user\nconfiguration affect what is shown).\n\n-Peff\n"},{"id":"122324","messageId":"20090902180050.GB5998@coredump.intra.peff.net","threadId":"20810","inReplyTo":"20090902124832.GC4012@sirena.org.uk","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-02T18:00:50Z","receivedAt":"2009-09-02T18:00:50Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 02, 2009 at 01:48:32PM +0100, Mark Brown wrote:\n\n> It would be nice to be able to explicitly ask to suppress some of the\n> output for cases where there's a lot of it and only a small part is\n> interesting (like when resolving a large merge as mentioned earlier) - I\n> often end up doing this by hand in those situations. I do agree that\n> doing this by default would be surprising.\n\nYeah, we already have --untracked-files= and a matching\nconfig variable. If there are cases people find useful, I don't see a\nreason why we can't make other sections configurable, too. I think it\njust somebody to write a patch for the behavior they think makes sense\n(or at the very least a concrete proposal).\n\n-Peff\n"},{"id":"122328","messageId":"20090902183923.GA10581@rakim.wolfsonmicro.main","threadId":"20810","inReplyTo":"20090902180050.GB5998@coredump.intra.peff.net","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Mark Brown","fromEmail":"broonie@opensource.wolfsonmicro.com","sentAt":"2009-09-02T18:39:23Z","receivedAt":"2009-09-02T18:39:23Z","isPatch":true,"sender":{"key":"broonie@opensource.wolfsonmicro.com","avatar":"https://gravatar.com/avatar/5fb25e4e0de3255caa21123e2b518c314d26245069221ff55910d5c6ba3343c4?d=mp&s=160"},"body":"On Wed, Sep 02, 2009 at 02:00:50PM -0400, Jeff King wrote:\n\n> Yeah, we already have --untracked-files= and a matching\n> config variable. If there are cases people find useful, I don't see a\n> reason why we can't make other sections configurable, too. I think it\n> just somebody to write a patch for the behavior they think makes sense\n> (or at the very least a concrete proposal).\n\nMy main wishlist would be to have the same control for the changes to be\ncommitted for the big merge case, the use case being while resolving\nmerges where those changes are those that have been dealt with and the\nremaining (hopefully much fewer) changes are those that still need\nattention.\n"},{"id":"122329","messageId":"200909022119.42102.j6t@kdbg.org","threadId":"20810","inReplyTo":"20090902100730.GA18226@gmail.com","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Johannes Sixt","fromEmail":"j6t@kdbg.org","sentAt":"2009-09-02T19:19:41Z","receivedAt":"2009-09-02T19:19:41Z","isPatch":true,"sender":{"key":"j6t@kdbg.org","avatar":"https://avatars.githubusercontent.com/u/14810926?v=4"},"body":"On Mittwoch, 2. September 2009, David Aguilar wrote:\n> No one has suggested this, so I figured I would.\n> What do you think about this layout?\n>\n> - untracked\n> - staged\n> - modified\n> - unmerged\n\nYou forget that these things also appear in the commit message editor. In that \nlocation, the important things must be at the *top*.\n\nWe can freely move the list of unmerged files because it will not appear in \nthe commit message editor. The current order of the other lists is sane, IMO.\n\n-- Hannes\n"},{"id":"122337","messageId":"20090903011234.GA7415@gmail.com","threadId":"20810","inReplyTo":"20090902175908.GA5998@coredump.intra.peff.net","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"David Aguilar","fromEmail":"davvid@gmail.com","sentAt":"2009-09-03T01:12:36Z","receivedAt":"2009-09-03T01:12:36Z","isPatch":true,"sender":{"key":"davvid@gmail.com","avatar":"https://avatars.githubusercontent.com/u/13196?v=4"},"body":"On Wed, Sep 02, 2009 at 01:59:08PM -0400, Jeff King wrote:\n> On Wed, Sep 02, 2009 at 03:07:32AM -0700, David Aguilar wrote:\n> \n> > I agree with all of this but would also add that we can have\n> > our cake and eat it too with respect to wanting to \"keep\n> > similar things together\" and having \"unmerged near bottom\".\n> \n> Well, my point was that the \"bottom\" is not really cake, but I am not\n> sure anyone else agrees.\n> \n> > No one has suggested this, so I figured I would.\n> > What do you think about this layout?\n> > \n> > - untracked\n> > - staged\n> > - modified\n> > - unmerged\n> \n> What about the current branch? Alternate author info? Tracking branch\n> relationship? Should those be at the top or bottom?\n> \n> I dunno. Maybe it is just me being crotchety and hating change, but I\n> like the current order (though swapping it below \"updated\" is fine with\n> me).\n\n\nNah, you're right.\nBeing crotchety and hating change is a good thing here.\n\n\n\n> If you want to know \"what does commit --amend do\", then shouldn't you be\n> using \"git commit --amend --dry-run\" (which is what \"git status\" is now,\n> but will not be in v1.7.0)?\n> \n> Are there other uses cases for arbitrary tree-ish's?\n> \n> > BTW is status -s intended to be something plumbing-like;\n> > something we can build upon and expect to be stable?\n> > I'm just curious because other commands have a --porcelain\n> > option and I wasn't sure if this was the intent.\n> \n> We mentioned a --porcelain option in other discussion, but I don't think\n> there is a patch. I would be in favor of --porcelain, even if it is\n> currently identical to --short, because then it gives us freedom to\n> diverge later (and in particular it gives us the freedom to let user\n> configuration affect what is shown).\n> \n> -Peff\n\nThe only use case would be for --amend.\nWhich is why I asked about --porcelain; really what I want is\nsomething like\n\n\tgit status --porcelain HEAD^\n\nRolling a patch to make --porcelain an alias for --short seems\nlike a good idea. If we want to support HEAD^ and HEAD^ only\nthen perhaps an --amend flag is useful.\n\nThe real crux of my question was about being able to script\nit, which is why commit --dry-run is not enough.\n\n-- \n\n\tDavid\n"},{"id":"122484","messageId":"20090905062846.GD29863@coredump.intra.peff.net","threadId":"20810","inReplyTo":"20090903011234.GA7415@gmail.com","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-05T06:28:46Z","receivedAt":"2009-09-05T06:28:46Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 02, 2009 at 06:12:36PM -0700, David Aguilar wrote:\n\n> The only use case would be for --amend.\n> Which is why I asked about --porcelain; really what I want is\n> something like\n> \n> \tgit status --porcelain HEAD^\n> \n> Rolling a patch to make --porcelain an alias for --short seems\n> like a good idea. If we want to support HEAD^ and HEAD^ only\n> then perhaps an --amend flag is useful.\n> \n> The real crux of my question was about being able to script\n> it, which is why commit --dry-run is not enough.\n\nI see. I still think you may want to improve \"commit --dry-run\" with a\nplumbing format, though, instead of \"git status\". Then it would\nautomagically support \"--amend\", as well as other dry-run things (e.g.,\n\"git commit --dry-run --porcelain --amend foo.c\"). And not having looked\nat the code, I would guess it is a one-liner patch to switch the \"output\nformat\" flag that commit passes to the wt-status.c code.\n\n-Peff\n"},{"id":"122500","messageId":"20090905084809.GA13073@coredump.intra.peff.net","threadId":"20810","inReplyTo":"20090905062846.GD29863@coredump.intra.peff.net","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-05T08:48:09Z","receivedAt":"2009-09-05T08:48:09Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 05, 2009 at 02:28:46AM -0400, Jeff King wrote:\n\n> I see. I still think you may want to improve \"commit --dry-run\" with a\n> plumbing format, though, instead of \"git status\". Then it would\n> automagically support \"--amend\", as well as other dry-run things (e.g.,\n> \"git commit --dry-run --porcelain --amend foo.c\"). And not having looked\n> at the code, I would guess it is a one-liner patch to switch the \"output\n> format\" flag that commit passes to the wt-status.c code.\n\nOK, it was a bit more complex than that. But here is a series which does\na few things. It is still missing a few bits, so is RFC.\n\n These first two are unrelated fixups that I noticed while working.\n\n [1/6]: status: typo fix in usage\n [2/6]: docs: note that status configuration affects only long format\n\n These are the --porcelain patches we discussed. The first two are\n obviously cleanup.\n\n [3/6]: status: refactor short-mode printing to its own function\n [4/6]: status: refactor format option parsing\n [5/6]: status: add --porcelain output format\n\n This brings the new formats to \"commit --dry-run\" to handle your case.\n Conceptually, it could come before (or instead) of 4/6 and 5/6, but as\n it adds both --short and --porcelain, there is an obvious dependency.\n\n [6/6]: commit: support alternate status formats\n\n-Peff\n"},{"id":"122501","messageId":"20090905085026.GA13157@coredump.intra.peff.net","threadId":"20810","inReplyTo":"20090905084809.GA13073@coredump.intra.peff.net","subject":"[PATCH/RFC 1/6] status: typo fix in usage","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-05T08:50:26Z","receivedAt":"2009-09-05T08:50:26Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"\nSigned-off-by: Jeff King \n---\n builtin-commit.c | 2 +-\n 1 files changed, 1 insertions(+), 1 deletions(-)\n\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex 6cb0e40..812470e 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -975,7 +975,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \tstatic struct option builtin_status_options[] = {\n \t\tOPT__VERBOSE(&verbose),\n \t\tOPT_BOOLEAN('s', \"short\", &shortstatus,\n-\t\t\t \"show status concicely\"),\n+\t\t\t \"show status concisely\"),\n \t\tOPT_BOOLEAN('z', \"null\", &null_termination,\n \t\t\t \"terminate entries with NUL\"),\n \t\t{ OPTION_STRING, 'u', \"untracked-files\", &untracked_files_arg,\n-- \n1.6.4.2.418.g1a1d3.dirty\n"},{"id":"122502","messageId":"20090905085218.GB13157@coredump.intra.peff.net","threadId":"20810","inReplyTo":"20090905084809.GA13073@coredump.intra.peff.net","subject":"[PATCH/RFC 2/6] docs: note that status configuration affects only long format","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-05T08:52:18Z","receivedAt":"2009-09-05T08:52:18Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The short format does not respect any of the usual status.*\nconfiguration.\n\nSigned-off-by: Jeff King \n---\nCombined with the --short/--porcelain distinction introduced later in\nthe series, should short perhaps respect status.relativePaths and\nstatus.submoduleSummary? Which would mean replacing this patch with ones\nto make those things work. :)\n\n Documentation/git-status.txt | 10 +++++-----\n 1 files changed, 5 insertions(+), 5 deletions(-)\n\ndiff --git a/Documentation/git-status.txt b/Documentation/git-status.txt\nindex b5939d6..fd71a7a 100644\n--- a/Documentation/git-status.txt\n+++ b/Documentation/git-status.txt\n@@ -109,13 +109,13 @@ compatibility) and `color.status.` configuration variables\n to colorize its output.\n \n If the config variable `status.relativePaths` is set to false, then all\n-paths shown are relative to the repository root, not to the current\n-directory.\n+paths shown in the long format are relative to the repository root, not\n+to the current directory.\n \n If `status.submodulesummary` is set to a non zero number or true (identical\n-to -1 or an unlimited number), the submodule summary will be enabled and a\n-summary of commits for modified submodules will be shown (see --summary-limit\n-option of linkgit:git-submodule[1]).\n+to -1 or an unlimited number), the submodule summary will be enabled for\n+the long format and a summary of commits for modified submodules will be\n+shown (see --summary-limit option of linkgit:git-submodule[1]).\n \n SEE ALSO\n --------\n-- \n1.6.4.2.418.g1a1d3.dirty\n"},{"id":"122503","messageId":"20090905085348.GC13157@coredump.intra.peff.net","threadId":"20810","inReplyTo":"20090905084809.GA13073@coredump.intra.peff.net","subject":"[PATCH/RFC 3/6] status: refactor short-mode printing to its own function","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-05T08:53:48Z","receivedAt":"2009-09-05T08:53:48Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"We want to be able to call it from multiple places.\n\nSigned-off-by: Jeff King \n---\nI am tempted to move all of the short-printing code to its own file, and\nmove \"cmd_status\" to its own builtin-status.c, as well. I don't know if\nthat is a cleanup that makes sense to others, as well, or if it is too\nmuch churn for too little good.\n\n builtin-commit.c | 45 +++++++++++++++++++++++++--------------------\n 1 files changed, 25 insertions(+), 20 deletions(-)\n\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex 812470e..5b42179 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -966,11 +966,32 @@ static void short_untracked(int null_termination, struct string_list_item *it,\n \t}\n }\n \n+static void short_print(struct wt_status *s, int null_termination)\n+{\n+\tint i;\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+\n+\t\tit = &(s->change.items[i]);\n+\t\td = it->util;\n+\t\tif (d->stagemask)\n+\t\t\tshort_unmerged(null_termination, it, s);\n+\t\telse\n+\t\t\tshort_status(null_termination, it, s);\n+\t}\n+\tfor (i = 0; i < s->untracked.nr; i++) {\n+\t\tstruct string_list_item *it;\n+\n+\t\tit = &(s->untracked.items[i]);\n+\t\tshort_untracked(null_termination, it, s);\n+\t}\n+}\n+\n int cmd_status(int argc, const char **argv, const char *prefix)\n {\n \tstruct wt_status s;\n \tstatic int null_termination, shortstatus;\n-\tint i;\n \tunsigned char sha1[20];\n \tstatic struct option builtin_status_options[] = {\n \t\tOPT__VERBOSE(&verbose),\n@@ -1003,25 +1024,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \ts.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;\n \twt_status_collect(&s);\n \n-\tif (shortstatus) {\n-\t\tfor (i = 0; i < s.change.nr; i++) {\n-\t\t\tstruct wt_status_change_data *d;\n-\t\t\tstruct string_list_item *it;\n-\n-\t\t\tit = &(s.change.items[i]);\n-\t\t\td = it->util;\n-\t\t\tif (d->stagemask)\n-\t\t\t\tshort_unmerged(null_termination, it, &s);\n-\t\t\telse\n-\t\t\t\tshort_status(null_termination, it, &s);\n-\t\t}\n-\t\tfor (i = 0; i < s.untracked.nr; i++) {\n-\t\t\tstruct string_list_item *it;\n-\n-\t\t\tit = &(s.untracked.items[i]);\n-\t\t\tshort_untracked(null_termination, it, &s);\n-\t\t}\n-\t} else {\n+\tif (shortstatus)\n+\t\tshort_print(&s, null_termination);\n+\telse {\n \t\ts.verbose = verbose;\n \t\tif (s.relative_paths)\n \t\t\ts.prefix = prefix;\n-- \n1.6.4.2.418.g1a1d3.dirty\n"},{"id":"122504","messageId":"20090905085414.GD13157@coredump.intra.peff.net","threadId":"20810","inReplyTo":"20090905084809.GA13073@coredump.intra.peff.net","subject":"[PATCH/RFC 4/6] status: refactor format option parsing","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-05T08:54:14Z","receivedAt":"2009-09-05T08:54:14Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"This makes it possible to have more than two formats.\n\nSigned-off-by: Jeff King \n---\nThis would make a \"--long\" option trivial, but I'm not sure there is\nmuch point.\n\n builtin-commit.c | 21 ++++++++++++++-------\n 1 files changed, 14 insertions(+), 7 deletions(-)\n\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex 5b42179..aa4a358 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -991,12 +991,16 @@ static void short_print(struct wt_status *s, int null_termination)\n int cmd_status(int argc, const char **argv, const char *prefix)\n {\n \tstruct wt_status s;\n-\tstatic int null_termination, shortstatus;\n+\tstatic int null_termination;\n+\tstatic enum {\n+\t\tSTATUS_FORMAT_LONG,\n+\t\tSTATUS_FORMAT_SHORT,\n+\t} status_format = STATUS_FORMAT_LONG;\n \tunsigned char sha1[20];\n \tstatic struct option builtin_status_options[] = {\n \t\tOPT__VERBOSE(&verbose),\n-\t\tOPT_BOOLEAN('s', \"short\", &shortstatus,\n-\t\t\t \"show status concisely\"),\n+\t\tOPT_SET_INT('s', \"short\", &status_format,\n+\t\t\t \"show status concisely\", STATUS_FORMAT_SHORT),\n \t\tOPT_BOOLEAN('z', \"null\", &null_termination,\n \t\t\t \"terminate entries with NUL\"),\n \t\t{ OPTION_STRING, 'u', \"untracked-files\", &untracked_files_arg,\n@@ -1006,8 +1010,8 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \t\tOPT_END(),\n \t};\n \n-\tif (null_termination)\n-\t\tshortstatus = 1;\n+\tif (null_termination && status_format == STATUS_FORMAT_LONG)\n+\t\tstatus_format = STATUS_FORMAT_SHORT;\n \n \twt_status_prepare(&s);\n \tgit_config(git_status_config, &s);\n@@ -1024,9 +1028,11 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \ts.is_initial = get_sha1(s.reference, sha1) ? 1 : 0;\n \twt_status_collect(&s);\n \n-\tif (shortstatus)\n+\tswitch (status_format) {\n+\tcase STATUS_FORMAT_SHORT:\n \t\tshort_print(&s, null_termination);\n-\telse {\n+\t\tbreak;\n+\tcase STATUS_FORMAT_LONG:\n \t\ts.verbose = verbose;\n \t\tif (s.relative_paths)\n \t\t\ts.prefix = prefix;\n@@ -1035,6 +1041,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \t\tif (diff_use_color_default == -1)\n \t\t\tdiff_use_color_default = git_use_color_default;\n \t\twt_status_print(&s);\n+\t\tbreak;\n \t}\n \treturn 0;\n }\n-- \n1.6.4.2.418.g1a1d3.dirty\n"},{"id":"122506","messageId":"20090905085537.GE13157@coredump.intra.peff.net","threadId":"20810","inReplyTo":"20090905084809.GA13073@coredump.intra.peff.net","subject":"[PATCH/RFC 5/6] status: add --porcelain output format","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-05T08:55:37Z","receivedAt":"2009-09-05T08:55:37Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The \"short\" format was added to \"git status\" recently to\nprovide a less verbose way of looking at the same\ninformation. This has two practical uses:\n\n 1. Users who want a more dense display of the information.\n\n 2. Scripts which want to parse the information and need a\n stable, easy-to-parse interface.\n\nFor now, the \"--short\" format covers both of those uses.\nHowever, as time goes on, users of (1) may want additional\nformat tweaks, or for \"git status\" to change its behavior\nbased on configuration variables. Those wishes will be at\nodds with (2), which wants to stability for scripts.\n\nThis patch introduces a separate --porcelain option early to\navoid problems later on. Right now the --short and\n--porcelain outputs are identical. However, as time goes on,\nwe will have the freedom to customize --short for human\nconsumption while keeping --porcelain stable.\n\nSigned-off-by: Jeff King \n---\nNo tests. Does this really need them? At this point, it would be pure\nduplication of the --short tests; I am inclined to leave such tests\nuntil later when there is actually a difference between the two formats\n(and then we will know _what_ to test).\n\n Documentation/git-status.txt | 9 +++++++--\n builtin-commit.c | 9 ++++++++-\n 2 files changed, 15 insertions(+), 3 deletions(-)\n\ndiff --git a/Documentation/git-status.txt b/Documentation/git-status.txt\nindex fd71a7a..58d35fb 100644\n--- a/Documentation/git-status.txt\n+++ b/Documentation/git-status.txt\n@@ -27,6 +27,11 @@ OPTIONS\n --short::\n \tGive the output in the short-format.\n \n+--porcelain::\n+\tGive the output in a stable, easy-to-parse format for scripts.\n+\tCurrently this is identical to --short output, but is guaranteed\n+\tnot to change in the future, making it safe for scripts.\n+\n -u[]::\n --untracked-files[=]::\n \tShow untracked files (Default: 'all').\n@@ -45,8 +50,8 @@ used to change the default for when the option is not\n specified.\n \n -z::\n-\tTerminate entries with NUL, instead of LF. This implies `-s`\n-\t(short status) output format.\n+\tTerminate entries with NUL, instead of LF. This implies\n+\tthe `--porcelain` output format if no other format is given.\n \n \n OUTPUT\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex aa4a358..ffdee31 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -995,12 +995,16 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \tstatic enum {\n \t\tSTATUS_FORMAT_LONG,\n \t\tSTATUS_FORMAT_SHORT,\n+\t\tSTATUS_FORMAT_PORCELAIN,\n \t} status_format = STATUS_FORMAT_LONG;\n \tunsigned char sha1[20];\n \tstatic struct option builtin_status_options[] = {\n \t\tOPT__VERBOSE(&verbose),\n \t\tOPT_SET_INT('s', \"short\", &status_format,\n \t\t\t \"show status concisely\", STATUS_FORMAT_SHORT),\n+\t\tOPT_SET_INT(0, \"porcelain\", &status_format,\n+\t\t\t \"show porcelain output format\",\n+\t\t\t STATUS_FORMAT_PORCELAIN),\n \t\tOPT_BOOLEAN('z', \"null\", &null_termination,\n \t\t\t \"terminate entries with NUL\"),\n \t\t{ OPTION_STRING, 'u', \"untracked-files\", &untracked_files_arg,\n@@ -1011,7 +1015,7 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \t};\n \n \tif (null_termination && status_format == STATUS_FORMAT_LONG)\n-\t\tstatus_format = STATUS_FORMAT_SHORT;\n+\t\tstatus_format = STATUS_FORMAT_PORCELAIN;\n \n \twt_status_prepare(&s);\n \tgit_config(git_status_config, &s);\n@@ -1032,6 +1036,9 @@ int cmd_status(int argc, const char **argv, const char *prefix)\n \tcase STATUS_FORMAT_SHORT:\n \t\tshort_print(&s, null_termination);\n \t\tbreak;\n+\tcase STATUS_FORMAT_PORCELAIN:\n+\t\tshort_print(&s, null_termination);\n+\t\tbreak;\n \tcase STATUS_FORMAT_LONG:\n \t\ts.verbose = verbose;\n \t\tif (s.relative_paths)\n-- \n1.6.4.2.418.g1a1d3.dirty\n"},{"id":"122507","messageId":"20090905085956.GF13157@coredump.intra.peff.net","threadId":"20810","inReplyTo":"20090905084809.GA13073@coredump.intra.peff.net","subject":"[PATCH/RFC 6/6] commit: support alternate status formats","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-05T08:59:56Z","receivedAt":"2009-09-05T08:59:56Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"The status command recently grew \"short\" and \"porcelain\"\noptions for alternate output formats. Since status is no\nlonger \"commit --dry-run\", these formats are inaccessible to\npeople who do want to see a dry-run in a parseable form.\n\nThis patch makes those formats available to \"git commit\",\nimplying the \"dry-run\" option when they are used.\n\nSigned-off-by: Jeff King \n---\nThis one is very RFC, as it has a few problems/questions:\n\n - no tests yet, and it definitely should have some\n\n - should alternate formats imply dry-run? It makes no sense to _not_ do\n dry-run, since you would be putting cruft into the editor for the\n user to see. But the other option would be barfing and complaining\n about mismatched options.\n\n - the \"committable\" flag is set in wt_status_print, which means it will\n not be set correctly for short output. I can hack it into the short\n output format, but I think it is probably a mistake for it to be\n stuck with the printing routines in the first place (it is a\n historical artifact, I suspect, from before we always had a \"collect\"\n phase). So I think it should probably just be part of the \"collect\"\n phase.\n\n Documentation/git-commit.txt | 14 ++++++++++++++\n builtin-commit.c | 39 ++++++++++++++++++++++++++++++++-------\n 2 files changed, 46 insertions(+), 7 deletions(-)\n\ndiff --git a/Documentation/git-commit.txt b/Documentation/git-commit.txt\nindex 64f94cf..c45fbe4 100644\n--- a/Documentation/git-commit.txt\n+++ b/Documentation/git-commit.txt\n@@ -75,6 +75,20 @@ OPTIONS\n \tand paths that are untracked, similar to the one that is given\n \tin the commit log editor.\n \n+--short::\n+\tWhen doing a dry-run, give the output in the short-format. See\n+\tlinkgit:git-status[1] for details. Implies `--dry-run`.\n+\n+--porcelain::\n+\tWhen doing a dry-run, give the output in a porcelain-ready\n+\tformat. See linkgit:git-status[1] for details. Implies\n+\t`--dry-run`.\n+\n+-z::\n+\tWhen showing `short` or `porcelain` status output, terminate\n+\tentries in the status output with NUL, instead of LF. If no\n+\tformat is given, implies the `--porcelain` output format.\n+\n -F ::\n --file=::\n \tTake the commit message from the given file. Use '-' to\ndiff --git a/builtin-commit.c b/builtin-commit.c\nindex ffdee31..f2fd0a4 100644\n--- a/builtin-commit.c\n+++ b/builtin-commit.c\n@@ -72,6 +72,15 @@ static int use_editor = 1, initial_commit, in_merge;\n static const char *only_include_assumed;\n static struct strbuf message;\n \n+static int null_termination;\n+static enum {\n+\tSTATUS_FORMAT_LONG,\n+\tSTATUS_FORMAT_SHORT,\n+\tSTATUS_FORMAT_PORCELAIN,\n+} status_format = STATUS_FORMAT_LONG;\n+\n+static void short_print(struct wt_status *s, int null_termination);\n+\n static int opt_parse_m(const struct option *opt, const char *arg, int unset)\n {\n \tstruct strbuf *buf = opt->value;\n@@ -105,6 +114,12 @@ static struct option builtin_commit_options[] = {\n \tOPT_BOOLEAN('o', \"only\", &only, \"commit only specified files\"),\n \tOPT_BOOLEAN('n', \"no-verify\", &no_verify, \"bypass pre-commit hook\"),\n \tOPT_BOOLEAN(0, \"dry-run\", &dry_run, \"show what would be committed\"),\n+\tOPT_SET_INT(0, \"short\", &status_format, \"show status concisely\",\n+\t\t STATUS_FORMAT_SHORT),\n+\tOPT_SET_INT(0, \"porcelain\", &status_format,\n+\t\t \"show porcelain output format\", STATUS_FORMAT_PORCELAIN),\n+\tOPT_BOOLEAN('z', \"null\", &null_termination,\n+\t\t \"terminate entries with NUL\"),\n \tOPT_BOOLEAN(0, \"amend\", &amend, \"amend previous commit\"),\n \t{ OPTION_STRING, 'u', \"untracked-files\", &untracked_files_arg, \"mode\", \"show untracked files, optional modes: all, normal, no. (Default: all)\", PARSE_OPT_OPTARG, NULL, (intptr_t)\"all\" },\n \tOPT_BOOLEAN(0, \"allow-empty\", &allow_empty, \"ok to record an empty change\"),\n@@ -363,7 +378,18 @@ static int run_status(FILE *fp, const char *index_file, const char *prefix, int\n \ts->is_initial = get_sha1(s->reference, sha1) ? 1 : 0;\n \n \twt_status_collect(s);\n-\twt_status_print(s);\n+\n+\tswitch (status_format) {\n+\tcase STATUS_FORMAT_SHORT:\n+\t\tshort_print(s, null_termination);\n+\t\tbreak;\n+\tcase STATUS_FORMAT_PORCELAIN:\n+\t\tshort_print(s, null_termination);\n+\t\tbreak;\n+\tcase STATUS_FORMAT_LONG:\n+\t\twt_status_print(s);\n+\t\tbreak;\n+\t}\n \n \treturn s->commitable;\n }\n@@ -821,6 +847,11 @@ static int parse_and_validate_options(int argc, const char *argv[],\n \telse if (interactive && argc > 0)\n \t\tdie(\"Paths with --interactive does not make sense.\");\n \n+\tif (null_termination && status_format == STATUS_FORMAT_LONG)\n+\t\tstatus_format = STATUS_FORMAT_PORCELAIN;\n+\tif (status_format != STATUS_FORMAT_LONG)\n+\t\tdry_run = 1;\n+\n \treturn argc;\n }\n \n@@ -991,12 +1022,6 @@ static void short_print(struct wt_status *s, int null_termination)\n int cmd_status(int argc, const char **argv, const char *prefix)\n {\n \tstruct wt_status s;\n-\tstatic int null_termination;\n-\tstatic enum {\n-\t\tSTATUS_FORMAT_LONG,\n-\t\tSTATUS_FORMAT_SHORT,\n-\t\tSTATUS_FORMAT_PORCELAIN,\n-\t} status_format = STATUS_FORMAT_LONG;\n \tunsigned char sha1[20];\n \tstatic struct option builtin_status_options[] = {\n \t\tOPT__VERBOSE(&verbose),\n-- \n1.6.4.2.418.g1a1d3.dirty\n"},{"id":"122508","messageId":"20090905090422.GA13221@coredump.intra.peff.net","threadId":"20810","inReplyTo":"20090902183923.GA10581@rakim.wolfsonmicro.main","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-05T09:04:22Z","receivedAt":"2009-09-05T09:04:22Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Wed, Sep 02, 2009 at 07:39:23PM +0100, Mark Brown wrote:\n\n> My main wishlist would be to have the same control for the changes to be\n> committed for the big merge case, the use case being while resolving\n> merges where those changes are those that have been dealt with and the\n> remaining (hopefully much fewer) changes are those that still need\n> attention.\n\nI think we need to be more concrete than that. What is the \"big merge\ncase\"? If there are any unmerged paths?\n\nWhat exactly should be cut out, and how can it be configured? Should you\nhave \"status.unmerged\" to cut out certain things? Which things (of\nstaged, unstaged, and untracked)? Or should it go the other way, with a\nstatus.showStaged variable which can be set to \"always\", \"never\", or\n\"unmerged\" (and probably adding an \"unmerged\" option to\n\"status.showUntrackedFiles).\n\n-Peff\n"},{"id":"122509","messageId":"20090905090808.GB13221@coredump.intra.peff.net","threadId":"20810","inReplyTo":"20090905084809.GA13073@coredump.intra.peff.net","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Jeff King","fromEmail":"peff@peff.net","sentAt":"2009-09-05T09:08:08Z","receivedAt":"2009-09-05T09:08:08Z","isPatch":true,"sender":{"key":"peff@peff.net","avatar":"https://avatars.githubusercontent.com/u/45925?v=4"},"body":"On Sat, Sep 05, 2009 at 04:48:09AM -0400, Jeff King wrote:\n\n> On Sat, Sep 05, 2009 at 02:28:46AM -0400, Jeff King wrote:\n> \n> > I see. I still think you may want to improve \"commit --dry-run\" with a\n> > plumbing format, though, instead of \"git status\". Then it would\n> > automagically support \"--amend\", as well as other dry-run things (e.g.,\n> > \"git commit --dry-run --porcelain --amend foo.c\"). And not having looked\n> > at the code, I would guess it is a one-liner patch to switch the \"output\n> > format\" flag that commit passes to the wt-status.c code.\n> \n> OK, it was a bit more complex than that. But here is a series which does\n> a few things. It is still missing a few bits, so is RFC.\n\nBTW, in case it was not obvious from the context, these are built on top\nof jc/1.7.0-status.\n\n-Peff\n"},{"id":"122511","messageId":"20090905113937.GA13390@opensource.wolfsonmicro.com","threadId":"20810","inReplyTo":"20090905090422.GA13221@coredump.intra.peff.net","subject":"Re: [PATCH v2] status: list unmerged files last","fromName":"Mark Brown","fromEmail":"broonie@opensource.wolfsonmicro.com","sentAt":"2009-09-05T11:39:37Z","receivedAt":"2009-09-05T11:39:37Z","isPatch":true,"sender":{"key":"broonie@opensource.wolfsonmicro.com","avatar":"https://gravatar.com/avatar/5fb25e4e0de3255caa21123e2b518c314d26245069221ff55910d5c6ba3343c4?d=mp&s=160"},"body":"On Sat, Sep 05, 2009 at 05:04:22AM -0400, Jeff King wrote:\n> On Wed, Sep 02, 2009 at 07:39:23PM +0100, Mark Brown wrote:\n\n> > My main wishlist would be to have the same control for the changes to be\n> > committed for the big merge case, the use case being while resolving\n\n> I think we need to be more concrete than that. What is the \"big merge\n> case\"? If there are any unmerged paths?\n\nThe context was that this was done when explictly requested by the user\nso all the time when enabled. In the context I'm thinking of this would\nbe used via the command line more than via the config file.\n\n> What exactly should be cut out, and how can it be configured? Should you\n> have \"status.unmerged\" to cut out certain things? Which things (of\n> staged, unstaged, and untracked)? Or should it go the other way, with a\n> status.showStaged variable which can be set to \"always\", \"never\", or\n> \"unmerged\" (and probably adding an \"unmerged\" option to\n> \"status.showUntrackedFiles).\n\nI'd been thinking of not showing anything in the index but keeping\neverything else. In terms of a configuration variable I'd go with\nspecifying the things not to show rather than the things to show - \nthe noise to cut out.\n"},{"id":"122547","messageId":"7vd464cxcz.fsf@alter.siamese.dyndns.org","threadId":"20810","inReplyTo":"20090905085218.GB13157@coredump.intra.peff.net","subject":"Re: [PATCH/RFC 2/6] docs: note that status configuration affects only long format","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-06T08:04:44Z","receivedAt":"2009-09-06T08:04:44Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> Combined with the --short/--porcelain distinction introduced later in\n> the series, should short perhaps respect status.relativePaths and\n> status.submoduleSummary?\n\nI think that makes sense. \n"},{"id":"122548","messageId":"7v63bwcxcc.fsf@alter.siamese.dyndns.org","threadId":"20810","inReplyTo":"20090905085348.GC13157@coredump.intra.peff.net","subject":"Re: [PATCH/RFC 3/6] status: refactor short-mode printing to its own function","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2009-09-06T08:05:07Z","receivedAt":"2009-09-06T08:05:07Z","isPatch":true,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Jeff King writes:\n\n> I am tempted to move all of the short-printing code to its own file, and\n> move \"cmd_status\" to its own builtin-status.c, as well. I don't know if\n> that is a cleanup that makes sense to others, as well, or if it is too\n> much churn for too little good.\n\nEarlier in the series when \"git commit --dry-run\" and \"git status\" still\nwere the same thing, I checked if the above was feasible and then decided\nagainst it, because they needed to share the option parsing and the index\npreparation, and exporting these functions inherently internal to \"git\ncommit\" only to use them in \"git status\" did not make much sense.\n\nBut once \"git status\" does not have anything to do with \"git commit\", I\nthink such a separation would become much more sensible.\n"}]}