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