It's unclear to me what you're referring to, but the part I can answer is this:
> How is git hard?
IMHO because it is not intuitively obvious what it means for your "HEAD" to be "detached", or for you to "rebase" onto a "remote branch", or why "checking out" a file reverts your changes, or why "checking out" a branch suddenly clones its files, or why you'd "add" a missing file to remove it, or why you "committing" doesn't actually commit your changes to the central repo, etc.
I want to edit the commit message of a commit that is 5 commits in the past, that I have not pushed yet. What is the command to do it?
Okay so it turns out I made a minor typo in that commit and I want to change it without adding any more commits. What is the command to do it?
Okay so now I want to take all commits that have "bugfix pickme" in the subject and cherry-pick them to master. What is the command to do it?
With a decent interface, these actions are basically trivial. I've been using git for several years and I have to think way too hard to figure out what to type just to get what I want to happen. All too frequently I just say 'screw it' and make a sad commit because my job is writing software, not wrestling with git commands.
> I want to edit the commit message of a commit that is 5 commits in the past, that I have not pushed yet. What is the command to do it?
Probably something like:
git --rebase -i --force HEAD~6
...followed by setting the commit in question to "edit"; then once the rebase pauses on that commit, using `commit --amend` to edit the message; and finally `rebase --continue`.
> Okay so it turns out I made a minor typo in that commit and I want to change it without adding any more commits. What is the command to do it?
Same as above, except you'd make the necessary change before `commit --amend`.
> Okay so now I want to take all commits that have "bugfix pickme" in the subject and cherry-pick them to master. What is the command to do it?
With a decent interface, these actions are basically trivial.
You might be able to do this with one of the filter commands, but I haven't used them enough to know. I'd probably just write a shell one-liner for this instead.
> I've been using git for several years and I have to think way too hard to figure out what to type just to get what I want to happen. All too frequently I just say 'screw it' and make a sad commit because my job is writing software, not wrestling with git commands.
Yeah, it's totally understandable. Between myself and the other dev on my team, I am the de facto git fixer. My coworker occasionally digs himself into a hole and becomes frustrated. Then the next day I do that with CSS, and he has to bail me out. I guess the point is most people have things they are motivated to specialize in.
Do you view that as in any way acceptable for a UI? All of these things are ultra-common operations. If Outlook were written this way, you'd have to type
> Do you view that as in any way acceptable for a UI?
The reason git is great as a console program is because the fundamental underlying problem you're trying to solve (graph manipulation) is complex. Graphical UIs only work for simple problems.
I think most people would like a simple graphical UI, but no one has been able to create one that has the same power as the textual one.
This is akin to the reason people don't use visual programming languages.
> The reason git is great as a console program is because the fundamental underlying problem you're trying to solve (graph manipulation) is complex. Graphical UIs only work for simple problems.
Is this meant to be ironic? Everything is literally the opposite of what you said. The entire reason why people make programs like the one you see here is literally that git sucks as a console program, making tasks that are inherently simple (and demonstrably so with a GUI like TortoiseGit) much harder on the command line.
> I want to edit the commit message of a commit that is 5 commits in the past, that I have not pushed yet. What is the command to do it?
> Okay so it turns out I made a minor typo in that commit and I want to change it without adding any more commits. What is the command to do it?
It seems pretty easy to do an interactive rebase for both these.
> Okay so now I want to take all commits that have "bugfix pickme" in the subject and cherry-pick them to master. What is the command to do it?
This would be pretty simple if you know the hashs of the commits you want to bring over, but more troublesome if you don't. But I can't think of a good interface that makes this trivial without having a specific command for just this action. If this is a common action you do it would be pretty simple make a script which would make that specific command.
Additionally, an interactive rebase can hammer this screw too. With an editor that can delete lines that don't match a regex you can simply rebase your bugfix branch on top of master and get rid of all commits that aren't bugfixes.
I would say that git's existing interface solves this as well as you could expect a GUI or CLI frontend like the post to do.
SourceTree's interactive rebase feature is amazing at the first one. You can also just change a dropdown to "Amend" and start changing your most recent commit.
TortoiseHg's search bar was amazing at deciding whether you were searching for commit message, author, or what. You'd just type "bugfix pickme" and you'd get back only the commits you needed. Check out master, right-click the batch, graft. I have five different ways to search my Git repo and all of them combined aren't as good as TortoiseHg's search bar with revsets.
Guitar ( https://soramimi.github.io/Guitar/ ) is the closest thing i've found to TortoiseHg for git, really promising but not yet fully baked - with a little help that could be a real TortoiseHg successor.
Everything other git GUI i've tried has some problems (git gui + gitk is reliable and featureful, but no grafting & has that Tk UI; git-cola is crashy and the DAG view isn't properly integrated; qgit and gitg can't push to remotes; sourcetree and gitkraken are nonfree; gitextensions and tortoisegit don't run on Linux).
One feature of git gui & gitk that TortoiseHg badly misses, though, is the option to stage lines for commit instead of just hunks.
Once you learn how to use `git rebase -i` it makes the above things trivial to do! I didn't know about it for a while, but that's my most often used command to fix up my commits.
I like git, I love the idea behind it, I appreciate the benefits it provides me, and I want to get better at it and I strive to adopt all the commonly-endorsed best practices.
However, with all the slightly different means to ultimately the same ends – merges, rebases, patches, fast-forwards, squashes, fixups, messages, descriptions, notes – it makes me wonder if git is not a Frankenstein's monster by now with too much bolted on to it, that needs to revised from the bottom up and consolidated into a more streamlined interface.
It's kinda telling when all the GUI tools for git do each task slightly differently, and none of the GUIs (that I've tried so far) let you do everything from one app, so I prefer to keep a couple different ones open at all times: https://i.imgur.com/itWE4Gs.png
I'm a pro with TortoiseHg so have all the concepts perfectly clear. Git is still hard with tons of command line syntax to look up and alias, no good GUIs, and poor error messages when things go wrong like Excel locking a file or not being able to pull. TortoiseHg lets me treat my commits like little bubbles on a graph and rearrange them at will. Git isn't trying not to be hard.
TortoiseGit is a GUI for Git that integrates with Explorer. You could indeed say it's geared toward people familiar with TortoiseSVN, though I'm not sure that paints an accurate picture of it. Unlike with SVN, I would argue you really do need to know Git on the command-line before you use TortoiseGit, but once you do, it makes life a hell of a lot easier than using Git on the command-line.
It's unclear to me what you're referring to, but the part I can answer is this:
> How is git hard?
IMHO because it is not intuitively obvious what it means for your "HEAD" to be "detached", or for you to "rebase" onto a "remote branch", or why "checking out" a file reverts your changes, or why "checking out" a branch suddenly clones its files, or why you'd "add" a missing file to remove it, or why you "committing" doesn't actually commit your changes to the central repo, etc.