From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Jordi =?ISO-8859-1?Q?Guti=E9rrez?= Hermoso Newsgroups: gmane.emacs.devel Subject: Re: preferring mercurial Date: Fri, 10 Jan 2014 14:55:53 -0500 Message-ID: <1389383753.5784.24.camel@Iris> References: <3905544.suqMZffgM5@descartes> <874n5d6whz.fsf@gaia.iap.fr> <87iottf4fe.fsf@uwakimon.sk.tsukuba.ac.jp> <1389366228.5784.14.camel@Iris> <8738kvfxtj.fsf@uwakimon.sk.tsukuba.ac.jp> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Trace: ger.gmane.org 1389383761 20192 80.91.229.3 (10 Jan 2014 19:56:01 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 10 Jan 2014 19:56:01 +0000 (UTC) Cc: =?ISO-8859-1?Q?R=FCdiger?= Sonderfeld , Neal Becker , =?ISO-8859-1?Q?Fran=E7ois?= Orieux , emacs-devel@gnu.org To: "Stephen J. Turnbull" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Jan 10 20:56:08 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 1W1iBc-00082d-DZ for ged-emacs-devel@m.gmane.org; Fri, 10 Jan 2014 20:56:08 +0100 Original-Received: from localhost ([::1]:58770 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1iBc-0007so-59 for ged-emacs-devel@m.gmane.org; Fri, 10 Jan 2014 14:56:08 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:57312) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1iBV-0007sF-0s for emacs-devel@gnu.org; Fri, 10 Jan 2014 14:56:05 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W1iBO-0001dS-8S for emacs-devel@gnu.org; Fri, 10 Jan 2014 14:56:00 -0500 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:46366) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W1iBO-0001d5-4p for emacs-devel@gnu.org; Fri, 10 Jan 2014 14:55:54 -0500 Original-Received: from beast.bic.mni.mcgill.ca ([132.206.178.199]:45800 helo=[IPv6:::1]) by fencepost.gnu.org with esmtpsa (TLS1.0:DHE_RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1W1iBN-0004tl-QT; Fri, 10 Jan 2014 14:55:53 -0500 In-Reply-To: <8738kvfxtj.fsf@uwakimon.sk.tsukuba.ac.jp> X-Mailer: Evolution 3.4.4-3 X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2001:4830:134:3::e 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:168038 Archived-At: On Sat, 2014-01-11 at 04:20 +0900, Stephen J. Turnbull wrote: > Jordi Guti=C3=A9rrez Hermoso writes: >=20 > > Furthermore, hg's internal data structures aren't that hard to > > understand either. Commit -> tree -> blob -> ref, meet changelog -> > > manifest -> filelog -> revlog. >=20 > Besides the fact that blob->ref is nonsense, look whose terminology > makes more sense here. Terminology aside (we're not going to solve the second hardest problem in computer science today), the structures are very similar. The arrows were just meant to be suggestive. I wasn't trying to give them a specific meaning. > > > Nothing has more respect for history than git. > >=20 > > This isn't very respectful of history: > >=20 > > http://www.infoq.com/news/2013/11/use-the-force/ >=20 > First, note that the culprit, Gerrit, does not use git to access git > repos, and by *default* does push --force. Blaming this particular > disaster on git itself is unfair. The fact that git allows this at all is an architectural problem in the UI. There are better ways, like hg evolve. > Second, from hg help push: >=20 > -f --force force push >=20 > Note: > Extra care should be taken with the -f/--force option, which > will push all new heads on all branches, an action which will > almost always cause confusion for collaborators. >=20 > IOW, this is a people problem, which Mercurial would be subject to as > well. The problem here would be different: both heads would be visible on the remote repo. Have you never tried doing this? I'm sure you're well aware that heads in hg don't need to have a reference to them in order to be visible from the UI and avoid garbage collection. In hg the problem is much easier to solve without server-side access: just push another commit closing-branch commit on the extra head that you don't want to keep working on. > > > History isn't *changed*, it is recreated > >=20 > > Same in hg. New history means new hashes. Old history is still > > lying around. >=20 > Where? How do you get at it? Eg (some output deleted): >=20 > $ mkdir hgtest && cd hgtest && hg init > $ echo foo >> foo && hg add foo && hg commit -m 1 && hg heads > changeset: 0:ead82a170088 > $ echo foo >> foo && hg commit -m 2 && hg heads > changeset: 1:e5790bc8b230 > $ hg rollback Oh, right. rollback. The one plainly destructive operation in core hg. It's deprecated, meaning it doesn't show up in the docs anymore, but because hg is committed to forever backwards compatibility in the CLI, the actual command is going to be operational forever. At least nowadays we get $ hg help rollback hg rollback roll back the last transaction (DANGEROUS) (DEPRECATED) Please use "hg commit --amend" instead of rollback to correct mistakes in the last commit. [etc] One of hg's youthful mistakes. Please don't use it anymore. > Oops. The same thing happened with "commit --amend". No, commit --amend creates strip backups by default, or hidden obsolete commits when using evolve. > > > AFAIK hg and bzr *do* destroy history when they perform operations > > > like commit --amend, strip, and rebase. > >=20 > > I hope I helped you to know better now. >=20 > Unfortunately, no. The actual behavior of hg is indeed immediately > destructive in some cases, unlike git. git has immediately destructive operations too, for example the "git reset HEAD --hard" that everyone blindly memorises (who really can keep all of the kinds of resets straight?) will destroy all unstaged changes. The equivalent command "hg revert --all" creates .orig file backups unless you explicitly give it the --no-backup option. Here is a fun git bug I know about: git-gc cannot do concurrency. If multiple git-gc processes run on the same repo at the same time, you may end up deleting more than merely unreferenced commits. It's only very recently received a patch that I know of: http://git.661346.n2.nabble.com/PATCH-gc-notice-gc-processes-run-by-othe= r-users-td7601374.html No write locks on git-gc? That's one of git's youthful mistakes. - Jordi G. H.