On May 7, Michael Sperber wrote:
> Thanks - this helps considerably.
>
> However, it's long on technical information on how one could work
> with git, and short on policy, i.e. how you want us to use git for
> PLT.
There's not going to be much on policy, at least not for a while.
(Like Sam mentioned, the minimal policy that the server enforces is
preventing you from pushing modified releases.)
> Immediate questions:
>
> - Should we merge or rebase?
Whatever seems better. The only thing that is really obnoxious is a
single commit follwed by a merge. There's really no reason not to
rebase in those cases.
> - Should we push directly to origin/master, or somewhere else, and
> you do the pulling?
Push directly -- that's why the server is there... For releases I'll
do the same thing as with svn -- a release branch that I'll
cherry-pick commits into.
> (Push doesn't scale indefinitely.)
How's that?
> - For longer-lived branches that we want others to see, do you want
> us to use named branches within the main repo, or user
> repositories?
User repositories -- and I should finish writing about that to make it
into a requirement. So if you have a long lived branch that you need
now, then start a branch and later I'll help moving it to a private
clone. The branch will have to start with your username
("sperber/...").
Or, if you know how to work with private clones, then just do so...
ssh pltgit fork plt sperber/plt; clone pltgit:sperber/plt
Also, this might change if there are long-lived branches with public
interests.
--
((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay:
http://barzilay.org/ Maze is Life!
_________________________________________________
For list-related administrative tasks:
http://list.cs.brown.edu/mailman/listinfo/plt-dev
