Better Git configuration • Hacker News Board

Re: Better Git configuration

#11

Post by pavel_lishin » Thu, Apr 06, 2017, 1:05 AM UTC

nichochar wrote: post #4

pavel_lishin wrote: post #3

Earlier quoted context omitted.

I have a similar one: lg2 = log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen%cn%Creset %Cblue(%cr)%Creset' --abbrev-commit --date=relative Shows dates at the end, in a relative format (2 days ago, 29 hours ago, etc) and the tags/branches before the commit message.

So do I! lg = log --color --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue) %Creset' --abbrev-commit

Date before author? Blasphemeeeeeeee†!

† http://oglaf.com/assorted-fruits/ (sfw)

Re: Better Git configuration

#12

Post by gsylvie » Thu, Apr 06, 2017, 1:36 AM UTC

This has saved me:

    git config  --global pull.ff only

I can always override an individual pull invocation with either "git pull --rebase" or "git pull --no-ff", making it a conscious choice when a fast-forward pull is not possible.

Re: Better Git configuration

#13

Post by hiphipjorge » Thu, Apr 06, 2017, 1:44 AM UTC

I'm going through my gitconfig and I'm realizing there's ALL THESE really nice shortcut I literally never use.

Re: Better Git configuration

#14

Post by llimllib » Thu, Apr 06, 2017, 2:15 AM UTC

Don't set fsckobjects=true. There are normal repositories that have broken trees which will not download if you have it set. Yes it is irritating and I would rather turn it on, but I had to turn it off after several repos failed for me.

Git doesn't check validity of commit hashes by default: https://groups.google.com/forum/#!topic/binary-transparency/...

Re: Better Git configuration

#15

Post by scottnonnenberg » Thu, Apr 06, 2017, 2:17 AM UTC

llimllib wrote: post #14

Don't set fsckobjects=true. There are normal repositories that have broken trees which will not download if you have it set. Yes it is irritating and I would rather turn it on, but I had to turn it off after several repos failed for me. Git doesn't check validity of commit hashes by default: https://groups.google.com/forum/#!topic/binary-transparency/...

Wouldn't it make sense to turn that off per-project when you encounter it?

Re: Better Git configuration

#16

Post by llimllib » Thu, Apr 06, 2017, 2:21 AM UTC

scottnonnenberg wrote: post #15

llimllib wrote: post #14

Don't set fsckobjects=true. There are normal repositories that have broken trees which will not download if you have it set. Yes it is irritating and I would rather turn it on, but I had to turn it off after several repos failed for me. Git doesn't check validity of commit hashes by default: https://groups.google.com/forum/#!topic/binary-transparency/...

Wouldn't it make sense to turn that off per-project when you encounter it?

That wasn't a hassle I was willing to deal with, I guess at least know that you're going to be doing that if you enable it.

IIRC, the jquery repo was an example of one with a bad object hash.

Re: Better Git configuration

#17

Post by peff » Thu, Apr 06, 2017, 2:52 AM UTC

llimllib wrote: post #14

Don't set fsckobjects=true. There are normal repositories that have broken trees which will not download if you have it set. Yes it is irritating and I would rather turn it on, but I had to turn it off after several repos failed for me. Git doesn't check validity of commit hashes by default: https://groups.google.com/forum/#!topic/binary-transparency/...

I'm not sure what you mean by this last sentence. But Git always computes the SHA1 of incoming objects (that's how it knows that the SHA1 is; the other side doesn't send it). And it likewise confirms that it has every object which is referenced by the newly fetched history.

The fsckObjects settings are entirely separate from the SHA. They are about syntactic and semantic rules in the objects themselves (e.g., well-formatted committer name/dates, tree filenames that don't contain "/", etc).

Re: Better Git configuration

#18

Post by [deleted] » Thu, Apr 06, 2017, 4:12 AM UTC

[deleted]

Re: Better Git configuration

#19

Post by r0muald » Thu, Apr 06, 2017, 4:49 AM UTC

> I will never accidentally create a merge commit

What is the big deal about creating a merge commit? It that because you only merge in `origin` (wherever that lives)?

Re: Better Git configuration

#20

Post by scottnonnenberg » Thu, Apr 06, 2017, 5:02 AM UTC

r0muald wrote: post #19

> I will never accidentally create a merge commit What is the big deal about creating a merge commit? It that because you only merge in `origin` (wherever that lives)?

Yep, as I mention down-thread, merges only happen at GitHub/GitLab/etc.

The two mistaken scenarios I run into the most are:

1. `git pull` when I'm not in the right branch, which will want to do a merge.

2. When I have commit access on the master branch, and I do a `git merge branch` when that branch hasn't been properly rebased on master. My preference is no merge commit here, so I like that Git can catch this.