From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1Vm5MW-0003r9-US for mharc-grub-devel@gnu.org; Thu, 28 Nov 2013 12:26:48 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:36607) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vm5MR-0003qb-Gd for grub-devel@gnu.org; Thu, 28 Nov 2013 12:26:47 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vm5MN-00063v-9v for grub-devel@gnu.org; Thu, 28 Nov 2013 12:26:43 -0500 Received: from mail-lb0-x231.google.com ([2a00:1450:4010:c04::231]:51891) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vm5MM-00063p-U0 for grub-devel@gnu.org; Thu, 28 Nov 2013 12:26:39 -0500 Received: by mail-lb0-f177.google.com with SMTP id w7so6318100lbi.36 for ; Thu, 28 Nov 2013 09:26:37 -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=CeVpqhTeSVgbQozlgnqNG+bOmj0D/WwSyB29P1lZXAM=; b=OeOtbLUoW958GxbJvsefBnre8lZvHBq9iT/EZV/08lzuETdE9iD3v8upHnDdTpFC1s 95ZW19JbJFRVP7fOb+ya6iyAeflKj1T4De3MdfRd9dyUaw7wnrW2bjO5VvcMZK6dPmNU qPJHXL6Yy0gW+dcCPPfiIgCAtxg/hLt0TSRagEKJNxeUPPgzkoUJ/fITfhFM+72uQajM lUjIBDdL8zuhmwUAPUnrkI4yvSgJI9RJ7IZ4wjhS2QcOsm+5VeqiWXjepQvDu7gq7iz+ MVYKA8LrqY7ISCpw16C3sLFbE6d+PotletQfIf7OXSgWxfMxkttMwvGeesN96ybWFbiU ncEw== X-Received: by 10.152.120.102 with SMTP id lb6mr4793214lab.37.1385659597861; Thu, 28 Nov 2013 09:26:37 -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 i8sm19682165lbh.2.2013.11.28.09.26.36 for (version=SSLv3 cipher=RC4-SHA bits=128/128); Thu, 28 Nov 2013 09:26:37 -0800 (PST) Date: Thu, 28 Nov 2013 21:26:36 +0400 From: Andrey Borzenkov To: grub-devel@gnu.org Subject: Re: GIT workflow Message-ID: <20131128212636.61e5bbbe@opensuse.site> In-Reply-To: References: <527FBC01.5010509@gmail.com> <5284CE0A.6090703@peda.net> <20131125222642.0f84c87b@opensuse.site> 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:c04::231 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: Thu, 28 Nov 2013 17:26:47 -0000 =D0=92 Thu, 28 Nov 2013 07:45:00 +0100 "Vladimir 'phcoder' Serbinenko" =D0=BF=D0=B8=D1=88=D0= =B5=D1=82: > I don't like the idea of double work to essentially have 2 commit message= s. > But it's possible to remove Changelog file. I'd like to know if any other > major gnu projects made the move. Oh, I did not dare to ask but if you mention it :) Yes, ChangeLog is the major source of merge conflicts and makes it impossible to cleanly cherry-pick patches for package maintenance. So please ...=20 > On Nov 25, 2013 7:27 PM, "Andrey Borzenkov" wrote: >=20 > > =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/Helsinki): > > > > 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 poin= ts: > > > > - Developpers with commit access can create branches as they see fi= t 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 th= at > > > > squash should be possible if developper desires. Is there any reaso= n to > > > > use merges? > > > > > > Squashed merge is identical to rebase && merge --no-ff except for the > > > detail that squashing loses any meaningful history for the patch seri= es. > > > I'd seriously suggest rebase followed by merge --no-ff over squashed > > > merges. The only exception is the case where commits in the original > > > work are not logical patches but instead random snapshots of the > > > directory tree during development of the patch. In that case, squashi= ng > > > the patch series loses no valuable information. > > > > > > The reason to keep patch series: git bisect > > > > > > > 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). > > > > > > - Which commits should we sign? All? Some? Official releases? > > > > > > Depends on what you mean by "sign". If you mean > > > > > > Signed-off-by: A U Thor > > > > > > that's the "Developer Certificate Of Origin": > > > http://elinux.org/Developer_Certificate_Of_Origin > > > > > > Other projects (e.g Grub) can decide their own policy for such metada= ta. > > > Additional info is available at > > > > > http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature= -in-git-for > > > > > > If you mean digitally signed, the correct method is to use signed tags > > > for all the releases meant for non-developers. See "git help tag" and > > > look for "--sign". > > > > > > > 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"? > > > > _______________________________________________ > > Grub-devel mailing list > > Grub-devel@gnu.org > > https://lists.gnu.org/mailman/listinfo/grub-devel > >