[Mark Triggs] > By the way, speaking of merging, I've just noticed that if I'm > in the *tla-revisions* buffer, move my point over a particular revision > and do "S" to star-merge it, all of the missing revisions get merged > in, not only the one I was interested in.
If you want to merge only a single patchset (i.e. you want to do some cherrypicking), star-merge probably isn't what you're looking for. Use replay instead. When star-merge is given a fully-qualified FROM revision, this revision is interpreted as the end-point for the merge; this means that all revisions prior to the FROM revision will also be part of the merge. > (It seems to be running "tla star-merge category--branch--version" > instead of "tla star-merge category--branch--version--revision"). > > I think the piece of code causing this behaviour is: > > (defun tla-revision-star-merge () > "Run star-merge from the current location" > ... > (if tla-buffer-archive-name > (tla-star-merge (tla-fully-qualified-revision > tla-buffer-archive-name > tla-buffer-category-name > tla-buffer-branch-name > tla-buffer-version-name) to-tree) > (let* ((elem (ewoc-data (ewoc-locate > tla-revision-list-cookie))) > (full (caddr elem))) > (tla-star-merge (apply 'tla-fully-qualified-revision > full) > to-tree))) > ..) > > That first arm of the IF is the one being entered. I haven't tried using xtla for this yet, nor have I studied the code... but to me it looks as though both arms of the IF are using TLA-FULLY-QUALIFIED-REVISION for constructing the first argument too TLA-STAR-MERGE. -- Harald
