[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [bug-patch] [PATCH 1/2] do not version-control ChangeLog; instead, g
Re: [bug-patch] [PATCH 1/2] do not version-control ChangeLog; instead, generate it
Mon, 21 Mar 2011 18:42:31 +0100
Andreas Gruenbacher wrote:
>> Are you open to the idea of not version-controlling ChangeLog?
> Yes, definitely.
>> I've included two change sets below. The first is for ChangeLogs, as
>> described. The second is to update to the latest gnulib, since without
>> that, I get warnings (fixed long ago in gnulib) when running autoconf.
> Can you push this?
> Should your vc-dwim recommendations go into README-hacking?
coreutils' README-hacking mentions that,
so I've sync'd a few changes from there.
How about this?
[I've deliberately not updated copyright year lists;
I have a patch to update all of those at once. ]
>From 7d41c04e7b98f360b52b3cb77b71860183c44042 Mon Sep 17 00:00:00 2001
From: Jim Meyering <address@hidden>
Date: Mon, 21 Mar 2011 18:39:22 +0100
Subject: [PATCH] doc: update README-hacking
* README-hacking: Update from coreutils, including mention of
how to use vc-dwim to git-commit efficiently and safely using
a non-VC'd ChangeLog file.
README-hacking | 64 ++++++++++++++++++++++++++++++++++++++++++++-----------
1 files changed, 51 insertions(+), 13 deletions(-)
diff --git a/README-hacking b/README-hacking
index 8928ab0..659a7a5 100644
@@ -22,32 +22,70 @@ tools we depend upon, including:
Valgrind <http://valgrind.org/> is also highly recommended, if
Valgrind supports your architecture.
-Only building the initial full source tree will be a bit painful.
-Later, a plain `git pull && make' should be sufficient.
+While building from a just-cloned source tree may require installing a
+few prerequisites, later, a plain `git pull && make' should be sufficient.
-* First checkout
+* First GIT checkout
-Obviously, if you are reading these notes, you did manage to check out
-this package from CVS. The next step is to get other files needed to
-build, which are extracted from other source packages:
+You can get a copy of the source repository like this:
- $ ./bootstrap
+ $ git clone git://git.sv.gnu.org/patch
+ $ cd patch
+As an optional step, if you already have a copy of the gnulib git
+repository on your hard drive, then you can use it as a reference to
+reduce download time and disk space requirements:
+ $ export GNULIB_SRCDIR=/path/to/gnulib
+The next step is to get and check other files needed to build,
+which are extracted from other source packages:
+ $ ./bootstrap
+To use the most-recent gnulib (as opposed to the gnulib version that
+the package last synchronized to), do this next:
+ $ git submodule foreach git pull origin master
+ $ git commit -m 'build: update gnulib submodule to latest' gnulib
And there you are! Just
- $ ./configure
- $ make
- $ make check
+ $ ./configure --quiet
+ $ make
+ $ make check
At this point, there should be no difference between your local copy,
-and the master:
+and the GIT master copy:
- $ git status
+ $ git diff
-should show no difference.
+should output no difference.
+* Submitting patches
+If you develop a fix or a new feature, please send it to the
+appropriate bug-reporting address as reported by the --help option of
+each program. One way to do this is to use vc-dwim
+<http://www.gnu.org/software/vc-dwim/>), as follows.
+ Run the command "vc-dwim --help", copy its definition of the
+ "git-changelog-symlink-init" function into your shell, and then run
+ this function at the top-level directory of the package.
+ Edit the ChangeLog file that this command creates, creating a
+ properly-formatted entry according to the GNU coding standards
+ Run the command "vc-dwim" and make sure its output looks good.
+ Run "vc-dwim --commit".
+ Run the command "git format-patch --stdout -1", and email its output
+ in, using the output's subject line.
Copyright (C) 2002-2007, 2009-2010 Free Software Foundation, Inc.