It's kind of amusing to me how the pendulum has swung, and we're now producing OS X-only developer software.
But then, I'm an oddball who works on Windows as my shell with the real work happening on a headless Linux box via SSH and Samba for 99% of my development.
+1 I was going to make a rather sarcastic comment that this is for "professional engineers", but is OS X only. Ubuntu on a VirtualBox on Windows for me.
I've not been able to run node apps because executables end up getting stored in /node_modules/, but if that is on a windows share, no executable flag is stored.
Resolving the FS differences has always been the biggest pain for me using windows as the core OS.
Disconnect is the management/config of VMs. We use vagrant, which means I have to check out the repo onto the drive to get the config...
Sounds like if either have to nest VMs (is that even possible?), check out the repo twice. Or have a config that is very different on windows vs everyone else.
Oh well... Maybe win 10 will support a Linux compatible FS.
I for one do all sharing of files between guest and host using Dropbox and git. I've found that shared volumes have many problems like the one you cite, and treating them like two separate machines is usually the easiest way for me. If I had two physical machines with the same configuration as my guest/host, I would use network-based sync, so that's what I do on my Windows host (gaming pc at home, laptop that needs to be work friendly) with my Arch guest VM.
A fleet of appropriately-powered OS X boxes is substantially more expensive, and a fleet of Linux machines can't be operated efficiently by the rank-and-file.
The node ecosystem in general is a mess; I don't think you can blame that on the OS. I did a node project recently and I've still not been able to get it to run on two seemingly identical systems in the same way.
Most mysteries come down to loose dependency declarations and semver stuffups, sometimes in combination. One of your deps' deps takes a ~ on one of its deps, that dep makes a breaking change and changes its version from 0.3.2 to 0.4.0… boom. Your fresh npm install on workstation #2 inhales the breaking change and doesn't work, but workstation #1 still works fine.
Fix: temporarily shrinkwrap from workstation #1 while you wait for the maintainer of the package with the ~ dep on the 0.* package to change to a ^ dep.
It's a machine. It's a lot more predictable than you think.
I understand how such things occur, but that's not an ecosystem I want to be involved in. If ~ frequently lets in breaking changes (and it does) then nobody should be using it--the entire point of having versioned dependencies is to prevent breaking changes from entering your system.
And tracking down these versions by hand is not a reasonable solution: some of these libraries pull down dozens of dependencies, each with their own dependencies, and it's not feasible to read the docs for every single package to find breaking changes.
> Fix: temporarily shrinkwrap from workstation #1 while you wait for the maintainer of the package with the ~ dep on the 0.* package to change to a ^ dep.
If I have to rewrite my entire install script to pull from a specific machine, the package system is useless, and I'll switch to a package system which is competently managed. What you're describing isn't a fix, it's a workaround.
In a larger sense, one of the main motivations for using other people's libraries is that libraries should "just work" and not need to be debugged and tested. That's not an assumption you can make in the node ecosystem. There are reasons you might want to test libraries, such as if you're writing crypto, or critical code on which people's lives depend. But the issues in node's ecosystem aren't that, they're just developers not following very basic development practices.
I stand by what I said: the node ecosystem is a mess. You've told me how to fix the node ecosystem's mess (which I already new) but the fact is, I have better things to do than constantly trying to fix other people's messes.
I tried npm shrinkwrap, but that only procrastinates on the problem: now instead of having to unravel a mess of dependencies on installation, you have to unravel a mess of dependencies whenever you want to upgrade a package. But now instead of having to solve a dependency problem that a bunch of other people have head to solve, you've created your own unique dependency problem. Not to mention that this completely bloats your installations.
npm shrinkwrap isn't a solution, it's a temporary hack and it makes things worse in the long run. Maybe you're only working on new projects, but I work on things that will have to be maintained.
You're not the only oddball. Some of us work on Windows software and NEED the Windows box -- I also use too many Windows-only tools to make the jump to Mac.
And what they do with Cmd-vs-Alt drives my fingers crazy, so I can't configure a Mac to be sane no matter what I try. And I use keyboard navigation to peruse menus, which OS X still hasn't implemented...the list goes on, and I stick with Windows.
Yup. I love that OS X is an actual POSIX environment with easy access to the standard GNU toolchain, but the UX drives me absolutely up the wall. I think that Windows 10 is actually a much nicer desktop than OS X.
I'll have a new Mac box soon. I'll try it. Last time I checked there was no keyboard menu navigation, and you're the first person to tell me that there is, so it must not be widely known.
And Ctrl-F2 isn't exactly as discoverable as "hit Alt," so I'm not surprised.
Could someone comment on the main complications on developing something like this for both Mac and Linux? From my point of view, they is so much common ground, comparing to a Mac/Windows support, that I'd strive for an application to cover both! And that's not something that you could always decide after launching the first time, you need to have it in consideration during design...
The non-UI layer can be made 100% portable for sure (although in the GitUp case it's not really since I chose to write it in Obj-C for productivity reasons).
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.
I was under the impression Qt has been maintaining their Cocoa styling well. Has that changed? I haven't actually tested Qt software on OSX in about three years.
Even with the Cocoa styling, Qt based applications always seem to feel weird or out of place. Things like button placement, toolbars, things of that nature just don't "feel" right.
Thats the "weird" thing about Mac users: noticing that things "doesn't feel right" while completely missing that somebody has mangled their keyboard (where is home/end? pg up/pg dn? Waht are these extra arrow up left and arrow down right thingies on my keyboard that even long time Mac users cannot explain? (Feel free to explain it and I'll give you an upvote tomorrow morning if I remember : ) why is fn/ctrl switched on laptop but not on full keyboard?
That said the most annoying thing about Macs is how much I'd love to be able to use one, even at their current price point they seem a good offer to me, - but after three years of trying to either adapt me or the Mac I have given up :-/
I've got a full sized keyboard, I've got an home/end, a page up/page down, and I am wondering what you mean with extra arrow up left, and arrow down right?
Are you referring to the arrows that signify home/end/page up/page down on the older full size keyboards?
On the laptop keyboard the Fn key is the outer key, followed by ctrl, then alt/option and then command on my full size keyboard it is placed above the delete button and to the left of the "home" button. It's not switched.
Either way, you could replace your Mac keyboard with one of your standard Windows ones and everything will continue to work without issues. So if the keyboard layout is a bother, that is easily fixed. You'll just need to remember to hit the windows key to copy/paste rather than ctrl.
3years ago this worked in some applications, in others you had to use the old ctrl-a/ctrl-e (which couldn't be combined with shift) or cmd or control-left/right/up/down.
Can't remember the details anymore, but I think I figured I needed at least three different combos for home/end back then.
I would have understood this remark a few years back. After having made such remarks for the last several years, and after having so much work done on UI/UX studies, let's become engineers again and be able to specify exactly what is not right.
The size and location of buttons is off, the font rendering isn't as crisp, in some cases the buttons are swapped, developers tend to not follow the HIG and buttons are named differently from their OS X counter parts. The toolbar will use icons that don't fit in with the rest of OS X. Closing the primary window will sometimes take the whole application down with it, rather than just closing that particular pane of glass, right clicking on the icon sometimes won't display the windows that are open, drag and drop doesn't seem to work as well onto certain fields. Text sometimes renders wrong, or buttons are not made auto scale-able so you have text hanging off the end. Keystrokes you expect to work in text fields don't, no dictionary or auto-correct (although that was about two years ago when I last built a Qt based application for Windows/OS X).
The list goes on. It's the same sort of list that can be made with Java based applications. CyberDuck was one of the few applications that surprised me when I first started using it with how well it fit into OS X and I didn't realise that it was a Java application underneath the hood.
Ultimately it comes down to the application "feeling" out of place simply because it is out of place and wasn't built or designed with OS X in mind.
I have only looked at the movie, because I avoid tools that work with only one provider, however this app doesn't seem to use that many OS X controls, and quite a lot of custom drawing (branches, editor, etc).
I think this could be done in Qt with QML, the most difficult problems would probably be the list that popped up on the right at one point and getting the scrollbars right. When it comes to graphics, animation and custom drawing Qt is very powerful, the issues that do pop up are with native controls.
The GUI systems are utterly different, so, for a GUI tool like this, you'd have to write the front-end twice. I don't think OS X and Linux are especially closer to each other than either with Windows when you're in that department.
Absolutely true... not to mention, that cross-platform gui toolkits look alien somewhere/everywhere ... IT's never/rarely a great experience. That said.
There's no market for this sort of thing on Windows. The vast majority of development that happens on Windows takes place in either Visual Studio or Eclipse, and those developers prefer tools that integrate with their IDE rather than be standalone.
Maybe I'm odd but apart from working in VS, none of your statements hold true for me. I saw this and was like 'gimme gimme' only to find out it is OSX only. Quite a disappointment, especially given the recent stall (afaik) in SourceTree for Windows development, making me go back to the command line more and more again. I vastly prefer standalone tools for things like git because else I have to learn the builtin tools for each environment seperately. (I do use Git Diff Margin for VS [1] though - in fact it's becoming more and more indispensable to me which actually shows what a great tool it is)
At my previous workplace I tried to introduce something better for code versioning than tarballs or (more often than not) date suffixed folders. We used windows. CLI was just a total no no. Long story short, I tried bunch of GUI tools/plugins. Most tools were either too simple for anything beyond personal repo or graphical git command/switch selector.
Out of everything I tried SmartGit [1] stood out for its power (never had to use shell for about half a year) and still graspable simplicity. IIRC supports custom providers OOB.
Take a look at P4Merge for doing your merges/diffs - it's a very nice tool for merging. You don't need the entire P4 ecosystem, the merge tool is standalone.
hear hear! I've been using P4Merge for years since it's indeed very nice, also have it set as 'external difftool' in ST. Only disadavantge for me: line ending settings for the merged file are fixed, which is messy if you have repositories from different sources and/or different autocrlf settings
Not the person you asked the question of, but I have a few reasons:
1) Hardware - cost is 1/2 Mac hardware, and I can upgrade cheaper as well. For example, my ultralight notebook came with 4GB Ram and a 128GB SSD. For ~$1000 - Mac equivalent was ~$1400 at the time, with no option to match the screen (1080p). Since then, I've upgraded but the SSD and Ram for another $300 - would have cost almost $700 to do the equivalent upgrade on the Mac and it would have been at the time of purchase.
2) I've grown up using Windows, CMD, batch files, etc. I know my way (a little) around the registry, services, etc. I'd have to relearn all of that on the Mac.
3) I hate all the program menus being at the top of the screen. I have a Mac on my desk at work...and it just drives me nuts. I'm sure I'd adapt, but it bugs me.
I could find more, but I've come to admit that I'm just a Windows user. If I need Linux or something, I just install a VM and go to town.
Main reason: I know it properly and hence can get pretty much anything done fast - faster than in the other 2 main OS'es. Although admittedly if I spent more time learning the others I could get things done there as fast or maybe faster as well.
Other reasons roughly ordered by priority:
- it has Visual Studio. Sure I can get around using an editor and a Makefile - or XCode if I really must, but nothing so far beats what VS gives me (note: mostly C, C++, C#)
- hardware indeed: decent, all kinds of form factors, not too expensive (though same goes for unix of course)
- legacy reasons: some of the hardware/software I work with only runs on Windows
- for desktop it is actually on par, if not better, then any other alternatives out there
- tried an MBP for 3 years but had a pretty bad experience with overall so turned back to PC harware. Yeah I know a single case is not representative but it was just too much trouble esp. given the money spent on it
We use git exclusively as a Windows-based shop and only 1 person uses the git integration with Visual Studio. Everyone else uses different solutions from tortoise to source tree to command line.
I think there's definitely a decent market for this sort of thing - I've had plenty of conversations locally that end with "Wow, I'm so glad to get away from Visual Studio for this"
I completely disagree, that is the kind of thinking that causes OSX only software to be written. I use Windows because that's what I grew up on and as a practical matter, I can buy the same equipment for half the price of a Mac. And I use all maner of "cool tools" like this as much as possible.
Pissing on devs who use Windows may have been somewhat valid a few years ago, but times are changing, and people use it even if they aren't doing VS/Eclipse work. (FWIW, I hate Eclipse. However, Visual Studio is a very good IDE, if you like IDEs)
1. The git integration in visual studio is incomplete (no ssh transport and no log rendering) so you have to complement it with an external tool. 2. Everything in a repo doesn't always belongs to a specific visual studio project.
I use this setup at work and I love it, the only thing I miss from my at-home linux setup is that I can't yank and paste directly to system clipboard with Windows. It's pretty sweet being able to yank in one buffer, flip over to another tmux window or pane and be able to paste seamlessly.
Yeah, I've just learned to use the Windows clipboard rather than buffers when I want to move stuff. Takes a bit of self-training, but it's not too bad now.
I have tried many flavors of Linux (I presume you mean desktops - I've run GNOME, KDE, Xfce, and a bunch of others), and I run Fedora (dev) and Ubuntu (HTPC) boxes at home. I've tinkered with switching fulltime to Linux desktops a number of times, and they're great 99% solutions, but the big showstoppers for me have been DRM'd video (Netflix, Amazon) and Steam (I'm a gamer, and 95% of my library doesn't run on Linux). With my setup, literally everything I care about runs without any real effort, and I don't sacrifice any dev power.
The really nice thing about my setup is that because all I need is an SSH client, I can work from my Chromebook, Macbook, or even my phone if I have to, and I have full access to my whole dev environment from anywhere. The biggest thing I've lost is the ability to attach to processes directly to debug them, but I just end up using terminal-level debugging or remote debugging facilities when they're available, and it works fine.
Netflix now works under Chrome (not Chromium) as of...October? But Amazon has broken as of a few months before that - they switched the DRM they use and the old solutions are no longer valid. As far as I know, there is no workable solution for Amazon video on Linux anymore.
DRM-protected video in general is a giant pain in the ass that you don't really notice on the "blessed" platforms.
I'm a SourceTree user on Mac. Just tried GitUp out for an hour.
Here are the problems I have with SourceTree:
* Slow as hell
* No/bad keyboard shorts, and setting up custom ones is annoying and buggy
* Uses tons of memory — it eventually gets up to 1 GB after running for a day or two, and my repos are not very big.
My thoughts on GitUp:
* Crazy fast (almost disarmingly so – I think it needs more visual confirmation when things happen)
* Excellent commit/staging view. Reminds me of GitExtensions, a nice Git GUI for Windows
* I love the focus on keyboard shortcuts. They work really well in the commit view
* Map view is truly awful. I get that it's a work in progress, but I have no idea what its organizing principle is. Too much pointless whitespace. It radically overprivileges old branches and commits. I don't see a way to focus on what I did most recently.
* The list of commits (Cmd+D) in the map view is useless
Sorry to hear about your issues with SourceTree, but thanks for highlighting them.
We are aware of performance issues for a number of users. To be fair it is taking us longer than we would like but, addressing these issues is our priority and we're working on it.
The slowness appears to be caused by continual directory scanning. For me at least, turning off the "Refresh when files change" option, and so having to do "view, refresh" or Command-R, made SourceTree be zippy again.
And as I'm usually on a laptop, having less continued CPU usage is a good tradeoff against having to press refresh when I'm going to do something in SourceTree.
Does not work, i've also heard from other sources that turning this option on makes it faster because then it uses some native file-changed-hooks instead of continuously polling the directory. For me both options are equally slow and many forum posts say the same. Sourcetree performance simply is crap and no fiddling with the options fixes this, nor should this fiddling be required. You can find bug tickets about performance issues dating back years but nothing happens, don't waste your time on sourcetree just because it looks shiny, use a tool that actually works.
> IMPORTANT: During Pre-Release, signing-up for a GitUp account allows you to enable advanced features (like rewriting commits), participate in the GitUp forums, access the "Continuous" build channel, and most importantly, show your support for the app and future developments!
Why do I need a GitUp account to enable rewriting commits?
Furthermore it looks like these prerelease builds expire. I'm guessing the released software will be neither free nor open source.
Anything can happen (I have a number of projects that are open-source, some other close-source), but the idea so far is to have a free app with an in-app purchase to unlock the advanced/pro feature.
I might make open-source some of the "Git toolkit" I built for this app, but it's too early to say.
The reason for expiring builds is that 1) it's pre-release, 2) it's a software intended for professional engineers and 3) the app is rapidly evolving, so I don't want to have people using old versions which may have bugs fixed since then: http://forums.gitup.co/t/gitup-release-notes/16.
It has a free version and a professional version which cost $69 per user. This does not break the GPL. You may already know this but it seems like a lot of developers think open source mean Free as in cost. [http://www.gnu.org/philosophy/selling.en.html]
This is also the reason why I don't like the term Free Software since people usually think it is speaking about the cost.
Although the GPL allows authors to charge for software, it disposes of all legal copyright protections that make such charges practical. Charging for GPL software doesn't mean anyone will pay you, it just means that everyone will get the free builds from someone else, which is even less desirable than releasing free builds since you lose control of distribution. Look at Red Hat and CentOS for case in point.
Yeah, Red Hat is really bleeding money from the all the lost sales caused by CentOS. I can't believe they only made a puny 1.53 billion dollar in revenue last year..
</sarcasm>
Red Hat has never made money because of its GPL software. People want to buy their support and consulting services, which Red Hat incidentally only offers for RHEL, necessitating users buy a license if they are to get the product they actually want. People who try to sell GPL software as a standalone product do not fare well.
Please note that the HN community takes a rather strict approach when moderating comments that contribute noise to the conversation. "Nice article!" comments are routinely downvoted. As is sarcasm, witticisms, memes, references and other styles of comments that occur frequently but do not contribute to the discussion. It's a knowingly doomed attempt to hold back the flood of noise that covers Reddit.
The parent comment, however, was actually relevant to the point being discussed (whether or not the ability to fork a free-as-in-speech but not free-as-in-beer program is a significant risk to one's business model). Sarcasm or no, it's a valid point, and thus I feel trying to spout off admonitions in the name of the "HN community" is inappropriate in this context.
Yeah, this was iffy. I totally agree with the comment. But, when it comes to maintaining a community, it doesn't matter if you are right if you are a jerk about it.
For the discussion: I recently paid for the Synergy software KVM even though it is GPL. Synergy's purchase process is very smooth. Paying $10 for the installers was much easier than compiling it myself. And, I was already had confidence that Synergy was useful, good quality, well-maintained software. So, I was happy to support it as long as doing so was convenient.
VA Linux Systems set a record for largest IPO and then tanked. The vast majority of Free-software based businesses have tanked too. RedHat is really the exception.
VA Linux Systems was a Hardware Company so your comparison fails in terms of speaking about Free Software Success Stories. Red Hat is far from being an exception. Actually old school closed source software companies are more difficult to start up today in my opinion.
Financial Success Stories abound all around. MySQL, WordPress, Drupal, Mozilla (FireFox), Android, etc.
None of those make money selling GPL software. The GPL software undergirds the product they sell, but it is not the product itself.
MySQL: Fancy proprietary version with non-GPL features makes money, GPL version sits there doing nothing. Used to make money from a traditionalist dual-license model before Oracle took over, now they just neglect the GPL version.
WordPress: Makes money from hosting and consulting, not from its software.
Drupal: ibid.
Firefox: makes money from search affiliate deals and charitable donations. This is closer because they make money by getting brands in front of Firefox's installed base, which is sort of close to making money from software, but still indirect.
Android: Google does not make money from Android directly except insofar as they negotiate licensing deals with phone providers for their closed-source "Google Apps" suite and/or for "Google Play Edition" or other official branding on a phone. In these cases, they are selling a collection of Android apps and/or Google branding, not the GPL software that runs on the phone.
I don't know of any case where a company sustained itself on the sales of actual GPL software. Every open-source company lives off ancillary services or licensing deals (dual-licensing like MySQL or branding deals like Google).
Yes. Does that change something? Red Hat finally acquiesced after 10 years. They started out threatening CentOS with a lawsuit, leading to the infamous "prominent North American enterprise Linux vendor" language that plagued CentOS's site until this deal was announced last year. If anything it's only further evidence for my argument.
GPL Encourages it doesn't discourage the charging of software. Please give me one source where they discourage charging fees for software. In regard to copyright you are 100% correct, but the GPL is copyleft not copyright. You can't blend in copyright and Open Source those are two different things unless the latest Google vs Oracle API fiasco follows through.
My favorite IDE RStudio is AGPL which offers a Open Source license that also allows them to charge for added features.
AGPL - The GNU Affero General Public License is a free, copyleft license for software and other kinds of works, specifically designed to ensure cooperation with the community in the case of network server software. [http://opensource.org/licenses/AGPL-3.0]
You can always dual license, and sell the second, commercial-friendly license for a price. You need to be careful that you're the sole copyright holder though, so you need a strong contributor agreement.
Sure, but this is not selling GPL software. This is giving GPL software out for free, and selling proprietary software.
I'd be interested in cases where people have made substantial money selling GPL software as if it were proprietary software; that is, where they are able to get the consumer to pay for the software after a short trial, in order to retain the privilege of using the software long-term. The GPL grants this privilege anyway, which is the problem. The consumer doesn't gain any value by exchanging their valuable money for something they already have (the right to use your software), so they don't do it.
Red Hat does OK because they can sell support for an OS to enterprises. Selling support for a Git GUI to individual developers (even end user apps in general) is a bit harder.
They provide integration of open components (which is good). Looking at their sources directory there does not seem to be an available build script to e.g. build a comparable installer (but that's legal).
While the source is free you can bump into trademark issues (I don't know if it's specifically true for MobaXterm though). You can go the CentOS or Iceweasel way, download the source, replace trademarked stuff and distribute the compiled binaries.
What made you decide where the line is for "advanced" features? It seems like doing any sort of actual work is considered advanced.
There isn't a feature I can think of that would make me consider paying for development tools, so I'll never be buying your software, so feel free to tailor your response (if any) with that in mind.
Fair question. It's not decided yet. The easiest code-wise was to put the Map editing features in that bucket, so that's what I did for now. Everything else (browsing, committing, stashes, repo config, undo / redo, cloning...) is free and no registration needed.
Just a thought: I sort of agree with the fact that "pay to use git in a more advanced way" is a bit of a slap in the face to new users.
For me, what I absolutely love about this is the quick view of changes in a commit. My usual workflow for this is
1. git log --oneline --graph
2. Copy commit hash to clipboard
3. git show <paste commit hash>
or worse
3. git difftool <paste hash>^ <paste hash again>
which is clunky as hell, and made worse that difftool operates on a single file at a time.
GitUp is the first application that I don't hate using that solves this problem.
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.
(Now it just sounds like I'm trying to avoid paying you for your work, but anyway.)
> 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? :)
I work at an organization with a lot of developers who first learned to use git through SourceTree. As far as they are concerned, "what SourceTree can do" is the entirety of how git works. While this is probably not great overall, I do think it is the experience of a lot of newer git users or people who aren't used to a CLI.
I also work at an organization where it is difficult (mostly just annoying I guess) to get software purchased. What I am afraid of is a bunch of people learning to use git through GitUp, and when I ask them to rebase something, they say "I can't because I don't have the pro version." Or even worse, some organization saying "we won't buy this for our developers because the free version does everything we think they need to do."
IMO, responsibly managing a git repository requires using a wide variety of the tools that git provides. Creating a situation which artificially categorizes those features into "essential" and "advanced" is bad for people learning git, because they probably should be learning those advanced things sooner rather than later.
I guess my vote would be (4) paid with trial, falling back to "view mode only" at end of trial.
The difference between #4 and #5 has to do with expectations.
When you download a free app, and then you discover that you need to pay for some features: That's a slap in the face.
When you download a trial of a paid app, and then you discover that you can get pretty far with the features of the free trial: That's a pleasant surprise.
>in-app purchase to unlock the advanced/pro feature
Preying on new git users when they need to do something "advanced" with their repository is pretty low.
>The reason for expiring builds is that [...] 3) the app is rapidly evolving, so I don't want to have people using old versions which may have bugs fixed since then
Controlling whether I can use the software just because it's an old build? You've gotta be kidding me.
I don't know if it's such a good idea to start by showing how easy changing commit messages is or even have this option that easily available, because after all you're changing the history and the beginner might not be aware what this really means, and beginners seem to be the target audience for this tool.
Actually, GitUp was designed to be for professional software engineers first, even though it may also appeal to beginners. It's faster than the CLI for a number of operations, and offers features that don’t even exist natively in Git like a visual commit splitter or a unified reflog browser.
The Map view documentation does have a large warning on rewriting history (which obviously is required for a number of operations), but I agree that an in-app warning might be good too: http://forums.gitup.co/t/using-gitup-map-view/34.
I agree. If you've already pushed to other repos with the old commit message, this can cause issues. The only time I actually change the commit message is when I'm sure that nobody else has seen it. I'm not even sure what happens when you change the local commit message, and push it again. Does it just get updated in the remote repo?
You get the usual Git error "unable to fast-forward" which means in plain English that what's on the remote repo doesn't match what you have locally anymore, so you can't push, unless you force.
In such cases, GitUp just prompts you if you want to force push.
If you decide to force push, then your updated commit message is on the remote repo as well. This is completely safe if this is your private repo, or you are pushing to a private branch. In any other situation e.g. a shared repo with a team or a public repo on GitHub, you should pretty much never force-push as this will mess up other people clones (as there are now 2 histories of the repo in a way).
I agree. Instead of promoting this as something very simple to do with GitUp, we should stop people from having people the urge to change commit messages.
Plus, as even programming data structures are increasingly immutable, I don't see why I would go change the commit message from a week ago.
Changing git history is simply and utterly wrong unless you are the sole developer, for the reasons you already understand.
I would even go so far as to say that even with a sole developer, this shouldn't be part of a workflow, as 1 developer can become 2 fairly easily.
I think you need to mention this in your homepage/video/marketing somewhere.
You're basically making it easier to mutate Git history, with all the concurrency issues that that creates. The reason why changing history in Git is hard, is because it should be hard.
You can't push your changed commits without forcing them, and if you force them, then you're overwriting the remote repo
and all guys having a clone will have "fun" on their next pull.
I realize this is a pretty broad question, but what is it about Git that people find painful? Could be Stockholm Syndrome on my part, but I have a pretty hard time understanding why someone can't spend a week getting up to speed with a tool they intend to use for years to come.
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.
Considering the top 5 questions of all time on SO for most technologies are trivial/basic cases or homework. Yeah, when I first used Git I had to look things up.
Now that I use Git daily a tool like this seems like a terrible plan. I don't even trust basic scripts for git commands I haven't written/read totally, something which I'm not prepared to do for this tool.
>Anyway, with GitUp, the idea is to have an interactive live map instead
I like the idea of a live map, but the "interactive" part seems silly.
> Considering the top 5 questions of all time on SO for most technologies are trivial/basic cases or homework.
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.
Yeah, I was coming here to post that Git is already painless. It's a tool you are intimately using if you're doing anything other than Hello World projects with your team; it doesn't seem too much to ask to actually learn how it works. And once you know it's painless.
Edit: I was thinking about it a bit more and it's actually one of the least painful tools I have ever used on a computer...
I don't think I'm in the minority of those that know how Git works and still find it one of the most painful tools out there. The interface should be designed with UX in mind, and Git's CLI wasn't.
I guess we worked with different tools... But what UX are you referring to when you talk about the git cli? What is painful about it (answering the parents' question I guess)?
I really love how your edit is the exact opposite you original statement. Good on you for coming back and adding your further thoughts to the discussion.
unknown unknowns. Odd choices for flags and commands. Inability to search for explanations of some commands.
These are all valid commands that do radically different things:
<pre>
git checkout patch
git checkout --patch
git checkout -- patch
</pre>
Yet, googling to find the difference is difficult (because search engines). If, eventually, you decide to search for 'dash dash', you'll start to find good results.
So, if a user had a file named 'patch' that they want to 'revert' back to the last committed version, they might try the first one (after all, it works for 'git checkout somefile.txt'). But IF they have a branch named patch, it would attempt to switch to it. It might succeed, it might fail, depending on the state of the tree, giving a very strange message compared to what the user wanted to do.
Despite it's ubiquity in the man pages, I haven't been able to find 'official' documentation or explanation for it, rather a bunch of blog posts and stack overflow questions. I find it hard to believe that a user who spent their time reading through docs and man pages would be able to work out the meaning on their own.
This is one example, but there are a TON of examples in StackOverflow as to what people find difficult. Most of my git knowledge comes from having to fix something that went awry. It's hard to 'spend a week getting up to speed' on a tool whose sole purpose is to manage other work.
> "Most of my git knowledge comes from having to fix something that went awry."
Can relate to this.
> "spend a week..."
I didn't mean it in a literal sit-down-and-read-all-the-man-pages sense, but frequent use does get common commands wired into your muscle memory. Also, if you're working in a team, which takes code review seriously, then your VCS is nearly as important as your language runtime. Yes, it's about managing process, but I feel it's just as integral to shipping as writing code.
> but I have a pretty hard time understanding why someone can't spend a week getting up to speed with a tool they intend to use for years to come.
Because it may not be for enough years. I've used CVS, SVN, Git in less than 15 years. I still have clients on SVN because Git is too much to get to grips with.
> what is it about Git that people find painful?
Why is there no built-in 'tree' command? I am lost without my .gitconfig and the aliases I have set up to give me a visual view of the repository.
Also, the difference between HEAD^3 and HEAD~3. I have muscle memory to do what I need, but for more occasional tasks I am searching StackOverflow.
I haven't used other DVCS so I don't know if the pain points are Git, or they're the complexities that DVCS brings. I look forward to the next (r)evolution in source control, when I hope we have power but more human-friendliness.
I still like a GUI from time to time. I use SourceTree. I can use GIT on the command-line and I'm a competent developer but I like to be able to click files and see the changes and just drag them into a commit. It may not be the fastest way, or the most advanced but it works for me.
Git command-line works fine, but I am not expert. Once something goes wrong, I find it impossibly hard to figure from Git command-line what is going on. Visualizing the repository (using SourceTree for example) makes understanding the problem trivial. Working 100% on the command-line with Git feels like having to move things around while being blind.
Not convinced? Try to stop using a whiteboard, drawing diagrams to explain things, using body language, etc. for a while.
I am been wishing for a tool like this GitUp for a long time, even thought about building one myself except that I see a lot of anti-GUI sentiment amongst many Git users, aka potential customers. Glad someone is making it.
I've also used some visual tools, but I always end up abandoning them after a short while, since I don't feel that they add to my workflow. Probably just a matter of taste and familiarity then. It's possible that I'd be marginally more productive with a GUI tool, but I'm too comfortable with my current process to bother. I'll admit to straying and using Github for Mac when I've made lots of changes without doing frequent small commits :-) It often beats `git add -p` in UX terms.
BTW I don't get all the negativity in the comments about Mac-only tools. A huge number of developers use Macs specifically for well-designed third party software with *nix goodness. I wish other platforms had the same quality of third party software, but they just don't. This is mostly because it is much more difficult to make money selling software for other platforms, for whatever reason.
In any case, I don't see the justification for ragging on someone for developing for (1) the platform they choose to use themselves and (2) the only platform where indie devs can make any money.
i'd expect any significant project to have a tree _at least_ that complex. here's a small sample of my company's tree with several team repos merging into a master repo. this tool really loses its usefulness quickly for repos this complex..
The general verbiage, tone and saying things like "It will change your life as a developer" makes me not really want to look into it.
Show, don't tell, that's my advice.
Anyway, the main point is you are making an effort to build something that can solve problems and you are putting it out there, so well done on that front.
Right. So... SHOW and don't tell ;) -- ie Axe/change the heckle raising verbiage.
Edit: If you make something great you don't need to brag, it's just great, and people will get that.
Edit 2: Think of it like this. You're creating a conversion funnel. People are landing on your page. If 50% of them instantly leave due to the bragging then the conversion funnel is not very optimized. You want as many people as possible to get into your funnel and few as possible to leave on any one step.
If you make something great you don't need to brag, it's just great, and people will get that.
If the "brag" is factually correct and doesn't spin or otherwise misrepresent, what's the problem? Some people might be repelled by "brags." Others might be repelled by being overly concerned with someone else's style.
- "The Git interface you've been missing all your life has finally arrived."
How can those possibly be factually correct brags?
Edit: Looking in to swisspol's real world profile... I must admit he's achieved so much that he probably does have the right to brag, so this may all be a moot point anyway ;)
The Git interface you've been missing all your life has finally arrived."
Exactly what does "change your life" mean? This isn't false, as it's entirely subjective. Its inclusion in the marketing text is merely stylistic. You could even say that it's "not even correct," but, you can't say that it's false. The same goes for the second sentence, depending on your interpretation of it.
How can those possibly be factually correct brags?
Essentially, those are stylistic flourishes, typical of marketing, devoid of facts or falsehoods. Again, they are "not even incorrect" -- but all the same, you can't call them incorrect. This goes to my point: You are being concerned about the style of text, not with the content of the developer's output. This puts you into a strange position, as when you object to a tangible thing which can be evaluated empirically on the basis of its marketing style alone, you are just as guilty of style over substance as what you are objecting to.
Looks interesting. I think speed is absolutely important when it comes to version-control interfaces. It was one of the main reasons Linus created it in the first place (as opposed to SVN), and I'd argue it's important to maintain flow.
My current git interface is "tig", a curses-based command-line client, which I enjoy for its speed and simplicity. Gitup looks appealing for similar reasons.
The tree visualization is nice, but if you'd rather use a (Mac only) GPL tool then Gitx-dev, a fork of Gitx, is still pretty good (http://rowanj.github.io/gitx/).
> Because it bypasses the Git binary tool and interacts directly with the repo database, GitUp is vastly more reliable than other Git clients and often faster than the command line.
There's something really satisfying about seeing a visual representation of my git repositories, but my overall impression is that I'm not going to get any productivity gains here.
If you know what you're doing, CLI is just faster. I understand that it's aimed at more novice developers, but I think for those developers it's even more important to use the command line. Developers that get into the habit of using unnecessary graphical UIs always seem worse off because of it.
> If you know what you're doing, CLI is just faster.
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.
Does this mean we have to rely on your code to be fully compatible with the repo database? I mean git is obviously tested and true when it comes to modifying the database, so I trust it.
Now I don't know anything about the formats used, so maybe it's not a big issue. But for such a critical piece it's quite important.
The 'gr' is short for 'graph'. You can tweak the -n to show more history. I actually have several of these, 'gr', 'grr', 'grrr', etc. to show more and more history.
I think your alias might have gotten cut off; the last color tag is never reset. Also, I don't understand, why disable the pager and limit the number of entries?
I needed something like this when I was starting out, and still occasionally do. Obviously once you've had a few dozen commits you get a hang of things, but initially, the visualisation can help a lot.
For my co-founder who's just getting started with software engineering practices like version control, I recommended she use ungit (https://github.com/FredrikNoren/ungit)
I've tried to use GitX and SourceTree in my workflow and always end up going back to gitk. There's always some information, view or action I can do in gitk that I can't make the others do. I find git from the command line to be the most painless. Everything else is always the third thing after gitk and command-line. Seeing multiple stashes used to be a great extra feature, then I just stopped using stashes.
I think your choice, swisspol, to use the 'free-with-in-app-purchase' model is the right one. You're selling to OS X users, who are willing to actually spend money on apps and software, and it allows us to use an app and then decide if we want to buy it. All that really needs to be said is, "GitUp is free with lots of capability to get things done. But to speed up your workflow even more and use all of its features, it offers an in-app purchase to upgrade." Plus, we as OS X users are used to noticing that little 'in-app purchases' note on apps and don't think it's a "slap in the face". I just hope that it will be available on the Mac App Store. I trust apps most that are sold on the App Store and I always look there first. I tie my card to my iTunes account or even have gift card money ready to make a purchase. Also, I can see when it was updated, what others say about it in reviews and share it quickly and easily. Just my thoughts, @swisspol
Dialog box? Why not drag and drop? Just drag this branch into the branch, to indicate what shape of graph you want, and it merges to make it that way.
How about an interface where you can pick commits from a graph, and drag them into a free space, where they exist as labeled points. Then, draw line segments among hem and connect them to a graph. Then, the software cherry picks these commits according to what you've drawn and creates that branch. The need for a merge could be indicated as a red blinking light on a node. (And the not yet cherry-picked segments are grayed out.) From there you click on it, get a list of conflicted paths, and engage in resolution UI. The blinking indicator goes away, and the cherry pick continues.
Sounds very nice. I'm using SourceTree and it slows down my entire system because I have up to 50 active repo I use which are updated often. Even when I turn off automatic fetch.
Proprietary development tools are a trap. And this software is just a proprietary wrapper around a real community product. Doesn't matter if you rewrote the library for interacting with the database... standing on the shoulders of giants.
Are we really at the point where "professional engineers" need to buy a GUI as a substitute for a fast, extensible, cross-platform command line tool that is so easy to use that even I could figure it out?
So you say, but if that's what everyone thought then GPL would have won instead of MIT. In every thread, the amount of "GPL is viral" people far outnumber the GPL defenders. It's clear that most people prefer to be able to build proprietary tools on top of open source ones.
So you say, but popularity "in every thread" (whatever that means) is a silly metric. Also I'm not sure what you mean by "then GPL would have won instead of MIT". Its not a war, even if some trendy corporate wannabe hacker tries to convince you that it is so that you give him the fruits of your labor for nothing. And if it was a war... show me the MIT licensed toolchain, the MIT licensed OS, etc. I'm not hating on permissively licensed free software at all, I appreciate those who write it and give it to the world... but I'm going to call you out if you try to sow the seeds of division among hackers.
Huge disadvantage that it's only for OSX. I don't know but I think the most people who can't already handle git should be on Windows, right? Or on the web. That's an attempt to be the best tool ever for people who don't know git yet and it's not aiming at them. That's really a pity, because I hope it would succeed.
`man git` make git painless. And it works on almost any platform.
I've also got to say I dislike how this makes history rewriting so simple, advertises it so much, but shows no warning as to the complications this can bring (anybody else using this repo will suffer greatly on the next pull!).
If StackOverflow surveys are any indication, more like 21.5%. I completely agree that I wish it wasn't tied to Mac (Linux please and thank you), but the proportion of developers is higher on OS X than in the consumer market. I have no data to support this, but I suspect that many of those devs on Mac are also front-end, which (again, no data) makes me think that they might care a lot more about a nice GUI tool than devs on other OSes.
I like the name GitUp for two reasons. First, it has the meaning "get up," and second, if you say "GitUp" out loud, people would reasonably hear "GitHub," then you'd have to launch into an explanation of the differences between the two.
Editing history (including comments) without a new commit is basically a revert to mutable history, which means shared git history suddenly becomes a problem.
IANAL, but they almost certainly don't need permission. Typically you just need a message that says X is a registered trademark of Y. GitUp is unaffiliated with Y.
Also, it's entertaining to me that in one comment you say that closed-source proprietary software is bad, and in another comment you're concerned about whether they follow trademark law. I understand that it's not a direct comparison and open source software is still subject to IP law; it's just that the juxtaposition of your comments is a bit silly.
Talking about "IP" law as one thing is useless. There's certainly no real-world validity to the idea that ideas are property, but even if we accept the legal concept of it…
Copyright is a restriction that mostly censors the sharing and building of ideas freely. It should be abolished. But it's currently used to deal with plagiarism and to support copyleft licenses. We should have stronger legal protects for attribution, against false endorsement claims, and support technology freedom with mandates for source release for published works and prohibition of DRM.
Patents are just bullshit. We should abolish patent law and just have better social systems for grants and funding for research (although it might already be true that almost all useful patentable inventions are built on socially-funded research already).
Trademark is a consumer protection. It is absolutely essential. It protects people in the market to know that they are dealing with the same legitimate entity when they see the trademark in use. There are cases of abuse or of it being overly strong, but trademark is totally important and basically positive.
IP law is pretty important to open-source keeping rights to names too, and git is open source (GPL v2 IIRC). Don't see the contradiction, as parts of IP law are needed to make sure contributions remain open.
You can email the Software Freedom Conservancy to report its use, even if you don't know whether they have permission or not. They'll sort it out. http://git-scm.com/trademark
Also I have the feeling that if they had permission that they wouldn't forget to add a notice about it to the bottom of their page.
Mostly because I didn't have time for one and also because I wanted not to require people to listen to some speech to understand how GitUp works (which you can't always do at work anyway).
Yeah, I simply don't understand this recent tendency to launch on Mac first. Out of the big 3 (Linux, Windows, Mac), Mac is by far the worst platform to launch on because you have to buy hardware. Please can we stop it now. Just launch on Linux - everyone can access Linux no matter whether they are PC or Mac.
The Mac is a phenomenal platform to launch right now if you make software targeted at developers. There's huge growth in mobile development, and many mobile developers work on OS X. Not just iOS developers, I'm seeing lots of Android devlopers working on Macs too recently.
And if you make a new tool, you should go where the young (in the sense of experience, not age) developers are. Experienced developers already have their workflows all set up and don't try new tools as often.
Even if its inconvenient for those who don't have a Mac, from a business point of view, targeting the Mac is absolutely sensible.
Having just (involuntarily) switched to a Mac at work, I can also attest to the fact that Mac users tend towards impulse buying software... The fact that I have to buy software to get proper window management and a good window switcher makes me furious. App-only switching makes no sense to me. I just want to pull up the last window I was looking at, I don't want to have to think about whether it was in the current app group or not. Also, not allowing that to be customized makes no sense. The OS has all of the info needed, and the market for 3rd party apps shows there is a desire... but I guess I'm just 'holding it wrong'.
Most people in the office have spent $100 on software that just customizes the OS, not even considering the other dev tools that they purchase.
As much as I detest OS X, IF I were releasing desktop software for-pay, I would focus on OS X ($ per user) and Windows (kids & college students).
It is true and I dont like this either but I still prefer working on OS X than windows because in windows I cant use most of the tools I use and than linux because of the pain of running linux on desktop.
OS X is a nix that works well on a very specific puece of hardware. I am not wasting my time and sanity fixing some driver compatibility issue.
> The fact that I have to buy software to get proper window management and a good window switcher makes me furious.
Off-topic, but what window management software did you buy? I use Spectacle (http://spectacleapp.com) which is free, and it seems to fit my needs fairly well, but, uh, I'll live up to your stereotype and admit that I'd be glad to pay for something better. :)
>Most people in the office have spent $100 on software that just customizes the OS, not even considering the other dev tools that they purchase.
What's your point? Most people have spent >$100 on going to a theater to watch movies, which is arguably a much worse way to spend money than improve your workflow.
Windows has much worse window management than OS X, and so does Linux. Just because the info is there, doesn't mean the Apple team should handle ever edge case and scenario ever.. that's why you have applications. Should an OS also come with a perfect and free IDE?
I'm trying to figure out what on earth you mean by OS X having better window management than Windows and Linux. Of the three, I've long considered OS X to have the worst.
>Experienced developers already have their workflows all set up and don't try new tools as often.
Speak for yourself. I'm always trying new tools as they come available, and was thinking that GitUp would be a fun one to add to my toolset. And then I saw "Mac Only" and groaned. I don't own a Mac, and though I will likely buy one soon (for iOS dev reasons), it will always remain my ugly-stepchild dev box, that I own only to do Xcode builds, not any serious development work.
I simply don't understand how so much weight gets thrown behind such a perverse walled garden from DEVELOPERS. We know far better than this and ObjC? Swift? Eat that right up. It's so unhealthy.
Releasing closed-source software on Linux is a pain, unlike Mac where you can assume most people will be running one of 3 recent Mac OS X releases (or even 2)
He missed the word special. You need to buy special hardware from Apple to use OSX (or figure out how to make Hackintosh work), while Linux can run on just about anything. Also, sidenote, some places do give out hardware with open source operating systems, eg Free Geek[1], but of course this sort of thing isn't available everywhere.
? The market share of people actually running a platform probably matters more than the number of people theoretically capable of installing a platform.
IntelliJ IDEA (after a while getting font rendering working properly) has an amazing set of VCS functionality and works quite nicely on Linux (have used on Gentoo and Arch). Of course it's ostensibly aimed at JVM languages, but has good support for PHP/JS/Python/Ruby/etc. There's also an upcoming C/C++ toolchain for it (the CLion experimental builds will eventually be a plugin for IDEA too). Most of the great VCS features are available in the non-commerical open-source branch too:
Similarly Eclipse's EGit is pretty nice too, although, being based on JGit and not the reference git implementations it has a few features here and there that aren't supported. But the on-disk format is compatible so you can always apply the commandline tools if needed.
…and not release under a free/open license for GNU/Linux. Yeah, right. That stinks. No joke. Proprietary software for proprietary OS's ought to not exist.
There also is nothing wrong with proprietary software. Don't run it, or purchase it if you have some moral disagreement with it, but many people don't and are perfectly happy to pay money for it.
There are a lot of people who believe there is something wrong with proprietary software. You don't have to agree with the FSF or their goals, but it does everyone a disservice to conflate the argument for software freedom with an argument against proprietary software. The FSF considers commercial use and distribution of software to be an important part of software freedom and does not consider licenses that forbid it to be free.
And if you think it is unethical to sell proprietary software and refuse to use it oneself, it is also perfectly reasonable to advocate that others follow the same course. A value position that one doesn't believe others should follow isn't a value, it's just a preference.
There's absolutely things wrong with proprietary software. It leaves software users in the position of having technology that they cannot control freely. See, e.g. the arguments from GM and John Deere that you do not have permission to modify your own car or tractor. Or countless other examples.
And basically zero of the people who pay for proprietary software are saying "I'm so glad this is proprietary". They pay because the package of what they get in utility is worthwhile and outweighs any concern about the proprietary nature of the software.
You see, I think this is exactly the kind of entitled attitude that pushes away people from Linux.
People don't give a damn about the intricacies and history of their tools, they care about getting a good work done in the less stressful way.
I stopped using Sourcetree a while ago, and I can't say I particularly miss it.
It's slow, RAM hungry, and their "recent" updates have made the tool unusable in my opinion.
If I pick a range of commits in the log: I can no longer get ST to show me a tree of files which changed between those commits. To add insult to injury: the list of diffs often only shows changes to one file, regardless of how many files are actually changed between those two commits.
These days I just use the command line and w/ Splice[0] I've got a nice diff/mergetool right in my editor.
I don't have a Mac at hand and the best effort I can do is to finish the 90 seconds. I would suggest an attempt to include more info in the stock view... Even the metro map have station names. :-) People do not recognize commits with just graphical patterns(especially when the patterns are just pulled in from remote).
But then, I'm an oddball who works on Windows as my shell with the real work happening on a headless Linux box via SSH and Samba for 99% of my development.