[Git-dpm-user] git-dpm thinks it is working with old upstream.

[Bernhard R. Link]

* Paul Elliott <pelliott at blackpatchpanel.com> [120407 22:08]:
> In the future I will always check debian/.git-dpm after doing a import-new-
> upstream. and do a "git-dpm new-upstream --append" if it does not show the 
> tarball changed.

import-new-upstream should always create the right debian/.git-dpm.
I guess it was right after you run import-new-upstream, which I guess
was Sat Apr 7 01:16:21 2012 -0500 (the commiter and author date
of 72c2d2ea75d56c21b602b0def0cb12761b445c90).
At Sat Apr 7 01:19:54 2012 -0500 there seems to have been the git-dpm
dch recording the new version done (judging from the author time).
But then Sat Apr 7 01:41:08 2012 -0500 the commits
93cb3d76d5d546cdc5394d3220addd2a1e307e97
and a333e312c1569f8adac4f90e045a4ecf3172ff99 were done (commit date),
which (looking at the author timestamps and the commit messages) are
most likely a rebase of 72c2d2ea75d56c21b602b0def0cb12761b445c90 and
the git-dpm dch calls. I guess this rebase (besides making it no longer
merging in your upstream branch but containing the chances as a commit
directly modifying it) also dropped the commit merging upstream
in your master branch and changing debian/.git-dpm.

I cannot imagine how such a rebase could be done by git-dpm and guess
you were doing it manually. If you did not do anything like that, I'd
like to get a copy of your .git/logs/refs/heads/master file (via
private mail if you prefer it not being public) so I might have a chance
to guess what happened then. (That file should exist and show all past
changes of the master branch done in that working copy if logging is
enabled (which current git versions do by default)).

        Bernhard R. Link