Hacker News Reader

Comment by fogetti | Hacker News Reader

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.

View on HN

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.

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.

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.

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

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!"

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.

I'll give it a try.

Do they have a free personal version?

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/smartgit/

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.

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.

For example?

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.

`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.

You don't need all this to just do versioning.

> 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).

>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.

It's a tool that you use many times a day every day for years, and understanding how to do it well helps you make money... doesn't it make sense to spend some time to learn about how it works and how to use it?

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.

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.

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.

Reply on news.ycombinator.com