Fork: A fast and friendly Git client for Mac and Windows
fork.dev
fork.dev
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?
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.
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...
Git kraken, sublime merge, sourcetree. It is pretty common among the most famous ones, just look at the list on wikipedia, https://en.wikipedia.org/wiki/Comparison_of_Git_GUIs
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
Congress could abolish the public domain or ban stuff like the GPL.
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. [..]
You can specifically ban (or make unenforceable) any subset of copyright licenses without banning copyright licenses generally.
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.
Governing Law
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.
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!"
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.
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?
Compare Microsoft Windows’s license:
https://www.microsoft.com/en-us/Useterms/Retail/Windows/10/U...
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.
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.
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:
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?
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.
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.
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.
This is more generally phrased than the very lawyer-written EULAs you generally find, but it's not unreasonable or unprecedented.
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.
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.
Whether it's enforceable, sure, that might be questionable.
If I cared about a git client for these platforms, I would file a bug about the license. Fortunately that is not the case.
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.
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.
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.
Fork is made by one person.
Not making any assumptions here, but if you're evaluating risks around compromises in one of the two products, I think Fork is higher risk.
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
Android/LineageOS is Linux.
Just type adduser and sudo, it's not too bad.
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.
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.
I'm curious why they didn't use Xamarin.Mac though, they could have shared a lot of code between apps.
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.
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 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.
[1]: https://stackoverflow.com/questions/1057564/pretty-git-branc...
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.
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.
That's a shame, I didn't know that. GitUp is really nice.
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.
- 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.
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 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)
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.
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.
- Staging/unstaging/dropping hunks or specific lines within a modified file
- Interactive rebase is simpler and clearer
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)
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.
Otherwise I don't know. Command interfaces familiar to you are hard to beat.
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.
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.
Just wanted to share!
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.
I am very skeptical about any git UI especially anything out of my IDE as switching windows distracts me.
However, after trying it a bit:
- it works and looks much better than SourceTree, GitKraken
- it's free (while I would prefer using a Sublime license model if asked)
- it has GitFlow integration (not a big fan of it, however it gives you a git workflow template out of the box, worth checking)
Thank you, Dan and Tanya, for the hard work!
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.
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.
As a plus, `forgit` integrates well with `diff-so-fancy`[5] (amazing-looking diffs), `bat`, and `emoji-cli`.
[0]: https://github.com/jonas/tig
[1]: https://github.com/jesseduffield/lazygit
[2]: https://github.com/git-cola/git-cola
[3]: https://github.com/wfxr/forgit
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!
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.
On the other hand, maintainer’s response is a bit disheartening suggesting they have not (yet) encountered the eyesight issue themselves.
See this feature request: https://github.com/git-up/GitUp/issues/470
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.
- 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.
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.
git fetch --prune
git branch -v
See:
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.
That's why Electron GUIs are good. People say they are bloated, but at least the program is available for Linux as well.
I imagine the number of Linux desktop using developers who use git and want a git GUI is numbering in the hundreds, worldwide.
So like 50% of total Linux desktop users? Haha, just kidding. I, for myself, use tig and git command line and I'm pretty happy with it.
[1] https://git-scm.com/docs/git-rebase#Documentation/git-rebase...
[1] https://blog.sourcetreeapp.com/2012/08/01/smart-branching-wi... [2] https://www.git-tower.com/help/win/integration/git-flow
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).
I might be alone in loving this feature though :D
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.
Now I prefer the Fork interface, it seems to be more functional for things I often need to do during dev work.
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.
If a client could support SSH-based workflow with remote git execution, that would solve it for me.
I'm a lurker but had to comment on this. A great app that I use daily and can't believe its free.
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.
Other then that, it doesn't seem to send anything else.
It really does look amazing, which is probably why I wonder how it can be free.
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.