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.
