Git commit for 3.2.2 release?

GNU Radio
1

Hi,

I’m trying to create a patch that applies cleanly onto a 3.2.2
tarball. I would like to maintain my changes in the form of a Git
branch.

I can’t seem to find a commit that matches up with the 3.2.2 release.
The best I’ve been able to do is about 3000 lines of diff, which still
feels quite big. Are the releases made from the
git://gnuradio.org/gnuradio.git repo?

Thanks,

Catalin

2

On Thu, May 20, 2010 at 5:29 PM, Catalin P.
[email protected] wrote:

Hi,

I’m trying to create a patch that applies cleanly onto a 3.2.2
tarball. I would like to maintain my changes in the form of a Git
branch.

I can’t seem to find a commit that matches up with the 3.2.2 release.
The best I’ve been able to do is about 3000 lines of diff, which still
feels quite big. Are the releases made from the
git://gnuradio.org/gnuradio.git repo?

Current releases - upcoming 3.3 - are generated out of the main git
tree. Prior releases - such as 3.2.2 - were created from the former
subversion repository.

For a number of interoperability reasons, not every aspect of the old
subversion repository exists in the git version. Notably, you won’t
find a specific commit that matches up perfectly with 3.2.2 or other
releases because those changes were outside of svn trunk.

For a different reason, I reconstructed the svn release history in git
a few weeks back. The diff should be close to the 3.2.2 tarball. You
may notice that the imported commits aren’t particularly descriptive,
which is one reason not to import them to git.

http://github.com/ttsou/gnuradio-ttsou/tree/releases/3.2

The problem with this approach - or any method dependent on old,
divergent branches - is that there will almost surely be conflicts if
you plan on merging upstream.

Thomas

3

On Fri, May 21, 2010 at 2:01 PM, Thomas T. [email protected] wrote:

http://github.com/ttsou/gnuradio-ttsou/tree/releases/3.2
The best I’ve been able to find in there is 24d0fd9:
http://github.com/ttsou/gnuradio-ttsou/commit/24d0fd908510846254f7317d353506c41daf079c

This seems to have only SVN keywords-related diffs in common files,
but there are a slew of files that are in one and not the other (the
commit’s tree vs 3.2.2 tarball).

I think my best bet at the moment is to import a 3.2.2 tarball into my
git repo and rebase on top of that? The reason we’re stuck with 3.2.2
is that there’s already an SRPM out there where we can add our changes
as a distro-level patch.

The problem with this approach - or any method dependent on old,
divergent branches - is that there will almost surely be conflicts if
you plan on merging upstream.
I can’t wait for the 3.3 release! :slight_smile:

4

On Fri, May 21, 2010 at 5:44 PM, Thomas T. [email protected] wrote:

That could work. In either case, unless you’re generating patches
against tarball or repo only code sections, patches should apply to
both version.
Indeed! I’m working off rev eefb51c0c0fac68d16544e492aebd883528607e1
and my patch applies just fine against 3.2.2.

5

On Fri, May 21, 2010 at 2:59 PM, Catalin P.
[email protected] wrote:

On Fri, May 21, 2010 at 2:01 PM, Thomas T. [email protected] wrote:

http://github.com/ttsou/gnuradio-ttsou/tree/releases/3.2
The best I’ve been able to find in there is 24d0fd9:
http://github.com/ttsou/gnuradio-ttsou/commit/24d0fd908510846254f7317d353506c41daf079c

This seems to have only SVN keywords-related diffs in common files,
but there are a slew of files that are in one and not the other (the
commit’s tree vs 3.2.2 tarball).

Yeah you’re right. I only ran the diff against git/svn tracked files.
The git commit and svn tag match, but there are other things going on
with the tarball. Added build files make up part of the unaccounted
changes, generated files another, and additional stuff that I can’t
explain.

I think my best bet at the moment is to import a 3.2.2 tarball into my
git repo and rebase on top of that? The reason we’re stuck with 3.2.2
is that there’s already an SRPM out there where we can add our changes
as a distro-level patch.

That could work. In either case, unless you’re generating patches
against tarball or repo only code sections, patches should apply to
both version.

Thomas