quilt-dev
[Top][All Lists]
Advanced

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

Re: [Quilt-dev] [patch 0/2] New function: commit


From: Hugo Mills
Subject: Re: [Quilt-dev] [patch 0/2] New function: commit
Date: Sun, 13 Dec 2009 18:15:51 +0000
User-agent: Mutt/1.5.20 (2009-06-14)

On Sun, Dec 13, 2009 at 09:27:48AM -0800, Kurtis Rader wrote:
> I don't have any objections but will point out that this doesn't solve the
> general problem. I've written a wrapper called "q4" so that Quilt can be
> used in conjunction with Perforce. The key feature is that you can associate
> a Quilt patch with a Perforce Changelist (via "q4 patch"). Updates to the
> patch (say, in response to review feedback) are made to the Quilt patch
> which are then propagated to the Perforce CL. When the patch is ready for
> submission you type "q4 submit" which submits the CL and archives the
> corresponding Quilt patch (in $root/patches/archive).
> 
> I don't think it is feasible to solve the general Quilt to other VCS
> interaction problem solely within Quilt. What would help a lot is if there
> were an actual public API that tools like my q4 script could use instead of
> using the Quilt CLI and dealing with the ambiguities it presents.

   This patch would give you the final part of the puzzle, I think. A
commit script would look something like this:


#!/bin/bash
patch_name=$(quilt top)
vcs_create_changelist $patch_name
for file in $(quilt files); do vcs_add_to_changelist $patch_name $file; done
quilt commit -s null $patch_name
quilt header | vcs_commit --message - $patch_name

(Where vcs_create_changelist, vcs_add_to_changelist and vcs_commit are
the relevant commands for your VCS)


   Alternatively, we could consider having VCS modules within quilt,
which are called by "quilt commit". Within the current code, there's
basically four parts to such an interface:

1) enumeration of known VCS types
2) test for presence of VCS metadata
3) ensuring that the VCS knows about all of the files touched in the patch
4) committing a patch

   From what you've said, the association of a patch with a changelist
sounds like it could be done in the third part of this interface. For
svn, the equivalent is simply doing "svn add" on all of the files
touched by the patch.

   Hugo.

> On Sun, Dec 13, 2009 at 04:22, Hugo Mills <address@hidden> wrote:
> 
> >   I think this may have slipped through a crack... any comments?
> >
> >   Hugo.
> >
> > On Thu, Nov 26, 2009 at 08:32:54PM +0000, address@hidden wrote:
> > >    It's useful when using quilt in conjunction with another version
> > > control system to hand off patches from quilt's management to that of
> > > the other VCS. This quilt function provides that capability.
> > >
> > >    Any patch in the stack can be sent to the VCS, provided that no
> > > earlier patch also touches the same files. The commit message is taken
> > > from the quilt patch header. A range of patches can be committed in
> > > sequence, if desired.
> > >
> > >    Only subversion (and a "null", forgetful VCS) are implemented in
> > > this version, although I have left stubs in the code for git and
> > > mercurial. The code attempts to determine automatically which VCS to
> > > use, and will complain (and stop) if none or more than one is found.
> >

-- 
=== Hugo Mills: address@hidden carfax.org.uk | darksatanic.net | lug.org.uk ===
  PGP key: 515C238D from wwwkeys.eu.pgp.net or http://www.carfax.org.uk
          --- Is a diversity twice as good as a university? ---          

Attachment: signature.asc
Description: Digital signature


reply via email to

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