* Colin Watson <cjwat...@debian.org> [100327 17:00]:
> > I think what quilt is missing here, is some reverse-setup: A command
> > to create a .pc file from a patched tree and a series of patches.
>
> Are you suggesting specifically here that this should go in quilt? I
> wouldn't be opposed to that; I'd been thinking of dpkg-dev, but either
> would work.
I've missed that functionality already in quilt before the 3.0 format
came, so I personally would suggest to have it in quilt.
> > Another way to work around that is not using quilt if you are using
> > a vcs, but use the vcs to manage the differences and export that
> > information into debian/patches/.
> > For git I wrote git-dpm[1] as some way[2] to do this. I guess with bzr
> > something similar should be possible.
>
> I know some people have been looking at this, and I recognise that in
> many ways it would be better to regard the patches as exports from a VCS
> (indeed, I mentioned this in my blog article). However, for me, I'd
> foresee many more warts than the mere management of branches and
> extraction of patches from them. For instance, I would want to commit
> debian/changelog at the same time as the patch (I don't like
> autogenerating debian/changelog; the results tend to be terrible), which
> means I'd have to either tolerate lots of conflicts or else put up with
> auto-merging tools, which I never really trust very much.
I like to have the patch without the debian/ related changes (so
upstream or other users can cherry-pick it).
In git-dpm workflow:
git-dpm checkout-patched
apply patch/modify files
git commit
git-dpm update-patches
dch "description"
# possible other debian/ changes
git commit -a --amend
so the commit that has the changed debian/patches (and the virtual branch
with the actual changes as parent) also has the debian/changelog
changes.
> Also there's
> the issue of DEP-3 metadata in patch files, which I'd often want to
> change along with the commit to their contents. Probably all soluble
> but all the tools I've seen are very definitely in their early stages as
> yet.
I try to just have them in the git commit description. I'm not using
them very consistently yet, though.
> > When using git, moving the patches to a new upstream is just a rebase
> > of a patched branch to a new upstream. That means if the patches are
> > stored as commits those commits can be rebased and one has the changes
> > and information to create the updated patches from created by the same
> > resolution. Perhaps something like that is possible with bzr, too.
>
> Well, firstly, I strongly disapprove of rebasing published branches, so
> I'll mentally s/rebase/merge/g (though either is of course perfectly
> possible with bzr).
I'd prefer if the commits are usable to be reused by upstream. Rebased
stuff usually is, while something merged and merged again is usually
nothing upstream will want to pull.
My solution against the "rebasing published branches" is thus to not
publish it as branch, but only as tag and as part of the history of the
debian branch (and of course as temporary branch for the user doing the
modification).
I'm guess this discussiong is slowly leaving debian-dpkg@ topic,
though...
Hochachtungsvoll,
Bernhard R. Link
--
To UNSUBSCRIBE, email to debian-dpkg-requ...@lists.debian.org
with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Archive:
http://lists.debian.org/20100327190305.ga2...@pcpool00.mathematik.uni-freiburg.de
