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.
- It's a separate, dedicated application to do just my source control
- Keeping repos in tabs makes it easy to switch between projects (yes, you could use screen or some other multiplexer, but it's just not as fast for me)
- I'm Windows
- Easier to review history / merges at a glance
- Sucks that SourceTree doesn't have diffing, but it's much easier to do diffs/merge conflict resolution in a UI
- Clicking through items to see what's staged/unstaged is quick
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.
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.
I usually recommend SourceTree to them, not because it's particularly amazing, but it does enough while not breaking repos (as often).
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.)
https://www.flickr.com/photos/jonasfonseca/3315600409/in/alb... (the official site link screenshots to flikr :)
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.
git log --graph --oneline --all
How do you end up dealing with that?
I will say that I ended up going with Git (+ LFS) for two reasons. I was comfortable with it from my other work and, more importantly, P4 felt like an absolute car crash - one of the worst pieces of software I’ve had the misfortune to use in the past few years. Unless and until I’m forced to use it, I’ll stick with Git.
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.
* 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.
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.
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.
Maybe 10 years ago, but not now that open-source alternatives are so mature and feature-rich.
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.
I do wish it were available on Linux as well.
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.
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...
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.
Just had an issue today and Dan replied in less than 5 minutes. Thumbs Up
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.
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
Also looking at 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.
These pulled me away from Sourcetree, but my experience with Fork is limited to early versions (ca. 2016/17).
