also sprach Stefano Zacchiroli <zack@debian.org> [2009.03.09.2210 +0100]:
> It is more expressive, and can give more easily access to
> individual patches (e.g. for pushing them upstream) when they get
> entangled with others. I'm using it because I'm convinced that it
> implements the right® packaging work-flow, as no other tool we
> currently have in our toolbox.
Actually, it all boils down to the distinction between who will do
the conflict resolution: you or the consumer. Manoj and I had long
debates about this on vcs-pkg-discuss.
With quilt, you are asking all consumers to do the conflict
resolution, in case a patch depends on an earlier one.
With plain feature branches, you have to do the conflict resolution
every time you pull them together to create a package.
TopGit can do both. You can maintain a simple stack, or a queue, or
anything in between. It allows^W encourages you to lean towards the
latter, so if a patch really depends on another, then upstream will
need both anyway. Then B depends on A. If a patch does not depend on
another, then B coexists with A and can be used separately.
> ... but it is, still, way more complex than legacy patch systems.
> Also, it requires serious git-fu if you get stuck.
Yes, it's definitely too complex right now, and just like Git, it
exposes too much of the internals.
I also feel it's the right direction, but it needs work. Having
experience people feed back their input and patches (!) will help.
--
.''`. martin f. krafft <madduck@d.o> Related projects:
: :' : proud Debian developer http://debiansystem.info
`. `'` http://people.debian.org/~madduckhttp://vcs-pkg.org
`- Debian - when you have better things to do than fixing systems
"there are more things in heaven and earth, horatio,
than are dreamt of in your philosophy."
-- hamlet