Re: git workflow (was Re: git?)

Please understand that this is because p5p has not picked a git
workflow yet. Git lets you pick pretty nearly any workflow you
like so the question on the table right now is “what workflow do
we on p5p want to establish?� In contrast, the question a
newcomer to p5p will eventually encounter is “how do I fit myself
into p5p’s workflow?�, which will be a very much easier to answer
question for which we will have a _Patches in a Minute_ rather
than handing out _The Way of Git_.

> IMO, without a good, Perl-specific cheat sheet, we are somewhat
> ill-prepared for the git transition. I will do what I can to
> help, but I'm short on both tuits and expertise to write such a
> document.

The current situation is complicated by the fact that many main
“stakeholders� have not had time to familiarise themselves with
git such that they already know their options, leading to the
long discussions that you see. (I am not saying that this is a
bad thing! I am rather pointing out that it is to be expected and
completely natural.) Please do not be alarmed at how broadly the
debate is meandering; this is merely a phase. It is a normal part
of establishing cooperation using a DVCS, and the discussion is
as intense as it is merely because many people are having it as
they are learning about DVCS in the first place. If everyone were
familiar with DVCS, consensus would be reached very much faster,
but at this time it’s a novel concept to many.

In short: relax. :-)

Furthermore, just as git does not impose any particular workflow,
it does not impose it at any one time; by which I mean to say,
you can always change it or make additions or adjustments later.
This also means a group of contributors can always use a
different workflow amongst themselves, and as a whole still
integrate into the main project workflow.

Got that? What I am trying to say here is: we don’t have to get
everything completely perfect straight away. So there is no need
to worry there either.

Again: relax. :-)

This will all become clearer once you start using git. It’s a lot
less overwhelming than might seem right now from the outside.

> But no one should have to know anything about how git works
> internally in order to track a couple of branches of Perl and
> submit their changes back. If they do, that's a fail.

Actually, this I’ll *sorta* disagree with. The fundamental git
data model is exposed very directly in git. Though you do not
need to know it in order to follow a cheat sheet or if others
tell you what to do, you will need an understanding of it to do
anything interesting of your own device. The analogy to baby-talk
Perl that someone else made is very apt here. Realise however
that the git data model is extraordinarily simple.

Then, there are all the clever ways in which git’s implementation
exploits the git data model in order to be fast. (Eg. it does
some very smart things to produce diffs between enormous trees
in milliseconds.) Knowing git internals at this level is not
necessary to use it.

Regards,