develooper Front page | perl.perl5.porters | Postings from November 2008

git workflow (was Re: git?)

Thread Next
David Golden
November 14, 2008 01:59
git workflow (was Re: git?)
Message ID:
On Fri, Nov 14, 2008 at 4:32 AM, Nicholas Clark <> wrote:
> One part of the documentation I know is missing is:
>  There are no instructions on how to commit back to the repository.

More importantly, there are no instructions yet on what the "workflow"
should be.

Git supports multiple committers to a single repository, but it
doesn't really have to work that way.

In a way, the pumpking's local git repo *is* the master repository.
The question is how/where to publish that publicly for others to work

Some thoughts:

(1) pumpkings publish to their own individual repositories

pro: low admin overhead
con: hard for the un-initiated to know which repository to clone to
participate on a particular branch

(2) pumpkings publish to the "master" perl repository

pro: single definitive master repo for everyone to track
con: pumpkings all need commit access (generally via ssh)

> Anonymous checkouts are easy. (This is good. This is a feature. This is a big
> improvement over the Perforce setup)
> But I've heard different plans on how commits get back - is it via an ssh
> tunnel, is it a git push (whatever that is).

(I think ssh protocol is just the easy way to authenticate a "git
push" operation.)

I think the basic workflow might go something like this:

(1) contributor clones master perl repository
(2) contributor hacks
(3) contributor publishes work
    (a) sends emails with patches to p5p list ("git send-email")
    (b) publishes own repository and sends a "pull notice" to p5p list
(4) pumpking applies patches
    (a) from email ("git apply")
    (b) from contributor's repository ("git remote add ..."; git pull
(5) pumpking publishes updated "master" ("git push")

It may seem a bit complex, but in practice it's pretty easy.  Here's
an example: rjbs and I continued the Oslo hackathon on the plane ride
home using a USB drive as our transfer medium.  We each had a working
repository on our laptops and we each published to separate folders on
the USB drive.

* dagolden hacks; dagolden inserts usb drive and publishes ("git push")
* dagolden gives usb drive to rjbs
* rjbs inserts drive and updates his working repo ("git pull dagolden")
* rjbs hacks; rjbs publishes new merged repo ("git push")
* rjbs gives usb drive to dagolden
* dagolden inserts drive and updates ("git pull rjbs")

That's the rhythm: I pull *your* work; I push *my* work

-- David

Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About