Hello,
thinking some more about gendiff, I really think it is the wrong
operation. From my understanding you are using gendiff like this:
- Start with a patch (say, patch.diff).
- Do a refresh and, as a side effect, remember the state
of the source tree with that patch applied (only those
files that are actually contained in that patch).
- Fork the patch, say, patch-2.diff, and work on it.
- Later, do a gendiff that compares the saved state from patch.diff
with the current state.
The problem I have with this is, it is a very limited implementation of
a general concept: You are really comparing two different source trees;
there could be more operations between saving the state and forking. I
think an easier to grasp and more general mechanism would be:
- Start with a specific state (e.g., go to a certain patch, and
optionally change a few things).
- Save the current state.
- Change the working state (pretty arbitrarily, by
pushing/popping/forking/etc).
- Compare the working state with the saved state.
I think that saving the current state can be implemented by saving the
latest version of all files that have been changed by any of the applied
patches.
This state can then be diff'ed with an arbitrary other working state by
going through all saved files plus all files modified by patches applied
since then. For each file in this list, the old version for diff'ing is
the one in the saved state. If the file is not in the saved state, the
old version is the copy in the most recent patch modifying that file.
The new version for diff'ing is always the file in the working
directory.
Comparing with such a saved state should be an option of `quilt diff'
instead of a new command I think.
Does this make any sense at all?
Cheers,