On 2013-11-03, Nils Bruin <nbr...@sfu.ca> wrote: > It seems that the current "branch" field in trac serves two purposes: > (a) It's a pointer to code-in-development that people who are > collaborating can refer to > (b) It serves as the official "to-be-merged" code once the ticket has a > positive review > > For purpose (a), having lots of little commits, trials, back-and-forths > etc. is great and natural: the barrier for people to make their > code-in-progress available to collaborators should be low. > > For purpose (b), however, it would be nicer if commits were in larger, > semantically significant blocks, so that if someone has to do some > archaeological excavations on a file, they find nice, well-defined > stratifications rather than a tangled mess.
IMHO getting "larger, semantically significant blocks" is error-prone and hard. It makes archaeology harder, not easier, in particular if it folds the story into one pathbomb-like commit. After all "git bisect" is specifically designed to narrow the problem down to the fateful commit, and getting a 100K commit (or even 10K one) in this way largely defeates the purpose of git. I'm not saying you must expose your own private history to the public, but once it hits the trac it is doing more harm than good to fold the patches. IMHO. Dima > > We had a similar situation with trac tickets and patches: As work on a > ticket progressed, one would often end up with a whole stack of patches. > These would usually be consolidated into one patch once the code stabilized. > > We could do this with branches too: first, we'd have a "draft" branch which > works as it does now. In the wrap-up of a ticket, one could make a fresh > branch, rooted at some well-defined point, where the new code is now merged > in some well-defined, folded commits. > > We wouldn't so much "rewrite" history: the draft branch would still exist. > We would write a "new" history, though: we would make a "to-be-merged" > branch which, while containing many of the same lines as the draft branch, > would technically be independent of it. Would this be acceptable practice > for people who prefer to "clean up" their commits before having them merged > in a sage release or would this wreak havoc with the process somehow? > > (I guess if other tickets decided to base themselves on the draft branch, > there might be some more merge-conflicts reported) > -- 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.
