On 09/26/2014 06:31 PM, Junio C Hamano wrote: > Michael Haggerty <mhagger@xxxxxxxxxxxx> writes: > >> * Rebase to current master. > > When you say this, could you be a bit more descriptive? Has the > series updated to use something new that appeared on 'master' since > the last series was posted and needed to be rebased? Or did you > just made sure that the series applied on top of the current master > still works, even though you have been running "rebase -i" on the > same fork point since the previous round? > > If the former, naming what it now uses i.e. "rebased to current > master, to redo PATCH x,y,z using the new X recently graduated" > would be helpful. > > If the latter, well, not rebasing is preferrable if the changes are > still viable on the previous fork point, to be absolutely honest. I have always routinely rebased my series to the current master each time I reroll them. I thought that was helpful. Thanks for the info that you prefer that I not do it. In the future I will only rebase to master if I see that there would be nontrivial conflicts or if I would like to take advantage of something that has graduated. I've always tried to mention when the rebases were nontrivial. In this case it was unproblematic. As an aside, I've always found it wishy-washy to talk about "current master" and "fork points" and stuff when (AFAIK) format-patch-generated emails don't mention the fork point. So unless my cover letter specifies the fork point as an unambiguous commit name, there is no basis *anyway* to expect that you will apply the patch series in the same context that I developed it. Another victim of the format-patch information shredder :-( Cheers, Michael -- Michael Haggerty mhagger@xxxxxxxxxxxx -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html