question to Git (power)users

I’m slowly switching to Git for my personal projects, and I like it more and more. And it seems that I can only find nice things to read about it.

So, I’m wondering: what are the things that you dislike with Git? That make you regret/prefer another VCS? If Git was redesigned from scratch, what should be changed?

29 thoughts on “question to Git (power)users

  1. I’m no Git power user. I think I’m in the same position as you, loving it immensely. Mainly just commenting so I can subscribe to comments via email ;)

  2. Salut Lucas,

    I am switching as well, and I miss the partial checkouts from SVN. I use git at work to store big (100 Mo – 10 Go) data files that are occasionally regenerated with updated scripts or reference data, and sometimes my colleagues would only need just a subset of them.

    Sometimes some big text files have just a few modifications after refreshing, and in that case I find git add, commit, and diff efficient, but some other times they are quite shuffle and git does not give up trying to make a nice delta. The computation can be longer than overnight on a machine with 128 GiB RAM and 16 Xeon processors. The problem being that I do not know before doing git diff whether the changes are enormous or not…

    Have a nice day,


  3. I’d like the manpages reorganized to have less of the plumbing exposed and more of the porcelain placed up front. This is really an accident of history though, and easily fixed. I’d also like git commit to have -a by default.

  4. I’ve worked with numerous version control systems, and I currently use Git for everything I can. I even have parts of my home directory in Git. I think I can reasonably call myself a Git power user.

    The major limitations I occasionally run into and wish Git would handle better:

    * Empty directories. Git does not track directories, it only tracks files; directories pop into existence as needed. This works great for a system designed around the handling of patches, which also don’t deal with directories. However, empty directory handling comes up in two contexts: interoperating with other version control systems which do handle them (such as SVN), and attempting to accurately track filesystems for purposes such as backups or replication.

    * Permissions. Beyond the “execute” bit, Git just plain doesn’t handle them.

  5. @David Nusinow: “I’d like the manpages reorganized to have less of the plumbing exposed and more of the porcelain placed up front. This is really an accident of history though, and easily fixed.”

    Agreed entirely.

    “I’d also like git commit to have -a by default.”

    I thought the same thing for a while after using Git, up until I learned and understood the index. Once I realized that I could actually leave multiple changes around and commit them in chunks, I really started to love the default of only committing what you explicitly stage in the index. I also liked the index a lot better once “git add” started handling both new files and changed files, and “git update-index” disappeared into the plumbing.

  6. The only qualm I have at the moment is the few inconsistencies. For example, sometimes it’s –staged and other times it’s –cached.

  7. After giving up trying to use git very quickly and switching to mercurial: the CLI just didn’t appeal to me. I have to know too many details about how git is working internally before the whole logic of the commands makes sense.

    And besides that, an application that needs manual repository maintenance to keep good performance (repacking) doesn’t win my favors easily. (No, I haven’t used to to an extent that this actually was an issue, but just to know that this process is necessary makes ge go all Ugh!-ish)

  8. I don’t like how the support for various remote VCS’ are all different, I’d prefer to git push to an SVN repository rather than git svn dcommit.

  9. I don’t like the fact remote branches are not shown unless you specify -a, and you have to manually set up a tracking local branch out-of-the-box. I don’t like the fact you can push to a non-bare repo, even though you shouldn’t, and when you do, you get a bizarre state where the “checked out” files are different to HEAD (as git diff reports) but git commit will suggest nothing has changed. I don’t like the fact that to create a branch in a remote repo, you need to write “git push origin newbranch” or some-such, which I haven’t yet figured out what that meanas.

    To echo David, the manpages/documentation really need reworking to keep the internals separate from the “friendly” interface.

  10. I guess the only thing that should be changed is the documentation. But, on the other hand, I know all too well how hard it is to write a good documentation. All in all, I am more than happy that the scare resources of the git project are mainly put into making it rock rather than in anything else.

    Git just rocks. People just have to invest in learning it.

  11. I really like git, but Junio’s thoughts about changing some commands names (linked above) make sense. For me, I’m used to git and I understand the commands but it would be beneficial to simplify the push/pull/merge terms and the model. Also something to make it easier to understand tracking/non-tracking remote branches default merges/pulls etc would probably be great.. but otherwise things like the default ‘origin’ remote and such are very sound.

    And, the core git team should try out and use git submodule for themselves, so that it could get some improvement.

  12. Just make it friendly. Maybe it has the repository format of the future, blazingly fast and whatnot. But the interface – even with GOOD docs – is pure masochism in an era when it doesn’t need to to be. The original authors of CVS didn’t know any better. Git has no such excuse.

    Also, I hate that git is the elitist VCS that exposes every detail and does not intergrate with anything. Fine for the kernel, but how the hell are we supposed to get our non-technical friends (graphics, documentation, management, sound, etc) on board on git? That’s an insane proposition. And we do want to have non-elite-programmers on board on many many projects, because it won’t be good without them.

    Subversion caters fantastically to those, but it’s, well, subversion. Bazaar does not – yet – cater as good, but there is steady progress and the thinking goes along these lines. It may be some microseconds slower, but at least it’s usable. Don’t know about hg and darcs and friends, sorry.

    Stop confusing what is technically cool and/or good for a operating system kernel code base with what is a good VCS to actually get things done in real world arbitrary teams that may not all be Linus Torvalds.

  13. @tyrone:
    git has potential in its technical strengths, and it shows incremental improvements, without ever having ripped out and replaced its internals i.e showing a lot of dependability/stability.

    And, git it integrating with git-svn, git-bzr, git-p4 etc.. the git-fast-export format is potentially going to be a canonical dvcs data exchange format.

  14. I want to have a command similar to “darcs put”.

    I have a repository on my laptop, and I would like to clone in on a server on

    I would like to run:

    $ git put

    But it does not exist, so I have to run:

    1. $ ssh
    2. $ cd public_html/git/
    3. $ mkdir myproject
    4. $ git init
    5. $ exit
    6. $ git remote add myserver
    7. $ git push myserver

    What a waste of time!

  15. Only “big” problems we had with git is with git-svn. It seems that having a problem in the middle of a dcommit leaves the WC in a state where the latest commits are missing :) I already had the chance to dig into all dangling commits for the missing ones.
    When starting to play with git-svn, I also had problems when switching branch where I loosed local commits. I’m now very cautious :) (sometimes I simply work on a copy of the tree) (maybe this comes from my lack of knowledge…)

  16. For me, the reason why I chose Mercurial over Git is cos of its cross platform support. If only Git was cross platform(cygwin don’t count!)

  17. Git ui isn’t great. Not being able to refer to versions with decent ids like 1, 2, 3 is a major drawback. The commands are somewhat badly designed: for eg. undoing all changes since my last commit is a commonly used operation for which you would normally expect git revert, but lo, git revert does something else :) – we have to use an obscure command to get what we want. Used to be a git fan, but I use hg now. No gripes with hg yet.

  18. @cmot: read git-gc – repository maintenance happens automatically

    I love Git. Every aspect of it.

    The things that annoy me have to do with additional stuff I want to do:

    – better detached worktree handling
    – tracking of extended attributes, permissions, users, groups, ACLs, if so desired. The tracking of file attributes should be freely extensible

    I’d like to see Git treated more like a filesystem and have other VCS, which properly abstract the complexity. I’d like to keep using git-* though.

  19. @Roopesh: Mercurial doesn’t have “decent ids” as well, or does it?

    My gripes with git are:
    – I don’t like the fact that Git is much slower on Windows.
    – I’ve used SVN for quite some time, and some git commands, such as revert, don’t map to the SVN homonimous ones. I’ve learned that you sometimes have to *forget* what SVN does and focus on Git itself.

  20. i find bazaar just easier to use. bzr commands made sense after the first read of the docs (similar to svn) — not so much w/ git. bzr-svn uses the same commands as regular bzr in a svn directory — no “git svn …” commands. easier to work with incremental revision numbers vs hashes.

  21. @Anonymous “I thought the same thing for a while after using Git, up until I learned and understood the index.”

    I fully understand and use the index in the way you describe, but it really should not be the default. The sane default is to just commit everything that’s changed and tracked if nothing is explicitly added to the index.

  22. I don’t like the gc and repacking stuff, that should be done automatically, I haven’t found yet the way to set it up a bare-repository with LDAP auth support and the thing that just works in UNIX-like (where I work some people use Windows in their personal machines and want that to remain in that way), the rest I love it :)

  23. @João: It does. mercurial too has sha1 codes like git internally, but also has alias integer ids on each rev, so you can do stuff like hg diff -r 42.

  24. Git revs can be specified like “HEAD~1” (one before HEAD) “HEAD~2” (two before HEAD) … etc. This is very much like that behavior.

Comments are closed.