Christian Couder <chriscool@xxxxxxxxxxxxx> writes: >> Hmm, forgot to amend, or perhaps you sent out a wrong series? > > Your comments on the v2 series were in a message replying to patch 5/9, so I > amended only 5/9 and after it, because I thought that you had already > reviewed those before 5/9 and they were ok. Sorry, but in general I expect readers of this list to be intelligent enough and capable of extrapolating, so that I do not have to spell out the same issue over and over again ;-) > As you merged the series in pu, I thought that it was ok. Heh, being queued to 'pu' does not mean any more than just that we do not want to lose what the author spent efforts to produce, and we want to give reviewers easier access to the end result. If it is Ok, it would have been in 'next'. That's why topics initially queued in 'pu' sometimes move to 'stalled' state in "What's in" report and then eventually get ejected. The comment you added only says what it does, namely, that it does two different things, based on the allow_dirty global variable that is underdocumented. It does not explain _why_ it is a good thing, in what circumstance the caller would want "almost" semantics and in what other circumstance the caller would want a "real" hard reset. >> I am afraid that the whole cc/sequencer-rebase-i series needs a serious >> reroll before it gets near 'next'. > > Ok, I will reroll everything to try to improve commit messages. It would be a good idea; it may expose a wrong abstraction or an insufficient refactoring (e.g. adding yet another function to make a commit object that runs parallel to what we already have). Thanks. -- 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