Re: problems with 3.0 format
Bernhard R. Link:
Not having that information also means that when you want to look for what
was changed for some bugfix, one has to look at the whole history and
collect the initial change and all the adoptions to newer upstream
versions.
That's the entire point of having it in a version control system, though,
that you can trace changes.
The information about what is changed is burried in the information when
it was changed. It also means one cannot tell upstream or some other
project to just cherry-pick a specific commit to get the fix.
True. But fixes generally apply anyway, until made redundant by upstream, so
this is probably not a big problem in most cases.
This is how I use Git to track changes (The "debian" branch holds the Debian
patches). As in your example, the Git history has been re-created from
previous package releases:
git://git.debian.org/users/peterk/lyskom-server.git -
http://git.debian.org/?p=users/peterk/lyskom-server.git;a=shortlog;h=refs/heads/debian
git://git.debian.org/crashmail/crashmail.git -
http://git.debian.org/?p=crashmail/crashmail.git;a=shortlog;h=refs/heads/debian
I haven't yet tried to use any automated tools to make packages from these,
curerntly I just use dpkg-buildpackage and tell it to ignore the .git
directory when building.
--
\\// Peter - http://www.softwolves.pp.se/
Reply to: