Commit 23468561 authored by Paul Eggert's avatar Paul Eggert

Generate a ChangeLog file from commit logs

* .gitignore: Add 'ChangeLog'.
* build-aux/gitlog-to-changelog: New file, from Gnulib.
* build-aux/gitlog-to-emacslog: New file.
* CONTRIBUTE: Document the revised workflow.
* Makefile.in (clean): Remove *.tmp and etc/*.tmp*
instead of just special cases.
(CHANGELOG_HISTORY_INDEX_MAX, CHANGELOG_N, gen_origin): New vars.
(ChangeLog, unchanged-history-files, change-history)
(change-history-commit): New rules.
* admin/admin.el (make-manuals-dist--1):
Don't worry about doc/ChangeLog.
* admin/authors.el: Add a FIXME.
* admin/make-tarball.txt:
* lisp/calendar/icalendar.el:
* lisp/gnus/deuglify.el:
* lisp/obsolete/gulp.el:
* lwlib/README:
Adjust to renamed ChangeLog history files.
* admin/merge-gnulib (GNULIB_MODULES): Add gitlog-to-changelog.
* admin/notes/repo: Call it 'master' a la Git, not 'trunk' a la Bzr.
Remove obsolete discussion of merging ChangeLog files.
New section "Maintaining ChangeLog history".
* build-aux/git-hooks/pre-commit:
Reject attempts to commit files named 'ChangeLog'.
* lib/gnulib.mk, m4/gnulib-comp.m4: Regenerate.
* make-dist: Make and distribute top-level ChangeLog if there's a
.git directory.  Distribute the new ChangeLog history files
instead of scattered ChangeLog files.  Distribute the new files
gitlog-to-changelog and gitlog-to-emacslog.
Fixes: bug#19113
parent dd1404cc
......@@ -237,6 +237,7 @@ info/dir
*~
.#*
\#*\#
ChangeLog
[0-9]*.patch
# Built by 'make install'.
......
......@@ -32,22 +32,33 @@ entry in their name, not yours. git distinguishes between the author
and the committer; use the --author option on the commit command to
specify the actual author; the committer defaults to you.
** commit messages
** Commit messages
When using git, commit messages should use ChangeLog format, with the
following modifications:
Typically, a patch creates ChangeLog entries by putting them into its
commit message, not by changing a ChangeLog file. Here is an example
commit message (indented):
Deactivate shifted region
Do not silently extend a region that is not highlighted;
this can happen after a shift.
* doc/emacs/mark.texi (Shift Selection): Document the change.
* lisp/window.el (handle-select-window):
* src/frame.c (Fhandle_switch_frame, Fselected_frame):
Deactivate the mark.
Fixes: bug#19003
The general format is as follows.
- Start with a single unindented summary line explaining the change,
then an empty line, then unindented ChangeLog entries.
You can use various Emacs functions to ease this process; see (info
"(emacs)Change Log Commands") or
http://www.gnu.org/software/emacs/manual/html_node/emacs/Change-Log-Commands.html.
- Limit lines in commit messages to 78 characters, unless they consist
of a single word of at most 140 characters. If you have trouble
fitting the summary into 78 characters, add a summarizing paragraph
below the empty line and before the individual file descriptions.
of a single word of at most 140 characters; this is enforced by a
commit hook. It's nicer to limit the summary line to 50 characters;
this isn't enforced. If the change can't be summarized so briefly,
add a paragraph after the empty line and before the individual file
descriptions.
- If only a single file is changed, the summary line can be the normal
file first line (starting with the asterisk). Then there is no
......@@ -63,8 +74,6 @@ following modifications:
- Commit messages should not contain the "Signed-off-by:" lines that
are used in some other projects.
** ChangeLog notes
- Emacs generally follows the GNU coding standards when it comes to
ChangeLogs:
http://www.gnu.org/prep/standards/html_node/Change-Logs.html . One
......@@ -83,25 +92,30 @@ following modifications:
and have a reasonable chance of being read in the future, so it's
better that they have good presentation.
- There are multiple ChangeLogs in the emacs source; roughly one per
high-level directory. The ChangeLog entry for a commit belongs in the
lowest ChangeLog that is higher than or at the same level as any file
changed by the commit.
- Use the present tense; describe "what the change does", not "what
the change did".
- Preferred form for several entries with the same content:
* help.el (view-lossage):
* kmacro.el (kmacro-edit-lossage):
* edmacro.el (edit-kbd-macro): Fix docstring, lossage is now 300 keys.
* lisp/help.el (view-lossage):
* lisp/kmacro.el (kmacro-edit-lossage):
* lisp/edmacro.el (edit-kbd-macro): Fix docstring, lossage is now 300.
(Rather than anything involving "ditto" and suchlike.)
- If the commit fixes a bug, add a separate line
- If the commit has authors other than yourself, the commit message
should contain a separate line like the following:
Co-authored-by: Joe Schmoe <j.schmoe@example.org>
- If the commit is a tiny change that is exempt from copyright paperwork,
the commit message should contain a separate line like the following:
Fixes: bug#NNNN
Copyright-paperwork-exempt: yes
- If the commit fixes a bug, append a separate line
Fixes: bug#NNNN
where NNNN is the bug number.
......@@ -119,6 +133,29 @@ following modifications:
of files such as 'configure'. "There is no need" means you don't
have to, but you can if you want to.
- If a commit message's first line starts with "; ", the message is
ignored when generating ChangeLog history files via 'make changelog'
or via 'make change-history'. You can use "; " for minor commits
that do not need separate ChangeLog entries.
** Generating ChangeLog entries
- You can use various Emacs functions to ease the process of writing
ChangeLog entries; see (info "(emacs)Change Log Commands") or
http://www.gnu.org/software/emacs/manual/html_node/emacs/Change-Log-Commands.html.
- If you use Emacs VC, one way to format ChangeLog entries is to create
a top-level ChangeLog file, and update it with 'C-x 4 a' file as
usual. Do not register the ChangeLog file under git; instead, use
'C-c C-a' to insert its contents into into your *vc-log* buffer.
- Alternatively, you can use the vc-dwim command to maintain commit
messages. When you create a source directory, run the shell command
'git-changelog-symlink-init' to create a symbolic link from
ChangeLog to .git/c/ChangeLog. Edit this ChangeLog via its symlink
with Emacs commands like 'C-x 4 a', and commit the change using the
shell command 'vc-dwim --commit'. Type 'vc-dwim --help' for more.
** branches
Development normally takes places on the trunk.
......@@ -182,6 +219,10 @@ to the tracker at http://debbugs.gnu.org .
You can subscribe to the mailing lists, or see the list archives,
by following links from http://savannah.gnu.org/mail/?group=emacs .
To email a patch you can use a shell command like 'git format-patch -1'
to create a file, and then attach the file to your email. This nicely
packages the patch's commit message and changes.
** Document your changes.
Any change that matters to end-users should have an entry in etc/NEWS.
......
......@@ -833,7 +833,7 @@ clean: $(clean_dirs:=_clean)
for dir in test/automated; do \
[ ! -d $$dir ] || $(MAKE) -C $$dir clean; \
done
-rm -f etc/emacs.tmpdesktop etc/emacs.tmpappdata
-rm -f *.tmp etc/*.tmp*
-rm -rf info-dir.*
### `bootclean'
......@@ -1087,6 +1087,44 @@ bootstrap: bootstrap-clean
$(MAKE) MAKEFILE_NAME=force-Makefile force-Makefile
$(MAKE) all
# The newest revision that should not appear in the generated ChangeLog.
gen_origin = 9d56a21e6a696ad19ac65c4b405aeca44785884a
# Convert git commit log to ChangeLog file. make-dist uses this.
.PHONY: ChangeLog change-history unchanged-history-files
ChangeLog:
$(AM_V_GEN)distprefix=$(distprefix) srcprefix=$(srcdir)/ \
$(srcdir)/build-aux/gitlog-to-emacslog $(gen_origin)
# The ChangeLog history files are called ChangeLog.1, ChangeLog.2, ...,
# ChangeLog.$(CHANGELOG_HISTORY_INDEX_MAX). $(CHANGELOG_N) stands for
# the newest (highest-numbered) ChangeLog history file.
CHANGELOG_HISTORY_INDEX_MAX = 1
CHANGELOG_N = ChangeLog.$(CHANGELOG_HISTORY_INDEX_MAX)
# Check that history-relevant files match what's in the repository.
# Otherwise, 'make change-history' might mess up the ChangeLog history files.
unchanged-history-files:
x=$$(git diff-files --name-only $(CHANGELOG_N) Makefile.in) && \
test -z "$$x"
# Copy newer commit messages to the start of the ChangeLog history file,
# and consider them to be older.
change-history: ChangeLog unchanged-history-files
(sed '/^Copyright/,$$d' <ChangeLog && cat $(CHANGELOG_N)) \
>$(CHANGELOG_N).tmp
new_origin=$$(git log --pretty=format:%H HEAD^!) && \
sed 's/^\(gen_origin *= *\).*/\1'"$$new_origin/" \
<Makefile.in >Makefile.in.tmp
mv $(CHANGELOG_N).tmp $(CHANGELOG_N)
mv Makefile.in.tmp Makefile.in
$(MAKE) $@-commit
# If 'make change-history' fails because the newest ChangeLog history
# file contains invalid text, fix the file by hand and then run
# 'make change-history-commit'.
change-history-commit:
git commit -m'; make $@' $(CHANGELOG_N) Makefile.in
.PHONY: check-declare
check-declare:
......
......@@ -28,10 +28,6 @@
(defvar add-log-time-format) ; in add-log
;; Does this information need to be in every ChangeLog, as opposed to
;; just the top-level one? Only if you allow changes the same
;; day as the release.
;; http://lists.gnu.org/archive/html/emacs-devel/2013-03/msg00161.html
(defun add-release-logs (root version &optional date)
"Add \"Version VERSION released.\" change log entries in ROOT.
Root must be the root of an Emacs source tree.
......@@ -601,7 +597,7 @@ style=\"text-align:left\">")
(copy-file "../doc/misc/texinfo.tex" stem)
(or (equal type "emacs") (copy-file "../doc/emacs/emacsver.texi" stem))
(dolist (file (directory-files (format "../doc/%s" type) t))
(if (or (string-match-p "\\(\\.texi\\'\\|/ChangeLog\\|/README\\'\\)" file)
(if (or (string-match-p "\\(\\.texi\\'\\|/README\\'\\)" file)
(and (equal type "lispintro")
(string-match-p "\\.\\(eps\\|pdf\\)\\'" file)))
(copy-file file stem)))
......
......@@ -27,6 +27,9 @@
;; Use M-x authors RET to create an *Authors* buffer that can used as
;; or merged with Emacs's AUTHORS file.
;; FIXME: This needs to modernized in the light of current practice,
;; which generates a single top-level ChangeLog file from commit logs.
;;; Code:
(defvar authors-coding-system 'utf-8
......@@ -76,7 +79,7 @@ files.")
("Gerd Möllmann" "Gerd Moellmann")
("Hallvard B. Furuseth" "Hallvard B Furuseth" "Hallvard Furuseth")
("Hrvoje Nikšić" "Hrvoje Niksic")
;; lisp/org/ChangeLog 2010-11-11.
;; lisp/org/ChangeLog.1 2010-11-11.
(nil "aaa bbb")
(nil "Code Extracted") ; lisp/newcomment.el's "Author:" header
("Jaeyoun Chung" "Jae-youn Chung" "Jae-you Chung" "Chung Jae-youn")
......
......@@ -31,28 +31,33 @@ General steps (for each step, check for possible errors):
M-x authors RET
If there is an "*Authors Errors*" buffer, address the issues.
If there was a ChangeLog typo, fix it. If a file was deleted or
renamed, consider adding an appropriate entry to authors-ignored-files,
authors-valid-file-names, or authors-renamed-files-alist.
If there was a ChangeLog typo, run "make change-history" and then
fix the newest ChangeLog history file. If a file was deleted or
renamed, consider adding an appropriate entry to
authors-ignored-files, authors-valid-file-names, or
authors-renamed-files-alist.
If necessary, repeat M-x authors after making those changes.
Save the "*Authors*" buffer as etc/AUTHORS.
Check the diff looks reasonable. Maybe add entries to
authors-ambiguous-files or authors-aliases, and repeat.
Commit any fixes to ChangeLogs or authors.el.
Commit any fixes to authors.el.
3. Set the version number (M-x load-file RET admin/admin.el RET, then
M-x set-version RET). For a release, add released ChangeLog
entries (M-x add-release-logs RET).
entries (create a ChangeLog symlink a la vc-dwim, then run M-x
add-release-logs RET, then run the shell command 'vc-dwim --commit').
For a pretest, start at version .90. After .99, use .990 (so that
it sorts).
The final pretest should be a release candidate. Set the version
number to that of the actual release. Pick a date about a week
from now when you intend to make the release. Use M-x add-release-logs
to add the ChangeLog entries for that date to the tar file (but
do not commit the entries to the repository until the actual release).
from now when you intend to make the release. Use vc-dwim and
M-x add-release-logs as described above to add commit messages
that will appear in the tarball's automatically-generated ChangeLog
file as entries for that date.
Name the tar file as emacs-XX.Y-rc1.tar. If all goes well in the
following week, you can simply rename the file and use it for the
actual release. If you need another release candidate, remember
......@@ -67,8 +72,7 @@ General steps (for each step, check for possible errors):
5. Copy lisp/loaddefs.el to lisp/ldefs-boot.el.
Commit etc/AUTHORS, lisp/ldefs-boot.el, and the files changed
by M-x set-version. For a release, also commit the ChangeLog
files in all directories.
by M-x set-version.
If someone else made a commit between step 1 and now,
you need to repeat from step 4 onwards. (You can commit the files
......
......@@ -31,7 +31,7 @@ GNULIB_MODULES='
crypto/md5 crypto/sha1 crypto/sha256 crypto/sha512
dtoastr dtotimespec dup2 environ execinfo faccessat
fcntl fcntl-h fdatasync fdopendir filemode fstatat fsync
getloadavg getopt-gnu gettime gettimeofday
getloadavg getopt-gnu gettime gettimeofday gitlog-to-changelog
intprops largefile lstat
manywarnings memrchr mkostemp mktime
pipe2 pselect pthread_sigmask putenv qacl readlink readlinkat
......
......@@ -10,10 +10,10 @@ instructions.
* Install changes only on one branch, let them get merged elsewhere if needed.
In particular, install bug-fixes only on the release branch (if there
is one) and let them get synced to the trunk; do not install them by
hand on the trunk as well. E.g. if there is an active "emacs-24" branch
is one) and let them get synced to the master; do not install them by
hand on the master as well. E.g. if there is an active "emacs-24" branch
and you have a bug-fix appropriate for the next emacs-24.x release,
install it only on the emacs-24 branch, not on the trunk as well.
install it only on the emacs-24 branch, not on the master as well.
Installing things manually into more than one branch makes merges more
difficult.
......@@ -21,10 +21,10 @@ difficult.
http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg01124.html
The exception is, if you know that the change will be difficult to
merge to the trunk (eg because the trunk code has changed a lot).
In that case, it's helpful if you can apply the change to both trunk
merge to the master (eg because the master code has changed a lot).
In that case, it's helpful if you can apply the change to both master
and branch yourself (when committing the branch change, indicate
in the commit log that it should not be merged to the trunk, by
in the commit log that it should not be merged to the master, by
including the phrase "Not to be merged to master", or any other phrase
that matches "merge").
......@@ -32,14 +32,14 @@ that matches "merge").
If your branch has only a single commit, or many different real
commits, it is fine to do a merge. If your branch has only a very
small number of "real" commits, but several "merge from trunks", it is
preferred that you take your branch's diff, apply it to the trunk, and
small number of "real" commits, but several "merge from masters", it is
preferred that you take your branch's diff, apply it to the master, and
commit directly, not merge. This keeps the history cleaner.
In general, when working on some feature in a separate branch, it is
preferable not to merge from trunk until you are done with the
preferable not to merge from master until you are done with the
feature. Unless you really need some change that was done on the
trunk while you were developing on the branch, you don't really need
master while you were developing on the branch, you don't really need
those merges; just merge once, when you are done with the feature, and
Bazaar will take care of the rest. Bazaar is much better in this than
CVS, so interim merges are unnecessary.
......@@ -66,22 +66,14 @@ variable in admin/merge-gnulib before running it.
If you remove a gnulib module, or if a gnulib module
removes a file, then remove the corresponding files by hand.
* How to merge changes from emacs-24 to trunk
* How to merge changes from emacs-24 to master
[The section on git merge procedure has not yet been written]
Inspect the change log entries (e.g. in case too many entries have been
included or whitespace between entries needs fixing). If someone made
multiple change log entries on different days in the branch, you may
wish to collapse them all to a single entry for that author in the
trunk (because in the trunk they all appear under the same date).
Obviously, if there are multiple changes to the same file by different
authors, don't break the logical ordering in doing this.
[The section on git merge procedure has not yet been written.]
You may see conflicts in autoload md5sums in comments. Strictly
speaking, the right thing to do is merge everything else, resolve the
conflict by choosing either the trunk or branch version, then run
`make -C lisp autoloads' to update the md5sums to the correct trunk
conflict by choosing either the master or branch version, then run
`make -C lisp autoloads' to update the md5sums to the correct master
value before committing.
* Re-adding a file that has been removed from the repository
......@@ -124,3 +116,21 @@ again.
This is a semi-automated way to find the revision that introduced a bug.
Browse `git help bisect' for technical instructions.
* Maintaining ChangeLog history
Older ChangeLog entries are kept in history files named ChangeLog.1,
ChangeLog.2, etc., and can be edited just as any other source files
can. Newer ChangeLog entries are stored in the repository as commit
messages, which cannot be edited directly.
'make ChangeLog' copies newer ChangeLog entries into a file
'ChangeLog' that is intended to be put into the distribution tarball.
This ChangeLog file is not put into the repository.
'make change-history' copies all newer ChangeLog entries into the
start of the newest ChangeLog history file. These ChangeLog entries
are thereafter considered to be old, so later uses of 'make ChangeLog'
and/or 'make change-history' will no longer copy the entries. To
alter ChangeLog history, run 'make change-history', then edit
the ChangeLog history files manually and commit your changes.
......@@ -34,13 +34,15 @@ if test "$nbadchars" -ne 0; then
exit 1
fi
new_names=`$git_diff HEAD` || exit
case "
$new_names" in
*/-* | *'
'-*)
echo "File name component begins with '-'."
exit 1;;
esac
for new_name in `$git_diff HEAD`; do
case $new_name in
-* | */-*)
echo "$new_name: File name component begins with '-'."
exit 1;;
ChangeLog | */ChangeLog)
echo "$new_name: Please use git commit messages, not ChangeLog files."
exit 1;;
esac
done
exec git diff-index --check --cached HEAD --
eval '(exit $?0)' && eval 'exec perl -wS "$0" ${1+"$@"}'
& eval 'exec perl -wS "$0" $argv:q'
if 0;
# Convert git log output to ChangeLog format.
my $VERSION = '2015-03-21 01:01'; # UTC
# The definition above must lie within the first 8 lines in order
# for the Emacs time-stamp write hook (at end) to update it.
# If you change this file with Emacs, please let the write hook
# do its job. Otherwise, update this string manually.
# Copyright (C) 2008-2015 Free Software Foundation, Inc.
# This program is free software: you can redistribute it and/or modify
# it under the terms of the GNU General Public License as published by
# the Free Software Foundation, either version 3 of the License, or
# (at your option) any later version.
# This program is distributed in the hope that it will be useful,
# but WITHOUT ANY WARRANTY; without even the implied warranty of
# MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
# GNU General Public License for more details.
# You should have received a copy of the GNU General Public License
# along with this program. If not, see <http://www.gnu.org/licenses/>.
# Written by Jim Meyering
use strict;
use warnings;
use Getopt::Long;
use POSIX qw(strftime);
(my $ME = $0) =~ s|.*/||;
# use File::Coda; # http://meyering.net/code/Coda/
END {
defined fileno STDOUT or return;
close STDOUT and return;
warn "$ME: failed to close standard output: $!\n";
$? ||= 1;
}
sub usage ($)
{
my ($exit_code) = @_;
my $STREAM = ($exit_code == 0 ? *STDOUT : *STDERR);
if ($exit_code != 0)
{
print $STREAM "Try '$ME --help' for more information.\n";
}
else
{
print $STREAM <<EOF;
Usage: $ME [OPTIONS] [ARGS]
Convert git log output to ChangeLog format. If present, any ARGS
are passed to "git log". To avoid ARGS being parsed as options to
$ME, they may be preceded by '--'.
OPTIONS:
--amend=FILE FILE maps from an SHA1 to perl code (i.e., s/old/new/) that
makes a change to SHA1's commit log text or metadata.
--append-dot append a dot to the first line of each commit message if
there is no other punctuation or blank at the end.
--no-cluster never cluster commit messages under the same date/author
header; the default is to cluster adjacent commit messages
if their headers are the same and neither commit message
contains multiple paragraphs.
--srcdir=DIR the root of the source tree, from which the .git/
directory can be derived.
--since=DATE convert only the logs since DATE;
the default is to convert all log entries.
--until=DATE convert only the logs older than DATE.
--ignore-matching=PAT ignore commit messages whose first lines match PAT.
--format=FMT set format string for commit subject and body;
see 'man git-log' for the list of format metacharacters;
the default is '%s%n%b%n'
--strip-tab remove one additional leading TAB from commit message lines.
--strip-cherry-pick remove data inserted by "git cherry-pick";
this includes the "cherry picked from commit ..." line,
and the possible final "Conflicts:" paragraph.
--help display this help and exit
--version output version information and exit
EXAMPLE:
$ME --since=2008-01-01 > ChangeLog
$ME -- -n 5 foo > last-5-commits-to-branch-foo
SPECIAL SYNTAX:
The following types of strings are interpreted specially when they appear
at the beginning of a log message line. They are not copied to the output.
Copyright-paperwork-exempt: Yes
Append the "(tiny change)" notation to the usual "date name email"
ChangeLog header to mark a change that does not require a copyright
assignment.
Co-authored-by: Joe User <user\@example.com>
List the specified name and email address on a second
ChangeLog header, denoting a co-author.
Signed-off-by: Joe User <user\@example.com>
These lines are simply elided.
In a FILE specified via --amend, comment lines (starting with "#") are ignored.
FILE must consist of <SHA,CODE+> pairs where SHA is a 40-byte SHA1 (alone on
a line) referring to a commit in the current project, and CODE refers to one
or more consecutive lines of Perl code. Pairs must be separated by one or
more blank line.
Here is sample input for use with --amend=FILE, from coreutils:
3a169f4c5d9159283548178668d2fae6fced3030
# fix typo in title:
s/all tile types/all file types/
1379ed974f1fa39b12e2ffab18b3f7a607082202
# Due to a bug in vc-dwim, I mis-attributed a patch by Paul to myself.
# Change the author to be Paul. Note the escaped "@":
s,Jim .*>,Paul Eggert <eggert\\\@cs.ucla.edu>,
EOF
}
exit $exit_code;
}
# If the string $S is a well-behaved file name, simply return it.
# If it contains white space, quotes, etc., quote it, and return the new string.
sub shell_quote($)
{
my ($s) = @_;
if ($s =~ m![^\w+/.,-]!)
{
# Convert each single quote to '\''
$s =~ s/\'/\'\\\'\'/g;
# Then single quote the string.
$s = "'$s'";
}
return $s;
}
sub quoted_cmd(@)
{
return join (' ', map {shell_quote $_} @_);
}
# Parse file F.
# Comment lines (starting with "#") are ignored.
# F must consist of <SHA,CODE+> pairs where SHA is a 40-byte SHA1
# (alone on a line) referring to a commit in the current project, and
# CODE refers to one or more consecutive lines of Perl code.
# Pairs must be separated by one or more blank line.
sub parse_amend_file($)
{
my ($f) = @_;
open F, '<', $f
or die "$ME: $f: failed to open for reading: $!\n";
my $fail;
my $h = {};
my $in_code = 0;
my $sha;
while (defined (my $line = <F>))
{
$line =~ /^\#/
and next;
chomp $line;
$line eq ''
and $in_code = 0, next;
if (!$in_code)
{
$line =~ /^([0-9a-fA-F]{40})$/
or (warn "$ME: $f:$.: invalid line; expected an SHA1\n"),
$fail = 1, next;
$sha = lc $1;
$in_code = 1;
exists $h->{$sha}
and (warn "$ME: $f:$.: duplicate SHA1\n"),
$fail = 1, next;
}
else
{
$h->{$sha} ||= '';
$h->{$sha} .= "$line\n";
}
}
close F;
$fail
and exit 1;
return $h;
}
# git_dir_option $SRCDIR
#
# From $SRCDIR, the --git-dir option to pass to git (none if $SRCDIR
# is undef). Return as a list (0 or 1 element).
sub git_dir_option($)
{
my ($srcdir) = @_;
my @res = ();
if (defined $srcdir)
{
my $qdir = shell_quote $srcdir;
my $cmd = "cd $qdir && git rev-parse --show-toplevel";
my $qcmd = shell_quote $cmd;
my $git_dir = qx($cmd);
defined $git_dir
or die "$ME: cannot run $qcmd: $!\n";
$? == 0
or die "$ME: $qcmd had unexpected exit code or signal ($?)\n";
chomp $git_dir;
push @res, "--git-dir=$git_dir/.git";
}
@res;
}
{
my $since_date;
my $until_date;