From: Clark Williams <clark.williams@gmail.com>
To: "Karl Hasselström" <kha@treskal.com>
Cc: git@vger.kernel.org
Subject: Re: [StGit PATCH] add option to import series directly from a tar archive
Date: Mon, 08 Sep 2008 13:11:37 -0500 [thread overview]
Message-ID: <48C56AD9.6040007@gmail.com> (raw)
In-Reply-To: <20080908180317.GA6123@diana.vm.bytemark.co.uk>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Karl Hasselström wrote:
> On 2008-09-06 22:47:19 -0500, Clark Williams wrote:
>
>> Attached is my first cut at adding the ability to import a patch
>> series by specifying the tarball.
>
> Thanks!
>
>> No Karl, I haven't developed a test for it (yet). I wanted to see
>> what you guys thought first :)
>
> I don't see a problem with it, and if you took the time to code it
> there is obviously at least one user (I have no idea how common patch
> series tarballs are). I do have some comments below, but nothing that
> would prevent you from writing a test or two right away. ;-)
>
Patch series tarballs are quite common from people who use quilt (e.g. many of the
kernel -rt series developers). My biggest problem (now that I can directly import
them) is to see if I can ease StGit's patch import rules a bit, since quilt accepts
pretty much anything as long as there's a diff in there somewhere. I bomb out
regularly importing the -rt series using StGit, because some people don't put
complete email addresses in their patches.
As to the test, I'll get right on that...:)
>> + make_option('--tarfile',
>> + help = 'import a series from a tar archive',
>> + action = "store_true"),
>
> As I hint below, you might want to autodetect tarballs with --series
> instead, since a tarball is just a tarred series directory.
Yeah I thought about that, as well as auto-detecting it in the file case. I'll look
into that a bit more.
>
>> + if n.startswith("../"):
>> + raise CmdException, "Relative path found in %s" % tar
>
> I guess any occurrence of /../ in the middle of n should be caught as
> well? Or can't that happen?
>
Hence the "would you guys look at this?". Yeah, I need to detect sneaky stuff like
that too.
> By the way, is the separator always '/' in tarfile? Or should you use
> os.sep? (There is also os.pardir which you could use instead of '..',
> but that might be overdoing it a little ...)
I doubt there are many Windows-generated tarballs out there (except for the Cygwin
case; I believe they use '/'), but I shouldn't be so Unix-centric. I'll work on
cleaning it up.
I did consider adding Zipfile support as well, but didn't get a very good match-up
between tar functionality and zip functionality. Maybe later...
>
>> + raise CmdException, "no series file found in %s" % tar
>
> Perhaps "no 'series' file ...", to make it clear what the name should
> be?
>
Yeah, that makes sense.
>> + # unpack into a tmp dir
>> + tmpdir = tempfile.mkdtemp('.stg')
>> + t.extractall(tmpdir)
>> +
>> + # apply the series
>> + __import_series(os.path.join(tmpdir, seriesfile), options)
>
> Hmm. It seems like such a waste to go via the file system here, when
> tarfile has such nice file extraction methods.
>
> What you could do is something like this:
>
> 1. Make two small classes with the same interface, one backed by a
> tarfile and one backed by a directory, that have two methods:
> get_series() and get_file(filename). Both methods return
> file-like objects (created by either open() or
> tarfile.extractfile()).
>
> 2. Change __import_series() to use objects of this class rather than
> a directory directly -- starting with creating an instance of one
> or the other depending on tarfile.is_tarfile(). This will involve
> teaching __import_file to accept a file-like object instead of
> just a file name, but that's a one-liner.
>
> 3. Drop the --tarfile flag, since you've just taught the --series
> flag to handle tarballs!
>
> That said, if you don't feel like doing it the hard way, I won't
> insist. The way you coded it is in no way bad (in particular, you
> chose the right function to create a temp dir).
I did consider pulling directly from the tarball. I'll look into it.
>
>> + # cleanup the tmpdir
>> + os.system('rm -rf %s' % tmpdir)
>
> Aaah! My eyes! My _eyes_!!!!!
>
> Seriously, though, you'd want to use something like shutil.rmtree
> here.
>
Man, I could not for the life of me remember which module had that in it. To be fair
I wasn't up at work with my Python Essential Reference, which would have pointed me
directly at it, but I would have thought I could have gotten there through the Python
docs. Sigh...
You can dock my StGit pay for the visit to the eye doctor :)
Clark
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Fedora - http://enigmail.mozdev.org
iEYEARECAAYFAkjFatgACgkQqA4JVb61b9fMRQCeLfK0zhPNEq3t5M4HW+vbRtaG
VhgAn0rtszqVLbd1bz12MS0b/3r0OkT2
=gkf1
-----END PGP SIGNATURE-----
next prev parent reply other threads:[~2008-09-08 18:12 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-09-07 3:47 [StGit PATCH] add option to import series directly from a tar archive Clark Williams
2008-09-08 18:03 ` Karl Hasselström
2008-09-08 18:11 ` Clark Williams [this message]
2008-09-08 21:22 ` Karl Hasselström
2008-09-12 12:21 ` Samuel Tardieu
2008-09-12 12:57 ` Clark Williams
2008-09-12 13:59 ` Samuel Tardieu
2008-09-12 15:44 ` Karl Hasselström
2008-09-12 13:07 ` Karl Hasselström
2008-09-12 13:08 ` Karl Hasselström
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=48C56AD9.6040007@gmail.com \
--to=clark.williams@gmail.com \
--cc=git@vger.kernel.org \
--cc=kha@treskal.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).