Johannes Schindelin wrote:

quoted text
> On Tue, 28 Nov 2006, Nicholas Allen wrote:
> 
>> [Linus wrote...]
>>> 
>>> So the tools are certainly there. "git status" just isn't necessarily the 
>>> best one (or the best that it could be, for that matter)..
>> 
>> I guess I hit a limitation in the output of status as opposed to a
>> limitation in what git can do ;-)
> 
> I think it is something different altogether: you learnt how to use CVS, 
> and you learnt how to use bzr, and you are now biased towards using the 
> same names for the same operations in git.
> 
> I actually use git-status quite often, just before committing, to know 
> what I changed. But I will probable retrain my mind to use "git diff" or 
> even "git diff --stat", because it is more informative.
> 
> As for your scenario: There really should be a "what to do when my merge 
> screwed up?" document.

It would be nice to have git-resolved (or git-resolve) wrapper around
git-update-index similar to git-add, git-mv, git-rm which would mark
file as resolved, without need for git-update-index, git-add and git-rm
even in the case of CONFLICT(rename/rename). Although I'm not sure
if it could work in all cases in the simple form of "git resolved <file>",
e.g. in the case of CONFLICT(add/add).

By the way, I wonder if git can detect the case when the same (or nearly
the same) file was added in two different branches under different
filename...
-- 
Jakub Narebski
Poland
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html