Op 12-3-2012 0:44, Lars Gullik Bjønnes schreef:
lar...@gullik.org (Lars Gullik Bjønnes) writes:

| lar...@gullik.org (Lars Gullik Bjønnes) writes:
| | ->  write access for developers  (this might be moved up in the queue)
| I'll enable write access now, but with some limitations: you are not
| allowed to create new branches nor delete them. Also history rewind is
| not allowed.
| Also: try to avoid pointless merge commits.
|     - multi commit features/work should be done on a separate branch (in
|       your local repo) and merged into the master branch when finished.
|     - single commit work can with benefit be rebased on top of master
| A nice way to look at what the branch looks like (parallel-)history wise
| is to use gitk.

Also if you are bit unsure how to do all this, please do not just muddle
along and create a mess. What you should do is get some guidance:
(substitue "larsbj" with your own username)

       - fork the lyx repo:
          $ ssh g...@git.lyx.org fork lyx developers/larsbj/lyx
       - clone this repo:
          $ git clone g...@git.lyx.org:developers/larsbj/lyx lyx-larsbj
       - try to do all the changes to the best of you abilities,
         ask if you have any questions.
       - instead of doing a push to the real upstream repo, ask some of
         the other developers to have a look at your repo.
         (you have to anable read access for others to your repo: read
          ssh g...@git.lyx.org help)
       - this other developer can possibly help, or even to the upstream
          push for you (after he pulls your changed branch into his own
          repo)

If we play around a bit with this instead of just hitting the main repo
hard I really think we will end up in a lot better state, both process
wise and repo wise.

If we want to introduce a staging repo and can also be done, but we
shouldn't change to much at the same time.

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.

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.

Vincent

Vincent


Reply via email to