14 ms·

I'm teaching Git in University. For all those who think that Git is easy, it's not. It takes a student about 20-30 hours to really understand all usual Git co

by adontz 3y ago

I'm teaching Git in University. For all those who think that Git is easy, it's not. It takes a student about 20-30 hours to really understand all usual Git commands. I'm not talking about something bizarre like ls-remote, but really understand merge, rebase, bisect. Not just syntax, but all the consequences. For instance, why rebasing something already pushed to public often leads to false merge conflicts, how does stash really work, etc.

deleted 3y ago
[deleted]
quadrifoliate 3y ago
I don't think Git is easy at all. But 20 hours seems a worthwhile investment to me for something they will likely use for at least the next decade of any serious work with software? I'm assuming that this doesn't mean literally 20 hours of instruction.
- Certhas 3y ago
  There are a lot of people who could benefit from git (or who are forced to interact with it sporadically) for whom this is a real problem. The problem is also, if you don't use it daily git knowledge decays fast. There is a piece of advise that was making the rounds (unironically) at the research institute where I worked before: "Before you do anything with git, first make a local backup copy."
  - bombcar 3y ago
    That’s the idea behind https://xkcd.com/1597/ https://xkcd.com/1597/ and it’s more true than people will admit.
    - jeltz 3y ago
      Can't agree. While learning git isn't trivial it is still easier than it was learning Subversion and at all places I have worked at a decent share of the devs understood git. If a dev cannot grasp git I would not trust them with any non-trivial code base.
      - Certhas 3y ago
        Nobody claims that git is impossible to use. It clearly isn't or it wouldn't be so successful. But it could demonstrably be better and easier and we are stuck in a local minimum of a good enough solution because of the network effects.
      - bombcar 3y ago
        Many more people use git than just developers. Especially with GitHub in there.
      - redeeman 3y ago
        you mean merging branches? because in all other aspects, subversion is significantly simpler and i would say far better UI. Much of this also comes from not being distributed
    - evandale 3y ago
      It really isn't. git stash is the equivalent to saving your work somewhere else and getting a fresh copy.
      - Certhas 3y ago
        No it's not. The recovery strategy when you've gotten your repo into aess is "wipe, clone, restore local backup, try the git thing again". But even then, what's the benefit of using a strange git command, which means I have to track another bit of state only visible to git, which can easily be misused (by applying the stash to the wrong commit), and anyway doesn't save the actual working directory I care about (untracked files), over simply making a file system copy?
        evandale 3y ago
        The benefit of using a strange git command would be learning what a strange git command does and then it's no longer strange. You'll learn how to create, read, update, and delete that new bit of state in git. Then you won't have to wipe, clean, restore local backup, try the git thing again. You can start saving your work somewhere else, getting a fresh copy, and then try that git thing again when you know how git stash works. What you're proposing is like not learning how an incremental compiler works and suggesting to wipe, clean, restore local backup, try to compile the thing again to fix compile errors every time you have a compile error instead of learning how an incremental compiler works.
- baby 3y ago
  > But 20 hours seems a worthwhile investment to me for something they will likely use for at least the next decade Yet most people just want to use VSCode and don't want to invest 20+ hours learning emacs or vim
  - tuukkah 3y ago
    Interestingly, the features of Emacs, Vim and VSCode are largely orthogonal (on top of any basic text editor). Further, a lot of people advocate using CLI instead of most VSCode features. Waiting for the holy grail, you can still learn from each: * Vim key bindings for text edits * CLI commands for Git * Emacs modes such as Magit and org-mode * VSCode for tight Typescript integration, nice block structure visualisation etc. I hope some editor will combine this all. (I think Emacs will be best placed to achieve this with its extension ecosystem that already includes Magit, org-mode, evil-mode etc.)
    - cassianoleal 3y ago
      VS Code already has extensions for all that.
      - subsection1h 3y ago
        VS Code doesn't have anything comparable to Org mode. The "VS Code Org Mode" extension[1] has maybe 1% or 2% of the features of Org mode for Emacs. Go read Org mode's manual[2] from start to finish (134,062 words) and then direct us to an extension for VS Code that has comparable features (e.g., plain text spreadsheets). [1] https://github.com/vscode-org-mode/vscode-org-mode https://github.com/vscode-org-mode/vscode-org-mode [2] https://orgmode.org/org.html https://orgmode.org/org.html
        cassianoleal 3y ago
        Fair enough! I don't use it so wouldn't know.
        baby 3y ago
- rhaway84773 3y ago
  The problem is that git alternatives which achieve pretty much the same so not take 20 hours to learn. A lot of those 20 hours are spent because git has a poor UX and a poor execution model which almost requires understanding it’s underlying working and data structures to be able to use it effectively. There’s several alternatives where you can be as effective if not more in a fraction of the time. The one that I preferred was mercurial, but unfortunately since GitHub was so successful we are all forced to learn git.
  - vladsanchez 3y ago
    I share your sentiment and opinion. Gitless looks, feels and smells like Mercurial (hg), which is simpler and more effective. It only took everyone 18yrs to realize it (sarcasm).
    - GeorgeTirebiter 3y ago
      What do you mean by 'more effective'?
stavros 3y ago
I've been using git for twenty years and I still don't intuitively know what half the operations do. When my local tree fucks up, it might as well need open heart surgery, because I can fix my repo as much as I can perform that.
digdugdirk 3y ago
Any tips for someone outside the industry wanting to up their hobby programming game? Basically just trying to avoid the Useful_Script_v2-Final-Final-ReallyFinalThisTime.py syndrome, and realizing the value of a dated change history.
- CitrusFruits 3y ago
  I think you can immediately get value out of Git, even if you don't understand almost anything. Also there's a lot less footguns if you're not collaborating with anyone else.
- entropie 3y ago
  You only need to understand {init,commit,diff,status,push} to use git. When something goes wrong you can delete your .git and start new. This obviously not what you want when you have a codebase with collaborateurs somewhere public accessible, but its fine to get used to it.
  - sorenjan 3y ago
    That's only true if you don't want to undo any changes. What's the easiest way to get back the previous version of function foo() in file bar.py if I already made other commits to the same file, and want to keep those? Keeping a "bar copy(2) final working.py" file is not about having a nice looking timeline, it makes it very easy to get back to a working state. All you need is copy and paste, or keep the working function as a comment in bar.py. You can see your working code and know you're not messing with it when you're experimenting with bar.py. I'm not saying that's the best way of doing it, but it's a very common use case that's not usually addressed in git guides, where it's all about pushing commit after commit, maybe branching, maybe pushing to a remote with others, but rarely enough focus on undoing mistakes after some experimenting if you didn't branch first.
    - dolni 3y ago
      > What's the easiest way to get back the previous version of function foo() in file bar.py if I already made other commits to the same file, and want to keep those? You are operating under the assumption that foo() changes in a vacuum. That is an invalid assumption for lots of software changes. Commits are supposed to contain one logical change each. That logical change may or may not cross function boundaries (often it will). Reverting a commit should revert the logical change. That is how you accomplish what you're after in git.
rmccue 3y ago
If you’re including rebasing, then I can believe this (rewriting history is nuanced and complex), but I’m not sure I’d be teaching that straight away. My recommendation is usually only to start using rebase once you’re already very familiar with the rest of git, since it’s almost never necessary to achieve what you want. Also, bisect is definitely not common, and the vast majority of my colleagues wouldn’t know it exists; I’d place it into the look-it-up-if-needed category.
- cassianoleal 3y ago
  > bisect is definitely not common Agree. > I’d place it into the look-it-up-if-needed category. Disagree. Bisect is so useful in so many different scenarios that learning about it and the basics of how to use it is a great way to get people into git. Obviously not right at the beginning of their learning curve but as soon as the basics have been covered satisfactorily.
  - aaomidi 3y ago
    I wish more people would know about bisect mainly because they’d design the toolchains to actually support testing when you’re doing bisect.
- jedberg 3y ago
  > I’d place it into the look-it-up-if-needed category. Knowing how to use git bisect is what elevates a programmer to the next level. Just understanding how it works gives you a new way to reason about bug finding and fixing (or feature development using old and new), and then actually using it can make you a bug fixing master.
  - pydry 3y ago
    It feels like a weird and magical superpower but realistically I find use for it about once every 6 years and even then I'm fairly sure I could have done without it. This was not my impression when I first learned about it. I thought I'd be using it all the time.
hedora 3y ago
The porcelain parts of git are terribly complex (though improving; especially if you just apply the config changes it suggests during normal operation). However, the core data model is simple (it is a content addressable store, where each commit contains pointers, forming a directed graph; the pointers are unforgeable, so the graph is acyclic).
- Certhas 3y ago
  This meme needs to die. That is one tiny component of the data git touches when working with it. There are many sources of interacting states, some internal to git, some not: the local tree of commits remote trees of commits a possible origin relationship between the two branch labels on each local and remote with possible relationships between them the HEAD label stash index/staging area the actual working directory .gitignore A simple question like which files are being tracked is actually a complex result of several different places in the above. Untracking a file is consequently extremely non-obvious.
  - nemetroid 3y ago
    Each commit in Git contains a file tree. So a single commit is what’s needed to answer the question ”what files does this commit track?”, which is the only question about file tracking that makes sense to ask in Git. Describing Git’s behaviour in terms of other version control systems’ semantics (e.g. Subversion or Mercurial) is not necessarily easy, but that’s not what’s being claimed.
    - Certhas 3y ago
      That's incorrect. Git considers files tracked if they are in the last commit or staged. As far as I am aware it considers files untracked if they are not tracked and not ignored (though git clean -x documentation suggests that it considers such files untracked and simply ignores them when listing untracked files, which also makes sense). So un/tracked depends on last commit, staging area and possibly .gitignore. > Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot, as well as any newly staged files; they can be unmodified, modified, or staged. In short, tracked files are files that Git knows about. > Untracked files are everything else — any files in your working directory that were not in your last snapshot and are not in your staging area. https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-...
prakis 3y ago
Git is not easy, some concepts are confusing especially for newbies. I wrote a simple intro on how git works https://git-help.com https://git-help.com
Topgamer7 3y ago
I often ask the difference between a merge and a rebase is in my interview questions. It is exceptional common that they cannot even describe it. I typically use it as a barometer for how in depth the candidate tries to understand underlying mechanisms of tools they use.
- rcme 3y ago
  This is the type of interview question I hate. You’re basically selecting for candidates who care about the same problems you do.
  - heyoni 3y ago
    Exactly. Dig into what they know!
  - rizzaxc 3y ago
    if the interviewee would be a direct report of the interviewer, I dont see the issue
    - rcme 3y ago
      Not an issue per se, but there are plenty of candidates who might not care about merging vs. rebasing but have an interest in other things. So many interviews consist of interviewers hoping you parrot their own worldview back to them. It’s not a good way to build a team.
      - tasuki 3y ago
        I prefer rebasing (for the usual reasons). I have successfully worked with people who prefer merging (for the usual reasons). I don't think I'd work successfully with people who don't care.
        rcme 3y ago
        I don’t care. Why? Because it’s largely a meaningless distinction that has nothing to do with the goal at hand. It’s like eMacs vs. vim or tabs vs. spaces. Another way of thinking about interviewing is this: you say you don’t want to work with people who don’t care about this problem you care about. That’s fine, I guess. But if you changed your viewpoint to “I want to work with candidates who care about interesting things” then you might find you ask more about what they care about and less about what you care about.
MikusR 3y ago
It takes hours to explain to some what variables are.
- redeeman 3y ago
  im gonna go ahead and say, that if it does that, they probably wont be needing something like git
dv_dt 3y ago
I’m not sure it would be much shorter with some other version control program. Merges, rebasing and bisect are fundamental to what version control does.
recursive 3y ago
I've used 20 or 30 git commands over 8 years or so. Many on a daily basis. I haven't gotten around to to rebase yet. It's definitely not essential.
- throwbadubadu 3y ago
  No, definitely not, but if you start using it you can fall in love with it easy and suddenly find merging overly complicated :) I dread the merge workflow my colleagues do in a strange multi-repo-with-subrepos project - I just rebase all branches in all repos and find it even simpler and be happy and can still see my history at least :D
xhainingx 3y ago
When I teach students git I show them init, status, add commit, diff, and log. That's all I focus on for several weeks. That's enough to track changes to your own projects, see the benefit of tracking what you've changed, and build the habit of commiting frequently. IME, adding anything more about remotes and branches is overwhelming to the point they don't bother with git because they aren't going to distinguish the fundamentals from those more complex features. Obviously branches and remotes are vital in real development, you just can't expect them to learn it all from the start.
jayd16 3y ago
I think git is fairly easy as far as data structures and such goes but the issue is that you need to understand it to use it well. In the same way that you don't need to understand the inner workings of Google Docs, Git should be something you don't even have to learn. Sadly we're not there.
kylejrp 3y ago
I really like using The Git Parable to help people understand the motivations behind Git. Remotes and staging seem really weird at first. https://tom.preston-werner.com/2009/05/19/the-git-parable.html https://tom.preston-werner.com/2009/05/19/the-git-parable.ht...
ww520 3y ago
If it takes students with no background in source version control to really understand the usual Git commands in 20-30 hours, that's a huge success.
- adontz 3y ago
  They have background in IT
- yCombLinks 3y ago
  The goal here is to save my files, change things, and get back to my old version if that ended up being a bad idea. That's a simple request. 20 to 30 hours of learning for a big undo is bullshit.
highmastdon 3y ago
Honestly, “easy” is relative. Understanding software engineering is a study of 4 years, so having someone take a course on fit for 20-40 hours is literally half a week of proper studying and you’d know git. I don’t get why there are bootcamps for _only_ JavaScript CSS that take at least 8 weeks of hard work and then half of those to learn git and call it “not easy”. It’s the depth that we want to commit to understanding something that leads to people saying it’s not easy. Invest proper time into it and everyone (in sw eng) can learn git
tgv 3y ago
I don't get it. Why would you spend so much time on git? You can teach the core ideas in 2 hours, let them do some homework (4 hours?), and the rest they can figure out later. I don't see the value of understanding git in detail.
achates 3y ago
The command line is really unintuitive. Like using 'checkout -b' to create a branch but 'branch -D' to delete one.
- adhesive_wombat 3y ago
  > 'checkout -b' to create a branch Well that's actually "create a branch and then checkout that new branch". And you can use "git switch -c" if you feel the "checkout" verb is confusing. The command to just create a branch is "git branch". Git branch won't touch the HEAD pointer, that's what switch does. And if "git branch -c" were the command for "create branch and switch", it would be criticised in the exact same way: creating a branch and switching to it would be a different subcommand to that used for switching existing branches. Except now the branch command can also do "switchy" things to your HEAD pointer, but only sometimes (and the fact that checkout also only sometimes changed the HEAD is why switch was introduced).
  - creamyhorror 3y ago
    What would be nicer is an interactive CLI interface for git. For example: "git switch <branch>", then if the branch doesn't exist, git asks you: "Branch <branch> does not exist; create it? [y/n]" To be fair, I've long used "checkout -b" and I don't think new branches need this, but it might be helpful in special situations like rebase/merge conflicts. I appreciate this sort of interactive CLI in other tools (apt, vite, etc.), versus having to look up the manual for the right options/switches. It's a different approach that might be more annoying to some power users, but is more friendly to most other users. (This is also where GUIs are helpful, since they display most of the useful commands and options for you. Plus they can do things like see line history by commit and list your stashes for super-easy switching; GitLens/GitLess in VSCode do these.)
unmole 3y ago
I taught myself Git in University. Over the course of a decade, I've taught Git to dozens of people. Sure, some people take more time than others but 20-30 hours sounds absolutely wild to me!
Buttons840 3y ago
Since you teach Git, I'm curious if you've tried https://ohmygit.org/ https://ohmygit.org/ , and what your opinion of it is?
jancsika 3y ago
> For instance, why rebasing something already pushed to public often leads to false merge conflicts This sounds like obscurantism. What bad thing happens if students just assume that rebasing something already pushed to public will cause merge conflicts, and just never do that?
whatscooking 3y ago
Pareto principle. 80% of the time all you’re doing is git add, git commit and git push.
kazinator 3y ago
Students have to understand the concepts first, then the commands. Many of the commands don't make sense, and many of them are dumb implementations, which wouldn't be done that way in a clean redesign of git, even if it were based on the same storage model and concepts. Some of the commands are essentially tooling that is external to the Git storage model and emulates delta-based version control on top of the native snapshot model. The commands lead to fundamental misunderstandings such as that commits are changes.
tasuki 3y ago
I've only taught git like two or three people. 20-30 hours is insane. Could it be that starting from the commands is not the best way? Git is basically just blobs, trees, commits, and refs [0]. Four simple concepts. Yes the interface is confusing and I don't know it either, but things are easy enough to look up. [0]: I love "fast intro to git internals": https://docs.google.com/document/u/0/d/1X5SnleaX4qpLCc4QMAMWdvrA5QRsUO-YxXKjhSZRPpY https://docs.google.com/document/u/0/d/1X5SnleaX4qpLCc4QMAMW...
- ShamelessC 3y ago
  You taught people with some sort of existing knowledge or advantage. This is one of those classic pitfalls that comes with experience - we forget how hard things were early on and/or fail to realize when something was “easy” because we had natural talent or passion. It’s probably best to consider that something like git is _not_ inherently interesting and is more likely (subjectively) boring and tedious to humans who are comfortable with simple saving and undoing of files.
- hardware2win 3y ago
  Rofl Git is the only software where the need for learning its internals is recommended It is a sign of huge failure of API design

by adontz 3y ago

deleted 3y ago

[deleted]

quadrifoliate 3y ago

I don't think Git is easy at all. But 20 hours seems a worthwhile investment to me for something they will likely use for at least the next decade of any serious work with software? I'm assuming that this doesn't mean literally 20 hours of instruction.

Certhas 3y ago
There are a lot of people who could benefit from git (or who are forced to interact with it sporadically) for whom this is a real problem. The problem is also, if you don't use it daily git knowledge decays fast. There is a piece of advise that was making the rounds (unironically) at the research institute where I worked before: "Before you do anything with git, first make a local backup copy."
- bombcar 3y ago
  That’s the idea behind https://xkcd.com/1597/ https://xkcd.com/1597/ and it’s more true than people will admit.
  - jeltz 3y ago
    Can't agree. While learning git isn't trivial it is still easier than it was learning Subversion and at all places I have worked at a decent share of the devs understood git. If a dev cannot grasp git I would not trust them with any non-trivial code base.
    - Certhas 3y ago
      Nobody claims that git is impossible to use. It clearly isn't or it wouldn't be so successful. But it could demonstrably be better and easier and we are stuck in a local minimum of a good enough solution because of the network effects.
    - bombcar 3y ago
      Many more people use git than just developers. Especially with GitHub in there.
    - redeeman 3y ago
      you mean merging branches? because in all other aspects, subversion is significantly simpler and i would say far better UI. Much of this also comes from not being distributed
  - evandale 3y ago
    It really isn't. git stash is the equivalent to saving your work somewhere else and getting a fresh copy.
    - Certhas 3y ago
      No it's not. The recovery strategy when you've gotten your repo into aess is "wipe, clone, restore local backup, try the git thing again". But even then, what's the benefit of using a strange git command, which means I have to track another bit of state only visible to git, which can easily be misused (by applying the stash to the wrong commit), and anyway doesn't save the actual working directory I care about (untracked files), over simply making a file system copy?
      - evandale 3y ago
        The benefit of using a strange git command would be learning what a strange git command does and then it's no longer strange. You'll learn how to create, read, update, and delete that new bit of state in git. Then you won't have to wipe, clean, restore local backup, try the git thing again. You can start saving your work somewhere else, getting a fresh copy, and then try that git thing again when you know how git stash works. What you're proposing is like not learning how an incremental compiler works and suggesting to wipe, clean, restore local backup, try to compile the thing again to fix compile errors every time you have a compile error instead of learning how an incremental compiler works.
baby 3y ago
> But 20 hours seems a worthwhile investment to me for something they will likely use for at least the next decade Yet most people just want to use VSCode and don't want to invest 20+ hours learning emacs or vim
- tuukkah 3y ago
  Interestingly, the features of Emacs, Vim and VSCode are largely orthogonal (on top of any basic text editor). Further, a lot of people advocate using CLI instead of most VSCode features. Waiting for the holy grail, you can still learn from each: * Vim key bindings for text edits * CLI commands for Git * Emacs modes such as Magit and org-mode * VSCode for tight Typescript integration, nice block structure visualisation etc. I hope some editor will combine this all. (I think Emacs will be best placed to achieve this with its extension ecosystem that already includes Magit, org-mode, evil-mode etc.)
  - cassianoleal 3y ago
    VS Code already has extensions for all that.
    - subsection1h 3y ago
      VS Code doesn't have anything comparable to Org mode. The "VS Code Org Mode" extension[1] has maybe 1% or 2% of the features of Org mode for Emacs. Go read Org mode's manual[2] from start to finish (134,062 words) and then direct us to an extension for VS Code that has comparable features (e.g., plain text spreadsheets). [1] https://github.com/vscode-org-mode/vscode-org-mode https://github.com/vscode-org-mode/vscode-org-mode [2] https://orgmode.org/org.html https://orgmode.org/org.html
      - cassianoleal 3y ago
        Fair enough! I don't use it so wouldn't know.
      - baby 3y ago
rhaway84773 3y ago
The problem is that git alternatives which achieve pretty much the same so not take 20 hours to learn. A lot of those 20 hours are spent because git has a poor UX and a poor execution model which almost requires understanding it’s underlying working and data structures to be able to use it effectively. There’s several alternatives where you can be as effective if not more in a fraction of the time. The one that I preferred was mercurial, but unfortunately since GitHub was so successful we are all forced to learn git.
- vladsanchez 3y ago
  I share your sentiment and opinion. Gitless looks, feels and smells like Mercurial (hg), which is simpler and more effective. It only took everyone 18yrs to realize it (sarcasm).
  - GeorgeTirebiter 3y ago
    What do you mean by 'more effective'?

stavros 3y ago

I've been using git for twenty years and I still don't intuitively know what half the operations do. When my local tree fucks up, it might as well need open heart surgery, because I can fix my repo as much as I can perform that.

digdugdirk 3y ago

Any tips for someone outside the industry wanting to up their hobby programming game? Basically just trying to avoid the Useful_Script_v2-Final-Final-ReallyFinalThisTime.py syndrome, and realizing the value of a dated change history.

CitrusFruits 3y ago
I think you can immediately get value out of Git, even if you don't understand almost anything. Also there's a lot less footguns if you're not collaborating with anyone else.
entropie 3y ago
You only need to understand {init,commit,diff,status,push} to use git. When something goes wrong you can delete your .git and start new. This obviously not what you want when you have a codebase with collaborateurs somewhere public accessible, but its fine to get used to it.
- sorenjan 3y ago
  That's only true if you don't want to undo any changes. What's the easiest way to get back the previous version of function foo() in file bar.py if I already made other commits to the same file, and want to keep those? Keeping a "bar copy(2) final working.py" file is not about having a nice looking timeline, it makes it very easy to get back to a working state. All you need is copy and paste, or keep the working function as a comment in bar.py. You can see your working code and know you're not messing with it when you're experimenting with bar.py. I'm not saying that's the best way of doing it, but it's a very common use case that's not usually addressed in git guides, where it's all about pushing commit after commit, maybe branching, maybe pushing to a remote with others, but rarely enough focus on undoing mistakes after some experimenting if you didn't branch first.
  - dolni 3y ago
    > What's the easiest way to get back the previous version of function foo() in file bar.py if I already made other commits to the same file, and want to keep those? You are operating under the assumption that foo() changes in a vacuum. That is an invalid assumption for lots of software changes. Commits are supposed to contain one logical change each. That logical change may or may not cross function boundaries (often it will). Reverting a commit should revert the logical change. That is how you accomplish what you're after in git.

rmccue 3y ago

If you’re including rebasing, then I can believe this (rewriting history is nuanced and complex), but I’m not sure I’d be teaching that straight away. My recommendation is usually only to start using rebase once you’re already very familiar with the rest of git, since it’s almost never necessary to achieve what you want. Also, bisect is definitely not common, and the vast majority of my colleagues wouldn’t know it exists; I’d place it into the look-it-up-if-needed category.

cassianoleal 3y ago
> bisect is definitely not common Agree. > I’d place it into the look-it-up-if-needed category. Disagree. Bisect is so useful in so many different scenarios that learning about it and the basics of how to use it is a great way to get people into git. Obviously not right at the beginning of their learning curve but as soon as the basics have been covered satisfactorily.
- aaomidi 3y ago
  I wish more people would know about bisect mainly because they’d design the toolchains to actually support testing when you’re doing bisect.
jedberg 3y ago
> I’d place it into the look-it-up-if-needed category. Knowing how to use git bisect is what elevates a programmer to the next level. Just understanding how it works gives you a new way to reason about bug finding and fixing (or feature development using old and new), and then actually using it can make you a bug fixing master.
- pydry 3y ago
  It feels like a weird and magical superpower but realistically I find use for it about once every 6 years and even then I'm fairly sure I could have done without it. This was not my impression when I first learned about it. I thought I'd be using it all the time.

hedora 3y ago

The porcelain parts of git are terribly complex (though improving; especially if you just apply the config changes it suggests during normal operation). However, the core data model is simple (it is a content addressable store, where each commit contains pointers, forming a directed graph; the pointers are unforgeable, so the graph is acyclic).

Certhas 3y ago
This meme needs to die. That is one tiny component of the data git touches when working with it. There are many sources of interacting states, some internal to git, some not: the local tree of commits remote trees of commits a possible origin relationship between the two branch labels on each local and remote with possible relationships between them the HEAD label stash index/staging area the actual working directory .gitignore A simple question like which files are being tracked is actually a complex result of several different places in the above. Untracking a file is consequently extremely non-obvious.
- nemetroid 3y ago
  Each commit in Git contains a file tree. So a single commit is what’s needed to answer the question ”what files does this commit track?”, which is the only question about file tracking that makes sense to ask in Git. Describing Git’s behaviour in terms of other version control systems’ semantics (e.g. Subversion or Mercurial) is not necessarily easy, but that’s not what’s being claimed.
  - Certhas 3y ago
    That's incorrect. Git considers files tracked if they are in the last commit or staged. As far as I am aware it considers files untracked if they are not tracked and not ignored (though git clean -x documentation suggests that it considers such files untracked and simply ignores them when listing untracked files, which also makes sense). So un/tracked depends on last commit, staging area and possibly .gitignore. > Remember that each file in your working directory can be in one of two states: tracked or untracked. Tracked files are files that were in the last snapshot, as well as any newly staged files; they can be unmodified, modified, or staged. In short, tracked files are files that Git knows about. > Untracked files are everything else — any files in your working directory that were not in your last snapshot and are not in your staging area. https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-...

prakis 3y ago

Git is not easy, some concepts are confusing especially for newbies. I wrote a simple intro on how git works https://git-help.com https://git-help.com

Topgamer7 3y ago

I often ask the difference between a merge and a rebase is in my interview questions. It is exceptional common that they cannot even describe it. I typically use it as a barometer for how in depth the candidate tries to understand underlying mechanisms of tools they use.

rcme 3y ago
This is the type of interview question I hate. You’re basically selecting for candidates who care about the same problems you do.
- heyoni 3y ago
  Exactly. Dig into what they know!
- rizzaxc 3y ago
  if the interviewee would be a direct report of the interviewer, I dont see the issue
  - rcme 3y ago
    Not an issue per se, but there are plenty of candidates who might not care about merging vs. rebasing but have an interest in other things. So many interviews consist of interviewers hoping you parrot their own worldview back to them. It’s not a good way to build a team.
    - tasuki 3y ago
      I prefer rebasing (for the usual reasons). I have successfully worked with people who prefer merging (for the usual reasons). I don't think I'd work successfully with people who don't care.
      - rcme 3y ago
        I don’t care. Why? Because it’s largely a meaningless distinction that has nothing to do with the goal at hand. It’s like eMacs vs. vim or tabs vs. spaces. Another way of thinking about interviewing is this: you say you don’t want to work with people who don’t care about this problem you care about. That’s fine, I guess. But if you changed your viewpoint to “I want to work with candidates who care about interesting things” then you might find you ask more about what they care about and less about what you care about.

MikusR 3y ago

It takes hours to explain to some what variables are.

redeeman 3y ago
im gonna go ahead and say, that if it does that, they probably wont be needing something like git

dv_dt 3y ago

I’m not sure it would be much shorter with some other version control program. Merges, rebasing and bisect are fundamental to what version control does.

recursive 3y ago

I've used 20 or 30 git commands over 8 years or so. Many on a daily basis. I haven't gotten around to to rebase yet. It's definitely not essential.

throwbadubadu 3y ago
No, definitely not, but if you start using it you can fall in love with it easy and suddenly find merging overly complicated :) I dread the merge workflow my colleagues do in a strange multi-repo-with-subrepos project - I just rebase all branches in all repos and find it even simpler and be happy and can still see my history at least :D

xhainingx 3y ago

When I teach students git I show them init, status, add commit, diff, and log. That's all I focus on for several weeks. That's enough to track changes to your own projects, see the benefit of tracking what you've changed, and build the habit of commiting frequently. IME, adding anything more about remotes and branches is overwhelming to the point they don't bother with git because they aren't going to distinguish the fundamentals from those more complex features. Obviously branches and remotes are vital in real development, you just can't expect them to learn it all from the start.

jayd16 3y ago

I think git is fairly easy as far as data structures and such goes but the issue is that you need to understand it to use it well. In the same way that you don't need to understand the inner workings of Google Docs, Git should be something you don't even have to learn. Sadly we're not there.

kylejrp 3y ago

I really like using The Git Parable to help people understand the motivations behind Git. Remotes and staging seem really weird at first. https://tom.preston-werner.com/2009/05/19/the-git-parable.html https://tom.preston-werner.com/2009/05/19/the-git-parable.ht...

ww520 3y ago

If it takes students with no background in source version control to really understand the usual Git commands in 20-30 hours, that's a huge success.

adontz 3y ago
They have background in IT
yCombLinks 3y ago
The goal here is to save my files, change things, and get back to my old version if that ended up being a bad idea. That's a simple request. 20 to 30 hours of learning for a big undo is bullshit.

highmastdon 3y ago

Honestly, “easy” is relative. Understanding software engineering is a study of 4 years, so having someone take a course on fit for 20-40 hours is literally half a week of proper studying and you’d know git. I don’t get why there are bootcamps for _only_ JavaScript CSS that take at least 8 weeks of hard work and then half of those to learn git and call it “not easy”. It’s the depth that we want to commit to understanding something that leads to people saying it’s not easy. Invest proper time into it and everyone (in sw eng) can learn git

tgv 3y ago

I don't get it. Why would you spend so much time on git? You can teach the core ideas in 2 hours, let them do some homework (4 hours?), and the rest they can figure out later. I don't see the value of understanding git in detail.

achates 3y ago

The command line is really unintuitive. Like using 'checkout -b' to create a branch but 'branch -D' to delete one.

adhesive_wombat 3y ago
> 'checkout -b' to create a branch Well that's actually "create a branch and then checkout that new branch". And you can use "git switch -c" if you feel the "checkout" verb is confusing. The command to just create a branch is "git branch". Git branch won't touch the HEAD pointer, that's what switch does. And if "git branch -c" were the command for "create branch and switch", it would be criticised in the exact same way: creating a branch and switching to it would be a different subcommand to that used for switching existing branches. Except now the branch command can also do "switchy" things to your HEAD pointer, but only sometimes (and the fact that checkout also only sometimes changed the HEAD is why switch was introduced).
- creamyhorror 3y ago
  What would be nicer is an interactive CLI interface for git. For example: "git switch <branch>", then if the branch doesn't exist, git asks you: "Branch <branch> does not exist; create it? [y/n]" To be fair, I've long used "checkout -b" and I don't think new branches need this, but it might be helpful in special situations like rebase/merge conflicts. I appreciate this sort of interactive CLI in other tools (apt, vite, etc.), versus having to look up the manual for the right options/switches. It's a different approach that might be more annoying to some power users, but is more friendly to most other users. (This is also where GUIs are helpful, since they display most of the useful commands and options for you. Plus they can do things like see line history by commit and list your stashes for super-easy switching; GitLens/GitLess in VSCode do these.)

unmole 3y ago

I taught myself Git in University. Over the course of a decade, I've taught Git to dozens of people. Sure, some people take more time than others but 20-30 hours sounds absolutely wild to me!

Buttons840 3y ago

Since you teach Git, I'm curious if you've tried https://ohmygit.org/ https://ohmygit.org/ , and what your opinion of it is?

jancsika 3y ago

> For instance, why rebasing something already pushed to public often leads to false merge conflicts This sounds like obscurantism. What bad thing happens if students just assume that rebasing something already pushed to public will cause merge conflicts, and just never do that?

whatscooking 3y ago

Pareto principle. 80% of the time all you’re doing is git add, git commit and git push.

kazinator 3y ago

Students have to understand the concepts first, then the commands. Many of the commands don't make sense, and many of them are dumb implementations, which wouldn't be done that way in a clean redesign of git, even if it were based on the same storage model and concepts. Some of the commands are essentially tooling that is external to the Git storage model and emulates delta-based version control on top of the native snapshot model. The commands lead to fundamental misunderstandings such as that commits are changes.

tasuki 3y ago

I've only taught git like two or three people. 20-30 hours is insane. Could it be that starting from the commands is not the best way? Git is basically just blobs, trees, commits, and refs [0]. Four simple concepts. Yes the interface is confusing and I don't know it either, but things are easy enough to look up. [0]: I love "fast intro to git internals": https://docs.google.com/document/u/0/d/1X5SnleaX4qpLCc4QMAMWdvrA5QRsUO-YxXKjhSZRPpY https://docs.google.com/document/u/0/d/1X5SnleaX4qpLCc4QMAMW...

ShamelessC 3y ago
You taught people with some sort of existing knowledge or advantage. This is one of those classic pitfalls that comes with experience - we forget how hard things were early on and/or fail to realize when something was “easy” because we had natural talent or passion. It’s probably best to consider that something like git is _not_ inherently interesting and is more likely (subjectively) boring and tedious to humans who are comfortable with simple saving and undoing of files.
hardware2win 3y ago
Rofl Git is the only software where the need for learning its internals is recommended It is a sign of huge failure of API design