Live data from Hacker News

Git log – The good parts

zwischenzugs.com

71–80 of 86 posts

Re: Git log – The good parts

#71

I like Tortoisegit. No commands to memorize and the entire product can be worked via the keyboard. https://i.stack.imgur.com/Xc9vb.png

I like GitExtensions. I cringe when i see people manually entering hashes when they want to do stuff such as simple diffs. It's busy work. Hammering away on the keyboard but actually accomplishing so little.

Thanks! I would really like something that integrates with Finder on the Mac and I see that it is cross platform, so I will have to try that out.

Re: Git log – The good parts

#73
post #70

I can't imagine developing or sorting out repo issues without a full tree-view of the last hundred commits showing branches, merges, SHAs, tags, authors, commit messages, etc. But it's just another tab in my GUI app (sourcetree), not a complicated set of flags that needs a blog post to explain. The use of git as a command-line-only tool is completely strange and alien to me. It works so well as a full-fledged graphic…

I work for a small game studio with a couple of programmers and artists, and we use git for source control (which works for us, our binary assets aren't big enough to make git too much trouble). Most of our team is non-programmers, and I've become the "go-to git guy" at my company. All the others use Sourcetree, so I have lots of experience with it, and I can tell you: I would never pick Sourcetree over command line git.

Sourcetree is an okay piece of software, but command-line git is so much faster to use. Even doing simple things like adding, committing, pulling and pushing takes half the time on the command line for me compared to Sourcetree. For this particular logging issue, you don't actually type up all those flags every time, you make an alias and it takes no time at all. If you're trying to do anything marginally complicated (say, bisecting or using the reflog), Sourcetree is all but useless.

Command line git is harder to learn and harder to use in the beginning (and virtually impossible to use unless you're comfortable with the terminal), but if you're using the terminal a significant amount anyway, it's just a better solution.

I will say: the last couple of weeks, I've been trying to get into the habit of using magit, and it's the only git client I've used that can compete with the command line. Sourcetree certainly can't, not for me.

Re: Git log – The good parts

#74
post #5

In case anyone finds these useful, here are some git log aliases I use everyday. FORMAT="%C(auto)%h %C(magenta)%ad %C(cyan)%an%C(auto)%d %s" PRETTY="--pretty=format:'$FORMAT' --date=short" git config --global alias.lga "log --graph --all $PRETTY" git config --global alias.lg "log --graph $PRETTY" git config --global alias.la "log --all $PRETTY" git config --global alias.ll "log $PRETTY" git config --global alias.lf "…

Git has a built-in way of achieving what you've done with the $FORMAT and $PRETTY variables; look at @twic's comment on this story.

Re: Git log – The good parts

#75
post #73
post #70

I can't imagine developing or sorting out repo issues without a full tree-view of the last hundred commits showing branches, merges, SHAs, tags, authors, commit messages, etc. But it's just another tab in my GUI app (sourcetree), not a complicated set of flags that needs a blog post to explain. The use of git as a command-line-only tool is completely strange and alien to me. It works so well as a full-fledged graphic…

I work for a small game studio with a couple of programmers and artists, and we use git for source control (which works for us, our binary assets aren't big enough to make git too much trouble). Most of our team is non-programmers, and I've become the "go-to git guy" at my company. All the others use Sourcetree, so I have lots of experience with it, and I can tell you: I would never pick Sourcetree over command line…

My experience is coworker developers struggling-at-best to use git from the command line in the simple case, and having almost no visibility into the tree/history of the repository for use in debugging. Or being unaware of useful git features such as line-by-line selective staging (that I consider absolutely essential for dev teams).

I don't particularly like SourceTree, and it is slow and annoying in certain ways. But I'm extremely productive with it as a poweruser, and it's much better for beginners as well.

Re: Git log – The good parts

#76
I can't use git without "git gl":

    [alias]
    gl = log --pretty=format:\"%x1b[33m%h%x1b[36m%d %Cgreen%ae %Cred%ad%Creset%n%s%n\" --graph --date=local
Try this in your .gitconfig. I highly recommend it.

Re: Git log – The good parts

#77

Earlier quoted context omitted.

lol, I named mine 'git l' because I type it far too often.

I use two-letter bash aliases for all my most commonly used git commands. git status git diff git diff --cached git add -A git commit -m Hello git push Is instead just st dp di aa cm Hello pu Additionally I also have le For git shortlog -s -e which I don’t use very often but often enough that having an alias for it still makes sense

I edited my inputrc to do a prefix search. So I just ‘git x’ where x is some letter, pressing up usually finds me what I want.

It still surprises me we don’t have good bash autocomplete.

Not sure how hard it is to create a shell but i’d do it in a heartbeat.

Re: Git log – The good parts

#78
post #6

For those increasingly rare times I'm not using Magit[0], I have a "git lg" alias I found once through HN[1]: git config --global alias.lg "log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue) %Creset' --abbrev-commit" I strongly recommend both. -- [0] - https://magit.vc/ [1] - https://coderwall.com/p/euwpig/a-better-git-log

Have you tried other git UIs (IDE or not) ? I wonder if there's one that is as good as magit (my opinion is no, but that's why I ask)

gitk 7-8 years ago, Github desktop app few years later. I used version control features in Eclipse and IntelliJ for SVN, but I believe the same interface maps to Git as well.

None of them even compare with Magit. They offer a small subset of Git features - unlike Magit, which gives you almost all of them, + some higher level abstractions (like "merge into"), and you're always one ! ! press away from entering a manual command. Also, the other interfaces I've used were mostly mouse based, whereas Magit just flows. Feels order of magnitude more efficient than anything else.

Re: Git log – The good parts

#79

Earlier quoted context omitted.

Have you tried other git UIs (IDE or not) ? I wonder if there's one that is as good as magit (my opinion is no, but that's why I ask)

gitk 7-8 years ago, Github desktop app few years later. I used version control features in Eclipse and IntelliJ for SVN, but I believe the same interface maps to Git as well. None of them even compare with Magit. They offer a small subset of Git features - unlike Magit, which gives you almost all of them, + some higher level abstractions (like "merge into"), and you're always one ! ! press away from entering a manual…

> you're always one ! ! press away from entering a manual command

Huh, I didn't know this. I'll probably live in Magit from now on.

Re: Git log – The good parts

#80
post #79

Earlier quoted context omitted.

gitk 7-8 years ago, Github desktop app few years later. I used version control features in Eclipse and IntelliJ for SVN, but I believe the same interface maps to Git as well. None of them even compare with Magit. They offer a small subset of Git features - unlike Magit, which gives you almost all of them, + some higher level abstractions (like "merge into"), and you're always one ! ! press away from entering a manual…

> you're always one ! ! press away from entering a manual command Huh, I didn't know this. I'll probably live in Magit from now on.

Also useful: any time you find yourself wondering what did Magit just do, press $ to display raw output from git commands (lists the commands issued and their return codes, TAB expands them to full output).
Post reply on HN