Re: Let's talk about git management

[Stefan Fritsch <sf@sfritsch.de>]

Hi,

let's try to make a plan how to proceed with git.

On Saturday 19 November 2011, Sandro Tosi wrote:
> > Is it
> > necessary to import the complete upstream source with git?
> 
> Following the usual workflow, yes, it should be imported the whole
> tarball inside the repository (in a separate branch than the debian
> stuff), usually also adding the pristine-tar diff (used to
> regenerate the pristine tarball downloaded from upstream code).
> 
> > Though it may
> > actually be a good idea, because we frequently have to backport
> > commits from upstream's 2.2.x branch.
> 
> I can see your reasoning here, but there are a couple of problems:
> 
> - it would make quite a lot of sense if the upstream repository was
> also git, but AFAIK apache httpd project is still on svn. you can
> use svn-git but is it really worth?

As pointed out elsewhere, there is a public git export. But I am not 
sure we want to import that into the debian repo (the .git dir is 
about 80MB). But it would be very nice if one could (locally) add it 
as git remote and use git diff/cherry-pick/etc. seamlessly.

> - if  you want to backport a patch, I think the best way from a
> packaging POV is to add a patch do debian/patches, and not simply
> take the patch from upstream repository and "merge" with the code.
> Having a separate patch will easy its removal when we'll package
> the version the patch was taken from, and clearly mark the
> differences we've made from the upstream version (and also why we
> did that).

I have (superficially) read a bit about git-buildpackage. It seems its 
patch-queue branches do what I want: Switch to the patch-queue branch, 
cherry-pick a commit from upstream, and then export the commit into 
the debian/patches dir of the main branch. The main branch would then 
simply be the debian source package with un-applied debian/patches 
dir. Do you think that would work?

Or would you prefer a different workflow/layout?

Cheers,
Stefan