From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mga14.intel.com ([143.182.124.37]) by linuxtogo.org with esmtp (Exim 4.72) (envelope-from ) id 1UeV2s-00051i-02 for bitbake-devel@lists.openembedded.org; Mon, 20 May 2013 20:42:55 +0200 Received: from azsmga001.ch.intel.com ([10.2.17.19]) by azsmga102.ch.intel.com with ESMTP; 20 May 2013 11:23:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.87,709,1363158000"; d="scan'208";a="305276519" Received: from envy2.jf.intel.com (HELO envy2.home) ([10.24.0.129]) by azsmga001.ch.intel.com with ESMTP; 20 May 2013 11:23:21 -0700 Message-ID: <519A6A18.3050802@intel.com> Date: Mon, 20 May 2013 11:23:20 -0700 From: Darren Hart User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130110 Thunderbird/17.0.2 MIME-Version: 1.0 To: Richard Purdie References: <1368958915.32727.96.camel@ted> <20130519123255.GG3196@jama> <1369038832.1619.3.camel@ted> In-Reply-To: <1369038832.1619.3.camel@ted> Cc: "Ashfield, Bruce" , Koen Kooi , bitbake-devel , Martin Jansa Subject: Re: [PATCH] fetch2: Shorten long srcrevs X-BeenThere: bitbake-devel@lists.openembedded.org X-Mailman-Version: 2.1.11 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 20 May 2013 18:43:15 -0000 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit On 05/20/2013 01:33 AM, Richard Purdie wrote: > On Sun, 2013-05-19 at 14:32 +0200, Martin Jansa wrote: >> On Sun, May 19, 2013 at 01:21:55PM +0300, Richard Purdie wrote: >>> The long srcrevs are mainly used or the workdir construction as well as >>> the package version. The long entries are hashes generated by the git fetcher >>> and other scms using a similar revision mechanism. >>> >>> We need these to change when the package changes however collisions are >>> unlikely to happen within the domains we care about. The long revisions >>> have generated negative user feedback due to the use in path and file >>> names. >>> >>> This patch therefore truncates the revisions to 10 characters maximum. >> >> What about 7 characters like git log --oneline is using? > > git uses varying lengths depending on whether it detects collisions. I > really don't want to have to do the collision detection or worry about > this so 10 characters seemed like a nice number, its short enough to > address the complaints but long enough to avoid problems. Exactly. 10 seems like a good choice to me as well, it significantly reduces the path length while keeping the implementation simple and minimizing the chances of collisions. -- Darren Hart Intel Open Source Technology Center Yocto Project - Linux Kernel