[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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: