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

From: Paolo Bonzini <bonzini@gnu.org>
Date: Jul 28, 2009, 07:27 UTC
Message-ID: <4A6EA86A.5010705@gnu.org>
In-Reply-To: <7viqhfrfu5.fsf@alter.siamese.dyndns.org>

Show 13 quoted lines

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