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).
I had a similar sense with the app. Despite the very slick UI, it just felt awkward and inconvenient in all sorts of little ways. I couldn't quite get at the info I wanted -- or couldn't do so fluidly. I couldn't quite do what I needed -- or couldn't do so fluidly.
I gave up on it in under an hour, which is kinda record time for me. I gave SourceTree a couple days, GitX/GitY/etc each got multiple hours, etc.
My team's been using https://rowanj.github.io/gitx/ which has been a godsend - many of the same features, including interactive diff staging and tree view, in a native-feeling Mac interface. But that gitup screencast, how it makes rebasing painless - that's like nothing I've seen before. I'll definitely give gitup a try.
In general, these types of interfaces are VERY useful for junior programmers who aren't used to thinking of Git as a digraph of commits. I'm surprised that they're not used more often in online courses and bootcamps... maybe not enough people know about them yet!
Because IMO struggling and learning "the hard way" first forces people to understand what is actually happening at the git level before using fancy tools like this or Tower to e.g. rebase master or otherwise do complicated unnecessary things because the tool makes them easy to do and "it seemed like the right thing".
There are a lot of ways to do git. If you frequently find yourself needing a GUI tool to do more than compare diffs (there are a few good ones out there), it's very possible that the way you / your team are using git could itself use some work.
If you're very new to git on teams or even if you're more intermediate, https://www.atlassian.com/git/tutorials/comparing-workflows/... is probably worth a read to understand how this stuff can work nicely for projects. It really shouldn't be rocket surgery to cut a new release :)
I just gave my throwaway email address, let them spam it all they want.
I wasn't overly impressed by their app (not to say that it's bad, given the overall scarcity of decent GUI options for Git), but I wanted to take a peek... having to provide some email isn't a showstopper at this point
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.
I don't think this is a dealbreaker for 99% of people. I currently use Tower (https://www.git-tower.com/), a closed-source Mac Git client that costs $70.
It's beautiful, it speeds up my work day to day, and it's been worth every cent. Open source is great and I spend my days building an open-source mail client, but I have no problem paying for great tools.
As a long time git command line user, I've played with different GUI clients, but I don't see where it would speed me up (and in fact, they seem to just slow me down). What about it helps you in your day to day coding? Do you interact with git exclusively through a GUI, or do you use some mix of command line and GUI?
1. interactive staging and committing of only part of a local change. git-cola is way better than the command line flow for this
2. gitk's tree viewing and filtering options are nice. i usually end up just using tig for speed of opening, but if there's a large set of changes i want to navigate through i launch gitk. also it's the easiest way i've found to branch at a particular commit.
I used to be a cli proponent and it worked very well for moderately sized, hardly dynamic repos; for other repos that can see dozens of commits an hour it's much easier to use a GUI. I use it for easier rebasing and cherry-picking, because I can directly see what I'm taking and where I'm putting it, instead of having to first check the log, then copy the hash, then paste it with the right git incantation.
Sometimes using the mouse really is more powerful; sometimes it is not. It is important to see that it can sometimes be your friend.
This, for me. I do most git things through the command line, but I find Tower's GUI very convenient for reviewing my changed files before I commit them.
At that point, I'm basically looking at superficial issues. That's usually the step where I realize I've left some debugging statements in my code, or have some formatting issues that ought to be cleaned up.
Almost exclusively a command-line user too. The one GUI tool I sometimes use is tig -- I like its status view for staging parts of files at a time if I made too many changes at once.
I hate to be that guy, but you're paying $70 for that? What does that offer over, say SourceTree, Atlassian's free offering. From a quick glance, they look pretty similar to me.
Am I the only one who remembers when $70 was cheap for anything development related? Either it's good enough to save you 5-10 minutes a day where it's obviously worth $70 or it's not, and isn't worth any price (well maybe a dollar or two if you are, say, a collector of git clients).
Exactly. I have a Bosch drill and I recently had a carpenter trying to convince me that I should have spent three times as much on a Makita. He was basically trying to show me that the cheaper drill was a false economy. Its hilarious in software how much time we waste dealing with poor tools. Some free tools are excellent but in many cases spending some money will save you so much time and effort, enabling you to make more money and giving some of that to the developers. Wins all round.
The problem isn't the cost in money, it's the cost in time and inconvenience. It sort of manifests in two ways. First, I build my professional workflow around a tool that can simply cease to exist in a few days/weeks/months/years...it puts me at the mercy of the maker of the tool, often needlessly. Second, software that costs money tends to be closed source, which is at odds with community efforts that can improve and shape the software over time, as well as maintain it should the original developer move on. So those issues are the problem, not the $70.
Is this an argument against my point? I'm not unwilling to pay for a tool -- I've even paid for Sublime which is free unless you choose to pay. Is there a reason I should feel compelled to pay for a tool, given a comparable free alternative?
SourceTree is a god awful nightmare of a UI and I have found myself having to triple check all the checkboxes present before I do anything lest I manage to hose it up. I would use absolutely no GUI if my option was that or SourceTree. I also hear the latest update has been a real punch to the gut for people as well.
I branch and merge in moments at least a half dozen times a day in Tower. Getting to diffs, creating patches, and viewing changesets are easy and pleasant to look at. It has built I support for a Gitflow workflow so naming conventions and everything allow for one or two clicks to go from no feature branch to a new one.
Frankly, it's just pleasant to use, doesn't screw up my source, and makes it easy to get my code committed and pushed.
So does SourceTree. Have you tried using it? If so, what issues have you found with it? Personally, I don't use it, so I can't speak to its functionality.
> I branch and merge in moments at least a half dozen times a day in Tower.
I do the same in SourceTree, and find it trivial, but perhaps it's just a usage difference. If you want to use Tower go for it -- I have no affiliation with Atlassian to push the product on you, I just enjoy it. I'm just surprised at how much Tower costs.
It's funny because I generally regard Atlassian products as at the worst, not bad. That is to say, I don't feel like anything they do sucks, some things I really like, some things I'm meh about. Except SourceTree. Maybe because I'd been using Tower for nearly a year by the time I came across SourceTree. Maybe because it's such a Windows feeling application. I don't know. I'm sure most of my dislike is illogical at this point, but it still is there.
I don't feel like $70 is very much for something that feeds my family. I use it all day every day and the work I do with it allows my wife to stay home with my kids. If people didn't pay me to build the software that _I_ build, this wouldn't be possible. It's the same reason I choose IntelliJ over Eclipse or other IDEs. If the price difference is justified by my effctiveness with your tool, I'm spending the money without hesitation.
The only caveat I have is, even if your product is the best, if your company is shifty or a bad actor- I'll do whatever I can to avoid it.
> What does that offer over, say SourceTree, Atlassian's free offering.
An intuitive interface and a simpler layout. I like Tower better for the same reason I like to use a trackpad over a mouse. Day to day, the difference is obvious and positively impacts my performance.
Really? Both you and another commenter said as much, but I've never seen this problem, or known anyone who experienced that across probably a dozen people I've worked with over the span of three (?) years. I'm actually not even sure what options you could use that would cause that. Do you have examples?
SourceTree's latest update makes you login to an Atlassian account just to be able to use the app. That has been a deal-breaker for an otherwise great app.
Much like GitKraken, the site is completely unhelpful and doesn't have any screenshots. Why would I download, much less pay for, a piece of software which I haven't even seen?
Wow, that's ridiculously expensive! Especially considering the OFFICIAL client is free software.
I also think you exagerate with it not being a deal breaker. I don't know any software developer IRL that uses proprietary git clients, or other developer-specific tools which are proprietary.
Maybe most people don't care about FLOSS/propietary, but devs tend to care a lot more.
I'm in an office surrounded by people using Visual studio on windows, running Perforce. We do have some git infrastructure, and anyone that interacts with that uses sourcetree. I know that the diff tools of choice are Araxis Merge/P4Merge/Beyond Compare. There's also people using VisualAssist on top of Visual Studio.
There's plenty of developers who don't mind using proprietary tools
I'm not concerned by the fact that it's closed source alone, but by the fact that it's both closed source and free-as-in-beer. You know, the whole "if you are not paying for the product you are the product" thing.
According to the FAQ it's free while they're iterating until they start a freemium model, which makes sense. But in that case I prefer the InteliJ model, where the community version is also open source.
Seems like you should investigate that, then. The first step is noticing that you may be acting irrationally. The second step is correcting (if in fact it turns out to be irrational, which I'm not claiming).
There are very good reasons not to get invested into non-free software, starting with privacy concerns.
Speaking of which, https://www.axosoft.com/privacy seems to say that the application is allowed to send home virtually unlimited amount of information about your repositories and the work you do in them.
Okay, I purposefully and carefully avoided taking a stance on whether or not one should invest in non-free software. You missed that apparently, as did the people downvoting me.
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.
Legal derivative works under copyright law of a particular computer program are not the same thing as programs which functionally interact with them -- functional interaction doesn't make a work derivative.
But what if the entire core functionality of the program relies on an open source program? This is the case here, I would argue.
ps. I realize that in a technical sense my comment is "wrong", hence the downvotes, but what I'm getting at is, doesn't this horribly break the spirit of the GPL?
That's almost certainly not the point being made. Building a workflow around non-free development tools means that eventually you're going to find support for your favored tool evaporating.
Using non open source tools is Harlech ever a problem. Yes the support can disappear, but so can one for FLOSS software. I am working on a tool which is based on a graveyard of abandonned open source libraries and taking them over is absolutely not an option. The only thing you can do is to slowly move to an alternative and hope that it will get maintained. With tools the choice is usually very easy because you can switch to other tools any time.
This seems only be a problem for software developers though. Every other profession out there builds their workflows around proprietary expensive tools and it works out all fine.
But we software developers are a special kind. We expect people to work for free (as in no money) to create tools for us we then can use to earn money.
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.
I use both with git, nothing wrong with that. A GUI client for committing which allows me to better look at diffs and makes selecting files for staging easier, not having to do `git status` all the time; and the command line for everything else - pulls, merges, rebases, cherry picking etc etc.
PyCharm / any IntelliJ-based IDE, Atom, vim, emacs etc can also all nicely show git status of your current project. I'd suggest one of those as well in whatever flavor of editor you prefer.
I'm using mostly IntelliJ / PyCharm and Atom which indeed show me that status. I usually commit either with IntelliJ directly (though sometimes it's too inclusive which is annoying), or with gitg.
>Ridiculously arrogant comment with nothing to back it up. GUIs exist; get over it.
A simple google search for "How to use git without command line" will show you the amount of people who are looking for just that, I said most, not all, I believe git is a developer tool that's mostly used by dev who can navigate their way around CLI, lately i've seen and worked with non devs who want to just use GUI tools to help them around without having to know the details of what's going under the hood, this submission is a good example of that, it lacks every single tool that a developer that works in a big team with a big codebase needs. so yes, it's a tool for people who don't want to use the CLI properly. nothing arrogant at all.
>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.
This doesn't seem to be exactly a FLOSS per say, but I get your point, they're just doing it the wrong way, if you're gonna start something that you want to be on par with other tools, at least get out your beta with the same features, then add up on that post beta, but they're not doing that, they're releasing a GUI tool that has the basics of git, with videos and js animations. and if i'm going to even consider using that in a production environment I'd rather have a more serious T&C that will make me feel a bit safe that this thing will be supported and will live on for a few years ahead and not die, "It's just a beta" is something i'm really tired of hearing as an excuse to a crippled product, gmail was in beta for way to long and it was superior to all existing email solutions at the time, no one would've used it if it only supported sending and receiving emails, I wouldn't call his git client a beta either, it's more of an alpha experimental product IMHO.
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.
This is totally backwards. HTML has no good elements for long lists at all, leading to janky techniques like "infinite scroll." But NSTableView was designed from the start with very long lists in mind.
Try opening a large repo and scrolling a list of commits in GitKraken. You'll see large blank areas that get filled in after a few seconds. Now try it in, say, GitUp, which uses NSTableView: it is perfectly smooth.
I don't see any complex NSTableView in GitUp, they definitely use something other. When i worked at Telegram, we worked hard to make default lists smooth and it is almost impossible. Eventually main client became Qt-based instead of native frameworks.
All other Git tools also very slow on my MPB Retina. All of them are laggy in lists and only lists.
Having nothing good for long lists doesn't matter as rendering pipline on OSX didn't updated for a years. Almost everything in UI on OSX is still software rendered instead of GPU. And Chrome extensively use GPU for rendering and that outperforms everything.
GitUp also loads the entire repo history in memory in a very optimized way, which is a key reason why it's so fast. Incidentally, this is something a web app like GitKraken can pretty much only dream of.
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.
Hey! Love git-cola, and I'll hijack the thread here for a quick question. Maybe I am missing something but I didn't see anyway to easily mark which commits I want to rebase in the UI.
For example, in the command line I would have to open a git log and then see that I want to do something like git rebase HEAD~3, or any of the more complicated parameters needed for rebase (such as git rebase --onto <master> <next> <topic>).
In particular, you really want a 3-way merge tool (which compares yours and theirs to the common ancestor) for resolving conflicts. Meld didn't used to have this, but it looks like it does now. FWIW, on OS X you can also configure git to use opendiff (which opens FileMerge). It does the job pretty well.
Source: my day job used to involve daily merging of Chromium with Rockmelt and I probably evaluated every merge tool that existed at the time.
A little off-topic: since 10.10 or so, FileMerge has started opening the bottom, free-editing pane by default—and at a random height, at that. Has anyone figured out how to disable that? It's driving me into the arms of a different, otherwise inferior diff tool.
Sure. I use kaleidoscope (or vimdiff if necessary). It's a little confusing to see git clients completely neglect this, though—how much time do you really use looking at pretty commit graphs as opposed to actually working with code?
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.
To be completely honest, I also do it like this at the moment, using Kdiff as a merge tool. I've been thinking about moving over to Ediff, but I'm lazy.
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.
In my situation I use gitg to add changes by chunks or lines, I think that's much more faster than cli.
But gitg is hard to compile on Ubuntu lts if you want newer versions, I wonder if there is a good alternative?
I generally do that sort of thing(staging/destaging lines and chunks) in my editor. If I could shift the merge tool stuff into my editor quickly I would do that as well.
The reason is that it reduces context switching and difference between environments: sure, I could spend hours making the fonts, colours, and keybindings the same between the git gui and my editor; I could get really good at switching to the window; etc. But even a slightly worse version of it in the editor is going to be way less work.
At least, that's how I see it.
Also, I'm sure there must be a PPA or something for gitg on Ubuntu, if you really like the tool.
So you're basically just arguing that their webpage doesn't have a good layout. If you want to dismiss the product because of that, that's your choice, but I wish people would keep complaints about website design to themselves. They're so boring. I come to HN to read insightful commentary about articles and projects, and complaints about the websites themselves just make me roll my eyes.
To be honest, this is actually a good strategy ... producing a poor layout that is. I've found a lot of times, a post either has a lot of comments/votes because the product idea was stupid and/or something unrelated about the product was less than impressive.
So if you are launching a product on Hacker News, it might be worthwhile to create two separate landing pages. Create one that is less than informative/provocative to get the votes/comments and then switch to a more informative one when you have secured a front page position.
But bad websites are correlated with bad products: the same incompetents are responsible for both, either directly or indirectly through accepting the work of bad designers and consultants.
Personally, I found the fullscreen pointless animations an arrogant abuse of my bandwidth and of my eyes, and the lack of content above and below the fold (and of scrolling and of the fold itself) a powerful source of claustrophobia; I noticed the tiny links to merely bad pages moments before closing the page in anger.
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.
Believe it or not, these guys are still using Visual Source Safe. They find "git pull, git checkout -b, git commit -a, git pull, open merge request on gitlab" too cumbersome for their day-to-day activities.
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.
I agree. I use it on a daily basis. It has a lot of shortcomings, but I still find it more convenient to use than SourceTree. I'm not aware about any other sensible GUI clients for Windows.
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.
I'd like to see it honor the settings defined in ~/.ssh/config . Currently you can only choose one key in the settings which doesn't work so well if you have both github and bitbucket repos to manage let alone repos from 2 github and 1 bitbucket accounts.
You can configure different keys for generic/github/bitbucket. Only one each, but I think the default github workflow is to have a single user account that belongs to different organizations.
This makes repos look cool, but I'm not quite sure what benefit this offers over just using cli git in combination with gitk (for easy visualisation). I like the icon/gravatar thing, but since most people don't use gravatar there is just a lot of "space invaders" and no names unless I click on the commit.
has anyone ever found the spaghetti tangle of branches diagram useful for anything?
every git gui provides one but I've never managed to parse any useful info from it. maybe you have to be supernaturally disciplined about your commit history or something. or maybe they're just fun to build, yay data visualisations etc
RPM is the Redhat and SUSE which are major commercial players in Linux. My library was Redhat only in the college I worked at (I actually got to make that switch happen)and still is. Now I work with OpenSUSE at my company.
> Subject to the terms and conditions of this Agreement, 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.
Wait, this is the same axosoft that makes ontime? I use ontime every day, and generally hate it. But I'm not sure if that's their fault, or my company's fault in the setup process :)
I guess by support they mean creating PRs etc directly from the client. Which from the screenshots seems to currently to be the public github.com and bitbucket.org.
However I would very surprised if they did not support normal git remotes so it is irrelevant if that is Github Enterprise, Bitbucket server(Stash), Gitlab or whatever.
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.