41–50 of 200 posts
haha, i cant count the times i fucked up and i just copied my files out, rm -rf repo; git clone; copy in :)
The definition of a branch here does not seem useful in any way.
I'm pleased the coming Part II purports to point to `reflog`. For a tool that _looks_ like it's fairly advanced, this is one of my favorites to show juniors, because it works so well as a "get me back to where I was" hack.
> But if I were going to tell everyone just one more thing, it would be: > It is very hard to permanently lose work. Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree [UPDATE: if you do 'git checkout [path]', but that is not an uncommon thing to do.] It is true that it is very hard to lose work that you have committed. But even this is not…
> Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree. Not by default it won't. It can do that, if you explicitly run it with the options to checkout a specific path. But why would you do that if it's not what you want?
Earlier quoted context omitted.
> Unfortunately, this is not quite true. Git checkout will silently and irretrievably clobber all the changes in your working tree. Not by default it won't. It can do that, if you explicitly run it with the options to checkout a specific path. But why would you do that if it's not what you want?
> It can do that, if you explicitly run it with the options to checkout a specific path. Fair point. I've update my comment to clarify. > But why would you do that if it's not what you want? Because sometimes it is what you want. The point is, if you happen to do it when it's not what you want, you're hosed. So it is simply not true that "It is very hard to permanently lose work." It is, in fact, quite easy under cer…
If you just learn the mapping of those concepts to Git's vocabulary, you really don't need to memorize all the commands. In the odd case, you can just look up the docs. Nodes are commits, references are either branches or labels depending on whether they stick to leaf nodes or any other node. Your working tree is the current state of the repo in your filesystem, and staging is how you assemble commits.
I'm not a fan of this mythos around Git's complexity. It is simply a DAG, a bunch of references to nodes in that graph, and a stack of commands that let you make any modification to that system you so desire. If you just learn the mapping of those concepts to Git's vocabulary, you really don't need to memorize all the commands. In the odd case, you can just look up the docs. Nodes are commits, references are either b…
I've seen it leveled against emacs, git, vim, etc. It's kind of sad.
I suspect that "attempts to explain something in an easy (but subtly wrong) way" have fueled it with regards to git.
I think it can be summarized as Linked List in reverse. New entries are always added on head instead of tail. The pointer used to track the growing list is 'branch' pointer. The pointer that is fixed to a specific node is 'tag'. Since we are adding on Head, we can have multiple nodes point to one node.