On Thursday, December 8, 2016 at 9:22:19 PM UTC, Volker Braun wrote: > > In the current release process I never rebase tickets, fyi. Generally, its > a bad idea to rebase published branches (unless you hate your > collaborators). >
on the other hand, reviewers won't hate you as much if you do rebase :-) I do not understand how you could build a new (beta)release without merging ticket into the current beta. (although probably the latter should not be called rebasing). > > The convoluted worktree process saves some recompilation because the > original worktree is never rewound to the original ticket state, only to > the updated (after merge with develop) state. > > Really, its a complicated workaround for a rare problem. The much more > straightforward (and more generally applicable) solution would be to store > time stamps and reset them on files unmodified relative to the last > checkpoint (i.e. the last time you ran "make", or at least before you > started wandering off into distant git branches) > just port Sage to use bazel as build system ;-) > > > > On Thursday, December 8, 2016 at 11:45:30 AM UTC+1, Dima Pasechnik wrote: >> >> I don't understand how the worktree procedure you describe reduces >> recompilation in merge/. (although combining this with the merge way I >> advocate looks like a good idea) >> >> I also do not see why the released tree should not be rebased. After all, >> it is merely cleaning after yourself; looks like a good idea. >> > -- You received this message because you are subscribed to the Google Groups "sage-support" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-support+unsubscr...@googlegroups.com. To post to this group, send email to sage-support@googlegroups.com. Visit this group at https://groups.google.com/group/sage-support. For more options, visit https://groups.google.com/d/optout.
