Re: [Monotone-devel] patch serieses

[Nathaniel Smith]

On Thu, Nov 09, 2006 at 10:46:34AM +1100, Brian May wrote:
> 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:

The problem with this is what to do if the patches are not independent
-- not necessarily because they have some semantic relations between
them, but it can happen from time to time that, oops, two patches both
need to touch the same line, or one patch needs to be modified to
avoid bumping into another patch, or some other thing like that.

> 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...

One approach might indeed be to have an "upstream" branch that you
make imports into, a bunch of feature branches off of it (one for each
current patch), and then a "release" branch which you get by merging
together all the feature branches.

> In what way was the "git's maintainer has screwed this up with git
> itself"?

In stgit's model, each "patch" is stored as a commit in the VCS; a
stack of patches is literally a series of commits made one after
another.  This means that when you refresh or reorder patches, you
have to delete the existing commits and create new ones, with new ids.
Obviously, this causes some problems if other people are trying to
track your branch remotely -- such changes to history do not
themselves get history tracking, so there's no way for remote sites to
figure out what has changed and how to merge it into their work.

My understanding is that Junio once accidentally used this kind of
technique on a branch that _was_ public, and rather broke things.

-- Nathaniel

-- 
"But suppose I am not willing to claim that.  For in fact pianos
are heavy, and very few persons can carry a piano all by themselves."