The license prohibits all kinds of things so I am not comfortable using it: https://fork.dev/license
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?
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!"
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.
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?
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?
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:
> 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?
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.
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.
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...
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
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.
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.
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.
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 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.
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.
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.
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. [..]
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.
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.
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.
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").
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.
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.
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
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?
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.
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.
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.
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.
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.
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.
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)
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.
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.
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.
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.
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.
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.
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.
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 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 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.
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.
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.
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.
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.
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.
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.
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:
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.
For that reason, I use `forgit`[3] as a git client on {ba,z}sh. I cannot recommend
`forgit` highly enough if you like fuzzy-finders like FZF[4]; my productivity has never
been higher. It's the perfect blend of the modularity and composability offered by UNIX
philosophy and the benefits of a simple user interface.
As a plus, `forgit` integrates well with `diff-so-fancy`[5] (amazing-looking diffs),
`bat`, and `emoji-cli`.
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!
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.
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!
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.
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.
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".
- 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.
>mark branches which are only local and have no remote, so you can easily purge old branches after they're merged.
git fetch --prune
EDIT: Then you can see which ones don't exist on the remote
git branch -v
which will show [gone] if it's a tracked branch but the corresponding upstream branch isn't there anymore. Use -vv to show the upstream branch names as well.
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.
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.
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.
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!
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).
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.
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.
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.
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.
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.
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.
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.
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?
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.
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?