But yes, I wasn't really worth actively maintaining it as it was feature complete and I didn't intend to build a business out of it.
317 karma · joined April 15, 2011
But yes, I wasn't really worth actively maintaining it as it was feature complete and I didn't intend to build a business out of it.
Unlimited undo / redo is achieved by taking a snapshot of the entire repo before and after any operation (e.g. checking out the repo or creating a branch etc...). The inspiration I had at the time was that is it is trivially cheap to take such snapshots: essentially all you need is a list of all the refs.
Then when you need to undo, you have 3 things: 1 - current state of all the refs in the repo 2 - state of all the refs from the before snapshot 3 - state of all the refs from the after snapshot Compute the delta between 3 -> 2 and apply on top of 1.
The same technique allows to do the Time Machine feature.
When the US fines foreign banks, VW group and others for incredibly higher amounts of money, it's fair-game but when France fines a US company after an 8 years investigation, it's not, and the authorities don't even get the benefit of doubt that maybe they know what they are doing and have a solid case? You don't have any basis to make such a statement that this is only about some revenge.
France was one of the top markets for Apple and had 20 years ago a vibrant network of small retailers dedicated to Apple hardware (without comparison with the distribution situation in the USA). That went downhill once Apple started its online store and then its physical stores. Maybe it's just survival of the fittest, or maybe Apple also tipped the balance in a way that's not ethical or maybe even not legal. That's why we have such government bodies as "Autorité de la Concurrence".
> it seems that Apple was engaged in some otherwise normal business practices.
The "Autorité de la Concurrence" probably has the best grasp compared to anyone on HN regarding what is "normal business practices" and what the law allows in France, which is not the USA.
From TC article, the accusations are rather quite specific:
=======================
The competition commissioner noted that Apple and its partners violated three specific areas:
— Apple and the two wholesalers agreed not to compete with each other and also to prevent other distributors to compete on price, “thereby sterilizing the wholesale market for Apple products.”
— Secondly, premium distributors were forced to keep prices high to keep them at the same level as those of integrated distributors.
— Third, Apple has “abused the economic dependence” of these premium distributors, by subjecting them to unfair and unfavorable commercial conditions compared to its network of integrated distributors. (These last two points relate specifically to the accusations eBizcuss had lodged against the company.)
=======================
It was a known fact at the time (10 years back or so) that independent Apple retailers were not getting stock from Apple for certain products and therefore couldn't meet demand from their customers. There were even some "hot" products that could only be bought from apple.com or its own physical stores. I don't know if some of these practices were illegal or not (that's why we have government bodies to act as arbiters and enforcers of the rules), but it certainly didn't help the retailers.
There's some more details in https://www.lemonde.fr/economie/article/2020/03/16/concurren....
Eventually the two will get merged but it will take some time to figure out the right copy.
Disclaimer: I made GitUp for that very reason ;)
This means that writing GitUp in Swift would be a ton of overhead for very little tangible benefit.
See examples of what well known Mac developers have to go through with Swift: http://inessential.com/swiftdiary. I'd rather spend my time on building the app rather than on dealing with Swift.
GitUpKit is a multi-level API design so you can just use exactly what you need from each level depending on how much control you need (e.g. you can use a raw diff rendering view or a ready-to-use full-featured diff view).
Happy to answer questions if any or just visit http://forums.gitup.co/ where the GitUp community lives.
And it's not far at all from what a number of GitUp users are saying themselves: https://twitter.com/GitUpApp/favorites.
> So my suggestion is: remove ALL the modification features from the free version, release it as a separate app called "GitUp Viewer" or something, and then sell the version that is actually a git client.
Hmmm... but wouldn't that be exactly the same problem of "slapping users in the face", except now with 2 apps?
There aren't that many options to distribute desktop software:
1) freeware
2) free to use but ads or equivalent
3) paid upfront
4) paid with trial
5) paid with in-app purchase for some features
6) a free basic app and a pro app
#1 and #2 are not an option here and #6 is too much overhead and complicates the user proposition.
I don't see how #3 is not worse than #4 and #5. Not an option either anyway: I truly think people should be able to try before they buy for such a product.
#5 is all the trend on mobile and has been demonstrated to work (I've also done that on a couple desktop software and it seems OK). IMO it's the best of both worlds if done right: you get a free useful product as-is, but pay to get even more value of it.
If you think #5 is a "slap in the face of new users", wouldn't #4 also be that? :)
Another example: if I do something in terminal, I don't wanna have to wait 5s for the Git client UI to refresh.
All these little half a second here, a few hundred ms here, add up, especially when you're trying to deal with thousands of commits.
To a certain degree, yes, but we're talking here about the top 5 question across all technologies and tools used by developers on the most popular reference site and by far. And Git stands out by far, not anything else ;)
> Now that I use Git daily a tool like this seems like a terrible plan.
Trust is important indeed. In case this helps, GitUp comes with snapshots and undo/redo and you'll always have the reflog as well. It's actually really really hard to lose committed work in Git.
The UI layer is absolutely not portable: it's all low-level CoreGraphics code for the rendering, some CoreAnimation, and a ton of AppKit of course.
You could have a version written in a cross-platform UI toolkit or Java or what have you, but you could not possibly get close to the level or polish and native performance required for an app like this IMO.
This is quite true with other Git GUIs since they pretty much wrap the Git CLI and add a bunch of dialogs and whatnot, but GitUp was designed especially to avoid that. I'm a big user of the CLI myself, so the last thing I wanted was to build a Git client with a slower interaction model :)
Between the keyboard shortcuts and the fact it deals directly with the repo database, GitUp is actually faster than the CLI in a number of cases. Experienced Git users do notice it on Twitter and on the GitUp forums. One example from my workflow: just rebasing my work branch is instantaneous in GitUp while the Git CLT takes a couple seconds (the UX being as fast in both cases to perform the operation, so a net gain for sure).
YMMV of course and you can totally use GitUp for some operations and Git CLI for some others.
IMO this all boils down to the Git CLI just being terrible e.g. “git add” to stage versus “git reset HEAD” to unstage. Pretty much everything is like that. And there are always edge cases so that a command works in this case but not in that one. Want to edit a commit message? "git amend". But only if the last one. Otherwise it's "git rebase -i" (even though your intent is not to do a rebase, go figure). Well, not if it's a merge actually, you'd need "git rebase -p" or something... Even if something is conceptually simple, Git CLI manages to make it complicated. And GUI tools don't help much as they just wrap the Git CLI.
Of course it does make sense if you know how Git is built internally, but that's irrelevant to getting the job done :)
Anyway, with GitUp, the idea is to have an interactive live map instead, where operations and UI actually make sense, while still being 100% compatible with Git under the hood.
> The list of commits (Cmd+D) in the map view is useless
Could you provide feedback on http://forums.gitup.co about what you are specifically trying to do or what your workflow is?
It'd be very helpful if you could take a minute to post a topic at http://forums.gitup.co so I can have a look. Thanks!