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

[Stefan Monnier <monnier@IRO.UMontreal.CA>]

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

Ah, I see.  You want to document each modification first, and then
split them into commits.  That'd be more difficult, yes (tho it's
probably not too hard to do if you only cater to splitting the changes
into commits on a file-by-file granularity).

>    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

I wouldn't want to rely on such an automatic filename rewrite and text
refilling (it's OK for M-q to try and DTRT because I get to see the
result and fix it immediately): I'd feel obligated to tweak (a second
time) the result when the layout isn't quite to my liking.

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

The content of the vc-log would be defined as "one commit", so if the
user wants to split it, he'd need to explicitly switch to another commit
message, hence telling Emacs where the boundary is: these commits would
likely be combined into a single buffer/file somewhere else but when the
user edits them, he'd only see a single commit (contrary to the current
case with ChangeLog).


        Stefan