In the current release process I never rebase tickets, fyi. Generally, its a bad idea to rebase published branches (unless you hate your collaborators).
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) 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.
