On Thu, 30 Nov 2006, Nicolas Pitre wrote:
>
> 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.
> 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@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html