Hacker News Reader

Comment by panpanna | Hacker News Reader

Try also "tig" which is something in between git --log and gitk.

Also, I firmly believe that git is very simple if you use it right. I'd you are deep in the manual with exotic commands and flags it's most likely your own fault.

Edit: forgot to add that saying git is not complicated always gets heavily downvoted on HN. So goodbye digital karma...

View on HN

Git's data model might be simple, but the commands sure aren't. Compared to Mercurial the UI is a mess, although better than it used to be, which isn't surprising since each command initially kind of evolved as a separate program rather than being designed as part of a coherent user experience like Mercurial.

I find that Git can usually do everything Mercurial can, but it does involve those "exotic commands and flags". For example, the equivalent to

  hg id -i

is apparently

  git describe --abbrev=12 --dirty=+ --always

which is not exactly obvious, not even if you read the manual. Stack Overflow also suggests alternatives[1] using "git log", "git status" and "git rev-parse" which do similar but slightly different things and accept similar but slightly different options.

What about listing all filenames from all commits – "hg manifest --all"? I'm sure it can be done, but I'm equally sure it involves exotic flags.

[1] https://stackoverflow.com/questions/14333388/git-equivalent-...

I think you just proved my point.

Which point is that? That git is very simple or that expecting an equivalent of "hg id" is unreasonable?

That's kind of a misleading comparison. It takes that many characters to exactly reproduce the "hg id -i" behavior because hg chose a certain set of defaults that git didn't happen to choose. What if as an hg user I want the first 16 chars of the commit ID and don't want the "dirty +"? The hg command quickly starts to look uglier.

If you just want the current commit ID in git it's just "git rev-parse HEAD". Which is still longer and uglier than "hg id -i", yeah, but it's a fairer comparison.

The fair comparison is to just "git describe", no?

TBH I'm not sure I'd ever heard of "describe" -- I'd always used rev-parse to get a commit ID. But now that I'm trying it, it gives me a branch/tag name rather than a commit ID (either bare "git describe" or with the other arguments mentioned above). So...not really sure?

It depends on what exactly you're looking for, I guess. There's a million ways to parse HEAD into a hash, if that's what you're after.

True. My point is that Mercurial has a more coherent set of commands that usually, in my experience, give you an obvious way to do obvious things.

Git has (although it's gotten better!) functionality spread haphazardly across different commands, and many commands can perform several seemingly unrelated tasks depending on the flags. There are lots of command to give you the hash of current commit, all with different combinations of bonus features, and in this particular case we use describe (which really seems to be for finding tags reachable from particular commits) because it happens to support the right combination of features.

(Perhaps I should mention that I'm currently migrating to Git. Git is fine. Many things are better than in Mercurial, just not the UI.)

It is simple and powerfull but not intuitive. I work a lot with biologist and I explain it as a lab journal: for a lab journal there are, depending on your company, many strict rules to follow, to keep it "valid". For example, changes need a date stamp, people need to sign off on your journal every 3 months. You need to number the pages and keep an index to show it has not been tampered with, etc.

Like many things in the computer world one starts out feeling that something is overly complex and then slowly one realizes that one would have designed a system just like it is now, given the opportunity. Realizing this has made me stop judging new tech until I try it for some time. Also, when many people use something and I find it to be overly complex, I try to reserve judgement and spends some hours at least to really try something. Although this does require some problem to be solved (a concrete target), at least for me.

I think it is simple until you make a mistake.

I am a very basic user of git, with one or two branches and straight merges.

Until I commit the wrong thing, or mess with the merge and end up with a set of files I did not create (.orig IIRC).

So git is simple but not simply forgiving (it may be forgiving, but you need to know more). https://ohshitgit.com/ helped me several times.

The best way I found to learn git is to read the first 3 chapters of Pro Git. Yes it's a pain, yes you're going to have to sit through the "distributed source control" speech again, but the enlightenment of realising why it works like it does is great.

When you realise it's nothing more than commits and a bunch of special labels it starts to make sense.

EDIT: Meant to add that sites like ohshitgit might help in a crisis but you're only a few hours reading off working out WHY those things work.

Reply on news.ycombinator.com