On Mon, Apr 25, 2016 at 06:12:25PM +0200, Vincent Lefevre wrote: > On 2016-04-25 13:18:53 +0200, Oswald Buddenhagen wrote: > > On Mon, Apr 25, 2016 at 10:49:01AM +0200, Vincent Lefevre wrote: > > > Rewriting the history is useful only when [...] > > > > > the whole argumentation is besides the point, as we're talking about > > non-mainline branches. > > No, that's the point, as the intent of these patches is to be > eventually applied to the main branch. > that's painfully obvious, and still besides the point.
> > > Note that the work in the feature branch should really be kept. This > > > can be useful if a bug or some suspicious code is discovered later, > > > in order to know what led to this code or what could be wrong if it > > > is modified (e.g. simplified). > > > > > this has multiple implications: > > - you cannot push the fixed up patches for review into the same branch. > > ? > that's just stating the reality of forced pushes. you can either preserve the history, or have a cleaned up history. if you want both, you need to store it in different places (branches). > > - the wip branch will never be merged. and as it also won't be deleted, > > will will stay forever active in hg terms (though i guess you can > > still hide it). > > No, the intent is to merge the branch. When done, it will automatically > become inactive, but it is better to close it. If it is decided that the > merge should not be done, then the branch can just be closed. > and here it shows that you just missed the point. kevin wants to merge a clean history (as do i, for that matter). that's *by definition* not the working branch (unless he produces only perfect commits, which his (reasonable) assumption is he doesn't). that means that the working branch will be never merged. > > - the case that something suspicious is discovered later should never > > happen when the final review is thorough. of course that is wishful > > thinking, but so is being able to reconstruct the reasoning that lead > > to some weird code form a messy history. > > If this were done, bugs would never exist in the main branch. > uhm, yes, the second sentence says that much. but the point is that accurate history preservation doesn't alleviate the problem. and on the contrary, massaging the history increases quality by itself, because you thoroughly re-evaluate the atomicity of each change, and make commit messages which really describe the what and why. the gain of this is on average much higher than the mostly hypothetical gain of having an accurate (rather than actually helpful) history.
