Live data from Hacker News

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

git-fork.com

41–50 of 66 posts

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

#41
post #28

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 a…

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…

Same here. I find merging branches (and viewing the results) easier with Fork, too, while I do the simpler things in the terminal.

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

#42
post #39

Earlier quoted context omitted.

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 cowork…

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 practi…

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.

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

#43
post #39

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 al…

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 cowork…

Fork can show the width guideline in the description field if you enable 'monospace font' in preferences. The width is configurable.

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

#44
post #15

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.

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.)

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

#45
post #28

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 a…

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.

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

#46
post #15

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.

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 wa…

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.

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

#47
post #28

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 a…

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

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

#48

Earlier quoted context omitted.

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 practi…

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.

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!

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

#49
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.

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

#50
post #4

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.

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.
Post reply on HN