At $dayjob, our setup instructions for Git do say that everyone setting up a
new machine shall run "git config --global push.default tracking". This is
what suits our workflow where people work on a topic branch, which they will
push to and pull from our central repository (each topic branch is owned by
a team of one or more developers). By using "tracking", they can just do a
git push
and not have to worry about other half-finished or local changes "pollute"
the One True Central Repository<tm>. We have found that this configuration
makes it easier to explain the workflow, especially since it more or less
does make "push" the opposite of "pull" (both of them just updating one
"real" branch on either side).
We also have cases where we work on different repositories, with different
codebases; we have an upstream codebase that is merged into one or more
downstream codebases, and sometimes we have branches that are used with more
than one codebase (pull branch A from upstream repo, merge with downstream
repo and work with it there). Or we work on cross-codebase maintainence
(transplant fix on branch A from codebase B to codebase C). We have
installed hooks on our repositories that try to make sure history does
not get pushed to the wrong repository -- as could sometimes happen if
you had a branch checked out locally from the another codebase and forgot
to configure your push.default.
I have also personally found that this is the setting that I do feel most
comfortable with in more or less every other context where I work with Git,
so I do think this would be a fairly useful default value.
I know the policy in Git is to not allow the remote repository dictate
anything about the configuration in the local repository, but as an
alternative to changing the "push.default" value, perhaps we should allow
setting some configuration option on the remote repository that blocks it
from being the target of a "push.default = matching" push?
--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html