package: git-dpm
version: 0.8.5-1

I'm packaging software that uses the ident tag in .gitattributes in the
upstream git directory.
Basically all the files in the tree have a $Id$ tag.
Why, I don't know; I thought we all learned we hated that back in the
bad old days of cvs.


Unfortunately this produces really unfortunate results with patches.
Attached is an example of the uunrepresented changes in a package I'm
working on:


I'm not quite sure how git dpm update-patches generates patches but it
manages to capture the patches with the old blob IDrather than with the
blob ID that results from  the merged content.

So, dpkg-source claims there are unrepresented upstream changes in the
form of all the blob id updates for all the files patched by git dpm.

to deal with this I think you need to generate diffs in a manner similar
to how git merge --renormalize would do its job.

---
The information above should follow the Patch Tagging Guidelines, please
checkout http://dep.debian.net/deps/dep3/ to learn about the format. Here
are templates for supplementary fields that you might want to add:

Origin: <vendor|upstream|other>, <url of original patch>
Bug: <url in upstream bugtracker>
Bug-Debian: http://bugs.debian.org/<bugnumber>
Bug-Ubuntu: https://launchpad.net/bugs/<bugnumber>
Forwarded: <no|not-needed|url proving that it has been forwarded>
Reviewed-By: <name and email of someone who approved the patch>
Last-Update: <YYYY-MM-DD>

--- freeradius-2.2.5+dfsg.orig/Make.inc.in
+++ freeradius-2.2.5+dfsg/Make.inc.in
@@ -1,7 +1,7 @@
 # -*- makefile -*-
 # Make.inc.in
 #
-# Version:	$Id: 5464b2e0e75bdfe1c8b1acfb0491b3e82c74e557 $
+# Version:	$Id: d3ade3b17314bead1763290a90749673092cf7e6 $
 #

 # Location of files.
--- freeradius-2.2.5+dfsg.orig/raddb/eap.conf
+++ freeradius-2.2.5+dfsg/raddb/eap.conf
@@ -2,7 +2,7 @@
 ##
 ##  eap.conf -- Configuration for EAP types (PEAP, TTLS, etc.)
 ##
-##	$Id: 95bebe4d25ef13871fb201ba540ed008078dab07 $
+##	$Id: 4157e09820bcb6c00cfe7f36cf9ca4f15860a6f9 $

 #######################################################################
 #
--- freeradius-2.2.5+dfsg.orig/raddb/radiusd.conf.in
+++ freeradius-2.2.5+dfsg/raddb/radiusd.conf.in
@@ -3,7 +3,7 @@
 ## radiusd.conf	-- FreeRADIUS server configuration file.
 ##
 ##	http://www.freeradius.org/
-##	$Id: 201b70b31b5bb4c2ef98c102690daa3462d5e1e3 $
+##	$Id: 39a19410e81ae0f833e01ddc09c08c80860e47eb $
 ##

 ######################################################################
--- freeradius-2.2.5+dfsg.orig/src/main/conffile.c
+++ freeradius-2.2.5+dfsg/src/main/conffile.c
@@ -5,7 +5,7 @@
  *		write a decent parser. I know how to do that, really :)
  *		miquels@cistron.nl
  *
- * Version:	$Id: bd993e3701f73a070ef1efb9ee8afbf1d9a7f6ad $
+ * Version:	$Id: d0c1b3a9bac26966dd591a587b82f0564c5af147 $
  *
  *   This program is free software; you can redistribute it and/or modify
  *   it under the terms of the GNU General Public License as published by
@@ -27,7 +27,7 @@
  */

 #include <freeradius-devel/ident.h>
-RCSID("$Id: bd993e3701f73a070ef1efb9ee8afbf1d9a7f6ad $")
+RCSID("$Id: d0c1b3a9bac26966dd591a587b82f0564c5af147 $")

 #include <freeradius-devel/radiusd.h>
 #include <freeradius-devel/rad_assert.h>
--- freeradius-2.2.5+dfsg.orig/src/modules/rlm_sql_log/Makefile
+++ freeradius-2.2.5+dfsg/src/modules/rlm_sql_log/Makefile
@@ -1,7 +1,7 @@
 #
 # Makefile
 #
-# Version:	$Id: e09feda643e1eb51fa72d5e782225d66c6a17b7e $
+# Version:	$Id: cfda9e720eb35eaa0481afa2ddfd5a71cf5cfad3 $
 #

 TARGET      = rlm_sql_log
--- freeradius-2.2.5+dfsg.orig/src/modules/rlm_sqlcounter/Makefile.in
+++ freeradius-2.2.5+dfsg/src/modules/rlm_sqlcounter/Makefile.in
@@ -1,5 +1,5 @@
 #
-# $Id: bd853f0810544d0ff2e66ebb5559fc3b53c19e9e $
+# $Id: dc57c7c169cd71b046387491c74aa0b42d651ad6 $
 #

 TARGET      = @targetname@
--- freeradius-2.2.5+dfsg.orig/src/modules/rlm_sqlippool/Makefile.in
+++ freeradius-2.2.5+dfsg/src/modules/rlm_sqlippool/Makefile.in
@@ -1,5 +1,5 @@
 #
-# $Id: af28710f09ff162000a5142f96faa471c83aa005 $
+# $Id: 3aa52c088e1b49631d0aa696450da1899e50ba91 $
 #

 INCLUDE += -I/usr/local/include/

* Sam Hartman <hartmans@debian.org> [141001 03:33]:

This is quite an ugly problem. git-dpm just uses git-format-patch and
that as far as I see it has no way to generate the proper patches.

Even worse removing the .gitattribute file usually does not help either,
as it caused git to put something different in the internal storage than
what the file actual has (so removing the .gitattribute will make git
claim the content of the file changed).

The only way I see around this is importing a tarball of the sources
on top of it (for example using git-dpm import-new-upstream).
If the tarball contains the .gitattribute even that will
not help without the new --exclude option added it git-dpm 0.9.

	Bernhard R. Link

I've been working with this a bit more.  One possibility would be to add
an export option or some git dpm option to generate a dsc or a tree that
could be used to generate a dsc.  At that point you could either add the
changes as a final patch or unapply them.  What I'm doing now is running
dpkg-source -b by hand rather than git-buildpackage.  I then
reverse-apply dpkg-source's generated diff of extra changes manully to
the working tree, then dpkg-source again which succeeds.

Even with dpkg-source --single-debian-patch dpkg-source does not succeed
because  git-dpm generates a patches-applied tree without a .pc
directory.

Another way to make this situation better would be to have an option to
generate a .pc tree that quilt would be happy with from a git-dpm tree
and then git-buildpackage or dpkg-source could be convinced to generate
the useless patch on their own.

* Sam Hartman <hartmans@debian.org> [141109 19:15]:

Being able to just call dpkg-buildpackage in a checkout of the git
repository with needing to call git-dpm at all is quite an import
feature of git-dpm for me. Besides: how would that help if the problem
is that the patches generated do not fit the files?

I think there are only two posibilities:
- not using git-format-patch. Perhaps needed in the long term anyway
  to get nicer patch headers. But then I'm not sure that can be easily
  fixed using any other invocation of git's diff machinery (and not
  running in other problems on the way). And using non-git diff on trees
  exported with git to generate the patches sounds like no nice way to
  be heading.
- fix the information in git. I fear in the end the only feasible
  solution is to document that one needs to do an git-dpm
  import-new-upstream with --exclude .gitattribute here.

	Bernhard R. Link

    Bernhard> * Sam Hartman <hartmans@debian.org> [141109 19:15]:
    >> I've been working with this a bit more.  One possibility would be
    >> to add an export option or some git dpm option to generate a dsc
    >> or a tree that could be used to generate a dsc.  At that point
    >> you could either add the changes as a final patch or unapply
    >> them.

    Bernhard> Being able to just call dpkg-buildpackage in a checkout of
    Bernhard> the git repository with needing to call git-dpm at all is
    Bernhard> quite an import feature of git-dpm for me. Besides: how
    Bernhard> would that help if the problem is that the patches
    Bernhard> generated do not fit the files?

Well, that's a nice feature when you can get it, but I've run across two
cases where it just doesn't do what you want:

* I want to manipulate the results with quilt

* This gitattribute case.

so, yeah, I think that maintaining support for git-buildpackage to
export a tree whereever possible is really important.
I think that adding an export that would:

* take the upstream sources
* drop in the debian directory
 * quilt push -a (or just leave an unapplied tree)

would be valuable for a number of use cases.