[HN Gopher] Git Fork: A fast and friendly Git client for Windows...
___________________________________________________________________
Git Fork: A fast and friendly Git client for Windows and Mac
Author : zubspace
Score : 68 points
Date : 2022-05-31 09:56 UTC (13 hours ago)
(HTM) web link (git-fork.com)
(TXT) w3m dump (git-fork.com)
| oerpli wrote:
| 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.
| Vanit wrote:
| 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).
| DanPristupov wrote:
| 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).
| duncanc4 wrote:
| 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.
| cosmotic wrote:
| 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.
| peppertree wrote:
| 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.
| a_chris wrote:
| 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.
| zacwest wrote:
| 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 wrote:
| I'd love to know why Fork is so much faster than every other
| git GUI client I've used.
| 726D7266 wrote:
| 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).
| IMTDb wrote:
| 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.
| asfasdf111 wrote:
| 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/alb...
| (the official site link screenshots to flikr :)
|
| 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 wrote:
| 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.)
| DanPristupov wrote:
| Hi. In Fork you can expand/collapse nodes in the graph.
| Collapsing all (i.e. --first-parent) and then expanding
| particular merge commits is also possible.
| WorldMaker wrote:
| Good to know. I'm just thinking it might be useful as a
| default.
|
| I'm also thinking that it's related to that "why didn't
| Outlook end up using 'subway diagrams'?" question: maybe
| strict chronological ordering _isn 't_ necessarily the best
| focus for commit ordering with respect to "top-level" merge
| commits.
|
| Anyway, not a direct criticism of your app specifically,
| more just a long slow stewing of my own thoughts on the
| subject that I likely won't ever get around to even
| prototyping, in case they do congeal into something worth
| prototyping. You are certainly ahead of me there by having
| built a thing, and I appreciate that.
|
| Right now I don't think enough people appreciate the idea
| of --first-parent as a default in as many views as possible
| (especially as opposed to how many seem to prefer
| squash/rebase-based workflows solely based on gut reactions
| to how the "subway diagrams" can look), and I like
| mentioning that in case it sparks ideas for other people to
| maybe find workflows that they like more than that (and can
| take advantage of the 2D nature of the git DAG possibly
| better than "straight line" approaches).
|
| I'm probably rambling at this point, because yeah I still
| haven't quite found the right "shape" of this idea and it
| is interesting to think out loud about it.
| ssddanbrown wrote:
| You can also get these lines via the git CLI like so:
|
| git log --graph --oneline --all
| skrowl wrote:
| I can't imagine using a paid, closed-source git client when
| https://github.com/desktop/desktop and
| 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.
| kitsunesoba wrote:
| 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 wrote:
| 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 wrote:
| 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
| robertoandred wrote:
| Love Fork! Switched to it after I got sick of how slow and buggy
| SourceTree was.
| jdlyga wrote:
| 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.
| zubspace wrote:
| 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_
| bm5k wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| 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 wrote:
| GP here. Thanks for your detailed reply. Please add this
| information on your website, maybe on the license page or
| elsewhere.
| sathomasga wrote:
| 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.
| DanPristupov wrote:
| Press the first button on the toolbar (or use Cmd+P). You can
| open Repository Manager by opening new tab (Cmd+T).
| sathomasga wrote:
| I merely cited this as one example of a confusing UI, but
| this response makes my point even stronger. For most
| applications, the normal user flow is from general (what
| the app calls Repository Manager, I guess) to specific (a
| particular repository). Well-designed user interfaces
| anticipate the typical user flow and give the user a chance
| to "go back." For example, a user may accidentally click on
| the wrong repository. That user likely wants to return the
| app to its previous state so as to make the correct choice.
|
| Neither of these steps really does that. The first opens a
| command palette which does not have anything resembling a
| "go back" command. It does list "Recent Repositories," but
| there is no reason for a user to assume that "Recent" is
| the same as All the repositories listed on the first
| screen. The command palette also omits the folder hierarchy
| present on the first screen, and that hierarchy may be key
| to finding the desired repo. Opening a new tab is not at
| all intuitive for a user that wants to go back. And the
| most obvious result of the command is a new blank screen.
|
| There a lots of things about Fork that look to be very
| well-done, and it appears to have a great feature set. But
| if I'm going to use a GUI instead of the command line for
| git, then I expect the app to be intuitive and easy to use.
| For me, Fork is not that. I appreciate that other users may
| have different opinions, and I do wish the developers great
| success with the project.
| onetom wrote:
| 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...
| lioeters wrote:
| 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
|
| 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.
| darkteflon wrote:
| 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 wrote:
| 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).
| jayd16 wrote:
| 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?
| SuperSandro2000 wrote:
| The obligatory use the flu comment
| chrismeller wrote:
| 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 wrote:
| There's always Sublime Merge on Linux.
| 0xcoffee wrote:
| 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.
| anaganisk wrote:
| 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!
| 9erdelta wrote:
| 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 wrote:
| 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.
| nerdjon wrote:
| 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.
| pathartl wrote:
| I work 100% in a git UI. Everything but merge diffs I do in
| Sourcetree... for diffs I use VS. It's how I've learned. Here's
| some of my scattered reasoning:
|
| - 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
| AndrewDucker wrote:
| Mostly same here. UI makes life really easy for me.
| stuartd wrote:
| I like SourceTree's 'branch diff' (and it's the only thing I
| use it for).
| ridiculous_fish wrote:
| 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 wrote:
| Same here. I find merging branches (and viewing the results)
| easier with Fork, too, while I do the simpler things in the
| terminal.
| kitsunesoba wrote:
| 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.
| robertoandred wrote:
| I find it much easier and faster to stage or unstage files (or
| parts of files) with a UI.
| ridiculous_fish wrote:
| 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.
| Night_Thastus wrote:
| 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 wrote:
| 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 wrote:
| Fork can show the width guideline in the description field if
| you enable 'monospace font' in preferences. The width is
| configurable.
| Night_Thastus wrote:
| 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 wrote:
| Enable 'monospace font in commit description' in Fork
| preferences and set the guideline for the description
| width. You can wrap the commit message using the context
| menu option in the description field.
| Night_Thastus wrote:
| I've gone ahead and downloaded/installed git-fork and did
| some brief testing with the features I use most in my
| existing client. I've sent feedback based on that.
|
| Thanks for your support!
___________________________________________________________________
(page generated 2022-05-31 23:02 UTC)