From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from pigeon.gentoo.org ([208.92.234.80] helo=lists.gentoo.org) by finch.gentoo.org with esmtp (Exim 4.60) (envelope-from ) id 1QS2sy-0005Yb-46 for garchives@archives.gentoo.org; Thu, 02 Jun 2011 08:04:17 +0000 Received: from pigeon.gentoo.org (localhost [127.0.0.1]) by pigeon.gentoo.org (Postfix) with SMTP id 8C1361C09C for ; Thu, 2 Jun 2011 08:04:07 +0000 (UTC) Received: from smtp.gentoo.org (smtp.gentoo.org [140.211.166.183]) by pigeon.gentoo.org (Postfix) with ESMTP id 80E611C051 for ; Thu, 2 Jun 2011 07:30:09 +0000 (UTC) Received: from localhost (localhost [127.0.0.1]) by smtp.gentoo.org (Postfix) with ESMTP id 114B21B4021 for ; Thu, 2 Jun 2011 07:30:09 +0000 (UTC) X-Virus-Scanned: by amavisd-new using ClamAV at gentoo.org X-Spam-Score: -4.534 X-Spam-Level: X-Spam-Status: No, score=-4.534 required=5.5 tests=[AWL=2.065, BAYES_00=-2.599, RCVD_IN_DNSWL_MED=-4] Received: from smtp.gentoo.org ([127.0.0.1]) by localhost (smtp.gentoo.org [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id TMW0H7+JBkpc for ; Thu, 2 Jun 2011 07:29:59 +0000 (UTC) Received: from lo.gmane.org (lo.gmane.org [80.91.229.12]) by smtp.gentoo.org (Postfix) with ESMTP id 312341BC013 for ; Thu, 2 Jun 2011 07:29:58 +0000 (UTC) Received: from list by lo.gmane.org with local (Exim 4.69) (envelope-from ) id 1QS2Lq-0006LE-No for gentoo-dev@gentoo.org; Thu, 02 Jun 2011 09:29:54 +0200 Received: from ip68-231-22-224.ph.ph.cox.net ([68.231.22.224]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Jun 2011 09:29:54 +0200 Received: from 1i5t5.duncan by ip68-231-22-224.ph.ph.cox.net with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 02 Jun 2011 09:29:54 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: gentoo-dev@lists.gentoo.org From: Duncan <1i5t5.duncan@cox.net> Subject: [gentoo-dev] Re: RFC: better policy for ChageLogs Date: Thu, 2 Jun 2011 07:29:44 +0000 (UTC) Message-ID: References: <4DD24EBE.5060002@gentoo.org> <201106011739.45691.dilfridge@gentoo.org> <201106011824.06028.dilfridge@gentoo.org> <4DE6CB57.5080709@gentoo.org> <1306991344.4416.37.camel@tablet> 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 Content-Type: text/plain; charset=UTF-8 X-Complaints-To: usenet@dough.gmane.org X-Gmane-NNTP-Posting-Host: ip68-231-22-224.ph.ph.cox.net User-Agent: Pan/0.134 (Wait for Me; GIT 717b0ac branch-testing) Content-Transfer-Encoding: quoted-printable X-Archives-Salt: X-Archives-Hash: 043baf53f1d32160ec0ecd1766d5ff48 Peter Volkov posted on Thu, 02 Jun 2011 09:09:04 +0400 as excerpted: >> One of the huge benefits in using git would be really fast emerge >> --syncs. Not having some kind of system for migrating users to git >> seems like a lot of the benefits are lost. >=20 > Is git faster then rsync? I've never done any checks but it'll be > surprising if it will. That's a question that has come up before. I don't know the answer... > Another useful feature of rsync is --exclude that > allows some categories to be excluded (for size and speed efficiency), > e.g. my servers don't need kde-* and games-*. Git has similar options in the form of the .git/info/exclude file at the=20 (local) repository level, and .gitignore files at the subdir level (these= =20 are normally synced with the repo but of course can be excluded locally b= y=20 the above repository level file, if desired). Patterns similar to those used by rsync --exclude are even supported. =3D= :^) See also the git config core.excludefile command (git-config (1) manpage)= =20 and the gitignore (5) manpage. > Also taking into account > that we use portage tree on embedded devices where again both size and > speed really matters it looks like the answer on your question is > "permanently". With shallow checkouts, the size aspect is somewhat mitigated. However,=20 it may be that there'd be three user sync options, adding git, to the=20 current two (rsync and webrsync). IMO it'd be a real shame to not make the git sync option available to the= =20 user, as a number of projects have already discovered that real community= =20 involvement at the GOOD bug report and above level can increase=20 dramatically after a switch to git, due to the vastly increased=20 accessibility and ease of use of tools such as git bisect. But the *REAL* decison on whether git is ultimately made available at the= =20 user level or not will probably be infra's to make, based not on the=20 above, but on the very practical question of whether Gentoo's mirror=20 infrastructure can actually handle the git-pull load. After all, that's=20 said to be the reason the CVS tree isn't made directly available to=20 ordinary users today. Git should be better than CVS in that regard, but=20 will it be good /enough/ as compared to the resources demanded by rsync,=20 or not? That I don't know, tho I suspect infra and/or the git upgrade=20 project already has a reasonably educated opinion on the matter. Of course, someone like Google donating enough hardware and bandwidth to=20 "make it happen", based on, say, their use of Gentoo as a basis for=20 ChromeOS, thus making a healthy Gentoo good for them too, might help infr= a=20 with its decision. One can hope. =3D:^) --=20 Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman