Re: git workflow (was Re: git?)

That is not going to *entirely* work because git is not the same
as Perforce and the centralised model makes assumptions and
impositions that git does not. But it is certainly possible to
stay close.

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.

> We change EXACTLY ONE THING at a time.
>
> Then, once we're happy with using git to do the tasks we
> already know about, we change and improve the workflow using
> the same tool.
>
> Small incremental changes. Far more likely to succeed.

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.

Maybe we should simply declare all potentially restrictive
decisions (like which repository is going to be official/blessed)
to be tentative until all the current committers feel basically
comfortable with git so they can weigh the consequences of
choices and therefore make firm decisions themselves?

Regards,