On Sunday, November 3, 2013 6:51:48 PM UTC-8, P Purkayastha wrote: > If you check out the branch locally, you can run a > > git diff <some other reference point> <this branch head> > > to see the cumulative changes. >
That's good to know. However, when trying to figure out the history of code, it's usually not so much the question what has changed, but more when and (more importantly) why. "git blame" does that, and hopefully the log entry for the relevant commit tells you where to look further. If that commit reads "third iteration of typo correction and rollback of latest change" it's not so helpful and you need to go and look in the log for commits close by that are more instructive. Authors may also feel more comfortable to write a fresh history for the official commit because they don't want their silly little mistakes to be permanently recorded in sage's official history. Our old patch-based system naturally catered to that scenario, so I was wondering how git-based development could. To accommodate providing "uncluttered" histories I see 3 possibilities: 1) attach a freshly built branch to a ticket, after detaching the draft branch 2) open a fresh ticket and close the last one as won't fix. A fresh ticket can have a fresh branch for sure. 3) only attach a branch once code has stabilized and work with patches or a privately shared branch before. Of those options, 1) seems the easiest to me, so I was wondering if there are serious drawbacks to doing so. The other options would work too, but they have their own drawbacks. -- 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.
