Re: [Quilt-dev] [PATCH] quilt drop command

[Josh Boyer]

On Thu, 2005-06-02 at 22:19 +0200, Jean Delvare wrote:
> Hi Josh,
> 
> [Josh Boyer]
> > (...)  So you could promote and demote the patches in any
> > combination, as long as b is always applied before c.  Quilt doesn't
> > have any way of know that today though, so it's left up to the user.
> 
> I think it does have a way to know, but to a limited extent. Quilt would
> learn about dependencies between patches if asked to switch two patches
> in the series file (either promote or demote, which are the very same
> operation when you think of it) and the operation would fail. So,
> although quilt cannot have an idea of the dependency before trying, the
> failure would reveal the dependency, and quilt could then tell the user
> about it. I don't think it is really different from e.g. push, which may
> fail, and quilt has to try before it knows and tells the user. So I'm
> not certain the patch grouping feature you mentioned would even be
> needed for promote/demote to be implementable.

I think our definitions of dependency are different.  What you describe
above is true if you view patch dependency as two patches that modify
the same file.  I call that patch conflicts.

What I meant by dependency is something that can't be detected by quilt,
but the patch order still matters.  For example, you have patch a that
creates an exported function in a particular file for a new interface in
this particular code base.  Now you have another patch that adds a call
to said interface, but it's in a completely different file.  In this
case, quilt will try and succeed in doing any operation because the two
patches modify individual files.

You might say, "why can't you just do both in a single patch?".  Well,
in larger patches developers are often told to break them up into
smaller ones so they are easier to review.  So they often get broken up
into "infrastructure" patches and "user" patches, but the order that
they are applied is still important.

Now if the series file was "redone" to imply an implicit order, you
could push/pop and entire series of patches at a time.  Then you could
fixup individual patches within that series, but the order remains the
same.

Where does this order come from originally?  Well, the user of course.
Quilt isn't psychic, so when a user does 'quilt new --series foo.series'
it creates a new series file.  Then all subsequent 'quilt new foo-add-
bar.patch' commands would add said patch to the foo.series file.  When
all of the new patches have been added and the user wants to work on
another patchset, they would do 'quilt pop --series foo.series' and the
whole series of patches is popped. [1]

> 
> > This could be highly useful to people using a single tree for multiple
> > patch sets that don't really have anything to do with each other.  For
> > example, maintaining two separate driver trees.
> 
> I think some people do that already (Greg KH among others, and you know
> he has a lot of stuff in his trees), and it works just fine. There is
> probably no immediate need for patch grouping nor promote/demote (but we
> can continue to think about it for the day we'll really need it, of
> course).

Yes, I was thinking of Greg KH's workload when I came up with that
example.  I wonder how he currently deals with that.  I'll have to find
out.  Anybody know if he subscribes to this list?

At any rate, you are right in that we need to think about it more.  I'll
focus on one thing at a time for now, and that's my {drop, graft,
incorporate, forget, ...} patch :).

josh

[1] The example commands were just made up off the top of my head and
I'm sure much more thought would be needed to make something actually
work.