Re: How to cope with patches sanely
Raphael, please follow the Debian Mailing List code of conduct
<URL:http://www.debian.org/MailingLists#codeofconduct>; in particular,
don't send individual copies of list messages unless specifically
requested.
Raphael Hertzog <hertzog@debian.org> writes:
> Imagine an history like this:
>
> - Change behaviour1
> - Change behaviour2
> - Bugfix in patch to change behaviour1
> - Bugfix in patch to change behaviour2
>
> You have two logical patches and a dumb export from the VCS into
> debian/patches/ would give 4 patches when you really want only two.
In a VCS with good merging support (most DVCSes fit this description,
Subversion does not), those "logical patches" can be maintained as
"feature branches".
Essentially, any set of changes that is more than "add this change and
let it be absorbed into the stream of changes" merits branching the
development tree to maintain that feature. Into that feature branch go
any commits that are related logically to the feature; anything else
goes into other branches.
Any time you want to find how feature-branch-A differs from the
development branch, that's a simple diff operation between the two
branches (optionally specifying which revision of each you're
interested in comparing). Merges between the two will show up as
single revisions in each branch, so the changes in feature-branch-A
will show exactly the history of feature A.
Any time the changes in feature-branch-A are at a point where they
need to be included in the main development branch, simply merge them
in.
The important thing that enables this workflow is *easy merging*
between arbitrary branches that share a common ancestor. Again, this
rules CVS and Subversion out. (Some, like git, allow merging
*anywhere*, but that's not necessary for this to work well.)
--
\ "I have had a perfectly wonderful evening, but this wasn't it." |
`\ -- Groucho Marx |
_o__) |
Ben Finney
Reply to: