[plt-dev] Revised git intro text

From: Eli Barzilay (eli at barzilay.org)
Date: Fri May 7 12:04:45 EDT 2010

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

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

          ((lambda (x) (x x)) (lambda (x) (x x)))          Eli Barzilay:
                    http://barzilay.org/                   Maze is Life!

Posted on the dev mailing list.