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 A3C6C1388C0 for ; Mon, 22 Feb 2016 21:06:06 +0000 (UTC) Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 06C9C21C01C; Mon, 22 Feb 2016 21:05:58 +0000 (UTC) Received: from mail-ig0-f169.google.com (mail-ig0-f169.google.com [209.85.213.169]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by pigeon.gentoo.org (Postfix) with ESMTPS id EE9E721C011 for ; Mon, 22 Feb 2016 21:05:56 +0000 (UTC) Received: by mail-ig0-f169.google.com with SMTP id hb3so86002853igb.0 for ; Mon, 22 Feb 2016 13:05:56 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to; bh=KDu2fdJnU9N4CRcZRhaHb279K9dOPf4CNjQiJo1WsYU=; b=03BsEiaMzwMyeAkKTCBaxx1dhbEicGL7fNZmf4MBOB3P3ABmv9xEhhMm83vl4VB6GV UP4DuL5uEzOhXgDkFmmq0B5ktLJ9JMRuf2mjdHG0tBjqYwClCgPvLxvsKk8Q9xP54zEw M2/YS2y9cvUna7TJEeeqkTVDZPtO8DnzzM7w6/dHNH/9DTCc/3YEmP2xoffyvUAVzLDi ukNpzpx6dbdQP1rltOZkM6ZA4nMI8k4hABjDkUSEBDxlhNPJHg2hdY1WZvgNSV+RIg8J OsG6jRVXkId7yDO/HWO5thEAdwc/HVsuWNpggbVRG6p6fqkOCOF1kLdd3mpkItoWHKoX 2g1g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:sender:in-reply-to:references:date :message-id:subject:from:to; bh=KDu2fdJnU9N4CRcZRhaHb279K9dOPf4CNjQiJo1WsYU=; b=lrp1toVdBKGly1SfgB4BifsapD0D6rE3IfwV19YCD1bGqeUA0GAtVNZfjtwBoaOjJf DWrIgW8vSBeaUV9x6SwS2ff8z2vdbT2ArmcCh/6g7cEPsRKqLe0pomuBO51NiodkVbk1 5IGTxLJNsfs1naErn2O2IBDqRxJrqKV4hh7BIuoTtqubHmXtW4CDRixTUOQJ9PJYbMx3 Fmn5weLK5aLTts9icCehXZmEPsEhy3TnhoEKCzjPfglhkn6gGpJd9e5hQaGanqEpI3lc ti6Dlv/SjRvYesDGzTM9cGg6pf1asZqC9MZ1frJSVq+OYCkBkijtMhR9a31lw8fX+uTY QN1A== X-Gm-Message-State: AG10YOQAuMvhIZlQAAPBEmhlQJe9BFV1UrgSY5AGC+MrJdAGwyQT8bURl2CERV89wg5B/ffFQjzPV7rNgtiiPw== Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-Id: Gentoo Linux mail X-BeenThere: gentoo-user@lists.gentoo.org Reply-to: gentoo-user@lists.gentoo.org MIME-Version: 1.0 X-Received: by 10.50.57.11 with SMTP id e11mr12355352igq.75.1456175156300; Mon, 22 Feb 2016 13:05:56 -0800 (PST) Sender: freemanrich@gmail.com Received: by 10.64.225.232 with HTTP; Mon, 22 Feb 2016 13:05:56 -0800 (PST) In-Reply-To: References: Date: Mon, 22 Feb 2016 16:05:56 -0500 X-Google-Sender-Auth: UenAKuLDz7gZ9-A1w018W7g0uQM Message-ID: Subject: Re: [gentoo-user] Attic (cvs) -> ???(git) From: Rich Freeman To: gentoo-user@lists.gentoo.org Content-Type: text/plain; charset=UTF-8 X-Archives-Salt: 0ac4c830-99b4-46f7-a4af-852c68a17143 X-Archives-Hash: bd87b4ec991fd46cae5145bb14ded8fd On Mon, Feb 22, 2016 at 2:49 PM, James wrote: > > So using wget to fetch {package/files} from the gentoo attic was/is a reliable > exercise to build things removed from the tree, into one's > /usr/local/portage tree. It still works, but I'm guessing there is a now a > "github_way" to do this. cvs was file-oriented, and git is not, so I'll warn you up-front that finding deleted files is a bit of pita. > A Fully automated script? I could not find a > gentoo wiki page to such effect, nor any other suggested pathway, but surely > it exists? I guessing the gentoo's cvs_attic is deprecated now and thus > subject to removal in the near future? I don't think anybody has plans to get rid of the old cvs, but nothing new goes into it, so it is frozen in time as of the migration date. > I'd would be excited to see a specific example, using git on on of the > recently removed packages "app-misc/multimon" [1], which was just removed > from the portage tree, unless someone wants to use another example. That > package is about radio packets. The approach to take depends on whether you want to find EVERYTHING that has ever been deleted, or a specific thing, but ultimately it comes down to looking at the full log. Lots of good stuff can be found here: https://stackoverflow.com/questions/953481/find-and-restore-a-deleted-file-in-a-git-repository The way I'd do it is run "git log --diff-filter=D --summary" and search for multimon. That gives you the commit ID it was removed in. Then you want to checkout the commit before it. In this case doing that search will yield: commit 760e17fcbac1b8c04a96ab08306dbcc644131dfb Author: Pacho Ramos Date: Sat Feb 20 12:49:31 2016 Remove masked for removal packages ... delete mode 100644 app-misc/multimon/Manifest delete mode 100644 app-misc/multimon/files/multimon-1.0-flags.patch delete mode 100644 app-misc/multimon/files/multimon-1.0-includes.patch delete mode 100644 app-misc/multimon/files/multimon-1.0-prll.patch delete mode 100644 app-misc/multimon/metadata.xml delete mode 100644 app-misc/multimon/multimon-1.0-r2.ebuild delete mode 100644 app-misc/multimon/multimon-1.0-r3.ebuild ... Then what you want to do is checkout the previous commit: git checkout "760e17fcbac1b8c04a96ab08306dbcc644131dfb^1" Now you're looking at the repo containing the last known state of those files, so you can just copy them or cat them from the directory tree: cat app-misc/multimon/multimon-1.0-r3.ebuild You could build all that into a script. If I were doing anything too crazy with all this I'd probably use the python git module. Then you'll get all your query results in collections and such instead of having to parse all that output. If you do want to parse you can control the output of git log. I will say that deleted files are one of those things that isn't as pretty in git. It isn't like a file with a deleted state flag that you can search by - they're identified by their presence in one commit and absence in the next. In fact, to identify them I'd think that git-log has to basically has to diff every tree for every commit historically. That isn't as bad as it sounds as each directory is shared with the previous commit COW-style - so if only one subdirectory contains changes only that directory needs to be walked to find what those differences are, and so on. The structure of our repository leads to a relatively well-balanced tree with fairly few levels, which is a good case for git. When I did the git validation I had to walk all of it and doing it smartly in parallel you can get it done remarkably quickly even in python (considering we have 2M commits, which is 2M* files you could have to diff in the brute force approach). -- Rich