4 ms·

It helps to NOT think of a branch as a commit node, nor a chain of commits ending in that node. A branch is a separate concept, it's not even stored in the his

It helps to NOT think of a branch as a commit node, nor a chain of commits ending in that node. A branch is a separate concept, it's not even stored in the history DB but in a different dir. See it as a label attached to a commit, since a commit can have several branches attached to it, or none. A branch will be moved across the history, while a commit will keep his place in the history. A branch is designed to be easily created, deleted, and moved around, freely, from anywhere to anywhere. A commit is designed to feel immutable, and unmovable, and although this is not strictly true, this is how you will mostly use it. A chain of commits is like a rail track, it goes in one direction, each commit composing it never changing (again, conceptually), and never moving. You stack commits, you grow the track, piece by piece. The branch is more like a flag you put somewhere on the rail track (most often at the end), to let the workers know where to put the next piece. Picturing it that way let you best use its properties: - branches cost nothing. They are very lightweight, unlike in SVN, you should create as many as you want. - moving to a branch is cheap. Apart from moving the files to the working copy, it's just a matter of changing point of view on the history. Switch to branches often, it's fast. - you can put a branch anywhere you want. You like an old commit and wanna try something new from it? Plant your flag here and start working. - deleted a branch by mistake ? No worry, it's just a label. You can recreate it in a blink. - this branch is so good it should be master? Sure you can. Just swap the labels. But let everyone knows :) Etc.

thaumasiotes 7y ago
> branches cost nothing. They are very lightweight, unlike in SVN, you should create as many as you want. Ahhhh. So the distinction matters if you bring in a bad assumption from SVN. It had never occurred to me that a labeled branch would be noticeably more expensive than the weight of the commits making up the branch. > you can put a branch anywhere you want. You like an old commit and wanna try something new from it? Plant your flag here and start working. Well... yeah. That's how you create branches. You go to the commit you want to branch from, and you run `git branch`. The fact that you can do this is immediately implied by the way you have to do it. I don't understand how someone could believe something different. > deleted a branch by mistake ? No worry, it's just a label. You can recreate it in a blink. This one's a little weirder; if you delete a branch, you _can_ recreate it, but it's only blink-of-an-eye easy to do if there's another branch containing the head of the old branch. Otherwise you're mucking around in the internal data. > this branch is so good it should be master? Sure you can. Just swap the labels. This is another one where I don't see how you would believe something different. Even if branches were huge, heavyweight objects, they have names, and changing the name of something is generally not so hard to do. There's a command solely for the purpose of renaming branches. (`git branch -m`) > moving to a branch is cheap. Apart from moving the files to the working copy, it's just a matter of changing point of view on the history. Switch to branches often, it's fast. And in my mental model, a checkout is indeed a (potentially mass) update to file contents (and, if applicable, file existence). Saying "apart from moving the files to the working copy" sounds -- to my ears -- kind of like the chestnut that "controlled for height, taller men earn no more than short men do". Setting up the working copy is the thing I'm looking to accomplish in a checkout. I can imagine two types of people who want git training: - Never used version control. - Used subversion heavily; trying to update to the new new thing. In your opinion, how many of these points are "git gotchas" that the first group need to be trained in, and how many are "subversion gotchas" that only really come up for the second group?
- steveklabnik 7y ago
  > This one's a little weirder; if you delete a branch, you _can_ recreate it, but it's only blink-of-an-eye easy to do if there's another branch containing the head of the old branch. Otherwise you're mucking around in the internal data. git reflog is very useful for this. Also, when you delete a branch, git helpfully prints Deleted branch foo (was da2bb5d) so you already have that information, right there.
  - BiteCode_dev 7y ago
    Was going to say that. reflog should be in every tutorials. When I started using git, I checked out back in time, then git logged and was baffled to not see my most recent commits in the listing. I panicked, though I lost my work. Git terrible UI didn't help there: who though it was a good idea to just hide everything with no hint of how to get back at it? Of course, I could have just git checkout master to get back where at was, I just didn't know it. But that's the point of reflog: if you are not sure what you did or where you are, it's always there for you, it has your back.
- BiteCode_dev 7y ago
  > In your opinion, how many of these points are "git gotchas" that the first group need to be trained in, and how many are "subversion gotchas" that only really come up for the second group? Many years ago, SVN users coming to git were indeed a huge source of head scratching. Not anymore. Now we just have a lot of people that just don't think in a way that will lead them to say "So, there's an isomorphism between (1) a commit node; and (2) the chain(s) of commits ending in that node.". In fact, they don't know what isomorphism means, nor that the word exists. Personally, I like to picture git as applied graph theory. One command = a bunch of operations on the graph. But there is an old git joke that says: "Git gets easier once you understand branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space". It is nonsensical (it's a meta reference to a Monad joke), but I think it gets the point perfectly: we need to bring git to the people that needs it, not to ask the people to come to git. I don't care what level of abstraction they are comfortable with, I want them to feel like they can trust their ability to be productive with the tool and feel their project is safe. And I find that this way of explaining branches is the most universal way for people from all sorts of background to have a decent model of how git works under the hood. So that when fall in a trap, they can use this model and find a pragmatic way out by themself. Being right used to be my objective when I was younger. Now I just want to be helpful.

thaumasiotes 7y ago

> branches cost nothing. They are very lightweight, unlike in SVN, you should create as many as you want. Ahhhh. So the distinction matters if you bring in a bad assumption from SVN. It had never occurred to me that a labeled branch would be noticeably more expensive than the weight of the commits making up the branch. > you can put a branch anywhere you want. You like an old commit and wanna try something new from it? Plant your flag here and start working. Well... yeah. That's how you create branches. You go to the commit you want to branch from, and you run `git branch`. The fact that you can do this is immediately implied by the way you have to do it. I don't understand how someone could believe something different. > deleted a branch by mistake ? No worry, it's just a label. You can recreate it in a blink. This one's a little weirder; if you delete a branch, you _can_ recreate it, but it's only blink-of-an-eye easy to do if there's another branch containing the head of the old branch. Otherwise you're mucking around in the internal data. > this branch is so good it should be master? Sure you can. Just swap the labels. This is another one where I don't see how you would believe something different. Even if branches were huge, heavyweight objects, they have names, and changing the name of something is generally not so hard to do. There's a command solely for the purpose of renaming branches. (`git branch -m`) > moving to a branch is cheap. Apart from moving the files to the working copy, it's just a matter of changing point of view on the history. Switch to branches often, it's fast. And in my mental model, a checkout is indeed a (potentially mass) update to file contents (and, if applicable, file existence). Saying "apart from moving the files to the working copy" sounds -- to my ears -- kind of like the chestnut that "controlled for height, taller men earn no more than short men do". Setting up the working copy is the thing I'm looking to accomplish in a checkout. I can imagine two types of people who want git training: - Never used version control. - Used subversion heavily; trying to update to the new new thing. In your opinion, how many of these points are "git gotchas" that the first group need to be trained in, and how many are "subversion gotchas" that only really come up for the second group?

steveklabnik 7y ago
> This one's a little weirder; if you delete a branch, you _can_ recreate it, but it's only blink-of-an-eye easy to do if there's another branch containing the head of the old branch. Otherwise you're mucking around in the internal data. git reflog is very useful for this. Also, when you delete a branch, git helpfully prints Deleted branch foo (was da2bb5d) so you already have that information, right there.
- BiteCode_dev 7y ago
  Was going to say that. reflog should be in every tutorials. When I started using git, I checked out back in time, then git logged and was baffled to not see my most recent commits in the listing. I panicked, though I lost my work. Git terrible UI didn't help there: who though it was a good idea to just hide everything with no hint of how to get back at it? Of course, I could have just git checkout master to get back where at was, I just didn't know it. But that's the point of reflog: if you are not sure what you did or where you are, it's always there for you, it has your back.
BiteCode_dev 7y ago
> In your opinion, how many of these points are "git gotchas" that the first group need to be trained in, and how many are "subversion gotchas" that only really come up for the second group? Many years ago, SVN users coming to git were indeed a huge source of head scratching. Not anymore. Now we just have a lot of people that just don't think in a way that will lead them to say "So, there's an isomorphism between (1) a commit node; and (2) the chain(s) of commits ending in that node.". In fact, they don't know what isomorphism means, nor that the word exists. Personally, I like to picture git as applied graph theory. One command = a bunch of operations on the graph. But there is an old git joke that says: "Git gets easier once you understand branches are homeomorphic endofunctors mapping submanifolds of a Hilbert space". It is nonsensical (it's a meta reference to a Monad joke), but I think it gets the point perfectly: we need to bring git to the people that needs it, not to ask the people to come to git. I don't care what level of abstraction they are comfortable with, I want them to feel like they can trust their ability to be productive with the tool and feel their project is safe. And I find that this way of explaining branches is the most universal way for people from all sorts of background to have a decent model of how git works under the hood. So that when fall in a trap, they can use this model and find a pragmatic way out by themself. Being right used to be my objective when I was younger. Now I just want to be helpful.