{"thread":{"id":"13453","subject":"git-svn: expand svn:keywords, or how else to deal with them?","startedAt":"2008-05-09T10:19:19Z","lastAt":"2008-05-11T10:39:51Z","messageCount":3,"participants":["martin f krafft","Eric Wong"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"76454","messageId":"20080509101919.GA25037@lapse.madduck.net","threadId":"13453","inReplyTo":null,"subject":"git-svn: expand svn:keywords, or how else to deal with them?","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2008-05-09T10:19:19Z","receivedAt":"2008-05-09T10:19:19Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"Hi,\n\nI am using git-svn to track an upstream SVN project, which I then\npackage for Debian. Upstream uses $Id:$ all over the source code,\nbut I am not ready to argue with him that this ought to be removed.\n\nThe problem is that I build the Debian packages out of the git-svn\ntree, but use the published tarball. The latter has $Id:$ expanded\nin all files, while the git-svn tree does not - git-svn does not\nexpand them.\n\nThe result is that my Debianisation diff now reverts the expansion\nfor every single file. This is quite ugly.\n\nI realise there are ways to prevent this, but I think that the\ncleanest would be if git-svn could be taught to expand svn:keywords.\n\nIs this something you could live with, Eric? I am willing to have\na go at the patch, but my Perl-foo is crap, so I may well fail...\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \n\"a mathematician is a device for turning coffee into theorems.\"\n                                                         -- paul erdös\n \nspamtraps: madduck.bogus@madduck.net\n"},{"id":"76593","messageId":"20080511084558.GC23929@untitled","threadId":"13453","inReplyTo":"20080509101919.GA25037@lapse.madduck.net","subject":"Re: git-svn: expand svn:keywords, or how else to deal with them?","fromName":"Eric Wong","fromEmail":"normalperson@yhbt.net","sentAt":"2008-05-11T08:45:58Z","receivedAt":"2008-05-11T08:45:58Z","isPatch":false,"sender":{"key":"e@80x24.org","avatar":null},"body":"martin f krafft <madduck@madduck.net> wrote:\n> Hi,\n> \n> I am using git-svn to track an upstream SVN project, which I then\n> package for Debian. Upstream uses $Id:$ all over the source code,\n> but I am not ready to argue with him that this ought to be removed.\n> \n> The problem is that I build the Debian packages out of the git-svn\n> tree, but use the published tarball. The latter has $Id:$ expanded\n> in all files, while the git-svn tree does not - git-svn does not\n> expand them.\n> \n> The result is that my Debianisation diff now reverts the expansion\n> for every single file. This is quite ugly.\n> \n> I realise there are ways to prevent this, but I think that the\n> cleanest would be if git-svn could be taught to expand svn:keywords.\n\n*shudder*\n\n> Is this something you could live with, Eric? I am willing to have\n> a go at the patch, but my Perl-foo is crap, so I may well fail...\n\nI'll accept a patch for it only if it's optional :)  Just the thought of\nhaving to do keyword (un)expansion in git-svn is scary; so I'm not\nwilling to do it myself.\n\nI'm mainly uncomfortable with how it'll interact with dcommit usage, but\nsince your use case seems to be fetch-only; you may just disable dcommit\nif keyword expansion is enabled if it's too painful to figure out the\nunexpansion...\n\n-- \nEric Wong\n"},{"id":"76597","messageId":"20080511103951.GA30508@lapse.madduck.net","threadId":"13453","inReplyTo":"20080511084558.GC23929@untitled","subject":"Re: git-svn: expand svn:keywords, or how else to deal with them?","fromName":"martin f krafft","fromEmail":"madduck@madduck.net","sentAt":"2008-05-11T10:39:51Z","receivedAt":"2008-05-11T10:39:51Z","isPatch":false,"sender":{"key":"madduck@madduck.net","avatar":null},"body":"also sprach Eric Wong <normalperson@yhbt.net> [2008.05.11.0945 +0100]:\n> I'm mainly uncomfortable with how it'll interact with dcommit\n> usage, but since your use case seems to be fetch-only; you may\n> just disable dcommit if keyword expansion is enabled if it's too\n> painful to figure out the unexpansion...\n\nUnfortunately, it's not fetch-only, I have commit rights upstream\nand I use them quite often.\n\nI understand your reasoning and am not too keen on implementing this\nhack either. However, the other ways of dealing with it are\nhorrific. Right now, for each release, I have to do:\n\n  git checkout -b build-$VERSION\n  # undo all changes, basically get pristine upstream\n  zcat ../mypkg_1.0-1.diff.gz | git apply -R\n  # reapply all my Debian changes\n  git diff upstream debian | git apply\n  git commit ...\n\nthis gets unmanageable when I am using more than just the debian\nbranch, but also feature branches, e.g. debian/fhs-compatibility\netc...\n\nYou wouldn't happen to have a better idea of how to deal with this?\n:)\n\n-- \nmartin | http://madduck.net/ | http://two.sentenc.es/\n \ndon't hate yourself in the morning -- sleep till noon.\n \nspamtraps: madduck.bogus@madduck.net\n"}]}