True; that's the only subscription model I find acceptable for software that hardly changes in meaningful ways. For example, I refuse to upgrade Git Tower to version 3 as a protest against fournova's new licensing. Up to that point, I was a loyal customer and product advocate, basically buying every upgrade anyway, but by my own choice. Instead, I'll be on version 2 "forever", despite all its flaws. It was even worse for Windows users, who bought licenses (on my advice, sometimes...) for a thing that realistically speaking never came out of beta. To have a usable product to begin with, they suddenly needed to pay for a subscription. There was zero response to my email explaining this, so there's that. Now I'm keeping my eyes open for alternatives.
Emacs is free and in my opinion Magit is far, far superior to Tower / Fork / SourceTree (used them all on mac extensively at some point; out of those, fork is pretty nice and lightweight).
I'm not an emacs user but always install it (via spacemacs) everywhere solely to host Magit.
The terminal is the best and only git client you need and it will always be free. You are doing yourself a disservice as a developer by not learning how to use your terminal
I'm not sure about that in the case of git. I used the terminal UI exclusively for a long time but it's so bizarrely designed that I've been interested in using a GUI for a while. There are a lot of reasons a dev should learn to use a terminal but making git more pleasant to use isn't necessarily one of them.
GUIs aren't super flexible but they are good at taking a common flow users go through and making it stupid simple to exercise. A lot of the usage of git should be stupid simple, with only infrequent need for complex interaction. Obviously there are some people out there for which a GUI will never be sufficient for their needs, but I'd argue it isn't the common case.
I'm typically a heavy terminal user. Git is my exception. a) the UI of git cli is just so terrible that I'd rather fill my brain with more important things, and b) for viewing what's changed, `git diff` just doesn't cut it relative to a GUI.
Sourcetree is my go to git client, but if I couldn't use sourcetree I'd be OK with pretty much any git GUI. But git CLI is reserved for particularly tricky things that GUIs just can't handle well. (And I need to look up the specific flags or commands every single time.)
Just yesterday I noticed a "Fork Activation" option in the Fork menu with fields for an email and a license key. I think you might be right, it won't be free for much longer.
It's a 3 way merge tool that works well with Fork. To be honest I can't say how it compares with other merge tools, I tried a few merge tools some time back and liked P4 best.
I am just replying to say that I have the exact same experience. I love Git Tower and recommended it to many people, but I haven't upgraded to version 3 and likely never will - for the exact reasons that you have lined out. I think FourNova (the company behind it) is probably missing out on quite some cash here...
I switched to Sublime Merge from using Git Tower (their licensing was awful after v3).
Never looking back, SM is amazing.
Git Tower folks: Stop pissing off your paying loyal users. Get a hint, I want my money back because you guys never made v2 properly stable and jumped on v3 for an awful cash grab. Fuck you, kindly.
Sublime HQ is an amazing company. I would pay for their products even if they charged double. Honesty and integrity matters. You’re not selling to normal sheep, programmers are a smart bunch.
Let's list just basic git concepts that you're likely to encounter fairly early on: the working tree, staged commits, branches, remotes, stashes, detached heads, tags, submodules, merge conflicts, squashed commits, fast-forwards, rebasing, cherry-picking.
Some of these you could choose to ignore - rebasing and submodules - but on the whole you need at least a cursory understanding of everything on that list to get by without a git angel to get you out of trouble. I still have a person I phone when anything out of the ordinary happens and I've taught git to other people!
I find that it has too many magic commands built-in so no-one really gets to learn the under-side of what's actually occuring so when it eventually breaks like everything does, you have no idea what you did wrong. An example would be how the git pull command is basically a bunch of different git fetch and merge commands.
Say you want to find a commit that occurred around June three years ago, and look at what the repo looked like after that commit -- without checking out any files. How do you currently do it?
For me, I just Right click -> TortoiseGit -> Show Log -> scroll -> Right-click -> Browse Repository.
How long does it take you? For me it takes < 10 seconds (I just timed myself).
Not against GUI or anything but just curious about doing it from CLI:
git log | grep 'June 2017' (and remember the first 5 characters of hash)
And then `got checkout <hash>`
git log | grep -- find the hash of the one I want. or git log > file and look at it in an editor. no need to change the tools just for this unusual action.
I understand that YMMV -- de gustibus non disputandum est -- but I have ever understood the appeal of GUI tools especially for something like git. I do use magit, but even then I do most manipulation with the command line interface
> git log | grep -- find the hash of the one I want.
This misses the point of the problem -- the point is you don't know precisely what string to grep for.
> or git log > file and look at it in an editor. no need to change the tools just for this unusual action.
I mean, nobody said this 1 reason should be enough to make you switch tools? I was just giving an example.
And no, it's not "unusual" just because you say so to try to dismiss the problem. I know I use Browse Repository as well as the GUI logs pretty frequently, and they're godsends compared to your solution.
And lastly: this is what your solution actually looks like:
1. Dump the entire log output into a temporary file
2. Open that temp file in your editor
3. Look through the commit messages/dates/names
4. Realize that's not quite enough to narrow down your search to a single commit (maybe you want to see the diffs or file paths or something else?)
5. Try to figure out which flags you should to pass to git log to dump all the info you need
6. Call git log again, hopefully now it dumps all the info you need
7. Open the temp file again in your editor
8. Scroll through your file containing diffs/names/whatever extra info you dumped
9. Type 'git checkout COMMIT -- file/path' once you find something
10. (Hopefully,) before you press Enter, realize you're about to trash your current copy of the file, which had some other changes
11a. Run git stash, and now suddenly messing up your staging area that you'd carefully staged changes in, and also messing up the file metadata (e.g. Make will now rebuild everything...), OR
11b. Figure out how to run git checkout-index -a -f --prefix=/destination/path/ so that you check the file out into a different directory.
12. Once you have a copy of that file, look through it, maybe examine/pull out the code you wanted (or whatever)
13. Remove the temporary file you checked out.
14. Remove the temporary file in your editor.
15. git stash pop.
And somehow you always do all the above without making a mistake, otherwise have fun reverting or recovering lost data.
With a GUI log TortoiseGit's log, you literally:
1. Click on a commit with the date you're interested in
2. Select Browse Repository
3. Double-click each file you want to examine to see the diff
4. If it's not the file you want, press Escape and click again.
Not only is the number of steps smaller, each one is also significantly faster, and less risky too. No need to mess with a single temporary file, fire up your editor manually, or risk losing anything.
Anyway, again: this was just 1 example meant to get the idea across, hopefully with the aid of your imagination to extrapolate to other scenarios. But if you're going to trash this all with "this never comes up" I don't really have the energy or interest to keep bringing up examples or try to convince anyone; you should just keep using the CLI.
I don't think a lot of the steps listed in your first example are as painful as you make them about to be. Most of those steps are just as elementary as clicking a button in a GUI to someone with fluency on the CLI. I also doubt the claims that it's that much faster for someone with a lot of experience doing it.
Perhaps you could be faster with the GUI than on the CLI, but learning a GUI doesn't come with zero overhead: you have to understand it's terminology, how it's configuration works, what its icons and symbols mean. Particularly when it comes to VCS management, GUI's like to simplify sometimes complicated or nuanced VCS behavior and you can't really be sure what is being done to your repo until you've pressed the button and done it. Not to mention you are now investing time learning a program that can be abandoned at any time and leave you without the basic knowledge necessary to manage your repo (not saying this would affect you this way, but it could certainly be a reason to not learn it in the first place).
> I don't think a lot of the steps listed in your first example are as painful as you make them about to be. Most of those steps are just as elementary as clicking a button in a GUI to someone with fluency on the CLI. I also doubt the claims that it's that much faster for someone with a lot of experience doing it.
I mean, it's not like you can ever convince me that >10 keystrokes are as fast as 1 click, but regardless, this is easy enough to settle -- just time yourself and let me know how long the steps take you on the CLI.
> Perhaps you could be faster with the GUI than on the CLI
Hence the point!
> but learning a GUI doesn't come with zero overhead:
I don't think anybody claimed this either, so it's fine.
> you have to understand it's terminology, how it's configuration works, what its icons and symbols mean.
It sounds like you haven't used TortoiseGit... at all? How often have you had to look at its manual? How many times have you had to look at the manual of git itself? Honestly, your own reply is warranted here so many times more than it was to me -- "I don't think a lot of the steps are as painful as you make them about to be."
In fact so many of the commands are so obviously self-explanatory (both in text and in icons) that you literally never need to look them up. Stuff that you would never just guess how to do in git itself. Like when you right-click a file in a commit and click "Save revision to...", which also has a floppy next to it. Is it really such a mystery what it does? Is it even remotely comparable to figuring out checkout-index (or whatever the right command is)?
And honestly: it's such a poor attempt at an argument to suggest that the minor ramp-up time of TortoiseGit is somehow not worth the perpetual git pains it saves you from that I don't even know what to say.
> Particularly when it comes to VCS management, GUI's like to simplify sometimes complicated or nuanced VCS behavior and you can't really be sure what is being done to your repo until you've pressed the button and done it.
First, this is such an unnecessary strawman. If you're so worried what some GUI command does, then just use the CLI for it instead.
Second, this is completely irrelevant for read-only operations (like log, Browse Repository, etc.) which were the ones concerned here.
And third... again, it sounds like you're only saying this because you haven't used TortoiseGit, because (shockingly enough, to someone coming from the git CLI) it's not a minefield; in fact it has a number of safeguards. "Commit" creates a commit, "Revert" reverts your changes, "Checkout" checks out a commit, etc... and in fact fails if your tree is dirty, so you don't lose data. Heck, sometimes the git commands it prints end up being more correct than what you'd type on the command line. I know I've learned a fair number of random git features from TortoiseGit.
> Not to mention you are now investing time learning a program that can be abandoned at any time and leave you without the basic knowledge necessary to manage your repo
Again, nobody said you shouldn't learn the CLI. In fact, I'll say it right here: you should definitely learn the CLI, especially for git, before moving to the GUI, or you will be confused (though even then, you'd probably be less confused than you would be if you started with the CLI itself).
> (not saying this would affect you this way, but it could certainly be a reason to not learn it in the first place).
No, it's most definitely not a reason not to learn it.The discussion was never about what you learn in the first place, but what you use. You should learn the command-line regardless. And even regarding usage, it's again a strawman: nobody even suggested you should never use the CLI. The question was "why do people want a graphical git client?" and the answer was "because it makes {tasks} easier", for some tasks. If you find any tasks that don't fall in that category, just use the CLI. It's just a tool after all, not a religion.
> I mean, it's not like you can ever convince me that >10 keystrokes are as fast as 1 click,
I know your reply was to debasarab2 and my upstream comment did say YMMV, but in fact it is a lot faster for me (and likely debasarab2) to type 10 characters than click an icon. My working mode is simply different. We’re not saying you’re wrong, what we’re saying is it’s not universal.
If I Haase to click a button I have to move a hand off the keyboard, shift my gaze, find the mouse pointer, move it, then BT my hand back to the keyboard.
Whereas on a command line I always know where my keystrokes go, I never have to move my hands or look away from the screen, and I have >40 years of typing at computers wired into my basal ganglia. (This is despite the fact that the first computer I used, a CADR lisp machine, had a mouse and bitmap display). GUI interfaces are simply much slower for me, except in very unusual applications. I am not claiming it to be universal but it is clear the affordances of the command line are significantly lower-friction for people accustomed to them.
My hands are on the keyboard most of the time too, I'm not a particularly slow typer, and there's no way I could write a proper git checkout-index command at the speed of just a click or two.
But again: I will believe you if you measure it and report back. So far the only person who's measured anything has been me, and I have to wonder why others are so averse to it.
Yeah, if you consider my arguments to be strawmen, then using a VCS GUI for the narrow use case of tracking down diffs might save you a solid few minutes. That just feels like a drop in the bucket compared to the overall time spent developing. YMMV I guess, depending on what organization/codebase you are working on.
Probably just GitHub (the browser UI). If you want to do it offline or from the command line, I understand why you might hesitate want to check out files, but stashing in git is extremely easy.
> You remember the hash of your June commit 3 years ago??
...which is what the git log above is there for.
> Web browser... for a local repo? Or do you mean you don't have a solution if your repo isn't on GitHub or you don't have an internet connection handy?
Yeah, local repo. You know, git is not GitHub. :)
> (You should also time yourself on your web interface by the way.)
Just paste the hash commit in the HEAD selector or even in the URL.
Try doing a merge with IntelliJ's 3-way merge UI. It's flippin' fantastic compared to roaming through the files and removing sections between >>>> and <<<<.
Many people are visual. It's a lot easier to see changes, compare diffs, and generally follow the development branches through a GUI instead of through a command line.
I think the main advantage of GUIs in general is a contextual, curated explorability that is often lacking in CLI tools. The GUI is stateful, allows the user to click on things and prod it, and hopefully shows the most frequently used features for that context. This allows even complete newbies to be productive almost immediately.
For something like git, the slightly more visual representation is a benefit to many, too.
I'm not here to knock CLIs, there are a set of tradeoffs to be made, and CLIs win in many cases (flexibility, scriptability, being able to copy snippets you frequently use, etc). The above does tend to hold true, however.
Infamous, and a more accurate description might be that discussions about git are well-known for quickly descending into discussions about whether or not it's intuitive and whether or not that matters since you use it every day you'll soon get it and no longer care that much how intuitive it is anyway.
Well on the face of it, it's a simple tool isn't it? It's a spinning saw blade, and surface(s) against which to rest the wood being cut.
And I've never used one, but I'm sure it takes some learning, skill, and practice to get good cuts the way you need them, e.g. bang on 45deg all the way across for a 'mitred' corner joint. And it certainly needs learning, care, and attention to operate safely.
I don't mean it to be an insensitive analogy - accidents involving table saws are obviously horrendously worse than those involving git.
As someone else mentioned here, the graphical merge tool in IDEA is extremely powerful. Plus keyboard shortcuts to all the main Git actions. It's overall more efficient. However I always use Git IDEA + Git CLI side by side.
Thanks for your thoughts on this, Thijs! Here's Tobias, the CEO of Tower.
We want to make sure that Tower can stay a high-quality application in the long run. This means we want to constantly improve the application, add new features, fix bugs, and help users with great customer support. To be able to do that, we need a steady and reliable source of income. The thruth is: for us - a small, self-funded business - a recurring revenue model from a subscription is the only sustainable way to survive.
A model where the user gets to keep the last version after she stops paying for the product does not work for a small business. If you have a team of 1,000 employees like JetBrains, you might be be able to afford this. But not a 7-person team like ours. For two reasons:
(1) First, it doesn't provide the steady and reliable source of income that we depend on. It's the old one-time payment model of the past - which we tried and which did not pay the bills for us in the long term.
(2) Second, and maybe more importantly: very quickly, there are lots of different old versions of the product out there. People want bugfixes, documentation and support for their version, no matter if they're currently paying or if they don't anymore. With a 7-person team, we simply cannot do this. We need to focus all of our painfully limited time on _one_ version and make sure to improve that one.
Most of our users make a simple calculation: "Can Tower help me or my team save some time or prevent some mistakes?" Over the course of the next 12 (!) months, even 1 or 2 hours or a mere handful of mistakes would make this worthwhile. If so, Tower has _easily_ paid itself off.
We offer a free and fully-featured 30-day trial that will help you answer this question for yourself - without any risks or commitments.
For the customer, automatically converting long subscriptions to perpetual licenses for an old version is a major safety net (the software will not stop working if I stop paying) and it proves that the vendor is committed to improving the product enough to make upgrades compelling.
On the other hand, reasonable customers do not expect support beyond the latest version and whatever they are currently paying for: "we have fixed that in the latest version, which you should buy" is a valid and honest answer to support issues.
For a tool that can be changed with very little friction like a revision control client, the typical "calculation" about spending money is likely to be waiting for an actual troublesome situation and then get out of it with a short subscription or a 30-day trial.
To summarise, you say you're not offering perpetual licenses for old paid-for versions because you don't feel you can make clear to your customers they don't come with support.
For some reason you do expect you can sell them on this new payment model that benefits mostly you, so it's really not your communicative skills or your customers' capacity to learn that are the problem here. That really only leaves us with the financial advantage to you.
Try SmartGit. I don't know how it compares with Tower, but it is very powerful and easy to use. I like the way it integrates Git features into a consistent view. For example, stashes and reflog commits can be viewed and manipulated in the same log view as any other commits.
They offer both purchase and subscription models, and a free license for open source work. Runs on Mac, Windows and Linux. I've been using it for years and have always been very pleased.
FYI, Git Tower is made by JetBrains is made by 7 people. JetBrains is a company of 1000. Not all software scales to allow that kind of model.
Also, JetBrains can afford that model because the JDK and other software languages are changing and it's not very feasible for their users to stay on an old version for very long.
Switched to Affinity, Photo, Designer and Publisher are pretty awesome and a true replacement for Photoshop, Illustrator and InDesign. Switched 1.5 years ago, never looked back and saved a lot of money in the process. There are a few things it doesn’t have, but its impressive nonetheless. The devs are very committed to speed and anti bloat.
FWIW, I think Adobe actually adds quite a bit to Creative Cloud every year, plus they offer fonts and connections with their mobile apps and such as part of the same price. Creative Cloud today is a very different beast from CS6.
(obdisclaimer: I worked for Adobe several years ago, but have no current stake other than being on the CC photography plan)
Same boat here. I’ll concede that they do add things, but as a pretty small scale hobbyist they don’t add anything I want or need. But they expect me to pay the same full price as a pro user.
I used to buy it every couple of versions or when it went on sale, and that was good enough for my needs. No such luck anymore.
Did a stint on Sketch as well. It’s now gone subscription, but it think it’s the more acceptable “still works but you stops getting updates” type subscription like jetbrains.
What I really want is an Affinity photo library manager like Lightroom. I’ve looked at some currently available options and not been impressed, but there were tweets to the effect that Affinity was thinking about it.
Best I’ve found is “considering it,” but fingers crossed! Seems like the next obvious step after vector illustration, photo editing, and desktop publishing
And I think all the plans come with cloud storage which syncs across devices.
I fought the subscription plan for LR, but realized I usually updated yearly and had this complicated file management system for my photos. For $120/year I have the latest LR versions on all my devices and only have to worry about true backup.
I do keep an eye out for a LR replacement, but I haven't found anything that comes close to LRs file management.
Intuit Quickooks is same way. Hasn’t substantively changed in 20 years but they stop you from importing new data if you don’t update to latest every 3 years. They need some real competition.
I upgraded to version 3 but feel like they haven't made a product improvement since, despite the new subscription model. Staging of chunks still remains the killer feature to keep me with it but I'd be happy to switch (pay) if anything else came along.
It’s interesting to see quite a few others in here had the same struggle with upgrading to tower 3 as I had a year (or 2?) ago.
Then I moved to vscode with it’s git integration and that works just as good.
