{"thread":{"id":"24255","subject":"Poor status output during conflicted merge","startedAt":"2010-07-01T18:16:29Z","lastAt":"2010-07-07T12:43:48Z","messageCount":6,"participants":["Eric Raible","Junio C Hamano","Elijah Newren","demerphq"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"144616","messageId":"loom.20100701T195742-266@post.gmane.org","threadId":"24255","inReplyTo":null,"subject":"Poor status output during conflicted merge","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2010-07-01T18:16:29Z","receivedAt":"2010-07-01T18:16:29Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"Let's create a merge conflict and then partially resolve it:\n\ngit init bad-status\ncd bad-status/\necho 1 > file\ngit add file\ngit commit -a -m1\necho 2 > file\ngit commit -a -m2\ngit checkout -b topic HEAD^\necho 3 > file\ngit commit -a -m3\ngit merge master\ngit checkout --ours file\ngit add file\n\nA 'git status' at this point gives the following output:\n\n# On branch topic\nnothing to commit (working directory clean)\n\nWhich is wrong, since the merge still needs to be committed.\n\n- Eric\n"},{"id":"144647","messageId":"7v1vbm3g8j.fsf@alter.siamese.dyndns.org","threadId":"24255","inReplyTo":"loom.20100701T195742-266@post.gmane.org","subject":"Re: Poor status output during conflicted merge","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2010-07-02T00:00:12Z","receivedAt":"2010-07-02T00:00:12Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Eric Raible writes:\n\n> A 'git status' at this point gives the following output:\n>\n> # On branch topic\n> nothing to commit (working directory clean)\n>\n> Which is wrong, since the merge still needs to be committed.\n\nIt might be just a simple matter of ...\n\n wt-status.c | 2 ++\n 1 files changed, 2 insertions(+), 0 deletions(-)\n\ndiff --git a/wt-status.c b/wt-status.c\nindex 2f9e33c..757536f 100644\n--- a/wt-status.c\n+++ b/wt-status.c\n@@ -674,6 +674,8 @@ void wt_status_print(struct wt_status *s)\n \t\t\tfprintf(s->fp, \"# No changes\\n\");\n \t\telse if (s->nowarn)\n \t\t\t; /* nothing */\n+\t\telse if (s->in_merge)\n+\t\t\tprintf(\"merge result will be the same as HEAD commit\\n\");\n \t\telse if (s->workdir_dirty)\n \t\t\tprintf(\"no changes added to commit%s\\n\",\n \t\t\t\tadvice_status_hints\n"},{"id":"144655","messageId":"4C2D4629.1090600@nextest.com","threadId":"24255","inReplyTo":"7v1vbm3g8j.fsf@alter.siamese.dyndns.org","subject":"Re: Poor status output during conflicted merge","fromName":"Eric Raible","fromEmail":"raible@nextest.com","sentAt":"2010-07-02T01:51:37Z","receivedAt":"2010-07-02T01:51:37Z","isPatch":false,"sender":{"key":"raible@nextest.com","avatar":null},"body":"Junio C Hamano wrote:\n> \n> It might be just a simple matter of ...\n> \n\nI don't think it's that simple. Consider the case of an integrator who\ninitially picks the wrong branch. Wouldn't it seem that:\n\tgit checkout --ours file\n\tgit add file\n\tgit status\n\nshould result in the same output as:\n\tgit checkout --theirs file\n\tgit add file\n\tgit status\n\t# oops\n\tgit checkout --ours file\n\tgit add file\n\tgit status\n\nI can accept an answer is \"no\". After all, 'git add' says\nthat you are happy. But it makes me wonder whether the empty\n\"if (s->in_merge)\" clause in wt_status_print_cached_header()\nwouldn't be the right place to handle this case.\n\nAside from that, wouldn't the message \"merge result will be the\nsame as HEAD commit\" be incorrect if that there are other files\nwhich were already merged successfully?\n"},{"id":"144973","messageId":"AANLkTimBQULqlIVLOOpFoOO5Lg7hGrgm7N69qouafFyG@mail.gmail.com","threadId":"24255","inReplyTo":"7v1vbm3g8j.fsf@alter.siamese.dyndns.org","subject":"Re: Poor status output during conflicted merge","fromName":"Eric Raible","fromEmail":"raible@gmail.com","sentAt":"2010-07-07T00:12:54Z","receivedAt":"2010-07-07T00:12:54Z","isPatch":false,"sender":{"key":"raible@gmail.com","avatar":null},"body":"On Thu, Jul 1, 2010 at 5:00 PM, Junio C Hamano wrote:\n> It might be just a simple matter of ...\n>\n>  wt-status.c |    2 ++\n>  1 files changed, 2 insertions(+), 0 deletions(-)\n>\n> diff --git a/wt-status.c b/wt-status.c\n> index 2f9e33c..757536f 100644\n> --- a/wt-status.c\n> +++ b/wt-status.c\n> @@ -674,6 +674,8 @@ void wt_status_print(struct wt_status *s)\n>                        fprintf(s->fp, \"# No changes\\n\");\n>                else if (s->nowarn)\n>                        ; /* nothing */\n> +               else if (s->in_merge)\n> +                       printf(\"merge result will be the same as HEAD commit\\n\");\n>                else if (s->workdir_dirty)\n>                        printf(\"no changes added to commit%s\\n\",\n>                                advice_status_hints\n\nI suppose that's better than nothing, but I can't help but think that\nthe output would be more useful if it explicitly mentioned the merge.\n\nMost sensible people probably already have that in their bash prompt,\nof course, but we have some users at $dayjob who use the anemic\nwindows cmd.exe as their \"command shell\".\n\nSo how about something like this:\n\n$ git status\n# Merging branch 'master' into topic\n# Changes to be committed:\n#\n# modified: file2\n\nThe \"branch 'master' into topic\" part can come\nfrom .git/MERGE_MSG\n"},{"id":"144989","messageId":"AANLkTimWugg7IznbXfVFDZe44Ag6VW-PJPAdDl7rWLY-@mail.gmail.com","threadId":"24255","inReplyTo":"AANLkTimBQULqlIVLOOpFoOO5Lg7hGrgm7N69qouafFyG@mail.gmail.com","subject":"Re: Poor status output during conflicted merge","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2010-07-07T05:07:39Z","receivedAt":"2010-07-07T05:07:39Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"On Tue, Jul 6, 2010 at 6:12 PM, Eric Raible wrote:\n> On Thu, Jul 1, 2010 at 5:00 PM, Junio C Hamano wrote:\n>> It might be just a simple matter of ...\n>>\n>>  wt-status.c |    2 ++\n>>  1 files changed, 2 insertions(+), 0 deletions(-)\n>>\n>> diff --git a/wt-status.c b/wt-status.c\n>> index 2f9e33c..757536f 100644\n>> --- a/wt-status.c\n>> +++ b/wt-status.c\n>> @@ -674,6 +674,8 @@ void wt_status_print(struct wt_status *s)\n>>                        fprintf(s->fp, \"# No changes\\n\");\n>>                else if (s->nowarn)\n>>                        ; /* nothing */\n>> +               else if (s->in_merge)\n>> +                       printf(\"merge result will be the same as HEAD commit\\n\");\n>>                else if (s->workdir_dirty)\n>>                        printf(\"no changes added to commit%s\\n\",\n>>                                advice_status_hints\n>\n> I suppose that's better than nothing, but I can't help but think that\n> the output would  be more useful if it explicitly mentioned the merge.\n>\n> Most sensible people probably already have that in their bash prompt,\n> of course, but we have some users at $dayjob who use the anemic\n> windows cmd.exe as their \"command shell\".\n>\n> So how about something like this:\n>\n> $ git status\n> # Merging branch 'master' into topic\n> # Changes to be committed:\n> #\n> #       modified:   file2\n>\n> The \"branch 'master' into topic\" part can come\n> from .git/MERGE_MSG\n\nAt my $dayjob, when we switched from cvs to git, I got _lots_ of\nsupport questions around people being confused with merges and rebases\n-- they often didn't realize they were still in the middle of one, or\ndidn't know how to resolve conflicts, or didn't know how to complete\nthe operation (i.e. didn't know that they needed to \"commit\" or\n\"rebase --continue\"), or didn't know how to abort the operation. This\ndespite a few hours of dedicated training on basic git usage for\neveryone including some nice handouts. [Granted, most developers were\nengineers that were more interested in engineering and physics than\n\"computer science stuff\", didn't have a very strong grasp of version\ncontrol, plus they had years of brain damage from CVS usage to cope\nwith, so this user group may be uncommon -- at least other than the\nCVS usage bit.] Fixing the bash prompt would help in reminding people\nthat they were in the middle of an operation, but not the other\nissues. And most people were stubbornly sticking with tcsh as their\nshell, preventing even using that solution.\n\nMost such users were using EasyGit (lightweight git-like wrapper\ndesigned to assist in avoiding common gotchas for those braindamaged\nby CVS or SVN), so I quickly modified \"eg status\" to also print\nannoying \"YOU ARE IN THE MIDDLE OF A OPERATION. TYPE 'eg help\ntopic middle-of- FOR MORE INFO\" notices when relevant[1].\n\nAfter making that change, support questions dropped _dramatically_.\n\nI'm a bit ashamed I never got around to making that into a proper RFC\npatch for git (yet?). I'm not sure whether it'd fit git, but it's\ncertainly worth discussion and was amazing how much it helped us.\n\nElijah\n\n[1] See http://people.gnome.org/~newren/eg/documentation/topic-middle-of-merge.html\nand http://people.gnome.org/~newren/eg/documentation/topic-middle-of-rebase.html\nfor what the help pages suggested; there are similar ones for am and\nbisect as well.\n"},{"id":"145019","messageId":"AANLkTinlLQEQuvX5zTmj6ulsnLdyzyuIdZC7fR4am0pC@mail.gmail.com","threadId":"24255","inReplyTo":"AANLkTimBQULqlIVLOOpFoOO5Lg7hGrgm7N69qouafFyG@mail.gmail.com","subject":"Re: Poor status output during conflicted merge","fromName":"demerphq","fromEmail":"demerphq@gmail.com","sentAt":"2010-07-07T12:43:48Z","receivedAt":"2010-07-07T12:43:48Z","isPatch":false,"sender":{"key":"demerphq@gmail.com","avatar":null},"body":"On 7 July 2010 02:12, Eric Raible wrote:\n> On Thu, Jul 1, 2010 at 5:00 PM, Junio C Hamano wrote:\n>> It might be just a simple matter of ...\n>>\n>>  wt-status.c |    2 ++\n>>  1 files changed, 2 insertions(+), 0 deletions(-)\n>>\n>> diff --git a/wt-status.c b/wt-status.c\n>> index 2f9e33c..757536f 100644\n>> --- a/wt-status.c\n>> +++ b/wt-status.c\n>> @@ -674,6 +674,8 @@ void wt_status_print(struct wt_status *s)\n>>                        fprintf(s->fp, \"# No changes\\n\");\n>>                else if (s->nowarn)\n>>                        ; /* nothing */\n>> +               else if (s->in_merge)\n>> +                       printf(\"merge result will be the same as HEAD commit\\n\");\n>>                else if (s->workdir_dirty)\n>>                        printf(\"no changes added to commit%s\\n\",\n>>                                advice_status_hints\n>\n> I suppose that's better than nothing, but I can't help but think that\n> the output would  be more useful if it explicitly mentioned the merge.\n>\n> Most sensible people probably already have that in their bash prompt,\n> of course, but we have some users at $dayjob who use the anemic\n> windows cmd.exe as their \"command shell\".\n>\n> So how about something like this:\n>\n> $ git status\n> # Merging branch 'master' into topic\n> # Changes to be committed:\n> #\n> #       modified:   file2\n>\n> The \"branch 'master' into topic\" part can come\n> from .git/MERGE_MSG\n\n+1\n\n\n-- \nperl -Mre=debug -e \"/just|another|perl|hacker/\"\n"}]}