In article <4B69D897.2060908@xxxxxxxxxxxx>, Pete Harlan <pgit@xxxxxxxxxxxx> wrote: > On 02/03/2010 10:48 AM, Avery Pennarun wrote: > >> [ron@mickey:~/devel/gittest]$ git mv file2 file3 > >> [ron@mickey:~/devel/gittest]$ git commit -m 'letters->numbers' > >> [master ae3f6d4] letters->numbers > >> 1 files changed, 0 insertions(+), 0 deletions(-) > >> rename file2 => file3 (100%) > > > > Whoops. You didn't 'git add file2' (before the mv) or 'git add file3' > > (after the mv), or use commit -a, so what you've committed is the > > *old* content of file2 under the name file3. The *new* content of > > file2 is still uncommitted in your work tree under the name file3. > > It may be reasonable for "git mv foo bar" to print a helpful message to > the user if foo has un-checked-in changes, similarly to what "git rm" does. > > Unlike "git rm", "git mv" could still perform the operation even without > "-f", but the semantics of "git mv" differ enough from plain "mv" that a > short blurb from Git in that case might help. I think that a simple tweak to the docs would be enough. Right now it says: "The index is updated after successful completion, but the change must still be committed." I'm pretty sure I would have been less confused if it had said something like: "The index is updated to reflect the new name of the file, but NOT any new content that file may contain. Changed content must be added to the index separately with git add, and all changes must still be commited." rg -- 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