The applicatino asks you to register with my email address for further "communications related to GitKraken or Axosoft". There is no way to skip this step, you have to provide an email address ––and pay attention to "OR"... No thanks, buddy.
First thing I tried is dropping a git repo folder to the window, didn't work. When I click the open button I can see the Javascript animation glitching on my 'Early 2015 i5 2.7 Ghz MacBook Pro'.
The commit list UI is kind of alright but it doesn't show you the diff anywhere. So that's not exactly a Git UI, buddy. And this is not open source either, that's a lot of strikes. No thanks.
You can click on the files in the right-hand pane to get the diff. Right-click for more options.
I've been using the beta(!) for a few weeks and I think it's a promising product. I also don't think software should be completely disqualified for not being open-source (, buddy).
Yeah. I don't know when this happened, but that's become a deal breaker for me. Strange, right?
Edit to add:
It's particularly strange because I wouldn't depend on this tool in some infrastructural way -- I could switch clients anytime without any lock in. But I'm no longer willing to even try anymore. Odd.
Which is weird, seeing as the git license is GPL 2. I mean, I find it weird that one can build a product completely around a GPL project, and somehow not make it GPL. The whole point of the GPL is to restrict derivatives. Yet, somehow this has been mutated to become "links to a library," as if the technical fact that the product links to some code over an API boundary is different, legally speaking, than calling it with arguments over a process boundary.
The point of the GPL was supposed to be about derivative products, that is code that depends non-optionally on other code. Whether it depends on that code via linking, calling exec(), or sending HTTP requests, it shouldn't be legal to write a non-open-source application that depends on a GPL program to do anything useful.
I personally never use GUI clients for git, the CLI does exactly what it's supposed to do, efficiently, quickly in a stable reproducible manner, most GUI clients are for people who just don't want to learn to use the CLI properly.
But some tips for your project:
1-Lose the forced email registration
2-Easy on the Luxury, we're devs not divas
3-The beta agreement is just way too scary to take the product seriously, examples:
>Company grants Recipient a nonexclusive, nontransferable license to use the GitKraken (“Product”) for a period designated by the Company for the purpose of testing and evaluating the Product.
>This Product is a beta release offering and is not at the level of performance of a commercially available product offering. The Product may not operate correctly and may be substantially modified prior to first commercial release, or at Company’s option may not be released commercially in the future.
How do you expect to compete with other existing and stable products ? I'm not trying to sound harsh, this is just my views and I think I've got a point right?
"most GUI clients are for people who just don't want to learn to use the CLI properly"
Ridiculously arrogant comment with nothing to back it up. GUIs exist; get over it.
"How do you expect to compete with other existing and stable products?"
It's a beta. The T's & C's pretty much translate as "it's a beta". What do you want them to do, NOT release a beta? Fair enough if so, but a lot of software is released this way. And pretty much all FLOSS software excuses itself from any kind of warranty too.
Whenever you make an action using a GUI, you can clearly see what options are available to you, even if you're not using them. It's unreasonable for every person to invest the time to fully internalize the capabilities of every tool they use. The more (good) GUIs available, the better.
So they can't bother learning, and/or hiring for, appropriate programming languages and architectures for a GUI application. From Javascript hipsters to Javascript hipsters.
I keep seeing this promoted on Twitter, but there's nothing on the site that gives any idea of what it does better than SourceTree/Tower or any of the dozens of other Git GUIs.
Love the interface, dark theme and super intuitive. Could use syntax highlighting in diffs, though. It will need that feature to convince me to pay money, later.
One weird thing: it'd be great to have the option to show a name, instead of a shrunken avatar in the commit log, perhaps configure how this is shown, so I can choose the format of the name and if I want to see an avatar or not... I may be the only one, but seeing a 100+ row long column of just my face (I have worked on a few projects solo) kind of creeps me out.
Any idea when the product is going to be ready and how much it will cost?
Here are the things every git client should have before opening up:
1) side by side comparison—seems like it only has vertical, which means for heavy changes it's basically useless.
2) conflict resolution.
3) search (it seems like gitkraken does this well from the screenshots)
4) Interactive rebasing, the bread and butter of clean git usage.
Without the above as a minimum, I might as well just use the git cli all the time. It's not worth using two git tools when the cli is already so powerful.
Hi, author of git-cola[1] here, and I completely agree that these features are key. I have a slightly different philosophy implementation-wise, though.
Maybe I'm a unix crank, but I've always tried to keep cola as more of a mediator over individual best-of-breed tools, whenever it made the most sense, rather than re-implementing things that already exist in better forms elsewhere.
For diffs we show inline diffs for interactive staging, one of our uniquely ergonomic features, while also making it extremely easy to launch `git difftool`. difftool itself can be configured to use the best tools for side-by-side diffing, so integrating tightly with it makes for the most cohesive Git experience.
For conflict resolution we defer to `git mergetool`, for the same reason.
With `git cola rebase` it's really easy to reorder lines in a rebase and swap through the pick/squash/fixup/... options using keyboard shortcuts. The advantage is you can't mess up the instruction sheet like you can when using $EDITOR -- cola ensures that the instruction sheet is semantically valid (e.g. "pick" must be first) and does not allow the user to create an invalid instruction sheet. Those little things make a big difference for usability.
What you didn't mention, though is one of the most important aspects to me: A Keyboard-Centric Design
I am a heavy vim/gvim user. I use the keyboard for everything, so cola is designed to augment the command-line experience. If you want to find some string in your codebase run:
$ git cola grep foo # or ctrl-g foo in cola
# hit enter
# navigate results using vim-style hjkl keys
# hit enter
# you are now in foo_bar.c at that exact line of code,
# in your favorite $EDITOR
Being able to do the most common operations, without touching a mouse, is one of my guiding design goals. Hopefully I'm not the only one that feels this way.
Serious question, never used a git GUI in my life, is there a practical point to it ? I just can't see myself doing it without zsh, my nested .dotfiles, fasd and so on. And worst case scenario, I can always git them back.
Believe or not, there are a number of cases where you can work faster in a GUI than the CLI: many operations on the topology of the repo for instance. See somes examples at http://gitup.co/.
If you want to visualize the topology of a nontrivial git history, It's several times better in a gui than as a tree drawn using slashes and pipes in a shell window. Compare a nice graphical tree with something you might get from "git log --graph --oneline --all" or a similar command. The shell window just isn't up to the task of drawing nice things, just like it doesn't show pictures very nicely by converting them to ascii.
If you want to see side-by side diffs that's also a lot better in a nice text editor than in a text window. Getting balloon tooltips when hovering commit hashes hidden in a gutter etc. allows more information to be fit onto the screen.
The reason you use a graphical UI is because a text ui doesn't fit all the information you want to show in a good way. Most git tools might not need show or draw a large amount of information (push/pull/commit/...) but some do (blame, log --graph for example).
Not everybody is as comfortable in the CLI as you are. I prefer graphical git "tree" views over the CLI-drawn, but other than maybe that, no, it doesn't sound like there would be a point to it for you.
The lead tech at one place I work at uses the commandline for his own commits, but a gui app (can't recall which one) for manipulating merges and pull requests, as it more reliably deals with issues in his experience.
I honestly have no idea why people would want to have to click buttons for this stuff.
The one exception in my case is 3-way merges. I handle those in Meld, which I find to be better suited than any of the integrated threesome tools in these git GUIs.
Even that I could probably do better in emacs if I set it up.
Does GitKraken support GitHub Enterprise/Bitbucket Server?
GitKraken currently does not support these services but support is planned for a future release.
The only conclusion I can draw from this is that GitKraken supports one or more specific git based services that aren't GitHub Enterprise or Bitbucket, both of which use git.
I'm assuming that the service it does support is GitHub, but maybe the title and website should reflect that limitation.
Not sure how the title is misleading. It supports any git remote, but it has a few extra features (GH-style pull requests for example) that aren't really a part of Git. Those features are only possible on a GitHub or Bitbucket server, not just any git remote, but it currently only supports using them on the main public GitHub/Bitbucket servers.
I've played around with it for a bit, and will probably continue to do so - but my initial take on it is that it isn't very intuitive, especially compared to SourceTree. SourceTree has had some struggles lately with performance and bugs in their new 1.8.x version, but those aside, it does everything I need it to, and it was very intuitive to pick up. In contrast, the UI for GitKraken is just...odd.
Lots of negativity here. I use SourceTree normally and although I'm a command-line comfortable vim/tmux/fugitive/etc kind-of-guy I've decided I like GUIs for GIT. GitKraken is worth watching IMO. So far I've liked using it (I started trying it at 0.5 and just came back to it now with this 0.8 announcement).
I don't care that it's an Electron app. It seems snappy enough for me. Isn't Slack on Electron? I have that running all day too.
This whole "it's not open-source anymore" thing kind of sucks though. If this is just gearing up to be a paid application then it's really got to step up to SourceTree. I initially figured it was just the rowdy javascript crowd flexing their muscles and playing with things like Electron and that it would remain open-sourced.
It was and is developed by Axosoft, a competitor of Atlassian (JIRA). Atlassian has SourceTree, Axosoft now has GitKraken. I'm assuming they'll keep GitKraken free for a long time in an effort to be able to market Axosoft.
Does GitKraken support git Large File Storage? If so, I could see this becoming an excellent tool for non-programmers who have to use git(designers, game artists, etc.) and don't really want to get involved with some of the complexities that come with git.
If you're on windows, GitExtensions is pretty awesome. (open source too). I made a donation to the author because that client saved me from a team mutiny after I introduced git on the command line.
It seems weird to me that in this day and age people would be making negative comments about an app with this one's functionality being written in JavaScript/ecmascript. This app looks awesome and performs well on my platform, not sure if I'll continue to use it over the CLI client but so far I'm impressed.
I tried this today. Pretty okay. A bit light on features, but it has the most important ones.
However, it kept on creating temporary files (copies of the files I staged), and they showed up as stageable files. Very confusing.
There also needs to be an option to truncate file paths in the staging area box. Middle truncation that responds to the box width, or an option to only show the file names, because right now file names are just completely unreadable.
Also, there are stage hunk buttons, but no discard hunk buttons.
Configurable diff font size too.
I'll be still using SourceTree for now (even though they had that catastrophic broken release last week).
Performance is a lot better than SourceTree though, which can be a real dog sometimes. It's definitely showing that Electron is a viable choice to make desktop apps.
[+] [-] alpb|10 years ago|reply
First thing I tried is dropping a git repo folder to the window, didn't work. When I click the open button I can see the Javascript animation glitching on my 'Early 2015 i5 2.7 Ghz MacBook Pro'.
The commit list UI is kind of alright but it doesn't show you the diff anywhere. So that's not exactly a Git UI, buddy. And this is not open source either, that's a lot of strikes. No thanks.
[+] [-] matt4077|10 years ago|reply
I've been using the beta(!) for a few weeks and I think it's a promising product. I also don't think software should be completely disqualified for not being open-source (, buddy).
[+] [-] andrei_says_|10 years ago|reply
[+] [-] elcapitan|10 years ago|reply
[+] [-] romanovcode|10 years ago|reply
[+] [-] chei0aiV|10 years ago|reply
[+] [-] 0942v8653|10 years ago|reply
[+] [-] lallysingh|10 years ago|reply
Edit to add: It's particularly strange because I wouldn't depend on this tool in some infrastructural way -- I could switch clients anytime without any lock in. But I'm no longer willing to even try anymore. Odd.
[+] [-] radarsat1|10 years ago|reply
The point of the GPL was supposed to be about derivative products, that is code that depends non-optionally on other code. Whether it depends on that code via linking, calling exec(), or sending HTTP requests, it shouldn't be legal to write a non-open-source application that depends on a GPL program to do anything useful.
[+] [-] mbilker|10 years ago|reply
This is another Electron app after all.
[+] [-] mostafaberg|10 years ago|reply
But some tips for your project: 1-Lose the forced email registration 2-Easy on the Luxury, we're devs not divas 3-The beta agreement is just way too scary to take the product seriously, examples:
>Company grants Recipient a nonexclusive, nontransferable license to use the GitKraken (“Product”) for a period designated by the Company for the purpose of testing and evaluating the Product.
>This Product is a beta release offering and is not at the level of performance of a commercially available product offering. The Product may not operate correctly and may be substantially modified prior to first commercial release, or at Company’s option may not be released commercially in the future.
How do you expect to compete with other existing and stable products ? I'm not trying to sound harsh, this is just my views and I think I've got a point right?
[+] [-] oneeyedpigeon|10 years ago|reply
Ridiculously arrogant comment with nothing to back it up. GUIs exist; get over it.
"How do you expect to compete with other existing and stable products?"
It's a beta. The T's & C's pretty much translate as "it's a beta". What do you want them to do, NOT release a beta? Fair enough if so, but a lot of software is released this way. And pretty much all FLOSS software excuses itself from any kind of warranty too.
[+] [-] adrianN|10 years ago|reply
[+] [-] sixo|10 years ago|reply
[+] [-] jibsen|10 years ago|reply
[+] [-] millstone|10 years ago|reply
[+] [-] __david__|10 years ago|reply
[+] [-] StavrosK|10 years ago|reply
[+] [-] ex3ndr|10 years ago|reply
[+] [-] HelloNurse|10 years ago|reply
[+] [-] chedabob|10 years ago|reply
[+] [-] subie|10 years ago|reply
[+] [-] readme|10 years ago|reply
One weird thing: it'd be great to have the option to show a name, instead of a shrunken avatar in the commit log, perhaps configure how this is shown, so I can choose the format of the name and if I want to see an avatar or not... I may be the only one, but seeing a 100+ row long column of just my face (I have worked on a few projects solo) kind of creeps me out.
Any idea when the product is going to be ready and how much it will cost?
[+] [-] efraim|10 years ago|reply
https://twitter.com/GitKraken/status/692866148199591936
[+] [-] duaneb|10 years ago|reply
1) side by side comparison—seems like it only has vertical, which means for heavy changes it's basically useless.
2) conflict resolution.
3) search (it seems like gitkraken does this well from the screenshots)
4) Interactive rebasing, the bread and butter of clean git usage.
Without the above as a minimum, I might as well just use the git cli all the time. It's not worth using two git tools when the cli is already so powerful.
[+] [-] davvid|10 years ago|reply
Maybe I'm a unix crank, but I've always tried to keep cola as more of a mediator over individual best-of-breed tools, whenever it made the most sense, rather than re-implementing things that already exist in better forms elsewhere.
For diffs we show inline diffs for interactive staging, one of our uniquely ergonomic features, while also making it extremely easy to launch `git difftool`. difftool itself can be configured to use the best tools for side-by-side diffing, so integrating tightly with it makes for the most cohesive Git experience.
For conflict resolution we defer to `git mergetool`, for the same reason.
With `git cola rebase` it's really easy to reorder lines in a rebase and swap through the pick/squash/fixup/... options using keyboard shortcuts. The advantage is you can't mess up the instruction sheet like you can when using $EDITOR -- cola ensures that the instruction sheet is semantically valid (e.g. "pick" must be first) and does not allow the user to create an invalid instruction sheet. Those little things make a big difference for usability.
What you didn't mention, though is one of the most important aspects to me: A Keyboard-Centric Design
I am a heavy vim/gvim user. I use the keyboard for everything, so cola is designed to augment the command-line experience. If you want to find some string in your codebase run:
Being able to do the most common operations, without touching a mouse, is one of my guiding design goals. Hopefully I'm not the only one that feels this way.[1] https://github.com/git-cola/git-cola
[+] [-] nine_k|10 years ago|reply
It integrates with git with just `git mergetool -t meld`.
[+] [-] Vlaix|10 years ago|reply
[+] [-] swisspol|10 years ago|reply
Disclaimer: I made GitUp for that very reason ;)
[+] [-] alkonaut|10 years ago|reply
If you want to see side-by side diffs that's also a lot better in a nice text editor than in a text window. Getting balloon tooltips when hovering commit hashes hidden in a gutter etc. allows more information to be fit onto the screen.
The reason you use a graphical UI is because a text ui doesn't fit all the information you want to show in a good way. Most git tools might not need show or draw a large amount of information (push/pull/commit/...) but some do (blame, log --graph for example).
[+] [-] detaro|10 years ago|reply
[+] [-] vacri|10 years ago|reply
[+] [-] madeofpalk|10 years ago|reply
[+] [-] microcolonel|10 years ago|reply
The one exception in my case is 3-way merges. I handle those in Meld, which I find to be better suited than any of the integrated threesome tools in these git GUIs.
Even that I could probably do better in emacs if I set it up.
[+] [-] adamwong246|10 years ago|reply
[+] [-] karlshea|10 years ago|reply
[+] [-] wwkeyboard|10 years ago|reply
The same thing applies for languages and frameworks, if the code is great show it off.
[+] [-] boomlinde|10 years ago|reply
Does GitKraken support GitHub Enterprise/Bitbucket Server?
GitKraken currently does not support these services but support is planned for a future release.
The only conclusion I can draw from this is that GitKraken supports one or more specific git based services that aren't GitHub Enterprise or Bitbucket, both of which use git.
I'm assuming that the service it does support is GitHub, but maybe the title and website should reflect that limitation.
[+] [-] 0942v8653|10 years ago|reply
[+] [-] smithkl42|10 years ago|reply
[+] [-] 51Cards|10 years ago|reply
[+] [-] lawnchair_larry|10 years ago|reply
[+] [-] rbosinger|10 years ago|reply
I don't care that it's an Electron app. It seems snappy enough for me. Isn't Slack on Electron? I have that running all day too.
This whole "it's not open-source anymore" thing kind of sucks though. If this is just gearing up to be a paid application then it's really got to step up to SourceTree. I initially figured it was just the rowdy javascript crowd flexing their muscles and playing with things like Electron and that it would remain open-sourced.
[+] [-] jrs235|10 years ago|reply
[+] [-] bsimpson|10 years ago|reply
> I hate blind dates. Can I see some screenshots?
> You can see some screenshots of GitKraken’s UI here.
You may want to rethink the design of your homepage.
[+] [-] theaustinseven|10 years ago|reply
[+] [-] boxerab|10 years ago|reply
[+] [-] mrmondo|10 years ago|reply
1. I shouldn't need to sign up with your service, this also makes me distrust the product.
2. There is no Gitlab login option.
3. It looks to be written in Javascript and thus uses a lot of resources: http://imgur.com/a/uEH4U
So it's not /really/ a desktop app, it looks like it's just a chrome wrapper for some javascript?
[+] [-] vuldin|10 years ago|reply
[+] [-] moogly|10 years ago|reply
However, it kept on creating temporary files (copies of the files I staged), and they showed up as stageable files. Very confusing.
There also needs to be an option to truncate file paths in the staging area box. Middle truncation that responds to the box width, or an option to only show the file names, because right now file names are just completely unreadable.
Also, there are stage hunk buttons, but no discard hunk buttons.
Configurable diff font size too.
I'll be still using SourceTree for now (even though they had that catastrophic broken release last week).
Performance is a lot better than SourceTree though, which can be a real dog sometimes. It's definitely showing that Electron is a viable choice to make desktop apps.