On Sun, 6 Jan 2008, Jon Hancock wrote:
>
> So, do I need to use git's mv and rm commands?
Nope.
They are there only to
(a) make people who are used to do "svn mv" not complain
(b) simplify things a little teeny bit, by avoiding having to "git add"
the new file.
So if you do just a rename, you can do either
git mv old-file new-file
git commit
or you can do
mv old-file new-file
git add new-file
git commit -a
and the *result* will be the same (the "git commit -a" is there to
automatically pick up the fact that "old-file" went away: you could have
done it with "git rm old-file" too, or "git add -u" or any number of
other ways that update the index).
> Can't I just rename, add, and remove files using any means I like and
> then just ensure my "index" is staged properly when I do a commit?
Absolutely. And depending on your workflow, that may well be the right
thing to do.
In particular, this all means that it's perfectly fine to make changes to
a git repository using *any* non-git-aware tools, including things like
graphical file managers etc.
> Additionally, is there a simple procedure with git to say: "I want to
> version exactly what is in my working tree. If I removed something or
> added something, just handle it". This is sort of what "git add ."
> does, but "git add" doesn't handling things I removed or moved, correct?
You should be able to do that with either
git add .
git commit -a
or if you don't want to do a commit, you can do a
git add -u
git add .
where the "git add -u" will look at any files git already knows and update
them (which includes removing them if they are gone), and then "git add ."
will add any new files.
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
