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 ) 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 ; Tue, 6 Apr 2010 07:29:30 +0000 (UTC) Received: by bwz23 with SMTP id 23so1570888bwz.26 for ; 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 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: In-Reply-To: Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail 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: 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: 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: 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