On Saturday, December 9, 2017 at 5:10:51 AM UTC+9, Simon King wrote: > > Hi Travis, > > On 2017-12-07, Travis Scrimshaw <tsc...@ucdavis.edu <javascript:>> wrote: > > IMO, a better practice is to merge in old branches to a branch based off > > develop. If you want to rebase, then run rebase. That way you never have > > old cruft and have to watch Sage do a massive rebuild of things with > only > > changed timestamps. For example > > > > $ git checkout -b branch_name develop > > $ git merge branch_name > > $ git rebase develop > > I am not sure if I understand that procedure correctly. Where does the > old branch comes into play? Should the second line perhaps be > $ git merge old_branch > ? > > Why would you rebase if old_branch merges cleanly into develop? > > And even if you abstain from rebasing: Assume you have local_old_branch > that is identical with remote_old_branch in the branch field of Trac > ticket > 12345. The purpose is to somehow merge it with the latest develop, and > according to your suggestion one does > $ git checkout -b new_branch_name develop > $ git merge local_old_branch > and then push new_branch_name to #12345. Would that mean to force-push? Or > would a normal push suffice? >
I guess Travis' idea is the same with my own practice. Suppose the feature branch is "trac12345_dev". The procedure to "rebase" the feature branch to the latest "develop" without massive rebuild is: $ git branch -m trac12345_dev trac12345 $ git checkout -b trac12345_dev develop $ git merge trac12345 $ git branch -d trac12345 and then push "trac12345_dev" to trac. This is a normal push. -- 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 https://groups.google.com/group/sage-devel. For more options, visit https://groups.google.com/d/optout.
