removed requirement for CHANGE_LOG_* env vars

From: Mauro Carvalho Chehab <mchehab@infradead.org>

Before, to use make commit, some env vars were required. Now, just using
HGUSER=Mauro Carvalho Chehab <mchehab@infradead.org>
is enough to gererate an useful log.
Readme updated to this new condition. Also added a warning about keeping
the first line in blank.
Readme visual improved.

Signed-off-by: Mauro Carvalho Chehab <mchehab@infradead.org>

2 files changed, 123 insertions, 111 deletions

diff --git a/Makefile b/Makefile
index 8dcf8a289..8124ec1f3 100644
--- a/Makefile
+++ b/Makefile
@@ -1,6 +1,10 @@
 BUILD_DIR := $(shell pwd)/v4l
 REPO_PULL := http://linuxtv.org/hg/v4l-dvb
-REPO_PUSH := ssh://$(CHANGE_LOG_LOGIN)@linuxtv.org/hg/v4l-dvb
+ifneq ($(CHANGE_LOG_LOGIN),)
+	REPO_PUSH := ssh://$(CHANGE_LOG_LOGIN)@linuxtv.org/hg/v4l-dvb
+else
+	REPO_PUSH := ssh://linuxtv.org/hg/v4l-dvb
+endif
 
 ifeq ($(EDITOR),)
   ifeq ($(VISUAL),)
@@ -25,12 +29,11 @@ commit cvscommit hgcommit change changes changelog:: whitespace
 	grep -v ^# /tmp/v4l_hg_commit.msg | hg commit -l -
 
 pull update v4l-update::
-	@echo "Pulling master repository changes"
+	@echo "Pulling changes from master repository $(REPO_PULL)"
 	-hg pull -u $(REPO_PULL)
-	hg checkout
 
 push::
-	@echo "Pushing changes to master repository"
+	@echo "Pushing changes to master repository $(REPO_PUSH)"
 	-hg push $(REPO_PUSH)
 
 whitespace:
diff --git a/README.HG b/README.HG
index ac6e6853a..d163528df 100644
--- a/README.HG
+++ b/README.HG
@@ -1,180 +1,189 @@
-Mauro Carvalho Chehab                                   2006 Jan 28
+Mauro Carvalho Chehab                                   2006 Jan 30
 
-	This file describes the general procedures used by v4l-dvb 
-maintainers. Some of these also applies to patch submitters.
+This file describes the general procedures used by v4l-dvb maintainers. 
+Some of these also applies to patch submitters.
 
-	We've moved from cvs to a modern SCM system that fits better 
-into kernel development model, called Mercurial (aka hg).
+We've moved from cvs to a modern SCM system that fits better into 
+kernel development model, called Mercurial (aka hg).
 
-	At http://selenic.com/mercurial you'll find quick-start info, a 
+At http://selenic.com/mercurial you'll find quick-start info, a 
 tutorial and FAQs.
 
-	Mercurial is a distributed SCM, which means every developer 
-gets his own full copy of the repository (including the complete 
-revision history), and can work and commit locally without network 
-connection. The resulting changesets can then be exchanged between 
-repositories and finally published to the master repository in 
-linuxtv.org.
+Mercurial is a distributed SCM, which means every developer gets his 
+own full copy of the repository (including the complete revision 
+history), and can work and commit locally without network connection. 
+The resulting changesets can then be exchanged between repositories and 
+finally published to the master repository in linuxtv.org.
 
-	Mercurial is organized with a master tag, called tip. This tag 
-contains the master repository that will be used by normal users and to 
-generate patches to kernel.
+Mercurial is organized with a master tag, called tip. This tag contains 
+the master repository that will be used by normal users and to generate 
+patches to kernel.
 
-	The v4l-dvb mercurial repository is meant for development. It 
-means that it might be broken from time to time, although all efforts 
-should be done to avoid this. There are more "stable" snapshots at 
+The v4l-dvb mercurial repository is meant for development. It means 
+that it might be broken from time to time, although all efforts should 
+be done to avoid this. There are more "stable" snapshots at 
 http://www.linuxtv.org/downloads/snapshot page.
 
-	This file postulates some simple rules for maintaing hg tree, 
-as stated below:
+This file postulates some simple rules for maintaing hg tree, as stated 
+below:
 
- 	1) It is strongly recommended that each developer be active at 
-IRC channels (irc://irc.freenode.net) #v4l (for analog) and/or #linuxtv 
-(for digital). It helps to have more discussions at major changes;
+1) It is strongly recommended that each developer be active at IRC 
+   channels (irc://irc.freenode.net) #v4l (for analog) and/or #linuxtv 
+   (for digital). It helps to have more discussions at major changes;
 
- 	2) Minor changes, like simple card additions (for example a 
-new card row at a card struct) can be applied directly by each 
-developer;
+2) Minor changes, like simple card additions (for example a new card 
+   row at a card struct) can be applied directly by each developer;
 
- 	3) Medium changes that needs modification on card coding or 
-creating a new card type should be discussed first at the Mailing Lists 
-video4linux-list@redhat.com (analog/common parts) and/or 
-linux-dvb@linuxtv.org to allow other contributors to discuss about the 
-way it will be included.
+3) Medium changes that needs modification on card coding or creating a 
+   new card type should be discussed first at the Mailing Lists 
+   video4linux-list@redhat.com (analog/common parts) and/or 
+   linux-dvb@linuxtv.org to allow other contributors to discuss about
+   the way it will be included.
 
- 	4) Major changes that implies changing some core structs 
-should be widely discussed on IRC, posted to the list, created a 
-snapshot THEN committed to the tip branch. It is strongly recommended 
-to use a branch or v4l_experimental area for such changes.
+4) Major changes that implies changing some core structs should be 
+   widely discussed on IRC, posted to the list, created a snapshot THEN 
+   committed to the tip branch. It is strongly recommended to use a branch 
+   or v4l_experimental area for such changes.
 
-  	5) Every CVS maintainer should follow the "rules of thumb" of 
-kernel development stated at Linux source code, especially:
+5) Every CVS maintainer should follow the "rules of thumb" of kernel 
+   development stated at Linux source code, especially:
 
 	Documentation/SubmittingPatches
 	Documentation/SubmittingDrivers
 	Documentation/CodingStyle
 
-	6) All commits should have a consistent message. On v4l-dvb, this is 
-done by using:
+6) All commits should have a consistent message. On v4l-dvb, this is 
+   done by using:
 
 	make commit
 
-	This will run some scripts that will check changed files, generating a
-ChangeLog like comment (that will be removed from the commit) and prepare the 
-last Signed-off-by field, as described bellow.
+   This will run some scripts that will check changed files, generating 
+   a ChangeLog like comment (that will be removed from the commit) and 
+   prepare the last Signed-off-by field, as described bellow.
 
-	7) Files can be added, removed or renamed at hg repository. This should
-be done by using:
+7) Files can be added, removed or renamed at hg repository. This should 
+   be done by using:
 	hg add <files>
 	hg remove <files>
 	hg rename <source> <dest>
 	hg addremove
 
-	*Warning* hg addremove will add/removes all files, including object files. 
-Be careful! You can remove wrongly added files with hg remove.
+   *Warning* hg addremove will add/removes all files, including object 
+   files. Be careful! You can remove wrongly added files with hg remove.
 
-	8) If the commit went wrong, hg allows you to undo the last commit, 
-by using the command:
+8) If the commit went wrong, hg allows you to undo the last commit, by 
+   using the command:
 
 	hg undo
 
-	This command will preserve the changes at the files. So, a new 
-hg commit will redo the desired commit.
+   This command will preserve the changes at the files. So, a new 
+   hg commit will redo the desired commit.
 
-	9) To push the change to the *MASTER* repository you need to run:
+9) To push the change to the *MASTER* repository you need to run:
 
 	make push
 
-	10) To update from the master repository, it is needed to do:
+10) To update from the master repository, it is needed to do:
 
 	make pull
 
-	11) For hg to work properly, these vars should be defined 
-(replacing the names at the left):
+11) For hg to work properly, these vars should be defined (replacing 
+    the names at the left):
 
-CHANGE_LOG_NAME="Maintainer Name" 
-CHANGE_LOG_EMAIL_ADDRESS=maintainer-email@cvsmaintainersite.com 
-CHANGE_LOG_LOGIN=my_log_name
+    HGUSER="Maintainer Name" <maintainer-email@cvsmaintainersite.com>
 
-HGUSER=$CHANGE_LOG_NAME
-export CHANGE_LOG_NAME CHANGE_LOG_EMAIL_ADDRESS CHANGE_LOG_LOGIN HGUSER
+    If you use a different login name at the repo, you may use:
 
-	It is recommended to have these lines at .bashrc or .profile.
+    CHANGE_LOG_LOGIN=my_log_name
 
-	12) All commit messages shall have a Developers Certificate of Origin
-version 1.1 at commit log, as postulated at kernel's source at:
+    You may also have it at ~/.hgrc, but, in this case, make commit will not
+    generate From: and Signed-off-by fields automatically.
+
+    Don't forget to export the vars, like:
+
+    export CHANGE_LOG_LOGIN HGUSER
+
+    It is strongly recommended to have these lines at .bashrc or .profile.
+
+12) All commit messages shall have a Developers Certificate of Origin
+    version 1.1 at commit log, as postulated at kernel's source at:
 
 	Documentation/SubmittingPatches
 
-	This is done by using Signed-off-by: fields at hg commit message.
+    This is done by using Signed-off-by: fields at hg commit message.
+
+    It is not acceptable to use fake signatures like:
 
-	It is not acceptable to use fake signatures like:
 	Signed-off-by: Fake me <me@snakeoilcompany.com>
 
-	The email should be a valid one.
-	The bottom signed-off-by should be the commiter.
+    The email should be a valid one.
+    The bottom signed-off-by should be the commiter.
  
-        13) Commit messages are very relevant, since they will be used 
-when generating the patches for v4l-dvb.git and to mainstream.
+13) Commit messages are very relevant, since they will be used 
+    when generating the patches for v4l-dvb.git and to mainstream.
 
-       The format of commit message shall be:
+    The format of commit message shall be:
 
-patch subject
-From: Patch Developer <patchdeveloper@patchdevelopersite.com>
+    patch subject
+    From: Patch Developer <patchdeveloper@patchdevelopersite.com>
 
-patch descriptions
+    patch descriptions
 
-Signed-off-by: Patch Developer <patchdeveloper@patchdevelopersite.com>
-Signed-off-by: Cvs Maintainer <cvsmaintainer@cvsmaintainersite.com>
+    Signed-off-by: Patch Developer <patchdeveloper@patchdevelopersite.com>
+    Signed-off-by: Cvs Maintainer <cvsmaintainer@cvsmaintainersite.com>
 
-	All lines starting with # will be removed by make commit stripts.
+    All lines starting with # will be removed by make commit stripts.
 
-	Subject should be a brief description of the patch. Please 
-notice that, with hg, there's no need (and not desired) to define a 
-Subject: tag. The first msg line will be used as subject, just like 
-git.
+    Subject should be a brief description of the patch. Please 
+    notice that, with hg, there's no need (and not desired) to define a 
+    Subject: tag. The *first* msg line will be used as subject, just like 
+    git.
+    *WARNING* Be careful not to leave the first line blank, otherwise hg
+    will leave subject in blank.
 
-	From: shouldn't be suppressed
+    From: line shouldn't be suppressed, since it will be used when 
+    converting to -git as patch author.
 
-	You may add other signers, if the patch were tested by somebody 
-else and he also wants to sign. The committer signed-off-by should be 
-the last one.
+    You may add other signers, if the patch were tested /co-developed 
+    by somebody else and he also wants to sign. The committer 
+    signed-off-by should be the last one.
 
-	14) If the patch also affects other parts of kernel (like alsa 
-or i2c), it is required that, at upstream submitting, the patch also goes
-to the maintainers of that subsystem. To do this, CVS maintainer shall 
-add one or more cc: fields to the commit message, after the subject:
+14) If the patch also affects other parts of kernel (like alsa 
+    or i2c), it is required that, at upstream submitting, the patch 
+    also goes to the maintainers of that subsystem. To do this, CVS 
+    maintainer shall add one or more cc: fields to the commit message, 
+    after the subject:
 
-CC: someotherkerneldeveloper@someplace
+    CC: someotherkerneldeveloper@someplace
 
-	Please notice that this is manually handled by the -git 
-maintainer, so unnecessary usage should be avoided.
+    Please notice that this is manually handled by the -git maintainer, 
+    so unnecessary usage should be avoided.
 
-	15) Sometimes, mainstream changes do affect v4l-dvb tree, and 
-requires to apply some kernel patches at the tree. This kind of commit 
-should follow the rules above and should also have a line like:
+15) Sometimes, mainstream changes do affect v4l-dvb tree, and requires 
+    to apply some kernel patches at the tree. This kind of commit should 
+    follow the rules above and should also have a line like:
 
-kernel-sync
+    kernel-sync
 
-	Patches with such lines will not be submitted upstream.
+    Patches with such lines will not be submitted upstream.
 
-	16) sometimes it is necessary to introduce some testing code 
-inside a module or remove parts that are not yet finished. Also, 
-compatibility tests may be required to provide backporting.
+16) sometimes it is necessary to introduce some testing code inside a 
+    module or remove parts that are not yet finished. Also, compatibility 
+    tests may be required to provide backporting.
 
-	To allow compatibility tests,  "compat.h" should be included
-first. It does include also linux/version.h.
+    To allow compatibility tests, "compat.h" should be included first. 
+    It does include also linux/version.h.
 
-	To include testing code, #if 0 or #if 1 may be used.
-If this code is meant to go also to kernel, this struct should be used:
+    To include testing code, #if 0 or #if 1 may be used. If this code 
+    is meant to go also to kernel, this struct should be used:
 
-#if 0 /* keep */
+    #if 0 /* keep */
 	or
-#if 1 /* keep */
+    #if 1 /* keep */
 
-	17) Nested #ifs are allowed, but the #elif macro shouldn't be 
-used, since the macro preprocessing script used to prepare kernel 
-upstream patches (v4l/scripts/gentree.pl) is not able to handle it.
+17) Nested #ifs are allowed, but the #elif macro shouldn't be used, 
+    since the macro preprocessing script used to prepare kernel upstream 
+    patches (v4l/scripts/gentree.pl) is not able to handle it.
 
 Cheers,
 Mauro