3 ms·

I sometimes use git this way on local files: git init # make a local repo git add foo.txt # add the file [edit

I sometimes use git this way on local files: git init # make a local repo git add foo.txt # add the file [edit] git add -u # add changes to commit git commit -m"made a change" # check in changes git log # see commits git status # what has changed That's really all you need to know.

kstrauser 12y ago
You beat me to it. RCS can't scale up like Git, but Git scales down very nicely. Instead of learning two VCSes, you can reuse the same one you probably already use for everything else. Sure, Git isn't the last word in VCS. There's lots of room for innovation in the space. Still, I don't see anything in the docs (at http://www.catb.org/~esr/src/src.html http://www.catb.org/~esr/src/src.html) that Git can't do just as well. It seems to be a solution in need of a problem.
Roboprog 12y ago
That's what I do on my "bin" directories (for scripts and such). On the other hand, maybe being able to grab something analogous to a ",v" file and moving the archive for a single file around by itself has some value. Just not enough value for me to bother installing RCS when git is already present :-)
treerock 12y ago
So what benefit do you get from that? i.e. have you ever gotten yourself in a mess and thought, 'thankfully I used git here, otherwise I'd be fecked.'
- cschmidt 12y ago
  Sure, I sometimes try things that don't work, and I can just revert my changes. I'm just used to having everything in source control, so I even like it for one-off stuff that doesn't fit in an existing repo.
kazinator 12y ago
What you need to know is that "git add" has little to do with "foo add" where "foo" is just about any other version control system. Look, you ran "git add" on files that were already added, what? There is this hidden thing called the index that confuses the heck out of everyone. Oh, but it's not always called the index, either: that would be unnecessarily easy. Sometimes it is called "the cache". How to show the difference between the index and HEAD? Why, of course not "git diff --index" but "git diff --cached". (In what way the index acts as a cache is beyond me; a cache is a fast place where you look for something that is also available in some slower place, but things in the index are sometimes only in the index and nowhere else!) Furthermore, things in the index are not "indexed" or "cached". Why, they are "staged". So why don't they call it the stage? (And only that: no synonyms?) (The index behaves like a cache in the following sense: it has transparent "read through". If you do a "git diff", you see the difference between the index and your working copy for any changed file. But if the index doesn't have that file, then it gets out of the way and you see the diff between HEAD and the working copy. This confuses people because the transparent behavior teaches them, most of the tiem, that "git diff" is like "svn diff" when it isn't.) The overloaded meanings of "git reset" are astonishing also. Sometimes it means "make the working tree like what is in HEAD". Sometimes it means "no, don't touch the working tree, but change HEAD to a particular revision". Sometimes it means "don't touch HEAD or the working tree: make the index look like a particular revision". Want interactivity? Sometimes it's --interactive, and sometimes it's --patch. Please, just let me do "git stash --interactive"; don't make me correct that to "--patch".
- cschmidt 12y ago
  You do have some very valid points, and git can be confusing. I wonder if those points are more confusing for someone coming to git from some other VCS than someone using git as their first VCS. My 13 year old son got the idea of Git after seeing a diagram like this: http://git-scm.com/book/en/v2/book/01-introduction/images/areas.png http://git-scm.com/book/en/v2/book/01-introduction/images/ar... So it is confusing, but I think it can be taught for very basic use.
- ngoldbaum 12y ago
  Notably mercurial sidesteps this mess but not exposing the staging area in its UI.
kazinator 12y ago
> git add -u This is a wasteful step; you can commit all your changes with "git commit -a" which adds the modified files to the index, and commits, in one step. The index is a completely pointless idea in git that has no purpose; the next major version of git should factor it out. Git would really improve if it lost the index thing. You're already using distributed version control where you can have a whole swath of commits which are not published to your upstream. That is all the staging area you need; you don't need a staging area before your staging area. There are just too many levels: working copy to index. Index to commit. Commit to upstream repo. Git tries to hide the index from users, but that backfires when awareness of its semantics crops up in corner cases. For instance, quite stupidly, if you try to revert a file from a prior commit with "git reset <sha> <file>", it does it in the index rather than where you expect, namely the working copy (that being left untouched). This is a purposeless complication. Now you have a "git diff" which looks like the change is being added rather than subtracted (because that's actually the delta from the index to the unmodified working copy), and a "git diff --cached" which is exactly its opposite (because it's a delta from HEAD to the index). There has to be a concept of modified state which extends to "this new file is scheduled for addition" or "this file is scheduled for deletion". That's all the "index" you need. Other than that, there should only be the working tree, and whatever is in HEAD. Git has the tools that let you make multiple commits and squash them together into one, so the index is completely redundant from that point of view. Instead of hack file git add file hack file git add file # squash into previous index entry you can easily do hack file git commit file # pretend the index doesn't even exist hack file git commit file and then do an interactive rebase where you squash those commits together. This is actually cleaner because you're not doing "squash as you go" into the staging area, but making actual commits where the changes are tracked and separated. Maybe you will end up not wanting to squash them into a single change! I.e. since commits can be amended, cherry picked and squashed to your heart's content, there is no need for the software to support workflow involving a staging area where you prepare the perfect commit. It is superfluous. The index smells like a left over from some early prototyped version of the software, before the full concept was hammered out, which was then difficult to remove (or it never occurred to anyone).
- ibrahima 12y ago

kstrauser 12y ago

You beat me to it. RCS can't scale up like Git, but Git scales down very nicely. Instead of learning two VCSes, you can reuse the same one you probably already use for everything else. Sure, Git isn't the last word in VCS. There's lots of room for innovation in the space. Still, I don't see anything in the docs (at http://www.catb.org/~esr/src/src.html http://www.catb.org/~esr/src/src.html) that Git can't do just as well. It seems to be a solution in need of a problem.

Roboprog 12y ago

That's what I do on my "bin" directories (for scripts and such). On the other hand, maybe being able to grab something analogous to a ",v" file and moving the archive for a single file around by itself has some value. Just not enough value for me to bother installing RCS when git is already present :-)

treerock 12y ago

So what benefit do you get from that? i.e. have you ever gotten yourself in a mess and thought, 'thankfully I used git here, otherwise I'd be fecked.'

cschmidt 12y ago
Sure, I sometimes try things that don't work, and I can just revert my changes. I'm just used to having everything in source control, so I even like it for one-off stuff that doesn't fit in an existing repo.

kazinator 12y ago

What you need to know is that "git add" has little to do with "foo add" where "foo" is just about any other version control system. Look, you ran "git add" on files that were already added, what? There is this hidden thing called the index that confuses the heck out of everyone. Oh, but it's not always called the index, either: that would be unnecessarily easy. Sometimes it is called "the cache". How to show the difference between the index and HEAD? Why, of course not "git diff --index" but "git diff --cached". (In what way the index acts as a cache is beyond me; a cache is a fast place where you look for something that is also available in some slower place, but things in the index are sometimes only in the index and nowhere else!) Furthermore, things in the index are not "indexed" or "cached". Why, they are "staged". So why don't they call it the stage? (And only that: no synonyms?) (The index behaves like a cache in the following sense: it has transparent "read through". If you do a "git diff", you see the difference between the index and your working copy for any changed file. But if the index doesn't have that file, then it gets out of the way and you see the diff between HEAD and the working copy. This confuses people because the transparent behavior teaches them, most of the tiem, that "git diff" is like "svn diff" when it isn't.) The overloaded meanings of "git reset" are astonishing also. Sometimes it means "make the working tree like what is in HEAD". Sometimes it means "no, don't touch the working tree, but change HEAD to a particular revision". Sometimes it means "don't touch HEAD or the working tree: make the index look like a particular revision". Want interactivity? Sometimes it's --interactive, and sometimes it's --patch. Please, just let me do "git stash --interactive"; don't make me correct that to "--patch".

cschmidt 12y ago
You do have some very valid points, and git can be confusing. I wonder if those points are more confusing for someone coming to git from some other VCS than someone using git as their first VCS. My 13 year old son got the idea of Git after seeing a diagram like this: http://git-scm.com/book/en/v2/book/01-introduction/images/areas.png http://git-scm.com/book/en/v2/book/01-introduction/images/ar... So it is confusing, but I think it can be taught for very basic use.
ngoldbaum 12y ago
Notably mercurial sidesteps this mess but not exposing the staging area in its UI.

kazinator 12y ago

> git add -u This is a wasteful step; you can commit all your changes with "git commit -a" which adds the modified files to the index, and commits, in one step. The index is a completely pointless idea in git that has no purpose; the next major version of git should factor it out. Git would really improve if it lost the index thing. You're already using distributed version control where you can have a whole swath of commits which are not published to your upstream. That is all the staging area you need; you don't need a staging area before your staging area. There are just too many levels: working copy to index. Index to commit. Commit to upstream repo. Git tries to hide the index from users, but that backfires when awareness of its semantics crops up in corner cases. For instance, quite stupidly, if you try to revert a file from a prior commit with "git reset <sha> <file>", it does it in the index rather than where you expect, namely the working copy (that being left untouched). This is a purposeless complication. Now you have a "git diff" which looks like the change is being added rather than subtracted (because that's actually the delta from the index to the unmodified working copy), and a "git diff --cached" which is exactly its opposite (because it's a delta from HEAD to the index). There has to be a concept of modified state which extends to "this new file is scheduled for addition" or "this file is scheduled for deletion". That's all the "index" you need. Other than that, there should only be the working tree, and whatever is in HEAD. Git has the tools that let you make multiple commits and squash them together into one, so the index is completely redundant from that point of view. Instead of hack file git add file hack file git add file # squash into previous index entry you can easily do hack file git commit file # pretend the index doesn't even exist hack file git commit file and then do an interactive rebase where you squash those commits together. This is actually cleaner because you're not doing "squash as you go" into the staging area, but making actual commits where the changes are tracked and separated. Maybe you will end up not wanting to squash them into a single change! I.e. since commits can be amended, cherry picked and squashed to your heart's content, there is no need for the software to support workflow involving a staging area where you prepare the perfect commit. It is superfluous. The index smells like a left over from some early prototyped version of the software, before the full concept was hammered out, which was then difficult to remove (or it never occurred to anyone).

ibrahima 12y ago