From: Paul Eggert <eggert@cs.ucla.edu>
To: nicolas.petton@foretagsplatsen.se
Cc: Emacs Development <Emacs-devel@gnu.org>
Subject: Re: April 7 cutover for generating ChangeLog automatically
Date: Tue, 31 Mar 2015 21:59:32 -0700 [thread overview]
Message-ID: <551B7B34.8070201@cs.ucla.edu> (raw)
In-Reply-To: <87lhic26ko.fsf@foretagsplatsen.se>
[-- Attachment #1: Type: text/plain, Size: 454 bytes --]
nicolas.petton@foretagsplatsen.se wrote:
> what does "create a ChangeLog symlink a la
> vc-dwim" mean? And what does `vc-dwim --commit' does?
If you have vc-dwim installed, 'vc-dwim --help' should explain both points.
I've attached its output. For the first question, please see the last paragraph
of the DESCRIPTION, and the EXAMPLE. For the second question, please see the
first two paragraphs of DESCRIPTION, and the first option under OPTIONS.
[-- Attachment #2: vc-dwim-help.txt --]
[-- Type: text/plain, Size: 4025 bytes --]
NAME
vc-dwim - use new ChangeLog entries to direct and cross-check a
version-control "diff" or "commit" command
SYNOPSIS
vc-dwim [OPTIONS] [CHANGELOG_FILE...]
vc-dwim [OPTIONS] --commit CHANGELOG_FILE...
vc-dwim [OPTIONS] --diff [FILE...]
vc-dwim [OPTIONS] --print-vc-list
DESCRIPTION
By default, each command line argument should be a locally modified,
version-controlled ChangeLog file. If there is no command line argument,
vc-dwim tries to use the ChangeLog file in the current directory. In this
default mode, vc-dwim works by first computing diffs of those files and
parsing the diff output to determine which named files are being changed.
Then, it diffs the affected files and prints the resulting output. One
advantage of using this tool is that before printing any diffs, it warns
you if it sees that a ChangeLog or an affected file has unsaved changes.
It detects that by searching for an editor temporary file corresponding to
each affected file. Another common error you can avoid with this tool is
the one where you create a new file, add its name to Makefiles, etc.,
mention the addition in ChangeLog, but forget to e.g., "git add" (or "hg
add", etc.) the file to the version control system. vc-dwim detects this
discrepancy and fails with a diagnostic explaining the probable situation.
You might also have simply mistyped the file name in the ChangeLog.
Once you are happy with your ChangeLog-derived diffs, you can commit those
changes and the ChangeLog simply by rerunning the command with the
--commit option.
But what if you'd like to use vc-dwim on a project that doesn't have or
want a ChangeLog file? In that case, you can maintain your own, private,
version-controlled ChangeLog file in a different hierarchy. Then just
make a symlink to it from the top level directory of the hierarchy in
which you'd like to use it and everything should work. Your private
ChangeLog file need not even use the same version control system as the
rest of the project hierarchy.
OPTIONS
--commit
perform the commit, too
--author="User Name <user@example.org>"
Specify the user name and email address of the author of this change
set.
--diff
Determine which version control system manages the first FILE, then
use that to print diffs of the named FILEs. If no FILE is specified,
print all diffs for the current hierarchy.
--print-vc-list
Print the list of recognized version control names, then exit.
--help
Display this help and exit.
--version
Output version information and exit.
--verbose
Generate verbose output.
--debug
Generate debug output.
EXAMPLE
Here's how to use vc-dwim in a project that does not version-control a
ChangeLog file. Create a repository just for your personal ChangeLog file
and make a symlink to it from the top-level directory of the project. For
projects that use git, I put this tiny auxiliary repository in a directory
named .git/c. You can use this bash/zsh alias to set it up and to create
the symlink:
git-changelog-symlink-init()
{
local d=.git/c
test -d .git || return 1
mkdir $d
touch $d/ChangeLog
(cd $d && git init && git add ChangeLog && git commit -m. -a)
ln --backup -s $d/ChangeLog .
}
RESTRICTIONS
This tool can be useful to you only if you use a version control system.
It's most useful if you maintain a ChangeLog file and create a log entry
per file per "commit" operation.
Relies on fairly strict adherence to recommended ChangeLog syntax.
Detects editor temporaries created by Emacs and Vim. Eventually, it will
detect temporaries created by other editors.
AUTHOR
Jim Meyering <jim@meyering.net>
Report bugs to <bug-vc-dwim@gnu.org>.
next prev parent reply other threads:[~2015-04-01 4:59 UTC|newest]
Thread overview: 38+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-03-31 7:53 April 7 cutover for generating ChangeLog automatically Paul Eggert
2015-03-31 11:58 ` Eli Zaretskii
2015-03-31 12:57 ` Stefan Monnier
2015-03-31 13:04 ` Eli Zaretskii
2015-03-31 20:49 ` Stefan Monnier
2015-04-01 2:37 ` Eli Zaretskii
2015-03-31 14:07 ` Nicolas Petton
2015-03-31 18:17 ` Paul Eggert
2015-03-31 21:35 ` nicolas.petton
2015-04-01 4:59 ` Paul Eggert [this message]
2015-03-31 21:52 ` Nicolas Petton
2015-03-31 14:45 ` Dmitry Gutov
2015-03-31 17:56 ` Paul Eggert
2015-03-31 20:52 ` Stefan Monnier
2015-03-31 21:50 ` Dmitry Gutov
2015-04-01 2:21 ` Stefan Monnier
2015-04-07 11:48 ` Dmitry Gutov
2015-04-01 5:13 ` Paul Eggert
2015-04-07 7:19 ` Emacs master ChangeLog files now generated automatically Paul Eggert
2015-04-07 14:04 ` John Wiegley
2015-04-07 16:48 ` Karl Fogel
2015-04-07 13:24 ` April 7 cutover for generating ChangeLog automatically Dmitry Gutov
2015-04-07 14:05 ` João Távora
2015-04-07 14:27 ` Eli Zaretskii
2015-04-07 16:41 ` Paul Eggert
2015-04-07 17:25 ` Dmitry Gutov
2015-04-07 17:32 ` Eli Zaretskii
2015-04-07 18:16 ` Dmitry Gutov
2015-04-07 18:27 ` Eli Zaretskii
2015-04-07 20:09 ` Paul Eggert
2015-04-08 5:36 ` Eli Zaretskii
2015-04-08 15:07 ` Dmitry Gutov
2015-04-08 15:18 ` Eli Zaretskii
2015-04-08 15:31 ` Dmitry Gutov
2015-04-08 15:37 ` Eli Zaretskii
2015-04-08 16:08 ` Eli Zaretskii
2015-04-08 19:15 ` Stefan Monnier
2015-04-09 0:42 ` Dmitry Gutov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=551B7B34.8070201@cs.ucla.edu \
--to=eggert@cs.ucla.edu \
--cc=Emacs-devel@gnu.org \
--cc=nicolas.petton@foretagsplatsen.se \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).