Hacker News Reader

Comment by cyborgx7 | Hacker News Reader

Here is my personal recommendation for getting more comfortable with git. Use "git status" a lot. Everytime you do something in git, and before you do something, do a "git status" and see what you change with your commands. And what you didn't change.

Also "git log".

View on HN

`git log` on its own (with no flags) isn't that useful, as it's missing a lot of important information. I prefer `git config --global alias.lg "log --color --graph --oneline --decorate"`. Then you can just type `git lg` and get a much more useful overview of the state of your current branch.

Git in many occasions (including when using git log) feels like the designer just threw their hands up and said:

"F*ck this shit, make your own UI on top if you want to use this tool!"

I don't think Torvalds has a proper excuse for the pain and suffering he's inflicted on millions of developers worldwide :(

(To the people going: "Oh, it's Open Source!". Sure, so are Mercurial, Fossil, etc.)

This makes a lot more sense when you realise that Linus thought he was building a low level tool that people would build a UI on top of. The 'original' git command line was more a proof of concept and engineering tool than something aimed at actual use.

Right, doing a search through the git mailing list for the use of the word "porcelain" is fascinating. It's unfortunate some of those "porcelain" projects never finished.

... because none of the power users used them.

Heh. I think Linux on desktop it is like that, at least a bit; frequently, by the time someone could write a friendly GUI (or friendly CLI for that matter), they have little use for it.

That's a disturbingly insightful parable for everything from startups to linux/FOSS contributions.

I don't think it was ever really intended for worldwide use by Linus, it was intended to exactly replicate his workflow and his alone. The real responsible party is github; I'm not sure how they came to dominate?

By being much, much, much better than the competition at the time (sourceforge) - github was faster, without ads, used superior vcs. Github also had Octopuss/Octocat as a logo :-) .

Sure, but why github rather than mercurialhub etc? The website has great usability but the git CLI does not. Maybe the github gui was also critical.

Yes, the gui was good (and it still is, or may be I am too familiar with it at this point, I do not know).

Another factor is that git was always FAST, and the most common operations (init, log, status, commit, checkout, push, pull) are not that complicated as people make them to be, so you can very easily start to use it for new local projects, and continue without installing additional plugins, unlike mercurial ... And at some point, when you wanted a colaboration hub or just a public remote repo, you just pushed your code to github.

> Git [...] feels like the designer [...] said "F*ck this shit, make your own UI on top if you want to use this tool!"

Actually this is exactly what happened back then, which is why many people used https://en.wikipedia.org/wiki/Cogito_(software) as a frontend to git in the early days. That said, I personally find current git UX absolutely fine and I can't imagine being effective without having all those commands like git reset --whatever -p and git rebase --interactive.

What an absurd statement: "Torvalds has a proper excuse for the pain and suffering he's inflicted on millions of developers worldwide :(" !

Who are you exactly to judge people like that, oh failed incarnation of a tibetan Lama ???

He does not need an excuse to make a tool that has proven very useful to many (including me). In fact, I am grateful, that he chose to make it and publish it.

It definitely feels like it was written by someone used to writing an ABI or library rather than a set of command line tools.

Certain tools are organized by what code goes together rather than by what user functions make sense to go together. It's part of what makes it confusing.

    git config --global alias.lg "log --color --graph --oneline --decorate"

for easy copy-pasting. HN doesn't support backticks or triple backticks like a lot of markdown parsers. To get fixed-width fonts, you have to insert 4 paces at the beginning of the 'code' block.

Two spaces (unlike Markdown).

Of course four will work, it just adds more indentation.

In some mobile browsers, doing this will result in the fixed-width font line getting cut off when viewing the resulting post.

I got into the habit of teaching people `gitk`. It's not the prettiest tool, but it's included with most distributions of git, defaults to a decorated color graph log, and thus avoids the "copy paste this weird config line" step on other people's machines.

I have a soft spot for Tk interfaces. I hope they become cool again (or, I mean, for the first time).

+1 these, I wish they were default for git. Much better both for beginners and experienced users.

I just use a GUI for that. I don't like using applications like Sourcetree for any actions, but they really are superior for visualisation of the commit tree, diffs between non-adjacent commits or between branches, etc.

I'd recommend Git Extensions, still, as a good compromise between porcelain and plumbing. The most useful commands are all at your fingertips, with deeper ones available if necessary. Visualization is best I've seen - clean graph display, easy to read, and _doesn't lie in complex cases like SourceTree does._

SourceTree tends to treat commits with multiple ancestry in a very weird way that has led to difficulty on multiple occasions, where people think changes 'went missing' because SourceTree decided the other ancestor wasn't important enough to show.

I don't use Windows. Seems a little clunky to get it to work on Linux, even more so on the Mac. Haven't had any multiple-ancestry issues with SourceTree - perhaps resolved in an update since you encountered it?

Zsh users can use glgga to get a nice full detailed graph log as well. It's not as concise as the custom config, but I use it quite often.

Classic git CLI. The option everyone wants is behind 5 optional flags.

`git log -p` is my favorite obscure git command. Shows you commit by commit changes. If you specify a path, it limits to only those files. If you do a single file you can do `git log -p --follow <file_path>` and it will track the file across moves and renames.

Also `git whatchanged` is a super helpful command to see just the list of files that changed in each commit

`git add -p` is also very, very useful. I use it all the time, to the point that I've aliased it to `a`.

If you're interested, here's my .gitconfig, including all of my aliases: https://gitlab.com/lyndsysimon/dotfiles/blob/master/git/gitc...

Completely agree. I think a lot of people would enjoy git more if they made better use of the `-p` options.

Do you know about `git commit -p`? You might like it even more than `git add -p`.

I didn't know "whatchanged", thanks! However, look at the description: https://git-scm.com/docs/git-whatchanged

Yea. It's technically deprecated, but it is also super useful so I don't see any reason not to use it.

Yikes, do people consider `git log -p` obscure? I can't live without it!

here's my git log alias: alias gl='git log --date=local --pretty=format:"%C(124)%ad %C(24)%h %C(34)%an %C(252)%s%C(178)%d" --stat -p'

has nice color coding around the date, person committing, commit hash, and message.

Better yet, alias "git status" and "git log" so you'll be more inclined to use them frequently.

Reply on news.ycombinator.com