[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: |
Fri, 13 Jul 2018 00:33:37 +0100 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) |
Stefan Monnier <address@hidden> 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
- Re: git history tracking across renames (and emacs support), (continued)
- Re: git history tracking across renames (and emacs support), Stefan Monnier, 2018/07/12
- Re: git history tracking across renames (and emacs support), Robert Pluim, 2018/07/12
- Re: git history tracking across renames (and emacs support), Stefan Monnier, 2018/07/12
- Re: git history tracking across renames (and emacs support), Robert Pluim, 2018/07/13
- Re: git history tracking across renames (and emacs support), Stefan Monnier, 2018/07/13
- Re: git history tracking across renames (and emacs support), Robert Pluim, 2018/07/13
- Re: git history tracking across renames (and emacs support), Clément Pit-Claudel, 2018/07/13
- Re: git history tracking across renames (and emacs support), Stefan Monnier, 2018/07/13
- Re: git history tracking across renames (and emacs support), João Távora, 2018/07/12
- Re: git history tracking across renames (and emacs support), Stefan Monnier, 2018/07/12
- Re: git history tracking across renames (and emacs support),
João Távora <=
- Re: git history tracking across renames (and emacs support), Stefan Monnier, 2018/07/13
- Re: git history tracking across renames (and emacs support), João Távora, 2018/07/13
- Re: git history tracking across renames (and emacs support), Stefan Monnier, 2018/07/13
- Re: git history tracking across renames (and emacs support), Radon Rosborough, 2018/07/11
- Re: git history tracking across renames (and emacs support), Paul Eggert, 2018/07/11
- Re: git history tracking across renames (and emacs support), Eli Zaretskii, 2018/07/11
- Re: git history tracking across renames (and emacs support), Richard Stallman, 2018/07/11
- Re: git history tracking across renames (and emacs support), Eli Zaretskii, 2018/07/12
- Re: git history tracking across renames (and emacs support), Richard Stallman, 2018/07/11
- Re: git history tracking across renames (and emacs support), Ted Zlatanov, 2018/07/12