50 ms·

High-Level Problems with Git and How to Fix Them

391 points by jordigh 9y ago

qznc 9y ago
Wow, usually criticism of git is attacking strawmen. This one is actually reasonable and I agree with it.
bluetwo 9y ago
I'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.
- lifthrasiir 9y ago
  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.
  - gmueckl 9y ago
    The speed of Subversion depends heavily on the hardware involved. On an underpowered server and/or over a WAN/internet connection it will be slow. On a fast server in a good LAN it is so fast that the speed difference to git or hg does not matter in practice: you will spend more time entering commands than waiting for the tool to process them.
- stephenr 9y ago
  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)
- influx 9y ago
  Git is over complicated for most people’s use cases, but I wouldn’t give up the fast branching and the rebasing features.
  - BurningFrog 9y ago
    GIt is only as complicated as you make it. You don't have to use all the features :)
    - qznc 9y ago
      No. That would be like handing a professional compound bow [0] to a newbie instead of a simple one [1]. The note "only as complicated as you make it" would be quite sarcastic in this case. [0] https://outdoorsexperienceonline.files.wordpress.com/2013/07/pse-compound-bows.jpg https://outdoorsexperienceonline.files.wordpress.com/2013/07... [1] https://www.archery360.com/wp-content/uploads/2016/05/traditional-bows.jpg https://www.archery360.com/wp-content/uploads/2016/05/tradit...
  - thomasahle 9y ago
    Apparently SVN has something like that now.
- TorKlingberg 9y ago
  I have do work with svn quite a lot. It's simpler that git in some ways, but things like merging branches just does not work at all.
  - bluetwo 9y ago
    Yes, I've seen that pain, but my workflow rarely needs branch merging, so I've avoided that issue.
- GordonS 9y ago
  I do like SVN, and have used it for more than 10 years. It's simple, and I like simple. But... I do seem to get a lot of annoying conflicts that require resolution though. Git just works, though does having a bigger learning curve
waterphone 9y ago
Reading this article is harder than learning how to use git the way it's intended to be used.
gear54rus 9y ago
The 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'.
- grey-area 9y ago
  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.
- y7 9y ago
  You can use Git for things other than open source software development.
- rbehrends 9y ago
  > 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)? The problem that Greg is referring to here is that `git commit` (as for many other version control systems) overloads two distinct operations: checkpointing your work and creating a new revision. Forcing you to provide messages for the former use case can even be counterproductive [1]. Contrast this with, say, Smalltalk's ENVY: saving a method automatically versioned the method (without the need of providing any other metadata), but you could also separately create system snapshots as named versions. Common Git usage is to squash checkpoint commits, anyway, with individual commit messages often disappearing in the process. [1] https://xkcd.com/1296/ https://xkcd.com/1296/
arunc 9y ago
The 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 <remote-url>` would remove the need for any of these and help me keep my simple histedit, strip, push loop intact!
- gmueckl 9y ago
  Could that be added as an extension? I don't know how extensions can work with remotes.
- rbehrends 9y ago
  1. The problem with `hg strip` is how it is (and has to be) implemented, because of the revlog format. Basically, revlogs store changesets in chronological order. Stripping a branch means first saving all commits that are not being stripped (but occur chronologically after the first stripped commit) to a bundle, then truncating the revlog before the first stripped commit, then restoring the commits from the bundle. This can already be an expensive operation locally, but it's even more of a problem on a server shared by multiple users who may have been pushing their own commits. 2. The general recommendation would be to use `hg prune` (part of the evolve extension) instead. Pruning commits will just hide the pruned commits and pushing will then send the obsolescence markers for those commits to the server, hiding them there, too. This is an append-only operation, so it's cheap and works well even with multiple users. 3. In general, though, it is a problem that Git and Mercurial treat remote branches/repositories as second class citizens. This is something that Bazaar got right: Bazaar abstracts over the storage, so (except where limited by network performance) you can do pretty much anything on a remote branch/repo that you can do locally.
nurettin 9y ago
>> 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.
- jononor 9y ago
  Automatically adding untracked files would make it extremely easy to commit (and without other safeguards, push) unwanted changes. Annoying things like node_modules or binary screenshots that now bloats the repo history forever (unless one rewrites the history), or potential security breaches like passwords/keys or logs/configs with confidential information.
  - nurettin 9y ago
    Then there is .gitignore_global for your node_modules/
- GordonS 9y ago
  I seem to recall that Visual Studio Could has an option to immediately push all your commits to remote, bypassing staging. I kind of like staging tho; I find it helps keep me focused on small, self-contained pieces of work, instead of working on several pieces at once.
- forgottenpass 9y ago
  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. Maximally practical or not, if you don't already have a repository for configuration files, shell scripts, aliases, and other little quality of life enhancements then create one today. Your git workflow isn't the only thing that will benefit. Next time you're hassled to do yet another "git config --global user.name" compare it to the hypothetical overhead of typing "git clone foo/homedir.git ~/homedir && ~/homedir/prep" to get both your name and aliases setup. I never thought I needed a dotfile repo, but once I made it I realized I waited way too long. It doesn't have to be anything fancy, just take 10 minutes and lay the groundwork to help yourself develop more quickly.
klodolph 9y ago
It's clear that there will be a successor to Git some day, in the sense that Git is a successor to SVN (yes, I know Linus's viewpoints on SVN). But the successor won't be a "better Git" just like Git isn't a "better SVN". The driving features of Git's successor will be unrelated to Git UI gripes. If Git's UI gripes were important enough, people would just be using Mercurial (which has it's own quirks). The biggest problems I've personally seen with Git are the same problems you see with other VCS, where two people change the same file, and one commits the changes first. Now you have to merge the changes and sometimes it's a pain in the ass when you just want to submit your changes and go home. A better VCS isn't going to solve that! I'm still glad that Git delivered me from all the merging problems that SVN had, although I've heard that SVN is a little better these days.
- posterboy 9y ago
  you could work in branches and merge after feature freeze, or you could, you know, colaborate and communicate intent before beginning to edit.
- arunc 9y ago
  Personally, the problems I have with git are related to the fact that none of my coworkers use git. If I mess up my repo I don't have anyone to look for. The experience with mercurial is exactly the opposite. I never needed to look for "experts" to solve a problem in mercurial. hg help is all I needed. Consistent UX and safe and powerful VCS is all we need.
  - pritambaral 9y ago
    > I never needed to look for "experts" to solve a problem in mercurial. hg help is all I needed. Git has good documentation too. As long as we're doing personal experience, here's mine: I learned git from `git help` too (well, `git --help` and `git <command> --help`), and I never needed to look for a git expert in my team for advanced operations; I did have to be one for others quite a few times , but when it wasn't an immediate, pressing concern I could just point to the appropriate manual.
gumby 9y ago
I'm surprisedly the staging-area hate. Does it really violate peoples' assumptions? I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.
- CJefferson 9y ago
  My problem with the staging area is it produces commits which never "exist" (that is, that code was probably never compiled/tested in isolation). I'd be happier if the staging area was handled at the filesystem level, give me a directory which at all times contains the staging area, so I can test it.
  - jononor 9y ago
    Your CI system can test those commits in isolation. I frequently push supposed-to-be-stable commits like that alone to my working branch on Github, so Travis CI can tell me if I have a problem. Though I'm quite picky about commits, that each merge point into mainline (master) is tested is what is most important to me. Github PRs with Travis CI for instance enforce that pretty OK. If I don't bother to do a PR, and the changes as a linear set upon master, I like to use git merge --no-ff master to force a merge commit.
- maxxxxx 9y ago
  To me staging is the best part of git. I don't want to commit all the time so I slowly stage changes that I think are OK. Once the feature is done I can do a full commit. Perfect!
  - spiznnx 9y ago
    The author purports that this can be achieved without staging. For example, you could slowly commit small changes that you think are ok on a work-in-progress feature branch with `git commit -p --allow-empty-message`. When you are done you could squash rebase + message rewrite. While currently this workflow is clunky, it could be made to work with the same nice semantics of your workflow, and not have a staging area at all.
milofeynman 9y ago
This may be sacrilege on here, but at my previous job I really enjoyed TFS. It's been awhile but the workflow felt a little more intuitive than git. And some of the merging features were nicer.
- maxxxxx 9y ago
  I used to work with TFS but after working with git I can't stand it anymore. But it shows that people have different tastes.
  - kylemuir 9y ago
    Strongly echo this sentiment. Last time I used TFS was probably in 2011 so things might have changed significantly since then but off the top of my head things I use to hate but now don't need to worry about since using git over TFS: - Offline? Looks like you'll have to wait to make that change or any other change for that matter since you can't check out files if you're offline. When doing remote work this use to do my head in. - TFS On Premise putting readonly locks on every file you have. Why? Great question. Made writing build scripts and their ilk much harder to accomplish. - Want to make a branch? That'll be an entire copy of the source code times however many branches you want
    - maxxxxx 9y ago
      Add to that detection of new files or deletions outside of visual studio. This is so easy in git and a real problem in TFS.
- GordonS 9y ago
  I've worked with TFS and SVN for more than 10 years, and Git for maybe 5. I find TFS the slowest of the lot, by quite a large margin.
- Chromozon 9y ago
  TFS is great if everything in your codebase is a Visual Studio project. If you are trying to use it for other things, there are better version control systems out there. My ranking is Perforce > Git > TFS > SVN. I haven't used Mercurial. I like Perforce the best because of its clean UI, its explicit checkout mechanism (all files are read-only by default, and you have to check out anything before you can edit), the integration tool GUI, and the ability to cloud-save work without submitting it. TFS is nice because it has built-in code review, but the UI isn't nearly as clean as Perforce.
phillco 9y ago
Anecdotally, being able to commit anywhere, without needing a branch name, is one of the biggest conceptual differences when we teach new hires Mercurial at Facebook.
- nhaehnle 9y ago
  As a convinced Git user, this is the one aspect of the article that I found genuinely interesting. I mean, you can commit anywhere in Git, too (and I occasionally do for some advanced use cases), but it tends to not be well supported by Git. (And, I might add, probably not by Hg either if it requires enabling an extension...) Anyway, hg show work looks like an interesting thing. It's perhaps a bit more magic than Git usually goes for, since you can't just show all DAG sinks (it would get messy really quickly with amends and rebases). And I don't think I'd benefit too much from it, since I've come to prefer having all my work-in-progress on a single branch. But I can see how someone could appreciate the feature.
  - rbehrends 9y ago
    > As a convinced Git user, this is the one aspect of the article that I found genuinely interesting. I mean, you can commit anywhere in Git, too (and I occasionally do for some advanced use cases), but it tends to not be well supported by Git. "Not well supported" in this context means that you can lose data (as commits that are not reachable from a ref can be garbage collected). Mind you, you have to ignore warnings/errors to get there, but without ignoring them, you also won't be able to actually have anonymous branches. > (And, I might add, probably not by Hg either if it requires enabling an extension...) It does not require an extension. The `show` extension that Greg talks about is a smart log display, which shows a contextual log for your current work. Anonymous branches have been part of Mercurial from the beginning, long before the `show` extension existed. For what it's worth, it's not so much that Mercurial supports it, but that Git doesn't. Git is rather unique in its setup in this regard. No other VCS that I know of uses garbage collection and in particular branches to prevent revisions from being garbage collected. (Some may require you to name branches for other reasons, but not so you don't lose commits.) It's probably also worth noting that we have an implementation detail leaking into user space here. Git uses what is essentially purely functional data structures underneath to achieve atomicity in the absence of an actual database engine [1]; a different implementation, such as on top of SQLite, could avoid this. [1] Atomicity here is not about locking, but about a transaction being interrupted by the user or an external event, such as a shutdown.
sharp11 9y ago
Lots of food for thought in this article, but the part I find most interesting is his distinction between "soft" and "hard" forks. (Viz., are you "forking" in order to collaborate or in order to go your own way?) If collaborate, it would be nice to lower the barrier to participation ... more like Wikipedia. I know that I often don't bother to submit a PR for small changes bc of the overhead of setup. Whereas I fairly often make small edits to Wikipedia changes, because it's so easy.
- ygra 9y ago
  GitHub at least has a simple way of making small changes: You can simply click 'Edit' on any file, which will make a fork, commit and pull request in one operation. It's only good for single-file changes you're confident to make in a simple web text editor, though. I've only used it for typos.
  - majewsky 9y ago
    I don't like that doing so frequently litters your personal repository list with forks. Would be nicer if they allowed arbitrary users to push to branches like `incoming/<username>/<branchname>` in the original repo.
    - ygra 9y ago
      Isn't that up to the repository maintainer whether they allow pushes from other people? And sure, it litters your list with forks, but you can remove them as soon as the PR is merged. And that's the case for pretty much anything you contribute to (unless you can push there, of course).
      - majewsky 9y ago
        No, there is no process in Github to allow everyone to push to a certain branch (or branches matching some regex). Github forces people without collaborator rights to use forks. I've seen this lead to confusion where people fork a repo and send PRs even though they have contributor rights, because they didn't understand the difference. As an extreme example: https://github.com/flystack/misty/pull/101 https://github.com/flystack/misty/pull/101 - This is a repo with only one person with write access [1]. Yet this same person only commits to their private fork of this repo and sends himself PRs that he then immediately merges. I don't mean to blame the developer, only the Github UX. [1] It says "6 contributors" on the mainpage of the repo, but four of these are from my team and we definitely don't have write access.
taeric 9y ago
If you requested save in your favorite GUI application, text editor, etc and it popped open a select the changes you would like to save dialog, you would rightly think just save all my changes already, dammit I'm sympathetic to what this is asking, but I have to feel that this would lead to much better practices for many people. I'd wager a ton of folks would be more "why in the world does it think I changed that?" than they would care to acknowledge. That is, by and large, the quick sanity check of "these are the things you did?" is actually quite valuable. Regardless of any annoyance it may give. Similar to the "did you mean to print all 500 pages?" warning you can get if you print something huge. Sometimes, yes. Yes I did. Often times, no, not what I intended.
- jcranmer 9y ago
  In my experience, the benefit you get is from giving you an editor to edit the commit message, which has a list of files changed, and can be cancelled in some way to abort the commit. Both hg and git can do this, so it's not necessary to have a separate command and staging area just to do it.
  - icebraining 9y ago
    List of files is not enough, I always do 'git add -p' to see the actual changes. And sometimes I detect an error, and I want to fix it and then keep going without having to re-evaluate the changes I had already seen.
    - MaxBarraclough 9y ago
      My preference is for `git commit --verbose`, which shows all changes in a 'commented-out' section of the commit message file.
    - ryanbrunner 9y ago
      The authour of this article suggests a solution - `git commit --interactive` could prompt you for each change like `git add -p` does without needing a staging error. You're right though that it would take some cleverness in that command to allow you to fix a typo without restarting the operation.
jonthepirate 9y ago
In practice I have found the biggest missing feature that I wish existed is the ability to pull a single file from a known ref on a remote server. For example, give me the Dockerfile located in the root of the master branch tip. Can't do that. Instead, you have to clone the entire repo first.
- drchickensalad 9y ago
  Well you can clone with --depth=1, so performance wise it's not too bad at all, but yeah still gets all the other latest files.
jcranmer 9y ago
One personal anecdote: In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. Even nowadays, where I'm more or less forcing myself to use git [1], I'm incredibly hesitant to try any sort of complex git operation because of the risk that I might lose my in-progress commits. While the problems of git's UI is well-known, I don't think it's as appreciated that git's complexity generally discourages people from trying things out. I'm never really sure what could cause me to lose unpushed commits or uncommitted working files, especially with git's predilection for reusing the same verb to do slightly different operations for different concepts. In stark contrast, it's more difficult to get Mercurial to chew up your work without telling you [2], and it's easier to explore the command lists to see if there's something that can do what you want it to do. [1] The repositories I'm working on involve submodules, which hg-git is exceptionally poor at supporting well. Even so, the list of git alias commands on the whiteboard is entitled "Forcing myself to use git before I rage-quit and switch to Mercurial." [2] I have done it, though. Worst offender was discovering that hg qrefresh <list of files> causes only those file changes to be committed, and files not mentioned are decommited to working-directory-only changes... which hg qpop happily deleted without warning me, causing me to lose a large patch. That was when I put the patch queue directory in version control.
- shaan7 9y ago
  Just keep a copy of the `.git` dir before you try the complex operation. If you screw it up, restore it back and voila!
  - sigjuice 9y ago
    No. This does not safeguard any uncommitted files.
    - nicoburns 9y ago
      Leaving any files uncommitted before a complex operation in git is a really bad idea (make a temporary commit if necessary). It's almost impossible to completely lose committed data, but pretty easy to destroy uncommitted data.
Smith_seth 9y ago
I GOT MY PROGRAMMED BLANK ATM CARD TO WITHDRAW A MAXIMUM OF $5000 DAILY. I AM SO EXCITED BECAUSE I ORDERED AND PAID FOR DELIVERY, DIDN'T GET SCAMMED, AND I NOW OWN MY HOME, MY BUSINESS HAS GROWN BIGGER. GEORG BEDNORZ (georgbednorzhackers@gmail.com) IS THE NAME OF THIS USA HACKER THAT GAVE ME THE CARD AND ALSO HE IS OFFERING ALL KINDS OF LOAN WITH ONLY 2% INTEREST RATE.
blux 9y ago
The Git staging area doesn't have to be this complicated. A re-branding away from index to staging area would go a long way. Adding an alias from git diff --staged to git diff --cached and removing references to the cache from common user commands would make a lot of sense and reduce end-user confusion. --staged is already an alias for --cached in the latest Git version.
- BlackFingolfin 9y ago
  And it has been for some time (years, I think)
  - majewsky 9y ago
    Years, yes. At least since 2.0, though probably longer.
yeukhon 9y ago
Here are the commands I use: git init git clone git checkout git commit git commit -m git commit —amend git rebase git add/rm/diff [—cached] git push git branch and a few more I can’t remember exactly. I try to keep my git workflow simple. The most complex is probably checkout abd rebase with several different branches.
- emj 9y ago
  You are already using ammend and rebase, you can do plenty of complex and hairy stuff with that, especially as a team. I'm also guessing you use merge and log at times. FWIW this is my philosphy with git too, but have you not experienced the points he brings up? I was nodding my head at all of them; branches are time-consuming, staging is problematic and forks are a bad analogy. The recent post and hype about the Facebook, Google and Microsoft monorepos should make us ask the question what our systems for source control is supposed to do really. save changes to a source code save changes to big binary assets annotate those changes annotate the files themselves tagging versions signing of code code review handle regressions testing collaborating (ACL, DCVS, official monkey patching etc) merging search on the whole code base refactoring on large code bases All these things have uses but they are not really supposed to be tied to one VCS, we have very basic needs when working with source code streamlining the UX for that workflow might be more important and in the same time opening up for easy access to the other stuff.
- saltedmd5 9y ago
  "I try to keep my git workflow simple," and yet I see 'git rebase' but no 'git merge' in that list.
  - zegl 9y ago
    `rebase` is simpler than `merge` in larger teams/projects, as the history will be much cleaner.
    - saltedmd5 9y ago
      Rebase is not simpler in any context - rebase rewrites history, which, if branches have been pushed to remotes, then necessitates force pushes, which in turn breaks any other instances of the same branch. By using rebase to "keep history clean" you are largely undermining git's power as a DVCS. Rebase as a tool is not inherently bad but it is definitely not simpler than merge - it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing and in my experience most teams that are using it as a core part of their workflow are doing so for the wrong reasons (generally because of a fundamental misunderstanding of how branching and merging works in git and why it works that way).
Sujan 9y ago
Workspaces please, now. That would be so much nicer than the current need to fork.
- beagle3 9y ago
  Are you familiar with the 'git worktree' command? It's rather new, and it might be what you are after.
dmitriid 9y ago
One of the main problems I still face is: Git's CLI is incomprehensible. It's a tangled mess of poorly named commands with even more poorly named options. If there's a "create" command, it's "modify" counterpart is likely to be "create -b -u -t --modify", and it's "delete" counterpart is likely to not exist at all or be an arcane incantation of several non-related commands and a push. Unfortunately, most GUI tools are just thin wrappers on top of all this mess (with the possible exception of GitUp whose abstractions are also paper-thing at times)
hyperion2010 9y ago
While many of these criticisms are valid, they seem to be written from the point of view of a user that doesn't really want control over their versions, they just want versions. I'd suggest that there are other tools for this, such as a properly configured ZFS setup which are atomic beyond most users widest dreams (especially if all the versions of a vim .swp file are retained). If you just want versions, yes, git gets in your way, because git is about control. Yes if you have all those versions you could go back and 'squash' them into a commit, but can you imagine trying to bisect those to find a bug?! Somehow I also get the feeling that this perspective is similar to that of a friend who really didn't like the idea of pulling, and that he should just be able to push to the remote repository. A seeming lack of awareness of the collaborative side of version control and development. Git isn't just about control, it is also about providing additional provenance information and context needed in order to understand what code does and the reasons why changes were made. Sometimes in order to get there we have a bunch of low intention commits that we use to checkpoint, and let's be honest, how many have created commits that put a tree in a broken state? I know I have. The bit about making the documentation more consistent in its use of vocabulary seems like something that will have a couple of pull requests by the morning. tl;dr If you want versions use ZFS if you want control and communication use git. Talking defaults is always a good exercise. with and EDIT: show work would be amazing ... edit2: I just don't see the workspaces model passing the bag of dicks test. I want to code, I don't want to have to become a community moderator and clean up people committing all sorts of crap to my project and on the other side I just wan't to code and not have to deal with the bags of dicks who are going to gate keep their projects. There are just too many social edge cases and the differences are mostly just semantic (iirc the way github implements forks is basically as workspaces anyway...). That said, I would really like it to be possible to have pull requests be part of the repo history instead of, say, the listserv.
- chrisan 9y ago
  Well said. > Most people see version control as an obstacle standing in the way of accomplishing some other task. They just want to save their progress towards some goal. In other words, they want version control to be a save file feature in their workflow. That was horrifying to me. We _religiously_ have a JIRA-XXX tag in our commits so that every commit has some kind of perspective in addition to the comment. This has been extremely useful in getting more context of why something was changed when dealing with a long lived project spanning multiple developers. Even if the commit message itself is weak or lazy we still have the user story in JIRA to get full context.
deleted 9y ago
[deleted]
Grue3 9y ago
Git staging area is nothing compared to Mercurial's branch/bookmark ridiculousness. And the need to use plugins for things that Git trivially supports out of the box.
cannam 9y ago
This is a really interesting piece that introduced a number of ideas I hadn't ever thought deeply about, particularly in the section on nameless workflow. (I do think of myself as reasonably capable with both Mercurial and Git.) If your instinctive response is to defend Git, boost Mercurial, ridicule people who can't use their tools, ridicule the tools for being unusable, or whatever -- suppress it for a while and give this article some thoughtful attention.
- cryptonector 9y ago
  My instinctive response is to explain why git is easier. TFA is very unfortunate. I think the author is missing out on a better experience, and their git hate isn't helping them.
  - Sheeriapi 9y ago
    Let me suggest to suppress that instinct and read the article again. There's not a shred of "git hate". Quite the contrary: The author is a Git user himself and has detailed suggestions to improve Git and its ecosystem. That is a good thing, not "very unfortunate". Also, Git is easier than what exactly? Than the proposed improvements? I suspect you haven't read the article. This is neither a "Mercurial vs Git" nor a "Git sucks" piece, which you should have noticed while reading.
giomasce 9y ago
The thing I love of git is that its internal structure is very simple and transparent, so for any given repository it is possible (although not necessarily easy, if things are well messed-up) to understand what is going on. It is true that the interface is often messy and inconsistent, sometimes annoyingly so, but if I can understand what things are, I can somehow work out how to do things with them (in extremal situations, I know I can fast-export everything, process with custom Python scripts, rather easy to write, and fast-import again). While if I do not understand what things are, the most powerful and user-friendly tool will have very little value to me. Also, knowing what is git under the hood makes me very confident that I will not lose pieces: as soon as the hash of my interesting commits is in another repository (which is not corrupted), I can do whatever I want with the first one and everything I care will be safe anyway. All of this depends on me knowing what happens inside git and the git insides being rather simple (a hash tree with a handful of object types); I think I would like Mercurial (or any other DVCS) much more if I knew the same about it: can someone suggest places where this is described?
- bluGill 9y ago
  As a long time mercurial user being forced to switch to git I find that I know more about git internals than mercurial. Mercurial provides a nice abstraction so I don't have to care. In face I've seen a few hints that mercurial has actually changed their internals over the years, but since everything still "just works" I don't think about it. By contrast git is forcing me to care even though I have better things to do with my time. Sadly github and CI systems provide community tools around git not mercurial (mercurial is an afterthought at best in most CI systems). Those community tools are compelling enough that I'm switching to an inferior system just to get them.
Philipp__ 9y ago
I was holding to that famous UNIX mentality for many years, since I started programming almost... Use many programs that do one single thing, pipe the data, print it on the main output etc etc. That’s how I used git too, writing 160 chars wide commands... I tried playing with Emacs year and a half ago, and it was big cultural shock, for first year of using it I still couldn’t adopt kitchensink philosophy. But after barely scratching what emacs had to offer I went back to my unix terminal workflow it felt clunkier than ever. Takeaway from this story can be Magit. It totally changed my perception of git, and felt like more robust and semantically better way to use/understand git. Maybe it was like that because of few years of terminal git usage, don’t know how will complete beginner react to magit. But what shocked me the most was how my approach to git changed with dofferent interface. GUIs never appealed to me, but magit represented the middle ground of GUI like functionality with terminal like interface that got many things semantically right.
- globuous 9y ago
  <edit> TD;DR: Magit is a lesson of UX. </edit> +1 for Magit. When I discovered it is when I discovered git. I assume tig must be similar although I've never looked into it but... With magit, from my editor, I can easily check: my git status, choose which hunks to stage or unstage, commit easily. I can switch branches with less than 10 keystrokes. etc. But to me, what's coolest about it is that I can easily see commit histories and graps for branches, files, and the repo. With less than 5 keystrokes. And I can navigate these histories easily. Finally !!! Same story for pushing, pulling, merging, rebasing. Which all of this you can do in CLI obviously. But Magit makes it easy, and because now I have everything I need with regards to git just a few keystrokes away, I can interact with git easily. So I do it.
  - masklinn 9y ago
    My only beef with magit is that it's really slow for nontrivial projects ($dayjob's main codebase is 1MLOC and has ~110000 commits reachable from HEAD, "status" takes a good 5s, and adding/removing stuff from d/u or d/s quickly gets painful).
  - dbdr 9y ago
yoodenvranx 9y ago
In the beginning I tried to use git exclusively through command line because I thought that's how real men do it. But after using gitkraken (or similar products) I will never go back to using git through its command line interface. Being able to see the whole repo structure is just so much more convenient and it helps to resolve most merging problems much faster. git guis all have their own problems, but overall using a git gui for me is the better choice in 95% of all use cases.
- michaelgrafl 9y ago
  I always have both open. Gitkraken for having a broad overview of local and remote branches, stashes, and for staging chunks of code. And the command line for everything else. Some things just confuse me in any GUI Frontend or don't work as fast as on the CLI.
  - cbcoutinho 9y ago
    This is what I do too. I like looking at my entire staging area commits using the CLI, but merging makes much more sense using GitKraken. Version control is just too complicated of a problem (for me) to reason about in one 'view', and using different tools to look at separate scales of a repository is the way I've found to work through that difficulty.
- bauerd 9y ago
  First time I hear of gitkraken but why would a Git repository viewer have me create an account!?
- jononor 9y ago
  Yeah being able to see what you do is critical for understanding and feeling comfortable. I do everything via "git", but always have "gitk" open for that visual overview. gitk is very basic and not that great, but does the trick.
deleted 9y ago
[deleted]
tomxor 9y ago
I like what this guy has to say so far, but it's a bit surprising that someone with his knowledge got this wrong: > The Git staging area doesn't have to be this complicated. A re-branding away from index to staging area would go a long way. Adding an alias from git diff --staged to git diff --cached I dislike the mess of crappy synonyms too, but git diff --staged is already an alias, in fact it's the primary way I diff the staging area because it's a well fitting synonym.
- masklinn 9y ago
  > I dislike the mess of crappy synonyms too, but git diff --staged is already an alias Problematically it's very little used, it's only mentioned once at the very tail end of the `—cached` description, `--cached` is still the primary flag, and the essay remains correct that references throughout the documentation are inconsistent. It's not exactly hard to miss, if e.g. you learn git through the Pro Git book, the option is not mentioned once, and even the full text search has not indexed it. Furthermore, there are many other commands which take a —cached flag but don't have a —staged alias (diff-index, submodule, check-attr, apply, rm)
- dwheeler 9y ago
  One small improvement would to make sure that all the options with "--cached" also have "--staged", and make sure that all the documentation uses term "staging" (deprecating "index" and "cached"). The git UI is historically terrible, but it's gotten a little better over time... it could definitely be improved further with a little more effort.
revmoo 9y ago
I've never understood these complaints. I _like_ the staging area. I _like_ branching. They've never stood in my way in any form.
andreareina 9y ago
The reflog is an invaluable feature, I'm glad that I learned about it right when I started learning how to use git. Knowing that there's little I can do to permanently mess things up has given me the confidence to just try things out, speeding up my learning tremendously. I agree that the default git porcelain leaves something to be desired. Personally I use and absolutely love magit, slightly tweaked to give me the defaults I want. The staging area is one of the things that magit really improves on; you retain all its power while making it very cheap to use -- one keystroke to stage the selected file, or all modified files. I stage individual hunks à la `git add --patch` a lot, and sometimes need to include only part of the hunk I'm presented with. It wasn't uncommon for my editing the diff to result in an error with the git cli, now I select the lines I need and just stage those. And if you really don't want to use it, `--all` is easily set as a default for committing.
zanchey 9y ago
This article can be summarised as: 1. Cache invalidation 2. Naming of things They seem like straightforward problems.
- rntz 9y ago
  Could you elaborate for those of you who don't quite understand? I understand the reference, but is there more to this comment than a joke?
  - zanchey 9y ago
    Sadly not.
saulrh 9y ago
A lot of this I can't really speak to, and for some things I can see the point - I use stashes to follow almost exactly the no-staging-area workflow - but in other places this suffers at least a little from being a generalization from one example. In particular, named branches significantly reduce friction in my day-to-day work. I often have PRs for multiple smallish tickets in flight simultaneously, working on the code for each ticket while I wait for review on the others. This means that branches generally live for about eight hours and I care about maybe three of them at any given time, a different set every day. Invocations are stable, named refs fit in cache and my CLI does fuzzy LRU to improve that further, and I can bounce to the current code for a given ticket/PR at almost the speed of thought. By contrast, the "view the log and copy-paste a hash" workflow makes me cringe - I have to inspect the log every time I want to bounce to the code for a PR, and the invocation to go to a PR changes four times a day? I agree that that that makes sense if you have thirty long-running PRs open at any given time and you don't have brainpower to remember branches anyway, and that's very reasonable for a big open-source project, but that's not all use cases.
camgunz 9y ago
I find the Git UI discussion the least interesting part of Git discussions. Git's UI isn't great, but it usually doesn't matter because 90% of what you're doing is what you always did with Subversion and Hg. The commands are a little more obtuse but that doesn't matter either. I really like Gregory's discussion about nameless workflows. For small side projects I use Git on a personal server and I don't care to name every change or even use branches. I essentially just want my work sync'd remotely and maybe -- maybe -- I'll look at the history, but almost never. I used to use tar/scp for this before I got worried about overwriting local/remote changes. I use Git for this now and guess what, my commits are all '.'. I blatantly don't care, and some commits I'm rewriting the entire source tree in a day (like I said, small side projects) so the message would be "Old version sucked, rewrote" and there would be 20 of them. Mostly this is because I don't care to waste my brain power on managing my changes. That's what I'm using a VCS for. They don't need summaries -- that's what diffs are for -- and they certainly don't need names. Gregory's argument against forks makes sense to me too. Semantically a fork doesn't really sync back up with the main branch; if it does it's pretty rare -- or just look at the terminology here: branch, root, trunk... FORK. Fork doesn't really go there.
phasmantistes 9y ago
While I appreciate and agree with the last section regarding replacing GitHub's "fork" model with something lighter-weight, it amuses and saddens me that the author puts a lot of effort into describing something that they feel is wholly novel... but is actually just the model already implemented by Gerrit (https://www.gerritcodereview.com/ https://www.gerritcodereview.com/). There are alternatives to GitHub already! Some do things better than GitHub already! Give it a shot.
cryptonector 9y ago
I find this depressing. I do think the git model is superior to Mercurial's, by far. I also find the git commands much, much easier to use than Mercurial's, unless I stop caring about having meaningful commits. With Mercurial I end up just committing lots of work in one go, with minimal logical splitting, and that's that. The Mercurial repos I share with others are full of useless (to me) merge commits because no one can bother rebasing as rebasing is not as easy on Mercurial. With git I can spend the effort of making clean, logical commits and rebasing so that no one need see pointless internal-to-my-way-of-working commits. I can do this because git does not hide its internals from me. I know git is a pile of anonymous commits that form trees, with branches and tags as symbolic names that resolve to specific commits in the pile. See https://news.ycombinator.com/item?id=15910094 https://news.ycombinator.com/item?id=15910094 in this same thread for more on how the git model is natural.

391 points by jordigh 9y ago

qznc 9y ago

Wow, usually criticism of git is attacking strawmen. This one is actually reasonable and I agree with it.

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

lifthrasiir 9y ago
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.
- gmueckl 9y ago
  The speed of Subversion depends heavily on the hardware involved. On an underpowered server and/or over a WAN/internet connection it will be slow. On a fast server in a good LAN it is so fast that the speed difference to git or hg does not matter in practice: you will spend more time entering commands than waiting for the tool to process them.
stephenr 9y ago
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)
influx 9y ago
Git is over complicated for most people’s use cases, but I wouldn’t give up the fast branching and the rebasing features.
- BurningFrog 9y ago
  GIt is only as complicated as you make it. You don't have to use all the features :)
  - qznc 9y ago
    No. That would be like handing a professional compound bow [0] to a newbie instead of a simple one [1]. The note "only as complicated as you make it" would be quite sarcastic in this case. [0] https://outdoorsexperienceonline.files.wordpress.com/2013/07/pse-compound-bows.jpg https://outdoorsexperienceonline.files.wordpress.com/2013/07... [1] https://www.archery360.com/wp-content/uploads/2016/05/traditional-bows.jpg https://www.archery360.com/wp-content/uploads/2016/05/tradit...
- thomasahle 9y ago
  Apparently SVN has something like that now.
TorKlingberg 9y ago
I have do work with svn quite a lot. It's simpler that git in some ways, but things like merging branches just does not work at all.
- bluetwo 9y ago
  Yes, I've seen that pain, but my workflow rarely needs branch merging, so I've avoided that issue.
GordonS 9y ago
I do like SVN, and have used it for more than 10 years. It's simple, and I like simple. But... I do seem to get a lot of annoying conflicts that require resolution though. Git just works, though does having a bigger learning curve

waterphone 9y ago

Reading this article is harder than learning how to use git the way it's intended to be used.

gear54rus 9y ago

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

grey-area 9y ago
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.
y7 9y ago
You can use Git for things other than open source software development.
rbehrends 9y ago
> 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)? The problem that Greg is referring to here is that `git commit` (as for many other version control systems) overloads two distinct operations: checkpointing your work and creating a new revision. Forcing you to provide messages for the former use case can even be counterproductive [1]. Contrast this with, say, Smalltalk's ENVY: saving a method automatically versioned the method (without the need of providing any other metadata), but you could also separately create system snapshots as named versions. Common Git usage is to squash checkpoint commits, anyway, with individual commit messages often disappearing in the process. [1] https://xkcd.com/1296/ https://xkcd.com/1296/

arunc 9y ago

The 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 <remote-url>` would remove the need for any of these and help me keep my simple histedit, strip, push loop intact!

gmueckl 9y ago
Could that be added as an extension? I don't know how extensions can work with remotes.
rbehrends 9y ago
1. The problem with `hg strip` is how it is (and has to be) implemented, because of the revlog format. Basically, revlogs store changesets in chronological order. Stripping a branch means first saving all commits that are not being stripped (but occur chronologically after the first stripped commit) to a bundle, then truncating the revlog before the first stripped commit, then restoring the commits from the bundle. This can already be an expensive operation locally, but it's even more of a problem on a server shared by multiple users who may have been pushing their own commits. 2. The general recommendation would be to use `hg prune` (part of the evolve extension) instead. Pruning commits will just hide the pruned commits and pushing will then send the obsolescence markers for those commits to the server, hiding them there, too. This is an append-only operation, so it's cheap and works well even with multiple users. 3. In general, though, it is a problem that Git and Mercurial treat remote branches/repositories as second class citizens. This is something that Bazaar got right: Bazaar abstracts over the storage, so (except where limited by network performance) you can do pretty much anything on a remote branch/repo that you can do locally.

nurettin 9y ago

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

jononor 9y ago
Automatically adding untracked files would make it extremely easy to commit (and without other safeguards, push) unwanted changes. Annoying things like node_modules or binary screenshots that now bloats the repo history forever (unless one rewrites the history), or potential security breaches like passwords/keys or logs/configs with confidential information.
- nurettin 9y ago
  Then there is .gitignore_global for your node_modules/
GordonS 9y ago
I seem to recall that Visual Studio Could has an option to immediately push all your commits to remote, bypassing staging. I kind of like staging tho; I find it helps keep me focused on small, self-contained pieces of work, instead of working on several pieces at once.
forgottenpass 9y ago
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. Maximally practical or not, if you don't already have a repository for configuration files, shell scripts, aliases, and other little quality of life enhancements then create one today. Your git workflow isn't the only thing that will benefit. Next time you're hassled to do yet another "git config --global user.name" compare it to the hypothetical overhead of typing "git clone foo/homedir.git ~/homedir && ~/homedir/prep" to get both your name and aliases setup. I never thought I needed a dotfile repo, but once I made it I realized I waited way too long. It doesn't have to be anything fancy, just take 10 minutes and lay the groundwork to help yourself develop more quickly.

klodolph 9y ago

It's clear that there will be a successor to Git some day, in the sense that Git is a successor to SVN (yes, I know Linus's viewpoints on SVN). But the successor won't be a "better Git" just like Git isn't a "better SVN". The driving features of Git's successor will be unrelated to Git UI gripes. If Git's UI gripes were important enough, people would just be using Mercurial (which has it's own quirks). The biggest problems I've personally seen with Git are the same problems you see with other VCS, where two people change the same file, and one commits the changes first. Now you have to merge the changes and sometimes it's a pain in the ass when you just want to submit your changes and go home. A better VCS isn't going to solve that! I'm still glad that Git delivered me from all the merging problems that SVN had, although I've heard that SVN is a little better these days.

posterboy 9y ago
you could work in branches and merge after feature freeze, or you could, you know, colaborate and communicate intent before beginning to edit.
arunc 9y ago
Personally, the problems I have with git are related to the fact that none of my coworkers use git. If I mess up my repo I don't have anyone to look for. The experience with mercurial is exactly the opposite. I never needed to look for "experts" to solve a problem in mercurial. hg help is all I needed. Consistent UX and safe and powerful VCS is all we need.
- pritambaral 9y ago
  > I never needed to look for "experts" to solve a problem in mercurial. hg help is all I needed. Git has good documentation too. As long as we're doing personal experience, here's mine: I learned git from `git help` too (well, `git --help` and `git <command> --help`), and I never needed to look for a git expert in my team for advanced operations; I did have to be one for others quite a few times , but when it wasn't an immediate, pressing concern I could just point to the appropriate manual.

gumby 9y ago

I'm surprisedly the staging-area hate. Does it really violate peoples' assumptions? I like the ability to make a big, complex change and checkpoint stable portions (subsets) of the work as I go.

CJefferson 9y ago
My problem with the staging area is it produces commits which never "exist" (that is, that code was probably never compiled/tested in isolation). I'd be happier if the staging area was handled at the filesystem level, give me a directory which at all times contains the staging area, so I can test it.
- jononor 9y ago
  Your CI system can test those commits in isolation. I frequently push supposed-to-be-stable commits like that alone to my working branch on Github, so Travis CI can tell me if I have a problem. Though I'm quite picky about commits, that each merge point into mainline (master) is tested is what is most important to me. Github PRs with Travis CI for instance enforce that pretty OK. If I don't bother to do a PR, and the changes as a linear set upon master, I like to use git merge --no-ff master to force a merge commit.
maxxxxx 9y ago
To me staging is the best part of git. I don't want to commit all the time so I slowly stage changes that I think are OK. Once the feature is done I can do a full commit. Perfect!
- spiznnx 9y ago
  The author purports that this can be achieved without staging. For example, you could slowly commit small changes that you think are ok on a work-in-progress feature branch with `git commit -p --allow-empty-message`. When you are done you could squash rebase + message rewrite. While currently this workflow is clunky, it could be made to work with the same nice semantics of your workflow, and not have a staging area at all.

milofeynman 9y ago

This may be sacrilege on here, but at my previous job I really enjoyed TFS. It's been awhile but the workflow felt a little more intuitive than git. And some of the merging features were nicer.

maxxxxx 9y ago
I used to work with TFS but after working with git I can't stand it anymore. But it shows that people have different tastes.
- kylemuir 9y ago
  Strongly echo this sentiment. Last time I used TFS was probably in 2011 so things might have changed significantly since then but off the top of my head things I use to hate but now don't need to worry about since using git over TFS: - Offline? Looks like you'll have to wait to make that change or any other change for that matter since you can't check out files if you're offline. When doing remote work this use to do my head in. - TFS On Premise putting readonly locks on every file you have. Why? Great question. Made writing build scripts and their ilk much harder to accomplish. - Want to make a branch? That'll be an entire copy of the source code times however many branches you want
  - maxxxxx 9y ago
    Add to that detection of new files or deletions outside of visual studio. This is so easy in git and a real problem in TFS.
GordonS 9y ago
I've worked with TFS and SVN for more than 10 years, and Git for maybe 5. I find TFS the slowest of the lot, by quite a large margin.
Chromozon 9y ago
TFS is great if everything in your codebase is a Visual Studio project. If you are trying to use it for other things, there are better version control systems out there. My ranking is Perforce > Git > TFS > SVN. I haven't used Mercurial. I like Perforce the best because of its clean UI, its explicit checkout mechanism (all files are read-only by default, and you have to check out anything before you can edit), the integration tool GUI, and the ability to cloud-save work without submitting it. TFS is nice because it has built-in code review, but the UI isn't nearly as clean as Perforce.

phillco 9y ago

Anecdotally, being able to commit anywhere, without needing a branch name, is one of the biggest conceptual differences when we teach new hires Mercurial at Facebook.

nhaehnle 9y ago
As a convinced Git user, this is the one aspect of the article that I found genuinely interesting. I mean, you can commit anywhere in Git, too (and I occasionally do for some advanced use cases), but it tends to not be well supported by Git. (And, I might add, probably not by Hg either if it requires enabling an extension...) Anyway, hg show work looks like an interesting thing. It's perhaps a bit more magic than Git usually goes for, since you can't just show all DAG sinks (it would get messy really quickly with amends and rebases). And I don't think I'd benefit too much from it, since I've come to prefer having all my work-in-progress on a single branch. But I can see how someone could appreciate the feature.
- rbehrends 9y ago
  > As a convinced Git user, this is the one aspect of the article that I found genuinely interesting. I mean, you can commit anywhere in Git, too (and I occasionally do for some advanced use cases), but it tends to not be well supported by Git. "Not well supported" in this context means that you can lose data (as commits that are not reachable from a ref can be garbage collected). Mind you, you have to ignore warnings/errors to get there, but without ignoring them, you also won't be able to actually have anonymous branches. > (And, I might add, probably not by Hg either if it requires enabling an extension...) It does not require an extension. The `show` extension that Greg talks about is a smart log display, which shows a contextual log for your current work. Anonymous branches have been part of Mercurial from the beginning, long before the `show` extension existed. For what it's worth, it's not so much that Mercurial supports it, but that Git doesn't. Git is rather unique in its setup in this regard. No other VCS that I know of uses garbage collection and in particular branches to prevent revisions from being garbage collected. (Some may require you to name branches for other reasons, but not so you don't lose commits.) It's probably also worth noting that we have an implementation detail leaking into user space here. Git uses what is essentially purely functional data structures underneath to achieve atomicity in the absence of an actual database engine [1]; a different implementation, such as on top of SQLite, could avoid this. [1] Atomicity here is not about locking, but about a transaction being interrupted by the user or an external event, such as a shutdown.

sharp11 9y ago

Lots of food for thought in this article, but the part I find most interesting is his distinction between "soft" and "hard" forks. (Viz., are you "forking" in order to collaborate or in order to go your own way?) If collaborate, it would be nice to lower the barrier to participation ... more like Wikipedia. I know that I often don't bother to submit a PR for small changes bc of the overhead of setup. Whereas I fairly often make small edits to Wikipedia changes, because it's so easy.

ygra 9y ago
GitHub at least has a simple way of making small changes: You can simply click 'Edit' on any file, which will make a fork, commit and pull request in one operation. It's only good for single-file changes you're confident to make in a simple web text editor, though. I've only used it for typos.
- majewsky 9y ago
  I don't like that doing so frequently litters your personal repository list with forks. Would be nicer if they allowed arbitrary users to push to branches like `incoming/<username>/<branchname>` in the original repo.
  - ygra 9y ago
    Isn't that up to the repository maintainer whether they allow pushes from other people? And sure, it litters your list with forks, but you can remove them as soon as the PR is merged. And that's the case for pretty much anything you contribute to (unless you can push there, of course).
    - majewsky 9y ago
      No, there is no process in Github to allow everyone to push to a certain branch (or branches matching some regex). Github forces people without collaborator rights to use forks. I've seen this lead to confusion where people fork a repo and send PRs even though they have contributor rights, because they didn't understand the difference. As an extreme example: https://github.com/flystack/misty/pull/101 https://github.com/flystack/misty/pull/101 - This is a repo with only one person with write access [1]. Yet this same person only commits to their private fork of this repo and sends himself PRs that he then immediately merges. I don't mean to blame the developer, only the Github UX. [1] It says "6 contributors" on the mainpage of the repo, but four of these are from my team and we definitely don't have write access.

taeric 9y ago

If you requested save in your favorite GUI application, text editor, etc and it popped open a select the changes you would like to save dialog, you would rightly think just save all my changes already, dammit I'm sympathetic to what this is asking, but I have to feel that this would lead to much better practices for many people. I'd wager a ton of folks would be more "why in the world does it think I changed that?" than they would care to acknowledge. That is, by and large, the quick sanity check of "these are the things you did?" is actually quite valuable. Regardless of any annoyance it may give. Similar to the "did you mean to print all 500 pages?" warning you can get if you print something huge. Sometimes, yes. Yes I did. Often times, no, not what I intended.

jcranmer 9y ago
In my experience, the benefit you get is from giving you an editor to edit the commit message, which has a list of files changed, and can be cancelled in some way to abort the commit. Both hg and git can do this, so it's not necessary to have a separate command and staging area just to do it.
- icebraining 9y ago
  List of files is not enough, I always do 'git add -p' to see the actual changes. And sometimes I detect an error, and I want to fix it and then keep going without having to re-evaluate the changes I had already seen.
  - MaxBarraclough 9y ago
    My preference is for `git commit --verbose`, which shows all changes in a 'commented-out' section of the commit message file.
  - ryanbrunner 9y ago
    The authour of this article suggests a solution - `git commit --interactive` could prompt you for each change like `git add -p` does without needing a staging error. You're right though that it would take some cleverness in that command to allow you to fix a typo without restarting the operation.

jonthepirate 9y ago

In practice I have found the biggest missing feature that I wish existed is the ability to pull a single file from a known ref on a remote server. For example, give me the Dockerfile located in the root of the master branch tip. Can't do that. Instead, you have to clone the entire repo first.

drchickensalad 9y ago
Well you can clone with --depth=1, so performance wise it's not too bad at all, but yeah still gets all the other latest files.

jcranmer 9y ago

One personal anecdote: In a decade of using Mercurial, I've managed to get a repository in such a confused state that I had to blow it up and start from scratch just once. In the same time, I've had to do the same for git repositories at least 5 or 6 times--and I never really used git all that much. Even nowadays, where I'm more or less forcing myself to use git [1], I'm incredibly hesitant to try any sort of complex git operation because of the risk that I might lose my in-progress commits. While the problems of git's UI is well-known, I don't think it's as appreciated that git's complexity generally discourages people from trying things out. I'm never really sure what could cause me to lose unpushed commits or uncommitted working files, especially with git's predilection for reusing the same verb to do slightly different operations for different concepts. In stark contrast, it's more difficult to get Mercurial to chew up your work without telling you [2], and it's easier to explore the command lists to see if there's something that can do what you want it to do. [1] The repositories I'm working on involve submodules, which hg-git is exceptionally poor at supporting well. Even so, the list of git alias commands on the whiteboard is entitled "Forcing myself to use git before I rage-quit and switch to Mercurial." [2] I have done it, though. Worst offender was discovering that hg qrefresh <list of files> causes only those file changes to be committed, and files not mentioned are decommited to working-directory-only changes... which hg qpop happily deleted without warning me, causing me to lose a large patch. That was when I put the patch queue directory in version control.

shaan7 9y ago
Just keep a copy of the `.git` dir before you try the complex operation. If you screw it up, restore it back and voila!
- sigjuice 9y ago
  No. This does not safeguard any uncommitted files.
  - nicoburns 9y ago
    Leaving any files uncommitted before a complex operation in git is a really bad idea (make a temporary commit if necessary). It's almost impossible to completely lose committed data, but pretty easy to destroy uncommitted data.

Smith_seth 9y ago

I GOT MY PROGRAMMED BLANK ATM CARD TO WITHDRAW A MAXIMUM OF $5000 DAILY. I AM SO EXCITED BECAUSE I ORDERED AND PAID FOR DELIVERY, DIDN'T GET SCAMMED, AND I NOW OWN MY HOME, MY BUSINESS HAS GROWN BIGGER. GEORG BEDNORZ (georgbednorzhackers@gmail.com) IS THE NAME OF THIS USA HACKER THAT GAVE ME THE CARD AND ALSO HE IS OFFERING ALL KINDS OF LOAN WITH ONLY 2% INTEREST RATE.

blux 9y ago

The Git staging area doesn't have to be this complicated. A re-branding away from index to staging area would go a long way. Adding an alias from git diff --staged to git diff --cached and removing references to the cache from common user commands would make a lot of sense and reduce end-user confusion. --staged is already an alias for --cached in the latest Git version.

BlackFingolfin 9y ago
And it has been for some time (years, I think)
- majewsky 9y ago
  Years, yes. At least since 2.0, though probably longer.

yeukhon 9y ago

Here are the commands I use: git init git clone git checkout git commit git commit -m git commit —amend git rebase git add/rm/diff [—cached] git push git branch and a few more I can’t remember exactly. I try to keep my git workflow simple. The most complex is probably checkout abd rebase with several different branches.

emj 9y ago
You are already using ammend and rebase, you can do plenty of complex and hairy stuff with that, especially as a team. I'm also guessing you use merge and log at times. FWIW this is my philosphy with git too, but have you not experienced the points he brings up? I was nodding my head at all of them; branches are time-consuming, staging is problematic and forks are a bad analogy. The recent post and hype about the Facebook, Google and Microsoft monorepos should make us ask the question what our systems for source control is supposed to do really. save changes to a source code save changes to big binary assets annotate those changes annotate the files themselves tagging versions signing of code code review handle regressions testing collaborating (ACL, DCVS, official monkey patching etc) merging search on the whole code base refactoring on large code bases All these things have uses but they are not really supposed to be tied to one VCS, we have very basic needs when working with source code streamlining the UX for that workflow might be more important and in the same time opening up for easy access to the other stuff.
saltedmd5 9y ago
"I try to keep my git workflow simple," and yet I see 'git rebase' but no 'git merge' in that list.
- zegl 9y ago
  `rebase` is simpler than `merge` in larger teams/projects, as the history will be much cleaner.
  - saltedmd5 9y ago
    Rebase is not simpler in any context - rebase rewrites history, which, if branches have been pushed to remotes, then necessitates force pushes, which in turn breaks any other instances of the same branch. By using rebase to "keep history clean" you are largely undermining git's power as a DVCS. Rebase as a tool is not inherently bad but it is definitely not simpler than merge - it introduces additional considerations, requires a deeper understanding of git for effective use and is a dangerous tool in the hands of people who do not understand what it is doing and in my experience most teams that are using it as a core part of their workflow are doing so for the wrong reasons (generally because of a fundamental misunderstanding of how branching and merging works in git and why it works that way).

Sujan 9y ago

Workspaces please, now. That would be so much nicer than the current need to fork.

beagle3 9y ago
Are you familiar with the 'git worktree' command? It's rather new, and it might be what you are after.

dmitriid 9y ago

One of the main problems I still face is: Git's CLI is incomprehensible. It's a tangled mess of poorly named commands with even more poorly named options. If there's a "create" command, it's "modify" counterpart is likely to be "create -b -u -t --modify", and it's "delete" counterpart is likely to not exist at all or be an arcane incantation of several non-related commands and a push. Unfortunately, most GUI tools are just thin wrappers on top of all this mess (with the possible exception of GitUp whose abstractions are also paper-thing at times)

hyperion2010 9y ago

While many of these criticisms are valid, they seem to be written from the point of view of a user that doesn't really want control over their versions, they just want versions. I'd suggest that there are other tools for this, such as a properly configured ZFS setup which are atomic beyond most users widest dreams (especially if all the versions of a vim .swp file are retained). If you just want versions, yes, git gets in your way, because git is about control. Yes if you have all those versions you could go back and 'squash' them into a commit, but can you imagine trying to bisect those to find a bug?! Somehow I also get the feeling that this perspective is similar to that of a friend who really didn't like the idea of pulling, and that he should just be able to push to the remote repository. A seeming lack of awareness of the collaborative side of version control and development. Git isn't just about control, it is also about providing additional provenance information and context needed in order to understand what code does and the reasons why changes were made. Sometimes in order to get there we have a bunch of low intention commits that we use to checkpoint, and let's be honest, how many have created commits that put a tree in a broken state? I know I have. The bit about making the documentation more consistent in its use of vocabulary seems like something that will have a couple of pull requests by the morning. tl;dr If you want versions use ZFS if you want control and communication use git. Talking defaults is always a good exercise. with and EDIT: show work would be amazing ... edit2: I just don't see the workspaces model passing the bag of dicks test. I want to code, I don't want to have to become a community moderator and clean up people committing all sorts of crap to my project and on the other side I just wan't to code and not have to deal with the bags of dicks who are going to gate keep their projects. There are just too many social edge cases and the differences are mostly just semantic (iirc the way github implements forks is basically as workspaces anyway...). That said, I would really like it to be possible to have pull requests be part of the repo history instead of, say, the listserv.

chrisan 9y ago
Well said. > Most people see version control as an obstacle standing in the way of accomplishing some other task. They just want to save their progress towards some goal. In other words, they want version control to be a save file feature in their workflow. That was horrifying to me. We _religiously_ have a JIRA-XXX tag in our commits so that every commit has some kind of perspective in addition to the comment. This has been extremely useful in getting more context of why something was changed when dealing with a long lived project spanning multiple developers. Even if the commit message itself is weak or lazy we still have the user story in JIRA to get full context.

deleted 9y ago

[deleted]

Grue3 9y ago

Git staging area is nothing compared to Mercurial's branch/bookmark ridiculousness. And the need to use plugins for things that Git trivially supports out of the box.

cannam 9y ago

This is a really interesting piece that introduced a number of ideas I hadn't ever thought deeply about, particularly in the section on nameless workflow. (I do think of myself as reasonably capable with both Mercurial and Git.) If your instinctive response is to defend Git, boost Mercurial, ridicule people who can't use their tools, ridicule the tools for being unusable, or whatever -- suppress it for a while and give this article some thoughtful attention.

cryptonector 9y ago
My instinctive response is to explain why git is easier. TFA is very unfortunate. I think the author is missing out on a better experience, and their git hate isn't helping them.
- Sheeriapi 9y ago
  Let me suggest to suppress that instinct and read the article again. There's not a shred of "git hate". Quite the contrary: The author is a Git user himself and has detailed suggestions to improve Git and its ecosystem. That is a good thing, not "very unfortunate". Also, Git is easier than what exactly? Than the proposed improvements? I suspect you haven't read the article. This is neither a "Mercurial vs Git" nor a "Git sucks" piece, which you should have noticed while reading.

giomasce 9y ago

The thing I love of git is that its internal structure is very simple and transparent, so for any given repository it is possible (although not necessarily easy, if things are well messed-up) to understand what is going on. It is true that the interface is often messy and inconsistent, sometimes annoyingly so, but if I can understand what things are, I can somehow work out how to do things with them (in extremal situations, I know I can fast-export everything, process with custom Python scripts, rather easy to write, and fast-import again). While if I do not understand what things are, the most powerful and user-friendly tool will have very little value to me. Also, knowing what is git under the hood makes me very confident that I will not lose pieces: as soon as the hash of my interesting commits is in another repository (which is not corrupted), I can do whatever I want with the first one and everything I care will be safe anyway. All of this depends on me knowing what happens inside git and the git insides being rather simple (a hash tree with a handful of object types); I think I would like Mercurial (or any other DVCS) much more if I knew the same about it: can someone suggest places where this is described?

bluGill 9y ago
As a long time mercurial user being forced to switch to git I find that I know more about git internals than mercurial. Mercurial provides a nice abstraction so I don't have to care. In face I've seen a few hints that mercurial has actually changed their internals over the years, but since everything still "just works" I don't think about it. By contrast git is forcing me to care even though I have better things to do with my time. Sadly github and CI systems provide community tools around git not mercurial (mercurial is an afterthought at best in most CI systems). Those community tools are compelling enough that I'm switching to an inferior system just to get them.

Philipp__ 9y ago

I was holding to that famous UNIX mentality for many years, since I started programming almost... Use many programs that do one single thing, pipe the data, print it on the main output etc etc. That’s how I used git too, writing 160 chars wide commands... I tried playing with Emacs year and a half ago, and it was big cultural shock, for first year of using it I still couldn’t adopt kitchensink philosophy. But after barely scratching what emacs had to offer I went back to my unix terminal workflow it felt clunkier than ever. Takeaway from this story can be Magit. It totally changed my perception of git, and felt like more robust and semantically better way to use/understand git. Maybe it was like that because of few years of terminal git usage, don’t know how will complete beginner react to magit. But what shocked me the most was how my approach to git changed with dofferent interface. GUIs never appealed to me, but magit represented the middle ground of GUI like functionality with terminal like interface that got many things semantically right.

globuous 9y ago
<edit> TD;DR: Magit is a lesson of UX. </edit> +1 for Magit. When I discovered it is when I discovered git. I assume tig must be similar although I've never looked into it but... With magit, from my editor, I can easily check: my git status, choose which hunks to stage or unstage, commit easily. I can switch branches with less than 10 keystrokes. etc. But to me, what's coolest about it is that I can easily see commit histories and graps for branches, files, and the repo. With less than 5 keystrokes. And I can navigate these histories easily. Finally !!! Same story for pushing, pulling, merging, rebasing. Which all of this you can do in CLI obviously. But Magit makes it easy, and because now I have everything I need with regards to git just a few keystrokes away, I can interact with git easily. So I do it.
- masklinn 9y ago
  My only beef with magit is that it's really slow for nontrivial projects ($dayjob's main codebase is 1MLOC and has ~110000 commits reachable from HEAD, "status" takes a good 5s, and adding/removing stuff from d/u or d/s quickly gets painful).
- dbdr 9y ago

yoodenvranx 9y ago

In the beginning I tried to use git exclusively through command line because I thought that's how real men do it. But after using gitkraken (or similar products) I will never go back to using git through its command line interface. Being able to see the whole repo structure is just so much more convenient and it helps to resolve most merging problems much faster. git guis all have their own problems, but overall using a git gui for me is the better choice in 95% of all use cases.

michaelgrafl 9y ago
I always have both open. Gitkraken for having a broad overview of local and remote branches, stashes, and for staging chunks of code. And the command line for everything else. Some things just confuse me in any GUI Frontend or don't work as fast as on the CLI.
- cbcoutinho 9y ago
  This is what I do too. I like looking at my entire staging area commits using the CLI, but merging makes much more sense using GitKraken. Version control is just too complicated of a problem (for me) to reason about in one 'view', and using different tools to look at separate scales of a repository is the way I've found to work through that difficulty.
bauerd 9y ago
First time I hear of gitkraken but why would a Git repository viewer have me create an account!?
jononor 9y ago
Yeah being able to see what you do is critical for understanding and feeling comfortable. I do everything via "git", but always have "gitk" open for that visual overview. gitk is very basic and not that great, but does the trick.

deleted 9y ago

[deleted]

tomxor 9y ago

I like what this guy has to say so far, but it's a bit surprising that someone with his knowledge got this wrong: > The Git staging area doesn't have to be this complicated. A re-branding away from index to staging area would go a long way. Adding an alias from git diff --staged to git diff --cached I dislike the mess of crappy synonyms too, but git diff --staged is already an alias, in fact it's the primary way I diff the staging area because it's a well fitting synonym.

masklinn 9y ago
> I dislike the mess of crappy synonyms too, but git diff --staged is already an alias Problematically it's very little used, it's only mentioned once at the very tail end of the `—cached` description, `--cached` is still the primary flag, and the essay remains correct that references throughout the documentation are inconsistent. It's not exactly hard to miss, if e.g. you learn git through the Pro Git book, the option is not mentioned once, and even the full text search has not indexed it. Furthermore, there are many other commands which take a —cached flag but don't have a —staged alias (diff-index, submodule, check-attr, apply, rm)
dwheeler 9y ago
One small improvement would to make sure that all the options with "--cached" also have "--staged", and make sure that all the documentation uses term "staging" (deprecating "index" and "cached"). The git UI is historically terrible, but it's gotten a little better over time... it could definitely be improved further with a little more effort.

revmoo 9y ago

I've never understood these complaints. I _like_ the staging area. I _like_ branching. They've never stood in my way in any form.

andreareina 9y ago

The reflog is an invaluable feature, I'm glad that I learned about it right when I started learning how to use git. Knowing that there's little I can do to permanently mess things up has given me the confidence to just try things out, speeding up my learning tremendously. I agree that the default git porcelain leaves something to be desired. Personally I use and absolutely love magit, slightly tweaked to give me the defaults I want. The staging area is one of the things that magit really improves on; you retain all its power while making it very cheap to use -- one keystroke to stage the selected file, or all modified files. I stage individual hunks à la `git add --patch` a lot, and sometimes need to include only part of the hunk I'm presented with. It wasn't uncommon for my editing the diff to result in an error with the git cli, now I select the lines I need and just stage those. And if you really don't want to use it, `--all` is easily set as a default for committing.

zanchey 9y ago

This article can be summarised as: 1. Cache invalidation 2. Naming of things They seem like straightforward problems.

rntz 9y ago
Could you elaborate for those of you who don't quite understand? I understand the reference, but is there more to this comment than a joke?
- zanchey 9y ago
  Sadly not.

saulrh 9y ago

A lot of this I can't really speak to, and for some things I can see the point - I use stashes to follow almost exactly the no-staging-area workflow - but in other places this suffers at least a little from being a generalization from one example. In particular, named branches significantly reduce friction in my day-to-day work. I often have PRs for multiple smallish tickets in flight simultaneously, working on the code for each ticket while I wait for review on the others. This means that branches generally live for about eight hours and I care about maybe three of them at any given time, a different set every day. Invocations are stable, named refs fit in cache and my CLI does fuzzy LRU to improve that further, and I can bounce to the current code for a given ticket/PR at almost the speed of thought. By contrast, the "view the log and copy-paste a hash" workflow makes me cringe - I have to inspect the log every time I want to bounce to the code for a PR, and the invocation to go to a PR changes four times a day? I agree that that that makes sense if you have thirty long-running PRs open at any given time and you don't have brainpower to remember branches anyway, and that's very reasonable for a big open-source project, but that's not all use cases.

camgunz 9y ago

I find the Git UI discussion the least interesting part of Git discussions. Git's UI isn't great, but it usually doesn't matter because 90% of what you're doing is what you always did with Subversion and Hg. The commands are a little more obtuse but that doesn't matter either. I really like Gregory's discussion about nameless workflows. For small side projects I use Git on a personal server and I don't care to name every change or even use branches. I essentially just want my work sync'd remotely and maybe -- maybe -- I'll look at the history, but almost never. I used to use tar/scp for this before I got worried about overwriting local/remote changes. I use Git for this now and guess what, my commits are all '.'. I blatantly don't care, and some commits I'm rewriting the entire source tree in a day (like I said, small side projects) so the message would be "Old version sucked, rewrote" and there would be 20 of them. Mostly this is because I don't care to waste my brain power on managing my changes. That's what I'm using a VCS for. They don't need summaries -- that's what diffs are for -- and they certainly don't need names. Gregory's argument against forks makes sense to me too. Semantically a fork doesn't really sync back up with the main branch; if it does it's pretty rare -- or just look at the terminology here: branch, root, trunk... FORK. Fork doesn't really go there.

phasmantistes 9y ago

While I appreciate and agree with the last section regarding replacing GitHub's "fork" model with something lighter-weight, it amuses and saddens me that the author puts a lot of effort into describing something that they feel is wholly novel... but is actually just the model already implemented by Gerrit (https://www.gerritcodereview.com/ https://www.gerritcodereview.com/). There are alternatives to GitHub already! Some do things better than GitHub already! Give it a shot.

cryptonector 9y ago

I find this depressing. I do think the git model is superior to Mercurial's, by far. I also find the git commands much, much easier to use than Mercurial's, unless I stop caring about having meaningful commits. With Mercurial I end up just committing lots of work in one go, with minimal logical splitting, and that's that. The Mercurial repos I share with others are full of useless (to me) merge commits because no one can bother rebasing as rebasing is not as easy on Mercurial. With git I can spend the effort of making clean, logical commits and rebasing so that no one need see pointless internal-to-my-way-of-working commits. I can do this because git does not hide its internals from me. I know git is a pile of anonymous commits that form trees, with branches and tags as symbolic names that resolve to specific commits in the pile. See https://news.ycombinator.com/item?id=15910094 https://news.ycombinator.com/item?id=15910094 in this same thread for more on how the git model is natural.