8 ms·

I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves proble

I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves problem Y" will always break down. Version control systems are an important part of the programmers toolkit and it's worth investing a little time to get the fundamentals right. Sure git is not the friendliest of beasts but what it lacks in interface, it more than makes up in internal consistency and trying to learn it "inside out" is a better long term investment than having a list of ways to solve "git problems".

rtpg 10y ago
I think there's a bit of that in git in particular. The irony is that if you think of git in terms of deltas, with branches just being tags to commits, and "git commit" actually being "git commit + move branch", then a lot of stuff is easier to reason about. Like, if you get the notion of working tree, staging area, commits, and branches on a deep-ish level, things get easier. Things can still be hard, but there's a lot less "does running this cause everything to disappear???" I think it would be possible to make this awesome page even more awesome with a little "annotated version" that gives the details of what you're actually doing.
- dfsegoat 10y ago
  > and "git commit" actually being "git commit + move branch" Can you elaborate on that a little more? I liked where it was going -- because being able to explain how git works to someone coming from SVN has been an ongoing problem for me.
  - _ikke_ 10y ago
    In git, branches are pointers to commits (branches are a specific kind of refs or references). When you commit, git creates a new commit object, links it to the last commit on that branch, and then points that branch to the new commit. This way, you get a chain of commits, each pointing to the previous commit, and and branch references pointing to the last commit of each branch.
  - chaosemer 10y ago
    Simplifying things a bit, git is what you did before you learned about using version control. That's right, it's just the old copy/paste the entire project folder for each revision and give it a name like "Project v1", "Project v2", etc. Branches and tags are then just symlinks to a specific folder. In this world, when you commit, you're doing two things: 1. Creating a new top level folder, e.g. "Project v42". 2. Updating the branch symlink you are on to point to that new folder. I'm actually not simplifying things that much here, the main git addition is that each folder (revision) also has a list of previous folders (revisions) and that the folders (revisions) are not named sequentially, they are named based on a hash of their contents.
vacri 10y ago
Git has enough bells and whistles that a cheat sheet is fine, in my opinion. It's only a problem if you don't understand the commands (the same problem as blind copy-pasting code from the web)
swang 10y ago
it was really hard for me to understand vim until a website explained it as being a set of grammars you can learn. i agree, if you really want to be more productive (and without having to go find some git expert on your team) knowing how each operation works and why its doing what its doing is really beneficial. despite that, its sometimes frustrating due to inconsistencies in the git "grammar" that i sometimes don't understand, like why if you want to apply only one file from git stash you have to use `git checkout` rather than `git stash apply [<stash>] -- <file>`. it makes "sense" but is unintuitive when i'm thinking about using stashed commits.
- InclinedPlane 10y ago
  The absolutely easiest way to learn vim is to just schedule a reminder every ... month? week? to run "vimtutor". Then do that for a few minutes until you get frustrated or want to do something else. It's shocking how fast you'll learn.
  - deleted 10y ago
    [deleted]
  - wonder_er 10y ago
    Thank you for this! I didn't know `vimtutor` existed, and just finished the first full lesson. I've got to work now, but I'll be back. Thank you!
prance 10y ago
I agree that it's worth it learning git properly, but sometimes you're thrown into the deep end and don't have the time to get up to speed the "right way". I think git is complicated enough to warrant some simplified descriptions for the most-required tasks.
- dozzie 10y ago
  > sometimes you're thrown into the deep end and don't have the time to get up to speed the "right way". So you don't have three hours to read the fsckin' manual that describes how git repository is organized? O_o
  - prance 10y ago
    At this point I think we need to define what it means to "learn git properly". The assumption in this discussion is that it is more than learn a few concrete commands for specific tasks in a few minutes. You say 3 hours is sufficient, but is it? For example, something as simple as "Changing the Last Commit" (as in "git commit --amend") is found in chapter 7.6 in the git book which is given as main documentation on git-scm.org. The first 6 chapter mainly deal with introducing the model, architecture and high level workflows. Even if you skip the chapter on github, that's still 5 chapters on mostly theory to read before you get to some often-used tool commands. I would argue that is more than 3 hours for most people if you don't just skim it but try to also understand it. Apart from that, to answer the question: indeed, often I don't have 3 hours for something to be considered "nice to know" as opposed to "absolutely necessary". And if the manual is a "fsckin'" one, I'm unlikely to read it at all.
mcv 10y ago
I think the biggest problem people have with git is that you can't and shouldn't want to change shared history, and yet git provides some tools that suggest that maybe you can. It's better to accept history as it is, and fix the problem with reverts, cherry-picking and new commits. History won't be as pretty or clean, but it will reflect what actually happened, which is what history is, after all. The biggest trick to understanding git is to learn to think in commits rather than file content. If one branch has a commit and the other branch doesn't, merging them will mean that the commit is there. If one branch has the commit while the other branch has the commit and a revert for that commit, merging will mean it will be reverted. Same goes with pushing. If you reset locally to before a commit that you already shared, that commit returns on your next pull. If you revert it, it will stay reverted. The most dangerous thing git can do, is rebasing. Rebase changes history. This is fine if it hasn't been shared yet (you commited a new change and try to push, but remote changes need to be pulled first, so rebasing is fine). Rebasing is not fine if the commit has already been shared, through a different branch or a different remote repository, for example. In that case, you need a merge. As pretty as rebase can make your history, you should really only use it when you understand what it does. If you don't, stick with merge.
- tech2 10y ago
  > but it will reflect what actually happened, which is what history is, after all. Recorded history is not necessarily what actually happened though, often (or always, according to some) it's an interpretation. "History is written by the victors" - Walter Benjamin?
- l0b0 10y ago
  `git rebase -i` by default rebases only back to the first commit you haven't shared (at least that's how I interpret the actual behaviour). This is a great default - it's the simplest way to change history and at the same time powerful without being too dangerous.
  - ZeroGravitas 10y ago
    Ah, interesting. I'd noticed this behaviour but hadn't conciously thought about it. The docs say: All changes made by commits in the current branch but that are not in <upstream> are saved to a temporary area. This is the same set of commits that would be shown by git log <upstream>..HEAD
pauljaworski 10y ago
Knowing Git "inside out" is great, but you can't expect to know/remember every command for every situation from day one or even day one thousand. A list of ways to solve Git problems serves as a refresher and even a tool for gaining more insight into how it works as a whole.
ewjordan 10y ago
"Not the friendliest of beasts" is putting it mildly. Git is basically Linus in a nutshell: abrasive, unforgiving, and behaving like an absolute asshole to any non-expert struggling user. Sure, engineers should probably get to know its quirks and learn to work around them because it's now ubiquitous in the field, but let's not pretend that there's something virtuous about it. This is a piece of truly terrible software with an even worse UX that just happened to win the PR battle against its superior foes, because...Idunno, Linux, I guess?
- rootlocus 10y ago
  > just happened to win the PR battle against its superior foes, because...Idunno, Linux, I guess? I would assume GitHub is to blame for that
- wkd 10y ago
  I'm struggling to see which VCS you deem superior, I'm assuming you are not referring to SVN, Mercurial maybe? The learning curve to git is not great but as far as I know nobody has publicly released an option that's improved enough over git to motivate the cost of switching technology. If it's not working for you the only advice I can give is either learn it until it is actually working for you rather than being in the way or try to find a better workflow.
  - pjc50 10y ago
    SVN is much easier to use for the standard corporate workflow of a group of people making commits to a project which mostly advances monotonically with continuous integration. Edit: also in a Windows environment, svn copes slightly better than git. First project we tried it on had the worst possible environment, a mix of Windows and Linux systems. Line ending nightmares everywhere. It also took a while to work out how to kill (with fast-forward) the spurious "merge commit" you get every time someone does a pull. You don't have that with svn, you just do the merging locally when you update and it doesn't generate a commit.
    - tempodox 10y ago
coldtea 10y ago
>I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves problem Y" will always break dow I disagree. "spell X solves problem Y" is an excellent way to both get started with fixing your Y fast AND for learning a system deeper. I think we better learn by example (such as that) and in practical use over time, as opposed to getting some abstract knowledge of the whole system first, or (god forbid) reading the manual, which noone does.
- Grangar 10y ago
  I disagree. Using Git (or any terminal interaction for that matter) is much like speaking a language. As a metaphor: you might be able to order two beers in German (zwei Bier bitte), but the moment the waitress asks you what brand you want it comes down to guessing. Some coworkers (across all experience levels) use Git this way. It's frustrating how slowly they learn and conversely, how inefficiently they work.
  - coldtea 10y ago
    >Using Git (or any terminal interaction for that matter) is much like speaking a language Which again, we learn best by absorbing bits and pieces piecemeal over time -- that's how toddlers learn their native language, by immersion. Not by getting some "understanding of fundamentals" course first.
pluma 10y ago
I think the reason you're disagreeing is that you're not looking at this from a beginner's point of view. Generally there are (roughly) three approaches depending on where you are in your journey from beginner to expert: As a beginner, you need specific, detailed, step-by-step instructions: First run X, then run Y, finally run Z, if something goes wrong along the way, follow these other steps, if that doesn't work, ask someone for help. Once you've moved beyond being a beginner, you understand how the different steps are connected, so you already know the intermediate steps and just need to be told the task at hand: do an X (e.g. "move these commits onto the other branch"). An expert fully understands all the inner workings and just needs to be told the big picture: this is what I have, that is what I want, make it happen. If you try to instruct experts like beginners, they will be frustrated because it seems so tedious and you're not giving them the information they want: what you're trying to do. If you try to instruct beginners like experts, they will be horribly confused because they don't know how to make any of it happen without you laying out each individual step they need to follow. A case can be made that a beginner should learn each individual operation by heart before moving on to the next one (like kata in martial arts) but this style of learning assumes you're willing to spend a lifetime perfecting a single art. It's unlikely git will stick around that long and for most of its users git is just a tiny (though important) aspect of their work.
- majewsky 10y ago
  "A lifetime" is massively exaggerated. I would argue that I know the majority of intricacies of every git command, and I've spent much less than a lifetime on this (about 2 years in reality, alongside other things, of course). > As a beginner, you need specific, detailed, step-by-step instructions: First run X, then run Y, finally run Z, if something goes wrong along the way, follow these other steps, if that doesn't work, ask someone for help. That's one way to do it, but it's not preferable. I would rather sit the beginner down for at least an hour and go through the basic concepts with them. I've taught Git to a few people (mostly fellow students or colleagues) and I found that they have a much easier time when they are introduced early on to the basic concepts of Git (the commit graph, and branches/tags as pointers into the graph), they have a much easier time grasping relevant tasks like merge and rebase. For specific questions (mostly in these "I screw up" moments), a whiteboard is also really helpful to explain them how the two or three magic commands that I tell them are actually fixing things up.
falsedan 10y ago
> this path of treating git as "spell X solves problem Y" will always break down I agree completely! Anytime you give a list of 'run this command', I think you've actually written a CLI tool in the wrong language (English instead of a programming language). At work, we want to increase dev's confidence with git in the next few months. We're making sure to separate out 'Technical' knowledge (what do steps do I perform to recover a deleted branch) from 'Conceptual' knowledge (why would it be a good/bad idea to delete a branch, how branches are intended to be used, understanding what git thinks a branch is, etc.). The former go into git aliases or CLI swiss army knife tool, the latter into training videos and workshops.

rtpg 10y ago

I think there's a bit of that in git in particular. The irony is that if you think of git in terms of deltas, with branches just being tags to commits, and "git commit" actually being "git commit + move branch", then a lot of stuff is easier to reason about. Like, if you get the notion of working tree, staging area, commits, and branches on a deep-ish level, things get easier. Things can still be hard, but there's a lot less "does running this cause everything to disappear???" I think it would be possible to make this awesome page even more awesome with a little "annotated version" that gives the details of what you're actually doing.

dfsegoat 10y ago
> and "git commit" actually being "git commit + move branch" Can you elaborate on that a little more? I liked where it was going -- because being able to explain how git works to someone coming from SVN has been an ongoing problem for me.
- _ikke_ 10y ago
  In git, branches are pointers to commits (branches are a specific kind of refs or references). When you commit, git creates a new commit object, links it to the last commit on that branch, and then points that branch to the new commit. This way, you get a chain of commits, each pointing to the previous commit, and and branch references pointing to the last commit of each branch.
- chaosemer 10y ago
  Simplifying things a bit, git is what you did before you learned about using version control. That's right, it's just the old copy/paste the entire project folder for each revision and give it a name like "Project v1", "Project v2", etc. Branches and tags are then just symlinks to a specific folder. In this world, when you commit, you're doing two things: 1. Creating a new top level folder, e.g. "Project v42". 2. Updating the branch symlink you are on to point to that new folder. I'm actually not simplifying things that much here, the main git addition is that each folder (revision) also has a list of previous folders (revisions) and that the folders (revisions) are not named sequentially, they are named based on a hash of their contents.

vacri 10y ago

Git has enough bells and whistles that a cheat sheet is fine, in my opinion. It's only a problem if you don't understand the commands (the same problem as blind copy-pasting code from the web)

swang 10y ago

it was really hard for me to understand vim until a website explained it as being a set of grammars you can learn. i agree, if you really want to be more productive (and without having to go find some git expert on your team) knowing how each operation works and why its doing what its doing is really beneficial. despite that, its sometimes frustrating due to inconsistencies in the git "grammar" that i sometimes don't understand, like why if you want to apply only one file from git stash you have to use `git checkout` rather than `git stash apply [<stash>] -- <file>`. it makes "sense" but is unintuitive when i'm thinking about using stashed commits.

InclinedPlane 10y ago
The absolutely easiest way to learn vim is to just schedule a reminder every ... month? week? to run "vimtutor". Then do that for a few minutes until you get frustrated or want to do something else. It's shocking how fast you'll learn.
- deleted 10y ago
  [deleted]
- wonder_er 10y ago
  Thank you for this! I didn't know `vimtutor` existed, and just finished the first full lesson. I've got to work now, but I'll be back. Thank you!

prance 10y ago

I agree that it's worth it learning git properly, but sometimes you're thrown into the deep end and don't have the time to get up to speed the "right way". I think git is complicated enough to warrant some simplified descriptions for the most-required tasks.

dozzie 10y ago
> sometimes you're thrown into the deep end and don't have the time to get up to speed the "right way". So you don't have three hours to read the fsckin' manual that describes how git repository is organized? O_o
- prance 10y ago
  At this point I think we need to define what it means to "learn git properly". The assumption in this discussion is that it is more than learn a few concrete commands for specific tasks in a few minutes. You say 3 hours is sufficient, but is it? For example, something as simple as "Changing the Last Commit" (as in "git commit --amend") is found in chapter 7.6 in the git book which is given as main documentation on git-scm.org. The first 6 chapter mainly deal with introducing the model, architecture and high level workflows. Even if you skip the chapter on github, that's still 5 chapters on mostly theory to read before you get to some often-used tool commands. I would argue that is more than 3 hours for most people if you don't just skim it but try to also understand it. Apart from that, to answer the question: indeed, often I don't have 3 hours for something to be considered "nice to know" as opposed to "absolutely necessary". And if the manual is a "fsckin'" one, I'm unlikely to read it at all.

mcv 10y ago

I think the biggest problem people have with git is that you can't and shouldn't want to change shared history, and yet git provides some tools that suggest that maybe you can. It's better to accept history as it is, and fix the problem with reverts, cherry-picking and new commits. History won't be as pretty or clean, but it will reflect what actually happened, which is what history is, after all. The biggest trick to understanding git is to learn to think in commits rather than file content. If one branch has a commit and the other branch doesn't, merging them will mean that the commit is there. If one branch has the commit while the other branch has the commit and a revert for that commit, merging will mean it will be reverted. Same goes with pushing. If you reset locally to before a commit that you already shared, that commit returns on your next pull. If you revert it, it will stay reverted. The most dangerous thing git can do, is rebasing. Rebase changes history. This is fine if it hasn't been shared yet (you commited a new change and try to push, but remote changes need to be pulled first, so rebasing is fine). Rebasing is not fine if the commit has already been shared, through a different branch or a different remote repository, for example. In that case, you need a merge. As pretty as rebase can make your history, you should really only use it when you understand what it does. If you don't, stick with merge.

tech2 10y ago
> but it will reflect what actually happened, which is what history is, after all. Recorded history is not necessarily what actually happened though, often (or always, according to some) it's an interpretation. "History is written by the victors" - Walter Benjamin?
l0b0 10y ago
`git rebase -i` by default rebases only back to the first commit you haven't shared (at least that's how I interpret the actual behaviour). This is a great default - it's the simplest way to change history and at the same time powerful without being too dangerous.
- ZeroGravitas 10y ago
  Ah, interesting. I'd noticed this behaviour but hadn't conciously thought about it. The docs say: All changes made by commits in the current branch but that are not in <upstream> are saved to a temporary area. This is the same set of commits that would be shown by git log <upstream>..HEAD

pauljaworski 10y ago

Knowing Git "inside out" is great, but you can't expect to know/remember every command for every situation from day one or even day one thousand. A list of ways to solve Git problems serves as a refresher and even a tool for gaining more insight into how it works as a whole.

ewjordan 10y ago

"Not the friendliest of beasts" is putting it mildly. Git is basically Linus in a nutshell: abrasive, unforgiving, and behaving like an absolute asshole to any non-expert struggling user. Sure, engineers should probably get to know its quirks and learn to work around them because it's now ubiquitous in the field, but let's not pretend that there's something virtuous about it. This is a piece of truly terrible software with an even worse UX that just happened to win the PR battle against its superior foes, because...Idunno, Linux, I guess?

rootlocus 10y ago
> just happened to win the PR battle against its superior foes, because...Idunno, Linux, I guess? I would assume GitHub is to blame for that
wkd 10y ago
I'm struggling to see which VCS you deem superior, I'm assuming you are not referring to SVN, Mercurial maybe? The learning curve to git is not great but as far as I know nobody has publicly released an option that's improved enough over git to motivate the cost of switching technology. If it's not working for you the only advice I can give is either learn it until it is actually working for you rather than being in the way or try to find a better workflow.
- pjc50 10y ago
  SVN is much easier to use for the standard corporate workflow of a group of people making commits to a project which mostly advances monotonically with continuous integration. Edit: also in a Windows environment, svn copes slightly better than git. First project we tried it on had the worst possible environment, a mix of Windows and Linux systems. Line ending nightmares everywhere. It also took a while to work out how to kill (with fast-forward) the spurious "merge commit" you get every time someone does a pull. You don't have that with svn, you just do the merging locally when you update and it doesn't generate a commit.
  - tempodox 10y ago

coldtea 10y ago

>I don't know if this post was intended as humour or a way to vent out some frustration but in my experience, this path of treating git as "spell X solves problem Y" will always break dow I disagree. "spell X solves problem Y" is an excellent way to both get started with fixing your Y fast AND for learning a system deeper. I think we better learn by example (such as that) and in practical use over time, as opposed to getting some abstract knowledge of the whole system first, or (god forbid) reading the manual, which noone does.

Grangar 10y ago
I disagree. Using Git (or any terminal interaction for that matter) is much like speaking a language. As a metaphor: you might be able to order two beers in German (zwei Bier bitte), but the moment the waitress asks you what brand you want it comes down to guessing. Some coworkers (across all experience levels) use Git this way. It's frustrating how slowly they learn and conversely, how inefficiently they work.
- coldtea 10y ago
  >Using Git (or any terminal interaction for that matter) is much like speaking a language Which again, we learn best by absorbing bits and pieces piecemeal over time -- that's how toddlers learn their native language, by immersion. Not by getting some "understanding of fundamentals" course first.

pluma 10y ago

I think the reason you're disagreeing is that you're not looking at this from a beginner's point of view. Generally there are (roughly) three approaches depending on where you are in your journey from beginner to expert: As a beginner, you need specific, detailed, step-by-step instructions: First run X, then run Y, finally run Z, if something goes wrong along the way, follow these other steps, if that doesn't work, ask someone for help. Once you've moved beyond being a beginner, you understand how the different steps are connected, so you already know the intermediate steps and just need to be told the task at hand: do an X (e.g. "move these commits onto the other branch"). An expert fully understands all the inner workings and just needs to be told the big picture: this is what I have, that is what I want, make it happen. If you try to instruct experts like beginners, they will be frustrated because it seems so tedious and you're not giving them the information they want: what you're trying to do. If you try to instruct beginners like experts, they will be horribly confused because they don't know how to make any of it happen without you laying out each individual step they need to follow. A case can be made that a beginner should learn each individual operation by heart before moving on to the next one (like kata in martial arts) but this style of learning assumes you're willing to spend a lifetime perfecting a single art. It's unlikely git will stick around that long and for most of its users git is just a tiny (though important) aspect of their work.

majewsky 10y ago
"A lifetime" is massively exaggerated. I would argue that I know the majority of intricacies of every git command, and I've spent much less than a lifetime on this (about 2 years in reality, alongside other things, of course). > As a beginner, you need specific, detailed, step-by-step instructions: First run X, then run Y, finally run Z, if something goes wrong along the way, follow these other steps, if that doesn't work, ask someone for help. That's one way to do it, but it's not preferable. I would rather sit the beginner down for at least an hour and go through the basic concepts with them. I've taught Git to a few people (mostly fellow students or colleagues) and I found that they have a much easier time when they are introduced early on to the basic concepts of Git (the commit graph, and branches/tags as pointers into the graph), they have a much easier time grasping relevant tasks like merge and rebase. For specific questions (mostly in these "I screw up" moments), a whiteboard is also really helpful to explain them how the two or three magic commands that I tell them are actually fixing things up.

falsedan 10y ago

> this path of treating git as "spell X solves problem Y" will always break down I agree completely! Anytime you give a list of 'run this command', I think you've actually written a CLI tool in the wrong language (English instead of a programming language). At work, we want to increase dev's confidence with git in the next few months. We're making sure to separate out 'Technical' knowledge (what do steps do I perform to recover a deleted branch) from 'Conceptual' knowledge (why would it be a good/bad idea to delete a branch, how branches are intended to be used, understanding what git thinks a branch is, etc.). The former go into git aliases or CLI swiss army knife tool, the latter into training videos and workshops.