From: William S F. <ws...@fu...> - 2013-01-03 20:14:43
|
With the new year we have switched SWIG development to a new development model - Git on Github. The old Subversion history (including the even older CVS history) has been migrated and is now viewable in Github - https://github.com/swig/swig . If you have used SWIG we would really appreciate improvements you have made for incorporation into themainlineSWIG releases. So, feel free to use Github to fork and send your pull requests or patches. Improvements to the documentation are also very welcome - the docs can be found at https://github.com/swig/swig/tree/master/Doc/Manual . Information for getting going is on the SWIG website: http://www.swig.org/svn.html . We have also turned on the new SourceForge Allura system which is much slicker than the old SourceForge for submitting bugs/patches - https://sourceforge.net/projects/swig/ . Happy new year! William |
From: Olly B. <ol...@su...> - 2013-01-04 05:36:05
|
William S Fulton writes: > With the new year we have switched SWIG development to a new development > model - Git on Github. So is the plan that everyone now submits pull requests which you process, or are you intending to let other developers push to the swig repo directly? > We have also turned on the new SourceForge Allura system which is much > slicker than the old SourceForge for submitting bugs/patches- It's certainly slicker, but I no longer seem able to change details on bugs, and I can't see a way to filter by category any more (e.g. to see just the bugs for a particular language backend). Am I missing something? Cheers, Olly |
From: William S F. <ws...@fu...> - 2013-01-05 01:10:59
|
On 04/01/13 05:35, Olly Betts wrote: > William S Fulton writes: >> With the new year we have switched SWIG development to a new development >> model - Git on Github. > > So is the plan that everyone now submits pull requests which you process, or > are you intending to let other developers push to the swig repo directly? > No - I don't have the time or the inclination to be the only gatekeeper of the source. I would like to provide write access in a similar way as we had with svn. There were 50+ developers with write access before, but most are no longer actively contributing. I'll give those who are actively contributing and maintainers of language modules write access. If you fall into this category, please give me your Github account name to add you into the new 'Developers' team I've just set up on Github. Olly, I've just added you. Other ad hoc contributors should send pull requests on Github. I hope this approach is sensible and helpful. William |
From: William S F. <ws...@fu...> - 2013-01-06 02:35:58
|
On 04/01/13 05:35, Olly Betts wrote: > William S Fulton writes: >> We have also turned on the new SourceForge Allura system which is much >> slicker than the old SourceForge for submitting bugs/patches- > > It's certainly slicker, but I no longer seem able to change details on bugs, > and I can't see a way to filter by category any more (e.g. to see just the > bugs for a particular language backend). Am I missing something? I've configured it so that the Labels are now showing as an additional column. If you click on one of the labels then it shows you a search for those labels, eg https://sourceforge.net/p/swig/bugs/search?q=labels:php for php labels. But then I prefer the drop-down boxes to configure searches, otherwise you have to work out the search syntax, say you want to see all the php bugs that are open, it needs a visit to the search syntax help page. Oh well :( William |
From: Geert J. <in...@ko...> - 2013-03-23 13:15:58
|
On Thursday 03 January 2013 20:14:23 William S Fulton wrote: With the new year we have switched SWIG development to a new development model - Git on Github. The old Subversion history (including the even older CVS history) has been migrated and is now viewable in Github - https://github.com/swig/swig[1] . If you have used SWIG we would really appreciate improvements you have made for incorporation into the mainline SWIG releases. So, feel free to use Github to fork and send your pull requests or patches. Improvements to the documentation are also very welcome - the docs can be found at https://github.com/swig/swig/tree/master/Doc/Manual[2] . Information for getting going is on the SWIG website: http://www.swig.org/svn.html[3] . We have also turned on the new SourceForge Allura system which is much slicker than the old SourceForge for submitting bugs/patches - https://sourceforge.net/projects/swig/[4] . Happy new year!William A meta question... I have cloned the master repository and have been playing on a private branch for my guile updates. I don't think my work is ready yet to be merged into the main repo. But I'd like to publish what I have so far to gather feedback. Since I have been working on a private branch so far, it was easy to rebase my branch to the latest master HEAD. But I read here and there that rebasing published branches is not really recommended. So I wonder what swig's public branch policy is ? I can push my branch to a cloned git repo, so others can look into it there or pull it into their own local repos. Can I still rebase it afterwards without causing too much frustration for other developers ? Or should I start merging the master branch into my personal branch regularly from there on ? How do other developers handle this ? Geert -------- [1] https://github.com/swig/swig [2] https://github.com/swig/swig/tree/master/Doc/Manual [3] http://www.swig.org/svn.html [4] https://sourceforge.net/projects/swig/ |
From: William S F. <ws...@fu...> - 2013-04-19 18:28:51
|
On 23/03/13 13:15, Geert Janssens wrote: > On Thursday 03 January 2013 20:14:23 William S Fulton wrote: > > With the new year we have switched SWIG development to a new development > model - Git on Github. The old Subversion history (including the even > older CVS history) has been migrated and is now viewable in Github - > https://github.com/swig/swig. If you have used SWIG we would really > appreciate improvements you have made for incorporation into the > mainline SWIG releases. So, feel free to use Github to fork and send > your pull requests or patches. > > Improvements to the documentation are also very welcome - the docs can > be found at https://github.com/swig/swig/tree/master/Doc/Manual. > > Information for getting going is on the SWIG website: > http://www.swig.org/svn.html. > > We have also turned on the new SourceForge Allura system which is much > slicker than the old SourceForge for submitting bugs/patches - > https://sourceforge.net/projects/swig/. > > Happy new year! > William > > A meta question... > > I have cloned the master repository and have been playing on a private > branch for my guile updates. > > I don't think my work is ready yet to be merged into the main repo. But > I'd like to publish what I have so far to gather feedback. > > Since I have been working on a private branch so far, it was easy to > rebase my branch to the latest master HEAD. But I read here and there > that rebasing published branches is not really recommended. > > So I wonder what swig's public branch policy is ? > In the official swig repo, it will be frowned upon to rebase. > I can push my branch to a cloned git repo, so others can look into it > there or pull it into their own local repos. Can I still rebase it > afterwards without causing too much frustration for other developers ? > For your own clone, you can do what you like. If other people are collaborating with you in your repo, then rebasing would be a bad idea. How about a private guile dev branch that you merge to a public guile dev branch which you advertise for general use? > Or should I start merging the master branch into my personal branch > regularly from there on ? Yup. Eventually I'd like one patch to apply to master for your initial guile update. We could do it via a merge from your repo/branch, but it seems that git bisect doesn't like branches, so I'm wondering if we should avoid branches and keep the development linear. It seems there are two schools of thought on best development practices for git, but we are still learning our way. Sorry for slow response, seems you have got going anyway. William |
From: Geert J. <in...@ko...> - 2013-04-20 07:35:18
|
On Friday 19 April 2013 19:28:29 William S Fulton wrote: > On 23/03/13 13:15, Geert Janssens wrote: > > > > A meta question... > > > > I have cloned the master repository and have been playing on a private > > branch for my guile updates. > > > > I don't think my work is ready yet to be merged into the main repo. But > > I'd like to publish what I have so far to gather feedback. > > > > Since I have been working on a private branch so far, it was easy to > > rebase my branch to the latest master HEAD. But I read here and there > > that rebasing published branches is not really recommended. > > > > So I wonder what swig's public branch policy is ? > > In the official swig repo, it will be frowned upon to rebase. > Understood > > I can push my branch to a cloned git repo, so others can look into it > > there or pull it into their own local repos. Can I still rebase it > > afterwards without causing too much frustration for other developers ? > > For your own clone, you can do what you like. If other people are > collaborating with you in your repo, then rebasing would be a bad idea. > How about a private guile dev branch that you merge to a public guile > dev branch which you advertise for general use? > > > Or should I start merging the master branch into my personal branch > > regularly from there on ? > > Yup. Eventually I'd like one patch to apply to master for your initial > guile update. We could do it via a merge from your repo/branch, but it > seems that git bisect doesn't like branches, so I'm wondering if we > should avoid branches and keep the development linear. It seems there > are two schools of thought on best development practices for git, but we > are still learning our way. > >From some quick search on the internet, it seems that bisect can work perfectly fine with branches (1). But I haven't had real life experience with bisection across branches myself so I'm in no position to actually make statements about best practice. If you like to keep development linear, how about cherry-picking the individual commits on my branch ? I'm currently at 6 commits. Two for the actual introduction of guile 2.0 support, one cleanup commit before, one for dropping guile 1.6 support, one for dropping the guile gh interface and the last one to fix the deprecation warnings. Theoretically I could reduce this into one big patch, but that would make it much harder to understand what I actually did and why. So I prefer to keep them in separate commits. Geert (1) http://git-scm.com/docs/git-bisect-lk2009.html |
From: Alexey S. <al...@as...> - 2013-04-23 18:26:47
Attachments:
signature.asc
|
20.04.2013 01:28, William S Fulton пишет: > but it > seems that git bisect doesn't like branches, Where did you get this?.. git bisect has no problems with branches. Well, branches is everything git is about -- Best regards, Alexey "DarthGandalf" Sokolov |
From: William S F. <ws...@fu...> - 2013-04-23 22:48:01
Attachments:
guile-travis.patch
|
On 20/04/13 08:35, Geert Janssens wrote: > On Friday 19 April 2013 19:28:29 William S Fulton wrote: > > > On 23/03/13 13:15, Geert Janssens wrote: > > > > > > > > A meta question... > > > > > > > > I have cloned the master repository and have been playing on a private > > > > branch for my guile updates. > > > > > > > > I don't think my work is ready yet to be merged into the main repo. But > > > > I'd like to publish what I have so far to gather feedback. > > > > > > > > Since I have been working on a private branch so far, it was easy to > > > > rebase my branch to the latest master HEAD. But I read here and there > > > > that rebasing published branches is not really recommended. > > > > > > > > So I wonder what swig's public branch policy is ? > > > > > > In the official swig repo, it will be frowned upon to rebase. > > > > > Understood > > > > I can push my branch to a cloned git repo, so others can look into it > > > > there or pull it into their own local repos. Can I still rebase it > > > > afterwards without causing too much frustration for other developers ? > > > > > > For your own clone, you can do what you like. If other people are > > > collaborating with you in your repo, then rebasing would be a bad idea. > > > How about a private guile dev branch that you merge to a public guile > > > dev branch which you advertise for general use? > > > > > > > Or should I start merging the master branch into my personal branch > > > > regularly from there on ? > > > > > > Yup. Eventually I'd like one patch to apply to master for your initial > > > guile update. We could do it via a merge from your repo/branch, but it > > > seems that git bisect doesn't like branches, so I'm wondering if we > > > should avoid branches and keep the development linear. It seems there > > > are two schools of thought on best development practices for git, but we > > > are still learning our way. > > > > > From some quick search on the internet, it seems that bisect can work > perfectly fine with branches (1). But I haven't had real life experience > with bisection across branches myself so I'm in no position to actually > make statements about best practice. If you like to keep development > linear, how about cherry-picking the individual commits on my branch ? > > I'm currently at 6 commits. Two for the actual introduction of guile 2.0 > support, one cleanup commit before, one for dropping guile 1.6 support, > one for dropping the guile gh interface and the last one to fix the > deprecation warnings. > > Theoretically I could reduce this into one big patch, but that would > make it much harder to understand what I actually did and why. So I > prefer to keep them in separate commits. > No, that is a nice manageable number of commits for what is a fairly big impact change. Perfect! You update your repo to the HEAD of master as with the latest fixes applied, you will probably have a full pass of the test-suite. There are a couple of silly warnings which would be nice to fix. If you don't, I will fix them as I try keep the number of warnings right down to suppress the noise they make. The nspace feature is missing in all the scripting languages, so don't worry about that. One day I'd like this feature finished off for all the languages. Before merging to master, I'd like you to have the Travis builds showing green in your github repo. First you should set up Travis on your repo which is dead easy, see http://about.travis-ci.org/docs/user/getting-started/ Then commit the attached .travis.yml patch. Instead of using 'git am', you can simply use 'git apply' and use 'git commit --author ...', although I wouldn't bother with putting me as the author. It should be clear that the patch uses guile-2.0. The examples probably still need some work though. The 'check' target in each needs fixing to run the tests properly... I'm not sure how to run guile for the examples which have no runtest in the 'check' target. Lastly I have a question about guile scm and gh. What is the difference? Does scm supercede gh and is gh going away? If both are important we need to configure Travis to test both. William |
From: William S F. <ws...@fu...> - 2013-04-23 22:53:51
|
On 23/04/13 23:47, William S Fulton wrote: > Before merging to master, I'd like you to have the Travis builds showing > green in your github repo. First you should set up Travis on your repo > which is dead easy, see > http://about.travis-ci.org/docs/user/getting-started/ Then commit the > attached .travis.yml patch. Instead of using 'git am', you can simply > use 'git apply' and use 'git commit --author ...', although I wouldn't > bother with putting me as the author. It should be clear that the patch > uses guile-2.0. Also you need to add in the name of your branch 'guile2' at the end of .travis.yml in the branches: only: section else Travis will ignore your branch. We won't want this commit when merged to master though. William |
From: Geert J. <in...@ko...> - 2013-04-24 14:59:14
|
On Tuesday 23 April 2013 23:47:49 William S Fulton wrote: > On 20/04/13 08:35, Geert Janssens wrote: > > On Friday 19 April 2013 19:28:29 William S Fulton wrote: > > > On 23/03/13 13:15, Geert Janssens wrote: > > > > A meta question... > > > > > > > > > > > > > > > > I have cloned the master repository and have been playing on a > > > > private > > > > > > > > branch for my guile updates. > > > > > > > > > > > > > > > > I don't think my work is ready yet to be merged into the main repo. > > > > But > > > > > > > > I'd like to publish what I have so far to gather feedback. > > > > > > > > > > > > > > > > Since I have been working on a private branch so far, it was easy to > > > > > > > > rebase my branch to the latest master HEAD. But I read here and there > > > > > > > > that rebasing published branches is not really recommended. > > > > > > > > > > > > > > > > So I wonder what swig's public branch policy is ? > > > > > > In the official swig repo, it will be frowned upon to rebase. > > > > Understood > > > > > > I can push my branch to a cloned git repo, so others can look into it > > > > > > > > there or pull it into their own local repos. Can I still rebase it > > > > > > > > afterwards without causing too much frustration for other developers > > > > ? > > > > > > For your own clone, you can do what you like. If other people are > > > > > > collaborating with you in your repo, then rebasing would be a bad idea. > > > > > > How about a private guile dev branch that you merge to a public guile > > > > > > dev branch which you advertise for general use? > > > > > > > Or should I start merging the master branch into my personal branch > > > > > > > > regularly from there on ? > > > > > > Yup. Eventually I'd like one patch to apply to master for your initial > > > > > > guile update. We could do it via a merge from your repo/branch, but it > > > > > > seems that git bisect doesn't like branches, so I'm wondering if we > > > > > > should avoid branches and keep the development linear. It seems there > > > > > > are two schools of thought on best development practices for git, but > > > we > > > > > > are still learning our way. > > > > From some quick search on the internet, it seems that bisect can work > > > > perfectly fine with branches (1). But I haven't had real life experience > > with bisection across branches myself so I'm in no position to actually > > make statements about best practice. If you like to keep development > > linear, how about cherry-picking the individual commits on my branch ? > > > > I'm currently at 6 commits. Two for the actual introduction of guile 2.0 > > support, one cleanup commit before, one for dropping guile 1.6 support, > > one for dropping the guile gh interface and the last one to fix the > > deprecation warnings. > > > > Theoretically I could reduce this into one big patch, but that would > > make it much harder to understand what I actually did and why. So I > > prefer to keep them in separate commits. > > No, that is a nice manageable number of commits for what is a fairly big > impact change. Perfect! > > You update your repo to the HEAD of master as with the latest fixes > applied, you will probably have a full pass of the test-suite. There are > a couple of silly warnings which would be nice to fix. If you don't, I > will fix them as I try keep the number of warnings right down to > suppress the noise they make. > > The nspace feature is missing in all the scripting languages, so don't > worry about that. One day I'd like this feature finished off for all the > languages. > > Before merging to master, I'd like you to have the Travis builds showing > green in your github repo. First you should set up Travis on your repo > which is dead easy, see > http://about.travis-ci.org/docs/user/getting-started/ Then commit the > attached .travis.yml patch. Instead of using 'git am', you can simply > use 'git apply' and use 'git commit --author ...', although I wouldn't > bother with putting me as the author. It should be clear that the patch > uses guile-2.0. > > The examples probably still need some work though. The 'check' target in > each needs fixing to run the tests properly... I'm not sure how to run > guile for the examples which have no runtest in the 'check' target. > I can look at those and see what I can improve. But I will have to postphone it a bit. Can this wait until after the integration of guile2 into master ? |
From: Alexey S. <al...@as...> - 2013-04-24 02:41:49
Attachments:
signature.asc
|
24.04.2013 02:47, William S Fulton пишет: > Before merging to master, I'd like you to have the Travis builds > showing green in your github repo. First you should set up Travis on > your repo which is dead easy, see > http://about.travis-ci.org/docs/user/getting-started/ Then commit the > attached .travis.yml patch. Instead of using 'git am', you can simply > use 'git apply' and use 'git commit --author ...', although I wouldn't > bother with putting me as the author. It should be clear that the > patch uses guile-2.0. Travis is much nicer than you think ;) The only thing Geert needs to do is to make a pull request, Travis will do the rest. See http://about.travis-ci.org/blog/2012-09-04-pull-requests-just-got-even-more-awesome/ -- Best regards, Alexey "DarthGandalf" Sokolov |
From: Geert J. <in...@ko...> - 2013-04-24 14:12:05
|
On Wednesday 24 April 2013 06:41:30 Alexey Sokolov wrote: > 24.04.2013 02:47, William S Fulton пишет: > > Before merging to master, I'd like you to have the Travis builds > > showing green in your github repo. First you should set up Travis on > > your repo which is dead easy, see > > http://about.travis-ci.org/docs/user/getting-started/ Then commit the > > attached .travis.yml patch. Instead of using 'git am', you can simply > > use 'git apply' and use 'git commit --author ...', although I wouldn't > > bother with putting me as the author. It should be clear that the > > patch uses guile-2.0. > > Travis is much nicer than you think ;) > The only thing Geert needs to do is to make a pull request, Travis will > do the rest. See > http://about.travis-ci.org/blog/2012-09-04-pull-requests-just-got-even-more-> awesome/ Ok, here's what I have done: - merged master into my guile 2 branch - fixed the external test again (got broken in another way on the guile 2 branch) - registered with travis - applied the .travis.yml patch - triggered a pull request Will that do to get travis to build my changes ? Note that I haven't explicitly added guile2 to the branches to build in the yml file. From Alexey's comment it seems that isn't necessary anymore. Geert |
From: William S F. <ws...@fu...> - 2013-04-24 14:38:43
|
On 24/04/13 15:11, Geert Janssens wrote: > On Wednesday 24 April 2013 06:41:30 Alexey Sokolov wrote: > > > 24.04.2013 02:47, William S Fulton пишет: > > > > Before merging to master, I'd like you to have the Travis builds > > > > showing green in your github repo. First you should set up Travis on > > > > your repo which is dead easy, see > > > > http://about.travis-ci.org/docs/user/getting-started/ Then commit the > > > > attached .travis.yml patch. Instead of using 'git am', you can simply > > > > use 'git apply' and use 'git commit --author ...', although I wouldn't > > > > bother with putting me as the author. It should be clear that the > > > > patch uses guile-2.0. > > > > > > Travis is much nicer than you think ;) > > > The only thing Geert needs to do is to make a pull request, Travis will > > > do the rest. See > > > > http://about.travis-ci.org/blog/2012-09-04-pull-requests-just-got-even-more- > > > awesome/ > > Ok, here's what I have done: > > - merged master into my guile 2 branch > > - fixed the external test again (got broken in another way on the guile > 2 branch) > > - registered with travis > > - applied the .travis.yml patch > > - triggered a pull request > > Will that do to get travis to build my changes ? Note that I haven't > explicitly added guile2 to the branches to build in the yml file. From > Alexey's comment it seems that isn't necessary anymore. The patch submission is to master, so the patch is tested against master, so is independent of the source of the patch for Travis pull request builds. Hence you don't need guile2 in .travis.yml in your pull request. However, if you test it on your guile2 branch in your repo as I was suggesting, then you'd need to add travis2 into .travis.yml. Looks like there is a fair bit more todo looking at the Travis patch pull request - https://travis-ci.org/swig/swig/jobs/6600579. There are plenty of weird warnings - I'd like the output to be clean to the same level as the other languages. If you are struggling with the 'make check-guile-examples', either look at the recent commits for other languages in this area or just shout when you have the running of the tests working and I'll tidy up the Makefiles. William |
From: William S F. <ws...@fu...> - 2013-04-24 14:47:39
|
On 24/04/13 03:41, Alexey Sokolov wrote: > 24.04.2013 02:47, William S Fulton пишет: >> Before merging to master, I'd like you to have the Travis builds >> showing green in your github repo. First you should set up Travis on >> your repo which is dead easy, see >> http://about.travis-ci.org/docs/user/getting-started/ Then commit the >> attached .travis.yml patch. Instead of using 'git am', you can simply >> use 'git apply' and use 'git commit --author ...', although I wouldn't >> bother with putting me as the author. It should be clear that the >> patch uses guile-2.0. > Travis is much nicer than you think ;) > The only thing Geert needs to do is to make a pull request, Travis will > do the rest. See > http://about.travis-ci.org/blog/2012-09-04-pull-requests-just-got-even-more-awesome/ Sure, for small patches this works well, but not for larger changes like Geert's. I doubt this will be got right first time as it is a new Travis target on an architecture that is probably different to Geert's own test environment. I would rather not have development by patch submission as it creates a lot of unnecessary noise. In an ideal world the patch is submitted and is perfect on first submission. When this is unlikely I think the developer should go through the testing iterations on their own branch given it is so easy to set up Travis. William |
From: Geert J. <in...@ko...> - 2013-04-24 16:05:42
|
On Wednesday 24 April 2013 15:18:44 William S Fulton wrote: > On 24/04/13 03:41, Alexey Sokolov wrote: > > 24.04.2013 02:47, William S Fulton пишет: > >> Before merging to master, I'd like you to have the Travis builds > >> showing green in your github repo. First you should set up Travis on > >> your repo which is dead easy, see > >> http://about.travis-ci.org/docs/user/getting-started/ Then commit the > >> attached .travis.yml patch. Instead of using 'git am', you can simply > >> use 'git apply' and use 'git commit --author ...', although I wouldn't > >> bother with putting me as the author. It should be clear that the > >> patch uses guile-2.0. > > > > Travis is much nicer than you think ;) > > The only thing Geert needs to do is to make a pull request, Travis will > > do the rest. See > > http://about.travis-ci.org/blog/2012-09-04-pull-requests-just-got-even-mor > > e-awesome/ > Sure, for small patches this works well, but not for larger changes like > Geert's. I doubt this will be got right first time as it is a new Travis > target on an architecture that is probably different to Geert's own test > environment. I would rather not have development by patch submission as > it creates a lot of unnecessary noise. In an ideal world the patch is > submitted and is perfect on first submission. When this is unlikely I > think the developer should go through the testing iterations on their > own branch given it is so easy to set up Travis. > > William > > FYI, I have now added my own guile2 branch in .travis.yml, so I can test independently. A lot of the warnings are caused by guile2's new autocompile feature. I have disabled it for the test-suite and the output is much cleaner already. There is one testcase that fails on travis that works in my environment (integers). I'll have to investigate that one. Geert |
From: William S F. <ws...@fu...> - 2013-04-25 20:53:47
|
On 24/04/13 01:26, Alexey Sokolov wrote: > 20.04.2013 01:28, William S Fulton пишет: >> but it >> seems that git bisect doesn't like branches, > Where did you get this?.. git bisect has no problems with branches. > Well, branches is everything git is about Bisect works with branches, but not very well from the view of some experienced users such as explained here: http://darwinweb.net/articles/the-case-for-git-rebase http://blog.izs.me/post/37650663670/git-rebase My main problem is with long topic branches, which although works to some degree with git bisect, I'm more concerned about being able to easily work out what the hell is going on. As soon as we started using git, the branching got out of hand, until I started avoiding it for pull requests. Take a look at the log for the 1st month of using git until I started to use 'git am' for pull requests:: git log --oneline --graph rel-2.0.9..38d454a1 You just can't tell what is going on. If the branches were always rebased little topic branches like: git log --oneline --graph ee2b46ab..670962cf then the development is mostly linear and branching is comprehensible, and from what I read git bisect has more chance of working easily. Eventually I guess we'll write some notes on how to submit the ideal pull request/patch and how to apply it. Meanwhile, I'm only just learning git and forming impressions of good work flows, so experienced git users can advise. William |
From: Johan H. <ha...@si...> - 2013-04-26 14:58:52
|
We have just switched to git (hosted on bitbucket) for fenicsproject.org. Most core developers are still getting used to git. However we have adopted a modified version of gitworkflow as our develomemt model. For now we just use the subset of gitworkflow that PETSc is using. See: https://www.kernel.org/pub/software/scm/git/docs/gitworkflows.html https://bitbucket.org/petsc/petsc/wiki/developer-instructions-git for more information. Maybe these strategies can inspire a structure for SWIG development? Johan On Apr 25, 2013 10:54 PM, "William S Fulton" <ws...@fu...> wrote: > On 24/04/13 01:26, Alexey Sokolov wrote: > > 20.04.2013 01:28, William S Fulton пишет: > >> but it > >> seems that git bisect doesn't like branches, > > Where did you get this?.. git bisect has no problems with branches. > > Well, branches is everything git is about > > Bisect works with branches, but not very well from the view of some > experienced users such as explained here: > > http://darwinweb.net/articles/the-case-for-git-rebase > http://blog.izs.me/post/37650663670/git-rebase > > My main problem is with long topic branches, which although works to > some degree with git bisect, I'm more concerned about being able to > easily work out what the hell is going on. As soon as we started using > git, the branching got out of hand, until I started avoiding it for pull > requests. Take a look at the log for the 1st month of using git until I > started to use 'git am' for pull requests:: > > git log --oneline --graph rel-2.0.9..38d454a1 > > You just can't tell what is going on. If the branches were always > rebased little topic branches like: > > git log --oneline --graph ee2b46ab..670962cf > > then the development is mostly linear and branching is comprehensible, > and from what I read git bisect has more chance of working easily. > > Eventually I guess we'll write some notes on how to submit the ideal > pull request/patch and how to apply it. Meanwhile, I'm only just > learning git and forming impressions of good work flows, so experienced > git users can advise. > > William > > > ------------------------------------------------------------------------------ > Try New Relic Now & We'll Send You this Cool Shirt > New Relic is the only SaaS-based application performance monitoring service > that delivers powerful full stack analytics. Optimize and monitor your > browser, app, & servers with just a few lines of code. Try New Relic > and get this awesome Nerd Life shirt! http://p.sf.net/sfu/newrelic_d2d_apr > _______________________________________________ > Swig-devel mailing list > Swi...@li... > https://lists.sourceforge.net/lists/listinfo/swig-devel > |