Re: More git policy: xsfbs and bundled apps packages
> On Wed, Jan 10, 2007 at 04:31:07PM +1100, Drew Parsons wrote:
> > > The apps are fairly easy. We use the upstream* branches and just extend
> > > it so we have individual upstream* branches for each upstream app repo.
> > > These all get merged in to debian as the need arises.
> > Is it as simple as that? The upstream apps are all separate repos, but
> > for our convenience we've collected them into single packages, for
> > instance xbase-clients (also xprint-utils and xutils). So we'd want
> > xbase-clients managed as only one repo, at least as far as the debian*
> > branches go, which conflicts with all the individual upstream* branches...
> We should be able to. You can test it yourself. Make a temporary repo with
> a file "a" in it. Once this is checked in, make a second branch with a file
> "b". Then go back to the master branch and make a third branch with a file
> "c". Your layout will be like this then:
> branch files
> ----- -----
> master a
> second a b
> third a c
> Then you can go back to master and pull second and third in independantly.
> You'll end up with master having files a, b, and c. This is pretty much the
> model for these packages. Since the second and third branches are unaware
> of each others individual files, they don't get deleted when their changes
> are pulled in to the master branch.
> > Does it have a concept of "subrepos" where a subdirectory pulls from a
> > different repo? I presume not otherwise this would have solved the
> > xsfbs problem.)...
> Git doesn't have the concept of subrepos unfortunately. It'd be nice, but
> this method should make it work. And we wouldn't have to change our
> packaging or anything.
OK, that seems to work for merging directories, although as Michel
pointed out it's not quite the same thing as our arrangement for apps,
where starting with
we would want pull/merge to turn master into
Without a way of shifting directories like this in git, I can't see the
solution to this question.
On the other hand, doesn't this solve the xsfbs sharing problem? xsfbs
can have its own repo, with the files in debian/xsfbs. Then any of our
packages can git-pull that repo to get their own debian/xsfbs copy
updated. The only difference is that this git-pull won't happen
automatically the way it did with svn (or can a hook be created to do so?).