Re: [PATCH] commit: Steer new users toward "git commit -a" rather than update-index

[Junio C Hamano <junkio@cox.net>]

Andy Whitcroft <apw@shadowen.org> writes:

> Are we sure this isn't porcelain-ish?  We need to use it in merge
> conflict correction and the like?  You can't use git-commit there as a
> replacement.  I'd expect it to be 'git update-index' rather than
> 'git-update-index' of course.

I think status should be taken as Porcelain-ish so it should
notice more about the environment to see why the user has
changed but not updated files and recommend the possible action
depending on the context.

For that, you would need to enumerate what kind of 'context'
there could be with the current set of tools.  Here is a
strawman.

 1. None of the below.
 2. A merge was attempted and resulted in a conflict.
 3. An am or rebase without --merge was attempted and
    resulted in a conflict or patch rejection.
 4. A "rebase --merge was attempted and resulted in a conflict.

In the normal case, the next user action would be:

 1-1. The user wants that change in the next commit, and should
      run "git update-index $that_path" to prepare the index for
      partial commit, or "git commit -a" to commit all the
      changes made to the working tree so far.  Carl's patch
      helps the user in this case.

 1-2. The user realizes that the some of the changes in the
      working tree were not desirable, and "git checkout --
      $that_path" to revert them before continuing.  Before
      deciding to revert, the user may want to check what the
      difference is by running "git diff -- $that_path" so
      suggesting these two might also be helpful.

 1-3. The user wants to keep that change a strictly local change
      in the working tree (this is often very useful and making
      "commit -a" the default will not be acceptable unless
      there is a very compelling reason to do so).  This means
      the suggestion we would make should clearly be
      _suggestion_.

The earlier wording was bad in that it suggested to use a
Plumbing command update-index, but was attempting to convey that
it was merely a conditional suggestion by saying "use it TO MARK
FOR COMMIT", implying that if the user does not want to mark
them for commit, it is Ok not to use update-index.

When a merge is in progress, we would have .git/MERGE_HEAD and
that would be the way to tell case 2.  In that case, the next
user action would be:

 2-1. The user resolves conflicts and marks them as resolved,
      with update-index (or "git mark-resolved"), to prepare the
      index for the merge commit.  But this is not done for
      "Changed but not updated" files but "unmerged" files.  We
      should strongly suggest not to do _anything_ to "Changed
      but not updated" files here.

 2-2. The user decides this conflict is too much to handle right
      now, and abandones the change by "git reset --hard".  This
      would lose the local changes ("Changed but not updated"),
      so we should suggest to save the change before doing so.

	If you are going to abandone this merge with "reset
	--hard", your changes to these files will be lost.  You
	can save them with "git diff HEAD -- $this_path
	$that_path..."

      which is probably too long for that part of the output but
      that is what we would want to say if we want to be
      helpful.

When either rebase without --merge or am is in progress, there
would be .dotest/ directory (whose name could be changed but I
think this was a mistake and we would be better off using fixed
names for this kind of application) for git-status to notice.
The next user action would be:

 3-1. The user resolves the conflict or manually apply the
      patch, update-index the paths involved and proceeds with
      "rebase --continue" or "am --resolved".  "Changed but not
      updated" paths should not be touched in this case,
      similarly to 2-1.

 3-2. The user gives up.  Same as 2-2.

Designing for the "rebase --merge" case and coming up with other
cases are left as exercise to the list for further discussion.