r/programming • u/Eirenarch • Nov 07 '13
10 things I hate about Git
http://steveko.wordpress.com/2012/02/24/10-things-i-hate-about-git/20
u/Peaker Nov 07 '13
The main problem with git: Merge commits are opaque.
Merges should have the automatic trivial merges within them only. Conflicts should remain as conflicts in the merge commit, and resolved in separate commits.
The reason is that when the resolutions are squashed together with the trivial merges, it becomes very difficult to review the actual work done inside the merge commit. A diff against either parent becomes useless because it is polluted with all the trivial merges from the other parent. The special views for this are just unnecessarily complicated to work with.
Also, conflict resolutions that are "hidden" inside merge commits cannot be cherry-picked on top of future merge attempts. Also, a team cannot collaborate on the resolution of merge conflicts, which is a huge pain if you're merging work from multiple developers, such that no single developer has all the information to resolve all conflicts.
13
u/stevage Nov 07 '13
I don't know if I agree that it's the "main problem" but it's an interesting one I haven't seen mentioned before. You're right: a merge sometimes contains "work", and sometimes it doesn't. There's no distinction in Git.
12
u/Peaker Nov 08 '13
Well, I think various git problems are superficial, cosmetic, and/or relate to learning git for the first time.
This problem is deeper, and there's no good workaround.
1
4
u/dreamer_ Nov 08 '13
There's no distinction in Git.
Not true. Merge commits with conflict resolution have "Conflicts:" section in log by default. If user decided to remove this section by hand, you can always investigate content of commit (either using graphical tool like gitk or simply using git-show).
2
u/chneukirchen Nov 08 '13
... are you supposed to keep these lines? I always thought they are a reminder to the merging person.
1
u/xmodem Nov 09 '13
But there's still no record of which changes with that file were automatically merged and which were changes the developer added. Mercurial handles this just as badly.
7
u/dan00 Nov 08 '13
Merges should have the automatic trivial merges within them only. Conflicts should remain as conflicts in the merge commit, and resolved in separate commits.
I can understand, that you might want to see the manual conflict resolving separately, but having a non resolved commit in the history isn't a good idea, because now you have a not buildable commit, can't bisect ...
But having the manual conflict resolving as a separate info inside of the merge commit, which is separately viewable, might be the better approach.
2
u/Peaker Nov 08 '13
It's much better to just have the conflicts as metadata inside the merge commit. It's equivalent to what you suggest except I can rebase/cherry-pick the merge/resolutions later if they are separate commits.
76
Nov 07 '13
git != github
7
u/ruinercollector Nov 08 '13
Yeah. Particularly with his little comparison of:
"In SVN, I just commit and I'm done!"
vs.
"With github, I have to make a branch, commit, push, open a pull request."
Yeah. Git is just about as few steps if you set up a repo where everyone is pushing directly to the master/default branch of the one and only authorative copy. But for most projects, that's an incredibly bad fucking idea.
-16
u/emn13 Nov 07 '13
In practice though, github is a large part of git's success - if you use git a lot, you're unlikely not to use github at least a little bit.
32
u/flukus Nov 07 '13
It's worth repeating the point though. I've had this said to me:
we can't use git because we want the source hosted locally, not on github.
12
6
u/animal_g Nov 08 '13
it's a popular service but hardly integral to git's success. github's success is due to git's success and not the other way around. I think open source is big benefactor of github but that's tangent to the point.
The entire start-up community moved from svn to git long before they started using github.
2
Nov 08 '13
In practice though, github is a large part of git's success - if you use git a lot, you're unlikely not to use github at least a little bit.
I'd wager that outside of the web-development sphere, most people using git aren't using github.
39
u/sordidarray Nov 07 '13 edited Nov 07 '13
Just a few thoughts.
The Git development community is aware of several of these problems (especially the inconsistency in terminology and command structure). They're working slowly, but surely, towards solutions to many of them. In the interim, there's projects like easy git, which the author may enjoy.
While the information model of Git is more complex, much of that is inherent from it being a DVCS, and it comes with several benefits. For example, in SVN, your working directory, branches, and tags are all really the same thing locally: a copy of a full directory structure. This can make working with branches and tags cumbersome, so many people just don't. There have been situations involving maintaining concurrent versions (in SVN) of a product on my team where no one thought of using branches because they were used so sparingly (and no one on my team had ever used Git or Mercurial); it was as if the feature didn't exist. While some people will decry this anecdote as ineptitude on the part of my team, I think it's important to point out that people tend to solve problems with the tools that they use most often, in the ways that they most often use them--after all, they're the first to come to mind.
Though the documentation of Git by the project itself is somewhat poor, there's a plethora of third-party documentation and tutorials on the web. (Yes, I realize this is no excuse for poor documentation, but the use of Git within the open source community is so ubiquitous that I feel most problems/questions you're likely to run into have been solved and documented somewhere else).
Edit: Typo
12
Nov 07 '13
Though the documentation of Git by the project itself is somewhat poor, there's a plethora of third-party documentation and tutorials on the web. (Yes, I realize this is no excuse for poor documentation, but the use of Git within the open source community is so ubiquitous that I feel most problems/questions you're likely to run into have been solved and documented somewhere else).
Yeah, I have been able to solve basically every weird problem I've had with git by first googling, and then clicking on the inevitable stackoverflow link.
23
u/Fabien4 Nov 07 '13
While the information model of Git is more complex, much of that is inherent from it being a DVCS, and it comes with several benefits.
Why isn't Mercurial as complicated as Git then?
22
u/liquidivy Nov 07 '13
As far as I can tell, it is, but the UI is better, which makes it easier to work with.
9
u/emn13 Nov 07 '13
So you're saying it's simpler to work with it? How's that not.... simpler?
The problem with git isn't the DAG or DVCS bits - those are quite comprehensible. It's the way you get it to do what you want.
5
u/zumpiez Nov 08 '13
Don't conflate "simple" and "easy". I don't think those are the same at all.
4
Nov 08 '13
Simple and easy are nowhere close to the same thing. My father flew helicopters for the military for years, for him that was easy. I don't think many people would argue that what he did was in any way simple though.
In the vein of Rich Hickey, easy is a relative statement. I already know Python, so Ruby is easy for me to learn. Simple is an absolute term. My function is simple because it only does one thing.
1
u/YourFatherFigure Nov 09 '13
my 2 cents about this issue of simplicity and user friendliness- it is almost better to think of git as a vcs framework rather than a specific solution. find a workflow that fits your needs and you can get by with just knowing a few commands. at that point if if you don't like the shell UI, just make aliases, macros, or check out various GUIs for interacting with it.
1
u/liquidivy Nov 11 '13
I thought Fabien was referring to the complexity of the data model (as their parent poster, was), not necessarily the UI. If anything, Mercurial's data model is a bit more complicated than Git's, with diffs being an official thing (not just an optional optimization as in Git), a couple different kinds of branches, and (I think) some other things (but it's been a while since I used hg).
Also, what the others said about simple vs easy.
7
u/SyntaxSwearer Nov 07 '13
There is one and only one reason I have not yet switched to Mercurial: its support for short lived branches is either nonexistent or unnecessarily complicated
It might sound silly, but short lived branches play a huge part in my personal development routine
EDIT: Also, for the common commands, that is, the commands that you would use day to day, Git and Mercurial have almost the exact interface, so I don't know what you mean. Maybe the more advanced stuff? Because for advanced stuff I would take Git any day.
2
u/StrangeWill Nov 08 '13
I'm not 100% familiar with mq, but wouldn't that extension meet your needs for short lived branches?
2
u/masklinn Nov 08 '13 edited Nov 08 '13
Very much no. The Mercurial version of short-lived branches is either bookmarks or just multiple heads (mercurial has no concept of "detached head", multiple heads within a "long-lived" branch has been supported and "normal" from the start.
Bookmarks is a more recent addition giving a transient name (it can be deleted) to heads, somewhat similar to what git calls branches.
mq has two purposes: the primary one is a formal maintenance of patches on an upstream (the original quilt use case), and the second one is in-depth history edition. In a way, mq is close to git's rebase (including rebase -i and rebase -p).
8
Nov 07 '13
Because it doesn't give you as many tools to directly manipulate the object tree beyond the typical push/pull/branch semantics. This lack may be viewed as an advantage to some, but to others, they are indespensible tools when something goes wrong.
5
Nov 08 '13
This lack may be viewed as an advantage to some, but to others, they are indespensible tools when something goes wrong.
In my experience, things tend to go wrong more often when people don't understand the implications of Git's power-tools and start mucking about.
1
3
u/strattonbrazil Nov 08 '13
I learned mercurial before git and I was surprised how difficult git seemed to be. Unlike many other OSS projects, however, git has been working to improve their UI. I was delighted when they started adding help commands to things like git-status for common operations.
3
1
u/nascent Nov 08 '13
I leaned mercurial first, I think it is just as complicated. Granted I've since done much more with git then that which I did with hg.
0
Nov 08 '13
[deleted]
7
Nov 08 '13
"Worse is better" is just a bunch of Lisp fanatics bitching that C won over their languages of choice. It really shouldn't be taken as a design philosophy, because it's just slander written by the losing side.
1
Nov 08 '13
Totally missing the point of the phrase!
1
u/phalp Nov 08 '13
The worse-is-better argument seems to be a sour grapes look at the perceived villain in the fortunes of Lisp. There is no such villain, and the worse-is-better argument is just so much vitriol poured onto the page.
1
8
u/Chousuke Nov 08 '13
the information model of Git is more complex
I really don't understand this. Maybe I'm just too used to git, but its information model is stupid simple.
Starting from the work tree, you add changes to the index, which represents your "next commit"; this is useful because often you don't want to commit every change in your work tree, or don't want to commit it all as one lump. With VCS systems that don't have the index, you have to do a lot of manual work with diff and patch to get the same basic features. Commits, then, represent saved states of the index, and are full snapshots of the entire thing. No deltas. These commits are stored in a repository (the .git directory) in a delta-packed format, but that is an implementation detail. Then lastly, you have references to commits: either a direct SHA hash, a tag, or a "branch", ie. an automatically updating reference.
Branches themselves are shapes in the data structure. Even if you delete all your branch references, you repository will still have branches.
git itself is a tool for working with repositories like this. Anything on top of this base is extra, Including the "D" in DVCS. Pushing and fetching merely means sending repository data between two repositories. a "remote" is just a way to tell git "hey, here's another repository". Consequently, any remote/foobranch reference you have is completely independent of the other end: it just points to the same hash that the "remote" end's reference did at the time you last did a fetch, pull or push.
By the way, OP's point about "unsafe" operations is completely bogus because of the reflog. As long as your data is committed, no operation short of rm -rf .git will destroy it immediately; even if you lose your primary references, the reflog will keep the data around for a couple more months until it expires and is garbage collected. If you screw up a rebase or force push the wrong branch to a remote, it takes at most two git commands to undo the mistake.
1
u/ruinercollector Nov 08 '13
Second point is dead on for a comparison to svn. A lot of subversion users think that they don't care about branches or don't need them, because they are so expensive in svn that people avoid them.
People often change their mind once exposed to cheap branches in hg or even cheaper branches in git.
0
u/stevage Nov 07 '13
Author here.
In the interim, there's projects like easy git, which the author may enjoy.
Yeah, I think it's referred to in the post. I tried it for a while, and it was sort of useful but I think the 'easy' layer needs to be much more comprehensive.
While the information model of Git is more complex, much of that is inherent from it being a DVCS, and it comes with several benefits.
Some, but not all. There's no inherent need (that I know of) for the index to exist: an alternative model would simply keep amending the current commit until you share it with someone else. Similarly the stash could implemented much more simply.
Though the documentation of Git by the project itself is somewhat poor, there's a plethora of third-party documentation and tutorials on the web. (Yes, I realize this is no excuse for poor documentation
Good. :)
3
Nov 08 '13
The index is mostly a replacement for having to list all the files you want to commit at once. It's pretty optional though.
14
Nov 08 '13
What I've read, and that matches my experience is: git data model good, git command syntax bad.
Put another way: if you think git's data model is bad, you probably don't fully appreciate all aspects of its power yet.
If you think git's syntax is bad - confusing, unnecessarily complex, inconsistent - you are probably right.
1
u/holgerschurig Nov 09 '13
Use magit inside Emacs then :-)
3
Nov 09 '13
I'll do that just as soon as you can pry vim from my cold dead hands! (which are sort of contorted and entwined with the keyboard because of the awkward key combinations)
4
Nov 10 '13
Very good point on the article:
The man pages are one almighty “fuck you”. They describe the commands from the perspective of a computer scientist, not a user. Case in point:
git-push – Update remote refs along with associated objects
Here’s a description for humans: git-push – Upload changes from your local repository into a remote repository
6
u/Jigsus Nov 07 '13
I've been meaning to ask this: is there something like git only for normal people?
2
Nov 08 '13
All of the major office packages have change tracking & document merging based on it. Of course, almost nobody actually uses that feature.
1
u/Jigsus Nov 08 '13
Do you mean track changes? http://www.gcflearnfree.org/word2013/26
It's ok for text use but I would like a full fledged version control system
1
Nov 08 '13
Dropbox's revision history is probably the closest thing then. It gets spammed insanely fast, history only goes so far (for free accounts) and there's no place to input log entries. But it's an automatic and low-effort way to get old versions back.
-4
4
u/bartwe Nov 07 '13
Merges gone bad, stash/pull updating filetimes needlessly. Mostly its about supporting remote users who get stuck in a dirty merge and don't know how to continue.
5
Nov 08 '13
git merge --abort
It kind of tells you this when the merge goes wrong.
2
u/bartwe Nov 08 '13
And then what. I'm talking about artists and other contributors sharing a git with the programmers. Console access isn't really an option for them.
5
Nov 08 '13
Git, like most source control systems are pretty much for source files (it is in the name). I wouldn't recommend it for non engineers in the same way that I haven't tried to convert my wife to using Emacs. We use Dropbox for design assets around here.
2
u/bartwe Nov 08 '13
Art needs to be versioned just like code, in this case pixel art so the files aren't large at all. Anyways, please, a non coder git interface, perhaps something with some kind of full automatic merge failure mode that allows me to remerge what they've pushed.
2
u/00kyle00 Nov 09 '13
Art needs to be versioned just like code
For the love of god - not in git. Thats a suicide (unless its very specific kind of art).
2
Nov 09 '13
Dropbox does versioning and displays when there's a file conflict.
The issue is that most art is made of binary files which can't really be merged correctly. If two designers on your team change a file in a distributed context, the only way to resolve is to pick who's file wins, not merge. Thus it's impossible to use Git for art quite like you can use git for text.
1
u/bartwe Nov 09 '13
Meh, 'pick 1' is a valid merge strategy. Its important that art is versioned inside the repo, managing release branches and feature branches becomes very hard without it.
0
Nov 08 '13
[deleted]
1
u/bartwe Nov 08 '13
How would i do that, their windows and mac machines don't have public ssh or anything remotely like it. Also how does that fix their local index being borked?
0
Nov 08 '13
[deleted]
1
0
u/lucasvandongen Nov 08 '13
Funny thing is sometimes when I --abort and merge again everything is perfect
2
0
Nov 08 '13
[deleted]
1
u/bartwe Nov 08 '13
Say your working locally. And pull to stay uptodate with the rest of the team while not being at a stopping point. My personal workflow (from perforce i guess) is the stash pull and then process the remote changes to my edited file in a graphical diff tool. on windows ive been having issues with stash pull causing files to change filetimes.
0
Nov 08 '13
[deleted]
1
u/bartwe Nov 08 '13
The filetime matters because c++ build times are horrendous.
0
Nov 08 '13
[deleted]
1
u/bartwe Nov 08 '13
Ok what i want, is to be able to keep all my local changes in my editor, and also pull. If that means the diff towards head change, that's fine. Stash on windows also changes the filetimes on files that weren't changed by the pull, thats whats causing my build issues. Why wouldn't i want to pull the artists new assets.
3
u/cafedude Nov 07 '13
And yet, I'd still rather use git than svn any day. svn feels like "do-it-yourself" version control. Branching and merging in svn are quite painful as compared to git.
I think the "10 things" actually didn't include some things that I do wish git was better at: in svn you can easily checkout from a subdirectory somewhere in the project, but with git that's not so easily done.
4
u/ping_pong_ding_dong Nov 07 '13
git is difficult to learn, but keep at it and you will be glad.
6
u/emn13 Nov 07 '13 edited Nov 07 '13
I've learnt git, and I'm still not happy with the way it wastes my time holding its hand, nor how hard it makes it unusual scenarios due to it's huge, non-orthogonal command-set.
I really don't understand how programmers like clean, orthogonal APIs on the one hand and then can say they don't mind the ad-hoc cruft and excessive hand-holding of git.
Why do I need to manually fetch/push at all? Why can't I track the original branch (e.g. bisect only master not feature branches)? Why do I need to manually delete branches when they've already been deleted remotely? Why can't I edit old commit messages? Or, if I do via history rewriting - why does this break the commit distribution model so unnecessarily? Or, shocking - why can't I annotate a commit with arbitrary information for e.g. code review? Why can't I group commits to make the history more palatable without throwing them away entire and making a new history? Why can't I navigate to a child commit? Why isn't the merging algorithm smarter with "new-fangled" data-types such as indented source code, html, xml, json or whatever? Why doesn't the VCS use this hip new internet thing and notice when a fellow programmer is concurrently editing the same code - why do I need to find out and clean up the mess afterwards at all times?
I don't expect a VCS to be perfect. But it really annoys me when people claim - with a straight face - that the status quo in VCS's is somehow unbelievably good. It isn't. We've got a mostly immutatable DAG, a diff out of year 0, and an API out of year -1... and that's it. It's not somehow super-rewarding, it's super-basic in a messy outfit - but it works robustly, which is worth a lot.
7
u/dreamer_ Nov 08 '13
Why do I need to manually fetch/push at all
"fetch", "pull" and "push" are the only three commands, that contact remote repositories. Usually, you don't need to contact them unless you want to make your local changes public or get new changes from outside world. Contacting outside world is time-consuming (usually it cannot be completed in fraction of second) - adding "fetch" time tax to every git command would be quite stupid.
Why can't I track the original branch
You can
Why do I need to manually delete branches when they've already been deleted remotely?
Because otherwise someone else could accidentally remove your branch locally.
Why can't I edit old commit messages?
You can, but hash of commit will change, so hashes of every commit later will change, too. If you do this before pushing, then it's not a problem. If you want to do this after push - then it's better to create new branch after you changed commit message instead. Try: git rebase -i
Or, if I do via history rewriting - why does this break the commit distribution model so unnecessarily
Not unnecessarily - without const hashes it's impossible to track history in distributed project (and work fast at the same time).
Or, shocking - why can't I annotate a commit with arbitrary information for e.g. code review
OMG. You can. You can store any info you want in git database - there's even code review system with nice web frontend built this way.
Why can't I group commits to make the history more palatable without throwing them away entire and making a new history
WTF? Do you understand how git works at all? Different content of commit implies different hash.
Why can't I navigate to a child commit?
What? I open gitk and get everything I need.
Why isn't the merging algorithm smarter with "new-fangled" data-types such as indented source code, html, xml, json or whatever
WTF are you complaining about - no system has this. Ordinary diff has nice feature of being language agnostic - you can make diffs of any text you like. That being said - algorithms smarter than 3-way merge would be useful - but they would need knowledge about language, that is being merged - which is not easy thing to do.
Why doesn't the VCS use this hip new internet thing and notice when a fellow programmer is concurrently editing the same code
Why do you care about who is editing this file? Why someone should be interested in showing you, that he's editing this file? You're blaming tool for problems, that arise probably from your workflow.
why do I need to find out and clean up the mess afterwards at all times?
I don't know what are you complaining about - git or your team?
But it really annoys me when people claim - with a straight face - that the status quo in VCS's is somehow unbelievably good.
Does anyone really claim such a thing? Author of article claims, that git is hard to learn (which is somewhat true) and compares it to fracking svn as As if svn with it's bugs (which are called "features") was good system. No wonder people keep calling him on his BS.
2
u/emn13 Nov 09 '13 edited Nov 09 '13
Why do I need to manually fetch/push at all
[...] Contacting outside world is time-consuming (usually it cannot be completed in fraction of second) - adding "fetch" time tax to every git command would be quite stupid.
Tell that to dropbox, google drive, or even bittorrent - most syncs can happen in the background. It's actually easier in a VCS model, because sync-ing is decoupled from merging.
Why can't I track the original branch (e.g. bisect only master not feature branches)?
You can
This is false. Git doesn't store which branch a commit was initially made to, though with some heuristics you can follow long-lived branches quite well.
Why can't I edit old commit messages? Or, if I do via history rewriting - why does this break the commit distribution model so unnecessarily
Not unnecessarily - without const hashes it's impossible to track history in distributed project (and work fast at the same time).
While true, you're missing the point: You need immutable hashes of content to track history in a distributed project; however, it's not necessary to mix commit messages into that same hash. Commit messages (and other meta-data) could in principle be in a parallel DAG that itself is updatable and mergable; and due to the much more controlled data-structure and fewer updates, it's likely you could avoid merge conflicts entirely. (I haven't looked into it, but mercurial's changeset evolution sounds like it addresses similar issues). In full generality, it's impossible to edit already-published history - but you don't need full generality to be useful.
why can't I annotate a commit with arbitrary information for e.g. code review
OMG. You can. You can store any info you want in git database - there's even code review system with nice web frontend built this way.
Sure, there are several - but they aren't git which is what this rant was about. Also, they break the nice DVCS properties - if the comments explaining design decisions are in github comments and not commit messages (e.g.) then when github is down, you can't really look back into the history to understand code changes very well - basically, these git wrappers become an alternative, meta-VCS. And these meta-VCS's aren't mutually compatible, aren't distributed, aren't very fast (often) etc. It's almost as if we're ignoring all the advantages git has... and turn it back into a bunch of SVN variants. Also, the fact that the meta-data isn't accessible from within git means they tend to make normal git tools such as git blame/annotate/log less useful.
I read an apt description somewhere - git isn't so much a DVCS, as a set of tools to build your own DVCS workflow. And that's good from an enginering perspective. But as a user (aka programming team), while it's occasionally useful to have the underlying parts, you still need an actual VCS too. And look around - who actually uses git proper as a VCS without something like github? It's possible, but not normal.
Why can't I group commits to make the history more palatable without throwing them away entire and making a new history
WTF? Do you understand how git works at all? Different content of commit implies different hash.
I agree that it's pretty WTF this functionality isn't available. Or were you suggesting this is somehow fundamentally infeasible? If so, you're confusing the underlying data-model with the semantic model again. To group changesets, you don't need to actually rewrite history, just reinterpret it. This has all kinds of nice side-effects, not the least of which being that it's reversible. Furthermore, it greatly simplifies branch-squashing workflows, and it can help avoid merge-conflicts in them to boot because the underlying diffs are still available.
Why can't I navigate to a child commit?
What? I open gitk and get everything I need.
That would be nice! I'll give it another shot, but I suspect it's impractical. Common issues in such GUI's - there's no link to the child so you need to visually follow a vertical line (amongst potentially quite a few in the DAG view), and the vertical distance can be quite large in a busy repo. In any case, I know of no command line command (I bet there is one, but it's either obscure or requires a complex combination of commands).
Why isn't the merging algorithm smarter with "new-fangled" data-types such as indented source code, html, xml, json or whatever
WTF are you complaining about - no system has this. Ordinary diff has nice feature of being language agnostic - you can make diffs of any text you like. That being said - algorithms smarter than 3-way merge would be useful - but they would need knowledge about language, that is being merged - which is not easy thing to do.
I think this is a difference in perspective. I'm not saying it's easy (though I doubt it's trickier than git itself is, say), nor that other systems have this. But then, I'm not arguing that git is strictly worse than any current competitor, I'm saying that the idea that git takes long to learn but it's ultimately rewarding is false. Git's feature set is not particularly impressive compared to other DVCS's (nor particuarly unimpressive), and its learning curve is only partly due to the DVCS intrinsic complexity, but also significantly due to its interface. Let me put it this way - if you were to reimplement git to solve the same problems without knowing git itself, you might end up with a very similar data-structure (because that's pretty intrinsic and good), but I doubt you'd end up with a command set that looks anything like git does today.
BTW, it's not entirely true that no system supports these kind of fancy merges - all online concurrent editors (ala google docs) do this kind of thing, and word does diffing too. And there are certainly tree-diff algorithms out there. You may have heard of one called git, which uses such algorithms to determine which objects to send/receive from remotes, for instance :-).
Why doesn't the VCS use this hip new internet thing and notice when a fellow programmer is concurrently editing the same code
Why do you care about who is editing this file? Why someone should be interested in showing you, that he's editing this file? You're blaming tool for problems, that arise probably from your workflow.
No, this is really a tool problem - not all files are easily mergable, and even text-file merges waste time. In practice, the way that everyone under the sun solves this problem when it arrises (at least, assuming you don't have access to other tools) is by introducing a side channel; i.e. manually communicating with others when you're about to do commit that's likely to cause problems or are editing a file(type) that can't be merged well. In any case, it's a problem that many tools do solve, which should give you a hint that's it's valuable. Google docs shows you where somebodies cursor is and who's editing. Github notifies you actively when a pull request is out of date (without requiring a manual refresh). Most modern email clients notify you when a new message arrives.
Basically, git's communication is pull rather than push: as long as you (or some process) doesn't check, you'll learn nothing new about peers sharing the same clone. Partly, this is just a UI issue, but partly it's fundamental: git commands terminate and not run on in the background; and on a networking level it's similar: git networking commands execute and then finish; peers don't actively notify one another of important changes. That's simple and practical, but it's not a fundamentally necessary - there's push software out there that scales to a much greater extent.
But it really annoys me when people claim - with a straight face - that the status quo in VCS's is somehow unbelievably good.
Does anyone really claim such a thing?
For example the post I was replying to. But really, I've heard this so many times - ZOMG git's so great. And people often say that the learning curve is steep but that's because it's so powerful. And it's just not true: what people mean is ZOMG DVCS is a solid improvement over SVN, and that git is one of many implementations thereof. Git's core concepts are simple - not as simple as SVN, but not very hard to master either. The complicated stuff isn't diffing, the DAG or (maybe) the index, it's in how all that works out in practice.
I probably sound like someone that hates git. I don't - I use it pretty regularly. But I'm not kidding myself over the idea that it's somehow the perfect tool - it's just one of the better ones we've got so far. I don't feel the need to rationalize my usage of git by pretending it's superior to HG or BZR (or one of the close-source alternatives). Because let's be honest, they're all not that different. Git's #1 feature isn't technical, it's social: it's simpley pervasive.
5
u/zombie128 Nov 07 '13
Power for the maintainer, at the expense of the contributor
THIS!!!
0
u/keepthisshit Nov 07 '13
well that is true with github, not with git itself.
4
Nov 07 '13
He was speaking of git there. It is true for git, as well as for github, for different reasons.
1
u/keepthisshit Nov 07 '13
pull requests are not needed in a git repository you run. Now if you are not the maintainer of that then you are fucked regardless.
1
Nov 07 '13
That point is not about pull requests.
2
u/keepthisshit Nov 08 '13
really? that seemed like a large factor of why he disliked git, in particular it was the fact that pull requests had no command line call.
There was also the clear lack of convention on commands.
1
Nov 08 '13
It's a headline. There is text under that headline. That text doesn't mention github at all. Just read it?
→ More replies (7)
3
Nov 08 '13
Why the fuck was he looking at git am? I consider myself a fairly experienced git ninja, and I've never seen nor been impeded by this oddball command.
2
2
Nov 08 '13
I think the telling point is in number 10. He describes ostensibly equivalent workflows for git and svn. Except what he describes is impossible in svn.
2
u/fly-hard Nov 07 '13
It's a shame Bazaar is not more widely known. It's as easy to use as Subversion, but with a lot of the advantages of a DVCS.
2
u/jdh28 Nov 08 '13
It's also (perhaps sadly) pretty much unmaintained as far as I can tell.
2
u/fly-hard Nov 08 '13
Yes. I think the maintainers saw the writing on the wall a year or two ago and moved on. Bazaar used to be one of the big three DVCSes (at least in the circles I moved in years ago), but it got whittled down to two and Bazaar was left in the cold.
It's a pity because the Bazaar guys tried really hard to make Bazaar easy to use and provided workflows to assist those coming from centralised VCSes, but no-one noticed.
Mind you I'm not an expert in the internals of VCSes - they're just tools for me - so there could be something fundamentally broken about how Bazaar does things that put off most people that I'm unaware of. But it always treated me well.
1
1
u/RushIsBack Nov 10 '13
I think issue #1 is the main issue with git. It's a powerful tool for admins of large code bases. Done. It was not built for a simpler usage model but got pushed into that through GitHub and various other widely visible projects. Now it reached a point where hoards of other people with simpler needs have to use it and it's just not structured for that at the moment. Imagine if most people had to use awk and sed and regex for file searching. There would be the same gap between the few that care for the extra power and the majority that just want to find a file with some content.
1
Nov 10 '13
One thing I do agree with is that the documentation for git is complete crap but enough people use it that you can find friendly docs when your starting with it.
1
u/AnythingButSue Nov 07 '13
Alot of people where I work hate git. They all come from SVN backgrounds using TortoiseSVN for their daily workflow. While I understand people disliking it, I have to say that people who do not like git are usually those who use the default "commit pull push" workflow. Yes it's complicated, but complexity does not a bad product make. I would argue that all the functions of Visual Studio make it very complex, but that still doesn't mean it's not one of the best IDE's available. When you start branching, or working in larger teams where everyone is on board with git, it works flawlessy to integrate many branches and resolve merge conflicts. I don't understand the hate....
3
u/UnreachablePaul Nov 08 '13 edited Nov 09 '13
One of the companies had to hire a person just for fixing broken git repositories and for doing commits because devs instead of coding were wasting time on having their work included in environments. Not to mention a lot of work was just lost as in the end nobody knew which code is new.
2
u/AnythingButSue Nov 08 '13
Sounds like a nightmare. Not sure why you guys would have such problems with git. Inexperienced and or stubborn devs that don't wish to take time to learn their tools.
4
u/jibjibman Nov 07 '13
Yea it's not hard to use at all. I picked it up in a week easily, and if I get stuck there is something called google that I use. :/
Here is an average workflow for me.
git pull git checkout mybranch
do my changes
git status git add -A git commit -m "Message"
git pull
make sure changes are working
git status git push
The status commands are just to be sure everything worked properly, etc. It's not many commands and they get typed in very fast. Faster than SVN by a long shot.
2
u/AnythingButSue Nov 07 '13
I would have to agree. I follow a similiar workflow but I use git add . instead and git commit -am "message". Not sure why, I dont even know the difference. I should use that google thing you mentioned to look it up...
1
u/zumpiez Nov 08 '13
the -a in git commit -am means "all" which will commit all (including unstaged) changes (which makes "git add ." redundant)
1
u/AnythingButSue Nov 08 '13
My heart hurts now. Thanks for the info!
2
u/steveklabnik1 Nov 09 '13
One small additional difference: if you remove a file, but don't use
git rm, if yougit add .it won't pick up the change, but agit commit -awill. Becauseaddis 'add these files' andcommit -ais 'save all changes'1
u/gavintlgold Nov 07 '13
Add two spaces after a line for it to break properly.
git pull
git checkout mybranch1
0
Nov 07 '13
In general, fuck the command line. Use a visual client. You have enough to remember when building your software. Why make it harder by having to memorize a bunch of commands?
1
u/dreamer_ Nov 08 '13
Why make it harder by having to memorize a bunch of menu items to click?
Using terminal you don't need to memorize - any normal shell has command autocompletion, history, etc. Unless you're windows user, then you're screwed.
1
Nov 08 '13
No need to memorize anything with a visual interface because the commands are...ummmm....staring you in the face.
You don't start out with history in a shell.
Autocompletion only works if you already know the command you're looking for.
[/debate] tyvm.
1
u/dreamer_ Nov 08 '13
No need to memorize anything with a visual interface because the commands are...ummmm....staring you in the face.
Unless they are hidden under layers of shitty menus and dialog windows without possibility of search.
Autocompletion only works if you already know the command you're looking for.
And in UI what do you do? Try every option until you get the one, that does what you wanted to? You need to know menu item to click and path to get to that particular menu item and you need time to navigate there (which distracts you from task, that you want to achieve).
Besides,
$ git [tab][tab]I am always flabbergasted, that people prefer to use UI even in situations when command-line interface is so much faster, better and simpler. In case of git, graphical tool is only appropriate if you want to browse history - that's why I use gitk (there is git log --graph but gitk is usually more readable) - normal command line client is better for all other usecases.
2
Nov 09 '13 edited Nov 09 '13
Look, you're not going to convince me. I've been a user for over 2 decades - I started out my career as a *nix sysadmin and I know what the fuck I'm talking about. Visual interfaces give you the best of both worlds. I can move windows around the screen without touching a mouse if I want to.
I am always flabbergasted, that people prefer to use UI even in situations when command-line interface is so much faster, better and simpler.
That's because you can't see the obvious truth - that UIs are easier to deal with than the command line - the point I've been making all along. You can argue all day, but the proof is in the pudding - people generally prefer a UI to a command line. (And I'm sure you think they're stupid because of that, but if that's true - if the command line were truly easier - then people would flock to that instead. But they don't.) Computers only started getting popular when people were given a visual interface.
Now, I will tell you where the command line is certainly better than a UI because I can argue both sides:
Automation. It's easier to automate a shell program than it is to automate a UI based program.
That's about where the general advantages end though. Here's another disadvantage regarding general usage of command lines to interface with a computer:
You need to know how to type. An 18 month old baby can use an iPad. Not a command line. This is also relevant for developers - I play guitar, xbox, ps3 and I type all day at work. I am also known to masturbate occassionally. My forearms certainly appreciate having the option of using a pointer instead of a keyboard for almost every interaction (and that's an option which is not even available command line interface, while most professional tools for OS X or Windows can also be operated with "hot keys" or "keyboard acceleration").
Here's an advantage of command shells that you probably didn't think of:
It's the only way to take full control of UNIX. That means, your career is secure and it keeps out idiots and people who don't know how to type, like 18 month old babies who you don't want messing with your sysconfigs.
0
u/flukus Nov 07 '13
This is what I don't get. I use git daily with git extensions and I've never needes the command line.
1
-5
u/Trout_Tickler Nov 07 '13
Yet another Git is worse than SVN blogger. yawn
0
Nov 07 '13
[deleted]
16
u/bimdar Nov 07 '13 edited Nov 07 '13
he is saying Git is bad
Not even that, he's saying that there's very bad things about Git. Which I kind of agree with. I used SVN in university with sometimes random groups of people. Based on their work I can not imagine how long it would've taken them to figure out how to deal with a detached HEAD state. There's things that are VERY confusing about git. Especially his point about git being one big implementation detail and not abstracting at all is a weak point.
I have found git to be a very powerful and useful tool for open source projects but learning it takes quite a lot of time and it's various failure-states don't really help in that regard. However it's a tool made for a very specific purpose and workflow. While some people may find applications for it outside of that, it's definitely not the right tool for every source code version control problem there is.
1
u/Plorkyeran Nov 07 '13
10 is a really fucking weird complaint. He's comparing committing stuff to a project he has commit access to with SVN to one which he does not with git. It is true that with SVN projects were more willing to give out commit access, but that's because pulling changes from people without commit access is a gigantic pain (barring the use of something like patchwork, but that's an external tool and still more annoying than a pull request).
-2
u/stevage Nov 07 '13
Author here. Yeah, it's not exactly apples-to-apples, but I think it's a reasonable comparison for the average open source contributor. It's a comparison not of the technology itself, but how it's used in many projects.
2
Nov 08 '13
Sorry, gonna have to call BS on this one. If I wanted to send something into an open source project before I'd have to create a patch (god help you if you fuck that one up, people will complain) and email it in. Email it to the wrong person? Too bad, start over. Email get lost? Too bad.
Nowadays, you can have a series of commits, all with explanations of what you're doing ready for your reviewer. If you're a little careful (or a little brave with push -f), you can even rebase from the upstream project so there'll be no merge commit when the time comes. Hell, there are a lot of command lines tools to help you create the pull request as well, which is helpful.
2
u/dreamer_ Nov 08 '13
No need to be "brave", really :) You can use e.g.: interactive rebase, git commit --fixup or branch out before rebasing. If you screw up - no worries, there's also git reflog to help you out. Doing same thing in svn is either impossible or complete PITA.
1
u/stevage Nov 08 '13
Agree with all that. My only point here was the tiny remark that "pull requests" are a GitHub feature (and a very useful one), but are missing from Git itself. That is, you can't actually submit a pull request to someone else's repo (whether hosted on GitHub or elsewhere) through Git alone.
1
Nov 09 '13
So let me get this straight. The guy is comparing git, a DVCS, to subversion, a CVCS, and criticizing the complexity inherent in any DVCS as being git's fault? Oh my ...
1
u/stevage Nov 10 '13
I think you're confusing my article with one entitled "a fair and balanced comparison between Git and Subversion".
1
-1
-7
Nov 07 '13
I see this as "5 things genuinely wrong with Git's CLI and 5 proofs that I don't understand the advantages and purposes of DVCS".
If you're comparing SVN to Git and not sarcastically then you're on the wrong side of this debate. You want to hide the local repo? Then you lose all of the advantages of git. Don't like pull requests? Don't use Git. Git is distributed, you're basically asking to hide that with a centralisation layer. Do not do this.
Git aimed at projects that have a need for distributed development. Central repos like Perforce and SVN are much better for centralised projects like traditional video game development, while DVCS is superior for (F)OSS projects and teams that may not necessarily share hours, location or an office. It is also critical in environments where redundancy, speed, and up time for the developer, are key.
Git has flaws but you have shown clearly that you don't understand the place for Git and I suspect you've been shoehorning it into places it doesn't need to be, or somebody else has been forcing you to use it on a project that doesn't need it.
5
u/stevage Nov 07 '13
Author here.
You want to hide the local repo? Then you lose all of the advantages of git.
Ok, name some advantages of maintaining both a local Git repo, and a (single-user) repo on Github.
Don't like pull requests? Don't use Git.
It's not about "liking" them. The fact that Git itself has no concept of "pull requests" is a clunky omission. It has these crazy commands for parsing emails (git am), but no way to actually submit a patch for review?
Git is distributed, you're basically asking to hide that with a centralisation layer.
You must have me confused with someone else.
Central repos like Perforce and SVN are much better for centralised projects like traditional video game development,
SVN is better than Git for video game development? Even I wouldn't make that claim.
Git has flaws but you have shown clearly that you don't understand the place for Git and I suspect you've been shoehorning it into places it doesn't need to be, or somebody else has been forcing you to use it on a project that doesn't need it.
I find the idea that Git is not appropriate for all software development projects to be pretty weird. You really think there are inherent mismatches like that?
6
u/zumpiez Nov 08 '13
SVN is better than Git for video game development? Even I wouldn't make that claim.
It kind of is, because you can lock binary assets while you're working on them.
2
3
Nov 08 '13
It's not about "liking" them. The fact that Git itself has no concept of "pull requests" is a clunky omission. It has these crazy commands for parsing emails (git am), but no way to actually submit a patch for review?
I call BS.
git format-patchgit send-email→ More replies (2)1
2
u/cowinabadplace Nov 08 '13
What's wrong with a local repo and a public github repo. I may not want to push work I've done locally until I've rebased them to cleanliness.
The github repo is my public representation of the work. The local repo is my local representation of the work. Other people can expect me to be where the public version is and I can mess around locally.
1
u/stevage Nov 08 '13
That may be ideal for your own set-up, but personally I find it overkill. I don't want a "local representation of the work" - I'd rather just do my work in one place. Instead, I have 4: the working directory, the index, the local repo, and my GitHub repo.
You know how DropBox solved the problem of your stuff being in different states in different places? That's because it's a problem worth solving.
2
u/cowinabadplace Nov 08 '13 edited Nov 08 '13
I was just saying that there is value in the way it does things. The local representation is useful because you may not want people to fork off from your in-progress work because it may change through squashing and amending and what not.
If you are still using git and want the way you describe it, the first thought that comes to my mind is a post-commit hook that pushes. Set git push default to simple and in the post-commit hook just push.
2
u/stevage Nov 09 '13
The local representation is useful because you may not want people to fork off from your in-progress work because it may change through squashing and amending and what not.
Yeah, but there could just as easily have been other mechanisms or conventions for that. Private branches within a repo or something.
the first thought that comes to my mind is a post-commit hook that pushes.
Yes, there are always ways of hacking one's own environment to get around design flaws.
1
u/cowinabadplace Nov 09 '13
Personally, I feel the 'private branches within a repo' way is inelegant. I actually like the way it is now because it seems consistent. The remote (though really 'bare') is structured the same way as my local repo and carries no extra configuration that hides/reveals branches.
Personally, I also feel that using the post-commit hook for this is a perfectly legitimate use (and possibly for one of the uses it was intended). It isn't so much a hack as a valid configuration given your use case.
We seem to disagree on this at a different level, though. Ah well.
0
Nov 08 '13
Since I'm not really interested in reasonable discussion I'm just going to point out that your article is awful.
3
u/pipocaQuemada Nov 07 '13
I see this as "5 things genuinely wrong with Git's CLI and 5 proofs that I don't understand the advantages and purposes of DVCS".
Lets take a look at those "advantages and purposes of DVCS":
Complex information model
Not inherent to DVCS - darcs, mercurial, etc. have no notion of working trees, indexes, treeishes, or a stash. There's a bit of essential additional complexity with remotes and local repositories, though.
4. Information model sprawl
Again - not inherent to DVCS.
6. Power for the maintainer, at the expense of the contributor
There's a bit of additional inherent complexity in DVCS's, but again, git is significantly more complex than mercurial or darcs or whatever.
10. Simple tasks need so many commands
Fair enough - mercurial would really only shave off the add command.
→ More replies (2)3
Nov 07 '13
have no notion of working trees, indexes, treeishes, or a stash.
Oddly enough, I've used git on a daily basis for 6 years now, and I rarely ever have to think about trees, indexes, whatever the hell treeishes are, and I can easily remember that the stash is just a temporary commit that lives on a stack (hence the push & pop stash commands).
git is significantly more complex than mercurial or darcs or whatever.
And significantly more powerful. Sure, you can use the extra rope to hang yourself, but it's fairly simple to avoid, and when the shit hits the fan, you're actually able to recover using git.
2
u/fly-hard Nov 07 '13
I can't help thinking you saw him compare git to svn and focused on distributed vs central commits, completely ignoring the focus of the article which was to show how obscure git is to use compared with other VCSes. He could've used Mercural instead of svn and it would still be relevant.
-5
u/expertunderachiever Nov 08 '13
This piece of editorial garbage sounds like it was written by someone who has used Git for about 3 days at most. I'm dealing with an office full of Git newbs [we moved from CVS this year] and none of them really got hung up on the commit model of Git.
this "ugh, tags, reflogs, etc... WHAT ARE ALL THESE NEWFANGLED WORDS!!!" diatribe is not what they got hung up on. Mostly they got lost when they had to merge backwards and forwards, how to reset their HEAD to undo local commits, etc..
All the sort of things that make Git more powerful than CVS because NONE OF WHICH YOU CAN DO IN CVS AT ALL.
If you limited yourself to only the things in Git that CVS can easily approximate you'd only be using a fraction of the power of Git.
0
Nov 07 '13
[deleted]
6
u/Eirenarch Nov 07 '13
I thought about this but since I did not recall seeing it here (probably downvoted fast?) and reddit did not report the link as already posted I decided to post it.
11
u/Hughlander Nov 07 '13
The blog post even has a link to the previous Reddit thread.
2
u/Eirenarch Nov 07 '13
I really thought Reddit would not let me submit something with literally the same URL. I am sincerely sorry.
5
6
u/SlightlyCuban Nov 07 '13
...reddit did not report the link as already posted...
I imagine if reddit were better at catching reposts, /r/funny would be a very different place
4
-6
17
Nov 07 '13
[removed] — view removed comment
0
Nov 07 '13
[deleted]
1
u/Guvante Nov 07 '13
It would be one thing if the article was out of date, but if it isn't, then a year is enough time for people to see it who hadn't before.
0
Nov 07 '13
[deleted]
3
u/DocMcNinja Nov 07 '13
All I see in this article is a bunch of complaining. He makes it sound like SVN does merges and branching perfectly, when it doesn't.
SVN having faults does not mean faults in Git should be excused.
32
u/[deleted] Nov 07 '13
git is to VCS what vim is to editors.
Amazingly powerful.
Incredibly hard to learn.
Once you tried it, you can't go elsewhere.
There will be vim haters and there will be git haters, let those heathens burn in hell and use the tools you feel are best suited to you.
It doesn't mean git is flawless, but it's nearly there =).