On 2016-04-24 11:46:53 +0200, Oswald Buddenhagen wrote: > On Sat, Apr 23, 2016 at 06:01:55PM -0700, Kevin J. McCarthy wrote: > > As I mentioned earlier, I was still iterating the patches and I posted > > them early just for comment. Pushing to a public repos would make it > > difficult to modify the patches afterwards. > > > the ability to easily discard history is possibly _the_ reason why git > is objectively superior to hg. of course, this upsets revision control > purists who want to never rewrite history, but that attitude plain > doesn't work in a project which has any reasonable standards for commit > atomicity and quality in general.
Rewriting the history is useful only when something really wrong occurred, such as something related to copyright, in order to prevent any user from downloading the contents in the future. But if this is just related to standard development, history should not be rewritten. If patches are not ready, they can go to a feature branch, where all the dirty work can be done until it's ready. Then the feature branch can be merged to the main development branch. With good branching mechanism, this should be seen as a single commit (if one wants to), thus hiding any temporary work. 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). -- Vincent Lefèvre <vinc...@vinc17.net> - Web: <https://www.vinc17.net/> 100% accessible validated (X)HTML - Blog: <https://www.vinc17.net/blog/> Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)
