Hacker News Reader

Comment by elric | Hacker News Reader

Can someone elaborate on why this would be preferred over not using a global ~/.gitconfig? You can just use .git/config on a per-repo basis. Which is very convenient if you have multiple identities, and it prevents accidental commits using the wrong identity, because git refuses commits unless a user.email is configured.

View on HN

If you're routinely working on many repositories and cloning new ones, it's more convenient to know that if you clone it into this directory, it will be configured for work. I have used a similar setup for a while now, and it's perfect for me.

As soon as work or personal is more than one repo, that's annoying, and gets more annoying the more it is.

You could also say 'why does global git config exist at all, you can always just use .git/config on a per-repo basis'.

I'm pretty sure that it's a 10-20 minute job to write a Git subcommand wrapper that checks out a work vs personal project, and then symlinks the correct config file for the repo, if someone chose to go this route.

But... how is this easier than the solution proposed by OP?

It's not, but it's my response to the problem discussed by the parent comment.

Sure, but that's more like a solution for implementing something like in OP for if it didn't exist in git itself, not the 'why not just use per-repo config' that I responded to.

My thoughts as well. You can set some core commands to be different in your per-project git config which I find more flexible for SSH identities than using a the .ssh/host file.

https://git-scm.com/docs/git-config#Documentation/git-config...

    git config core.sshcommand "ssh -i /path/to/project/keyfile"

Reply on news.ycombinator.com