Hi! On 2013-11-04, kcrisman <kcris...@gmail.com> wrote: > ------=_Part_109_13671842.1383581913134 > Content-Type: text/plain; charset=ISO-8859-1 > > I like this discussion, hopefully we'll find a good result. What if > multiple people are contributing to a ticket - how might that play in for > the various options?
I think this is orthogonal. If I understand correctly, collaboration is relatively easy in git. I push something to trac. You pull it, do changes, push back. Hence, we now have one commit from me and one commit from you on top of mine. Alternative scenario: We both work parallely. You have code, I have code. Then we need to figure out which of us will merge the code. This person will pull the branch of the other person, do "git merge", resolve conflicts, and push back. If I understand correctly, we only have a problem if there is a different ticket's branch that has merged an old version of our ticket's branch. The problem is that the other ticket's branch keeps track of its exact branch point. Hence, if we do some changes after the other ticket has branched off, then the other ticket is still based on a preliminary version of our ticket: It is needed to rebase the branch from the other ticket, and this even holds if the resulting code on our ticket did not change (say, if we just changed a commit message). Again if I understand correctly, the current discussion is: What freedom can we allow in our workflow concerning changing the commit history of a branch on trac so that we still avoid that the necessity to rebase other dependent ticket's branches becomes a mess? Let there be ticket A with attached branch ticket/A, and ticket B with attached branch ticket/B, such that ticket/B contains commits 1,2,3 from ticket/A, and such that A is mentioned in the "Dependencies" field of B. It is possible to change ticket/A in such a way that commit 2 vanishes and another commit is added, so that ticket/A now provides commits 1,3',4. It could actually be that the resulting code did not changes. But in any case, ticket/B only knows about 1,2,3, and must now be made aware to drop 2, rebase 3 (becoming 3') and add 4: It must be rebased, and it needs a (new) review. I think it would be nice (take this as a feature request) if the participants of B would get an automated mail, stating that the branch attached to the dependency A has changed and hence it is necessary to rebase ticket/B with respect to the new state of ticket/A. What would be even nicer: Have a script that tests whether rebasing ticket/B can be done automatically. If this does not change the resulting code (or at most removes trailing whitespace), then I believe it is not even needed to inform the participants of B of the automatic rebasing. In all other cases, B should be changed from "positive review" to "needs review" (if applicable), and the participants of B should be informed that an automated rebasing/merging has taken place and that they need to look at the resulting code, because it can be that seemingly harmless changes on A are breaking B. The ultimate niceness would be: *Automatically* detect that B depends on A (i.e., assume that the author of B was basing ticket/B on ticket/A, but forgot to add A to the list of dependencies for B). I don't know if this would be possible. Also it would be nice if adding a dependency C to ticket B would automatically trigger a test whether the commits of the branch ticket/C are contained in the branch ticket/B. Question to trac experts and the authors of the development scripts: Which of these features (if we want to have them) can be implemented directly on trac, and which needed to be implemented in the scripts? Best regards, Simon -- 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.
