Poor status output during conflicted merge

Poor status output during conflicted merge

[Eric Raible]

Let's create a merge conflict and then partially resolve it:

git init bad-status
cd bad-status/
echo 1 > file
git add file
git commit -a -m1
echo 2 > file
git commit -a -m2
git checkout -b topic HEAD^
echo 3 > file
git commit -a -m3
git merge master
git checkout --ours file
git add file

A 'git status' at this point gives the following output:

# On branch topic
nothing to commit (working directory clean)

Which is wrong, since the merge still needs to be committed.

- Eric

Re: Poor status output during conflicted merge

[Junio C Hamano]

Eric Raible <raible@gmail.com> writes:

> A 'git status' at this point gives the following output:
>
> # On branch topic
> nothing to commit (working directory clean)
>
> Which is wrong, since the merge still needs to be committed.

It might be just a simple matter of ...

 wt-status.c |    2 ++
 1 files changed, 2 insertions(+), 0 deletions(-)

diff --git a/wt-status.c b/wt-status.c
index 2f9e33c..757536f 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -674,6 +674,8 @@ void wt_status_print(struct wt_status *s)
 			fprintf(s->fp, "# No changes\n");
 		else if (s->nowarn)
 			; /* nothing */
+		else if (s->in_merge)
+			printf("merge result will be the same as HEAD commit\n");
 		else if (s->workdir_dirty)
 			printf("no changes added to commit%s\n",
 				advice_status_hints

Re: Poor status output during conflicted merge

[Eric Raible]

Junio C Hamano wrote:
> 
> It might be just a simple matter of ...
> 

I don't think it's that simple.  Consider the case of an integrator who
initially picks the wrong branch.  Wouldn't it seem that:
	git checkout --ours file
	git add file
	git status

should result in the same output as:
	git checkout --theirs file
	git add file
	git status
	# oops
	git checkout --ours file
	git add file
	git status

I can accept an answer is "no".  After all, 'git add' says
that you are happy.  But it makes me wonder whether the empty
"if (s->in_merge)" clause in wt_status_print_cached_header()
wouldn't be the right place to handle this case.

Aside from that, wouldn't the message "merge result will be the
same as HEAD commit" be incorrect if that there are other files
which were already merged successfully?

Re: Poor status output during conflicted merge

[Eric Raible]

On Thu, Jul 1, 2010 at 5:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
> It might be just a simple matter of ...
>
>  wt-status.c |    2 ++
>  1 files changed, 2 insertions(+), 0 deletions(-)
>
> diff --git a/wt-status.c b/wt-status.c
> index 2f9e33c..757536f 100644
> --- a/wt-status.c
> +++ b/wt-status.c
> @@ -674,6 +674,8 @@ void wt_status_print(struct wt_status *s)
>                        fprintf(s->fp, "# No changes\n");
>                else if (s->nowarn)
>                        ; /* nothing */
> +               else if (s->in_merge)
> +                       printf("merge result will be the same as HEAD commit\n");
>                else if (s->workdir_dirty)
>                        printf("no changes added to commit%s\n",
>                                advice_status_hints

I suppose that's better than nothing, but I can't help but think that
the output would  be more useful if it explicitly mentioned the merge.

Most sensible people probably already have that in their bash prompt,
of course, but we have some users at $dayjob who use the anemic
windows cmd.exe as their "command shell".

So how about something like this:

$ git status
# Merging branch 'master' into topic
# Changes to be committed:
#
#       modified:   file2

The "branch 'master' into topic" part can come
from .git/MERGE_MSG

Re: Poor status output during conflicted merge

[Elijah Newren]

On Tue, Jul 6, 2010 at 6:12 PM, Eric Raible <raible@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 5:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> It might be just a simple matter of ...
>>
>>  wt-status.c |    2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/wt-status.c b/wt-status.c
>> index 2f9e33c..757536f 100644
>> --- a/wt-status.c
>> +++ b/wt-status.c
>> @@ -674,6 +674,8 @@ void wt_status_print(struct wt_status *s)
>>                        fprintf(s->fp, "# No changes\n");
>>                else if (s->nowarn)
>>                        ; /* nothing */
>> +               else if (s->in_merge)
>> +                       printf("merge result will be the same as HEAD commit\n");
>>                else if (s->workdir_dirty)
>>                        printf("no changes added to commit%s\n",
>>                                advice_status_hints
>
> I suppose that's better than nothing, but I can't help but think that
> the output would  be more useful if it explicitly mentioned the merge.
>
> Most sensible people probably already have that in their bash prompt,
> of course, but we have some users at $dayjob who use the anemic
> windows cmd.exe as their "command shell".
>
> So how about something like this:
>
> $ git status
> # Merging branch 'master' into topic
> # Changes to be committed:
> #
> #       modified:   file2
>
> The "branch 'master' into topic" part can come
> from .git/MERGE_MSG

At my $dayjob, when we switched from cvs to git, I got _lots_ of
support questions around people being confused with merges and rebases
-- they often didn't realize they were still in the middle of one, or
didn't know how to resolve conflicts, or didn't know how to complete
the operation (i.e. didn't know that they needed to "commit" or
"rebase --continue"), or didn't know how to abort the operation.  This
despite a few hours of dedicated training on basic git usage for
everyone including some nice handouts.  [Granted, most developers were
engineers that were more interested in engineering and physics than
"computer science stuff", didn't have a very strong grasp of version
control, plus they had years of brain damage from CVS usage to cope
with, so this user group may be uncommon -- at least other than the
CVS usage bit.]  Fixing the bash prompt would help in reminding people
that they were in the middle of an operation, but not the other
issues.  And most people were stubbornly sticking with tcsh as their
shell, preventing even using that solution.

Most such users were using EasyGit (lightweight git-like wrapper
designed to assist in avoiding common gotchas for those braindamaged
by CVS or SVN), so I quickly modified "eg status" to also print
annoying "YOU ARE IN THE MIDDLE OF A <OP> OPERATION.  TYPE 'eg help
topic middle-of-<OP> FOR MORE INFO" notices when relevant[1].

After making that change, support questions dropped _dramatically_.

I'm a bit ashamed I never got around to making that into a proper RFC
patch for git (yet?).  I'm not sure whether it'd fit git, but it's
certainly worth discussion and was amazing how much it helped us.

Elijah

[1] See http://people.gnome.org/~newren/eg/documentation/topic-middle-of-merge.html
and http://people.gnome.org/~newren/eg/documentation/topic-middle-of-rebase.html
for what the help pages suggested; there are similar ones for am and
bisect as well.

Re: Poor status output during conflicted merge

[demerphq]

On 7 July 2010 02:12, Eric Raible <raible@gmail.com> wrote:
> On Thu, Jul 1, 2010 at 5:00 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> It might be just a simple matter of ...
>>
>>  wt-status.c |    2 ++
>>  1 files changed, 2 insertions(+), 0 deletions(-)
>>
>> diff --git a/wt-status.c b/wt-status.c
>> index 2f9e33c..757536f 100644
>> --- a/wt-status.c
>> +++ b/wt-status.c
>> @@ -674,6 +674,8 @@ void wt_status_print(struct wt_status *s)
>>                        fprintf(s->fp, "# No changes\n");
>>                else if (s->nowarn)
>>                        ; /* nothing */
>> +               else if (s->in_merge)
>> +                       printf("merge result will be the same as HEAD commit\n");
>>                else if (s->workdir_dirty)
>>                        printf("no changes added to commit%s\n",
>>                                advice_status_hints
>
> I suppose that's better than nothing, but I can't help but think that
> the output would  be more useful if it explicitly mentioned the merge.
>
> Most sensible people probably already have that in their bash prompt,
> of course, but we have some users at $dayjob who use the anemic
> windows cmd.exe as their "command shell".
>
> So how about something like this:
>
> $ git status
> # Merging branch 'master' into topic
> # Changes to be committed:
> #
> #       modified:   file2
>
> The "branch 'master' into topic" part can come
> from .git/MERGE_MSG

+1


-- 
perl -Mre=debug -e "/just|another|perl|hacker/"