On Mon, Mar 12, 2012 at 1:03 PM, Vincent van Ravesteijn <[email protected]> wrote: > Op 12-3-2012 0:44, Lars Gullik Bjønnes schreef:
First of all, thank you for this work Lars, this is a truly great achievement :-) >> If we want to introduce a staging repo and can also be done, but we >> shouldn't change to much at the same time. I strongly think that one repo per developper is way too complicated. > Usually it is quite problematic to have a fellow developer to look at your > proposed changes. Especially if the developers should look at ten different > repositories. > > That's why I would like a staging branch/repo. To have a single place where > all the finished but not yet pushed work can be found. Fully agreed. I've tried both methods withing my team at work (using mercurial not git but the idea is the same). Initially, one branch per developper is really the way to go: It's easy to understand and to follow: You just do like you did with svn but committing only to your personal branch. The only 2 additional steps is to merge from lyx-devel from time to time. The lyx-devel maintainer will actually take care of merging your personal branch to lyx-devel. > Also, I would say it would be ok to rewrite the history in your personal > branch. People should not base work on your personal branch. It's one of the > advantages of git, that you can "publish" the work, that people can comment > on it, and you reshape it before pushing it to the main repo/branch. Agreed. But I actually think that the main repo should be pushed only by the current maintainers: Richard and Vincent. I would go even further: The main repo would be automatically synchronized (only the 2.0 and 2.1 branches); either via a git hook or a cron script at server side. The cron idea is better if only we had some automatic regression testing in place. Then only those commits that passes regression on the cooking repo would be pushed to the main repo. Cheer, Abdel.
