In my archive, the function tla--prepare-changes-buffer takes two more arguments : BASE and MODIFIED.
They represent the revisions or tree compared by the resulting buffer. The local variables tla--changes-base and tla--changes-modified are set accordingly. This is currently used by no other function, but will soon be used by at least tla-changes-ediff that would be able to retrieve the right versions when called from a *tla-changes* buffer other than one created by `tla-changes'. (typically tla-get-changeset). Once we have a robust and generic tla-changes-mode, I'd like to implement a feature tla-review-last-patch: Problem answered: ================= When I merge from your archives, I like to review, more or less quickly, what have been done. I currently do so after merging and before committing. I run M-x tla-changes RET, read the patch, and when the modifications are too complex, type `e' to use ediff. Sometimes, I read a piece of code and think: "Ah, that's not the way it should be. Let's fix it !". But if I fix it right now, I'll get a changeset containing both manual modifications and merges, and I don't like this. How will I know, later, which modifications I've done in this patch? So, currently, I have mainly two options: Fix the problem before committing, or take notes, commit, and fix problems in the next patch. Proposed solution: ================== My suggestion is to allow the user to commit rather blindly, and run something like "tla-review-last-patch" that would act like tla-changes, but against the last-but-one revision instead of the last revision (The output should be the same as M-x tla-changes RET done before committing). The user could read the diff, use ediff (and potentially undo some modifications from here) and all features available in *tla-changes* to review the patch. At the end of the review, he may commit his changes if any. -- Matthieu
