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

Paolo Bonzini [off-list ref] writes:

Is your workflow to merge next to master after the release, or do you
cherry-pick the merges?

Usually 'next' will never rewind, and topics graduate by merging into
'master', either as a whole or in steps.

But I've kept 'next' and 'pu' deliberately more inclusive during this -rc
period, knowing that people by now would be very well aware that after the
final release of 1.6.4, 'next' will be discarded and rebuilt with a few
selected topics.  That means what currently is in 'next' can be safely
kicked back to 'pu' or discarded if it turns out to be necessary.

If you have doubts or regrets in the series currently in 'next', you can
even send in replacements if you want to (which is not how 'next' works
normally). I can revert the merge of the original series to 'next' and
merge the replacements during -rc period.  After 1.6.4, I can discard the
original series and keep only the updated series.

On the other hand, if you want to keep going incremental, which is how
'next' is supposed to work, that is perfectly Ok, too.  After 1.6.4, we
can decide what to do.

Do you plan to merge at least the first two patches of "git push
--current" (i.e. without the config option)?

I am not quite sure if that is a good approach.  If the design is in flux,
perhaps we should cook the code in 'pu' a bit longer until we know what
end user interface want?  The last thing I want to do is to give end users
a set of new command line options in 'master' (or even 'next'), only to
revoke them before the next release.

On 07/28/2009 10:01 AM, Junio C Hamano wrote:

The last thing I want to do is to give end users
a set of new command line options in 'master' (or even 'next'), only to
revoke them before the next release.

Agreed.  However, some people expressed appreciation for the new 
git-push command-line option independent of the push.tracking work, of 
which I'd guess they might not even be aware.  If you agree, I would 
leave in pu the third patch ("add remote.*.pushHeadOnly") while merging 
the first two to next.

Paolo