On Mon, 22 Mar 2010 at 14:23:13 +0100, Tamas TEVESZ wrote: > On Mon, 22 Mar 2010, Carlos R. Mafra wrote: > > > On Mon, 22 Mar 2010 at 11:43:36 +0100, Tamas TEVESZ wrote: > > > Subject: [PATCH] Add the BSD version of GetCommandForPid() > > > > > > - fix up the linux version (terminate argv with a null ptr) > > > - add error handling to file ops in the linux version > > > > As it fixes linux.c which was added in "Introduce OS dependent stuff", > > I will squash this patch into that one, is that OK? > > whatever you see fit, though i'm not sure this doesn't count as > "falsifying history" :))
But #next is not supposed to have a history (it is supposed to be rebased). The purpose of #next is to try to avoid that mistakes or omissions propagate to the "stable" branch #master. Of course, that is only avoidable in a reasonable amount of time (~10 days at most), like in this case. But if I notice that some patch can be cleaner before it hits #master, I think it is worth to fix it up. You can do that in your own private branch with 'git rebase -i HEAD~5' to rebase the last five patches in your series and make it cleaner, such that the third patch does not contain fixes to the first, for example. But you are the author. So that is why I asked first (I still haven't pushed the rebased version, only now that I read your "whatever you see fit" answer). I will always ask the author if I can rebase his/her work. But that hasn't happened before. I am open to suggestions if people have a better workflow for #next --> #master. The idea is to always improve :-) -- To unsubscribe, send mail to [email protected].
