* pb/tracking (Thu Jul 16 16:26:15 2009 -0500) 7 commits
+ branch.c: if remote is not config'd for branch, don't try delete
push config
+ branch, checkout: introduce autosetuppush
+ move deletion of merge configuration to branch.c
+ remote: add per-remote autosetupmerge and autosetuprebase
configuration
+ introduce a struct tracking_config
+ branch: install_branch_config and struct tracking refactoring
+ config: allow false and true values for branch.autosetuprebase
After some discussion, I suspect we may want to rewind this out of 'next'
and start over with a fresh design.
Is your workflow to merge next to master after the release, or do you
cherry-pick the merges? If the latter, I propose that instead you
graduate to master only the first five patches (e.g. as
pb/per-remote-tracking).
I'd rather not see the series reverted until there is some code for the
fresh design. While I like it overall, I tried implementing it and I
could not really do it in a nice way (I could not even find a way to
nicely separate changes).
Do you plan to merge at least the first two patches of "git push
--current" (i.e. without the config option)? Do you want me to resend
them separately?
I will also separate from the --push series in two parts the patch that
reuse "git remote" code in "git clone", so that you can get the first
one as a cleanup and I can resubmit the rest later if the fresh design
does not work out. I'll submit it after 1.6.4.
Paolo
--
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