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

Re: Triggers status?



On Thu, 25 Oct 2007, Ian Jackson wrote:
> Raphael Hertzog writes ("Re: Triggers status?"):
> > Automatic merge failed; fix conflicts and then commit the result.
> 
> This is precisely what using a merge tracking drcs, used properly, is
> supposed to avoid.  And it is exactly what my approach _does_ avoid.

I know this, I don't need to learn it. :-)

And it would be wise & fine to proceed that way if your history
was clean and all. I was just showing you that loosing the history
doesn't involve as much work as you expected to, but of course it's
more work.

You can't get everything:
- either you fix the history and you get some more conflicts to handle (but not
  as many as you expected) 
- or you keep the problematic history and provided that this history is
  merged by the dpkg maintainers, you'll have less conflicts to handle

But as I said, if I were an official dpkg maintainer, I wouldn't merge
history that looks like this in gitweb:

33325ac Merge ../dpkg.base
13c3738 Reapply "Remove duplicate nested conditional" etc.
2791b4c Revert "Fix .... failed remove resulting in installed state"
5565fa4 Revert to untangle ``Remove duplicate nested conditional ...''
[...]
da517d0 dpkg (1.14.5ubuntu16) gutsy; urgency=low
5f25773 dpkg (1.14.5ubuntu15) gutsy; urgency=low
1620746 dpkg (1.14.5ubuntu14) gutsy; urgency=low
9ed9425 + dpkg (1.14.5ubuntu13) gutsy; urgency=low
45b5781 remove unused variable f_verbose
ee4bd47 add %nounput to trigdeferred.l
502affd + dpkg (1.14.5ubuntu10) gutsy; urgency=low
fb7f439 + dpkg (1.14.5ubuntu9~~) unstable; urgency=low
1ab6796 triggers initial implementation as of 1.14.5ubuntu8
8c02ed9 triggers initial implementation as of 1.14.5ubuntu8

So I would rather generate the diff associated to that, and apply the diff with
a proper commit message.

You have the opinion of someone else who managed to put patches in dpkg.
HTH and you're free to wait the input of Guillem on this topic.

Cheers,

PS: If you want to compare, here's what looks like my last merge:
036c800 ChangeLog: move everything related to Dpkg::Deps at the same date.
6b50675 Dpkg::Deps: add some integrated POD documentation of the API
065910a Update dpkg-gencontrol's man page to mention its handling of dependency fields
79157e8 Update changelog entries concerning the integration of Dpkg::Deps.
8cf298f controllib.pl: Remove obsolete and unused functions and variables.
7811be9 dpkg-scanpackages: Use @pkg_dep_fields from Dpkg::Deps
cd7b1b2 dpkg-checkbuilddeps: modify to use the new Dpkg::Deps module
6cda719 dpkg-source: use the new Dpkg::Deps module instead of controllib's parsedep
f143c9d dpkg-gencontrol: use the new Dpkg::Deps module to rewrite the dependencies
847f78a Include the new scripts/Dpkg/Deps.pm in the dpkg-dev package
6aef17c Add new module Dpkg::Deps to handle dependencies and some corresponding tests

And yes I invested time to obtain this result by squashing bug fixes into
previous commits and by making the effort to commit individual logical change.
-- 
Raphaël Hertzog

Premier livre français sur Debian GNU/Linux :
http://www.ouaza.com/livre/admin-debian/



Reply to: