Vendor branches workflow

Vendor branches workflow

[Leonid Podolny]

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).

Re: Vendor branches workflow

[Jonathan Nieder]

Hi Leonid,

Leonid Podolny wrote:

> 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.

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

Re: Vendor branches workflow

[Neal Kreitzinger]

"Leonid Podolny" <leonidp.lists@gmail.com> wrote in message 
news:AANLkTi=s9p3RycRCrocHEzfc4L-pnU6S9xCKfEL7TP=i@mail.gmail.com...
> 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).

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

v/r,
Neal