Re: [Monotone-devel] patch serieses

[Brian May]

>>>>> "Nathaniel" == Nathaniel Smith <address@hidden> writes:

    Nathaniel> There was a discussion on IRC today about
    Nathaniel> quilt/mq/stgit style workflows:
    Nathaniel> 
http://colabti.de/irclogger//irclogger_log/monotone?date=2006-11-08,Wed&sel=5#l9

Just my current thoughts (still reading the IRC log).

I use quilt in the Debian packaging of Heimdal, so it is possible for
people to tell at a glance each individual change as an atomic unit.

(comment: while the patches are applied in strict sequential order,
they should all be independent of each other - at least most of them
anyway).

Otherwise, the Debian packaging would end up with one big patch
containing all changes I have made based on upstream, and this isn't a
easy to understand.

Similarly, a set independent patches:

bug A fix --> update upstream v1 --> update upstream v2
bug B fix --> update upstream v1 --> update upstream v2
bug C fix --> update upstream v1 --> update upstream v2

that apply against the latest upstream version is easier to work out then:

bug A fix --> bug B fix --> bug C fix --> update upstream v1 --> update 
upstream v2

If for example, upstream decides they like my bug B fix but not the
bug A or C fix, it is easy to provide the patch in the first case, but
not in the second case (as the patch has to be separated first).

However, traditionally this means I can not use a revision control
system (unless I commit the patch file to the revision control system
- yuck!). I have asked about this before with other projects and got
an answer along the lines of "this is a problem that cannot be solved
with revision control systems".

This is because most systems keep track of changes based on time, not
based on the feature being implemented or bug being fixed.

Unfortunately, this means I don't have any history of paste changes I
have made (unless I keep copies of the old patch files - and doing
this manually is error prone). It might have been better if I did
store the patch files. The problem with this approach though is that I
don't really get a history of the old version preserved, only the
changes that I made.

Maybe monotone with its light weight branches could provide a
solution...

In what way was the "git's maintainer has screwed this up with git
itself"?
-- 
Brian May <address@hidden>