Re: [VOTE] git versus mercurial (for DragonflyBSD)

["0000 vk" <0000.vk@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 6464 bytes --]

2008/10/27 Jakub Narebski <jnareb@gmail.com>

> Dnia poniedziałek 27. października 2008 10:29, Benoit Boissinot napisał:
> > On Mon, Oct 27, 2008 at 2:52 AM, Jakub Narebski <jnareb@gmail.com>
> wrote:
> >> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
> >>> Am Sonntag 26 Oktober 2008 19:55:09 schrieb Jakub Narebski:
> >>>>
> >>>> I agree, and I think it is at least partially because of Git having
> >>>> cleaner design, even if you have to understand more terms at first.
> >>>
> >>> What do you mean by "cleaner design"?
> >>
> >> Clean _underlying_ design. Git has very nice underlying model of graph
> >> (DAG) of commits (revisions), and branches and tags as pointers to this
> >> graph.
> >
> > Git and Mercurial are very close from that point of view.
> >
> > Mercurial explicitely disallow octopus merges (and we don't think there's
> > a good reason to allow them, although I agree with Linus, they look very
> nice
> > in gitk ;) ).
>
> From what I see Mercurial disallows octopus merges (merges with more
> than two parents) because of its rigid-record database repository
> design, while Git is more like object database.  Fixed width records
> of VMS vs delimited records of Unix... There is simply place on
> zero, one or two parents (two parent fields, which can be null) in
> Mercurial changerev format.
>
> By the way flexibility of Git design allowed to add 'encoding' header
> to commit message (if commits message is encoded not in utf-8) after
> the fact, without affecting older repository data, and playing well
> with old git installations which do not understand this header.
>
> > And we don't have "branches as pointer" in core, but the bookmark
> > extension does that.
>
> I disagree. Mercurial implementation of tags is strange, and from
> what I remember and from discussion on #revctrl implementation
> of local named branches is also strange (CVS-like). They are IMHO
> not well designed.
>
> Also the 'hidden' branches after fetching from remote repository
> (hg pull) but before merging (hg update) are IMHO worse design
> than explicit remote-tracking branches in Git, especially in presence
> of multiple [named] branches in repositories.
>
> > Apart from that I think the underlying format are interchangeable,
> > someone could use the git format with the hg ui, or use revlogs
> > (the basic format of mercurial) like packs.
>
> I don't think so. The 'content addressed filesystem' idea of Git
> is quite pervasive along Git implementation and Git thoughtflows.
>
> >
> > The only special thing about revlogs is the linkrev stuff, it's a
> > pointer to the first revision that introduced an object, so we can
> > easily find what to send in our network protocol (we don't have to
> > read the manifest, ie the "tree" of objects"). linkrev can be useful
> > to speedup "hg log" too.
>
> At first I thought: what a nice idea... but then I realized that in
> distributed environment there is no way to define "first revision that
> introduced an object". Take for example the following history
> (independent introduction):
>
>  .---.---.---.---x---.---.---.
>           \
>            --x---.---.
>
> where both 'x' have the same version of an object. The top branch
> appeared first in current repository, but the bottom branch had 'x'
> with earlier timestamp (earlier authordate).
>
>
> Git just relies on the fact that traversing revision is a part of it
> that is heavily optimized and really fast. Git very much by design
> doesn't store any backlinks in repository object database.
>
> >> I have read description of Mercurial's repository format, and it is not
> >> very clear in my opinion. File changesets, bound using manifest, bound
> >> using changerev / changelog.
> >>
> >
> > just do a s/// with the git terminology:
> > filelog -> blob
> > manifest -> tree
> > changelog -> commit object
>
> True. But as I see it they are bound in reverse order in Mercurial:
> deltas are stored in filelog, filelogs are bound together in manifest,
> manifest are bound using changelog, while in Git commit object
> references tree (and parents), trees references blobs, and blob store
> content of a file. But that might be just my impression.
>
>
> .......................................................................
>
> By the way, going back to the matter of choosing version control system
> for DragonflyBSD; some time ago I have written post
>  * "Mercurial's only true "plugin" extension: inotify...
>    and can it be done in Git?"
>   http://thread.gmane.org/gmane.comp.version-control.git/76661
>   (current answer: it is possible using 'assume unchanged' bit)
> about how nearly every Mercurial extension has equivalent functionality
> in Git.
>
> But what about the reverse, about the following features and
> issues in Mercurial:
>
>  * Merging in presence of criss-cross merges[1], and in presence of
>   file renames, i.e what merge-recursive does in Git.
>
>  * git-rerere, reusing recorded resolution of conflicted merges.
>   Resolving the same merge happens often if you use topic branches
>   and trial merging.
>
>  * git-grep that allows you to "and" the match criteria together,
>   and also pick a file (not a line) that matches all the criteria;
>   and of course allow searching given revision and not only working
>   directory.
>
>  * pickaxe search (git log -S) which contrary to blame/annotate
>   allow to find commit which _deleted_ given fragment.
>
>  * easy management of multiple repositories you fetch from with
>   remote-tracking branches and git-remote command.
>
>  * blame that follows block-of-line movement (it was invented by Linus
>   as a vision long time ago, but it took very long time to materialize).
>
>  * a way to review merge resolution, something that is done in git
>   by using combined diff format
>
>  * git-stash, allowing to stash away changes to go back to them later;
>   it allows to stash away even partially resolved merge conflict
>   (merge resolution in progress).
>
>  * git-filter-branch (based on cg-admin-rewrite-hist), which allow
>   to rewrite history for example to remove file which should never
>   be added to version control (for example because of copyright
>   or license).
>
> References:
> ===========
> [1] http://revctrl.org/CrissCrossMerge
>    BTW I wonder why reverting spam is made so hard on revctrl.org wiki
>
> --
> Jakub Narebski
> Poland
>

Jakub,

Do you know if git supports the equivalent of hg bundle?
Thanks.

vk

[-- Attachment #1.2: Type: text/html, Size: 8102 bytes --]