From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Vl0s4-0008Iz-B9 for mharc-grub-devel@gnu.org; Mon, 25 Nov 2013 13:26:56 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40846) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vl0rx-0008Hy-NC for grub-devel@gnu.org; Mon, 25 Nov 2013 13:26:54 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vl0rt-0006N4-5R for grub-devel@gnu.org; Mon, 25 Nov 2013 13:26:49 -0500 Received: from mail-la0-x232.google.com ([2a00:1450:4010:c03::232]:52902) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vl0rs-0006N0-TV for grub-devel@gnu.org; Mon, 25 Nov 2013 13:26:45 -0500 Received: by mail-la0-f50.google.com with SMTP id el20so3346991lab.37 for ; Mon, 25 Nov 2013 10:26:43 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=date:from:to:subject:message-id:in-reply-to:references:mime-version :content-type:content-transfer-encoding; bh=T/gRaR0TGbpcwamBIKwUOBE+SwUwK2UamfggMSlAMEA=; b=e3AN2J4mDzp+fRdc1staFff6V6OUjyW1OaLfGunmuDCEaOMzBqJ7iQ3ozdDUNiB/EX P/6MahCokxqwb4ugo3O2L0Dx02NyTaCX2irG74DfoyHu5byyBrxtPJBtHHrUYqQRlplh eZfwqksEHtblKHcNxAvZj67hxfkbvfSyBnNUQOXI3YRDv0b5ERbZXtGK5hBDXbnQvQxV lzkgmyYEBpG07CSAAILGRZzk1uW3DA819++gcLyQHzMDhGaXFPsd3UFmioXR3S8EEJVX bg2lMYGE+Cx8rtncRQW2OQr++k1Jz70Dh2DbvuuXSiDtvQ9u1ein4+T8kTjWRdBCekSB INXg== X-Received: by 10.112.72.233 with SMTP id g9mr22826044lbv.2.1385404003852; Mon, 25 Nov 2013 10:26:43 -0800 (PST) Received: from opensuse.site (ppp91-76-170-113.pppoe.mtu-net.ru. [91.76.170.113]) by mx.google.com with ESMTPSA id c10sm35780054lbd.9.2013.11.25.10.26.43 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Mon, 25 Nov 2013 10:26:43 -0800 (PST) Date: Mon, 25 Nov 2013 22:26:42 +0400 From: Andrey Borzenkov To: grub-devel@gnu.org Subject: Re: GIT workflow Message-ID: <20131125222642.0f84c87b@opensuse.site> In-Reply-To: <5284CE0A.6090703@peda.net> References: <527FBC01.5010509@gmail.com> <5284CE0A.6090703@peda.net> X-Mailer: Claws Mail 3.9.2 (GTK+ 2.24.18; x86_64-suse-linux-gnu) Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:4010:c03::232 X-BeenThere: grub-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list Reply-To: The development of GNU GRUB List-Id: The development of GNU GRUB List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Nov 2013 18:26:54 -0000 =D0=92 Thu, 14 Nov 2013 15:20:10 +0200 Mikko Rantalainen =D0=BF=D0=B8=D1=88=D0=B5=D1= =82: > Vladimir '=CF=86-coder/phcoder' Serbinenko, 2013-11-10 19:01 (Europe/Hels= inki): > > Hello, all. We've switched to git some time ago, now we should have some > > kind of workflow documents. In particular I think of following points: > > - Developpers with commit access can create branches as they see fit as > > long as it's prefixed by their name and they don't do sth nasty like > > storing binary or unrelated files. > > - When committing bigger work should we merge or squash? I think that > > squash should be possible if developper desires. Is there any reason to > > use merges? >=20 > Squashed merge is identical to rebase && merge --no-ff except for the=20 > detail that squashing loses any meaningful history for the patch series.= =20 > I'd seriously suggest rebase followed by merge --no-ff over squashed=20 > merges. The only exception is the case where commits in the original=20 > work are not logical patches but instead random snapshots of the=20 > directory tree during development of the patch. In that case, squashing=20 > the patch series loses no valuable information. >=20 > The reason to keep patch series: git bisect >=20 Also squash is losing individual contribution. I think it really depends. For simple patches that are self-contained squash is actually better; that is basically what TopGIT does to maintain patches. For anything developed over long time history should be preserved (a.k.a. merge).=20 > > - Which commits should we sign? All? Some? Official releases? >=20 > Depends on what you mean by "sign". If you mean >=20 > Signed-off-by: A U Thor >=20 > that's the "Developer Certificate Of Origin": > http://elinux.org/Developer_Certificate_Of_Origin >=20 > Other projects (e.g Grub) can decide their own policy for such metadata.= =20 > Additional info is available at=20 > http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-i= n-git-for >=20 > If you mean digitally signed, the correct method is to use signed tags=20 > for all the releases meant for non-developers. See "git help tag" and=20 > look for "--sign". >=20 Release tags should better be signed; is there official key to be used in this case? I have additional topic - format of commit message Established GIT commit message is single summary line followed by more extensive description if necessary. Quite a number of git commands and wrappers around git assume that the summary line is present. Currently commit message format is near to useless. Half of the first line is lost for file name; the second half is partial sentence, often meaningless. Could we break with tradition "commit message" =3D=3D "ChangeLog entry"?