8 ms·

Git Fork: A fast and friendly Git client for Windows and Mac

74 points by zubspace 4y ago

zubspace 4y ago
Our whole team works with git fork and we're really happy with it. You can browse the repo at a specific commit, branch, merge, rebase and blame everything from the gui. I rarely need to fall back to the command line and there's even the option to add custom commands to the gui. And it's really fast, even with multiple repos. Just had an issue today and Dan replied in less than 5 minutes. Thumbs Up
skrowl 4y ago
I can't imagine using a paid, closed-source git client when https://github.com/desktop/desktop https://github.com/desktop/desktop and https://github.com/Murmele/Gittyup https://github.com/Murmele/Gittyup are both great. Maybe 10 years ago, but not now that open-source alternatives are so mature and feature-rich.
- bm5k 4y ago
  Never used gittyup but last time I tried the github desktop app was years behind gittower in terms of functionality & features provided. If you’re earning money developing software but refuse to pay for tools, in my personal and not at all humble opinion, you’re part of The Problem.
- kitsunesoba 4y ago
  Never heard of GittyUp, but I used to use the GitHub desktop client. It was great originally, but then they rewrote it with Electron and it’s been a shadow of its former self ever since.
bm5k 4y ago
This looks neat, but I don’t see anything off hand that will pull me away from my current git tower + kaleidoscope ~rut~ workflow. In particular, the drag & drop rebase support in tower is very convenient. Kaleidoscope is capable of all kinds of diffing but the text conflict resolution is probably the feature that I use the most.
- Armic 4y ago
  I used to use tower, but I switched to fork for two reasons - it was more performant with my work monorepo, and fork's a one time payment and tower's an annual subscription (and more expensive). I'm not affiliated with them at all but I'm a happy customer and recommend you give it a shot; they have a free trial.
  - AnonC 4y ago
    I’m not the GP. I don’t like subscriptions and looked at Fork after your comment. I couldn’t find the policy on versions and upgrades. Is it a one time purchase with updates for major versions or for a period of time (after which updates wouldn’t be available) or a one time purchase forever (how would the developers and the product survive)? The purchase page says one license is for up to three computers. It doesn’t explain it there is some activation process (in which case there needs to be a way to deactivate and reassign).
    - DanPristupov 4y ago
      Hi! I develop Fork with my wife. We don't have manager, marketing team, designers, etc. We also don't have meetings which makes us more efficient :). So, we don't need too much money to survive. Answering your question, yes, it's a one-time purchase which includes future updates. We may release a major paid update in the future, however currently we don't have plans for that. The license is cross-platform. You can activate, deactivate and reassign the license.
      - AnonC 4y ago
        GP here. Thanks for your detailed reply. Please add this information on your website, maybe on the license page or elsewhere.
- sathomasga 4y ago
  Same reaction. My Tower subscription is up for renewal next month, so I'm primed to give this a try. A cursory look, however, and I find the user interface to be baffling. As one example, on loading the app presents a list of repositories to manage. Select one and you get to interact with that particular repo. But, as far as I can tell, there's no simple way to go back to the repository list to select a different repo to manage. At least, no way other than closing the app and relaunching it. Maybe I'm just used to the way Tower presents things and Fork is simply different, but I felt totally lost in the app, unsure of what to do or how to accomplish non-trivial tasks. With Tower, by contrast, all the interactions seem intuitive and straightforward. Looks like Tower will be getting my money in June as scheduled.
anaganisk 4y ago
I discovered this on the day pandemic was declared, god this tool is well polished and is so great. It is closed source but that shouldn’t be a blocker, its not like every app we use is open-source and not everyone is going to take a look under the hood. I think it was a two people team(a couple) if Im not wrong. Awesome work guys!
zacwest 4y ago
Fork is the only GUI in Mac performant enough to handle my work monorepo. That alone would be sufficient, but it's also a stellar client with great support for things like interactively rebasing and handling merges. I can do roughly everything I need, faster, in its UI.
- sdflhasjd 4y ago
  I'd love to know why Fork is so much faster than every other git GUI client I've used.
- frogperson 4y ago
  The fastest gui client I know of is gitup (gitup.co). Have you tried it? How does it compare to Fork?
  - bjtitus 4y ago
    I've found Fork to be faster than Gitup for very large repos. I used to use Gitup exclusively but switched to Fork a few years back. The graph drawing in Gitup can get bogged down when you have hundreds of branches. I still love that representation of branches but I'm usually not that confused about the repo state and I've found the vertical layout that Fork uses to be sufficient.
darkteflon 4y ago
Does this handle LFS file-locking? Very handy for repos with lots of binaries (eg game dev), but also almost wholly unimplemented in the most popular Git GUI clients.
- DanPristupov 4y ago
  Yes, you can lock and unlock LFS files using file context menu. There's also the ability to see the list of locked files (and force-unlock one, if needed).
  - darkteflon 4y ago
    Excellent, thank you - I’m trialling it now. Loads of positive comments for your product on this thread. High quality paid native Mac software from smaller developers is one of my favourite things about the ecosystem.
    - DanPristupov 4y ago
      Being honest, we don't use LFS internally, so dogfooding doesn't really work in this area. If you don't like something or you have an idea how we can improve LFS support in Fork, please feel free to contact me directly.
      - darkteflon 4y ago
        Sure thing, will do - cheers.
- jayd16 4y ago
  SmartGit supports it too but I find that even with access to it, its less useful than with something like P4 simply because git style ends up using more branches and locks don't work across branches. How do you end up dealing with that?
  - darkteflon 4y ago
chrismeller 4y ago
I love Fork, it just seems to work the way I expect such a tool to behave. Also very snappy, even with large diffs. I do wish it were available on Linux as well.
- nicoburns 4y ago
  There's always Sublime Merge on Linux.
kitsunesoba 4y ago
Been using Fork for several years now, and it’s great. It’s exactly what I look for in a tool: capable, yet focused and fast, with everything being as it should right out of the box. It never feels like it’s getting in the way. I use it along with Secretive[0] to keep GitHub SSH keys in my MacBook’s Secure Enclave and add a biometric prompt whenever pushing or pulling. All together it’s extremely smooth and unfussy. [0]: https://github.com/maxgoedjen/secretive https://github.com/maxgoedjen/secretive
0xcoffee 4y ago
I love this so much, I've been waiting to see if they ever have a sale, but honestly it's worth the full price.
Vanit 4y ago
Fork, aka the footgun git UI that repeatedly causes me to lose productive time to help junior devs unmangle their local repos. I usually recommend SourceTree to them, not because it's particularly amazing, but it does enough while not breaking repos (as often).
- peppertree 4y ago
  My experience has been exact opposite. SourceTree has been regressing since going Atlassian and Fork has been rock solid for years, especially for large repos.
- DanPristupov 4y ago
  Hi. Dan from Fork is here. I guess there's some mistake. I answer a lot of user questions daily and this is the first time I hear about such a feedback. I would really appreciate if you could send me any details (by email or using the feedback button on the toolbar in Fork).
- cosmotic 4y ago
  It sounds like you're blaming the jr devs or the fork app, but really you should be blaming the tool, git, for allowing users to mangle their repos.
- a_chris 4y ago
  Opposite situation for me. I've been using Sourcetree for YEARS and it was a PITA, so bad, slow and counterintuitive. On the other hand Fork saved my mental health and it's by far the best git manager I've always used. This is the only software I would be happy to pay for.
- duncanc4 4y ago
  I also had the opposite experience. I used Sourcetree for a while, but the performance became really bad, so I switch to Fork and have never looked back.
IMTDb 4y ago
Unrelated to fork itself, but I always wonder how do people implement the vertical colored lines representing branches and merges. This is present in almost all git desktop clients, and of course very useful.
- ssddanbrown 4y ago
  You can also get these lines via the git CLI like so: git log --graph --oneline --all
- asfasdf111 4y ago
  There's also the least-promoted awesome project that is terminal/ncurses based... so easy to run on remote development https://www.flickr.com/photos/jonasfonseca/3315600409/in/album-72157614470764617/ https://www.flickr.com/photos/jonasfonseca/3315600409/in/alb... (the official site link screenshots to flikr :) https://jonas.github.io/tig/ https://jonas.github.io/tig/ it is part of my workflow for years. I prefer direct git commands. But sometimes it is nice to explore history and complex changes there. And most of the parameters are the same as `git diff ...` just `tig ...` with (almost always) same values for the ellipsis.
- WorldMaker 4y ago
  Going further afield into tangent, I love the looks of these "subway diagrams" of the commits, but I keep thinking that as great as they look and as nice screenshots as they make what I'd love to see a Git UI do is something very different: take a --first-parent approach by default and use a drilldown/expandable view of commits past first parent. It would look a lot more boring in screenshots, but could be a great way in practice to ease people into the two dimensional git DAG without making it seem so messy/busy by default. Many projects it would provide a good "PR focused" view of the repository up front and center (without being reliant on specific PR tools/APIs, only that those PR tools create merge commits). Going off to a different tangent: the vertical colored lines down the side of a list of chronologically ordered items to show reply threads was a visualization I first spotted in the early oughts or late 90s from a showcase of Microsoft Research Visualizations and so Microsoft Research has published research and had patents on it at one time. Those patents have all since expired, I believe, but it's interesting to note that it was on some minds even back then, which was neat, and curious to wonder what if a Microsoft product had embraced it earlier. (I recall the demo felt a lot like Outlook's email list and the impression was that was what they were trying to sell it as a possible tool to the Outlook team. Which seemed a neat idea for email visualization, though I think Outlook decided that strict temporal ordering wasn't necessary for reply threading that users were happy enough with.)
robertoandred 4y ago
Love Fork! Switched to it after I got sick of how slow and buggy SourceTree was.
SuperSandro2000 4y ago
The obligatory use the flu comment
726D7266 4y ago
Are there big features missing from the built-in Git UI in VS Code compared to Fork? These pulled me away from Sourcetree, but my experience with Fork is limited to early versions (ca. 2016/17).
nerdjon 4y ago
The UI does look really good, but I do wonder how much of the dev community uses a GUI vs just sticking in the command line? Personally the only GUI stuff I find useful are the features that are already part of VSCode (live showing what I have changed or doing a diff). Outside of that I generally find that any GUI for git just inevitably makes something just opaque enough that I don't really know for sure what I am about to commit or where I am pushing too. For me "git status" >> "git add XYZ" >> "git status" >> "git push" are so ingrained in my workflow that I don't get that feedback in any UI I have seen. I have started to dip my toes into it a bit now with the Atlassian integration that can name new branches properly... but even using that just gives me a weird disconnect with what is actually happening that it doesn't feel right. After the creation of the branch I am back to my cli. Maybe it is just because I live in the command line anyways (enough so that I have iTerm setup to just pop up from the bottom of my screen with a keyboard command) that I just feel more comfortable with the command line? I just feel like I am missing something here since I know some do rely on these tools heavily.
- ridiculous_fish 4y ago
  I use both the git CLI and Fork for different tasks. For the `git add` workflow you describe I use the CLI exclusively, and for interactive rebase it's about half and half. An example where Fork comes in handy is deleting branches, especially on remotes. It's pleasant to see all the branches and just click on the ones I want to delete, and not have to deal with git CLI's differences between deleting local and remote branches, or remember how git deletes remote branches this week.
  - brycewray 4y ago
    Same here. I find merging branches (and viewing the results) easier with Fork, too, while I do the simpler things in the terminal.
- kitsunesoba 4y ago
  In my case my git usage is so mundane that the most basic of its CLI commands are sufficient 98% of the time. Reaching for the more advanced commands is so infrequent that they don't ever stick meaning I'm always looking them up (and probably subsequently screwing them up). My work is scattered across different IDEs/editors too so the differing UI conventions of integrated VCS make that more trouble than it's worth. So I just use Fork all the time. It covers base case very well regardless of the project, and on the occasion that I need to do something more fancy I can do it without pulling up docs and with far fewer screwups.
ridiculous_fish 4y ago
I'm a huge fan of Fork too! I love the speed and how Mac-native it feels. I'm comfortable with the git CLI but I still find Fork superior for many tasks, like deleting remote branches.
onetom 4y ago
My choice is the VCS client in JetBrains IDEs, like IntelliJ, WebStorm, PyCharm etc. IntelliJ Community Edition is even free and open-source, so for Java coding it's perfect, but pretty good for Clojure, Python, PHP too. The JetBrains IDEs are cross-platform, including Linux and cross architecture, including ARM, because the JVM/JDK is cross-arch. The sticking point for me is how well it deals with the 3-way resolution of merge conflicts. It also has a magic-wand icon, which seems to resolve 95% of conflicts automatically and correctly, presumably doing something based on common ancestor commits. BUT what makes both this 3-way merge interface AND the commit interface really great, is the ability to edit in-place, with all your custom keybindings, syntax highlighting, linting and code intelligence tools! You can auto-complete code, look up docs or the source code of function definitions, even in JAR files, without leaving the context of the commit dialog. If you need to do something more involved, like refactoring or jump to definition, u can always get to the source code with F4 from the commit dialog or from within any commit context. You don't know what are you missing out on, until you experience it! It's a significant reduction in mental overhead, imho. Now the cost of all this convenience is that you need to download hundreds of megabytes and IntelliJ CE has a substantial startup time and memory consumption, since it indexes your code. It also sprinkles your repo with projects files under a .idea folder. I will check out Fork regardless, because it's good to know what's out there and what are the different set of tradeoffs it choose. Then I can choose and/or recommend it for different situations. It's the same reason I'm learning vc.el and magit too. If you need to do some git surgery over high-latency SSH, then it's hard to beat Emacs with TRAMP...
jdlyga 4y ago
I struggled with anything besides committing or pushing when I first started using Git. People keep trying to make better GUI's to account for this, but going and in and learning how to use the command line and reading Pro Git really was the best solution. It's so much easier to work with.
Night_Thastus 4y ago
I've been looking for a new client. It really only needs a couple things: * Be fast * Let me do line-by-line staging/reverting * Automatically wrap commit message bodies past a given line length, and warn if titles are similarly too long. If it does that, I am happy. I've been using Git-cola, but it's slow. Every action incurs some delay, even simple ones. (Can't use VSCode for reasons) The problem is most of the alternatives are either subscription (eww) or quite pricey. Fork is one of the cheaper ones, been meaning to try it.
- oerpli 4y ago
  I think it doesn't count characters in the body but I am sure Dan could add this as optional feature (though I think it's a bad idea to enforce 80 chars there. Maybe a max line length would be better). Also, I think it doesn't enforce the limits but counts down letters and if you're above the 50 chars for the message it shows a negative char count in bright red (which makes me reconsider what I want to tell my coworkers in that message). The other points should be fulfilled.
  - DanPristupov 4y ago
    Fork can show the width guideline in the description field if you enable 'monospace font' in preferences. The width is configurable.
  - Night_Thastus 4y ago
    My statement about the character limits was incorrect and ambiguous. Git-cola is similar. It displays the number of characters and a color. No color for up to 64, yellow to 72, orange to 78, and red above that. The body wraps the next word onto a new line if it crosses past 72 characters. (By default, that is configurable and disable-able) Those are fairly arbitrary choices, but they work well enough for me in practice and help keep my titles/messages clean and readable. If Fork could do something similar (the auto-wrapping and title warning) I'd be happy.
    - DanPristupov 4y ago
oerpli 4y ago
I tried a few Git clients over the years and am proficient with the CLI. My impression is that Fork captures how git actually works better than some of the other GUI tools and it has a lot of handy features that make certain tasks a pleasure instead of a chore (common rebasing things, add/deleting/changing local/remote branches, splitting up changes in single files into multiple commits - this is maybe be an antipattern but I do it frequently enough). Also, it's very cheap. I hope they make enough money with it to continue development.
9erdelta 4y ago
Fork is great -- except for when you try and google about it b/c at least for me, I haven't been able to differentiate my queries between the git fork operation and git Fork the UI. Also on my local machine, push to remote gitlab does not work reliably and I have to push via command line. Have not been able to find a solution, but also haven't done more than googling about it.
- DanPristupov 4y ago
  File -> Accounts -> + -> GitLab should solve the problem. Otherwise, contact me using the feedback button on the toolbar (or by email) and I'll be able help you.
lioeters 4y ago
I'm a paying user of Fork, it's my favorite Git GUI, I love it. However, it "only" supports macOS and Windows. I'm migrating to Linux for my work and home computers, so I haven't used Fork in a while, just so I can get familiar with other tools available on Linux - and, importantly, learning to do more advanced Git operations in the terminal. So far I still depend on a GUI, mainly VS Code's built-in Git integration and the GitGraph extension. (One of the advantages of this setup is that it also works for remote SSH editing.) https://github.com/mhutchie/vscode-git-graph https://github.com/mhutchie/vscode-git-graph Also looking at GitLens: https://www.gitkraken.com/gitlens https://www.gitkraken.com/gitlens ..But I sure miss using Fork. I used it everyday for the last couple years. It does everything I want to do with Git, the UI is familiar and well-designed. I whole-heartedly recommend it. I see the main developer @DanPristupov is on HN, maybe he'd consider supporting Linux? I totally understand if you won't, since creating the same application for two OSes must be quite difficult already, especially for a small team rather than a company.
nerdyadventurer 4y ago
There is also gitui : https://github.com/extrawurst/gitui https://github.com/extrawurst/gitui, simple command line UI for git

74 points by zubspace 4y ago

Our whole team works with git fork and we're really happy with it. You can browse the repo at a specific commit, branch, merge, rebase and blame everything from the gui. I rarely need to fall back to the command line and there's even the option to add custom commands to the gui. And it's really fast, even with multiple repos. Just had an issue today and Dan replied in less than 5 minutes. Thumbs Up

skrowl 4y ago

I can't imagine using a paid, closed-source git client when https://github.com/desktop/desktop https://github.com/desktop/desktop and https://github.com/Murmele/Gittyup https://github.com/Murmele/Gittyup are both great. Maybe 10 years ago, but not now that open-source alternatives are so mature and feature-rich.

bm5k 4y ago
Never used gittyup but last time I tried the github desktop app was years behind gittower in terms of functionality & features provided. If you’re earning money developing software but refuse to pay for tools, in my personal and not at all humble opinion, you’re part of The Problem.
kitsunesoba 4y ago
Never heard of GittyUp, but I used to use the GitHub desktop client. It was great originally, but then they rewrote it with Electron and it’s been a shadow of its former self ever since.

bm5k 4y ago

This looks neat, but I don’t see anything off hand that will pull me away from my current git tower + kaleidoscope ~rut~ workflow. In particular, the drag & drop rebase support in tower is very convenient. Kaleidoscope is capable of all kinds of diffing but the text conflict resolution is probably the feature that I use the most.

Armic 4y ago
I used to use tower, but I switched to fork for two reasons - it was more performant with my work monorepo, and fork's a one time payment and tower's an annual subscription (and more expensive). I'm not affiliated with them at all but I'm a happy customer and recommend you give it a shot; they have a free trial.
- AnonC 4y ago
  I’m not the GP. I don’t like subscriptions and looked at Fork after your comment. I couldn’t find the policy on versions and upgrades. Is it a one time purchase with updates for major versions or for a period of time (after which updates wouldn’t be available) or a one time purchase forever (how would the developers and the product survive)? The purchase page says one license is for up to three computers. It doesn’t explain it there is some activation process (in which case there needs to be a way to deactivate and reassign).
  - DanPristupov 4y ago
    Hi! I develop Fork with my wife. We don't have manager, marketing team, designers, etc. We also don't have meetings which makes us more efficient :). So, we don't need too much money to survive. Answering your question, yes, it's a one-time purchase which includes future updates. We may release a major paid update in the future, however currently we don't have plans for that. The license is cross-platform. You can activate, deactivate and reassign the license.
    - AnonC 4y ago
      GP here. Thanks for your detailed reply. Please add this information on your website, maybe on the license page or elsewhere.
sathomasga 4y ago
Same reaction. My Tower subscription is up for renewal next month, so I'm primed to give this a try. A cursory look, however, and I find the user interface to be baffling. As one example, on loading the app presents a list of repositories to manage. Select one and you get to interact with that particular repo. But, as far as I can tell, there's no simple way to go back to the repository list to select a different repo to manage. At least, no way other than closing the app and relaunching it. Maybe I'm just used to the way Tower presents things and Fork is simply different, but I felt totally lost in the app, unsure of what to do or how to accomplish non-trivial tasks. With Tower, by contrast, all the interactions seem intuitive and straightforward. Looks like Tower will be getting my money in June as scheduled.

anaganisk 4y ago

I discovered this on the day pandemic was declared, god this tool is well polished and is so great. It is closed source but that shouldn’t be a blocker, its not like every app we use is open-source and not everyone is going to take a look under the hood. I think it was a two people team(a couple) if Im not wrong. Awesome work guys!

zacwest 4y ago

Fork is the only GUI in Mac performant enough to handle my work monorepo. That alone would be sufficient, but it's also a stellar client with great support for things like interactively rebasing and handling merges. I can do roughly everything I need, faster, in its UI.

sdflhasjd 4y ago
I'd love to know why Fork is so much faster than every other git GUI client I've used.
frogperson 4y ago
The fastest gui client I know of is gitup (gitup.co). Have you tried it? How does it compare to Fork?
- bjtitus 4y ago
  I've found Fork to be faster than Gitup for very large repos. I used to use Gitup exclusively but switched to Fork a few years back. The graph drawing in Gitup can get bogged down when you have hundreds of branches. I still love that representation of branches but I'm usually not that confused about the repo state and I've found the vertical layout that Fork uses to be sufficient.

darkteflon 4y ago

Does this handle LFS file-locking? Very handy for repos with lots of binaries (eg game dev), but also almost wholly unimplemented in the most popular Git GUI clients.

DanPristupov 4y ago
Yes, you can lock and unlock LFS files using file context menu. There's also the ability to see the list of locked files (and force-unlock one, if needed).
- darkteflon 4y ago
  Excellent, thank you - I’m trialling it now. Loads of positive comments for your product on this thread. High quality paid native Mac software from smaller developers is one of my favourite things about the ecosystem.
  - DanPristupov 4y ago
    Being honest, we don't use LFS internally, so dogfooding doesn't really work in this area. If you don't like something or you have an idea how we can improve LFS support in Fork, please feel free to contact me directly.
    - darkteflon 4y ago
      Sure thing, will do - cheers.
jayd16 4y ago
SmartGit supports it too but I find that even with access to it, its less useful than with something like P4 simply because git style ends up using more branches and locks don't work across branches. How do you end up dealing with that?
- darkteflon 4y ago

chrismeller 4y ago

I love Fork, it just seems to work the way I expect such a tool to behave. Also very snappy, even with large diffs. I do wish it were available on Linux as well.

nicoburns 4y ago
There's always Sublime Merge on Linux.

kitsunesoba 4y ago

Been using Fork for several years now, and it’s great. It’s exactly what I look for in a tool: capable, yet focused and fast, with everything being as it should right out of the box. It never feels like it’s getting in the way. I use it along with Secretive[0] to keep GitHub SSH keys in my MacBook’s Secure Enclave and add a biometric prompt whenever pushing or pulling. All together it’s extremely smooth and unfussy. [0]: https://github.com/maxgoedjen/secretive https://github.com/maxgoedjen/secretive

0xcoffee 4y ago

I love this so much, I've been waiting to see if they ever have a sale, but honestly it's worth the full price.

Vanit 4y ago

Fork, aka the footgun git UI that repeatedly causes me to lose productive time to help junior devs unmangle their local repos. I usually recommend SourceTree to them, not because it's particularly amazing, but it does enough while not breaking repos (as often).

peppertree 4y ago
My experience has been exact opposite. SourceTree has been regressing since going Atlassian and Fork has been rock solid for years, especially for large repos.
DanPristupov 4y ago
Hi. Dan from Fork is here. I guess there's some mistake. I answer a lot of user questions daily and this is the first time I hear about such a feedback. I would really appreciate if you could send me any details (by email or using the feedback button on the toolbar in Fork).
cosmotic 4y ago
It sounds like you're blaming the jr devs or the fork app, but really you should be blaming the tool, git, for allowing users to mangle their repos.
a_chris 4y ago
Opposite situation for me. I've been using Sourcetree for YEARS and it was a PITA, so bad, slow and counterintuitive. On the other hand Fork saved my mental health and it's by far the best git manager I've always used. This is the only software I would be happy to pay for.
duncanc4 4y ago
I also had the opposite experience. I used Sourcetree for a while, but the performance became really bad, so I switch to Fork and have never looked back.

IMTDb 4y ago

Unrelated to fork itself, but I always wonder how do people implement the vertical colored lines representing branches and merges. This is present in almost all git desktop clients, and of course very useful.

ssddanbrown 4y ago
You can also get these lines via the git CLI like so: git log --graph --oneline --all
asfasdf111 4y ago
There's also the least-promoted awesome project that is terminal/ncurses based... so easy to run on remote development https://www.flickr.com/photos/jonasfonseca/3315600409/in/album-72157614470764617/ https://www.flickr.com/photos/jonasfonseca/3315600409/in/alb... (the official site link screenshots to flikr :) https://jonas.github.io/tig/ https://jonas.github.io/tig/ it is part of my workflow for years. I prefer direct git commands. But sometimes it is nice to explore history and complex changes there. And most of the parameters are the same as `git diff ...` just `tig ...` with (almost always) same values for the ellipsis.
WorldMaker 4y ago
Going further afield into tangent, I love the looks of these "subway diagrams" of the commits, but I keep thinking that as great as they look and as nice screenshots as they make what I'd love to see a Git UI do is something very different: take a --first-parent approach by default and use a drilldown/expandable view of commits past first parent. It would look a lot more boring in screenshots, but could be a great way in practice to ease people into the two dimensional git DAG without making it seem so messy/busy by default. Many projects it would provide a good "PR focused" view of the repository up front and center (without being reliant on specific PR tools/APIs, only that those PR tools create merge commits). Going off to a different tangent: the vertical colored lines down the side of a list of chronologically ordered items to show reply threads was a visualization I first spotted in the early oughts or late 90s from a showcase of Microsoft Research Visualizations and so Microsoft Research has published research and had patents on it at one time. Those patents have all since expired, I believe, but it's interesting to note that it was on some minds even back then, which was neat, and curious to wonder what if a Microsoft product had embraced it earlier. (I recall the demo felt a lot like Outlook's email list and the impression was that was what they were trying to sell it as a possible tool to the Outlook team. Which seemed a neat idea for email visualization, though I think Outlook decided that strict temporal ordering wasn't necessary for reply threading that users were happy enough with.)

robertoandred 4y ago

Love Fork! Switched to it after I got sick of how slow and buggy SourceTree was.

SuperSandro2000 4y ago

The obligatory use the flu comment

726D7266 4y ago

Are there big features missing from the built-in Git UI in VS Code compared to Fork? These pulled me away from Sourcetree, but my experience with Fork is limited to early versions (ca. 2016/17).

nerdjon 4y ago

The UI does look really good, but I do wonder how much of the dev community uses a GUI vs just sticking in the command line? Personally the only GUI stuff I find useful are the features that are already part of VSCode (live showing what I have changed or doing a diff). Outside of that I generally find that any GUI for git just inevitably makes something just opaque enough that I don't really know for sure what I am about to commit or where I am pushing too. For me "git status" >> "git add XYZ" >> "git status" >> "git push" are so ingrained in my workflow that I don't get that feedback in any UI I have seen. I have started to dip my toes into it a bit now with the Atlassian integration that can name new branches properly... but even using that just gives me a weird disconnect with what is actually happening that it doesn't feel right. After the creation of the branch I am back to my cli. Maybe it is just because I live in the command line anyways (enough so that I have iTerm setup to just pop up from the bottom of my screen with a keyboard command) that I just feel more comfortable with the command line? I just feel like I am missing something here since I know some do rely on these tools heavily.

ridiculous_fish 4y ago
I use both the git CLI and Fork for different tasks. For the `git add` workflow you describe I use the CLI exclusively, and for interactive rebase it's about half and half. An example where Fork comes in handy is deleting branches, especially on remotes. It's pleasant to see all the branches and just click on the ones I want to delete, and not have to deal with git CLI's differences between deleting local and remote branches, or remember how git deletes remote branches this week.
- brycewray 4y ago
  Same here. I find merging branches (and viewing the results) easier with Fork, too, while I do the simpler things in the terminal.
kitsunesoba 4y ago
In my case my git usage is so mundane that the most basic of its CLI commands are sufficient 98% of the time. Reaching for the more advanced commands is so infrequent that they don't ever stick meaning I'm always looking them up (and probably subsequently screwing them up). My work is scattered across different IDEs/editors too so the differing UI conventions of integrated VCS make that more trouble than it's worth. So I just use Fork all the time. It covers base case very well regardless of the project, and on the occasion that I need to do something more fancy I can do it without pulling up docs and with far fewer screwups.

ridiculous_fish 4y ago

I'm a huge fan of Fork too! I love the speed and how Mac-native it feels. I'm comfortable with the git CLI but I still find Fork superior for many tasks, like deleting remote branches.

onetom 4y ago

My choice is the VCS client in JetBrains IDEs, like IntelliJ, WebStorm, PyCharm etc. IntelliJ Community Edition is even free and open-source, so for Java coding it's perfect, but pretty good for Clojure, Python, PHP too. The JetBrains IDEs are cross-platform, including Linux and cross architecture, including ARM, because the JVM/JDK is cross-arch. The sticking point for me is how well it deals with the 3-way resolution of merge conflicts. It also has a magic-wand icon, which seems to resolve 95% of conflicts automatically and correctly, presumably doing something based on common ancestor commits. BUT what makes both this 3-way merge interface AND the commit interface really great, is the ability to edit in-place, with all your custom keybindings, syntax highlighting, linting and code intelligence tools! You can auto-complete code, look up docs or the source code of function definitions, even in JAR files, without leaving the context of the commit dialog. If you need to do something more involved, like refactoring or jump to definition, u can always get to the source code with F4 from the commit dialog or from within any commit context. You don't know what are you missing out on, until you experience it! It's a significant reduction in mental overhead, imho. Now the cost of all this convenience is that you need to download hundreds of megabytes and IntelliJ CE has a substantial startup time and memory consumption, since it indexes your code. It also sprinkles your repo with projects files under a .idea folder. I will check out Fork regardless, because it's good to know what's out there and what are the different set of tradeoffs it choose. Then I can choose and/or recommend it for different situations. It's the same reason I'm learning vc.el and magit too. If you need to do some git surgery over high-latency SSH, then it's hard to beat Emacs with TRAMP...

jdlyga 4y ago

I struggled with anything besides committing or pushing when I first started using Git. People keep trying to make better GUI's to account for this, but going and in and learning how to use the command line and reading Pro Git really was the best solution. It's so much easier to work with.

Night_Thastus 4y ago

I've been looking for a new client. It really only needs a couple things: * Be fast * Let me do line-by-line staging/reverting * Automatically wrap commit message bodies past a given line length, and warn if titles are similarly too long. If it does that, I am happy. I've been using Git-cola, but it's slow. Every action incurs some delay, even simple ones. (Can't use VSCode for reasons) The problem is most of the alternatives are either subscription (eww) or quite pricey. Fork is one of the cheaper ones, been meaning to try it.

oerpli 4y ago
I think it doesn't count characters in the body but I am sure Dan could add this as optional feature (though I think it's a bad idea to enforce 80 chars there. Maybe a max line length would be better). Also, I think it doesn't enforce the limits but counts down letters and if you're above the 50 chars for the message it shows a negative char count in bright red (which makes me reconsider what I want to tell my coworkers in that message). The other points should be fulfilled.
- DanPristupov 4y ago
  Fork can show the width guideline in the description field if you enable 'monospace font' in preferences. The width is configurable.
- Night_Thastus 4y ago
  My statement about the character limits was incorrect and ambiguous. Git-cola is similar. It displays the number of characters and a color. No color for up to 64, yellow to 72, orange to 78, and red above that. The body wraps the next word onto a new line if it crosses past 72 characters. (By default, that is configurable and disable-able) Those are fairly arbitrary choices, but they work well enough for me in practice and help keep my titles/messages clean and readable. If Fork could do something similar (the auto-wrapping and title warning) I'd be happy.
  - DanPristupov 4y ago

oerpli 4y ago

I tried a few Git clients over the years and am proficient with the CLI. My impression is that Fork captures how git actually works better than some of the other GUI tools and it has a lot of handy features that make certain tasks a pleasure instead of a chore (common rebasing things, add/deleting/changing local/remote branches, splitting up changes in single files into multiple commits - this is maybe be an antipattern but I do it frequently enough). Also, it's very cheap. I hope they make enough money with it to continue development.

9erdelta 4y ago

Fork is great -- except for when you try and google about it b/c at least for me, I haven't been able to differentiate my queries between the git fork operation and git Fork the UI. Also on my local machine, push to remote gitlab does not work reliably and I have to push via command line. Have not been able to find a solution, but also haven't done more than googling about it.

DanPristupov 4y ago
File -> Accounts -> + -> GitLab should solve the problem. Otherwise, contact me using the feedback button on the toolbar (or by email) and I'll be able help you.

lioeters 4y ago

I'm a paying user of Fork, it's my favorite Git GUI, I love it. However, it "only" supports macOS and Windows. I'm migrating to Linux for my work and home computers, so I haven't used Fork in a while, just so I can get familiar with other tools available on Linux - and, importantly, learning to do more advanced Git operations in the terminal. So far I still depend on a GUI, mainly VS Code's built-in Git integration and the GitGraph extension. (One of the advantages of this setup is that it also works for remote SSH editing.) https://github.com/mhutchie/vscode-git-graph https://github.com/mhutchie/vscode-git-graph Also looking at GitLens: https://www.gitkraken.com/gitlens https://www.gitkraken.com/gitlens ..But I sure miss using Fork. I used it everyday for the last couple years. It does everything I want to do with Git, the UI is familiar and well-designed. I whole-heartedly recommend it. I see the main developer @DanPristupov is on HN, maybe he'd consider supporting Linux? I totally understand if you won't, since creating the same application for two OSes must be quite difficult already, especially for a small team rather than a company.

nerdyadventurer 4y ago

There is also gitui : https://github.com/extrawurst/gitui https://github.com/extrawurst/gitui, simple command line UI for git