Johannes Schindelin wrote: > 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@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html