From: Arne Babenhauserheide <arne_bab@web.de>
To: Jakub Narebski <jnareb@gmail.com>
Cc: mercurial@selenic.com, SLONIK.AZ@gmail.com, git@vger.kernel.org
Subject: Re: [VOTE] git versus mercurial (for DragonflyBSD)
Date: Mon, 27 Oct 2008 11:14:00 +0100 [thread overview]
Message-ID: <200810271114.03406.arne_bab@web.de> (raw)
In-Reply-To: <200810271041.54511.jnareb@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 4660 bytes --]
Am Montag 27 Oktober 2008 10:41:53 schrieb Jakub Narebski:
> > If you tell a disk "give me files a, b, c, d, e, f (of the whole abc)",
> > it is faster then if you tell it "give me files a k p q s t", because the
> > filesystem can easier optimize that call.
>
> I would expect _good_ filesystem to be able to optimize this call as
> well. As I said it looks like Mercurial and Git are optimized for
> different cases: Git relies on filesystem for caching, and optimizes
> for warm cache performance.
The problem is by which knowledge the filesystem should optimize this call
when it is storing the files in the first place.
> > relying on crontab which might not be available in all systems (I only
> > use GNU/Linux, but what about friends of mine who have to use Windows?)
>
> But that doesn't matter in the context of this discussion, which is
> DragonflyBSD; worse or better support for MS Windows doesn't matter
> here, does it?
It only matters, if some developers are forced to work on WIndows machines at
times.
> > But Mercurial normally works on standard filesystems, so this isn't the
> > case for normal operations.
>
> Mercurial implements transactions as a way to keeping operations atomic.
> So I don't know what you mean by "normally works on standard filesystem"
> here.
I just meant "databases are a bit off topic" :)
> > You could say, though, that git implements a very simple transaction
> > model: Keep all old data until it gets purged explicitely.
>
> Git just uses different way to keep operations atomic, different way
> of implementing transactions.
That's what I wanted to express.
> And probably requires transactions and locks for that. Git simply uses
> atomic write solution for atomic update of references.
Doesn't atomic write also need locks, though on a lower level (to ensure
atomicity)?
> Behind the scenes, at a lower level, Git does necessary delta resolving.
> Delta chains in packs have limited length (as they have in Mercurial).
So both do snapshots - they seem more and more similar to me :)
> The answer usually is: did you have this repository packed? I admit
> that it might be considered one of disadvantages of git, this having
> to do garbage collection from time to time... just like in C ;-)
I cloned from the official repositories.
I hope Linus had his repository packed :)
> Well, understanding "git checkout ." doesn't require understanding
> inner workings of git. Your friend was incorrect here. I'll agree
> though that it is a bit of quirk in UI[1] (but I use usually
> "git reset --hard" to reset to last committed state).
Damn - one more way how I could have archieved what I wanted... one more way I
didn't find.
> Just Google for "Worse is Better". But what I actually mean that Git
> feature set and UI has evolved from very bare-bones plumbing, adding
> features and UI _as needed_, instead of being designed according to
> what designer thought it was needed.
And that's how it feels to me.
A great testing ground, but it developed too many stumbling blocks which keep
me from trying things.
When I now use git, I only do the most basic operations: clone, pull, push,
add, commit, checkout. When anything else arises, I check if it is worth the
risk of having to read up for hours - and since that wasn't the case for the
last few months, I then just ignore the problem or ask someone else if he can
fix it.
As a contrast, when I encounter a problem with Mercurial, I simply check the
commands for a moment and then try to solve it, and normally I have what I
wanted within seconds to minutes.
Git instead bit me once too often.
I know that this isn't something which hits everyone and that it is
subjective, but since it hit me, I'm wary of git, because in my view it isn't
something for the majority of people - and you almost always have someone from
that "majority" in your project.
I don't want people getting afraid of solving their own problems, so I avoid
systems which bite so often, that they create fear (for example of losing much
time on something which should be a side issue).
All in all it's a UI issue - while the git UI bit me quite often, the
Mercurial UI just works.
Best wishes,
Arne
-- My stuff: http://draketo.de - stories, songs, poems, programs and stuff :)
-- Infinite Hands: http://infinite-hands.draketo.de - singing a part of the
history of free software.
-- Ein Würfel System: http://1w6.org - einfach saubere (Rollenspiel-) Regeln.
-- PGP/GnuPG: http://draketo.de/inhalt/ich/pubkey.txt
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 197 bytes --]
next prev parent reply other threads:[~2008-10-27 10:15 UTC|newest]
Thread overview: 65+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-10-26 4:28 [VOTE] git versus mercurial walt
2008-10-26 14:15 ` [VOTE] git versus mercurial (for DragonflyBSD) Jakub Narebski
2008-10-26 14:30 ` Maxim Vuets
2008-10-26 15:05 ` Leo Razoumov
2008-10-26 18:55 ` Jakub Narebski
2008-10-27 0:20 ` Arne Babenhauserheide
2008-10-27 4:15 ` Leo Razoumov
2008-10-27 7:16 ` Arne Babenhauserheide
2008-10-27 7:16 ` dhruva
2008-10-27 0:47 ` Arne Babenhauserheide
2008-10-27 1:52 ` Jakub Narebski
2008-10-27 7:50 ` Arne Babenhauserheide
2008-10-27 9:41 ` Jakub Narebski
2008-10-27 10:12 ` Leslie P. Polzer
2008-10-27 10:14 ` Arne Babenhauserheide [this message]
2008-10-27 12:48 ` Jakub Narebski
[not found] ` <200810271512.26352.arne_bab@web.de>
2008-10-27 18:01 ` Jakub Narebski
2008-10-27 20:48 ` Arne Babenhauserheide
2008-10-27 21:07 ` Miklos Vajna
2008-10-27 21:30 ` Arne Babenhauserheide
2008-10-28 0:13 ` Miklos Vajna
2008-10-28 17:48 ` Andreas Ericsson
2008-10-28 19:11 ` Arne Babenhauserheide
2008-10-28 19:38 ` SZEDER Gábor
2008-11-06 16:25 ` Marcin Kasperski
2008-11-06 17:41 ` Isaac Jurado
2008-10-28 19:16 ` Randal L. Schwartz
2008-10-27 23:25 ` Jakub Narebski
2008-10-27 9:29 ` Benoit Boissinot
2008-10-27 10:57 ` Jakub Narebski
2008-10-27 14:29 ` 0000 vk
2008-10-27 14:57 ` Jakub Narebski
[not found] ` <1225100597.31813.11.camel@abelardo.lan>
2008-10-27 11:42 ` David Soria Parra
2008-10-27 20:07 ` Brandon Casey
2008-10-27 20:37 ` Jakub Narebski
2008-10-28 1:28 ` Nicolas Pitre
2008-10-26 15:57 ` Felipe Contreras
2008-10-26 19:07 ` Jakub Narebski
2008-10-26 19:54 ` Felipe Contreras
2008-10-28 12:31 ` [VOTE] git versus mercurial walt
2008-10-28 14:28 ` Johannes Schindelin
2008-10-28 14:41 ` Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial) Peter Krefting
2008-10-28 14:59 ` Johannes Schindelin
2008-10-28 15:02 ` Git/Mercurial interoperability (and what about bzr?) Matthieu Moy
2008-10-28 15:03 ` Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial) Nicolas Pitre
2008-10-28 15:33 ` Pieter de Bie
2008-10-28 19:12 ` Miklos Vajna
2008-10-28 21:10 ` Miklos Vajna
2008-10-28 21:31 ` Theodore Tso
2008-10-28 23:28 ` Miklos Vajna
2008-11-01 8:06 ` Git/Mercurial interoperability (and what about bzr?) Florian Weimer
2008-11-01 10:03 ` Santi Béjar
2008-11-01 10:33 ` Jakub Narebski
2008-11-01 10:44 ` Florian Weimer
2008-11-01 11:10 ` Florian Weimer
2008-11-01 12:26 ` Jakub Narebski
2008-11-01 13:39 ` Theodore Tso
2008-11-01 17:51 ` Linus Torvalds
2008-11-02 1:13 ` Theodore Tso
2008-11-01 10:16 ` Git/Mercurial interoperability (and what about bzr?) (was: Re: [VOTE] git versus mercurial) Peter Krefting
2008-10-29 19:11 ` [VOTE] git versus mercurial Shawn O. Pearce
2008-10-29 19:36 ` Boyd Lynn Gerber
2008-10-29 19:48 ` Johannes Schindelin
2008-10-29 19:51 ` Boyd Lynn Gerber
2008-10-29 8:15 ` Miles Bader
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=200810271114.03406.arne_bab@web.de \
--to=arne_bab@web.de \
--cc=SLONIK.AZ@gmail.com \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=mercurial@selenic.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).