Currently, git-import-dsc will properly set the date on the commits on
the Debian branch (using the changelog).  However, for the upstream
tarball, it doesn't do anything.

The result is that you have history with upstream commits in the future,
relative to the Debian commits (which come *LATER* in history).  This is
ugly as all heck, and completely insane.

git-import-dsc needs to set the commit dates of the upstream branch too!

I suppose it should use the orig tarball date (or, with multiple
tarballs, the latest date of the set) for the "new upstream" commit.  In
the worst case, it should use the changelog date (as the Debian commit
will do).

Right now, I have to manually fix all upstream commit dates when
creating the initial repository.

El 14/1/11 a las 16:25, Henrique de Moraes Holschuh escribió:

Hello. I also have found this problem recently.

The date of the orig tarball (or the latest timestamp inside the tarball)
is probably the first idea which comes to mind.

However, that would not always work. Very often, it may happen that
the upstream author releases a new version, but we still continue
to make a few more Debian releases based on the previous upstream
version.

So, in my opinion, the best date for the original tarball would be the one
matching the first Debian release based on such tarball.

This way, such upstream version will appear (in the output of "git log")
after all Debian releases based on the previous version.

Same here. I'm currently considering to use a script for that task.
(If anybody is curious, just see the one I attached to Bug #953589).

Thanks.