On Thu, Aug 30, 2007 at 09:25:33PM +0200, martin f krafft wrote:
quoted text
> So I clone upstream and find that git-branch -r includes
> upstream/master (s/origin/upstream/ for clarity). I then branch
> 'debian' off upstream/master and make some required changes. With
> utter enjoyment of git, I wrap it up and package a new mdadm.deb.
> Yay.
> 
> And then I wonder: how do I now publish this result of my work? I'd
> like to push my repository to git.debian.org so that others can
> clone it and help or submit patches against the debianised upstream.

So in the setup you describe if they clone your repo then they'll get a
single branch called 'debian' with your work in it.  That sounds fine to
me, actually.

quoted text
> But the remote branch upstream/master only really exists in
> $GIT_DIR, which is local and can't be pushed. Or well, even if
> I tried, the people cloning from the push location wouldn't see it

They can always just fetch from upstream as well if they'd like.  They
could do something like:

	git clone git://coolproject.org/cool.git
	cd cool
	git remote add debian git://git.debian.org/cool.git
	git fetch debian

Then they have a repository where git-branch -r reports something like

	origin/master
	debian/debian

Or they could do it the other way around, with "origin" pointing to you
and an "upstream" remote pointing to coolproject.org.  The naming's
obviously up to them.

quoted text
> 1. I could tell my $GIT_DIR/config that upstream/* comes from mdadm
> upstream and debian/* comes from git.debian.org and then merge
> happily across branches locally and be done with it. However, John
> Doe, who on a rainy Saturday afternoon has two hours to spend and
> wants to fix some mdadm bugs would have to jump through hoops to
> replicate the setup: all the ties between upstream and the
> git.debian.org repo are local to my machine and can't be pushed
> anywhere (except to verbose documentation).

Maybe the one extra "git remote add ...; git remote fetch" isn't such a
big deal?

quoted text
> I guess the cleanest solution I can come up with is to branch off
> upstream/master into branch "upstream" whenever *I* decide it's time
> to snapshot. Then, people using my repo would basically be confined
> to the state of the tree as it was the last time I rebased
> "upstream", but could work freely on the Debian-specific stuff.
> I think this is actually quite okay, but I am still interested in
> any comments you may have.

Sure, you can do that.  I don't think it's really necessary.

My local kernel repository, for example, currently knows about five
other repos:

	$ git remote
	labiaga		# server pnfs work
	linux-nfs	# my public repo
	origin		# Linus's repo
	richterd	# a coworker's nfs work
	trond		# Trond's nfs stuff

Sure, each of those could add a "linus" branch that tracked upstream, so
I could still get some idea what Linus's tree was even if I didn't
happen to already have it.  But then I'd end up with 4 different
slightly-out-of-date pointers to the head of linus's repo in each of
those trees, which would end up being just be a bunch of cruft that I'd
have to ignore whenever I looked at them.

--b.
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html