Le samedi 17 mars, Jeroen Demeyer a écrit: > On 2012-03-16 14:01, R. Andrew Ohana wrote: > > For the same reason you started releasing 5.0 prealphas while > > finishing up 4.8. It makes sense to continue working on closing > > various fixes + improvements/features, but you shouldn't be doing > > this to code that is being prepped for release. > Except this was me privately working on stuff in my own sandbox. I > provided the prealphas because there was no real reason to keep them > private, but they were not official in any way. > > If you want this "prealpha" history to be published and you want a > clean git history, this is really going to make release management > MORE DIFFICULT which I don't like. So -1 from me. > > I like the fact that I can just put a patch in a non-official release, > test it, back it out if I don't like the patch (for whatever > reason). I can do this without needing to leave a clean history of > all this.
I suggest that you have a look at : http://live.gnome.org/Git/Developers A version management system makes things easier, not harder. Easier for developers, easier for maintainers, easier for translators, easier for release managers, easier for packagers. Yes, those are different roles. On a private branch, you can kick patches out ; you can even kick the whole branch out if you please. But as long as it's public, you only retract a patch with a new commit, stating why. I insist : this is only for the *public branch* case that the "Don't ever rewrite history" is important. Just this morning, I did the following on a project : git stash (put my local uncommitted changes away) git fetch upstream (get the new changes) git rebase upstream (rebase my private branch on what is now the tip) (there was no conflict so that went smooth) git stash pop (put my local uncommitted changes again) Does it look like the fact that upstream is a moving target is a problem for me? When I'm happy with my changes, the maintainer will have no trouble getting them in after review! In fact he will incorporate them in private and if the review is positive, just push them in master. No problem there either. Snark on #sagemath -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
