Re: git workflow (was Re: git?)

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,