git-svn: expand svn:keywords, or how else to deal with them?

git-svn: expand svn:keywords, or how else to deal with them?

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1057 bytes --]

Hi,

I am using git-svn to track an upstream SVN project, which I then
package for Debian. Upstream uses $Id:$ all over the source code,
but I am not ready to argue with him that this ought to be removed.

The problem is that I build the Debian packages out of the git-svn
tree, but use the published tarball. The latter has $Id:$ expanded
in all files, while the git-svn tree does not - git-svn does not
expand them.

The result is that my Debianisation diff now reverts the expansion
for every single file. This is quite ugly.

I realise there are ways to prevent this, but I think that the
cleanest would be if git-svn could be taught to expand svn:keywords.

Is this something you could live with, Eric? I am willing to have
a go at the patch, but my Perl-foo is crap, so I may well fail...

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
"a mathematician is a device for turning coffee into theorems."
                                                         -- paul erdös
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]

Re: git-svn: expand svn:keywords, or how else to deal with them?

[Eric Wong]

martin f krafft <madduck@madduck.net> wrote:
> Hi,
> 
> I am using git-svn to track an upstream SVN project, which I then
> package for Debian. Upstream uses $Id:$ all over the source code,
> but I am not ready to argue with him that this ought to be removed.
> 
> The problem is that I build the Debian packages out of the git-svn
> tree, but use the published tarball. The latter has $Id:$ expanded
> in all files, while the git-svn tree does not - git-svn does not
> expand them.
> 
> The result is that my Debianisation diff now reverts the expansion
> for every single file. This is quite ugly.
> 
> I realise there are ways to prevent this, but I think that the
> cleanest would be if git-svn could be taught to expand svn:keywords.

*shudder*

> Is this something you could live with, Eric? I am willing to have
> a go at the patch, but my Perl-foo is crap, so I may well fail...

I'll accept a patch for it only if it's optional :)  Just the thought of
having to do keyword (un)expansion in git-svn is scary; so I'm not
willing to do it myself.

I'm mainly uncomfortable with how it'll interact with dcommit usage, but
since your use case seems to be fetch-only; you may just disable dcommit
if keyword expansion is enabled if it's too painful to figure out the
unexpansion...

-- 
Eric Wong

Re: git-svn: expand svn:keywords, or how else to deal with them?

[martin f krafft]

[-- Attachment #1: Type: text/plain, Size: 1209 bytes --]

also sprach Eric Wong <normalperson@yhbt.net> [2008.05.11.0945 +0100]:
> I'm mainly uncomfortable with how it'll interact with dcommit
> usage, but since your use case seems to be fetch-only; you may
> just disable dcommit if keyword expansion is enabled if it's too
> painful to figure out the unexpansion...

Unfortunately, it's not fetch-only, I have commit rights upstream
and I use them quite often.

I understand your reasoning and am not too keen on implementing this
hack either. However, the other ways of dealing with it are
horrific. Right now, for each release, I have to do:

  git checkout -b build-$VERSION
  # undo all changes, basically get pristine upstream
  zcat ../mypkg_1.0-1.diff.gz | git apply -R
  # reapply all my Debian changes
  git diff upstream debian | git apply
  git commit ...

this gets unmanageable when I am using more than just the debian
branch, but also feature branches, e.g. debian/fhs-compatibility
etc...

You wouldn't happen to have a better idea of how to deal with this?
:)

-- 
martin | http://madduck.net/ | http://two.sentenc.es/
 
don't hate yourself in the morning -- sleep till noon.
 
spamtraps: madduck.bogus@madduck.net

[-- Attachment #2: Digital signature (see http://martin-krafft.net/gpg/) --]
[-- Type: application/pgp-signature, Size: 189 bytes --]