Live data from Hacker News

Git tips from the trenches

ochronus.com

31–40 of 47 posts

Re: Git tips from the trenches

#31

Earlier quoted context omitted.

`git grep` is such a weird command: it defaults to being pointlessly redundant with `grep` (with a few default ignores). Contrast with hg grep, which defaults to searching the whole history (although it stops after finding the historical first match, `—all` will display all matches).

"git grep" is a lot faster than grep in a large codebase. One obvious reason is that "git grep" ignores non-checked-in files in the project directory. But I also notice a speed difference even when the project directory is clean.

That's because git-grep doesn't need to bother to go through the filesystem for the on-disk files. It greps directly from the object storage instead.

And AFAIK it can run the grep in parallel. Practically any non-archaic machine has multiple cores now, so git-grep can easily be faster than regular grep from command line.

Re: Git tips from the trenches

#32
"After a few years with git everyone has his own bag o' tricks..."

So "everyone" (every developer, ever) is a "he"? I'm not here to bash the author, but remarks like this (whether or not they're intentional) really don't help make the field of software engineering, which is already quite the boy's club, any more accessible to non-male people.

Re: Git tips from the trenches

#33

My git shortcuts (in my bash_profile): alias g='git' alias pull='git pull origin master' alias push='git push origin master' alias gc='git commit -m $1' alias ga='git add -A' # Adds all and commits (gg 'Commit message') function gg () { git add -A; git commit -m "$1"; git push origin master; } alias gs='git status' alias gd='git diff --color' alias gdc='git diff --cached' alias gstat='git diff --stat'

I don't like the idea of your gg function, but I add files to the index using git add -p exclusively since it gives me a chance to review my changes as I'm adding them, as well as let's me ensure I split up different logical changes into separate commits. Likewise, I think git commit -m encourages lazy git commit messages (see: http://tbaggery.com/2008/04/19/a-note-about-git-commit-messa...)

Mostly because this helps me keep a clean history, which is something I value highly.

Re: Git tips from the trenches

#34
post #32

"After a few years with git everyone has his own bag o' tricks..." So "everyone" (every developer, ever) is a "he"? I'm not here to bash the author, but remarks like this (whether or not they're intentional) really don't help make the field of software engineering, which is already quite the boy's club, any more accessible to non-male people.

No post body was provided.

Re: Git tips from the trenches

#35
post #26

One that I use the whole time is: git status --untracked=no This shows only files that are tracked. I tend to do a lot of work which leaves files that I don't want to check in lying around in my git repo, this eliminates these and lets me see exactly what I have been working on. The slight caveat to this is when you are working on a new file that you have not yet checked in ever. This goes hand in hand with: git add…

Is there a reason for not adding such files to your .gitignore?

I'm a neat-freak when it comes to file placement, and have a ~/tmp directory specifically for dropping one-off files without cluttering up repos and such.

Are the things your repo isn't tracking mostly temporary/build files? or things that are going to be checked in eventually?

Re: Git tips from the trenches

#36

My personal favorites: > git-rerere will prevent you from getting stuck resolving the same merge conflicts repeatedly, by remembering how you resolved them the last time. Also, instead of passing any arguments to "git-log", I usually just use "tig", an ncurses display of the commits: https://blogs.atlassian.com/2013/05/git-tig/ Finally, when I was first taught Git, I was told that I should never need to comment out c…

> Also, instead of passing any arguments to "git-log", I usually just use "tig", an ncurses display of the commits: https://blogs.atlassian.com/2013/05/git-tig/

+1 for tig. Definitely my favourite git interface. Its status view is also very handy for viewing diffs, and adding/removing files to the index, as well as reverting changes.

Also, it now has mouse support. I know this, cos I added it :)

Re: Git tips from the trenches

#37
post #6

I liked this one: git blame -w Ignore the whitespace if a block was [un]indented, attribute to original author instead of person re-indenting due to control structure change around block.

The truth is that command-line blame is a pain in the ass. Blame is great for finding out where a piece of code comes from, but (especially on big projects with many contributors) there's a lot of small churn with code being moved around, slightly altered, etc… CLI blame requires an extensive danse of "blame to find out last change before $(rev:tip)" "log with patch to find out if it's the change I'm looking for" "ge…

`git gui blame` is actually pretty great. You can click around to parent commits and everything.

Re: Git tips from the trenches

#38
post #32

"After a few years with git everyone has his own bag o' tricks..." So "everyone" (every developer, ever) is a "he"? I'm not here to bash the author, but remarks like this (whether or not they're intentional) really don't help make the field of software engineering, which is already quite the boy's club, any more accessible to non-male people.

English is not his first language. No need to write a novel about it.

Re: Git tips from the trenches

#39

My all-time favorite git tip is adding the '--graph' flag to git log, which will show the log with a branch graph. But while you're at it, might as well go all the way: git log --graph --abbrev-commit --decorate --date=relative --format=format:'%C(bold blue)%h%C(reset) - %C(bold green)(%ar)%C(reset) %C(white)%s%C(reset) %C(dim white)- %an%C(reset)%C(bold yellow)%d%C(reset)' --all (Kudos to the unremembered internet p…

I think we have benefitted from the same stackoverflow thread =) http://stackoverflow.com/questions/1057564/pretty-git-branch...

Re: Git tips from the trenches

#40
post #32

"After a few years with git everyone has his own bag o' tricks..." So "everyone" (every developer, ever) is a "he"? I'm not here to bash the author, but remarks like this (whether or not they're intentional) really don't help make the field of software engineering, which is already quite the boy's club, any more accessible to non-male people.

English is not his first language. No need to write a novel about it.

So two thoughtful sentences now count as a novel? I should really look into getting published.
Post reply on HN