Re: linux-next workflow question for cifs

["J. Bruce Fields" <bfields-uC3wQj2KruNg9hUCZPvPmw@public.gmane.org>]

On Wed, May 09, 2012 at 08:19:05AM -0500, Steve French wrote:
> Trying to figure out the easiest way for the workflow for the new
> cifs-2.6.git linux-next branch for this scenario:
> 
> - push a series of patches to cifs-2.6.git linux-next
> - someone adds an ack to a patch in the middle, or even a coding
> change to a patch in the middle
> - how do I easiest make this change and repush (without constantly
> doing git push --force)

The other way to deal with it is:
	- if there's a coding change, add another patch on top.
	- if an ack or attribution got lost, apologize and try to
	  do better next time.

There are advantages to clean bisectable history, and there are also
advantages to real append-only history:
	- if someone's doing extra work on top of your branch, then
	  rebasing their stuff becomes easier.
	- if someone finds a bug in your branch and fixes it, then you
	  have a record of how that actually happened.

My personal balance is to have one append-only branch that's what gets
pulled into next, and then a different tree with any works in progress
that I can point someone to if necessary.

And I try not to push to the append-only branch until I'm pretty sure
there's been a chance for review, etc.

Not saying that's perfect--there are times when I would've liked to get
a patch some more testing in -next before really committing to it, and
at least one case when someone was annoyed not to be able to improve the
change log on something they submitted.

--b.