From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Barry Warsaw Newsgroups: gmane.emacs.devel Subject: Re: PROPOSAL: Move to git, now that bzr is no longer a req. Date: Sat, 4 Jan 2014 23:49:43 -0500 Organization: Damn Crazy Followers of the Horn Message-ID: <20140104234943.1455d96b@anarchist.wooz.org> References: <20140102095347.6834E381D0C@snark.thyrsus.com> <87fvp6bdd9.fsf_-_@ktab.red-bean.com> <83wqiixqbb.fsf@gnu.org> <83ob3uxfr2.fsf@gnu.org> <87wqihdxsw.fsf@bzg.ath.cx> <83y52xw4bh.fsf@gnu.org> <87ha9kkejn.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; boundary="Sig_/IJkglf+vy2OHSKiZY/r+QuT"; protocol="application/pgp-signature" X-Trace: ger.gmane.org 1388897421 460 80.91.229.3 (5 Jan 2014 04:50:21 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 5 Jan 2014 04:50:21 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sun Jan 05 05:50:27 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1VzffO-0001Ei-Vy for ged-emacs-devel@m.gmane.org; Sun, 05 Jan 2014 05:50:27 +0100 Original-Received: from localhost ([::1]:56629 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzffO-0002CC-LX for ged-emacs-devel@m.gmane.org; Sat, 04 Jan 2014 23:50:26 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49785) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1VzffE-0002C4-2b for emacs-devel@gnu.org; Sat, 04 Jan 2014 23:50:23 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1Vzff6-0000qQ-Nw for emacs-devel@gnu.org; Sat, 04 Jan 2014 23:50:16 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:42992) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1Vzff6-0000pj-EA for emacs-devel@gnu.org; Sat, 04 Jan 2014 23:50:08 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1Vzfex-0000OL-Tu for emacs-devel@gnu.org; Sun, 05 Jan 2014 05:49:59 +0100 Original-Received: from mail.wooz.org ([216.15.33.194]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Jan 2014 05:49:59 +0100 Original-Received: from barry by mail.wooz.org with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Sun, 05 Jan 2014 05:49:59 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 97 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: mail.wooz.org X-Newsreader: Claws Mail 3.9.3 (GTK+ 2.24.22; x86_64-pc-linux-gnu) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:167344 Archived-At: --Sig_/IJkglf+vy2OHSKiZY/r+QuT Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: quoted-printable On Jan 04, 2014, at 05:15 AM, Stephen J. Turnbull wrote: >It's true that Bazaar has some useful features, such as shared repos, >whose performance characteristics are hard to emulate accurately in >git. I can't speak to Stefan's experience, of course, but when I look >at my git repos, in fact sharing is quite high because branches in >separate repos tend to be very divergent (so only the original shared >objects *can* be shared), and when the main feature branch gets >merged, the whole repo usually gets deleted so the failure of "git >fetch" to hardlink pulled objects isn't a big space leak. I know Stephen knows this, but Bazaar shared repos are really just a way to efficiently store revision objects in a parent directory, such that you can have a number of subdirectories inside there that represent working directories of different branches. Or put it another way, it just moves the .bzr directory up one level so everything underneath it can share that. In most cases, most branches share probably 90% of their revisions, and that's what makes local branching and remote pulling into a shared repo pretty fas= t. I'm another big bzr fan, and while colocated branches are interesting, I fi= nd them to be completely counter to my way of working. If I'm going to be working on a number of branches, I want separate working directories for ea= ch. So for example, in Mailman (under bzr) I'll have a shared repo directory containing working directories each containing a different in-progress feat= ure (topic) branch. For Python hg's and other projects git repos, I basically have multiple clo= nes inside a parent directory that's nothing special. It works, but doesn't map to my way of working as well as bzr. The other thing I sorely miss when working with git repositories is bzr's m= ain line of development approach. Once you understand this, and use it correct= ly (i.e. merges in the right direction), it's a very nice simplifying feature. It allows you to have human friendly revision numbers[1], with dotted revis= ion numbers for side branches. More importantly, it means that there's no cult= ural pressure for history changing rebases, `bzr log` by default only follows the main line (so side branches are hidden by default, unless you *want* to see them), and bisect doesn't make you unhappy by landing you in non-working revisions. I think if git had this concept and --help text that wasn't 20 pages long (= 629 lines for `git merge --help`!) it would go a long way to improving the user friendliness of git, IMHO of course. That said, it's pretty clear that git has won this round of dVCS wars. Mercurial will probably hang on and hopefully even thrive as a viable alternative, but network effects have given git most of the mindshare. At least until something better comes along, as it has with CVS and svn in the= ir times. -Barry [1] Yes, they are local-only, and yes they can change, and yes you still ha= ve unique hashes to unambiguously reference a revision, but it's still darn convenient. I'd much rather say "Are you on revision 7250 of branch lp:mailman?" --Sig_/IJkglf+vy2OHSKiZY/r+QuT Content-Type: application/pgp-signature; name=signature.asc Content-Disposition: attachment; filename=signature.asc -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.15 (GNU/Linux) iQIcBAEBCAAGBQJSyORnAAoJEBJutWOnSwa/bWAQAI8wO3Q9RpQhVIw3y8qGCObR SE/tKewh7iCL3PIwyk0dnXXlGhmXnb5vR1PTGq1Ju9BAgejXhmkn9tIyH1Oy6E2S gmzTn4zglciXNeOPX0gohb+Z3lZyyoBg9nOxaEooBMqqQy/BxU4ieQnvm9IicQ4t prHbSlrweCSfvONNgFuMU5gM764FQSJPsBiq6o6X8WfyPCiG1hzR/MVkkzQKLSkI T5BRcaRna5KtqPjZEn8Bk72MjjYPy/5if0GENZmZyDERB4rJRiGlI6SIZjOGYIf5 4Y+1fxPbVln7tBzUDcfrOaUaebRzhqGoUhrNJJ4dvW2/tJ336ZWRfhoUa9krDNMU 7EHi/MkxOOokGIEOT1UdFaqcmQsgUEAjUcMvZA1X0Fg5VIBvM5USN2CIzLivHxNr cqvyPAmtKyJPVajN3B3zJC74fRQ+HMdEC1aaugi3GTJOej6EJmaEe277wOTwMCwd HbgKaItwhzFI8k7AzQJdkBaVaMTeRLF09x+xnRc0Jg/GinPdTlu5qk7A6K974qSn BHDjfT3dkTg98AeSkx+4jx5U3R0BLRjRHPh9FvB3gmoYkDbhl4ysVcMecNp7oX0U iiZDpvYwDQapc7mXpV+iUDf8WaWe7Yeb662ahwayhSAAFEPyuSrV/6aVmWcPpAhk 30WMe1lv96KxfbZpt8uO =kM30 -----END PGP SIGNATURE----- --Sig_/IJkglf+vy2OHSKiZY/r+QuT--