From mboxrd@z Thu Jan 1 00:00:00 1970
Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org)
by finch.gentoo.org with esmtp (Exim 4.60)
(envelope-from <gentoo-dev+bounces-40583-garchives=archives.gentoo.org@lists.gentoo.org>)
id 1Nz3EP-0006rn-AY
for garchives@archives.gentoo.org; Tue, 06 Apr 2010 07:29:53 +0000
Received: from pigeon.gentoo.org (localhost [127.0.0.1])
by pigeon.gentoo.org (Postfix) with SMTP id DB7D6E09A2;
Tue, 6 Apr 2010 07:29:48 +0000 (UTC)
Received: from mail-bw0-f223.google.com (mail-bw0-f223.google.com [209.85.218.223])
by pigeon.gentoo.org (Postfix) with ESMTP id BB79BE08FC
for <gentoo-dev@lists.gentoo.org>; Tue, 6 Apr 2010 07:29:30 +0000 (UTC)
Received: by bwz23 with SMTP id 23so1570888bwz.26
for <gentoo-dev@lists.gentoo.org>; Tue, 06 Apr 2010 00:29:30 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
d=gmail.com; s=gamma;
h=domainkey-signature:received:received:from:to:subject:date
:user-agent:references:in-reply-to:disposition-notification-to
:mime-version:content-type:content-transfer-encoding:message-id;
bh=tcnnsJ9KozYJsAqKU8MeSUWs3a09l7hYI9rYYHogLwo=;
b=JRJwXWKuKo5MNFn7PwIGHplv+o8LLdjCiZ21eDA3+nBpbIK9aISFRGzwKG5I+fQaTQ
/LSBx1m5qOInZB4x/4GBvBi8bMMZmCm3OVg2sfefC5iOm15oCCNG/gziCLUo5HpKbAMa
tEr7VBTgIiQKRH1cE05lSbA5wZKq+H4dx9CBA=
DomainKey-Signature: a=rsa-sha1; c=nofws;
d=gmail.com; s=gamma;
h=from:to:subject:date:user-agent:references:in-reply-to
:disposition-notification-to:mime-version:content-type
:content-transfer-encoding:message-id;
b=BmCdIgPWjuX8Fq3gkFZdKWEw0oK5pRYyBnBW+PpvDQGrIHRGhXXoOvDVIGWa2uOP7k
mM1C3lgVWqcpTH+QWlCZdINRNXI5t8yDzv19lWwyPOYUryjtiGe1zRnnm9M/eY6AM3ca
6BE3D0vunXFflo6VEJ0J46OG3xBnZnCAdhmLY=
Received: by 10.204.134.151 with SMTP id j23mr344640bkt.17.1270538970055;
Tue, 06 Apr 2010 00:29:30 -0700 (PDT)
Received: from lebrodyl.localnet (bro64.neoplus.adsl.tpnet.pl [83.29.108.64])
by mx.google.com with ESMTPS id 14sm5968051bwz.6.2010.04.06.00.29.29
(version=SSLv3 cipher=RC4-MD5);
Tue, 06 Apr 2010 00:29:29 -0700 (PDT)
From: Maciej Mrozowski <reavertm@gmail.com>
To: gentoo-dev@lists.gentoo.org
Subject: Re: [gentoo-dev] [git migration] Proposition for tags supported by git hooks
Date: Tue, 6 Apr 2010 09:28:49 +0200
User-Agent: KMail/1.13.2 (Linux/2.6.31-gentoo-r10; KDE/4.4.2; x86_64; ; )
References: <y2h8b4c83ad1004051913je48d03eat3af5f26b7500428f@mail.gmail.com>
In-Reply-To: <y2h8b4c83ad1004051913je48d03eat3af5f26b7500428f@mail.gmail.com>
Precedence: bulk
List-Post: <mailto:gentoo-dev@lists.gentoo.org>
List-Help: <mailto:gentoo-dev+help@lists.gentoo.org>
List-Unsubscribe: <mailto:gentoo-dev+unsubscribe@lists.gentoo.org>
List-Subscribe: <mailto:gentoo-dev+subscribe@lists.gentoo.org>
List-Id: Gentoo Linux mail <gentoo-dev.gentoo.org>
X-BeenThere: gentoo-dev@lists.gentoo.org
Reply-to: gentoo-dev@lists.gentoo.org
MIME-Version: 1.0
Content-Type: Text/Plain;
charset="utf-8"
Content-Transfer-Encoding: 7bit
Message-Id: <201004060928.50259.reavertm@gmail.com>
X-Archives-Salt: de14dafe-3b98-4b5f-8924-825888ffbcaa
X-Archives-Hash: ad321f8c14eed753ed8eab7368341cb1
On Tuesday 06 of April 2010 04:13:02 Nirbheek Chauhan wrote:
> One of the few remaining problems to be solved for the migration to
> git for our gentoo-x86/ and gentoo/ trees (besides other
> projects/overlays) is the problem of how to handle ChangeLogs.
Great that you touched this topic.
> ========
> Problems:
> ========
> * Messages in ChangeLog are not always the same as the commit messages
> (~1% are different)
> * Some people place additional information in the commit message which
> is intended only for developer use
> - Most of the difference in ChangeLog/commit messages comes from this
> * Trivial changes are often not documented in ChangeLogs
> - This is upto the developer's personal preference
> - Some folks do this because of the extra time it takes
> + This use-case becomes irrelevant due to automatic generation of
> ChangeLog
>
> ========
> Solutions:
> ========
> * Do not re-generate the existing ChangeLog; rather make the ChangeLog
> generation script smart enough to only append
> - Solves the "messages not same" problem for existing commits
I don't think its' good idea, changelog should reflect state of remote
repository, not the state of local clone. Besides storing Changelog is simply
redundant and would increase repository size unnecessarily. It already
increases rsync size considerably.
> * Use a separator in the commit message like "== \n" to denote that
> everything after this is dev-only information and should be skipped
> from the user ChangeLog
> - Solves the problem for people who like to add extra dev-only info
> in the CVS commit message
> * Ignore commits with "[$tag][trivial]" in the tag[2] from being added
> to ChangeLog
> - Keeps the wishes of the developer and does not pollute ChangeLog
> with such info
Both would work fine, maybe tag syntax could be improved - certainly we want
it error prone and relatively simple to use - I've moved it to separate
subthread.
Maybe something like this: (modeled a bit after KDE tags allowed in svn
messages):
Each entry in its own line in commit message:
BUG: <bugnumber>
Marks the bug as RESO/FIXED, as comment adding full git commit message
with tags removed and just below gitweb URL corresponding to this
particular commit. For bugzilla, instead of full gitweb URL, maybe make
bugzilla aware of hashes in comments and expand gitweb links
automatically
CCBUG: <bugnumber>
Adds comment to the bugreport containing full git commit message with
tags removed and just below gitweb URL corresponding to this particular
commit. For bugzilla, instead of full gitweb URL, maybe make
bugzilla aware of hashes in comments and expand gitweb links
automatically
CCMAIL: <one-email-address>
Sends email to given address containing full git commit message with
tags removed and just below gitweb URL corresponding to this particular
commit
SILENT:
Marks entire commit message as "silent" by adding "(silent)" to the
subject of the mail or adding some mail header to allow filtering out
trivial commits. (like those containing typo fixes in comments and
such). Such commits could also be skipped by ChangeLog generator.
I specifically don't like [tag][sth] format, because I'd suggest to impose
some guidelines to git commit messages:
- put [$CATEGORY/$PN] in first line of commit message for git commits
related to packages
- same with [$profile] for profiles or [package.mask] for p.mask,
[eclass/$ECLASS] etc
to make history a bit more readable, see example:
http://git.overlays.gentoo.org/gitweb/?p=proj/kde.git;a=summary
Also some number (for instance up to 80) of characters from first line could
be used as email Subject in CCMAIL, so I think it's vital to have it organized
a bit.
--
regards
MM