High-Level Problems with Git and How to Fix Them
gregoryszorc.com
High-Level Problems with Git and How to Fix Them
1–10 of 294 posts
Re: High-Level Problems with Git and How to Fix Them
#2I've just never found a reason to move on from SVN, to be honest.
I use GIT when I am forced to, but for everything under my control, SVN works the best.
I was unaware you could get rid of the staging area in GIT. I may need to look more into that.
Re: High-Level Problems with Git and How to Fix Them
#3Reading this article is harder than learning how to use git the way it's intended to be used.
Re: High-Level Problems with Git and How to Fix Them
#4I've just never found a reason to move on from SVN, to be honest. I use GIT when I am forced to, but for everything under my control, SVN works the best. I was unaware you could get rid of the staging area in GIT. I may need to look more into that.
Is today's Subversion fast enough? My first impression of Mercurial moving from Subversion was that it's much faster compared to Subversion (I know, Subversion over HTTP at that time was nothing more than WebDAV :-); I'd migrated all my repositories at the day 1. I later noticed that it noticably slows down with larger repositories and that became a good reason to try Git out (only to be displeased with its interface, though), but even Mercurial was "fast" enough to displace Subversion for me.
Re: High-Level Problems with Git and How to Fix Them
#5I've just never found a reason to move on from SVN, to be honest. I use GIT when I am forced to, but for everything under my control, SVN works the best. I was unaware you could get rid of the staging area in GIT. I may need to look more into that.
Honestly I find Mercurial to be a good alternative. It's a lot more intuitive than Git, but with the same basic benefits (local, complete history, more portable, etc)
Re: High-Level Problems with Git and How to Fix Them
#6The general sentiment of this article is in things like:
> A commit message is already too annoying for many users!
So because your ass is just lazy another guy a few months down the road has to suffer (in this case decipher what it is you wanted to do with your changes)?
Put some damn effort in, we have enough crapware already, we don't need to add more just because you were 'annoyed by having to document changes'.
The thing with git (the way I see it more and more while working with it) is that it barely cares if it makes sense to the 'lay user', it instead cares about wrapping the most fundamental operations on text files. And that's a good thing in my book. I would not like seeing all this ruined just because it was 'zomg too confusing, not useful for most users'.
Re: High-Level Problems with Git and How to Fix Them
#7I've just never found a reason to move on from SVN, to be honest. I use GIT when I am forced to, but for everything under my control, SVN works the best. I was unaware you could get rid of the staging area in GIT. I may need to look more into that.
Git is over complicated for most people’s use cases, but I wouldn’t give up the fast branching and the rebasing features.
Re: High-Level Problems with Git and How to Fix Them
#8The only reason I am urged to use git is for it's remote branch deletion (that mercurial frowns upon) and Gitlab (posh UI) that lacks with any mercurial hosting solution.
If hg supports to strip a remote repo, it would be just fantastic!
hg evolve is awesome and topics are fantastic, but a `hg strip ` would remove the need for any of these and help me keep my simple histedit, strip, push loop intact!
Re: High-Level Problems with Git and How to Fix Them
#9The general sentiment of this article is in things like: > A commit message is already too annoying for many users! So because your ass is just lazy another guy a few months down the road has to suffer (in this case decipher what it is you wanted to do with your changes)? Put some damn effort in, we have enough crapware already, we don't need to add more just because you were 'annoyed by having to document changes'.…
The thing with git (the way I see it more and more while working with it) is that it barely cares if it makes sense to the 'lay user', it instead cares about wrapping the most fundamental operations on text files. And that's a good thing in my book. I would not like seeing all this ruined just because it was 'zomg too confusing, not useful for most users'.
As the author intimates, most of the problems with git are problems of UI - the UI is simply not very good, it's confusing, inconsistent and too intimately tied with the implementation. This can and should be fixed.
This is a really interesting article, even if you don't agree with it, and the author has a deep understanding of version control systems (works on hg). There's no need to be dismissive of it.
Re: High-Level Problems with Git and How to Fix Them
#10>> And the Git staging area should be an opt-in feature.
Thousands of yes! `git commit -a` just doesn't add the untracked files it is the most annoying misfeature of any version control system. Oh, I added unwanted project directories? I would then just remove them and put them to `.gitignore`, or create a `.gitignore` prior to `init`.
Of course I could just alias `add -A . && commit -m` on every machine I ever connect to for developing. There's a great, practical solution.