Re: [patch 06/16] diff-test_cmp.patch

From: Gary V. Vaughan <git@mlists.thewrittenword.com>
Date: Apr 28, 2010, 10:22 UTC
Message-ID: <20100428102250.GB39644@thor.il.thewrittenword.com>
In-Reply-To: <20100428095159.GD1394@progeny.tock>

On Wed, Apr 28, 2010 at 04:51:59AM -0500, Jonathan Nieder wrote:

> I think one sign-off for the whole series would be good enough; then
> the person applying the patches can forge your signed-off-by lines.

Okay, done Thanks.

Show 16 quoted lines

> Gary V. Vaughan wrote:
> > (Like SuSE Linux, we use quilt to manage and
> > submit our patch stacks... git seems to require hosting the entire
> > history of each project which is too heavyweight for the 1000's of
> > packages we build - if git provides the means to store just the head
> > of an upstream release branch along with our patch stacks on local
> > disk, I would love to be proven wrong here).
> 
> The most general way:
> 
>  curl http://address/of/tarball.tar.gz | tar -xf - 
>  git init *
>  cd *
>  git add .
>  git commit -m "upstream release"
>  ... use git like normal

D'oh.  Of course... I was too fixated on git clone to notice.

Show 8 quoted lines

> You can automate some of those steps by
> 
>  wget http://address/of/tarball.tar.gz
>  git init project
>  cd project
>  perl /usr/share/doc/git/contrib/fast-import/import-tars.perl tarball.tar.gz
>  git checkout import-tars
>  ... use git as usual

What's happening here? Is this sharing a single repository for all locally hosted git projects, or is this more or less the same as the above?

Show 5 quoted lines

> If upstream uses git, there is also the shallow-clone facility:
> 
>  git clone -b master --depth=1 git://repo.or.cz/git.git/
>  cd git
>  ... use git as usual, except history is cauterized

This is probably the flavour that would be of the most use to us. Thanks for educating me :)

> It has one rough edge you may run into: push is not supported.  If that
> is a problem for you, let me know and maybe I can try to help fix it.

No, I think the main benefit of using git locally would be to provide a pull source for upstream.

> Honestly, I???m okay with quilt, too.  The main difference I notice is that
> ???git diff??? uses the equivalent of the diff -p (--show-c-function)
> option by default.

In /etc/quilt.quiltrc we have:

# Options passed to GNU diff when generating patches QUILT_DIFF_OPTS="--show-c-function"

And I've been careful to regenerate a/b patches for submission to this list, so the only difference then is that you can't pull the patches from me when I use quilt.

Cheers,

-- 
Gary V. Vaughan (gary@thewrittenword.com)