Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

git config -- where do best practices live? #130

Closed
cjcjameson opened this issue Jul 19, 2017 · 2 comments
Closed

git config -- where do best practices live? #130

cjcjameson opened this issue Jul 19, 2017 · 2 comments

Comments

@cjcjameson
Copy link
Contributor

cjcjameson commented Jul 19, 2017

I've got a number of "best practices" around git config -- trying to figure out where they should go. What do people think? Do individual teams end up layering on custom git configs onto workstations?

  1. let's say you've set up a new remote, pointing to your pair's fork. You do git fetch <pair> to download the remote references. Then you want to, all in one fell swoop:
    • Checkout their branch
    • Start a local branch with the same branch name
    • Have your local branch automatically be tracking the upstream reference

I'm used to being able to simply git checkout <new_branch_name> -- no flags, no remote name needed. Git recognizes that it's not a valid local ref, searches the list of remote refs, figures out what I'm trying to do, and does all the above for me.

I think the following post's settings are a big part of what's necessary. But is there other stuff needed for this to just magically work?
https://stackoverflow.com/questions/5480069/autosetuprebase-vs-autosetupmerge

  1. let's say you work across various repos, some public, some private. You're rotating among workstations regularly, so you keep your ssh key on a USB stick, and set it on your machine daily.

http://engineering.pivotal.io/post/git-push-instead-of/ describes the optimal way to do it.

It uses the following global git config to make the magic happen:

[url "[email protected]:"]
  pushInsteadOf = https://github.com/
  pushInsteadOf = git://github.com/
  1. use of a global gitignore file. Here's how I configure it:
[core]
	excludesfile = /Users/cjcj/.gitignore_global

and a typical excludes file might look like:

*.iml
*.swp
.DS_Store
.idea
.python-version
.ropeproject
cmakelists.txt
greenplum-db-devel
greenplum-dev
pylama.ini
pylama.ini.bak

great for types of files that are idiosyncratic to workstations or IDEs that you like but are too specific to your particular dev flow for an open source community to accept them into their .gitignore

@nertzy
Copy link
Contributor

nertzy commented Jul 19, 2017

You could set these via git config --global and add them to the end of this file: https://github.com/pivotal/workstation-setup/blob/master/scripts/git.sh

And you could copy the .gitignore_global into place there as well.

@cjcjameson
Copy link
Contributor Author

Looking back at this, I think we can close the issue.

number 1 is not an issue after all. Default git behavior on a new machine.
number 2 is addressed by #183
number 3 is vague; open to someone else suggesting an excludesfile to the global config in the future but probably hard to find consensus.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants