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

["João Távora" <joaotavora@gmail.com>]

Stefan Monnier <monnier@IRO.UMontreal.CA> writes:

>>>> 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.

Yes, but imagine that you do that for a bunch of files, and then decide
only to commit a subset of those files.  I guess I could discipline
myself to only add entries for whatever I'm about to commit (sometimes I
add entries for everything I've changed).

>>> 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.

Apart from my comment above, I could probably learn to work with that.

But I had something potentially simpler in mind.  It's very similar to
the current operation.  In this version the file-backed ChangeLog stays
put, but there's only one for every project, this should ease some of
the pain:

1. change-log-default-name is set to something very near the top of the
   file hierarchy, say ~/.emacs.d/UeberChangeLog

2. C-x 4 a is used as usual, but because of point 1, a much longer file
   path gets inserted in the file, like

   * ../Source/Emacs/emacs-master/lisp/jsonrpc.el (jsonrpc--lambda): what
     thingy

   This is working fine currently.

3. After vc-next-action in project dir, C-c C-a inserts the entries

   This doesn't at all work currently if the ChangeLog is higher up in
   the hierarchy than the vc-log buffer's default-directly.

   The paths would need fixing to make them relative to project's
   root. The paragraphs would need refilling. The entry above would
   become

   * lisp/jsonrpc.el (jsonrpc--lambda): what thingy

4. Optionally, C-c C-a would set local variables in the vc-log buffer
   that are markers in ~/.emacs.d/UeberChangeLog.  When the user presses
   C-c C-c the region is deleted (or somehow disabled) in that 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.

I didn't understand this part.  Maybe I need to see it in action.
Generally there's no way of knowing what delimits "the changes I want to
commit now" from other changes without using the actual commit action as
a boundary.

João