GitUp makes Git painless
gitup.co
gitup.co
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.
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.
- SSH to linux box with node on it
- Edit files via Samba/CIFS from windows box
- Run node/iojs via nvm for the project on linux
- ???
- PROFIT!
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.
Are you using npm shrinkwrap?
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.
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.
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.
[1] https://visualstudiogallery.msdn.microsoft.com/cf49cf30-2ca6...
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.
Fair enough, I get this, but I also found that if its your main professional tool, a few hundred either way isn't that big an issue.
2) I've grown up using Windows
I actually found that learning OSX stuff is quite simple if you just see it as a tool as opposed to a hobby.
3) I hate all the program menus being at the top of the screen.
Fair enough, guess that's personal preference.
Seems like you have fairly decent reasons for your choice, but I couldn't go back.
- 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
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"
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)
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.
And Ctrl-F2 isn't exactly as discoverable as "hit Alt," so I'm not surprised.
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.
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 :-/
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.
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.
http://superuser.com/questions/46452/weird-symbols-for-key-c...
Seems you are right about home and end having gotten text descriptions.
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 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.
also a repository viewer is not latency sensitive.
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.
- GTK+
- Qt
- wxWidgets
I'm not saying I have used them or they are easy to use - but crossplatform UI toolkits do exist.
- QT apps look alien on Mac.
- wxWidgets look alien everywhere.
There is no real X-platform UI toolkit.
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 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.
DRM-protected video in general is a giant pain in the ass that you don't really notice on the "blessed" platforms.
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
> * Slow as hell
Good to know I'm not the only one with this issue.
There are a few Git specific things if you're running Git < v2 that you can try: https://stackoverflow.com/questions/4485059/git-bash-is-extr...
And in Sourcetree, set options under Options -> Diff, set Size Limit (Text) to 128KB and Size Limit (Binary) to 1024KB.
> 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?
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.
Compressing the mapview (less white space) or zooming (Ctrl-+/Ctrl--) would be nice.
I never tried SourceTree, but used to work with macports gitk, which started missing redraws lately. There is no comparison.
GitUp is excellent.
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.
If you haven't already consider raising an issue, at https://jira.atlassian.com/browse/SRCTREE for OSX or https://jira.atlassian.com/browse/SRCTREEWIN for Windows, with info about your environment.
Thanks
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.
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.
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.
Look at mobaxterm [http://mobaxterm.mobatek.net/license.html] It is licensed under GPL version 3.
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.
For a single app: take a look at what happened when XChat tried to sell their Windows binaries as shareware: http://en.wikipedia.org/wiki/XChat#Licensing
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.
Financial Success Stories abound all around. MySQL, WordPress, Drupal, Mozilla (FireFox), Android, etc.
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).
http://www.redhat.com/en/about/press-releases/red-hat-and-ce...
My favorite IDE RStudio is AGPL which offers a Open Source license that also allows them to charge for added features.
http://www.rstudio.com/pricing/
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]
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.
I don't want to do that, cause I'd prefer they get more money, but it's neat to know. (I'll double check the license of course.)
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.
No thanks.
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.
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 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).
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.
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.
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.
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...
[alias]
hist = log --graph --pretty=format:'%C(auto)%h%d%C(reset) - %s %C(bold blue)(%cr by %an)' --abbrev-commit
ain't nobody got time for that
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.
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.
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.
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.
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.
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.
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.
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 hope no-one here ever has to deal with a tree like this.
https://github.com/torvalds/linux/network
"Couldn't load network graph. Too many forks to display."
OSX only and proprietary: no thanks.
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.
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 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 ;)
And it's not far at all from what a number of GitUp users are saying themselves: https://twitter.com/GitUpApp/favorites.
http://profitseduction.com/are-you-afraid-to-make-a-bold-cla...
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.
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.
> 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.
Then on top of it is an extensive toolkit I built in a few months for repo manipulation and rendering.
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.
gr = !git \
--no-pager \
log -n 16 --graph --date-order --date=short --branches \
--pretty=\
'%C(yellow bold)%h%Creset\
%Creset %C(blue bold)%d%Creset\
%C(white bold blink)%s'
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.
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)
After SourceForge turned evil, we have to be very suspicious of anyone trying to cash in on open source development.
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.
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?
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!).
Of course, that's explains in the man page.
0 - http://en.wikipedia.org/wiki/Usage_share_of_operating_system...
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 have been using Git cmd line and its easy to use and would not have it any other way.
Editing history (including comments) without a new commit is basically a revert to mutable history, which means shared git history suddenly becomes a problem.
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!
Here you go: http://forums.gitup.co/t/improved-error-message-idea-if-a-fe...
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.
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.
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).
Apparently it is not the interface I have been missing...
Having a Git tool not available for Linux is blasphemy
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.
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.
git is a tool developed specifically for Linux Kernel Development, GIT would not exist with out linux.. Linus Torvalds created git for linux.....
So releasing any tool for git that does not support linux, IMO is betraying the history and foundation of git.
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.
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).
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?
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.
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. :)
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.
Yea, I'm a huge fan of the free hardware they give away when you download open source operating systems.
I still weep for Sourcetree support for linux... ;(
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.
https://github.com/JetBrains/intellij-community
</fanboy>
git up https://github.com/aanand/git-up
Pick another name!