Hi Ralf, On 2013-11-05, Ralf Hemmecke <hemme...@gmail.com> wrote: >> If you agree, then let me repeat my question: Why do some people believe >> that changing A-B-C into A-B-C-D is better than changing it into A-C'? >> Because in this case I really don't get the argument. > > Some people believe that changing history is bad and some don't. > > I would put it that way: it's a convention. > > ... > > Well, the question now is whether the Sage convention sees submissions > to TRAC more like the first view or more like "official" proposals whose > history should be kept. > > In fact, all Sage developers simply have to agree on one convention. I > don't think that one is particularly better than the other. > Personally, I somehow tend more to a convention which would forbid > history rewriting only for the master branch. And to all branches that > got a "positive review". All other stuff is work in progress and thus > people know that commits can be reordered or squashed together or even > disappear.
I would also agree with a convention that forbids rewriting the master branch history but allows rewriting trac ticket branch history, as long as the work has not stabilised. A branch that is not merged into master yet but has "positive review" could easily become "needs work", when the release manager notices unforseen problems or notices that the reviewer forgot one aspect. So, here we have a borderline case: If a formerly positively reviewed branch needs work, should it still be considered "history" (i.e., only new commits are allowed) or "work in progress, because it hasn't been merged into master yet"? If the commit history was like A: Basic implementation of a duck (quacks, swims) B: Added duckumentation C: Added feature "duck flies" D: Remove trailing whitespace E: Fix bad doc formatting then I believe to *some* extent it makes sense to re-group these commits (like: (A+C+D)-(B+E)), since, as we have seen, rebasing of dependent branches does not become more difficult. However, I think Dima's point is valid: It is bad to squash everything into one commit by default, because this means having the equivalent of a patch bomb, and loosing the opportunity to efficiently bisect. Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/groups/opt_out.
