From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from list by lists.gnu.org with archive (Exim 4.71) id 1VgwqX-0007FX-VQ for mharc-grub-devel@gnu.org; Thu, 14 Nov 2013 08:20:33 -0500 Received: from eggs.gnu.org ([2001:4830:134:3::10]:40096) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgwqR-0007Cj-AX for grub-devel@gnu.org; Thu, 14 Nov 2013 08:20:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1VgwqI-00047R-MC for grub-devel@gnu.org; Thu, 14 Nov 2013 08:20:27 -0500 Received: from posti8.jyu.fi ([130.234.5.35]:37720) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VgwqI-00046z-BI for grub-devel@gnu.org; Thu, 14 Nov 2013 08:20:18 -0500 Received: from localhost (localhost.localdomain [127.0.0.1]) by posti8.jyu.fi (8.13.8/8.13.8) with ESMTP id rAEDKEwS015902; Thu, 14 Nov 2013 15:20:14 +0200 X-Virus-Scanned: amavisd-new at cc.jyu.fi Received: from posti8.jyu.fi ([127.0.0.1]) by localhost (posti8.jyu.fi [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id z7oGVzjnswuG; Thu, 14 Nov 2013 15:20:11 +0200 (EET) Received: from [130.234.78.125] (semyol-329-b.ktl.jyu.fi [130.234.78.125]) (authenticated bits=0) by posti8.jyu.fi (8.13.8/8.13.8) with ESMTP id rAEDKAvY015897 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NO); Thu, 14 Nov 2013 15:20:11 +0200 Message-ID: <5284CE0A.6090703@peda.net> Date: Thu, 14 Nov 2013 15:20:10 +0200 From: Mikko Rantalainen User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.1.0 MIME-Version: 1.0 To: grub-devel@gnu.org Subject: Re: GIT workflow References: <527FBC01.5010509@gmail.com> In-Reply-To: <527FBC01.5010509@gmail.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-MIME-Autoconverted: from 8bit to quoted-printable by posti8.jyu.fi id rAEDKEwS015902 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 130.234.5.35 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, 14 Nov 2013 13:20:32 -0000 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 som= e > 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? 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. The reason to keep patch series: git bisect > - 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 metadata.=20 Additional info is available at=20 http://stackoverflow.com/questions/1962094/what-is-the-sign-off-feature-i= n-git-for 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 Mikko