Re: git history tracking across renames (and emacs support)

[Stefan Monnier]

>>> I wish there was a way to make these buffers without buffer-file-name and
>>> still have vc collect the entries from them.  Also, after committing, the
>>> entries would actually be removed.
>> How 'bout making C-x 4 a add entries directly to the *vc-log* buffer
>> when there's one and there's no ChangeLog?
> I though about that too, but how exactly you deal with multi-file
> commits?

Hmm... I'm missing something because I fail to see in what way this
needs to be treated differently than the single-file case: `C-x 4 a`
only adds a single entry, and you just call it on every relevant part
of the code.

>> Maybe another take on it is to use a "hidden" ChangeLog file, saved
>> somewhere in ~/.emacs.d, indexed by the project location and with some
>> way to recover some earlier commit message you worked on and had
>> to abandon?
> A single ChangeLog for all my C-x 4 a needs?  Doesn't sound bad, too.
> All that would be needed, I think, is to make log-edit-insert-changelog
> fix the paths and refill the "paragraphs" when collecting entries.

I'd think that the file names would already be project-relative when
inserting them with `C-x 4 a`: log-edit-insert-changelog shouldn't have
to mess with the message at all.

More specifically, the suggestion is split into 2 parts:
- a feature for vc-log that lets you save a commit message in a file (in
  ~/.emacs.d, but indexed by the project).  When erasing a *vc-log*
  buffer, I'd probably want the previous message to be automatically be
  stashed into that file.  This would be commit-message-format-agnostic,
  hence not directly related to change-log-mode.
- a new feature of add-log.el which lets you use a vc-log buffer (using
  the slightly different format expected there) instead of the
  ChangeLog file.

> It leaves me with the multiple-commit-per-day-per-file problem.  I think
> the entries copied to the vc-log buffer by `log-edit-insert-changelog'
> could be deleted from that file when you C-c C-c (log-edit-done).

I often re-use some old commit message, so I think I'd rather rely on
a better UI to choose which message to use than on actual deletion of
messages we think are unlikely to be useful.

IOW I think the "multiple-commit-per-day-per-file problem" needs to be
solved by looking more carefully at what happens (e.g. the operation
to fetch a previous commit message would likely first give you the most
recently added message, which should usually be the right choice, no?).

I suspect in your case, the issue with "the
multiple-commit-per-day-per-file problem" is simply that add-log.el
doesn't know where one entry stops and the other starts (and you can
"solve" it by explicitly adding a "<DATE> <NAME> <EMAIL>" line to
separate them), but in the model suggested above, each entry would be
naturally separated, so I think the problem wouldn't show up at all.


        Stefan