emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Looming colocation [Was: Git mirrors]


From: Barry Warsaw
Subject: Re: Looming colocation [Was: Git mirrors]
Date: Mon, 17 Oct 2011 15:04:23 -0400

On Oct 18, 2011, at 01:59 AM, Stephen J. Turnbull wrote:

>"loom" is an established but not so widely-used bzr plugin.  It allows
>you to create a stack of groups of provisional changes which are
>version-controlled (and so can be pulled into another branch; I think
>push is inhibited for the same kinds of reasons that people prefer to
>require that push be a fast-forward, but I'm not sure).

You can definitely push looms to Launchpad, and anyone else can pull them from
Launchpad as long as they also have the loom plugin installed.

>Maybe Barry Warsaw will chime in, as I know he loves loom, and I've
>never fully understood it or used it in anger.

I think you got it pretty much right, but also see my other followup.

FWIW, I used looms a lot when I was working on Launchpad because there feature
work can sometimes be pretty complex, often touching multiple layers of the
system.  I prefer to work on such layers independently, precisely as you
describe.  A great use case for this is where different layers need to be code
reviewed by different experts.  E.g. you wouldn't want to mix UI changes into
database schema diffs.

For simpler code bases, looms tend not to be that useful (but no harm in
leaving the plugin sit around).  Sometimes I'll use looms when merging in
other people's work to Mailman 3 because it lets me keep my own integration
work above and below their branch separated.  I'll also use them in cases like
you describe, where a particular new feature requires some prerequisite
refactoring work that would ordinarily clutter up the real meat of your
current changes.

-Barry

Attachment: signature.asc
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]