A. Pagaltzis (paga...@gmx.de)

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,

* demerphq <demerphq@gmail.com> [2008-11-16 15:50]:
> You said "smokers can PULL from multiple remotes", you meant
> fetch, and some of us understood it that way, but some people
> will think you meant something like:

Yes, sorry. I find “fetch� kind of awkward when used in informal
context, since “pull� is a general concept universally understood
among different DVCSs whereas the pull/fetch distinction that git
makes, in the way that git makes it, is not universal. And I was
trying to speak in conceptual terms rather than implementation.
The vernacular has not settled down enough quite yet and the
difference in everyone’s conception of the terms can make it
frustrating to try to convey ideas at the right level.

> Wheras you really meant:
>
> git remote update
>
> or its equivalent:
>
> for r in $(git remote); do git fetch $r; done;

Yes, exactly. And then check which relevant remote branches have
new stuff and smoke them in turn.

Regards,

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,

No no no. I said nothing about merging.

Fetching from multiple repos does nothing more than convert them
into branches in a single repo. In so doing, the histories from
all the separate repositories will conjoin into a single DAG that
precisely reflects who diverged from whom at what point, at no
extra effort, due to the content addressing design of git. In
other words, multiple repositories and branches are essentially
interchangeable in terms of reasoning about them. A smoker could
then be set up to smoke any number of branches, each separately,
and we would just have to decide which ones we want smoked.

There is no merging going on in any of this.

Distribution means never having to merge in an unsafe/unsane way.
The absolute most terrible aspect of Subversion is that `svn
update` will try to merge against your working copy (!!!!!!) and
leave you without any record of your pre-merge-attempt working
copy state. I can’t understand why that doesn’t make everyone’s
neck hairs stand up when it is suggested as a totally normal part
of the workflow.

I don’t know if Perforce behaves similarly, but if it does, well,
then I can see why you’d think that pulling from many repos would
entail merges. Suffice to say you can forget this; it is not the
case in DVCS. Merges in DVCS are always between two commits, and
git at least will insist on a clean working copy before it will
attempt a merge.

Anyway, I got sidetracked a bit, if necessarily so. The point is,
if multiple developers have multiple published repositories, this
won’t pose any technical problem to setting up smoke testing for
them all. The only question is, as it should be, social: how much
coordinational overhead is incurred and whether the smokemasters
care to take it on.

In the case of Perl 5 I don’t see a huge number of active
pumpkin branches happening, so it does not seem like it should
become a significant burden to set up a smoker to test them all,
and it seems like would in fact be very beneficial if we had
smokers scrutizing stuff like Schwern’s y2038 branch long before
it’s merged into any mainline branch.

Regards,

That *is* the syntax I suggested. :-) Your example just doesn’t
include a user name, which of course is fine if ssh DTRT in that
regard.

> > Next, git-pull is actually git-fetch (which downloads commits
> > you are missing) *plus* git-merge. Because of the latter, you
> > have to say which branch you want to merge. And since
> > git-pull is used to merge changes from a remote branch, and
> > you can have several remotes configured (it's a DVCS!), you
> > also have to specify which remote, to make it unambiguous. So
> > based on the above you'd say
>
> Only if the current workin branch doesnt have a remote defined
> for it. In which case 'git pull' will work fine.

Ah. I guess in the few cases where I’ve used it, I set up my
branch in a way that doesn’t do that automatically, so I didn’t
know that it would.

> > If you have push access to all of your remotes, and you want
> > to push to all, you can also pass `--all` instead of a
> > particular remote.
>
> Huh? --all is documented as pushing all refs to the remote
> specified. Not pushing to all remotes. Have i missed a trick
> here?

Woops, you are right.

> Hrm, I didnt know that you could define multiple urls for a
> single remote. That seems a bit strange to me.

Strange maybe, but extremely useful! Makes it very easy to deal
with multiple repos that you _publish_ to (vs the ones you
actually muck around in), or even multiple sets of them (if your
workflow is so defined).

Regards,

Don’t see why not. Smokers can pull from multiple remotes into
a single mirror repo as easily as they can pull from a single
remote; no waste of bandwidth or jumbling of history.

That’s what the D in DVCS is all about.

Regards,

Roughly. But wrong on a lot of details. The remote needs a name,
and the syntax for SSH-based remotes is not URLish, but SSHish:

    git remote add origin nick@perl5.git.perl.org:perl.git

Next, git-pull is actually git-fetch (which downloads commits you
are missing) *plus* git-merge. Because of the latter, you have to
say which branch you want to merge. And since git-pull is used to
merge changes from a remote branch, and you can have several
remotes configured (it’s a DVCS!), you also have to specify which
remote, to make it unambiguous. So based on the above you’d say

    git pull origin master # or some other branch

Or you can say just

    git fetch

in which case you’ll merely slurp in all the new stuff from all
your remotes without merging any of them to your current branch
yet. The above git-pull command is equivalent to this sequence:

    git fetch origin
    git merge origin/master

If you do a git-fetch instead of a git-pull, you can do things
like

    git log ..origin

to see what’s happened in `public` without merging it yet.

Next, git-push defaults to pushing to `origin`. If your remote is
called something else (I usually set up my published repo as a
remote called `public`), you have to specify it:

    git push public

If you have push access to all of your remotes, and you want to
push to all, you can also pass `--all` instead of a particular
remote. (But you can also set up several URLs for the same remote
by editing `.git/config`, which gives you more granular choices
and seems like better option to me: I add the URLs of all public
repos to my `public` remote so they’re always pushed all at once.)

Regards,

* David Golden <xdaveg@gmail.com> [2008-11-14 04:10]:
> Since the whole idea of "authoritative" is a bit loose in
> git anyway, I'd be supportive of using them as the "official
> mirror".

I don’t know why we couldn’t declare them both equally
authoritative as long as synching is set up so all official
repositories either stay perfectly in sync, or at least very
closely. That shouldn’t be hard to do with post-commit hooks,
and github provides a way to set one up.

Regards,

* Erwan Lemonnier <erwan@lemonnier.se> [2008-11-06 08:35]:
> Well, ideas? suggestions?

Uhm, you know about subroutine attributes? See perlsub and
Attribute::Handlers.

Regards,

* Matt S Trout <matt-p5p@trout.me.uk> [2008-10-11 17:15]:
> Plus I've often seen code that does $class->VERSION and I'd be
> willing to bet there's some somewhere that won't handle getting
> a version object back.

Question is though, how many of these places will DTRT with the
stringified version? If a version object breaks the code most of
the time and a stringified version DTWT some of the time, all you
can do is pick your kind of breakage, and frankly I’d prefer the
bigger and more reproducible breakage in that case. The real
solution in that case is to fix the code that can’t handle
getting a version object.

Regards,

This is not a bug in perl, it’s a bug in your shebang line. The
fact that this used to work was a bug in perl that has since been
fixed. The correct incantation for what you want to achieve is

    use open qw( :std :encoding(UTF-8) );

Regards,

* J. Shirley <jshirley@gmail.com> [2008-10-06 01:10]:
> Andy apparently just wanted to start a flamewar.

In the comments:

    Oh, FFS. If you didn't use software because you think one or
    several of the contributors were assholes, you'd have to
    write everything from scratch.

    And I rather like ack.

Ice Burn.

Regards,

* Lee Aylward <lee@laylward.com> [2008-10-03 00:40]:
> Assuming that your shared host has all of the required modules
> installed you can use the .cgi script found in the /scripts
> directory of your catalyst application.

That?s going to be extraordinarily slow.

Regards,