emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: João Távora
Subject: Re: git history tracking across renames (and emacs support)
Date: Thu, 12 Jul 2018 17:56:09 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

Stefan Monnier <address@hidden> writes:

>> Perhaps it could work in emacs -Q if you make the whole feature depend
>> on a variable which I can set dir-locally (presumably not in Emacs, but
>> in all my other projects).
>
> Actually, I think it can be made to work without any customization
> (take the absence of a ChangeLog file as the cue).

Yes, I'm fine with that.

>>> And having the vc-log buffer under change-log-mode is, of course,
>>> trivial, either with your customizations or by default.
>> But that in turn would lose me some useful that vc-log functionality.
>> AFAIU the two modes should be merged, maybe one deriving from the other.
>
> They're different:
> - change-log-mode handles a sequence of commit messages
> - it includes dates
> - it uses a different syntax for authorship
> - its entries are indented with a TAB
> - it doesn't know about the special first line "Subject: ".
>
> So, while I do think that some of change-log-mode's features should be
> made available in *vc-log* buffers, it's not just a "merge".

Right, we agree.  I should have said a "process whereby things from two
different things are combined into one thing".

>> I think the changes envisioned above (particularly the fileless
>> ChangeLog buffer) only justify working on them if noone else is working
>> on the better alternative, which is IMO to automatically generate the "*
>> file.ext (changed entity)" list from the diff at commit-preparation
>> time, as I think someone suggested already.
>
> AFAIK the two issues are orthogonal/complementary: ChangeLog files are
> being phased out pretty much everywhere, AFAIK, so while we'll probably
> want change-log-mode to keep supporting them for the foreseeable future,
> we do want to adapt it to the newer use case where similar entries are
> recorded in the commit log rather than in a file.

I have no problem in keeping the ChangeLog funtionality intact.  I just
said that the small enhancements I proposed to it would probably be
useless in the face of an "add-from-diff-directly-into-vc-log"
alternative.

> BTW, there's diff-add-change-log-entries-other-window (bound to `C-x
> 4 A` in diff-mode) which already tries to create the list of entries
> from the diff.
> [ It turns out it's not as easy as it seems to make it work well :-(  ]

Thanks, didn't knwo that.  Are the current hangups listed somewhere?

João



reply via email to

[Prev in Thread] Current Thread [Next in Thread]