Front page | perl.perl5.porters |
Postings from November 2008
Re: git workflow (was Re: git?)
November 16, 2008 15:51
Re: git workflow (was Re: git?)
Message ID: firstname.lastname@example.org
2008/11/16 Nicholas Clark <email@example.com>:
> On Sun, Nov 16, 2008 at 07:44:38PM +0100, Aristotle Pagaltzis wrote:
>> * Nicholas Clark <firstname.lastname@example.org> [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
patch -p 1 < patchname.txt
git commit -a -m'....'
and you are done. Of course you could also use
and pretty much be done with it:
git-am - Apply a series of patches from a mailbox
git am [--signoff] [--keep] [--utf8 | --no-utf8]
[--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
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
> 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/"