Fork: A fast and friendly Git client for Mac and Windows(fork.dev)
fork.dev
Fork: A fast and friendly Git client for Mac and Windows
https://fork.dev
172 comments
I don't really understand the upside for them to include such toothless yet threatening clauses. It makes them seem a bit juvenile.
Like when we had to come up with laws for our make-believe countries for a class project in middle school and we tried to cover our bases with rules like "if you're a bad person doing all bad stuff, you're not allowed to!"
Like when we had to come up with laws for our make-believe countries for a class project in middle school and we tried to cover our bases with rules like "if you're a bad person doing all bad stuff, you're not allowed to!"
It's pretty clear that those terms are all defined in the context of whatever they might mean under Czech law, which I am not familiar with.
Also, those quotes are taken out of context for dramatic effect:
You will not engage in using this Software that will interfere with or damage the operation of the services of any third parties by overburdening/disabling network resources through automated queries, excessive usage or similar conduct.
You will not use this Software to engage in any activity that will violate the rights of third parties, including, without limitation, through the use, public display, public performance, reproduction, distribution, or modification of communications or materials that infringe copyrights, trademarks, publicity rights, privacy rights, other proprietary rights, or rights against defamation of third parties.
GP is really trying hard to smear this author for some reason, but you read the actual license you'll see that their criticism is based on fiction.
Also, those quotes are taken out of context for dramatic effect:
You will not engage in using this Software that will interfere with or damage the operation of the services of any third parties by overburdening/disabling network resources through automated queries, excessive usage or similar conduct.
You will not use this Software to engage in any activity that will violate the rights of third parties, including, without limitation, through the use, public display, public performance, reproduction, distribution, or modification of communications or materials that infringe copyrights, trademarks, publicity rights, privacy rights, other proprietary rights, or rights against defamation of third parties.
GP is really trying hard to smear this author for some reason, but you read the actual license you'll see that their criticism is based on fiction.
Whoops, that was pretty silly of me to miss the Czech.
However I stand by my criticism that it is not possible to know if you are violating the license or not. I don’t want to have to learn and follow Czech law to use a git client. Why does this agreement cover how I use third party services and who defines what qualifies as interfering? How far does my obligation to not allow others to reverse engineer the application go? What rights might third parties have under Czech law that I have to worry about while using the software?
Compare Microsoft Windows’s license:
https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/U...
It also says you can’t reverse engineer, but it does not obligate you to stop others. It’s section about online service is a little bit more explicit about what is not allowed. There are no other requirements to follow every law of a particular jurisdiction while using the software.
However I stand by my criticism that it is not possible to know if you are violating the license or not. I don’t want to have to learn and follow Czech law to use a git client. Why does this agreement cover how I use third party services and who defines what qualifies as interfering? How far does my obligation to not allow others to reverse engineer the application go? What rights might third parties have under Czech law that I have to worry about while using the software?
Compare Microsoft Windows’s license:
https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/U...
It also says you can’t reverse engineer, but it does not obligate you to stop others. It’s section about online service is a little bit more explicit about what is not allowed. There are no other requirements to follow every law of a particular jurisdiction while using the software.
However I stand by my criticism that it is not possible to know if you are violating the license or not. I don’t want to have to learn and follow Czech law to use a git client.
Surely this applies to anyone using a piece of US-made software living outside the US. And without a governing law clause, isn't it always ambiguous?
Why does this agreement cover how I use third party services and who defines what qualifies as interfering?
Who am I to judge. That's what they want.
How far does my obligation to not allow others to reverse engineer the application go? What rights might third parties have under Czech law that I have to worry about while using the software?
Now that's a good question and the license should be clearer on that.
Surely this applies to anyone using a piece of US-made software living outside the US. And without a governing law clause, isn't it always ambiguous?
Why does this agreement cover how I use third party services and who defines what qualifies as interfering?
Who am I to judge. That's what they want.
How far does my obligation to not allow others to reverse engineer the application go? What rights might third parties have under Czech law that I have to worry about while using the software?
Now that's a good question and the license should be clearer on that.
> Surely this applies to anyone using a piece of US-made software living outside the US. And without a governing law clause, isn't it always ambiguous?
I don't think most software licenses say you can't violate some country's laws while using it. It is already illegal to do the illegal thing.
> Who am I to judge. That's what they want.
I'm not judging either. I am not able to confidently follow these terms, so I won't use the software. No hard feelings.
I'm guessing that the license author's intention was to avoid legal liability for people doing illegal things with their software. Usually this is addressed with some language in the license about limitation of liability or or indemnification. For example, see section 3.8 of Atlassian's software agreement:
https://www.atlassian.com/legal/software-license-agreement
I don't think most software licenses say you can't violate some country's laws while using it. It is already illegal to do the illegal thing.
> Who am I to judge. That's what they want.
I'm not judging either. I am not able to confidently follow these terms, so I won't use the software. No hard feelings.
I'm guessing that the license author's intention was to avoid legal liability for people doing illegal things with their software. Usually this is addressed with some language in the license about limitation of liability or or indemnification. For example, see section 3.8 of Atlassian's software agreement:
https://www.atlassian.com/legal/software-license-agreement
> You will not use this Software to engage in any activity that will violate the rights of third parties, including, without limitation, through the use, public display, public performance, reproduction, distribution, or modification of communications or materials that infringe copyrights... other proprietary rights...
OK, not allowed to use it for reverse engineering or other research the DMCA attempts to block?
OK, not allowed to use it for reverse engineering or other research the DMCA attempts to block?
> It makes them seem a bit juvenile.
It's also apparently one individual, and non-US. I've seen many clauses like that in European, especially eastern European, software. Sometimes, even in countries like Australia. It's inspecific, but seems pretty clear they're trying to say, "don't use our software for something you shouldn't." They're within their rights to desire that.
Would you perhaps want to edit your comment to remove the rather patronising comments about "like... laws for our make-believe countries", "middle school", etc?
It's also apparently one individual, and non-US. I've seen many clauses like that in European, especially eastern European, software. Sometimes, even in countries like Australia. It's inspecific, but seems pretty clear they're trying to say, "don't use our software for something you shouldn't." They're within their rights to desire that.
Would you perhaps want to edit your comment to remove the rather patronising comments about "like... laws for our make-believe countries", "middle school", etc?
It did not seem that they were used by the poster to patronize, they were there to describe a task (creating laws for make-believe countries) that they performed at one stage of their life (middle school).
Is not a direct comparison between the author and middle school attitudes and conduct and being juvenile extremely patronising? (Almost by definition, given the description 'juvenile', ie youthful or child-like.)
There's conduct and commentary that follows the Hacker News ethos, and there's conduct and commentary that does not. This does not. It is a pity to read it.
There's conduct and commentary that follows the Hacker News ethos, and there's conduct and commentary that does not. This does not. It is a pity to read it.
Not being the author I can not definitively express their intent.
You seem to desire to be an enforcer of rules in this thread, which is admirable, but ultimately not your authority or responsibility to do. I would respectfully suggest you leave moderation to those with the authority to do so.
You seem to desire to be an enforcer of rules in this thread, which is admirable, but ultimately not your authority or responsibility to do. I would respectfully suggest you leave moderation to those with the authority to do so.
I can answer one of your questions: "This agreement shall be governed by the laws of Czeck Republic. If any portion of this Agreement is deemed unenforceable by a court of competent jurisdiction, it shall not affect the forcibility of the other portions of this Agreement."
Though, this license is pretty much radioactive for me: "You will not, and will not permit others to reverse engineer, decompile, disassemble, derive the source code of, modify, or create derivative works from this Software..."
Fair enough if you want to use whatever license you want to use, but definitely a "no thanks" from me...
Though, this license is pretty much radioactive for me: "You will not, and will not permit others to reverse engineer, decompile, disassemble, derive the source code of, modify, or create derivative works from this Software..."
Fair enough if you want to use whatever license you want to use, but definitely a "no thanks" from me...
I really like those "no reversing" clauses.
Because they are worth less than the bits used to write them in Poland - only the "distribute derivative works" would be enforceable because that would be blatant copyright violation
Because they are worth less than the bits used to write them in Poland - only the "distribute derivative works" would be enforceable because that would be blatant copyright violation
gray_-_wolf(2)
A closed source git client, that's almost an oxymoron.
No it isn't.
Git kraken, sublime merge, sourcetree. It is pretty common among the most famous ones, just look at the list on wikipedia, https://en.wikipedia.org/wiki/Comparison_of_Git_GUIs
Git kraken, sublime merge, sourcetree. It is pretty common among the most famous ones, just look at the list on wikipedia, https://en.wikipedia.org/wiki/Comparison_of_Git_GUIs
Either quotes have been deliberately taken out of context, or the author has updated the license. It now reads:
By using this Software or storing this program or parts of it on a computer hard drive (or other media), you are agreeing to be bound by the terms and conditions of this Agreement. You represent and warrant that you will not violate any of the requirements of this Agreement and further represent and warrant that:
You will not, and will not permit others to:
1) reverse engineer, decompile, disassemble, derive the source code of, modify, or create derivative works from this Software, or
2) copy, distribute, publicly display, or publicly perform content contained in this Software other than as expressly authorized by this Agreement.
You will not use this Software to engage in or allow others to engage in any illegal activity.^
You will not engage in using this Software that will interfere with or damage the operation of the services of any third parties by overburdening/disabling network resources through automated queries, excessive usage or similar conduct.*
You will not sell this Software or charge others for use of it (either for profit or merely to recover your media and distribution costs) whether as a stand-alone product, or as part of a compilation or anthology, without explicit prior written permission.
You will not use this Software to engage in any activity that will violate the rights of third parties, including, without limitation, through the use, public display, public performance, reproduction, distribution, or modification of communications or materials that infringe copyrights, trademarks, publicity rights, privacy rights, other proprietary rights, or rights against defamation of third parties.
You may not claim any sponsorship by, endorsement by, or affiliation with me.
By using this Software or storing this program or parts of it on a computer hard drive (or other media), you are agreeing to be bound by the terms and conditions of this Agreement. You represent and warrant that you will not violate any of the requirements of this Agreement and further represent and warrant that:
You will not, and will not permit others to:
1) reverse engineer, decompile, disassemble, derive the source code of, modify, or create derivative works from this Software, or
2) copy, distribute, publicly display, or publicly perform content contained in this Software other than as expressly authorized by this Agreement.
You will not use this Software to engage in or allow others to engage in any illegal activity.^
You will not engage in using this Software that will interfere with or damage the operation of the services of any third parties by overburdening/disabling network resources through automated queries, excessive usage or similar conduct.*
You will not sell this Software or charge others for use of it (either for profit or merely to recover your media and distribution costs) whether as a stand-alone product, or as part of a compilation or anthology, without explicit prior written permission.
You will not use this Software to engage in any activity that will violate the rights of third parties, including, without limitation, through the use, public display, public performance, reproduction, distribution, or modification of communications or materials that infringe copyrights, trademarks, publicity rights, privacy rights, other proprietary rights, or rights against defamation of third parties.
You may not claim any sponsorship by, endorsement by, or affiliation with me.
Does that seem like a reasonable license to you? Admittedly, it doesn't matter, because these authors don't have the resources to hire lawyers from abroad, but all this stuff about "illegal activity"? This is a git client. It gives us no functionality that does not already exist in git. What am I going to do, rob a convenience store with it? Why would the author care if I did? Why are the terms more onerous than those of git itself?
Even in the US, it's common to have clauses about specific illegal activity, such as breaking embargoes or similar. For example, you might be banned from using the software in, or cooperating with someone located in, Iran. You could do both of those with a git client.
This is more generally phrased than the very lawyer-written EULAs you generally find, but it's not unreasonable or unprecedented.
This is more generally phrased than the very lawyer-written EULAs you generally find, but it's not unreasonable or unprecedented.
Assuming for the sake of argument that I'm not supposed to collaborate with someone in some particular place... why again do the authors of these clients care about that? Are the black-bag squad going to disappear them because they didn't warn us to be good? Actually the charitable interpretation is probably that this is a sort of cargo-culted license without much informed decision-making behind it.
Embargoes and sanctions have no ethical force behind them anyway. They are merely a way to harm poor people while ginning up more pretexts for more wars. Anyone who can oppose such monstrosities using git should do so.
Embargoes and sanctions have no ethical force behind them anyway. They are merely a way to harm poor people while ginning up more pretexts for more wars. Anyone who can oppose such monstrosities using git should do so.
Rather than protecting themselves, it's more likely that the author of the software desires that their software is only used for legal or ethical purposes, and that clause is their attempt to require that.
It's fair for a software author to not want their software used to make the world worse. I think you have a very different interpretation of "charitable interpretation" than I do.
As for embargoes - sure. It's just an example. There are plenty of other less morally ambiguous things too.
It's fair for a software author to not want their software used to make the world worse. I think you have a very different interpretation of "charitable interpretation" than I do.
As for embargoes - sure. It's just an example. There are plenty of other less morally ambiguous things too.
It seems reasonable because they're within their rights to license their software however they want, subject to the laws of the Czech Republic.
Whether it's enforceable, sure, that might be questionable.
Whether it's enforceable, sure, that might be questionable.
It would be within my rights to repeatedly batter my own head with a hammer. It would not seem reasonable, however. Most of the thinking behind this license is of the cargo-cult variety, and these valiant defenses of developers' rights are just silly.
If I cared about a git client for these platforms, I would file a bug about the license. Fortunately that is not the case.
If I cared about a git client for these platforms, I would file a bug about the license. Fortunately that is not the case.
What a silly license. Why do people insist on rolling their own? It's quite amazing to me, especially when it comes to things like cryptography and legal texts. Surely any lawyer could point at these phrases and say what you're saying now -- how do you define this? Sure, you could argue that keeping it vague is a way to protect the authors, but I'd argue that a competent lawyer would write it in a less vague way, to protect the authors even more -- if it was necessary. Is it? I doubt it, considering the type of software we see under insanely brief licenses like the MIT.
The MIT license is extremely permissive. It's a stupid measuring post for comparison, because it basically doesn't say anything at all.
Yes, they could have consulted with and paid a lawyer to tighten up the wording. But unless you either own a company, or intend to use this in consulting work, I don't think this license should bother you at all. The intent and general meaning are pretty clear, even if you could argue over the definition of one word or another.
Yes, they could have consulted with and paid a lawyer to tighten up the wording. But unless you either own a company, or intend to use this in consulting work, I don't think this license should bother you at all. The intent and general meaning are pretty clear, even if you could argue over the definition of one word or another.
Jurisdiction is right there on the bottom:
Governing Law
This agreement shall be governed by the laws of Czeck Republic. If any portion of this Agreement is deemed unenforceable by a court of competent jurisdiction, it shall not affect the forcibility of the other portions of this Agreement.
It is clear that those clauses are ONLY trying to protect them, the authors, from liability for the actions of others using their software. Perfectly reasonable.
It is clearly not written by a lawyer (IANAL), it may not be legally bullet proof, but this is freeware by a couple of people in their spare time. FOR FREE.
Governing Law
This agreement shall be governed by the laws of Czeck Republic. If any portion of this Agreement is deemed unenforceable by a court of competent jurisdiction, it shall not affect the forcibility of the other portions of this Agreement.
It is clear that those clauses are ONLY trying to protect them, the authors, from liability for the actions of others using their software. Perfectly reasonable.
It is clearly not written by a lawyer (IANAL), it may not be legally bullet proof, but this is freeware by a couple of people in their spare time. FOR FREE.
Despite this and as someone doing only "vanilla" non-controversial stuff in (afaik) any jurisdiction I can at the very least say that as a git gui client, it works really well. So there's that.
Worse yet these are not concrete points. Laws change. Things happen. Worse yet you need a lawyer from the appropriate jurisdictions just to figure out if you are lawfully using the software? At which point if you ignore the license now you are a pirate of sorts.
That applies to any license, doesn't it?
Congress could abolish the public domain or ban stuff like the GPL.
Congress could abolish the public domain or ban stuff like the GPL.
IANAL, but I'm fairly sure banning "stuff like the GPL" would mean banning every EULA and software license, as that's really all the GPL is.
Eben Moglen (Free Software Foundation) sums up the differences:
> But most proprietary software companies want more power than copyright alone gives them. These companies say their software is “licensed” to consumers, but the license contains obligations that copyright law knows nothing about. Software you're not allowed to understand, for example, often requires you to agree not to decompile it. Copyright law doesn't prohibit decompilation, the prohibition is just a contract term you agree to as a condition of getting the software when you buy the product under shrink wrap in a store, or accept a “clickwrap license” on line. [..]
> The GPL, on the other hand, subtracts from copyright rather than adding to it. [..] Copyright grants publishers power to forbid users to exercise rights to copy, modify, and distribute that we believe all users should have; the GPL thus relaxes almost all the restrictions of the copyright system. The only thing we absolutely require is that anyone distributing GPL'd works or works made from GPL'd works distribute in turn under GPL. [..]
https://www.gnu.org/philosophy/enforcing-gpl.en.html
Eben Moglen (Free Software Foundation) sums up the differences:
> But most proprietary software companies want more power than copyright alone gives them. These companies say their software is “licensed” to consumers, but the license contains obligations that copyright law knows nothing about. Software you're not allowed to understand, for example, often requires you to agree not to decompile it. Copyright law doesn't prohibit decompilation, the prohibition is just a contract term you agree to as a condition of getting the software when you buy the product under shrink wrap in a store, or accept a “clickwrap license” on line. [..]
> The GPL, on the other hand, subtracts from copyright rather than adding to it. [..] Copyright grants publishers power to forbid users to exercise rights to copy, modify, and distribute that we believe all users should have; the GPL thus relaxes almost all the restrictions of the copyright system. The only thing we absolutely require is that anyone distributing GPL'd works or works made from GPL'd works distribute in turn under GPL. [..]
https://www.gnu.org/philosophy/enforcing-gpl.en.html
> IANAL, but I'm fairly sure banning "stuff like the GPL" would mean banning every EULA and software license, as that's really all the GPL is.
You can specifically ban (or make unenforceable) any subset of copyright licenses without banning copyright licenses generally.
You can specifically ban (or make unenforceable) any subset of copyright licenses without banning copyright licenses generally.
How would that law be written? If it mentioned GPL by name (which I don't think would be Constitutional?), we'd just use a different name for it. If it zeroed in on particular legal idioms used by GPL (which probably are also used by thousands of other licenses), GPL could be modified to use different idioms. If the law were general enough to take out GPL for good, it would be general enough to take out all software licenses for (very) good.
> would mean banning every EULA and software license
That seems proper. AFAIK, these have (statistically) never protected the public, so the legalese is there for protect the company's ability to restrict and penalize the user, as well as fill the pockets of lawyers.
That seems proper. AFAIK, these have (statistically) never protected the public, so the legalese is there for protect the company's ability to restrict and penalize the user, as well as fill the pockets of lawyers.
No, the problem is with general and sudden redefinitions of stuff like "illegal activity", which makes the license as written vague and unstable, even without changes to contract and copyright law that would interfere with the more basic level of offering, accepting and enforcing a license (irrespective of its content)
The GPL is much more specific in its terms. I imagine people who break laws wont care about this software license anyway. You cant stop criminals by giving them more rules / laws to follow. Just wont ever happen.
Alongside a donation link, you should put a "purchase a license" or "purchase a subscription" link. That way, an engineer can upload the resulting receipt to expensify and get reimbursed by their employer.
Employers are used to paying for software licenses out of engineering budgets; Donations would generally come out of a different budget managed by someone an engineer doesn't work with day-to-day.
Employers are used to paying for software licenses out of engineering budgets; Donations would generally come out of a different budget managed by someone an engineer doesn't work with day-to-day.
Another +1 for them adding a price to this. It's a really good program and even as a solo indie developer, I want to give them money so they can afford to keep working on it. Customer support takes time too, I've already emailed them about one bug & used up some minutes of the developer's time.
Preferably not a subscription, though. The whole reason I started using Fork is because their competitor Tower switched to a subscription model, so I started looking for competitors. The Fork developers seem keen on keeping it free, so maybe something like the Sublime Text / REAPER model where it has a nag screen on startup but will keep working anyway (useful for us indie developers until the money rolls in). I also like the idea of no internet-based licensing, so if the company ever disappears I can still use the software.
Preferably not a subscription, though. The whole reason I started using Fork is because their competitor Tower switched to a subscription model, so I started looking for competitors. The Fork developers seem keen on keeping it free, so maybe something like the Sublime Text / REAPER model where it has a nag screen on startup but will keep working anyway (useful for us indie developers until the money rolls in). I also like the idea of no internet-based licensing, so if the company ever disappears I can still use the software.
I think the point is that it should remain a free project but put an artificial "price" instead of a donation link. This is similar to what SQLite does (offering a $1000 license, where you're basically paying for a piece of paper saying "no really, you can use this freely").
Plus the phone number of a developer, with a response 24/7, I think.
Support is actually an entirely different (and much more expensive) concept. Business Hours phone support starts at 8k, but 24/7 phone support costs as much as 85k/year.
https://sqlite.org/prosupport.html
https://sqlite.org/prosupport.html
I'm also looking for an alternative to Tower. Their subscription model is too expensive.
On the plus side I find Fork to be performant and clean. I prefer it over Kraken and Tower and I find it vastly better than SourceTree. I also find it somewhat similar to GitX-dev on the Mac, which is a good thing.
On the minus side (and it's a big minus), it's not open source. As a developer of commercial software I basically have to trust the Fork developers not to do anything fishy with all the source code / IP that I am opening up to the app.
On the minus side (and it's a big minus), it's not open source. As a developer of commercial software I basically have to trust the Fork developers not to do anything fishy with all the source code / IP that I am opening up to the app.
Aren't all the other ones you mention closed source as well? Like Kraken and SourceTree for sure.
Sourcetree is provided by Atlassian, a large well-known company.
Fork is made by one person.
Not making any assumptions here, but if you're evaluating risks around compromises in one of the two products, I think Fork is higher risk.
Fork is made by one person.
Not making any assumptions here, but if you're evaluating risks around compromises in one of the two products, I think Fork is higher risk.
Moreover, the business model of Sourcetree is somehow clear: attract users to BitBucket, and, hence, to Atlassian.
The business model of Fork is unknown, so to me it's a clear no-no. Can't afford to put a tool in my workflow not knowing if in a few months it will become yet another service I must subscribe to
The business model of Fork is unknown, so to me it's a clear no-no. Can't afford to put a tool in my workflow not knowing if in a few months it will become yet another service I must subscribe to
What’s an open source app for github? Can’t we run gitlab on a local server?
You can run GitLab on a local server https://about.gitlab.com/pricing/#self-managed
GitHub has a very specific business model and yes, you can run gitlab on your local server.
It is very disappointing that in 2019 we still have to rely on trusting a software vendor or reading the app souce code if it is available. That would be great to we have an OS-level system to give fine-grained permissions and restrictions to desktop apps, like on lineageOS?
How would fine grain permissions solve the problem of software doing something fishy with the code you give it access to?
White list for network access?
Disabling unsafe and unnecessary sys calls in containers (not Docker) and forcing apps to communicate via API with capabilities management would let you do this now, I think. In fact, sandstorm.io is said to do all this. And it's open-source. I never used it, except the demo. And I'm not sure if its PowerBox (manages capabilities) is fully implemented.
> like on lineageOS?
Android/LineageOS is Linux.
Just type adduser and sudo, it's not too bad.
You'll probably find, however, that it might not be all you were looking for. It can still steal your source code and credentials, which might have been what you were worried about.
You will also miss out on your editor, compiler, zip utilities, and whatever else that's not included in your git client. Anything useful would probably look more like privileges (where opening a file can be ok but a network socket forbidden). There's been a ton of research in this area and some very mature systems such as SELinux.
Android/LineageOS is Linux.
Just type adduser and sudo, it's not too bad.
You'll probably find, however, that it might not be all you were looking for. It can still steal your source code and credentials, which might have been what you were worried about.
You will also miss out on your editor, compiler, zip utilities, and whatever else that's not included in your git client. Anything useful would probably look more like privileges (where opening a file can be ok but a network socket forbidden). There's been a ton of research in this area and some very mature systems such as SELinux.
It looks like it's a WPF app on Windows and a Cocoa app (via Xamarin.Mac) on macOS. It feels good to not try something based on Electron for once.
I wonder if they used a cross platform library abstracting the two.
It looks like I was wrong: the macOS version has lots of Swift frameworks inside of it and no hints of Xamarin, they appear to be two completely separate apps
So essentially: Mac app written with Cocoa/ObjC/Swift and the Windows app written with C# and WPF. A great example of native software.
I'd prefer something like Fork over something like GitKraken IMHO. I cannot imagine the performance of some electron alternatives if I were to open a repository with 200k commits, but this can be resolved with shallow cloning.
Even if it has lots of Swift frameworks embedded, as soon as they switch to Swift 5 and Mojave and higher, Swift will become built in with no dylibs.
I'd prefer something like Fork over something like GitKraken IMHO. I cannot imagine the performance of some electron alternatives if I were to open a repository with 200k commits, but this can be resolved with shallow cloning.
Even if it has lots of Swift frameworks embedded, as soon as they switch to Swift 5 and Mojave and higher, Swift will become built in with no dylibs.
To be clear, I was interpreting the abundance of Swift frameworks as proof of it being written in Swift, not as something bad (a ton of Swift frameworks is still a lot better than Chromium + node + a ton of npm packages)
I'm curious why they didn't use Xamarin.Mac though, they could have shared a lot of code between apps.
I'm curious why they didn't use Xamarin.Mac though, they could have shared a lot of code between apps.
The Mac version came first and later they decided to port it to windows.
If it is a WPF app on Windows and it's described as performant, then WPF as come a hell of a long way.
As someone pretty comfortable with got on the command line, what advantages would a GUI give me? I’m not trolling, it’s an honest question. Anyone with good got command line skills move to something like this and find it offers them a better workflow?
I use a Git GUI, not because it's more efficient or because it enables better workflows, but it's more comfortable for me.
- When I'm browsing the history, I can scroll up and down the list of commits and see the diff of each one by clicking on it.
- When I'm cherry-picking a commit, I can just drag the commit onto the branch.
- When I'm modifying a branch or a remote, I can right-click on it and go to Delete or Rename.
- When I'm resetting to an old commit, I can right-click on it and go to Reset.
Basically, I like to refer to things by pointing to them, and interacting by clicking or dragging. All of those things I just mentioned are trivial using the command-line — with the exception of modifying a branch or remote, you just have to write the git subcommand and its arguments. But having a Git resource as a tangible "thing" on the end of my mouse cursor makes me feel more calm using Git. I want to reset to that commit. I want to delete this branch. I want to cherry-pick this commit onto that branch. I want to see the diff for this commit. I can't really describe it but I feel more "connected" interacting with a repository like this, than on the command-line where I have to run commands and use the output of previous commands in new commands.
- When I'm browsing the history, I can scroll up and down the list of commits and see the diff of each one by clicking on it.
- When I'm cherry-picking a commit, I can just drag the commit onto the branch.
- When I'm modifying a branch or a remote, I can right-click on it and go to Delete or Rename.
- When I'm resetting to an old commit, I can right-click on it and go to Reset.
Basically, I like to refer to things by pointing to them, and interacting by clicking or dragging. All of those things I just mentioned are trivial using the command-line — with the exception of modifying a branch or remote, you just have to write the git subcommand and its arguments. But having a Git resource as a tangible "thing" on the end of my mouse cursor makes me feel more calm using Git. I want to reset to that commit. I want to delete this branch. I want to cherry-pick this commit onto that branch. I want to see the diff for this commit. I can't really describe it but I feel more "connected" interacting with a repository like this, than on the command-line where I have to run commands and use the output of previous commands in new commands.
I concede the point on mouseability/clicking-and-dragging, but I respectfully disagree with your other points on what GUIs offer.
Everything else you described is easily available via already-existing CLI wrappers for git. I described my workflow in another comment[0] here. It is incredibly easy to search for specific commits and branches with instant live-previews using tools like forgit, and these tools are only possible because of the composability of command-line programs.
[0]: https://news.ycombinator.com/item?id=20516798
Everything else you described is easily available via already-existing CLI wrappers for git. I described my workflow in another comment[0] here. It is incredibly easy to search for specific commits and branches with instant live-previews using tools like forgit, and these tools are only possible because of the composability of command-line programs.
[0]: https://news.ycombinator.com/item?id=20516798
[deleted]
We've found that our repos get bad branches and bad merges far less often with them. For a long time, we had issues where a repo would have to be completely rebuilt (or replaced with all history lost) after a dev who thought he knew the Git CLI did a merge incorrectly or force pushed something. Detached HEAD branches locally and remotely, incompatible remote branches, inability to merge without conflict, etc. It was always strange issues that usually required we branch off a commit on develop from a few weeks earlier, merge a few weeks of changes in a single commit, drop every single remote branch, and push and merge back into develop. Was a mighty pain.
We noticed that this only ever happened with devs who (incorrectly) believed they knew the Git CLI and as a result, we instituted a GUI-only policy and preinstalled SourceTree on all computers. In the 2 or 3 years since we started the policy, we haven't had this issue even once. We occasionally have a complaint from a new hire, but after a week or so, they usually tell us that they prefer using a GUI after all. I wish we didn't have the policy, but it became necessary, unfortunately.
(for reference, we are a small-ish shop. Never had more than 15 devs at once. That makes such a policy more easily enforced and worked around. We're currently reevaluating using SourceTree as the default recommendation and Fork is one of the options we are considering)
We noticed that this only ever happened with devs who (incorrectly) believed they knew the Git CLI and as a result, we instituted a GUI-only policy and preinstalled SourceTree on all computers. In the 2 or 3 years since we started the policy, we haven't had this issue even once. We occasionally have a complaint from a new hire, but after a week or so, they usually tell us that they prefer using a GUI after all. I wish we didn't have the policy, but it became necessary, unfortunately.
(for reference, we are a small-ish shop. Never had more than 15 devs at once. That makes such a policy more easily enforced and worked around. We're currently reevaluating using SourceTree as the default recommendation and Fork is one of the options we are considering)
All your troubles would be solved if you simply locked down master and only allowed pull requests with limited merge options like fastforward and squash.
I work at a small shop with 6 devs. We do this. No issues.
We did this at one point, but at the scale we work at (our GitLab has 671 projects, about 150 of which have been worked on in the last 4 months), that kind of lock down creates a major bottleneck for updating projects unfortunately. We had to disable it shortly after starting it because it was simply too much to manage with our current workforce. It's too much extra work for us compared to just saying "use a GUI", which has had a great success rate so far.
I have tended to use a gui to view the state of the repo (even gitk, which is bundled with git, is better than the CLI for this IMO), and the CLI to manipulate it. Inspecting the state of the repo through the CLI is mostly slower and less clear than through any GUI from my experience, except in the case of complex queries in a repo with a complicated branch structure (I at one point had a linux repo which had something like 7 different remotes for the purposes of tracking the differences between different branches of the kernel in embedded development. GUIs will struggle to show that tree sensibly)
This is the reason I use the curses-based gui named tig.
I think it would be nice to have a UI where all input or manipulation of data was done through a CLI with autocomplete and a well-written tutorial, but which presented read-only graphics to represent the data model.
I think it would be nice to have a UI where all input or manipulation of data was done through a CLI with autocomplete and a well-written tutorial, but which presented read-only graphics to represent the data model.
Tig user +1, an amazing little tool. Yes, a few times I wish it could do more, but it's good as it is, as a git viewer.
At the very minimum, having the local file status and recent history visible in a window at all times (i.e. a permanent 'git status', 'git log' and 'git diff' view) makes a GUI worthwhile. I can't even imagine working without that.
Another thing a GUI can be superior is operating on arbitrary subsets of files. E.g. imagine you have 100 new files and want to 'git add' an arbitrary subset of them; doing this in a GUI is far faster than the command line. (This is equivalent to shell vs. file manager - some operations are done more efficiently in the command line, some in a GUI.)
Then there's all sorts of niceties that a GUI can provide to speed up your work. E.g. git is very anal about what can be done if your local tree isn't clean, requiring often a stash-operation-unstash workflow. Smartgit (my weapon of choice, highly recommended) does it for me when required. More niceties I appreciate: reordering commits with a simple drag-and-drop; a diff/merge view to use during conflicts, or just to add a subset of file changes instead of whole files; jumping between repos with a single click. I'm probably forgetting a few.
TL;DR You can pry Smartgit from my cold dead hands.
Another thing a GUI can be superior is operating on arbitrary subsets of files. E.g. imagine you have 100 new files and want to 'git add' an arbitrary subset of them; doing this in a GUI is far faster than the command line. (This is equivalent to shell vs. file manager - some operations are done more efficiently in the command line, some in a GUI.)
Then there's all sorts of niceties that a GUI can provide to speed up your work. E.g. git is very anal about what can be done if your local tree isn't clean, requiring often a stash-operation-unstash workflow. Smartgit (my weapon of choice, highly recommended) does it for me when required. More niceties I appreciate: reordering commits with a simple drag-and-drop; a diff/merge view to use during conflicts, or just to add a subset of file changes instead of whole files; jumping between repos with a single click. I'm probably forgetting a few.
TL;DR You can pry Smartgit from my cold dead hands.
Better code review than git diff, easy to commit only subset and faster way to view all changes in commits. I'm using GitUp and it's really good although not maintained anymore.
> I'm using GitUp and it's really good although not maintained anymore.
That's a shame, I didn't know that. GitUp is really nice.
That's a shame, I didn't know that. GitUp is really nice.
Are you sure it's not maintained anymore? There is still activity on the GitHub repository. Just no new versions?
There’s activity, but no new releases in a year and a pull request that’s been sitting for a year.
To me it falls into that category of things that you don't know what you're missing until you use it.
A visual client just makes much much easier to visualize the state of a repo immediately, the relationship between branches, and individual changes over time. You see a commit from another branch in a list and you click on it; it's instantaneous and the diff is shown in a window. Doing the same on the command line takes a bunch of arcane commands and is extremely longer to execute.
Some things like interactive rebasing are also much easier (you can double check diff as you go, again with a click). Committing just hunks of a file is also much easier.
Some people are comfortable with the command line for everything and that's fine. But the reality is that certain actions are so cumbersome to execute via the command line that some people can never be bothered with them. In that case a GUI helps immensely.
A visual client just makes much much easier to visualize the state of a repo immediately, the relationship between branches, and individual changes over time. You see a commit from another branch in a list and you click on it; it's instantaneous and the diff is shown in a window. Doing the same on the command line takes a bunch of arcane commands and is extremely longer to execute.
Some things like interactive rebasing are also much easier (you can double check diff as you go, again with a click). Committing just hunks of a file is also much easier.
Some people are comfortable with the command line for everything and that's fine. But the reality is that certain actions are so cumbersome to execute via the command line that some people can never be bothered with them. In that case a GUI helps immensely.
Basically, in GUIs the most common commands are represented in UI, and some combined into a single action. Also, visually viewing the entire tree (not sure the name for the entire branching structure) can be helpful to debugging and fixing issues caused by merging, accidental overwrites, etc.
The disadvantages are:
- cherry picking commits is not easy
- lacks advanced (read uncommon) commands
- sometimes git errors are encountered that can only be solved with command line anyways
It's also way easier to onboard junior engineers who haven't used version control before.
The disadvantages are:
- cherry picking commits is not easy
- lacks advanced (read uncommon) commands
- sometimes git errors are encountered that can only be solved with command line anyways
It's also way easier to onboard junior engineers who haven't used version control before.
”cherry picking commits is not easy”
That always baffles me in git UIs. You have your list of branches on the left, list of commits in the current branch on the right (haven’t checked this client, but it likely has that), so why can’t I drag one of those commits on top of a branch to cherry-pick it?
Similarly, changing git commits shouldn’t need a separate dialog, and reordering commits could be done in-place by drag and drop (probably with a warning if done on commits that have been pushed). Yes, that’s less efficient and may occasionally lead to more or harder merge conflicts than doing complex rebase’s in one go, but it’s the GUI way.
That always baffles me in git UIs. You have your list of branches on the left, list of commits in the current branch on the right (haven’t checked this client, but it likely has that), so why can’t I drag one of those commits on top of a branch to cherry-pick it?
Similarly, changing git commits shouldn’t need a separate dialog, and reordering commits could be done in-place by drag and drop (probably with a warning if done on commits that have been pushed). Yes, that’s less efficient and may occasionally lead to more or harder merge conflicts than doing complex rebase’s in one go, but it’s the GUI way.
> visually viewing the entire tree [branching structure]
You can do that with git CLI no problem, it's one of my most used aliases (so I can't recall exactly the underlying command) - just flags to log. --pretty=oneline --all --decorate is the key bit iirc.
While I'm at it, my hands down most used alias is 'fixup', which takes a ref, commits with message 'fixup! <ref>' and rebases with whatever flag makes it turn that into 'fixup' instead of 'pick' automatically. i.e. it's commit --amend for older commits.
Recently I added fzsha and fzfile too, which use fzf to fuzzy find a SHA/file, and call the git command given as $1 with it and any other supplied args. So git fzfile add stages whatever I choose in fzf, and likewise git fzsha fixup amends a fuzzy-found commit.
These GUIs look pretty, but I've no desire to learn one when it inevitably misses some things I use frequently, and adds new features I don't have, sure, but no (quick, maybe it's open source and .. sure) way of adding my own.
You can do that with git CLI no problem, it's one of my most used aliases (so I can't recall exactly the underlying command) - just flags to log. --pretty=oneline --all --decorate is the key bit iirc.
While I'm at it, my hands down most used alias is 'fixup', which takes a ref, commits with message 'fixup! <ref>' and rebases with whatever flag makes it turn that into 'fixup' instead of 'pick' automatically. i.e. it's commit --amend for older commits.
Recently I added fzsha and fzfile too, which use fzf to fuzzy find a SHA/file, and call the git command given as $1 with it and any other supplied args. So git fzfile add stages whatever I choose in fzf, and likewise git fzsha fixup amends a fuzzy-found commit.
These GUIs look pretty, but I've no desire to learn one when it inevitably misses some things I use frequently, and adds new features I don't have, sure, but no (quick, maybe it's open source and .. sure) way of adding my own.
The mnemonic is to do it like "a dog" [1], though I think some of these flags are now default.
The one option I really like is --first-parent. If you did merge commits for every new feature, and gave sensible names to those commits (instead of "Merge A into master", use "Merge awesome feature"), it really simplifies the git history and makes it easy to grasp the dev history.
Now, on command-line vs GUI, I think the contrary is actually true: once you know your way around some piece of software, small operations are easier using CLI. However, I really appreciate GUIs to set-up the most complex ones, or the fairly complex, but rarely used ones. And of course, GUIs tend to help you discover stuff while you're still learning the software, though git CLI does that pretty well too.
[1]: https://stackoverflow.com/questions/1057564/pretty-git-branc...
The one option I really like is --first-parent. If you did merge commits for every new feature, and gave sensible names to those commits (instead of "Merge A into master", use "Merge awesome feature"), it really simplifies the git history and makes it easy to grasp the dev history.
Now, on command-line vs GUI, I think the contrary is actually true: once you know your way around some piece of software, small operations are easier using CLI. However, I really appreciate GUIs to set-up the most complex ones, or the fairly complex, but rarely used ones. And of course, GUIs tend to help you discover stuff while you're still learning the software, though git CLI does that pretty well too.
[1]: https://stackoverflow.com/questions/1057564/pretty-git-branc...
I echo the other comment about easier selective commits. I have done that in the console and it's a pain. Nevertheless I have been using VSCode git features for that and it basically removed my need for a separate GUI program.
I used to use the one from atlassian, but they made it so difficult to use it, and also I think they started charging for it. I also downloaded kraken, but found it very heavy and intrusive.
Nothing beats using the terminal (except for selective commits)
I used to use the one from atlassian, but they made it so difficult to use it, and also I think they started charging for it. I also downloaded kraken, but found it very heavy and intrusive.
Nothing beats using the terminal (except for selective commits)
I find GUIs easier for several tasks. These come to mind:
- Staging/unstaging/dropping hunks or specific lines within a modified file
- Interactive rebase is simpler and clearer
- Staging/unstaging/dropping hunks or specific lines within a modified file
- Interactive rebase is simpler and clearer
I use both command line and GUI as part of my workflow.
I use GUI mainly for doing "visual" stuff like looking at diffs, and commit and merge history (especially across branches), etc. In my opinion, this stuff is quicker and easier and looks better on a GUI.
I also use GUI if I have several changes and I only want to stage some of them (or partials). It's easy to go through and stage/unstage things on a good GUI.
For everything else I use the command line. Almost any time I want to actually DO something (like commit, push, pull, etc), I do this through command line.
I use GUI mainly for doing "visual" stuff like looking at diffs, and commit and merge history (especially across branches), etc. In my opinion, this stuff is quicker and easier and looks better on a GUI.
I also use GUI if I have several changes and I only want to stage some of them (or partials). It's easy to go through and stage/unstage things on a good GUI.
For everything else I use the command line. Almost any time I want to actually DO something (like commit, push, pull, etc), I do this through command line.
i mostly use the git cli. i even like it; despite some ux problems! i've often been the one teaching git, and always make sure junior hires learn at least a little bit of git cli. but i do use a few extra interfaces.
1. complex staging operations. i do a lot of partial staging. staging by line or hunk is good enough most of the time. sometimes though i want a little more. maybe only part of a line, or parts of multiple lines. or even edit the staged content directly! i haven’t used eclipse in a few years, but its staging ui was great. side by side diff, working tree on one side, stage on the other. like resolving a merge conflict. full syntax highlighting, both sides editable. i haven’t found another tool like it. even primitive staging tools (like fork, tower, and tig) that don't do anything fancier than `git add -p` tend to be more useful to me, just because it's so quick to change your mind. no need to type out an unstage command then go through a bunch of screens. just drag and drop, or highlight and click.
2. studying history of a class or function. i use a jetbrains ide, and it makes it super easy to jump through the full history of a file. it's just git blame, but you don't have to copy and paste the ref to blame. very quickly you can see a bunch of versions all at once, and diff between them.
3. perusing git history. mostly, i use git-log and git-show. but sometimes, i want to see the git graph and quickly see the contents of individual nodes. a normal advanced scenario is, show me the full git graph, highlighting commits that touch a particular file, and let me quickly see the contents of those commits. i can do that with the cli, but it's way faster in other tools. if it's simple enough, i use tig right in my terminal. if my ide doesn't support the more complex cases, git-gui does.
4. interactive rebase. i don't know any tools where this doesn't suck. i'm rebasing against origin/master.. is it towards the top or towards the bottom? what files are in the commits i'm manipulating? what are the contents of those files? why can't i jump around between them without starting a new rebase session? i think there's potential for radically different tooling around interactive rebase, especially inside an ide. i'm used to the git cli. i interactive rebase constantly without any trouble. but my team mates don't, and it's not cause they're stupid or lazy. i just got really interested and put a ton of effort into learning it.
1. complex staging operations. i do a lot of partial staging. staging by line or hunk is good enough most of the time. sometimes though i want a little more. maybe only part of a line, or parts of multiple lines. or even edit the staged content directly! i haven’t used eclipse in a few years, but its staging ui was great. side by side diff, working tree on one side, stage on the other. like resolving a merge conflict. full syntax highlighting, both sides editable. i haven’t found another tool like it. even primitive staging tools (like fork, tower, and tig) that don't do anything fancier than `git add -p` tend to be more useful to me, just because it's so quick to change your mind. no need to type out an unstage command then go through a bunch of screens. just drag and drop, or highlight and click.
2. studying history of a class or function. i use a jetbrains ide, and it makes it super easy to jump through the full history of a file. it's just git blame, but you don't have to copy and paste the ref to blame. very quickly you can see a bunch of versions all at once, and diff between them.
3. perusing git history. mostly, i use git-log and git-show. but sometimes, i want to see the git graph and quickly see the contents of individual nodes. a normal advanced scenario is, show me the full git graph, highlighting commits that touch a particular file, and let me quickly see the contents of those commits. i can do that with the cli, but it's way faster in other tools. if it's simple enough, i use tig right in my terminal. if my ide doesn't support the more complex cases, git-gui does.
4. interactive rebase. i don't know any tools where this doesn't suck. i'm rebasing against origin/master.. is it towards the top or towards the bottom? what files are in the commits i'm manipulating? what are the contents of those files? why can't i jump around between them without starting a new rebase session? i think there's potential for radically different tooling around interactive rebase, especially inside an ide. i'm used to the git cli. i interactive rebase constantly without any trouble. but my team mates don't, and it's not cause they're stupid or lazy. i just got really interested and put a ton of effort into learning it.
I also use CLI like 95% of the time. Last one I can think of (above the ones you mention) is complex merge conflicts. The CLI makes it kind of hard to read and visualize what is going on. I’ve actually gotten so used to the Jetbrains GUI for resolving conflicts that even if the language isn’t supported in whatever I’m trying to resolve I’ll open it in a Jetbrains software to resolve it.
Interactive staging (add -p) can be very useful with a GUI.
Otherwise I don't know. Command interfaces familiar to you are hard to beat.
Otherwise I don't know. Command interfaces familiar to you are hard to beat.
To add to what others wrote.
Some GUIs are insanely good for tasks that may be complex through CLI.
GitUp, for instance, allows you to instantly rearrange, squash and split your commits (mostly through keyboard shortcuts). It also has unlimited undo/redo even for complex actions such as merges and rebases.
Some GUIs are insanely good for tasks that may be complex through CLI.
GitUp, for instance, allows you to instantly rearrange, squash and split your commits (mostly through keyboard shortcuts). It also has unlimited undo/redo even for complex actions such as merges and rebases.
Multiple repos visible at a glance
Happy user of Fork here. I switched a few months ago from SourceTree, as it was getting laggy due to having a large number of repos.
Fork is a performant Git GUI client, well-designed with most practical features you could want. It's a native app written separately for macOS and Windows - though they might use their own cross-platform library, I seem to recall reading about it.
Anyway, it's excellent software, I'm willing to pay to support development.
Fork is a performant Git GUI client, well-designed with most practical features you could want. It's a native app written separately for macOS and Windows - though they might use their own cross-platform library, I seem to recall reading about it.
Anyway, it's excellent software, I'm willing to pay to support development.
Not my work, but this is one of the most impressive Git clients I've extensively used — and it's free. Tons of features, lots of thought put into usability, and fully native. If this were a $50 product, I'd happily pay it, but there's not even a donation link.
Just wanted to share!
Just wanted to share!
Is it more impressive than the git command line client? What does it do better?
DISCLAIMER: Obviously some git tasks are just the wrong fit for a GUI, and some git tasks are just not possible.
I've not used Fork but I find SourceTree (which looks very similar) MUCH quicker to search for, and build commits from, hunks. I mean perhaps if I really invested in the git tool I could get my speed up, but I don't see the point - I have what I need already in SourceTree.
More generally the tree-structure of the git filesystem often lends itself to persistent visualisations e.g. split view graph + branches. Especially when fetching, and the graph automatically re-renders and shows you an unexpected structure.
If we are talking about vanilla git - GUIs can be a nice drop in to speed up commit work flows like "checkout that commit I was working approx a dozen commits ago". Being able visually-grep, and then double-click is a bit faster than `git log --pretty=oneline; git checkout SHA"`
And finally, and they are a great on-boarding wrapper for users who are new to git. I've had good success unblocking users with very little git experience who are only using a git CLI, by introducing a git GUI. This really flattens out the learning curve, which frees up both devs to concentrate on the _actual_ task at hand.
I've not used Fork but I find SourceTree (which looks very similar) MUCH quicker to search for, and build commits from, hunks. I mean perhaps if I really invested in the git tool I could get my speed up, but I don't see the point - I have what I need already in SourceTree.
More generally the tree-structure of the git filesystem often lends itself to persistent visualisations e.g. split view graph + branches. Especially when fetching, and the graph automatically re-renders and shows you an unexpected structure.
If we are talking about vanilla git - GUIs can be a nice drop in to speed up commit work flows like "checkout that commit I was working approx a dozen commits ago". Being able visually-grep, and then double-click is a bit faster than `git log --pretty=oneline; git checkout SHA"`
And finally, and they are a great on-boarding wrapper for users who are new to git. I've had good success unblocking users with very little git experience who are only using a git CLI, by introducing a git GUI. This really flattens out the learning curve, which frees up both devs to concentrate on the _actual_ task at hand.
I've discovered Fork by looking at my teammate's screen :D
I am very skeptical about any git UI especially anything out of my IDE as switching windows distracts me.
However, after trying it a bit:
- it works and looks much better than SourceTree, GitKraken
- it's free (while I would prefer using a Sublime license model if asked)
- it has GitFlow integration (not a big fan of it, however it gives you a git workflow template out of the box, worth checking)
Thank you, Dan and Tanya, for the hard work!
I am very skeptical about any git UI especially anything out of my IDE as switching windows distracts me.
However, after trying it a bit:
- it works and looks much better than SourceTree, GitKraken
- it's free (while I would prefer using a Sublime license model if asked)
- it has GitFlow integration (not a big fan of it, however it gives you a git workflow template out of the box, worth checking)
Thank you, Dan and Tanya, for the hard work!
Ok - I haven't read all the comments here; maybe it's been asked and answered, but I'm going to ask anyhow:
Is there something like this available for Linux? Even if you have to pay for it?
IntelliJ covers most use cases, and I already pay for that, but I have been wanting to move away from it, and I am one of those few who do not like to use the cli much for git, unless there's no other choice (sometimes, that's the case). I honestly don't know why such a tool doesn't seem to exist.
Parts of it do exist (or did - not sure about their active state) - but one tool will have one piece, but lack others; and that holds for every tool I've seen so far. One tool or another will lack that one needed piece - back to the command line for it; sigh.
It is strange, because as a whole, all the pieces seem like they are there - but for some reason, nobody has taken the time to combine them all. Probably for the same reason why I haven't done it myself: It isn't that interesting, I suppose.
Is there something like this available for Linux? Even if you have to pay for it?
IntelliJ covers most use cases, and I already pay for that, but I have been wanting to move away from it, and I am one of those few who do not like to use the cli much for git, unless there's no other choice (sometimes, that's the case). I honestly don't know why such a tool doesn't seem to exist.
Parts of it do exist (or did - not sure about their active state) - but one tool will have one piece, but lack others; and that holds for every tool I've seen so far. One tool or another will lack that one needed piece - back to the command line for it; sigh.
It is strange, because as a whole, all the pieces seem like they are there - but for some reason, nobody has taken the time to combine them all. Probably for the same reason why I haven't done it myself: It isn't that interesting, I suppose.
Not Fork, but I just love Sublime Merge. It runs natively on all major OSs and is insanely fast. Plus I can’t go back from that search function, it’s just too good. Might be worth a try?
Yes! If you're comfortable with a terminal but would rather have a TUI than an CLI, I
recommend `tig`[0] or `lazygit`[1]. If you want to launch a separate GUI program in its
own window to use git, git-cola[2] isn't too bad. It looks much better than the
screenshots make it out to be if you have a good Qt 5 theme (e.g., breeze-dark).
I personally prefer separate wrappers for different git commands for two reasons:
As a plus, `forgit` integrates well with `diff-so-fancy`[5] (amazing-looking diffs), `bat`, and `emoji-cli`.
[0]: https://github.com/jonas/tig
[1]: https://github.com/jesseduffield/lazygit
[2]: https://github.com/git-cola/git-cola
[3]: https://github.com/wfxr/forgit
[4]: https://github.com/junegunn/fzf
[5]: https://github.com/so-fancy/diff-so-fancy
I personally prefer separate wrappers for different git commands for two reasons:
1. I like how the modular nature of git encourages me to think.
2. I'd rather not leave my shell just to use git.
As a plus, `forgit` integrates well with `diff-so-fancy`[5] (amazing-looking diffs), `bat`, and `emoji-cli`.
[0]: https://github.com/jonas/tig
[1]: https://github.com/jesseduffield/lazygit
[2]: https://github.com/git-cola/git-cola
[3]: https://github.com/wfxr/forgit
[4]: https://github.com/junegunn/fzf
[5]: https://github.com/so-fancy/diff-so-fancy
Magit? Although be aware it is a gateway drug into Emacs.
Thanks for ridding me of GitHub Desktop’s Electron bloat on Mac. Native apps, please come back.
Fork is awesome. I've been using Windows for the past year for a project and missed GitUp on Mac.
After trying a few clients (Tower, SourceTree, Kraken, and a few others) I stayed with Fork - very fast, performant, and intuitive. Right now I have about 15 repo tabs open in Fork with a large number of branches in each. The tree view is excellent (I actually liked the older one-line-per-entry version).
Fork recently added the ability to compare branches - literally click two times to get a diff within half a second.
I really can't believe this app is free. Well done to the makers of this excellent app!
After trying a few clients (Tower, SourceTree, Kraken, and a few others) I stayed with Fork - very fast, performant, and intuitive. Right now I have about 15 repo tabs open in Fork with a large number of branches in each. The tree view is excellent (I actually liked the older one-line-per-entry version).
Fork recently added the ability to compare branches - literally click two times to get a diff within half a second.
I really can't believe this app is free. Well done to the makers of this excellent app!
For Mac users, nothing beats GitUp[0]
0: https://gitup.co
0: https://gitup.co
I use GitUp as my primary git client, but I switch to Fork to handle complicated rebasing. Fork’s “interactive rebase” tool is fantastic, if GitUp had it I’d never need to switch away. I actually registered a HN account just to say this about Fork, it’s that helpful to me.
could you elaborate how it compares to fork and why it would be better?
as someone who is training developers, cross-platform is a critical feature. gitup fails on that. on the other hand it's FOSS, another critical feature for me. fork fails on that one.
so it's a tossup, and i probably can't recommend either for those reasons.
as someone who is training developers, cross-platform is a critical feature. gitup fails on that. on the other hand it's FOSS, another critical feature for me. fork fails on that one.
so it's a tossup, and i probably can't recommend either for those reasons.
I like GitUp, but how do you handle the fact that the map view doesn't show commit messages and dates (like gitk for example)?
I’ll compare Fork with GitUp (https://gitup.co) on macOS.
A big advantage of Fork is a better merging experience. Personally, I use GitUp in conjunction with CLI when I do rebases, which implies higher mental overhead.
Overall, Fork’s UI feels a fair bit slower to use compared to GitUp, both in terms of raw performance and design. For example, after selecting a commit, details take about half a second to load in the bottom pane, and expanding a diff from there takes a precision click. (The Changes subpane offers another diff view, but it requires to select a single changed file first and takes a half-second until file’s diff appears.)
GitUp is blazing-fast, has very focused UI, and further speeds up your workflow with well-thought keyboard shortcuts that cover pretty much all available functionality.
Platform integrations in Fork might make sense to someone, though to me it’s a concern. It supports GitHub and Bitbucket—what about Gitlab? Unless you monetize, I doubt you can integrate with everything, maintain each integration as their APIs evolve, and still spare enough effort on improving the core UI.
A big advantage of Fork is a better merging experience. Personally, I use GitUp in conjunction with CLI when I do rebases, which implies higher mental overhead.
Overall, Fork’s UI feels a fair bit slower to use compared to GitUp, both in terms of raw performance and design. For example, after selecting a commit, details take about half a second to load in the bottom pane, and expanding a diff from there takes a precision click. (The Changes subpane offers another diff view, but it requires to select a single changed file first and takes a half-second until file’s diff appears.)
GitUp is blazing-fast, has very focused UI, and further speeds up your workflow with well-thought keyboard shortcuts that cover pretty much all available functionality.
Platform integrations in Fork might make sense to someone, though to me it’s a concern. It supports GitHub and Bitbucket—what about Gitlab? Unless you monetize, I doubt you can integrate with everything, maintain each integration as their APIs evolve, and still spare enough effort on improving the core UI.
Both seem to work pretty well, if only I could actually use them. My aging eyes just can't deal with all the gray text on a white background in Fork, or the tiny text in GitUp. Sigh!
Someone is currently maintaining a fork of GitUp that adds a text size slider in preferences.
On the other hand, maintainer’s response is a bit disheartening suggesting they have not (yet) encountered the eyesight issue themselves.
See this feature request: https://github.com/git-up/GitUp/issues/470
On the other hand, maintainer’s response is a bit disheartening suggesting they have not (yet) encountered the eyesight issue themselves.
See this feature request: https://github.com/git-up/GitUp/issues/470
Thanks for the link! Disheartening indeed. Found the fork at the end of that thread, and I'll give it a try.
I love git extensions [0]. It's definitely not as pretty, but it's open source and very powerful. Development is very active too. Devs is happy to take PRs.
[0] https://gitextensions.github.io/
[0] https://gitextensions.github.io/
Highly recommend. Switched after another developer at my office mentioned it. I suggested the filter active branch hot key and it was added I believe in less than a week. Comes out of the box with a great dark mode. The way you can view the commits diffs in the program is wonderful as well. It's the one thing I didn't like about git kraken. Which I even had suggested that they add a different view for that and I would have purchased for my whole team.
Take a look at this one. The ability to jump between branches is great with command B.
Keep up the good work. Like people have already mention please make a donate button as I'll gladly donate to encourage the continued work.
Take a look at this one. The ability to jump between branches is great with command B.
Keep up the good work. Like people have already mention please make a donate button as I'll gladly donate to encourage the continued work.
Quick feedback to whoever maintains the web-page.
I'm looking at the introduction, the screenshots and all looks nice. Then at the bottom of the screen I get the text "Download Fork for Mac", and nothing else. No Windows-download.
Had the headline on HN not been explicit about there being a Windows-version, I wouldn't have gone looking... And therefore not found the tiny "For for Windows" navigation item on top of the page. I would have assume this was Mac only and left.
Any reason you different pages, and particularly why you don't show both download links on the bottom of the screen?
I'm pretty sure you're at risk of missing 99% of the potential Windows-users skimming by this page.
I'm looking at the introduction, the screenshots and all looks nice. Then at the bottom of the screen I get the text "Download Fork for Mac", and nothing else. No Windows-download.
Had the headline on HN not been explicit about there being a Windows-version, I wouldn't have gone looking... And therefore not found the tiny "For for Windows" navigation item on top of the page. I would have assume this was Mac only and left.
Any reason you different pages, and particularly why you don't show both download links on the bottom of the screen?
I'm pretty sure you're at risk of missing 99% of the potential Windows-users skimming by this page.
It's definitely Mac-centric. Mac in all the screenshots. Mac link in the menu has a blue border to make it stand out and the Windows one doesn't. Like you said, the bottom of the homepage is a link to download the Mac version. Release notes are all for Mac, no Windows. The blog talks about "Fork", which is a Mac app, and then a separate "Fork for Windows".
I moved to Fork from Sourcetree a few weeks ago.
- This really is much faster than SourceTree (I have a surface Go and CPU is important to me). My entire machine feels faster. It's entirely possible this is due to ST doing a whole bunch of unnecessary work rather than Fork being good though.
- Unlike Tower (and like ST) it has a separate staging area
Didn't try anything else asides from ST, Tower and Fork because the rest don't even seem to be capable of interactive rebase, which is essential for a good commit history.
- This really is much faster than SourceTree (I have a surface Go and CPU is important to me). My entire machine feels faster. It's entirely possible this is due to ST doing a whole bunch of unnecessary work rather than Fork being good though.
- Unlike Tower (and like ST) it has a separate staging area
Didn't try anything else asides from ST, Tower and Fork because the rest don't even seem to be capable of interactive rebase, which is essential for a good commit history.
I use Fork on work and also private. Great software. One of the main reasons to switch is the merge/conflict view, which is, at least in my opinion, one of the best out there.
Previously I've used Sourcetree and SmartGit, and even some Git integration in PHPStorm/WebStorm. But for now, Fork is just lit.
If I could I just wish for one thing: mark branches which are only local and have no remote, so you can easily purge old branches after they're merged.
Previously I've used Sourcetree and SmartGit, and even some Git integration in PHPStorm/WebStorm. But for now, Fork is just lit.
If I could I just wish for one thing: mark branches which are only local and have no remote, so you can easily purge old branches after they're merged.
>mark branches which are only local and have no remote, so you can easily purge old branches after they're merged.
See:
- https://git-scm.com/docs/git-fetch#_pruning
- https://git-scm.com/docs/git-fetch
git fetch --prune
git branch -v
See:
- https://git-scm.com/docs/git-fetch#_pruning
- https://git-scm.com/docs/git-fetch
Better than BeyondCompare?
As a game industry git newbie that was used to the Perforce client for managing versioning and visualizing changes, this app has been a huge blessing to me.
Looks nice and clean, although useless for me as a Linux user.
The one thing I use graphical git client for is resolving merge issues, so something lightweight is nice. Currently I just do it in IntelliJ and hope I already have the project opened.
As a side note, I guess the images on the website are fairly small, but they pay for it with tons of jpeg artifacts which does not look clean.
The one thing I use graphical git client for is resolving merge issues, so something lightweight is nice. Currently I just do it in IntelliJ and hope I already have the project opened.
As a side note, I guess the images on the website are fairly small, but they pay for it with tons of jpeg artifacts which does not look clean.
> Looks nice and clean, although useless for me as a Linux user.
That's why Electron GUIs are good. People say they are bloated, but at least the program is available for Linux as well.
That's why Electron GUIs are good. People say they are bloated, but at least the program is available for Linux as well.
So we’re all forced to use shit apps? No thanks.
I imagine the number of Linux desktop using developers who use git and want a git GUI is numbering in the hundreds, worldwide.
I imagine the number of Linux desktop using developers who use git and want a git GUI is numbering in the hundreds, worldwide.
> numbering in the hundreds
So like 50% of total Linux desktop users? Haha, just kidding. I, for myself, use tig and git command line and I'm pretty happy with it.
So like 50% of total Linux desktop users? Haha, just kidding. I, for myself, use tig and git command line and I'm pretty happy with it.
Even in SE field Linux market is small, that was one of the reasons I've moved out of it as my primary OS
Not for products targeting software engineers, the distributions of systems looks very different from the general public and Linux is very common.
Why do merge tools pretend that "their" and "our" or "remote" and "local" are good labels? Can they not show the commit message and hash? Nowadays with history editing often both sides are local and mine.
And, on the command-line at least, "theirs" and "ours" are reversed (only) for "rebase" [1] so that means, at least for me, I have to mentally ask myself "are theirs/ours reversed for this command?" for every command I execute, they might as well be called "foo" and "bar" at this point for me.
[1] https://git-scm.com/docs/git-rebase#Documentation/git-rebase...
[1] https://git-scm.com/docs/git-rebase#Documentation/git-rebase...
Did you see the screenshots? Looks like it shows the branches at least.
I did see the screenshots. That's what triggered my comment. I did not see any branch names. Now I see "nh-scroll-fix" and "origin/fix-simulate-na..." in the conflict dialog, but not in the merge dialog. Branch names seem insufficient anyway though, but it would be a slight improvement I guess.
And then they get misspelled as "their's" and "our's".
Just downloaded it cause SourceTree has been getting slower and more temperamental over time. Seems fantastic and very fast thus far, I'll be testing it more extensively over the coming weeks and might well switch to this. Beautiful work!
Also would love a GitFlow integration like the one you get in SourceTree [1] or Tower [2].
[1] https://blog.sourcetreeapp.com/2012/08/01/smart-branching-wi... [2] https://www.git-tower.com/help/win/integration/git-flow
[1] https://blog.sourcetreeapp.com/2012/08/01/smart-branching-wi... [2] https://www.git-tower.com/help/win/integration/git-flow
Been using it for work and my first 'request' would be to add the "commit message recall" that SourceTree offers, a feature I always missed in Tower.
With it I can make small commits individually (eg "added new CRUD resource-class for users") and then recall the last message and make minor changes (eg changing "users" to "posts", "comments", etc).
I might be alone in loving this feature though :D
With it I can make small commits individually (eg "added new CRUD resource-class for users") and then recall the last message and make minor changes (eg changing "users" to "posts", "comments", etc).
I might be alone in loving this feature though :D
Does is support signing commits? I can't tell form the website.
I usually go for the command line and only reach for a GUI if I made a lot of changes that should be committed separately and Github Desktop doesn't work with signed commits at all.
I usually go for the command line and only reach for a GUI if I made a lot of changes that should be committed separately and Github Desktop doesn't work with signed commits at all.
I’ve been using this after quitting SourceTree due to so many issues I had with handling authentication, especially with Azure DevOps.
Now I prefer the Fork interface, it seems to be more functional for things I often need to do during dev work.
Now I prefer the Fork interface, it seems to be more functional for things I often need to do during dev work.
Yeah, please put a donation link. I would happily pay if I enjoy using it
Bug report: for some reason I initially could not get past the initial "User information" screen.
I suspect it may have had to do with the "full name" field, does it perhaps require a space? When I typed with a space on the 2nd try, Finish was enabled. When I then went back and removed the space, it continued enabled.
Anyway, I was left with confusion about "username", and I preferred to go with a nick, however that wish was apparently not respected, and why that was was not clarified.
I suspect it may have had to do with the "full name" field, does it perhaps require a space? When I typed with a space on the 2nd try, Finish was enabled. When I then went back and removed the space, it continued enabled.
Anyway, I was left with confusion about "username", and I preferred to go with a nick, however that wish was apparently not respected, and why that was was not clarified.
Is there such thing as "remote git"? As someone who gave up trying to run Docker under WSL, returning to the warm embrace of Linux on VMWare, I tried most git clients and found them not usable over neither Samba nor NFS share. Console git pseudo-GUIs are pretty good now (lazygit is my workhorse), but I miss the ability to easily scroll around.
If a client could support SSH-based workflow with remote git execution, that would solve it for me.
If a client could support SSH-based workflow with remote git execution, that would solve it for me.
When I develop for arm Linux, I use local git on Windows PC. I share that folder with CIFS, mount on Linux, build and run my stuff from the mounted directory. As a nice side effect, the disk speed is much faster, the PC has fast SSD, target device uses much slower SD card for the system drive.
From a brief use, it looks good, definitely a lot faster than something like Gitkraken. I'll be happy to see where you guys take this project.
10/10 Would use again.
I'm a lurker but had to comment on this. A great app that I use daily and can't believe its free.
I'm a lurker but had to comment on this. A great app that I use daily and can't believe its free.
This is pretty awesome, thanks for working on that! At the moment I'm struggling a bit trying to figure out how to use GPG. My Git profile is set up to require signed commits and the website claims this is supported, but it's at least not obvious how to do that.
This looks neat! It will be great to have a Linux version in the future.
I’m not too hopeful as this seems to be made native to the platforms (and very well!) by experienced native devs. Maybe, the app becomes very popular and there will eventually be a Linux version of such good quality.
I’m not too hopeful as this seems to be made native to the platforms (and very well!) by experienced native devs. Maybe, the app becomes very popular and there will eventually be a Linux version of such good quality.
Hm... Looks nice so far, except for the Google Analytics call upon startup. Would love to see an option to disable it - and you should add a privacy policy, if you keep it in your application.
Other then that, it doesn't seem to send anything else.
Other then that, it doesn't seem to send anything else.
Just downloaded it from the link on the website and the downloaded version was one release behind, which means an immediate ~50meg download again. Please be considerate of people on slow/remote/expensive connections.
Does Fork support integrations with self-hosted systems like Github or Gitlab?
BTW, could we all please stop creating Electron apps and spend time to properly code native, resource-efficient software instead of shipping a full browser engine in every single application?
Previous discussion (2016):
https://news.ycombinator.com/item?id=12382493
So everybody's bitching about the license aside... :)
This sure looks like a really nicely designed git client, congrats to the team on the release!
The whole, if the product is free you are the product etc.
So, how is this free?
It really does look amazing, which is probably why I wonder how it can be free.
It really does look amazing, which is probably why I wonder how it can be free.
Not everything aims to be a "product", I suppose.
Git is also free. So, how are you the product when you use git?
Git is open source and a community project; Fork is closed source and developed by two people.
Problems with BitBucket? Trying to sign on to BB after downloading and keep getting the error "Could not parse error json data".
What technology is it using that prevents it from being available on Linux? I don't like what is currently available.
It’s using WPF on Windows and Cocoa on Mac. It doesn’t seem to share much code between them, either.
What about Sublime Merge? I think its great, and works great for me on Linux
Does it run precommits that have keyboard interactions? We use that a lot and Sublime Merge does not work.
Amazing, well crafted piece of software. I wonder how they can afford to build and maintain it for free.
I had Fork 1.0.19. Wasn't any good back then. Just reopened and updated it. Much better now!
Interesting how similar it is to SourceTree, even down to having Custom Actions.
Once Gitbox stops working in Mac OS, I'm going to have to become Amish.
I wish it worked on linux
What distinguishes it from TortoiseGit on Windows?
Judging solely from screenshots I’d say the biggest difference is that it is not a shell extension but a self contained program.
I would describe TortoiseGit as file-centric, while most other git Gui tools (including this, judging by the screenshots) are timeline-centric.
With timelines, you are dealing mainly with diffs (what's changed in your working directory, or a commit), and the files involved are just a side effect of that. The files that are unchanged are simply not displayed at all in the UI. This is especially conducive to using the staging area and committing partial files.
Tortoise shows you working directory diffs but only if you ask via several clicks (eg, creating a commit). Because you interact via Explorer, every time-based action is hidden behind context menu.
IMHO about the only thing easier in tortoise is viewing history or blame on a specific file or directory.
With timelines, you are dealing mainly with diffs (what's changed in your working directory, or a commit), and the files involved are just a side effect of that. The files that are unchanged are simply not displayed at all in the UI. This is especially conducive to using the staging area and committing partial files.
Tortoise shows you working directory diffs but only if you ask via several clicks (eg, creating a commit). Because you interact via Explorer, every time-based action is hidden behind context menu.
IMHO about the only thing easier in tortoise is viewing history or blame on a specific file or directory.
Also it's really helpful if you have heaps of repos and want a centralised view and to quickly switch from one to the other with Ctrl/Cmd+Shift+O
I need a nice git client for Linux..
Why not linux? :(
Specifically, it says:
* "You will not use this Software to engage in or allow others to engage in any illegal activity.": Which jurisdiction? how far do I have to go to prevent illegal activity?
* "You will not engage in using this Software that will interfere with or damage the operation of the services of any third parties[...]" How is this defined? How quickly can I push the "git pull" button before I violate this term?
* "You will not use this Software to engage in any activity that will violate the rights of third parties, including, without limitation, [...]" again, which jurisdiction?