emacs-orgmode
[Top][All Lists]
Advanced

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

Re: [Orgmode] Re: A request: Moving away from ChangeLog


From: Eric Schulte
Subject: Re: [Orgmode] Re: A request: Moving away from ChangeLog
Date: Fri, 21 May 2010 10:32:48 -0600
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.50 (gnu/linux)

Bernt Hansen <address@hidden> writes:

> John Wiegley <address@hidden> writes:
>
>> On May 21, 2010, at 9:47 AM, Tassilo Horn wrote:
>>
>>> I think it would be better if line 3+ would be exact ChangeLog entries
>>> format-wise, so that you can still use emacs' ChangeLog facilities
>>> (`add-change-log-entry').  I don't really want to write the changed file
>>> and function names on my own, and adding them correctly is exactly what
>>> that function does very well.
>>
>> This ends up looking rather ugly in the history, and I would hate to
>> see VCS history bent merely to conform to tools usage.
>>
>> Rather, the history should be as clean and exact as possible.  If
>> elisp functions need to be written to convert ChangeLog entries to a
>> suitable format, I can do that.
>>
>> Also, in magit if you press 'C' on any diff hunk, it auto-generates a
>> properly formatted ChangeLog-style comment into the current commit
>> log.
>
> I also prefer descriptive and succinct commit messages.
>
> It should be possible to automatically retrieve function information and
> other items from the source based on hunk line information and the
> source code in a tool that builds the Changelog.
>

Yes, `which-function' should be sufficient for collecting the names of
modified functions.

>
> I make most of my git commits (including org-mode) in vim which is
> kicked off from raw command-line git.  I normally make multiple changes
> at once and then build separate commits by using git's editing hunk
> features from 'git add -p'.  I don't think that functionality is
> available in magit yet.
>
> Requiring an elisp-only solution for making commits isn't ideal -- the
> tools should be as flexible as possible.
>
> I have no issue with the maintainers rejecting patches and requesting
> changes to the commit messages so that they can be applied to the
> project but I wouldn't want to require the use of a specific tool to do
> the job.
>

I think this could be a good candidate for a user-end pre-commit hook.
Since everyone on this project can be assumed to have a working Emacs
instillation it should be possible for git to run an elisp function
(through emacs --batch) before every commit which make the necessary
changelog changes (and possibly adds some key to the commit message
which could be checked by a gatekeeper commit-hook on the remote
repository to ensure compliance).

>
> Regards,
> Bernt
>
> _______________________________________________
> Emacs-orgmode mailing list
> Please use `Reply All' to send replies to the list.
> address@hidden
> http://lists.gnu.org/mailman/listinfo/emacs-orgmode



reply via email to

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