It's kind of amusing to me how the pendulum has swung, and we're now producing OS X-only developer software.
But then, I'm an oddball who works on Windows as my shell with the real work happening on a headless Linux box via SSH and Samba for 99% of my development.
+1 I was going to make a rather sarcastic comment that this is for "professional engineers", but is OS X only. Ubuntu on a VirtualBox on Windows for me.
You're not the only oddball. Some of us work on Windows software and NEED the Windows box -- I also use too many Windows-only tools to make the jump to Mac.
And what they do with Cmd-vs-Alt drives my fingers crazy, so I can't configure a Mac to be sane no matter what I try. And I use keyboard navigation to peruse menus, which OS X still hasn't implemented...the list goes on, and I stick with Windows.
Could someone comment on the main complications on developing something like this for both Mac and Linux? From my point of view, they is so much common ground, comparing to a Mac/Windows support, that I'd strive for an application to cover both! And that's not something that you could always decide after launching the first time, you need to have it in consideration during design...
There's no market for this sort of thing on Windows. The vast majority of development that happens on Windows takes place in either Visual Studio or Eclipse, and those developers prefer tools that integrate with their IDE rather than be standalone.
I use this setup at work and I love it, the only thing I miss from my at-home linux setup is that I can't yank and paste directly to system clipboard with Windows. It's pretty sweet being able to yank in one buffer, flip over to another tmux window or pane and be able to paste seamlessly.
I'm a SourceTree user on Mac. Just tried GitUp out for an hour.
Here are the problems I have with SourceTree:
* Slow as hell
* No/bad keyboard shorts, and setting up custom ones is annoying and buggy
* Uses tons of memory — it eventually gets up to 1 GB after running for a day or two, and my repos are not very big.
My thoughts on GitUp:
* Crazy fast (almost disarmingly so – I think it needs more visual confirmation when things happen)
* Excellent commit/staging view. Reminds me of GitExtensions, a nice Git GUI for Windows
* I love the focus on keyboard shortcuts. They work really well in the commit view
* Map view is truly awful. I get that it's a work in progress, but I have no idea what its organizing principle is. Too much pointless whitespace. It radically overprivileges old branches and commits. I don't see a way to focus on what I did most recently.
* The list of commits (Cmd+D) in the map view is useless
> IMPORTANT: During Pre-Release, signing-up for a GitUp account allows you to enable advanced features (like rewriting commits), participate in the GitUp forums, access the "Continuous" build channel, and most importantly, show your support for the app and future developments!
Why do I need a GitUp account to enable rewriting commits?
Furthermore it looks like these prerelease builds expire. I'm guessing the released software will be neither free nor open source.
Anything can happen (I have a number of projects that are open-source, some other close-source), but the idea so far is to have a free app with an in-app purchase to unlock the advanced/pro feature.
I might make open-source some of the "Git toolkit" I built for this app, but it's too early to say.
The reason for expiring builds is that 1) it's pre-release, 2) it's a software intended for professional engineers and 3) the app is rapidly evolving, so I don't want to have people using old versions which may have bugs fixed since then: http://forums.gitup.co/t/gitup-release-notes/16.
I don't know if it's such a good idea to start by showing how easy changing commit messages is or even have this option that easily available, because after all you're changing the history and the beginner might not be aware what this really means, and beginners seem to be the target audience for this tool.
Actually, GitUp was designed to be for professional software engineers first, even though it may also appeal to beginners. It's faster than the CLI for a number of operations, and offers features that don’t even exist natively in Git like a visual commit splitter or a unified reflog browser.
The Map view documentation does have a large warning on rewriting history (which obviously is required for a number of operations), but I agree that an in-app warning might be good too: http://forums.gitup.co/t/using-gitup-map-view/34.
I agree. If you've already pushed to other repos with the old commit message, this can cause issues. The only time I actually change the commit message is when I'm sure that nobody else has seen it. I'm not even sure what happens when you change the local commit message, and push it again. Does it just get updated in the remote repo?
I realize this is a pretty broad question, but what is it about Git that people find painful? Could be Stockholm Syndrome on my part, but I have a pretty hard time understanding why someone can't spend a week getting up to speed with a tool they intend to use for years to come.
IMO this all boils down to the Git CLI just being terrible e.g. “git add” to stage versus “git reset HEAD” to unstage. Pretty much everything is like that. And there are always edge cases so that a command works in this case but not in that one. Want to edit a commit message? "git amend". But only if the last one. Otherwise it's "git rebase -i" (even though your intent is not to do a rebase, go figure). Well, not if it's a merge actually, you'd need "git rebase -p" or something... Even if something is conceptually simple, Git CLI manages to make it complicated. And GUI tools don't help much as they just wrap the Git CLI.
Of course it does make sense if you know how Git is built internally, but that's irrelevant to getting the job done :)
Anyway, with GitUp, the idea is to have an interactive live map instead, where operations and UI actually make sense, while still being 100% compatible with Git under the hood.
Yeah, I was coming here to post that Git is already painless. It's a tool you are intimately using if you're doing anything other than Hello World projects with your team; it doesn't seem too much to ask to actually learn how it works. And once you know it's painless.
Edit: I was thinking about it a bit more and it's actually one of the least painful tools I have ever used on a computer...
unknown unknowns. Odd choices for flags and commands. Inability to search for explanations of some commands.
These are all valid commands that do radically different things:
<pre>
git checkout patch
git checkout --patch
git checkout -- patch
</pre>
Yet, googling to find the difference is difficult (because search engines). If, eventually, you decide to search for 'dash dash', you'll start to find good results.
So, if a user had a file named 'patch' that they want to 'revert' back to the last committed version, they might try the first one (after all, it works for 'git checkout somefile.txt'). But IF they have a branch named patch, it would attempt to switch to it. It might succeed, it might fail, depending on the state of the tree, giving a very strange message compared to what the user wanted to do.
Despite it's ubiquity in the man pages, I haven't been able to find 'official' documentation or explanation for it, rather a bunch of blog posts and stack overflow questions. I find it hard to believe that a user who spent their time reading through docs and man pages would be able to work out the meaning on their own.
This is one example, but there are a TON of examples in StackOverflow as to what people find difficult. Most of my git knowledge comes from having to fix something that went awry. It's hard to 'spend a week getting up to speed' on a tool whose sole purpose is to manage other work.
> but I have a pretty hard time understanding why someone can't spend a week getting up to speed with a tool they intend to use for years to come.
Because it may not be for enough years. I've used CVS, SVN, Git in less than 15 years. I still have clients on SVN because Git is too much to get to grips with.
> what is it about Git that people find painful?
Why is there no built-in 'tree' command? I am lost without my .gitconfig and the aliases I have set up to give me a visual view of the repository.
Also, the difference between HEAD^3 and HEAD~3. I have muscle memory to do what I need, but for more occasional tasks I am searching StackOverflow.
I haven't used other DVCS so I don't know if the pain points are Git, or they're the complexities that DVCS brings. I look forward to the next (r)evolution in source control, when I hope we have power but more human-friendliness.
I still like a GUI from time to time. I use SourceTree. I can use GIT on the command-line and I'm a competent developer but I like to be able to click files and see the changes and just drag them into a commit. It may not be the fastest way, or the most advanced but it works for me.
Git command-line works fine, but I am not expert. Once something goes wrong, I find it impossibly hard to figure from Git command-line what is going on. Visualizing the repository (using SourceTree for example) makes understanding the problem trivial. Working 100% on the command-line with Git feels like having to move things around while being blind.
Not convinced? Try to stop using a whiteboard, drawing diagrams to explain things, using body language, etc. for a while.
I am been wishing for a tool like this GitUp for a long time, even thought about building one myself except that I see a lot of anti-GUI sentiment amongst many Git users, aka potential customers. Glad someone is making it.
BTW I don't get all the negativity in the comments about Mac-only tools. A huge number of developers use Macs specifically for well-designed third party software with *nix goodness. I wish other platforms had the same quality of third party software, but they just don't. This is mostly because it is much more difficult to make money selling software for other platforms, for whatever reason.
In any case, I don't see the justification for ragging on someone for developing for (1) the platform they choose to use themselves and (2) the only platform where indie devs can make any money.
i'd expect any significant project to have a tree _at least_ that complex. here's a small sample of my company's tree with several team repos merging into a master repo. this tool really loses its usefulness quickly for repos this complex..
The general verbiage, tone and saying things like "It will change your life as a developer" makes me not really want to look into it.
Show, don't tell, that's my advice.
Anyway, the main point is you are making an effort to build something that can solve problems and you are putting it out there, so well done on that front.
Looks interesting. I think speed is absolutely important when it comes to version-control interfaces. It was one of the main reasons Linus created it in the first place (as opposed to SVN), and I'd argue it's important to maintain flow.
My current git interface is "tig", a curses-based command-line client, which I enjoy for its speed and simplicity. Gitup looks appealing for similar reasons.
The tree visualization is nice, but if you'd rather use a (Mac only) GPL tool then Gitx-dev, a fork of Gitx, is still pretty good (http://rowanj.github.io/gitx/).
> Because it bypasses the Git binary tool and interacts directly with the repo database, GitUp is vastly more reliable than other Git clients and often faster than the command line.
There's something really satisfying about seeing a visual representation of my git repositories, but my overall impression is that I'm not going to get any productivity gains here.
If you know what you're doing, CLI is just faster. I understand that it's aimed at more novice developers, but I think for those developers it's even more important to use the command line. Developers that get into the habit of using unnecessary graphical UIs always seem worse off because of it.
> If you know what you're doing, CLI is just faster.
This is quite true with other Git GUIs since they pretty much wrap the Git CLI and add a bunch of dialogs and whatnot, but GitUp was designed especially to avoid that. I'm a big user of the CLI myself, so the last thing I wanted was to build a Git client with a slower interaction model :)
Between the keyboard shortcuts and the fact it deals directly with the repo database, GitUp is actually faster than the CLI in a number of cases. Experienced Git users do notice it on Twitter and on the GitUp forums. One example from my workflow: just rebasing my work branch is instantaneous in GitUp while the Git CLT takes a couple seconds (the UX being as fast in both cases to perform the operation, so a net gain for sure).
YMMV of course and you can totally use GitUp for some operations and Git CLI for some others.
The 'gr' is short for 'graph'. You can tweak the -n to show more history. I actually have several of these, 'gr', 'grr', 'grrr', etc. to show more and more history.
I needed something like this when I was starting out, and still occasionally do. Obviously once you've had a few dozen commits you get a hang of things, but initially, the visualisation can help a lot.
For my co-founder who's just getting started with software engineering practices like version control, I recommended she use ungit (https://github.com/FredrikNoren/ungit)
I've tried to use GitX and SourceTree in my workflow and always end up going back to gitk. There's always some information, view or action I can do in gitk that I can't make the others do. I find git from the command line to be the most painless. Everything else is always the third thing after gitk and command-line. Seeing multiple stashes used to be a great extra feature, then I just stopped using stashes.
I think your choice, swisspol, to use the 'free-with-in-app-purchase' model is the right one. You're selling to OS X users, who are willing to actually spend money on apps and software, and it allows us to use an app and then decide if we want to buy it. All that really needs to be said is, "GitUp is free with lots of capability to get things done. But to speed up your workflow even more and use all of its features, it offers an in-app purchase to upgrade." Plus, we as OS X users are used to noticing that little 'in-app purchases' note on apps and don't think it's a "slap in the face". I just hope that it will be available on the Mac App Store. I trust apps most that are sold on the App Store and I always look there first. I tie my card to my iTunes account or even have gift card money ready to make a purchase. Also, I can see when it was updated, what others say about it in reviews and share it quickly and easily. Just my thoughts, @swisspol
Dialog box? Why not drag and drop? Just drag this branch into the branch, to indicate what shape of graph you want, and it merges to make it that way.
How about an interface where you can pick commits from a graph, and drag them into a free space, where they exist as labeled points. Then, draw line segments among hem and connect them to a graph. Then, the software cherry picks these commits according to what you've drawn and creates that branch. The need for a merge could be indicated as a red blinking light on a node. (And the not yet cherry-picked segments are grayed out.) From there you click on it, get a list of conflicted paths, and engage in resolution UI. The blinking indicator goes away, and the cherry pick continues.
[+] [-] cheald|10 years ago|reply
But then, I'm an oddball who works on Windows as my shell with the real work happening on a headless Linux box via SSH and Samba for 99% of my development.
[+] [-] iconjack|10 years ago|reply
[+] [-] alexchamberlain|10 years ago|reply
[+] [-] SomeCallMeTim|10 years ago|reply
And what they do with Cmd-vs-Alt drives my fingers crazy, so I can't configure a Mac to be sane no matter what I try. And I use keyboard navigation to peruse menus, which OS X still hasn't implemented...the list goes on, and I stick with Windows.
[+] [-] harperlee|10 years ago|reply
[+] [-] Touche|10 years ago|reply
[+] [-] vectorpush|10 years ago|reply
[+] [-] fleetfox|10 years ago|reply
[+] [-] dcre|10 years ago|reply
Here are the problems I have with SourceTree:
* Slow as hell
* No/bad keyboard shorts, and setting up custom ones is annoying and buggy
* Uses tons of memory — it eventually gets up to 1 GB after running for a day or two, and my repos are not very big.
My thoughts on GitUp:
* Crazy fast (almost disarmingly so – I think it needs more visual confirmation when things happen)
* Excellent commit/staging view. Reminds me of GitExtensions, a nice Git GUI for Windows
* I love the focus on keyboard shortcuts. They work really well in the commit view
* Map view is truly awful. I get that it's a work in progress, but I have no idea what its organizing principle is. Too much pointless whitespace. It radically overprivileges old branches and commits. I don't see a way to focus on what I did most recently.
* The list of commits (Cmd+D) in the map view is useless
[+] [-] eric_h|10 years ago|reply
Why do I need a GitUp account to enable rewriting commits?
Furthermore it looks like these prerelease builds expire. I'm guessing the released software will be neither free nor open source.
[+] [-] swisspol|10 years ago|reply
I might make open-source some of the "Git toolkit" I built for this app, but it's too early to say.
The reason for expiring builds is that 1) it's pre-release, 2) it's a software intended for professional engineers and 3) the app is rapidly evolving, so I don't want to have people using old versions which may have bugs fixed since then: http://forums.gitup.co/t/gitup-release-notes/16.
[+] [-] dan00|10 years ago|reply
[+] [-] swisspol|10 years ago|reply
The Map view documentation does have a large warning on rewriting history (which obviously is required for a number of operations), but I agree that an in-app warning might be good too: http://forums.gitup.co/t/using-gitup-map-view/34.
[+] [-] graffitici|10 years ago|reply
[+] [-] pdmy|10 years ago|reply
[+] [-] depr|10 years ago|reply
[+] [-] okal|10 years ago|reply
[+] [-] swisspol|10 years ago|reply
IMO this all boils down to the Git CLI just being terrible e.g. “git add” to stage versus “git reset HEAD” to unstage. Pretty much everything is like that. And there are always edge cases so that a command works in this case but not in that one. Want to edit a commit message? "git amend". But only if the last one. Otherwise it's "git rebase -i" (even though your intent is not to do a rebase, go figure). Well, not if it's a merge actually, you'd need "git rebase -p" or something... Even if something is conceptually simple, Git CLI manages to make it complicated. And GUI tools don't help much as they just wrap the Git CLI.
Of course it does make sense if you know how Git is built internally, but that's irrelevant to getting the job done :)
Anyway, with GitUp, the idea is to have an interactive live map instead, where operations and UI actually make sense, while still being 100% compatible with Git under the hood.
[+] [-] tluyben2|10 years ago|reply
Edit: I was thinking about it a bit more and it's actually one of the least painful tools I have ever used on a computer...
[+] [-] hatsix|10 years ago|reply
These are all valid commands that do radically different things: <pre> git checkout patch git checkout --patch git checkout -- patch </pre> Yet, googling to find the difference is difficult (because search engines). If, eventually, you decide to search for 'dash dash', you'll start to find good results.
So, if a user had a file named 'patch' that they want to 'revert' back to the last committed version, they might try the first one (after all, it works for 'git checkout somefile.txt'). But IF they have a branch named patch, it would attempt to switch to it. It might succeed, it might fail, depending on the state of the tree, giving a very strange message compared to what the user wanted to do.
Despite it's ubiquity in the man pages, I haven't been able to find 'official' documentation or explanation for it, rather a bunch of blog posts and stack overflow questions. I find it hard to believe that a user who spent their time reading through docs and man pages would be able to work out the meaning on their own.
This is one example, but there are a TON of examples in StackOverflow as to what people find difficult. Most of my git knowledge comes from having to fix something that went awry. It's hard to 'spend a week getting up to speed' on a tool whose sole purpose is to manage other work.
[+] [-] pbowyer|10 years ago|reply
Because it may not be for enough years. I've used CVS, SVN, Git in less than 15 years. I still have clients on SVN because Git is too much to get to grips with.
> what is it about Git that people find painful?
Why is there no built-in 'tree' command? I am lost without my .gitconfig and the aliases I have set up to give me a visual view of the repository.
Also, the difference between HEAD^3 and HEAD~3. I have muscle memory to do what I need, but for more occasional tasks I am searching StackOverflow.
I haven't used other DVCS so I don't know if the pain points are Git, or they're the complexities that DVCS brings. I look forward to the next (r)evolution in source control, when I hope we have power but more human-friendliness.
[+] [-] rbosinger|10 years ago|reply
[+] [-] alok-g|10 years ago|reply
Not convinced? Try to stop using a whiteboard, drawing diagrams to explain things, using body language, etc. for a while.
I am been wishing for a tool like this GitUp for a long time, even thought about building one myself except that I see a lot of anti-GUI sentiment amongst many Git users, aka potential customers. Glad someone is making it.
[+] [-] alexchamberlain|10 years ago|reply
[+] [-] pyrocat|10 years ago|reply
ain't nobody got time for that
[+] [-] masnick|10 years ago|reply
BTW I don't get all the negativity in the comments about Mac-only tools. A huge number of developers use Macs specifically for well-designed third party software with *nix goodness. I wish other platforms had the same quality of third party software, but they just don't. This is mostly because it is much more difficult to make money selling software for other platforms, for whatever reason.
In any case, I don't see the justification for ragging on someone for developing for (1) the platform they choose to use themselves and (2) the only platform where indie devs can make any money.
[+] [-] zatkin|10 years ago|reply
I hope no-one here ever has to deal with a tree like this.
[+] [-] scotthew1|10 years ago|reply
http://i.imgur.com/xl2a1ac.png
[+] [-] swisspol|10 years ago|reply
[+] [-] davexunit|10 years ago|reply
OSX only and proprietary: no thanks.
[+] [-] Grue3|10 years ago|reply
[+] [-] jv22222|10 years ago|reply
Show, don't tell, that's my advice.
Anyway, the main point is you are making an effort to build something that can solve problems and you are putting it out there, so well done on that front.
[+] [-] swisspol|10 years ago|reply
[+] [-] barbs|10 years ago|reply
My current git interface is "tig", a curses-based command-line client, which I enjoy for its speed and simplicity. Gitup looks appealing for similar reasons.
[+] [-] paozac|10 years ago|reply
[+] [-] dcre|10 years ago|reply
> Because it bypasses the Git binary tool and interacts directly with the repo database, GitUp is vastly more reliable than other Git clients and often faster than the command line.
[+] [-] swisspol|10 years ago|reply
Then on top of it is an extensive toolkit I built in a few months for repo manipulation and rendering.
[+] [-] chjohasbrouck|10 years ago|reply
If you know what you're doing, CLI is just faster. I understand that it's aimed at more novice developers, but I think for those developers it's even more important to use the command line. Developers that get into the habit of using unnecessary graphical UIs always seem worse off because of it.
[+] [-] swisspol|10 years ago|reply
This is quite true with other Git GUIs since they pretty much wrap the Git CLI and add a bunch of dialogs and whatnot, but GitUp was designed especially to avoid that. I'm a big user of the CLI myself, so the last thing I wanted was to build a Git client with a slower interaction model :)
Between the keyboard shortcuts and the fact it deals directly with the repo database, GitUp is actually faster than the CLI in a number of cases. Experienced Git users do notice it on Twitter and on the GitUp forums. One example from my workflow: just rebasing my work branch is instantaneous in GitUp while the Git CLT takes a couple seconds (the UX being as fast in both cases to perform the operation, so a net gain for sure).
YMMV of course and you can totally use GitUp for some operations and Git CLI for some others.
[+] [-] cgs1019|10 years ago|reply
[+] [-] mgold|10 years ago|reply
[+] [-] neil_s|10 years ago|reply
For my co-founder who's just getting started with software engineering practices like version control, I recommended she use ungit (https://github.com/FredrikNoren/ungit)
[+] [-] zyxley|10 years ago|reply
[+] [-] karmakaze|10 years ago|reply
[+] [-] dallanlee|10 years ago|reply
[+] [-] kazinator|10 years ago|reply
How about an interface where you can pick commits from a graph, and drag them into a free space, where they exist as labeled points. Then, draw line segments among hem and connect them to a graph. Then, the software cherry picks these commits according to what you've drawn and creates that branch. The need for a merge could be indicated as a red blinking light on a node. (And the not yet cherry-picked segments are grayed out.) From there you click on it, get a list of conflicted paths, and engage in resolution UI. The blinking indicator goes away, and the cherry pick continues.
[+] [-] swisspol|10 years ago|reply
[+] [-] kolev|10 years ago|reply
[+] [-] swisspol|10 years ago|reply