Hi! Meanwhile I got convinced that the change to git and the use of the new Sage development scripts is mostly a very good thing.
My advice would be: Look at what the development scripts do. Some of them answer questions you asked. I am only a bit sceptical in one aspect of git resp. the proposed git-based workflow: History. If I understand correctly, the proposed notion of history includes all aspects of "work in progress whose result will eventually be merged into Sage in *future*". Why does the notion of history matter? Well, it is also stated that changing the history is bad. Namely, if Alice works on branch A and Bob works on branch B *on top of* A, and Alice changes a commit message or folds commits *without* changing the resulting code (!), then from the perspective of git A changes essentially. Hence, Bob needs to rebase B because of (trivial) changes in A. On the other hand, this rebasing is really trivial, if I understand correctly: Bob just needs to do "git checkout B" (in order to change to his branch) and then "git merge A" (in order to merge all the changes that happened in A since Bob started work on B). Since Alice changed A in a way that did not change the code, this merge should work without problem. (Note: Sorry, I am rather new in git, it could be that the command to use in this case is "git rebase A B" and not "git merge A"; git rebase can do other nice things, such as take changes that happened between two commits and move it past other commits) In other words, the consequences of the weird notion of history can easily be fixed, probably in an automated way. On 2013-11-04, Anne Schilling <a...@math.ucdavis.edu> wrote: > - Should we use a fork for sage-combinat? Or branches for the various patches > or projects? I have not been an active user of the combinat queue, so take this as an outside view: My impression was that the workflow on the combinat queue was much different from the workflow in the rest of Sage. It happened repeatedly that I had problems reviewing patches from the queue because they have not been posted on trac, and if they have then soon the patch in the queue and on trac became out of sync. Hence, from the viewpoint of workflow, the combinat queue constituted a fork. I think it would be excellent if Sage workflow and sage-combinat workflow would coincide and allow for an easy transition. I guess one option would indeed be to simply say that sage-combinat is just formed by a collection of branches, in the same way as trac is formed by a collection of branches. I am not totally sure about the technical details, but if I am not mistaken, git is able to merge a branch from one repository into a branch from another repository. Hence, it would probably not matter whether sage-combinat is a sub-collection of the branches on trac, of if sage-combinat is a separate repository. That said, I guess reviewing of branches happens on trac. Hence, a branch that is supposed to be reviewed and be merged into the released version of Sage should appear in the trac repository. As I said, it *is* easily possible to take a branch from a separate sage-combinat repository, work on it in a local repository, and push it to a new branch in the trac repository. If I understand correctly, keeping the branch on sage-combinat and the corresponding branch on trac synced is as easy as keeping your local repository synced with the trac repository. Only it needs someone to regularly do so (I could imagine that this "someone" is in fact a script). > * If we don't fork, then is there some way we can tie all of the > combinat branches together? Specifically can we list all branches > which don't have ticket numbers. If I am not mistaken, git allows to use "tags" on branches. Hence, I guess it should be possible to implement this based on tags. Ask git experts. Of course, if sage-combinat would become a separate repository (such as sage-on-github and sage-on-trac are separate), the problem would not arise. > Is there an automatic way to remove a sage-combinat branch once > it has been merged into main sage? There is a sage development skript that removes all the branches from your local repository whose commits have already been merged into the master branch. So, there should be an automated way. > - How do we transform the queue into git branches, > how do we handle dependencies? How did Andrew Ohana and friends did the corresponding task for the Sage mercurial repository? Handling dependencies is trivial in git, if I understand correctly. > - Will it be easy to switch between branches (like experimental code, > branches to be reviewed etc)? Switching between branches is totally trivial. Just do "git checkout name-of-branch", and you are there. This even holds for a branch that belongs to a different remote repository. Again, just see what the Sage development scripts are doing. There is "sage --dev checkout --ticket=12345", which would automatically - create a branch u/YourTracName/ticket/12345 on the (remote) trac repository (if it does not exist already) - create a branch ticket/12345 on your local repository, if it does not exist already - I think it also checks whether the remote and the local branch are in sync, and lets you decide what to do if they aren't. Best regards, Simon -- You received this message because you are subscribed to the Google Groups "sage-combinat-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-combinat-devel+unsubscr...@googlegroups.com. To post to this group, send email to sage-combinat-devel@googlegroups.com. Visit this group at http://groups.google.com/group/sage-combinat-devel. For more options, visit https://groups.google.com/groups/opt_out.
