On Monday, November 4, 2013 10:33:24 AM UTC-8, David Roe wrote: > > I agree with Volker: any plan which involves rewriting the history of your > branch to make it "nicer" is a very bad idea. Once you push changes to > trac, you really should not go back and rewrite your commits. Even if you > decide you don't want some code that you introduced, you should introduce a > new commit that deletes the code rather than removing old commits and > force-pushing your branch. >
That may actually produce unnecessary merge problems as if your branch has to be merged with another branch that does change the code that you are now not really changing any more in the end. Smart merge tools can help a bit with that, but I suspect some pain remains. > This is a fundamental difference between using patches and using revision > control properly. You just can't do this kind of thing without causing > anyone else who's based work on your ticket a lot of pain. And you won't > even know who they are: they may not have pushed their work to a trac > ticket yet. > Right. This is why I included the example of abandoning a ticket and starting "fresh": if someone bases a branch A on another branch B that has not been merged into the main branch, they are taking a risk: the cause for branch B existing may disappear and as a result, all the changes introduced there will now be inherited by branch A: you're just ending up with more merging pain. I think there are two scenarios to optimize for: 1) avoid merging as much as possible. That means basing branches off each other as much as possible (and hence avoiding abandoning branches and starting new ones) 2) make merging easier. That means keeping branches shallow and try to let them not touch too many files. In that scenario, many branches do not arise as dependencies until they are merged in the main branch, so abandoning them wouldn't have consequences. Given that merging is inevitable in the sage development process, we have to do a bit of 2). I think in the language of Linus, the question really becomes: do we want trac to also provide hosting of "ticket-private" branches: the branch is publicly accessible, but is really meant to be private between the people working on the ticket, so if they decide to "clean" their history that's still fine. Given that trac previously served this purpose by being a patch repository and was used quite heavily in that function, I would think this might be desirable. If the distinction needs to be formal, I guess we might add a field to trac that marks the branch as such, although I'd think the better place would be the commit message, which could say something along the lines of "this would be a reasonable place to base another branch on". It's really the commit (and the history it depends on) that determines whether something makes a good base, not the branch as a whole. Also note that Linus expresses that it's important to show good judgement in where you base a new branch: A ticket that's still in flux is obviously a bad place. I'd hope that reasonable conventions for handling these issues would simply evolve if people are aware of what the ramifications of their actions are (and finding that out was my main reason for asking here). -- 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.
