lkml.org 
[lkml]   [2002]   [Feb]   [9]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [bk patch] Make cardbus compile in -pre4
On Feb 08, 2002  23:02 -0500, Jeff Garzik wrote:
> Andreas Dilger wrote:
> > I don't see why everyone who is using BK is expecting Linus to do a pull.
> > In the non-BK case, wasn't it always a "push" model, and Linus would not
> > "pull" from URLs and such? Why are people not simply doing:
> >
> > !bk send -r+ (other options) -
> >
> > from within their editor (or equivalent) to inline the CSET in the email?
> > This has the added advantage that other people reading the email can also
> > import the CSET immediately if they so desire.
>
> 'bk pull' is probably most useful to high volume submitters, where the
> contents of most patches is either obvious and/or uninteresting.

The problem is that (AFAIK) bk pull does not let Linus pick-and-choose
which patches he wants to accept as easily as importing them at the time
he reads each email. It basically assumes that he wants everything that
is in the repository he is pulling from.

> 'bk send -d -r<rev> -' should be fine for importing.

Yes, that would be my thought as well. Sadly, running the command

bk send -d -r+ -wgzip_uu -

does not work as I would _hope_ it would, namely putting a regular context
diff at the beginning of the email, and gzip_uu for only the CSET. That
would give us the best of both worlds, namely a diff to look at (which
most people can read easily), and the compressed CSET for people who
have BK.
I suppose it is possible to do exactly what I want by running both:

bk changes -r<rev> # generates Changelog
bk export -tpatch -h -du -r<rev> # generates context diff
bk send -wgzip_uu -r<rev> - # generates gzipped/uuencoded CSET

This has the added benefit that 'bk export' does not contain changes to
the BK files themselves, only the real changes.

I have no idea if this would confuse BK if you tried to recieve from
a file which had both of these in it...

> But this is still a trial run of BK, so who knows what will wind up to
> be the best policy for casual submitters.
>
> And there's nothing wrong at all with sending GNU patches...

Oh, I agree that for people without BK they can keep sending patches.
I would prefer that people who _do_ have BK to send the CSET along with
the patch to the mailing list so that you don't have to go hunting for a
specific CSET, or if you can't because you are not currently connected.

This might also be possible if BK could export/import a whole changeset
in patch form, plus some magic stuff at the beginning/end (gzip_uu) which
had all of the BK metadata in it, but I don't know if that is possible or
desirable.

Cheers, Andreas
--
Andreas Dilger
http://sourceforge.net/projects/ext2resize/
http://www-mddsp.enel.ucalgary.ca/People/adilger/

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

\
 
 \ /
  Last update: 2005-03-22 13:24    [from the cache]
©2003-2011 Jasper Spaans