Re: Updating *vc-dir* marks from *VC-log*

[Bob Rogers]

   From: Dan Nicolaescu <address@hidden>
   Date: Sun, 21 Nov 2010 12:02:19 -0500

   It's still unclear what you are trying to do, could you please
   describe in detail the use-case you have in mind?

Here's what I often find myself wanting to do:

   1.  Start a multi-file commit from vc-dir.

   2.  After writing half the log buffer, realize that one or two of the
files scheduled for commit are independent of the others, and should
really be committed first, in a separate operation.

   3.  Go back to *vc-dir*, change the mark set to include only those
files, and commit using a new log buffer.

   4.  Re-visit the first log buffer and finish the original commit,
with a reduced fileset.

   Currently, I either have to (a) save the current log buffer contents
somewhere and start fresh, or (b) drop the file(s) from the first commit
and just do them in the reverse order.  (It might work to rename the log
buffer at step 2, and then rename it back; I haven't tried that.  But I
was shooting for something more transparent.)

   FWIW, I used to have a hack that supported this workflow by splitting
log buffers in two, but it was driven by file names in the log buffer
itself, which wasn't very clean.  (And it was part of another multi-file
commit hack, before Emacs had proper support for it.)

   >    But, at the very least, I ought to check vc-parent-buffer first,
   > since that would always DTRT if the file appears in multiple vc-dir
   > buffers.  Thanks for making that apparent.
   >
   >    BTW, this is a subproject that came up while trying to make Emacs
   > smarter about changing marked files in vc-dir during the commit (see
   > bug#7350).  

   That's quite easy (I have it in my local copy).  `log-edit-files'
   gives you a list of files that *VC log* would check in.
   `vc-deduce-fileset' in `vc-parent-buffer' gives you the currently
   selected files in *vc dir*

All true.  But Stefan pointed out in response to bug#7350 that C-c C-c
should at least bring it to the user's attention if those two sets
differ, and update the commit fileset if the use approves.

   But if you've already have that code in your local copy, then I don't
have to write it.  Right?

                                        -- Bob