29 ms·

If it's an introduction to software engineering then I think leaving out software craftsmanship or functional programming, etc is not necessarily a sin. And gi

If it's an introduction to software engineering then I think leaving out software craftsmanship or functional programming, etc is not necessarily a sin. And git (the cli not the versioning approach per se) never made sense to begin with. It is extremely user hostile. So no surprises there.

spraak 7y ago
I have heard often people's view that git is not user friendly, but it's always confused me because that hasn't been my experience compared to any other tool I need to learn. Can anyone explain more this view? Perhaps I'm too accepting and forgiving.
- duxup 7y ago
  As someone who feels they understand git enough to use it... I think it is unfriendly. The terminology is just a beast. I feel like every term / command is a bit of a hieroglyph that means nothing on the surface and then I have to associate with some other thing (possibly more hieroglyphs) and memorize. Few git... isms really tell me / give me a clue what it does. It feels like programming in a foreign language (god bless you folks who do that!) where I just don't have anything to hang on to, just memorize it all.
  - Stratoscope 7y ago
    Try SmartGit. It gives you all the power of the command line and then some. A lot of the 5-10 line git recipes you see online are just a single operation in SmartGit. The reflog is one example. Instead of copying and pasting hashes and checking out each one to see if it had the changes you want, just click the Recyclable Commits box and every commit from the reflog shows up in the normal commit and branch display. Just click one to see its changes, or click two commits to see what is different between them.
    - keithnz 7y ago
      SmartGit is great. It makes Git completely usable to a novice and still useful to powerusers, it also makes it very easy to visualize the state of your repositories. For the most it hides things like staging, however you still need to understand the git "mental model". I think the biggest problem for people new to git is that it solves problems they don't really have yet. They are solo on their own repo.... they don't see the point of branches, they only really ever need to stage/commit/push all their changes to a remote. So they learn the magic command line incantations until the day it goes wrong somehow, or they need to roll back, or need to start collaborating and they have to dig a bit deeper
      - duxup 7y ago
        I think you are correct, although when working as an individual I think branches are handy for working multiple unfinished features or the good old: "Let me try....oh gawd this turned into a mess!"
        Stratoscope 7y ago
        With SmartGit the lesson to start with is simply to commit, commit, commit. Commit every little change. You don't have to worry about adding to the index, you don't have to worry about branches, just type Ctrl+K, type a message, and Ctrl+Enter to commit. Or select from the menus to do the same thing. You can always go back and add a branch onto any commit. Just right click the commit, select "add branch", and give it a name. You can move branches around by dragging them and immediately see what branches are where. And if you really mess up, click Recyclable Commits, and any commit you thought you lost will be there.
    - duxup 7y ago
      I'll give it a try. Do they have a free personal version?
      - Stratoscope 7y ago
        They do! A non-commercial license is free, and have a very liberal interpretation of this: > A purpose is considered non-commercial only if the SOFTWARE is exclusively used to actively work on open-source projects, for learning or teaching on a public academic institution, in the spare time to manage projects where you don't get financial compensation for (hobby usage), by public charitable organizations primarily targeting philanthropy, health research, education or social well-being. https://www.syntevo.com/documents/smartgit-license.html https://www.syntevo.com/documents/smartgit-license.html https://www.syntevo.com/smartgit/ https://www.syntevo.com/smartgit/
- asauce 7y ago
  In my experience the reason why people struggle with git is because git is also their introduction to source control. Students generally get the gist of staging and commiting, but usually braches/merges/rebasing causes a lot of issues. The other thing is that students are also scared to get their hands dirty with git. Some of them don't fully understand source control and therefore they are terrified that if they commit/merge something incorrectly then they will destroy the whole code base.
  - RHSeeger 7y ago
    As someone who went through RCS, CSV, SVN, ClearCase, and some others... no, not really. Git just does a great job of taking things that are simple in every other VC and making them hard to understand. Git is powerful, but it's completely user unfriendly.
    - int0x80 7y ago
      For example?
  - malingo 7y ago
    The key is to not introduce git in the context of a real codebase. The codebase is precious, and git (for a beginner) is a a bunch of confusing, sharp tools. The cost of a misstep is too high. Working with a "throwaway" local repo was crucial when I was learning git. It was just a handful of gibberish text files in a few directories, and I experimented with "what happens when I run this git command?", comparing what actually happened with my expectations of what would happen.
- fogetti 7y ago
  `git merge`, `git rebase`, `git rebase -i`, `git revert`, `git checkout`, `git reset`, `git reset --hard`, `git log`, `git reflog`, `git stash`, `git cherry-pick`, `git add`, `git rm`, `git status`, `git commit`, `git push` and squash, reword, fixup, pick and f@ck knows what else. Who wants to really use all this bullshit just to do versioning? Especially if you are a beginner, this doesn't make any sense (and not even later in many cases) In my experience during the last two decades or so in the industry, there is always a special kind of person in the IT field who takes pride knowing all the nitty-gritty details of the latest shiny versioning tool. Should it be IBM Clearcase or SVN or CVS or Git or Mercurial. Even though that most of these softwares only slightly improve the user experience and only claim to solve the users' problems, so they over promise and under deliver. But there is this special kind of person who takes pride in it. To me this seems like someone who takes pride in knowing all the details of his toaster. Might be impressive, but also completely irrelevant for the 90% of the toaster users.
  - rimliu 7y ago
    You don't need all this to just do versioning.
  - eitland 7y ago
    > Who wants to really use all this bullshit just to do versioning? Nobody. It is a strawman or should be. You can teach everything a beginner need to know about git as an ordinary team member in less than one A4 page and less than half a days work. Of course this means part of what you teach then is when to talk to the git expert on the team but as long as beginners stay away from squash, rebase etc they should be fine. Ok, add another half day about effective diffing and merging too, it is a big topic and useful outside the context of git too (local history etc).
    - BeetleB 7y ago
      >Of course this means part of what you teach then is when to talk to the git expert on the team but as long as beginners stay away from squash, rebase etc they should be fine. The thing is, if you ask 10 git experts what should be taught to a beginner, you'll get 10 different A4 size pages. As an example, when my team (finally) switched to git, the expert on the team made a tutorial on what commands to use, and what to avoid/ignore. Looking at it now, he taught that rebase is almost mandatory and gives problems you're guaranteed to run into if you don't use rebase. Not saying I agree with him, but that is one problem with git - no clear consensus on beginner friendly features.
- jrumbut 7y ago
  I think the unfriendliness is that features are hard to discover and the commands are at a lower level than beginners (and a fair few non-beginners) can tolerate. Additionally, almost everyone uses a pretty straightforward workflow with git, but if you look at the docs it looks very complicated. You aren't trying to git checkout -b you are trying to start a new feature. This is a weird layer to add for someone struggling to control a computer using the keyboard instead of the mouse. The other thing is that the dev community has settled on a small range of simple and effective git workflows, where you only ever need 6ish commands, but check this out from man giteveryday (which man git sends you to if you want a simple answer): satellite$ git clone mothership:frotz frotz (1) satellite$ cd frotz satellite$ git config --get-regexp '^(remote|branch)\.' (2) remote.origin.url mothership:frotz remote.origin.fetch refs/heads/:refs/remotes/origin/ branch.master.remote origin branch.master.merge refs/heads/master satellite$ git config remote.origin.push \ +refs/heads/:refs/remotes/satellite/ (3) satellite$ edit/compile/test/commit I mean it's cool for a power user but a little intimidating for someone who just learned about man pages. Of course if you copy and paste it those (numbers) are going to give some weird errors. Edit: I should mention that despite the critique I appreciate all the incredible work they did in exchange for absolutely nothing from me.
- watwut 7y ago
  Back then, they shown me CVS in maybe 10 minutes. I never needed to Google commands and somehow knew how to use it after. It was easy to remember. Never run into problem I would have to Google to fix. Git takes more and people constantly ask questions or have to have cheat sheets printed.
nickthemagicman 7y ago
The thing that really put git together for me was understanding that each commit id was based on the previous commit id. So you could have two branches with the exact same code committed...and have different commit id's. That explains rebases...you take one branch and put it on top of another branches commits but REWRITE those new commit id's based on the new branches commits. Merges, you keep the same commit ids but smush two branches together. Also, when I do a git reset HEAD~1 and make changes I can force push and understand the my new code is overwriting the last commit. I think that really helped my understanding of git.

spraak 7y ago

I have heard often people's view that git is not user friendly, but it's always confused me because that hasn't been my experience compared to any other tool I need to learn. Can anyone explain more this view? Perhaps I'm too accepting and forgiving.

duxup 7y ago
As someone who feels they understand git enough to use it... I think it is unfriendly. The terminology is just a beast. I feel like every term / command is a bit of a hieroglyph that means nothing on the surface and then I have to associate with some other thing (possibly more hieroglyphs) and memorize. Few git... isms really tell me / give me a clue what it does. It feels like programming in a foreign language (god bless you folks who do that!) where I just don't have anything to hang on to, just memorize it all.
- Stratoscope 7y ago
  Try SmartGit. It gives you all the power of the command line and then some. A lot of the 5-10 line git recipes you see online are just a single operation in SmartGit. The reflog is one example. Instead of copying and pasting hashes and checking out each one to see if it had the changes you want, just click the Recyclable Commits box and every commit from the reflog shows up in the normal commit and branch display. Just click one to see its changes, or click two commits to see what is different between them.
  - keithnz 7y ago
    SmartGit is great. It makes Git completely usable to a novice and still useful to powerusers, it also makes it very easy to visualize the state of your repositories. For the most it hides things like staging, however you still need to understand the git "mental model". I think the biggest problem for people new to git is that it solves problems they don't really have yet. They are solo on their own repo.... they don't see the point of branches, they only really ever need to stage/commit/push all their changes to a remote. So they learn the magic command line incantations until the day it goes wrong somehow, or they need to roll back, or need to start collaborating and they have to dig a bit deeper
    - duxup 7y ago
      I think you are correct, although when working as an individual I think branches are handy for working multiple unfinished features or the good old: "Let me try....oh gawd this turned into a mess!"
      - Stratoscope 7y ago
        With SmartGit the lesson to start with is simply to commit, commit, commit. Commit every little change. You don't have to worry about adding to the index, you don't have to worry about branches, just type Ctrl+K, type a message, and Ctrl+Enter to commit. Or select from the menus to do the same thing. You can always go back and add a branch onto any commit. Just right click the commit, select "add branch", and give it a name. You can move branches around by dragging them and immediately see what branches are where. And if you really mess up, click Recyclable Commits, and any commit you thought you lost will be there.
  - duxup 7y ago
    I'll give it a try. Do they have a free personal version?
    - Stratoscope 7y ago
      They do! A non-commercial license is free, and have a very liberal interpretation of this: > A purpose is considered non-commercial only if the SOFTWARE is exclusively used to actively work on open-source projects, for learning or teaching on a public academic institution, in the spare time to manage projects where you don't get financial compensation for (hobby usage), by public charitable organizations primarily targeting philanthropy, health research, education or social well-being. https://www.syntevo.com/documents/smartgit-license.html https://www.syntevo.com/documents/smartgit-license.html https://www.syntevo.com/smartgit/ https://www.syntevo.com/smartgit/
asauce 7y ago
In my experience the reason why people struggle with git is because git is also their introduction to source control. Students generally get the gist of staging and commiting, but usually braches/merges/rebasing causes a lot of issues. The other thing is that students are also scared to get their hands dirty with git. Some of them don't fully understand source control and therefore they are terrified that if they commit/merge something incorrectly then they will destroy the whole code base.
- RHSeeger 7y ago
  As someone who went through RCS, CSV, SVN, ClearCase, and some others... no, not really. Git just does a great job of taking things that are simple in every other VC and making them hard to understand. Git is powerful, but it's completely user unfriendly.
  - int0x80 7y ago
    For example?
- malingo 7y ago
  The key is to not introduce git in the context of a real codebase. The codebase is precious, and git (for a beginner) is a a bunch of confusing, sharp tools. The cost of a misstep is too high. Working with a "throwaway" local repo was crucial when I was learning git. It was just a handful of gibberish text files in a few directories, and I experimented with "what happens when I run this git command?", comparing what actually happened with my expectations of what would happen.
fogetti 7y ago
`git merge`, `git rebase`, `git rebase -i`, `git revert`, `git checkout`, `git reset`, `git reset --hard`, `git log`, `git reflog`, `git stash`, `git cherry-pick`, `git add`, `git rm`, `git status`, `git commit`, `git push` and squash, reword, fixup, pick and f@ck knows what else. Who wants to really use all this bullshit just to do versioning? Especially if you are a beginner, this doesn't make any sense (and not even later in many cases) In my experience during the last two decades or so in the industry, there is always a special kind of person in the IT field who takes pride knowing all the nitty-gritty details of the latest shiny versioning tool. Should it be IBM Clearcase or SVN or CVS or Git or Mercurial. Even though that most of these softwares only slightly improve the user experience and only claim to solve the users' problems, so they over promise and under deliver. But there is this special kind of person who takes pride in it. To me this seems like someone who takes pride in knowing all the details of his toaster. Might be impressive, but also completely irrelevant for the 90% of the toaster users.
- rimliu 7y ago
  You don't need all this to just do versioning.
- eitland 7y ago
  > Who wants to really use all this bullshit just to do versioning? Nobody. It is a strawman or should be. You can teach everything a beginner need to know about git as an ordinary team member in less than one A4 page and less than half a days work. Of course this means part of what you teach then is when to talk to the git expert on the team but as long as beginners stay away from squash, rebase etc they should be fine. Ok, add another half day about effective diffing and merging too, it is a big topic and useful outside the context of git too (local history etc).
  - BeetleB 7y ago
    >Of course this means part of what you teach then is when to talk to the git expert on the team but as long as beginners stay away from squash, rebase etc they should be fine. The thing is, if you ask 10 git experts what should be taught to a beginner, you'll get 10 different A4 size pages. As an example, when my team (finally) switched to git, the expert on the team made a tutorial on what commands to use, and what to avoid/ignore. Looking at it now, he taught that rebase is almost mandatory and gives problems you're guaranteed to run into if you don't use rebase. Not saying I agree with him, but that is one problem with git - no clear consensus on beginner friendly features.
jrumbut 7y ago
I think the unfriendliness is that features are hard to discover and the commands are at a lower level than beginners (and a fair few non-beginners) can tolerate. Additionally, almost everyone uses a pretty straightforward workflow with git, but if you look at the docs it looks very complicated. You aren't trying to git checkout -b you are trying to start a new feature. This is a weird layer to add for someone struggling to control a computer using the keyboard instead of the mouse. The other thing is that the dev community has settled on a small range of simple and effective git workflows, where you only ever need 6ish commands, but check this out from man giteveryday (which man git sends you to if you want a simple answer): satellite$ git clone mothership:frotz frotz (1) satellite$ cd frotz satellite$ git config --get-regexp '^(remote|branch)\.' (2) remote.origin.url mothership:frotz remote.origin.fetch refs/heads/:refs/remotes/origin/ branch.master.remote origin branch.master.merge refs/heads/master satellite$ git config remote.origin.push \ +refs/heads/:refs/remotes/satellite/ (3) satellite$ edit/compile/test/commit I mean it's cool for a power user but a little intimidating for someone who just learned about man pages. Of course if you copy and paste it those (numbers) are going to give some weird errors. Edit: I should mention that despite the critique I appreciate all the incredible work they did in exchange for absolutely nothing from me.
watwut 7y ago
Back then, they shown me CVS in maybe 10 minutes. I never needed to Google commands and somehow knew how to use it after. It was easy to remember. Never run into problem I would have to Google to fix. Git takes more and people constantly ask questions or have to have cheat sheets printed.

nickthemagicman 7y ago

The thing that really put git together for me was understanding that each commit id was based on the previous commit id. So you could have two branches with the exact same code committed...and have different commit id's. That explains rebases...you take one branch and put it on top of another branches commits but REWRITE those new commit id's based on the new branches commits. Merges, you keep the same commit ids but smush two branches together. Also, when I do a git reset HEAD~1 and make changes I can force push and understand the my new code is overwriting the last commit. I think that really helped my understanding of git.