Andy Whitcroft <apw@xxxxxxxxxxxx> 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.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html