Re: What's cooking in git.git (Jul 2009, #02; Sun, 26)

[Paolo Bonzini <bonzini@gnu.org>]

> * 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