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

[João Távora]

Stefan Monnier <address@hidden> writes:

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

Yeah, hunk by hunk would be nirvana.  This is probably the only thing
about Magit that I envy.  I remeber seeing that diff-mode seems to have
the line-counting machinery that could be made to interact with git add
-p (no idea if that's how Magit does it)


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

OK scratch refilling.  But the filename rewrite should be perfectly safe.

I'm going to try to implement either this or the fileless ChangeLog idea
that Eli floated before.  Which one do you prefer?

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

Right.  But where would you record this information?  In the
~/.emacs.d/PseudoChangeLog file?

João