From: Jon Hancock <hidden> Date: 2016-06-15 22:44:02
Hello list,
I'm fairly new to git and coming from svn and have tasted hg and bzr
along the decision path.
Here's my newbie issue:
In reading Aristotle Pagaltzis's article http://plasmasturm.org/log/
487/ the author stresses that a major difference between git and
something like bzr or svn is that git tracks content and not metadata
(or at least less metadata); meaning is inferred through content and
less through metadata.
The heart of Pagaltzis's argument copied here:
<COPY>
Among the systems I did look into, there are really just two
contenders: git and Mercurial. All the other systems track metadata;
git and hg just track content and infer the metadata.
By tracking metadata I mean that these systems keep a record of what
steps were taken. “This file had its name changed.” “Those
modifications came from that file in that branch.” “This file was
copied from that file.” Tracking content alone means doing none of
that. When you commit, the VCS just records what the tree looks like.
It doesn’t care about how the tree got that way. When you ask it about
two revisions, it looks at the tree beforehand and the tree
afterwards, and figures out what happened inbetween. A file is not a
unit that defines any sort of boundary in this view. The VCS always
looks at entire trees; files have no individual identity separate from
their trees at all.
As a consequence, whether you used VCS tools to manipulate your
working copy or regular command line utilities or applied a patch or
whatever is irrelevant. The resulting history is always the same.
</COPY>
So, do I need to use git's mv and rm commands? 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? 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?
thanks, Jon
From: David Brown <hidden> Date: 2016-06-15 22:44:02
On Sun, Jan 06, 2008 at 03:55:22PM +0800, Jon Hancock wrote:
So, do I need to use git's mv and rm commands? 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?
Yes. You can use either git-rm or 'git-commit -a' to remove files. To
rename, you can use git-mv, or you can rename the file yourself, git-add
the new name, and git-rm the old name.
There is no metadata stored with git-mv and git-rm, they just update the
tree and the index.
Dave
From: Jeff King <hidden> Date: 2016-06-15 22:44:02
On Sun, Jan 06, 2008 at 03:55:22PM +0800, Jon Hancock wrote:
So, do I need to use git's mv and rm commands? 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?
No, you don't need to use those commands. They really are just wrappers
that manipulate the working tree files and the index at the same time.
So instead of "git-mv a b" you can do "mv a b; git rm a; git add b".
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?
"git add ." will add the contents of any modified files to the index, as
well as add any untracked files (which may or may not be what you want).
It will not add removals. Try "git add -u" which updates all files that
git knows about (i.e., modifications and removals). You can also simply
use "git commit -a" which is the moral equivalent of "git add -u ; git
commit".
-Peff
From: Brian Swetland <hidden> Date: 2016-06-15 22:44:02
[Jon Hancock [off-list ref]]
So, do I need to use git's mv and rm commands? 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? 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?
"git add ." only adds new or modified files to the index. You can use
"git add -u ." to update the index to reflect any deleted files.
Brian
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
From: Jeff King <hidden> Date: 2016-06-15 22:44:02
On Sun, Jan 06, 2008 at 11:22:50AM -0800, Linus Torvalds wrote:
quoted
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.
I haven't looked to see if this optimization is in place, but "git mv"
can also avoid having to recompute the sha1 of the file (which in most
cases doesn't matter, but on a large file with a cold cache, can make
the operation seem just as snappy as a regular "mv").
-Peff
From: Jay Soffian <hidden> Date: 2016-06-15 22:44:02
On 1/6/08, Jon Hancock [off-list ref] wrote:
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".
is the helpful hint:
$ git-ls-files -d -m -o -z | xargs -0 git-update-index --add --remove
I've got the following aliases in my .gitconfig:
alias.addremove=!git-ls-files -d -m -o -z -X .git/info/exclude -X
$(git-config core.excludesfile) --exclude-per-directory=.gitignore |
xargs -0 git-update-index --add --remove
alias.ls=!git-ls-files -d -m -o -v -X .git/info/exclude -X
$(git-config core.excludesfile) --exclude-per-directory=.gitignore
(In 1.5.4, you can replace the two -X's and the
--exclude-per-directory with --exclude-standard.)
j.
From: David Brown <hidden> Date: 2016-06-15 22:44:02
On Sun, Jan 06, 2008 at 10:05:34PM -0500, Jay Soffian wrote:
On 1/6/08, Jon Hancock [off-list ref] wrote:
quoted
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".
is the helpful hint:
$ git-ls-files -d -m -o -z | xargs -0 git-update-index --add --remove
As long as your git is new enough to have git-add -u, you should be able to
do:
$ git add .
$ git add -u
and have the index match the working tree (keeping excludes out).
Dave