From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from lists.gentoo.org (pigeon.gentoo.org [208.92.234.80]) by finch.gentoo.org (Postfix) with ESMTP id 08B7659CAF for ; Sun, 10 Apr 2016 22:21:59 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 77B7221C01F; Sun, 10 Apr 2016 22:21:52 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id 8703F21C005 for ; Sun, 10 Apr 2016 22:21:51 +0000 (UTC) Received: from [192.168.1.100] (c-98-218-46-55.hsd1.md.comcast.net [98.218.46.55]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) (Authenticated sender: mjo) by smtp.gentoo.org (Postfix) with ESMTPSA id 2835D34082B for ; Sun, 10 Apr 2016 22:21:50 +0000 (UTC) Subject: Re: [gentoo-dev] CVS headers in ebuilds To: gentoo-dev@lists.gentoo.org References: <22273.33734.119435.731152@a1i15.kph.uni-mainz.de> <20160404085853.6e57080c@shanghai.paradoxon.rec> <57033F57.7090204@gentoo.org> <20160409101243.GA3564@lightningfox> <20160409141211.09f1293f@shanghai.paradoxon.rec> <22282.31813.77241.710735@a1i15.kph.uni-mainz.de> From: Michael Orlitzky X-Enigmail-Draft-Status: N1110 Message-ID: <570AD1F8.7080905@gentoo.org> Date: Sun, 10 Apr 2016 18:21:44 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.7.0 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 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit X-Archives-Salt: 7a3a9ef5-8951-4c5a-8e0e-090f52de4f38 X-Archives-Hash: 846fa0280b9d31e909871309a3b7a451 On 04/10/2016 05:36 PM, Gordon Pettey wrote: > Or you could just use a branching workflow like Git has great support > for, and create your overlay as a branch of the main tree you're copying > ebuilds from. With recent versions, you can even have checkouts of > different branches from the same tree in different directories, so > you're not duplicating the the whole repository. Then you could just git > diff from the master branch, and no need for preserving CVS misbehavior. > I suggested this on the bug, but it's not so clear-cut. With a branch, you have a million other ebuilds sitting around in "your overlay" that you don't care about. I'm also not sure how the metadata updates would work; like, if it would be efficient to pull the rsync metadata and then run `emerge --metadata` or something like that. It wouldn't be fair to say "just use a branch!" if that's going to mean that somebody's day-to-day work gets a lot slower. I would also feel a little guilty saying that the supported way of extending/modifying the tree (overlays) won't work and you have to branch off our VCS. I promised to think about it, but haven't had much inspiration. Here's the best I've got so far. 1. Use git for your ::gentoo tree. 2. Before every sync (git pull), save the current HEAD: OLD=$(git rev-parse --verify HEAD) 3. git pull 4. Save the new HEAD: NEW=$(git rev-parse --verify HEAD) 5. Search through the log (between the old HEAD and the new one) for any files that were modified: git log $OLD..$NEW --format='' --name-status \ | grep '^M.*ebuild' \ | cut -f2 \ | sort \ | uniq That gives you a nice list at least, and you can compare it to the files present in your overlay. If you add another | xargs git log --stat $OLD..$NEW onto the end of that last command, you can see statistics on what changes were made. (Holy crap do we have a lot of people editing dependencies without making revision bumps.)