develooper Front page | perl.perl5.porters | Postings from November 2008

Re: git workflow (was Re: git?)

Thread Previous | Thread Next
November 16, 2008 06:48
Re: git workflow (was Re: git?)
Message ID:
2008/11/16 Aristotle Pagaltzis <>:
> * Nicholas Clark <> [2008-11-15 17:30]:
>> On Sat, Nov 15, 2008 at 02:45:32PM +0100, Aristotle Pagaltzis wrote:
>> > 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.
>> Sure, and that strikes me as a recipe for chaos.
>> We'll get a smoke report, and then we have to work out which
>> merge of upstreams went into the source.
> No no no. I said nothing about merging.

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:

for r in $(git remote); do git pull $r; done

Wheras you really meant:

git remote update

or its equivalent:

for r in $(git remote); do git fetch $r; done;

> 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.

As i say above I suspect its because you say "pulling", which does
implying merging, at least to someone who already uses git.

If you had said fetching or remote updating then I suspect that
implication wouldnt have been made. :-)

>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.


perl -Mre=debug -e "/just|another|perl|hacker/"

Thread Previous | Thread Next Perl Programming lists via nntp and http.
Comments to Ask Bjørn Hansen at | Group listing | About