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

Re: git workflow (was Re: git?)

Thread Previous | Thread Next
November 16, 2008 15:51
Re: git workflow (was Re: git?)
Message ID:
2008/11/16 Nicholas Clark <>:
> On Sun, Nov 16, 2008 at 07:44:38PM +0100, Aristotle Pagaltzis wrote:
>> * Nicholas Clark <> [2008-11-16 18:55]:
>> > RIGHT NOW we go for exactly the same workflow as we're using
>> > with Perforce.
>> That is not going to *entirely* work because git is not the samae
>> as Perforce and the centralised model makes assumptions and
>> impositions that git does not. But it is certainly possible to
>> stay close.
> Ah OK
>> I think important in is this case in particular is the part that
>> followed the one you quoted: that groups of people with different
>> workflows can collaborate productively. In other words, you (Nick
>> Clark, not the general ???you???) can stick to something close to
>> Perforce while the more git-experienced committers can take more
>> advantage of distribution without you having to hop right into
>> the deep end trying to understand everything at once. You???ll get
>> to see what they???re doing and how, and get some assistance in how
>> it can all be fit together, getting into the groove by example.
> Right. This makes sense. So to me, right now, the useful assistance I'd like
> would be to have documented how have a git workflow as close as is sane to the
> current perforce commit-to-blead workflow.

Afaik it is basically the same, except you dont have to worry about
unlocking the files that are affected by a patch.

The really simple version would be

git pull
patch -p 1 < patchname.txt
git commit -a -m'....'
git push

and you are done. Of course you could also use

git pull
git am
git push

and pretty much be done with it:

       git-am - Apply a series of patches from a mailbox

       git am [--signoff] [--keep] [--utf8 | --no-utf8]
                [--3way] [--interactive]
                [--whitespace=<option>] [-C<n>] [-p<n>]
                [<mbox> | <Maildir>...]
       git am (--skip | --resolved | --abort)

       Splits mail messages in a mailbox into commit log message,
authorship information and patches, and applies them to the current

> (Given that once 5.8.9 comes out, I don't need to worry about merging
> branches, so I don't need to immediately learn *that* in git)

In general you would probably not actually merge named branches like
blead into 5.8.x, instead you would git-cherry-pick patches from blead
and apply them to 5.8.x And thats pretty much it. In other words you
would find a patch from blead, note its SHA1 and then do something

git cherry-pick --edit -x -s $SHA1

or maybe

git cherry-pick --edit -x -s -n $SHA1

The latter if you wanted to do further modifications after the
application of the patch.

GIT-CHERRY-PICK(1)                Git Manual                GIT-CHERRY-PICK(1)

       git-cherry-pick - Apply the change introduced by an existing commit

       git cherry-pick [--edit] [-n] [-m parent-number] [-s] [-x] <commit>

       Given one existing commit, apply the change the patch
introduces, and record a new commit that records it. This requires
your working tree to be clean (no modifications from the HEAD commit).

>> My only concern with that is to avoid infrastructure like the
>> smokers getting set up in ways that are tied too closely to
>> transitory workflows, thereby becoming a roadblock to future
>> improvements.
> The smokers currently all run of the same rsync server. So whatever the
> rsync server serves up is what all the current smokers will smoke. They
> would only become a blocker if people started to set up smokers that got
> their code via git, rather than rsync, and then expected that to keep working.
> Right now the rsync server acts as a single point of control, that allows
> us to easily change what "workflow" the (existing) smokers smoke.

The workflow need not change appreciably at all. If smokers switch to
using git fetch/checkout, basically the only thing that will happen is
their updates will get faster.


perl -Mre=debug -e "/just|another|perl|hacker/"

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