Vendor branches workflow

Hi, list,
I would like an advice on organizing a vendor branch workflow, to
minimize the risk of it biting me in the future.
In our project, we have two upstreams, which are rather massively
patched. One of the upstreams is an SF svn repository, the other
arrives in form of tgz's with sources. Now git is tracking the patched
version, and I want to add a vendor branch to simplify future vendor
drops.
Out of the SVN upstream, we use only specific directories.
So, two questions:
- How do I deal with unneeded directories? Do I filter them out before
commiting to the vendor branch or while merging the vendor branch into
the master?
- Do you think it would be a good idea to keep .svn directories around
at the vendor branch? (Kind of connected to the first question,
because if I keep the .svn's, I will also have to keep the unneeded
dirs).

Hi Leonid,

Leonid Podolny wrote:

If I were in this situation, I would use "git svn" with its ignore-paths option. Like so:

	git svn -Rsvn init --ignore-paths='^(?!directory-a|directory-b)' \
		$url/trunk

This way, using "git svn fetch" causes the history of these files to be fetched, and one can use gitk, git log -S, git bisect, and other familiar tools to browse through it.

Alternatively, a more usual vendor branch workflow (manually committing the relevant files) can work well, too. In either case I would only track the upstream files relevant to the history of my project. A .gitignore file can be useful to avoid accidentally tracking other files (like the .svn metadata).

Hope that helps, Jonathan

"Leonid Podolny" <leonidp.lists@gmail.com> wrote in message news:AANLkTi=s9p3RycRCrocHEzfc4L-pnU6S9xCKfEL7TP=i@mail.gmail.com...

The git-rm manpage explains a methodology for vendor branches. Maybe you've already read it...

v/r, Neal