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

[Junio C Hamano <gitster@pobox.com>]

Paolo Bonzini <bonzini@gnu.org> 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.