This looks sweet! I use git quite lightly right now as I'm currently the only developer on my project. Gitup.co is the benchmark of Git apps for me right now. I barely need anything more than it and it's so incredibly light feeling. Like the app goes out of the way so that I can do what I need, such as reviewing lines to be staged.
It hasn't been receiving many updates unfortunately. I'm happy that another app has popped up! Looking forward to try it out.
I sort of wondered about that thinking maybe there's only one logical way to design a git GUI on osx, but then even within this thread people brought up a few other examples that look totally different:
I switched from SourceTree to GitKraken, I don't know all the internal issues of what transpired at Atlasian on the SourceTree team, but to me it's just not the same product that the old Mac app was when they where independent.
I really like GitKraken and the team is taking feedback applying it constructively and putting out an impressive product. The part I really like is it's the same app on OSX, Linux and Windows using Electron to build it was a smart move on their part. My favorite feature has to be dropping a branch on another branch to create a pull request. I don't fanboy stuff much these days but I am a pretty big fan of their's right now.
I already got that question today. So, I'll just repost my answer:
here are some differences from the top of the head:
* Fork has tabbed interface
* For each commit you can see not only changes, but also the whole repository as it was at the moment of commit
* Diff viewer shows exact difference between two pieces of code. For example, here are both SourceTree and Fork showing the same commit: https://dl.dropboxusercontent.com/s/fn9mzjmyvhec2sa/2016-08-..., In ST (on the top) you need to figure out what has changed, in Fork (the bottom one) you see the difference clearly.
* Repository browser shows you many details about your repositories in the similar way as Finder does
* Commit list marks commits which do not belong to your commit tree with gray color
SourceTree has a tabbed interface as well now. The diff viewer might be interesting if it's really good but I think that to require an external viewer where the company focused on that as a product. On Mac most of the good options are paid though, might help you.
All of the OS X interfaces to Git are, to be honest, quite terrible. Sourcetree is awful. GitHub Desktop is even worse. I've tried a couple of others, the names of which elude me at the moment. I think most of it is less of a complaint against the software itself, and more of a problem with trying to present the complexities of Git in a simplistic UI. The simple fact is: Git as a whole is really, really freaking complex. Making the basic operations idiot proof is difficult enough, and then you have to try to offer a frontend for things like rebasing. Seriously though, fuck the products that pre-select all unstaged files to be added to the index on every commit. If I wanted the file staged, I would add it. Stop harassing me to add my development files - and no, I shouldn't have to gitignore them to prevent being constantly forced to deselect them. By all means, show checkboxes for me to add the files, but do not pre-check them.
I haven't seen a single interface that gets it right. JetBrains' integration in their IDEs is the closest to "mostly usable" I've seen, where branch creation, pulls, merges, conflict resolution, and pushes are fairly straightforward. It's still far from perfect - I do the lower-level Git > Pull rather than using the Update Project window because I have no idea what operations that window performs; and some rare operations still require dropping to command-line. I'd rate their implementation a 7/10 compared to the 3/10 other tools like Sourcetree provide.
A huge reason JetBrains has an insurmountable lead is its diff and merge editor. It is the best on the market, and the only usable side-by-side merge tool I can work with. Their 3-way diff is a dream to use. The last time I had to assist a co-worker merge a conflict using WinMerge on Windows, I gave up after 30 minutes. I flat out could not understand what the differences were, let alone figure out how to resolve the conflicts. Went back to my desk, checked out the branch in JetBrains' PhpStorm, performed the same merge, and had the conflicts resolved in a couple of minutes. It's no surprise to me that people using WinMerge erase work done by other people far too often.
Anti-disclaimer: not affiliated in any way with JetBrains. Their IDEs are mostly amazing, though it's frustrating that they focus 95%+ of their efforts on new features without going back and fixing what is wrong with their existing features. Their diff/merge editor, at least, is unmatched by any other product I have seen to date (other than the fact that CMD+F / CTRL+F to find in the diff editor is broken... again, JetBrains has some serious bugs that never get fixed).
Agree with all of your points. SourceTree nowadays does not select by default (at least my setup doesn't) but it's still far from optimal.
WinMerge? On Windows? I'm using beyond compare which is pretty nice when correctly configured, tortoise internal diff ain't bad either. Both have three way diff which I consider standard for any diff tool. Jetbrains indeed get a lot of things right. Using their resharper (visual studio), webstorms and itellij ultimate versions. They make amazing products.
Agree with all of your points. SourceTree nowadays does not select by default (at least my setup doesn't) but it's still far from optimal.
WinMerge? On Windows? I'm using beyond compare which is pretty nice when correctly configured, tortoise internal diff ain't bad either. Both have three way diff which I consider standard for any diff tool. Jetbrains indeed get a lot of things right. Using their resharper (visual studio), webstorms and itellij ultimate versions. They make amazing products.
I suggest not using the magnifying glass icon for the repo favorites. It is confusing especially because you have a search field already on the right hand side. Might I suggest a star icon or a list icon for the list of repos?
Not sure why this is downvoted, I'm also interested to know how popular these sort of tools are compared to command line git and what the main advantages are.
I'm curious as well...I've tried using the Git integration within MSVS ,and it was a ~very~ unpleasant experience. I suppose in some instances it may be nice to visually see changes, but I've always preferred the command line for git.
Because I have dyslexia and command lines are torture for me.
Do you really need to justify people making tools more usable? Seriously? Isn't it enough to say, "if there's a quality UI, way more people can comfortably use the tool."
Because when you're doing anything outside of git commit am- "whatever" it's nice to be able to see the complete implications of your actions, what files have been modified, what lines in those files have changed, etc.,
git commit -v gives you the diffs provided you don't also use -m. Personally, I find -m to be a dangerous flag for commit for exactly the reasons you described not mention its hard to really do detailed multi-line commit messages with -m.
Having `git status` in a window-based UI is very nice. In magit, the window is divided into two sections horizontally: unstaged changes and staged changes. Each section contains multiple changed files that can be folded or expanded, and individual lines or hunks can be staged/unstaged as needed in order to prepare a commit.
While it is an emacs extension, non-emacs users can start it with a one-line command and treat it as a standalone application, e.g.
I know at least one non-emacs user who uses it that way.
There are some videos on youtube showing the magit UI. It would of course look more modern were it not an emacs extension but, emacs lisp programmers being as they are, I believe it is the most fully featured and powerful graphical git UI in existence.
For anyone looking for a Mac graphical git client, I should mention GitBox here (http://gitboxapp.com) as I've used it for years to augment the command line. Not all the GUI clients for git are useful, but I really like GitBox. Right mix of features.
I wish someone would maintain a list of all current (and past, abandoned) Git UIs, including a feature grid. This would both help the community using them, and help people who think "oh, I'll write a Git UI!".
Do you really need one? Sourcetree is awful. Slow. Bloated. It even fails to dim non-available UI elements all over the place. Doesn't know how to use checkbox widgets correctly.
I love the 5-6 seconds of waiting for its UI to gradually, slooowly, update itself after you do virtually any operation, no matter how simple.
I guess I haven't had any UI issues with it as far as asset popping, although going through their "big update" and the related auth problems left it pretty much unusable for a full week.
i have been using GitBox (http://gitboxapp.com) for quite awhile now, but it seems like it doesn't get much in the way of updates, so i tried this.
Very first thing it does is write a file called "gitclient.log" to my home directory. i deleted it, and it came back the next time i started the app. I see nothing in the prefs that allows you to move the file somewhere else.
call me picky, but this is is a deal-breaker for me. nothing gets to write files to the root of my home directory. Right into the trash.
The developer is here. I've already mentioned, I wasn't ready to be on HN today (I'm not the OP), and that's why I missed logging. Anyway, I'm really sorry for that.
Right now I'm making a new build with the fix. Thanks for letting know.
It's worse on Windows, where Git tools (including some from Microsoft themselves!) expect to see a .ssh folder in your user folder root. Wrong. Bad. Windows doesn't work that way! There's not even any contract/guarantee the user folder root is writable by the user in Windows! Sigh.
Can confirm. Installing Git (or SSH) on Windows is frustrating beyond belief. I can't seem to ever get the .ssh folder in the correct place and when I do it doesn't make any sense (from a Windows standpoint). Grrrr...
How are you using Git in the first place?
The first time it asked me to do `git config --global user.name` and `git config --global user.email` and produced a ~/.gitconfig file.
I didn't have to do that, probably because I already had that stuff lying around from earlier git usage. Fork recognized several of the repos I use without me having to configure anything.
It was missing a couple of crucial repos I need, and I was in the process of figuring out how to add them, when I hit the show-stopper that caused me to put the app in the trash.
The developer says he's put up a new version without that problem, so I will try again.
Does GitBox still work without issues for you? About 3 months ago it just stopped working completely on two separate machines, could never get it to work again. Had to switch to Tower instead.
If it doesn't include interactive rebase, it's not worth the cash because I'll have to go back to the CLI before I merge anything.
EDIT: Fork looks wonderful, I didn't mean to be so cold—just pointing out that it's hard to write a replacement for the original tool, and that I value it when it happens. I believe Sourcetree supports it.
Neat. But please check if a name is taken, so we don't have to tell people that we used Fork to checkout a copy of the Linux source tree, and fix a bug in Fork.
I have a pre-commit hook that is installed on all new repo's I create/clone that warns me, and then I set an email address PER REPO. This way I can work on both $WORK and open source projects on the same machine while having different email addresses per repository.
The assumption that a user needs to have user.email set globally breaks my entire work-flow.
People shouldn't use git without having configured that. It would prevent incorrect commits landing in public repositories. Actually git defaults to some made-up local git author if it's not set, and that's less useful and sometimes invalid, provoking git-fsck errors.
I agree. A potential middle ground would be a small button that lets them skip that screen with a second confirmation dialog box with a warning about it.
Git explicitly shows a "Committer" line when typing the commit message if it chooses a default, so I also find not setting one globally and getting this reminder to be more useful:
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Committer: Ben Alpert <balpert@balpert-mbp.local>
#
# On branch master
# Your branch is up-to-date with 'origin/master'.
#
FWIW, I solve this problem with ~/src/work and ~/src/personal. My default, system-wide config in .gitconfig are my personal creds. In ~/src/work, I have a direnv (http://direnv.net/) which configures my work credentials.
I used to do something similar to you, but this has been less effort to maintain/less repetition :) (which is nice, as our internal structure is lots of micro-repos so you're constantly cloning new things, and constantly adding creds becomes a hassle).
I use tig (https://github.com/jonas/tig) because it doesn't require me to leave the terminal and I find it does everything I need from a git UI without getting in the way
This. I can't really tell how much time of doing "git commit -p" GitX has saved me. It's a much easier way to visualize, stage and group changes into commits when you've made a bunch of unrelated changes.
108 comments
[ 2.3 ms ] story [ 176 ms ] threadIt hasn't been receiving many updates unfortunately. I'm happy that another app has popped up! Looking forward to try it out.
https://www.atlassian.com/software/sourcetree
http://gitup.co/
http://gitboxapp.com/
But I do agree there are lots of very similar UIs for various git GUIs. And I'm sure SourceTree borrowed lots of their layout from others as well.
I really like GitKraken and the team is taking feedback applying it constructively and putting out an impressive product. The part I really like is it's the same app on OSX, Linux and Windows using Electron to build it was a smart move on their part. My favorite feature has to be dropping a branch on another branch to create a pull request. I don't fanboy stuff much these days but I am a pretty big fan of their's right now.
here are some differences from the top of the head:
* Fork has tabbed interface
* For each commit you can see not only changes, but also the whole repository as it was at the moment of commit
* Diff viewer shows exact difference between two pieces of code. For example, here are both SourceTree and Fork showing the same commit: https://dl.dropboxusercontent.com/s/fn9mzjmyvhec2sa/2016-08-..., In ST (on the top) you need to figure out what has changed, in Fork (the bottom one) you see the difference clearly.
* Repository browser shows you many details about your repositories in the similar way as Finder does
* Commit list marks commits which do not belong to your commit tree with gray color
Does it really? I just checked that I am on the latest version on osx and it's not tabbed. Is this a windows only feature or something?
I haven't seen a single interface that gets it right. JetBrains' integration in their IDEs is the closest to "mostly usable" I've seen, where branch creation, pulls, merges, conflict resolution, and pushes are fairly straightforward. It's still far from perfect - I do the lower-level Git > Pull rather than using the Update Project window because I have no idea what operations that window performs; and some rare operations still require dropping to command-line. I'd rate their implementation a 7/10 compared to the 3/10 other tools like Sourcetree provide.
A huge reason JetBrains has an insurmountable lead is its diff and merge editor. It is the best on the market, and the only usable side-by-side merge tool I can work with. Their 3-way diff is a dream to use. The last time I had to assist a co-worker merge a conflict using WinMerge on Windows, I gave up after 30 minutes. I flat out could not understand what the differences were, let alone figure out how to resolve the conflicts. Went back to my desk, checked out the branch in JetBrains' PhpStorm, performed the same merge, and had the conflicts resolved in a couple of minutes. It's no surprise to me that people using WinMerge erase work done by other people far too often.
Anti-disclaimer: not affiliated in any way with JetBrains. Their IDEs are mostly amazing, though it's frustrating that they focus 95%+ of their efforts on new features without going back and fixing what is wrong with their existing features. Their diff/merge editor, at least, is unmatched by any other product I have seen to date (other than the fact that CMD+F / CTRL+F to find in the diff editor is broken... again, JetBrains has some serious bugs that never get fixed).
WinMerge? On Windows? I'm using beyond compare which is pretty nice when correctly configured, tortoise internal diff ain't bad either. Both have three way diff which I consider standard for any diff tool. Jetbrains indeed get a lot of things right. Using their resharper (visual studio), webstorms and itellij ultimate versions. They make amazing products.
WinMerge? On Windows? I'm using beyond compare which is pretty nice when correctly configured, tortoise internal diff ain't bad either. Both have three way diff which I consider standard for any diff tool. Jetbrains indeed get a lot of things right. Using their resharper (visual studio), webstorms and itellij ultimate versions. They make amazing products.
It's supposed to be something like Spotlight search in OS X (https://dl.dropboxusercontent.com/s/vopjz0e9tp1k1ul/2016-08-...).
The star icon more closely aligns with quick access to something used often.
Am I missing something?
Do you really need to justify people making tools more usable? Seriously? Isn't it enough to say, "if there's a quality UI, way more people can comfortably use the tool."
- I can stage/unstage/reset my changes line-by-line
- I can observe the whole repository structure as it was at the moment of commit
- Gui client automatically keeps my submodules in the valid state so I don't need to check their state after each checkout
- I can quickly review the whole repo history (sometimes it can be useful when I am involved in a new project)
- I can see clearly the commits which are going to be pushed
While it is an emacs extension, non-emacs users can start it with a one-line command and treat it as a standalone application, e.g.
https://github.com/dandavison/emacs-config/blob/master/bin/e...
I know at least one non-emacs user who uses it that way.
There are some videos on youtube showing the magit UI. It would of course look more modern were it not an emacs extension but, emacs lisp programmers being as they are, I believe it is the most fully featured and powerful graphical git UI in existence.
The homebrew version of the Git is bundled with two Git GUI frontends called gitk (invoked with `gitk`) and git-ui (invoked with `git gui`)
I love the 5-6 seconds of waiting for its UI to gradually, slooowly, update itself after you do virtually any operation, no matter how simple.
Very first thing it does is write a file called "gitclient.log" to my home directory. i deleted it, and it came back the next time i started the app. I see nothing in the prefs that allows you to move the file somewhere else.
call me picky, but this is is a deal-breaker for me. nothing gets to write files to the root of my home directory. Right into the trash.
Right now I'm making a new build with the fix. Thanks for letting know.
Lazy Linux developers making lazy "ports" lazily.
Might be an issue with the port of openssh, rather than git itself.
It was missing a couple of crucial repos I need, and I was in the process of figuring out how to add them, when I hit the show-stopper that caused me to put the app in the trash.
The developer says he's put up a new version without that problem, so I will try again.
EDIT: Fork looks wonderful, I didn't mean to be so cold—just pointing out that it's hard to write a replacement for the original tool, and that I value it when it happens. I believe Sourcetree supports it.
Well, it is free :-) (at least while in beta)
P.S. I wasn't ready to be mentioned on HN today :).
http://imgur.com/a/T4s4o
I have a pre-commit hook that is installed on all new repo's I create/clone that warns me, and then I set an email address PER REPO. This way I can work on both $WORK and open source projects on the same machine while having different email addresses per repository.
The assumption that a user needs to have user.email set globally breaks my entire work-flow.
I used to do something similar to you, but this has been less effort to maintain/less repetition :) (which is nice, as our internal structure is lots of micro-repos so you're constantly cloning new things, and constantly adding creds becomes a hassle).
https://rowanj.github.io/gitx/