11–20 of 143 posts
Also of course I had to test the help commands!
git branch --help opens man
git branch -h throws those short commandline help summaries.
Interestingly, -h does not mention -h itself or --help, so the only way to know that --help exists, is someone else telling you, you will never find on your own.
Has anyone made an alternative interface for git that tidies this up without drastically changing how you use git? Or would this condemn someone's sanity to the graveyard?
http://mercurial.selenic.com/
But I still use git because I already grokked it before I learned hg.
Short of me downing distressing amounts of coffee, could someone explain these please for those of us still trying to grok git?
From "git --help config": "To avoid confusion and troubles with script usage, aliases that hide existing git commands are ignored."
> “Use git checkout.”
This is just a jab at how "checkout" does too many different things.
> “I have a historical record of a merge commit with two parents. How can I find out which branch each parent was originally made on?”
Git doesn't let you do this.
> “Surely some of these could be made more consistent, so as to be easier to remember in the heat of coding?”
Git commands can be inconsistent.
> “git -h branch“.
This command tells you nothing about "branch" (throws error), whereas "git --help branch" launches the browser at git-branch's manpage. This goes against what people usually expect (that "-h" is just shorthand for "--help".
I don't understood the suicidal git thing... Also of course I had to test the help commands! git branch --help opens man git branch -h throws those short commandline help summaries. Interestingly, -h does not mention -h itself or --help, so the only way to know that --help exists, is someone else telling you, you will never find on your own.
Has anyone made an alternative interface for git that tidies this up without drastically changing how you use git? Or would this condemn someone's sanity to the graveyard?
That said hg is the better choice for big software shops IMO, because of the lower training cost and because they probably won't use github anyway.
Thanks, Master Git!
Earlier quoted context omitted.
http://mercurial.selenic.com/
This may seem like a joke, but having used Hg a little bit, I do think it has a superior interface. The error messages are clear, the commands are intuitive. The command addremove is genius. But I still use git because I already grokked it before I learned hg.
The Long and the Short of It: -h is not a valid argument. Passing -h therefore results in providing usage information.
1. Silence: you can't alias built-in commands — for good reason. You don't change the defaults of commands, that's just going to cause problems with scripts. Why is it ignored silently? For starters because new git versions can add a command that would conflict with your config that came from an older version. You can trivially see that an alias is ignored by just adding ``--help`` to the command and it won't show you the alias.
2. One Thing Well: I fail to see the problem with that? All of these do the same thing. They check out a revision. With the exception of branch creation which is actually not a feature of `git checkout` but `git branch`. There is just a convenience operation on `git checkout` that also changes branches. The better question is why branches in mercurial are called bookmarks :P
3. Only the Gods: thankfully you don't know which branch something came from. Mercurial fucked me over more than once where I accidentally pulled a patch that came from a named branch that was conflicting with one I already had (you would not believe how many people name their branches "bugfix"). Mercurial's named branches are among the stupidest idea in software maintenance.
4. The Hobgoblin: these are all different commands. "How can I view a list of all tags": that's not what all tags is, that is "what's the list of tags I know locally". In mercurial you can't even figure that out properly because depending on the branch you're on you get different defined tags since tags are stored in the tree. Git's tag system is much superior to that.
"How can I view a list of all branches": that's a question you will never ask because it's the wrong question. A branch could show up multiple times. The correct question to ask is "How can I view a list of all local branches?" `git branch`, the second question is "how can I view a list of all remote branches?" And for that the answer is `git branch -r` or `git branch --remote` which makes a lot of sense in my mind.
"And how can I view the current branch": Same way you show all branches, just `git branch`. Shows you your current branch as well as all other branches and neatly colorizes it. `git rev-parse` is a command you really never have to use unless you script something.
Yeah, some could probably more consistent. The odd one out are `git submodule` and `git remote` which are sub commands instead of using parameters to remove/modify them. That being said, you rarely need to use those.
In direct comparison with hg, git's UI and functionality is a present from god. I'm pretty sure hg only has a better UI reputation because git's UI used to be pretty bad. Now however? Pretty sure it wins over hg hands down.
Has anyone made an alternative interface for git that tidies this up without drastically changing how you use git? Or would this condemn someone's sanity to the graveyard?
Mercurial is essentially git with a clean interface and drastically fewer workflows. If it weren't for github's existence I'd recommend hg to anyone. That said hg is the better choice for big software shops IMO, because of the lower training cost and because they probably won't use github anyway.