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

Re: problems with 3.0 format



* Peter Krefting <peter@softwolves.pp.se> [100328 18:25]:
>> Up to know I was rather thinking of designing a new tool
>> "vcs-buildpackage" but maybe I simply want to create new source
>> formats "3.0 (git2quilt)" or "3.0 (bzr2quilt)" and extend the dpkg-source
>> integration in dpkg-buildpackage.
>
> That only works if you use a rebase workflow in the VCS, not if you use a
> merge workflow. Personally, I find merge workflows easier to follow,
> since you can track the branch back through history properly.

History with rebased branches is indeed the tricky point.
I know of two possibilities:
 - Either rebase and merge that one (possibly with -s ours).
   The problem with that is that git's format patch (and all the
   rebase operations) have problems coping with that.
 - don't publish the patched branch but only tag when released and
   include in the history of some debian branch. (That is what git-dpm
   does). (Try to clone git://git.debian.org/users/brlink/xwit.git and
   take a look at the history. I've tried to import the old history in
   a way like it would be created when using git-dpm workflow.) I think
   it is relatively easy to follow such a history. (And pointing someone
   to the specific tag in git.debian.org's web-view is as useable for
   someone to look at the actual changes as viewing the patches with
   patch-tracker.debian.org is).

> Unfortunately, such a workflow can't easily be translated back into a set
> of patches to apply on top of the current upstream.

I think it is a worse problem than only the impossiblity to create the
patches. That is only a consequence of the version control system
missing information about what the changes are.

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. 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.

Hochachtungsvoll,
	Bernhard R. Link


Reply to: