[VOTE] git versus mercurial

[David Soria Parra]

Emanuele Aina schrieb:

> Jakub Narebski precisò:
>
>>> 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.
>
> Just for reference, the abstract history model of Mercurial and GIT is
> the same, a DAG of changesets identified by their cryptographic hash as
> designed for Monotone, which can be considered the parent of both.
>
> GIT and Mercurial then differs in how this abstract model is written to
> disk, with different tradeoffs in terms of performances and how easily a
> specific feature can be implemented, but there is no reason something
> can be done in GIT but not in Mercurial or viceversa.

Yes, it's the same: a DAG  with hashes. But there are limitations due to
the implementation (and not the design). Just as a bad and completely
useless example (don't start to argue, I know it's nothing someone would
like to have): you cannot force mercurial to merge two revisions and
create a merge commit if one is the others ancestor,which is possible in
git with git --no-ff. In addition they differ in some other ways:
Mercurial doesn't have an index to stage commits, which is something
that git has and allows very powerful features (such as git add -i, etc).


--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jakub Narebski]

On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:

> 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.

Well, that is a question for filesystem designer, and VFS designer...

What I want to emphasize that perhaps Mercurial is optimized for
"streaming access", but fully packed Git repository requires only
single (well, up to details) mmap, which I think is even better.

>>> 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.

DragonFly BSD developers? I think they would work on DragonFly BSD
(eating one's own dogfood and all that...).

Sidenote: I don't know if DragonFly BSD is more like Linux kernel, or
as Linux distribution. It would be in my opinion good idea to ask
similar projects about the impressions about SCM they use (Linux kernel,
Android, ALT Linux distribution, Debian (build tools etc.), CRUX Linux
distribution, Exherbo, grml, Source Mage GNU/Linux for impressions
on their Git usage; OpenSolaris, Conary, Heretix, Linux HA, perhaps
Mozilla for impressions on their Mercurial usage;

IIRC ALSA moved from Mercurial to Git, so they could be of help there.

[...]
>> Git just uses different way to keep operations atomic, different way
>> of implementing transactions.

>> 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)?

No, you can use create then rename to final place trick, making use
of the fact (assumption) that renames are atomic. And Git first write
data, then write references which are used to access this data (this
relies on pruning dangling objects).
 
I'm not saying that git does not use locks at all, because it does,
for example to edit config file, or update branch and its reflog as
atomic operation. But it needs locking in very few places.

>> 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 :)

There are differences: Mercurial from what I understand uses forward
deltas (from older to never) while Git prefers recency order; delta
chains in Git doesn't need to form single line, but can be forest of
delta chains; Git searches for good delta basis from large range of
objects (see pack.window); there is pack index which allow for random
access as if objects were in loose format (resolving deltas behind the
scenes).

I also don't know how Mercurial deals with binary files; in Git pack
format uses binary delta from LibXDiff by Davide Libenzi (File
Differential Library), heavy modified.

>> 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, that also depends on _when_ did you try this. In older versions
of Git pack file got from network (git:// and ssh:// protocols) was
exploded into loose objects; now is kept if it is large enough, only
expanding it to make it thick, self contained pack file.

Unless you used http:// protocol, which I think kept packs as they were,
and as dumb protocol (along ftp:// and rsync://) depends on remote
repository being well 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.

Well, there is a difference between "git checkout ." and
"git reset --hard", but it does not matter here.

By the way, the design of Git allowed to add lately new feature:
"git checkout --merge <file>..." to recreate conflicted merge in
specified paths. For example if you completely borked merge resolution,
and want to start from scratch.

>> 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.

Well, as shown in "Worse is better", evolved design wins (Lisp machines
versus Unix) :-)

> 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.

Understanding Git "mental model" certainly helps.

[...]
> All in all it's a UI issue - while the git UI bit me quite often, the
> Mercurial UI just works.

But _that_ might be because you are used to Mercurial UI, isn't it?

--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jakub Narebski]

On Mon, 27 Oct 2008, 0000 vk wrote:
> 2008/10/27 Jakub Narebski <[hidden email]>

> > 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:

[...]

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

The equivalent of "hg bundle" (http://www.selenic.com/mercurial/hg.1.html#bundle)
would be "git bundle" (http://git.or.cz/man/git-bundle). I think
git-bundle was inspired by Mercurial feature, just like fast-import
format and bisect went in other direction.

P.S. Could you _please_ quote only relevant fragments of email you are
replying to, especially if it is so long?

--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jakub Narebski]

On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
> Am Monday 27 October 2008 13:48:38 schrieben Sie:

>>> All in all it's a UI issue - while the git UI bit me quite often, the
>>> Mercurial UI just works.
>>
>> But _that_ might be because you are used to Mercurial UI, isn't it?
>
> I rather think it is because I was used the Subversion UI before I tried git
> and Mercurial.

I think Mercurial UI is more compatibile with Subversion UI than Git;
additionally Mercurial uses separate, different names to avoid
ambiguities: examples are 'hg rollback' and 'hg backout' for commands
which various SCM name reset and revert, sometimes referring to one
and sometimes to the other.

AFAIK Git mostly follows BitKeeper UI; it is quite natural as it was
meant as replacement for BitKeeper for Linux kernel development.

[...]
> Also, Mercurial is Python based with quite readable code and it's very easy to
> create extensions for new uses, when I need them.
>
> If you know Python, creating a new Mercurial extension isn't harder than
> creating a shell chain command for git, but it feels much cleaner and is
> nicely integrated once it's done. You can even change the operation of basic
> commands very easily without having to touch any existing code.

There are advantages and disadvantages to each method.

Git was developed in true Unix tools style, as described in TAOUP i.e.
"The Art of UNIX Programming" by ESR (http://catb.org/esr/writings/taoup/html/)
In "Programming Pearls" by Jon Bentley there is in one of chapters
description of prototyping 'spell' using ready UNIX tools, pipelines,
and a few of custom tools, to examine the needs of 'spell'.

One of the consequences of this type of design is that there isn't
(yet?) something like git library; this is caused by the fact that
tools (plumbing) that make up git are designed to run once, and let
operating system take care of freeing resources.

On the other hand clean and clear design of git repository made it
possible to create native Git (re)implementation in Java: the JGit
project. (Well, Git is GPLv2 and JGit/Egit is BSD 3-clause/EPL, so
reimplementation might have been needed for licensing purposes anyway.
Well, it is not _full_ implementation yet...

Besides is writing plugin in Python for Mercurial that much easier
than writing new command or stuff in C for Git? Well, perhaps it is,
as only recently there began to appear API documentation, and there
were created utility mini-libraries like strbuf, or string_list,
or parseopt.

Also often third-party projects or stuff in contrib gets incorporated
into git proper; sometimes stuff is moved from git core to contrib,
if there is no maintainer however (git-svnimport, git-p4import).
Git repository has many roots: one from git core, one with gitk
(graphical history viewer), one from what was git mail tools, one
with gitweb (web interface), and one with git-gui (graphical commit
tool).


The extending via plugins idea used by Mercurial, so succesfull IMHO
for Firefox, and I think quite successfull for ikiwiki for example, is
not without drawbacks, especially that there is no plugins clearinghouse,
and plugins are required for what is considered pretty required
functionality, like bisect before hg 1.0.

See also blog post on vcscompare: "Plugins In Version Control"
http://vcscompare.blogspot.com/2008/06/plugins-in-version-cotnrol.html

--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Brandon Casey]

Jakub Narebski wrote:
> On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
>> Also, looking at git, git users still have to garbage collect regularly, which
>> shows to me that the design wasn't really cleaner.
>
> Well, they have to a lot less than they used to, and there is
> "git gc --auto" that can be put in crontab safely.

I think you missed the most convincing argument _for_ explicit garbage collection.

By allowing explicit repository packing, git allows you to delay a cpu intensive
operation til later, when time doesn't matter, like at the end of the day right
before I go home. It also allows more cpu intensive delta/compression algorithms
to be used.

By contrast, mercurial performs deltafication and compression on each commit.
So, acceptable commit speed must be weighed against the complexity of the
deltafication/compression algorithm and file format.

-brandon
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Jakub Narebski]

On Mon, 27 Oct 2008, Brandon Casey wrote:

> Jakub Narebski wrote:
> > On Mon, 27 Oct 2008, Arne Babenhauserheide wrote:
> > >
> > > Also, looking at git, git users still have to garbage collect regularly, which
> > > shows to me that the design wasn't really cleaner.
> >
> > Well, they have to a lot less than they used to, and there is
> > "git gc --auto" that can be put in crontab safely.
>
> I think you missed the most convincing argument _for_ explicit garbage collection.
>
> By allowing explicit repository packing, git allows you to delay a cpu intensive
> operation til later, when time doesn't matter, like at the end of the day right
> before I go home. It also allows more cpu intensive delta/compression algorithms
> to be used.
>
> By contrast, mercurial performs deltafication and compression on each commit.
> So, acceptable commit speed must be weighed against the complexity of the
> deltafication/compression algorithm and file format.

On the one hand one can use different compression for loose (immediate)
and packed (in a free time) objects.

On the other access from "smart" client (git://, ssh://, future "smart"
HTTP server) results in creating a pack, so we cannot allow for too
tight pack compression, or to be more exact too much CPU load taken.

The ability to vary 'quality' of pack compression is very useful to
distinguish between very loosely packed fast-import pack, and tightly
repacked in free time.

--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Arne Babenhauserheide-2]

Am Montag 27 Oktober 2008 19:01:48 schrieb Jakub Narebski:
> AFAIK Git mostly follows BitKeeper UI; it is quite natural as it was
> meant as replacement for BitKeeper for Linux kernel development.

It is a great choice for an SCM intended for kernel development where everyone
knows bitkeeper, but might not be optimal for other tasks.

> Besides is writing plugin in Python for Mercurial that much easier
> than writing new command or stuff in C for Git? Well, perhaps it is,
> as only recently there began to appear API documentation, and there
> were created utility mini-libraries like strbuf, or string_list,
> or parseopt.

Yes, for two main reasons:

1) Writing Python is much easier and quicker than writing C, especially when
you can just experiment with the Python interpreter (or better still: with
ipython). No memory management hassle, no strange compiler bugs, no stray
pointers. Just plain writing what you want to do. But if you need C speed, you
can still include parts written in C - where you really need it. For all other
cases you have more readable and far more compact code.

2) You can easily access every core function, and you can replace every
command.
You don't have to invent a "git foolog" command. Instead you can just adapt
the regular log to do a foolog which people can use via "hg log".

> Also often third-party projects or stuff in contrib gets incorporated
> into git proper; sometimes stuff is moved from git core to contrib,
> if there is no maintainer however (git-svnimport, git-p4import).
> Git repository has many roots: one from git core, one with gitk
> (graphical history viewer), one from what was git mail tools, one
> with gitweb (web interface), and one with git-gui (graphical commit
> tool).

Maybe I should include the extensions in the codeswarm to have matching
repositories.

> The extending via plugins idea used by Mercurial, so succesfull IMHO
> for Firefox, and I think quite successfull for ikiwiki for example, is
> not without drawbacks, especially that there is no plugins clearinghouse,
> and plugins are required for what is considered pretty required
> functionality, like bisect before hg 1.0.

But they can just be included in the core distibution once they become central
enough.

It's a way of allowing people to add functionality they miss without forcing
them to mess with core code instantly.

> See also blog post on vcscompare: "Plugins In Version Control"
> http://vcscompare.blogspot.com/2008/06/plugins-in-version-cotnrol.html

I just read it, and it didn't convince me, because in my opinion a VCS has
certain core functions which it should provide to everyone, and other
functionality which only certain people need.

For example I normally don't need rebasing, mercurial queues, transplanting
and similar. Why should my tool include the commands by default?

The defaults should be the most common way to use the tool, so people can
easily learn it.

Advanced stuff can be added with extensions.

And because the most used plugins are distributed with Mercurial, I can also
activate them when I don't control the Mercurial installation - and should
something be missing which I need, I can just download and activate a plugin
without having to compile anything, since they are simply Python modules.

Just set
[extensions]
foo = /blah/foo.py

in ~/.hgrc and the foo plugin is active.

Gits missing plugin system might just be a reason, why its usability still
suffers from many problems: They have to do everything for everyone all the
time, so the chances are high, that they won't do it really good for anyone
(but the main git coders).

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

[Miklos Vajna]

On Mon, Oct 27, 2008 at 09:48:50PM +0100, Arne Babenhauserheide <[hidden email]> wrote:
> 1) Writing Python is much easier and quicker than writing C, especially when
> you can just experiment with the Python interpreter (or better still: with
> ipython). No memory management hassle, no strange compiler bugs, no stray
> pointers. Just plain writing what you want to do. But if you need C speed, you
> can still include parts written in C - where you really need it. For all other
> cases you have more readable and far more compact code.

You compare Python to C here, but did you realize that in git you can
write your git command in any language you want? Of course it's
recommended to do it in C/shell/perl if you want to get it included in
git.git, but that's just a decision.

> 2) You can easily access every core function, and you can replace every
> command.
> You don't have to invent a "git foolog" command. Instead you can just adapt
> the regular log to do a foolog which people can use via "hg log".

IIRC the main reason git aliases can't overwrite git commands is because
that would break scripts relying on the output of existing git commands.
Given that I install such an extension, won't my script break?

> The defaults should be the most common way to use the tool, so people can
> easily learn it.
>
> Advanced stuff can be added with extensions.

From a user's point of view, I think external git commands and such hg
plugins are equal. The user instally the "foo"
extension/command/plugin/whatever and gets the "git/hg foo" command.

> And because the most used plugins are distributed with Mercurial, I can also
> activate them when I don't control the Mercurial installation - and should
> something be missing which I need, I can just download and activate a plugin
> without having to compile anything, since they are simply Python modules.
>
> Just set
> [extensions]
> foo = /blah/foo.py
>
> in ~/.hgrc and the foo plugin is active.

Same for git, as long as it's written in a scripting language; you
should include git-foo in PATH then you can use git foo.

[Arne Babenhauserheide-2]

Am Montag 27 Oktober 2008 22:07:16 schrieb Miklos Vajna:
> You compare Python to C here, but did you realize that in git you can
> write your git command in any language you want? Of course it's
> recommended to do it in C/shell/perl if you want to get it included in
> git.git, but that's just a decision.

I was asked explicitely about the difference of writing a Mercurial extension
and of writing some addition for git in C, so I answered that.

> IIRC the main reason git aliases can't overwrite git commands is because
> that would break scripts relying on the output of existing git commands.
> Given that I install such an extension, won't my script break?

Since that "script" will likely be an extension which will use the core
function instead of the UI command, it won't break.

Stuff which does command line parsing can naturally break when I change the
output. But it can also directly use the advanced features.

> From a user's point of view, I think external git commands and such hg
> plugins are equal. The user instally the "foo"
> extension/command/plugin/whatever and gets the "git/hg foo" command.
[snip]
> Same for git, as long as it's written in a scripting language; you
> should include git-foo in PATH then you can use git foo.

Means git can provide additional commands and only has the limitation that I
can't overwrite the basic commands, right?

But we're slowly moving off topic, aside from "OK, git also has extensions -
they are called external commands".

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

[Jakub Narebski]

Dnia poniedziałek 27. października 2008 21:48, Arne Babenhauserheide napisała:
> Am Montag 27 Oktober 2008 19:01:48 schrieb Jakub Narebski:
 

> > Besides is writing plugin in Python for Mercurial that much easier
> > than writing new command or stuff in C for Git? Well, perhaps it is,
> > as only recently there began to appear API documentation, and there
> > were created utility mini-libraries like strbuf, or string_list,
> > or parseopt.
>
> Yes, for two main reasons:
>
> 1) Writing Python is much easier and quicker than writing C, especially when
> you can just experiment with the Python interpreter (or better still: with
> ipython). No memory management hassle, no strange compiler bugs, no stray
> pointers. Just plain writing what you want to do. But if you need C speed, you
> can still include parts written in C - where you really need it. For all other
> cases you have more readable and far more compact code.

In Git you can write in C, using (underdocumented) git API, or you can
script (in shell script, in Perl, in Python, in Ruby) using git plumbing
commands which are meant for scripting (or bindings in appropriate
language).
 
Most new features, like git-remote tool to manage interaction with
multiple remote repositories, each of which can have multiple branches,
start as a shell or Perl script, and when they and their UI mature they
get converted into C (made into builtin). Builtinification is done not
only for performance, but also for portability (think Perl support on
MS Windows).

So in Mercurial you can write in Python, or you can write in C; in Git
you can write in any scripting language (e.g. shell script, Perl, Tcl/Tk),
or you can write in C... yes, I know it is oversimplification...

> 2) You can easily access every core function, and you can replace every
> command.
> You don't have to invent a "git foolog" command. Instead you can just adapt
> the regular log to do a foolog which people can use via "hg log".

Well, if I remember correctly if you drop git-foo in EXEC_PATH, then
you would be able to call it as "git foo". So adding commands is easy.

Git provides a few entry points which can be used to extend
functionality. They are: hooks system; gitattributes to define custom
merge, diff and clean/smudge (checkout) drivers per file (pathname);
custom merge strategies; EXTRENAL_DIFF and EXTERNAL_GREP.

I'm not sure if other messing with core functions is a good idea to
have such ability accessible.

> > The extending via plugins idea used by Mercurial, so succesfull IMHO
> > for Firefox, and I think quite successfull for ikiwiki for example, is
> > not without drawbacks, especially that there is no plugins clearinghouse,
> > and plugins are required for what is considered pretty required
> > functionality, like bisect before hg 1.0.
>
> But they can just be included in the core distibution once they become central
> enough.

Having some extensions blessed to be included with core program (like
ikiwiki with goodstuff, and similar to Git with contrib/ section)
solves some problems of relying on extensions for basic functionality.
I for example consider bisect and patch+mail workflow tools to be basic,
while patch queue management (well, patch management in general) to be
something that can be built on top of SCM, like StGit, Guilt, TopGit
for Git, or mq (Mercurial Queues) for Mercurial.
 
>
> It's a way of allowing people to add functionality they miss without forcing
> them to mess with core code instantly.

The problem with extensions IMVVVHO is that they don't require to
follow strict "inclusion in core" standards, which means that there
is no pressure to add them to core... which for example leads to
including bisect in core only since hg v1.0, "because it is available
as extension".

Requiring to use large amount of extensions to having required
functionality is also one of bad consequences of extension based
development, although having default set of extensions that can be
turned on via some metaextension / metapackage (like ikiwiki's
goodstuff) reduces impact of this.
 
Extensions / modules / plugins are good in projects with high
barriers of development, like Mozilla / Firefox, GNU Emacs, etc.
but I am not sure if it doesn't make for slower core development...

> Gits missing plugin system might just be a reason, why its usability still
> suffers from many problems: They have to do everything for everyone all the
> time, so the chances are high, that they won't do it really good for anyone
> (but the main git coders).

Well, Git doesn't have plugin system, but is easily scriptable...

And, at least according to annual Git User's Survey results (on git wiki)
many people create their custom scripts and scriplets to make their work
with SCM easy...

--
Jakub Narebski
Poland
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Miklos Vajna]

On Mon, Oct 27, 2008 at 10:30:44PM +0100, Arne Babenhauserheide <[hidden email]> wrote:
> Means git can provide additional commands and only has the limitation that I
> can't overwrite the basic commands, right?

Yes. And in general the API is the output of the plumbing commands, not
the API of libgit which is totally unstable.

> But we're slowly moving off topic, aside from "OK, git also has extensions -
> they are called external commands".

I think we're offtopic since the dragonfly list is not in cc. :)

[Nicolas Pitre]

On Mon, 27 Oct 2008, Jakub Narebski wrote:

> On the other access from "smart" client (git://, ssh://, future "smart"
> HTTP server) results in creating a pack, so we cannot allow for too
> tight pack compression, or to be more exact too much CPU load taken.

Don't forget that, in those cases, the created pack for streaming is
copying chunks of data from existing packs for most objects, effectively
reusing for free the work that has previously been done to tightly
compress those packs.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[walt-2]

walt wrote:
> No, no, I'm not the one calling for a vote.  You old-timers here
> will know the name Matt Dillon, who is leading the dragonflybsd
> project (www.dragonflybsd.org).
>
> Matt is the one who is calling for the vote in his thread "Vote
> for your source control system" in the dragonfly.kernel group,
> accessible via nntp://nntp.dragonflybsd.org...

The official vote was 19 to 19, plus one for perforce and one
for svn.  Matt has proposed a primary git repository and a mirror
in hg, and that's being debated now.

I've already learned a lot from following this topic in both
lists and it seems this is a topic of great interest to many,
so I'll continue reading in both places.

Thanks!

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Johannes Schindelin]

Hi,

On Tue, 28 Oct 2008, walt wrote:

> walt wrote:
> > No, no, I'm not the one calling for a vote.  You old-timers here will
> > know the name Matt Dillon, who is leading the dragonflybsd project
> > (www.dragonflybsd.org).
> >
> > Matt is the one who is calling for the vote in his thread "Vote for
> > your source control system" in the dragonfly.kernel group, accessible
> > via nntp://nntp.dragonflybsd.org...
>
> The official vote was 19 to 19, plus one for perforce and one for svn.  
> Matt has proposed a primary git repository and a mirror in hg, and
> that's being debated now.

While many may say that that is a half-baked solution, I actually like it.  
Mercurial and Git are pretty similar in their concept (if not in how the
data is actually stored).

Note that with git fast-export and hg fast-import, it should be relatively
simple to convert from one data format to the other, even incrementally.

And for the other direction, you could use hg fast-export from the
fast-export.git repository (I am working on a better one at the moment,
too, so that incremental fast-export would be possible, too).

Ciao,
Dscho

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Peter Krefting]

Johannes Schindelin:

> While many may say that that is a half-baked solution, I actually
> like it. Mercurial and Git are pretty similar in their concept (if
> not in how the data is actually stored).

That touches on something that I have been thinking about for a while.

How difficult are the storage formats? Would it be possible, in a
reasonable amount of work, to add support for the Mercurial protocol
and format in "git clone", so that I could clone a Mercurial repository
and work on it with Git, and then possibly use "git push" to possibly
push the result back to Mercurial?

It seems to me that use of DVCS is polarising between Git, Mercurial
and Bzr. It would be nice to have easy interoperability between the
systems, at least as far as can be covered by the lowest common
denominator of what they support. I would love to be able to use Git to
clone a Bzr repository that I need to be able to access, since bzr is
just different enough from Git to be annoying. Same goes for Mercurial.
And I am sure that users of the other tools feel the same.

Would it be possible to design a common transfer format that could be
implemented by all three (and that would be a little smarter than
fast-export/fast-import)?

--
\\// Peter - http://www.softwolves.pp.se/
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Johannes Schindelin]

Hi,

On Tue, 28 Oct 2008, Peter Krefting wrote:

> How difficult are the storage formats? Would it be possible, in a
> reasonable amount of work, to add support for the Mercurial protocol
> and format in "git clone", so that I could clone a Mercurial repository
> and work on it with Git, and then possibly use "git push" to possibly
> push the result back to Mercurial?

There was talk about imitating Mercurial's wire protocol in order to have
an efficient HTTP server.  Shawn is working on that front;

We discussed it briefly, and there might be some cute ways to copy it:
since we are not append-only, we have to download the pack index first
(which is not downloaded ATM, as we generate it from the downloaded pack
while verifying it).  With that index, we can determine which parts we
need in order to regenerate the pack; it would still be pretty stupid when
there are a lot of branches and we are really only interested in one of
them.

But I doubt that it will be possible to use the wire protocol to pull/push
between different DVCSes.  I _strongly_ doubt that the SHA-1s in the
Mercurial repositories could _ever_ be reused in Git mirrors of them, as
our data format (on which the hash depends) is different.

> It would be nice to have easy interoperability between the systems, at
> least as far as can be covered by the lowest common denominator of what
> they support. I would love to be able to use Git to clone a Bzr
> repository that I need to be able to access, since bzr is just different
> enough from Git to be annoying. Same goes for Mercurial. And I am sure
> that users of the other tools feel the same.

Wasn't bzr touting it as one of their major features that they could have
foreign-scm remotes?  If I remembered that correctly, that might be the
route you want to take.

Ciao,
Dscho

--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Matthieu Moy]

Johannes Schindelin <[hidden email]> writes:

> Wasn't bzr touting it as one of their major features that they could have
> foreign-scm remotes?  If I remembered that correctly, that might be the
> route you want to take.

Yes, see http://bazaar-vcs.org/BzrForeignBranches . That can be
compared to git-svn for git, except that one uses the exact same
command set to interact with the remotes (i.e. you "bzr push" to an
svn repository, while you would "git svn dcommit" with git).

There are read-only implementations of Git and Mercurial foreign
branches. AFAIK, unfortunately, they're more proof of concepts than
real "production ready" plugins.

--
Matthieu
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Nicolas Pitre]

On Tue, 28 Oct 2008, Peter Krefting wrote:

> Johannes Schindelin:
>
> > While many may say that that is a half-baked solution, I actually
> > like it. Mercurial and Git are pretty similar in their concept (if
> > not in how the data is actually stored).
>
> That touches on something that I have been thinking about for a while.
>
> How difficult are the storage formats? Would it be possible, in a
> reasonable amount of work, to add support for the Mercurial protocol
> and format in "git clone", so that I could clone a Mercurial repository
> and work on it with Git, and then possibly use "git push" to possibly
> push the result back to Mercurial?

The git protocol is intimately tied to its repository storage format,
making any interoperability at the protocol level really hard.  It is
probably easier to perform the clone/push operations with native tools
and do the interoperability dance locally between repositories, possibly
with some wrappers hiding all the details.  In the end you could still
be doing a "git push" but the native tool is best for handling transfer
protocols.  Yes, there is git-cvsserver outperforming a real CVS server,
but that's another story.


Nicolas
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Pieter de Bie-3]

On 28 okt 2008, at 15:41, Peter Krefting wrote:

> It seems to me that use of DVCS is polarising between Git, Mercurial
> and Bzr. It would be nice to have easy interoperability between the
> systems, at least as far as can be covered by the lowest common
> denominator of what they support. I would love to be able to use Git  
> to
> clone a Bzr repository that I need to be able to access, since bzr is
> just different enough from Git to be annoying. Same goes for  
> Mercurial.
> And I am sure that users of the other tools feel the same.
>
> Would it be possible to design a common transfer format that could be
> implemented by all three (and that would be a little smarter than
> fast-export/fast-import)?

What would you want that the fast-export/imports are lacking? I think  
they are excellent tools to build some integration on.

You might want to look at my git-bzr script (http://github.com/pieter/git-bzr/tree/master 
), which I created so I could use
bazaar branches easily in git. It allows you to fetch a bzr branch,  
merge it in with your local work, and then push it out again:

        git bzr add bzr-branch ~/bazaar/something
        git bzr fetch bzr-branch
        git merge bzr/bzr-branch
        git bzr push bzr-branch

It's quite crude, but it's also only 100 lines or so and does what I  
need. It should also be simple enough to adapt it to also incorporate  
hg. When I needed the bzr integration, I looked into hg as well, but  
there wasn't a hg fast-import yet. If I understand dscho correctly,  
that exists now, so it should be easy enough to integrate that as well.

- Pieter
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Andreas Ericsson]

Arne Babenhauserheide wrote:

> Am Montag 27 Oktober 2008 22:07:16 schrieb Miklos Vajna:
>> IIRC the main reason git aliases can't overwrite git commands is because
>> that would break scripts relying on the output of existing git commands.
>> Given that I install such an extension, won't my script break?
>
> Since that "script" will likely be an extension which will use the core
> function instead of the UI command, it won't break.
>
> Stuff which does command line parsing can naturally break when I change the
> output. But it can also directly use the advanced features.
>

But then you're back with a single language, taking valuable freedom
away from the addon author. How many perl gurus have skipped writing
stuff for hg because it's a "python-or-bust" thing?

And please don't give me that rubbish of "but Python is obviously better
than C". Which one's true (if any) depends only on how you define "better".

--
Andreas Ericsson                   [hidden email]
OP5 AB                             www.op5.se
Tel: [phone]                  Fax: [phone]
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to [hidden email]
More majordomo info at  http://vger.kernel.org/majordomo-info.html