Git can't be this terrible, what am I doing wrong?

[drjdpowell]

I've switched to Git from Mercurial recently, and my opinion of it gets worse and worse.  The number of times I've gotten stuck trying to figure out how Git got screwed up and how to fix things is way too high.  Mercurial had similar issues when I first learned it, but it was an order of magnitude less than Git.  Git seems to make the simple unnecessarily complicated and non-intuitive, with any step wrong leaving you in a position of not being able to fix things. with horrible gobbledygook error messages and blank stares on my part. 

So I must be doing something wrong.  What should I read up on to make Git less crap?

[Neil Pate]

10 minutes ago, drjdpowell said:

I've switched to Git from Mercurial recently, and my opinion of it gets worse and worse.  The number of times I've gotten stuck trying to figure out how Git got screwed up and how to fix things is way too high.  Mercurial had similar issues when I first learned it, but it was an order of magnitude less than Git.  Git seems to make the simple unnecessarily complicated and non-intuitive, with any step wrong leaving you in a position of not being able to fix things. with horrible gobbledygook error messages and blank stares on my part. 

So I must be doing something wrong.  What should I read up on to make Git less crap?

I have recently embarked on this same journey and also found things to be way less intuitive than Hg. Which client are you using? I found GitHub desktop awful and am now using GitKraken which I really like.

• Just a few days ago I "lost" some work by rolling back to the "wrong" commit. I was able to get back my commit by reverting to the commit using the hash which can be found by running: git reflog
• I seem to get into a Detached head state quite often. No idea what I am doing wrong but have sort of figured out how to recover from it.
• Was not able to see the commits from another user for love or money. Turns out somehow the "upstream" on the remote (whatever this is) was not set correctly

Anyway, stick with it my friend. The war is over and git has won...

[drjdpowell]

The problems I've had have mostly been using SourceTree. I've started to just us TortoiseGit, but it is lacking compared with TortoiseHg that I used to use.  

[drjdpowell]

The "detached head" is a good example of the problems with git: confusing terminology for something that has no reason to exist.  Why does it even allow commits not on any branch to exist as a possibility, let alone something that is easy to mistakenly do?

[Neil Pate]

1 hour ago, drjdpowell said:

The problems I've had have mostly been using SourceTree. I've started to just us TortoiseGit, but it is lacking compared with TortoiseHg that I used to use.  

Try GitKraken, it is not free if you want to access private repos on GitHub (which I do) but I really like the interface and does everything I need apart from showing the reflog which I believe Fork does show.

[JKSH]

I switched from Subversion to Git many years ago and encountered quite a steep learning curve but it was well worth it in the end -- Not having to be connected to the server all the time was a great boon.

I haven't used Mercurial much, but from what I read Hg and Git were supposed to be similar to each other (at least when compared to SVN or Perforce)

 

1 hour ago, Neil Pate said:

Which client are you using? I found GitHub desktop awful and am now using GitKraken which I really like.

Yes, your choice of client has a huge impact on your experience. I find GitHub Desktop far too limiting; I like the power of SourceTree but I wouldn't recommend it to newcomers of Git -- too much power and too many options can overwhelm.

Having said that, SourceTree supports Mercurial too. Perhaps @drjdpowell can use SourceTree to create and manage a Mercurial project, and then repeat the same steps for a Git project? This might help you to see the parallels between the 2 technologies and learn Git faster.

 

1 hour ago, Neil Pate said:

• I seem to get into a Detached head state quite often. No idea what I am doing wrong but have sort of figured out how to recover from it.

Every single commit in the Git history can be checked out.

• If you ask git to check out Branch X, your HEAD now points to the latest commit on Branch X.
• If you ask git to check out Commit Y, your HEAD now points to Commit Y and is now considered "detached" (because it is not attached to a specific branch).

To avoid "detached HEAD state", all you have to do is specify a branch when you check out.

 

1 hour ago, drjdpowell said:

The "detached head" is a good example of the problems with git: confusing terminology for something that has no reason to exist.  Why does it even allow commits not on any branch to exist as a possibility, let alone something that is easy to mistakenly do?

I have a use-case for entering detached HEAD state: Suppose I've made many commits recently and then discover a bug in my code. I want to go back to an earlier snapshot of my code, so I check out a commit that I think is good. Voila, I'm now in detached HEAD state and I can run my old code for debugging.

When my HEAD is detached, I think of it as working on an anonymous/unnamed branch (a bit like how I can edit and run an unsaved VI, but if my PC loses power the VI is gone)

Don't let the terminology discourage you; your journey will be worth it. Happy coding!

Edited July 7, 2020 by JKSH

[drjdpowell]

55 minutes ago, JKSH said:

Don't let the terminology discourage you; your journey will be worth it.

Doubtful.  You went from Git from SVN,  I'm coming from Hg.  In Hg, if you want to go to an earlier commit, you just go to that commit.  If you want to make changes, then you make a new branch coming off at that point.  If you like those changes, you might merge that offshoot branch with the main one.  I have yet to find anything in Git over Hg that is actually useful.  I consider the possibility of losing committed work because I didn't realize I was in an "anonymous/unnamed branch" to be a strong negative.  

[Neil Pate]

@jksh thanks for the explanation. In every other VCS I have used I can pretty much arbitrarily move around the changesets without fear. All I did was roll back to check out some earlier code and my recent changes just "disappeared" from the client. That is very unexpected behaviour. Sure, I was able to get them back by looking up the commits using the reflog because they were not truly missing, but it is really strange behaviour to me.

Not wanting to sidetrack the discussions, I now using Plastic SCM at work where I do Unity and C# dev and its really quite nice to use. Apparently it is based on git but made more for game devs.

 

[drjdpowell]

Ah, "Reflog".   Another tool to fix the problems caused by the other tools.

[LogMAN]

6 hours ago, drjdpowell said:

What should I read up on to make Git less crap?

Atlassian has comprehensive (and visual appealing) documentation on Git.

• https://www.atlassian.com/git/tutorials
• https://www.atlassian.com/git/tutorials/atlassian-git-cheatsheet

Unfortunately Git has a lot of commands, most of which you'll probably never use. I suggest you play around with it to get used to the workflow and be prepared for your daily job. Just don't do stuff like "git push -f" and you should be fine.

3 hours ago, drjdpowell said:

Doubtful.  You went from Git from SVN,  I'm coming from Hg.  In Hg, if you want to go to an earlier commit, you just go to that commit.  If you want to make changes, then you make a new branch coming off at that point.  If you like those changes, you might merge that offshoot branch with the main one.  I have yet to find anything in Git over Hg that is actually useful.  I consider the possibility of losing committed work because I didn't realize I was in an "anonymous/unnamed branch" to be a strong negative.  

You might find this worth reading: https://sqlite.org/whynotgit.html

5 hours ago, drjdpowell said:

The problems I've had have mostly been using SourceTree. I've started to just us TortoiseGit, but it is lacking compared with TortoiseHg that I used to use.  

There you have it, your problem is not Git, it's the tools. Have you ever tried the command line?

In my experience, there are many tools that work well with some aspects, but fail miserably at others. They only get you so far before you need some command line Voodoo to fix the "unfixable". Eventually you'll get used to the command line 🤷‍♂️ (I lost this battle a long time ago)

3 hours ago, Neil Pate said:

All I did was roll back to check out some earlier code and my recent changes just "disappeared" from the client. That is very unexpected behaviour. Sure, I was able to get them back by looking up the commits using the reflog because they were not truly missing, but it is really strange behaviour to me.

This is the same reason why I abandoned SourceTree a few years back. Tools like that only give you access to a subset of instructions and they don't even provide ways to undo bad decisions.

6 hours ago, drjdpowell said:

The "detached head" is a good example of the problems with git: confusing terminology for something that has no reason to exist.  Why does it even allow commits not on any branch to exist as a possibility, let alone something that is easy to mistakenly do?

To be fair, you do actually get a big warning message (which nobody seems to read, including me):

The command line version of this is much more helpful in my opinion, as it even teaches you some new commands.

There is also no way to mistake it with the normal output.

[LogMAN]

This actually sums it up quite nicely 😋

[JB_1592]

 

4 hours ago, Neil Pate said:

Try GitKraken, it is not free if you want to access private repos on GitHub (which I do) but I really like the interface and does everything I need apart from showing the reflog which I believe Fork does show.

Assuming you've tried both, what are some of the features you found useful over Sourcetree?

At least at a glance they look pretty similar. GitKraken has the ability to add issues to the sidebar, which is nice. Unfortunately, it only seems to be available for Jira and their own Boards product, and I'm not really planning to use either... probably.

[Aristos Queue]

GIT is that awful, in my opinion. I've screwed up many things years. I try not to use it as much as possible.

The reason that GIT has taken over the SCC world is not because of its ease of comprehension or elegance of interface. It is because it is the only tool that can manage the full complexity of massive software teams, parallel releases, compression of features, etc, and the folks who use it daily just deal with it and get used to it.

[Aristos Queue]

1 hour ago, LogMAN said:

They only get you so far before you need some command line Voodoo to fix the "unfixable". Eventually you'll get used to the command line 🤷‍♂️ (I lost this battle a long time ago)

THIS. Absolutely this.

Misery loves company: please use GIT!

[Neil Pate]

2 hours ago, JB_1592 said:

 

Assuming you've tried both, what are some of the features you found useful over Sourcetree?

At least at a glance they look pretty similar. GitKraken has the ability to add issues to the sidebar, which is nice. Unfortunately, it only seems to be available for Jira and their own Boards product, and I'm not really planning to use either... probably.

Not really tried sourcetree enough to make an educated comparison. I really like the look and feel of GitKraken and am now invested in learning how to use it properly.

Also, at the time I was super annoyed with Atlassian for the way they handled the sunsetting of Mercurial and was fed up with dealing with their snail-slow Bitbucket servers all the time so I just picked up my toys, set aside a week or so to move 30 repositories over and now am a happy Github koolaid drinker.

[shoneill]

8 hours ago, drjdpowell said:

Doubtful.  You went from Git from SVN,  I'm coming from Hg.  In Hg, if you want to go to an earlier commit, you just go to that commit.  If you want to make changes, then you make a new branch coming off at that point.  If you like those changes, you might merge that offshoot branch with the main one. 

Correct me if I'm wrong, but you can also do all of that with SVN....

[JKSH]

8 hours ago, drjdpowell said:

I have yet to find anything in Git over Hg that is actually useful.

That is expected.

As I wrote previously, Git and Hg are very similar to each other in scope/functionality (but not in workflow details!). 5 years ago, people were saying that we should just pick one or the other and stick with it; we gained nothing from using both.

Today, there is a benefit to learning Git: It gives us easier access to the plethora of code bases around the world, and it helps us move forward from incidents like Bitbucket's bombshell.

 

8 hours ago, drjdpowell said:

if you want to go to an earlier commit, you just go to that commit.  If you want to make changes, then you make a new branch coming off at that point.  If you like those changes, you might merge that offshoot branch with the main one.

You have just described Git (and SVN, according to @shoneill). The exact steps differ but the concepts are the same.

 

8 hours ago, drjdpowell said:

I consider the possibility of losing committed work because I didn't realize I was in an "anonymous/unnamed branch" to be a strong negative.

Agreed.

My analogy with an unsaved VI was a poor one, I realized. Unlike a power cut which is quite plausible, it is actually quite difficult to accidentally lose commits unless we ignore prompts/hints/warnings like the ones @LogMAN posted.

 

8 hours ago, Neil Pate said:

In every other VCS I have used I can pretty much arbitrarily move around the changesets without fear. All I did was roll back to check out some earlier code and my recent changes just "disappeared" from the client. That is very unexpected behaviour. Sure, I was able to get them back by looking up the commits using the reflog because they were not truly missing, but it is really strange behaviour to me.

Yes, Git could be made safer by automatically preserving "detached" branches and requiring the user to manually discard them, rather than automatically hiding them when the user moves away.

I guess I've never encountered this issue in my 9 years of regular Git use because I habitually create a branch before making any new commits at an old point. This highlights the importance of running UX tests on people who aren't familiar with a product!

[sam]

I found gitExtensions to be very good too.  http://gitextensions.github.io/.

If you coming from HG, this maybe a good choice to try.

[LogMAN]

7 hours ago, Aristos Queue said:

It is because it is the only tool that can manage the full complexity of massive software teams, parallel releases, compression of features, etc, and the folks who use it daily just deal with it and get used to it.

Let's also not forget that Git was originally invented by Linus Torvalds to manage the Linux kernel with thousands of contributors, commits, and branches being done every day. Although my projects are slightly below that complexity, Git does manage (barely)

4 hours ago, JKSH said:

Yes, Git could be made safer by automatically preserving "detached" branches and requiring the user to manually discard them, rather than automatically hiding them when the user moves away.

This is the fault of tools like SourceTree. Here is an example of Git moving away from a detached head:

Again, they provide you with the necessary command template to prevent you from loosing track of your changes.
I cannot stress enough how much better the command line interface is compared to any of the tools (at least the ones I have tried).

[smithd]

i find gitextensions to be my favorite. it asks you a lot of questions and is fairly 'low level'...which is to say it doesnt do much fancy past displaying command line output. it also exposes all of the little options like force pushing (to override history on a server) or amending commits, both as pretty clear options on the appropriate dialog.

https://gitextensions.github.io/

 

[JB_1592]

18 hours ago, LogMAN said:

Let's also not forget that Git was originally invented by Linus Torvalds to manage the Linux kernel with thousands of contributors, commits, and branches being done every day. Although my projects are slightly below that complexity, Git does manage (barely)

 

Which goes a long way towards explaining why it's necessary to use the CLI for so much. (And why there isn't actually a real official GUI to begin with.)

 

18 hours ago, LogMAN said:

This is the fault of tools like SourceTree. Here is an example of Git moving away from a detached head:

Again, they provide you with the necessary command template to prevent you from loosing track of your changes.
I cannot stress enough how much better the command line interface is compared to any of the tools (at least the ones I have tried).

I'm not saying you are wrong about the CLI being better for some tasks, but this message seems clear enough to me.

That said, GitKraken does not seem to show any warnings at all when creating a detached head or navigating away from one. That's a bit disappointing.

[drjdpowell]

I have been reading various Git guides over the past couple of days, and am starting to get a grip on it.  One of them mentioned the "most common way to get a detached HEAD", which I suspect has been both my and Neil's problem.  That link is quite a good guide (there were other good once, but I've forgotten where that are).  The key is to understand Git "branches", especially that they are not actually branches, just pointers to commits.

Git is still overly complicated, though I can possibly see that the complexity is from supporting VERY large repos in projects like Linux.  It is annoying that there is no obvious go-to UI for Git.  The command line is poor UX.  I made good progress having two UI (Gitkraken and TortoiseGit) open on the same repo at the same time and asking "why do i not see a comparable view".  This allowed me to see where TortoiseGit had confusing default settings (in particular not ordering commits chronologically!).  I am probably going to stick with TortoiseGit for now.

[Darren]

20 minutes ago, drjdpowell said:

It is annoying that there is no obvious go-to UI for Git.

I've noticed that too. I think it's because, for whatever reason, different UIs resonate with different people more than others. Of the several I've tried, Fork is the one I prefer. I can say that in the couple of months I've used Fork the UI has made my (admittedly simple) workflows straightforward, to the point that I've never encountered the detached HEAD issue, or any other major issues for that matter. And the authors of Fork provide incredibly responsive tech support as well.

[LogMAN]

19 hours ago, JB_1592 said:

I'm not saying you are wrong about the CLI being better for some tasks, but this message seems clear enough to me.

Nice, that message did not exist in the version of Sourcetree I used a few years ago. Glad to know they keep improving. Still, some genius decided to make "Yes" the default answer...

[JB_1592]

4 hours ago, Darren said:

I've noticed that too. I think it's because, for whatever reason, different UIs resonate with different people more than others.

 

Maybe, but honestly I think it's just the Linux culture. There really isn't one singular, official GUI for the OS itself, why would we expect one for the VCS created by the same guy to manage the kernel source?

Besides, if we took that as a valid reason not to create a GUI for something then how do we end up using a graphical programming language?! 🤣