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. -- To unsubscribe from this list: send the line "unsubscribe linux-cifs" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
