On Thu, 30 Nov 2006, Nicolas Pitre wrote:
quoted text
> 
> Would it make sense for "git add" to do the same as "git update-index" 
> on already tracked files?  Given the explanation above this would make 
> 100% sense to me.

Yeah, I think it would probably make sense. I also think it would make 
sense to rename "update-index" entirely, or at least offer other names for 
it (ie the "git resolved" suggestion).

In short - I agree that it's all just facets of the same thing: telling 
git that some part of the working tree is now in a state ready to be 
committed. Whether it's because we want to "add" content, or just mark it 
as no longer having conflicts, or any other reason.

quoted text
> But right now, doing "git add" on an already tracked file simply does 
> nothing.  This is even worse than erroring out.

Yeah, that's arguably a stupid thing to do ("you already added it, what do 
you want me to do?") but the choice we use is probably the worst of the 
three straightforward possibilities (ignore, update or error).

The _original_ "git add" was literally just this one-liner:

	#!/bin/sh
	git-update-index --add -- "$@"

which actually was better in this respect (it updated the content), but 
that didn't do sub-directories, so this is arguable a bug introduced by 
commit 37539fbd: 

    [PATCH] Improved "git add"

    This fixes everybodys favourite complaint about "git add", namely that it
    doesn't take directories.

which started using 

	git-ls-files --others -z -- "$@"

together with the exclude files to generate the list of files to add. At 
that point, we lost files that already existed (since "--others" specifies 
just files we don't know about).

			Linus
-
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