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.
I've already cast my vote for git, which I confess is not very

honest because I've never even tried mercurial.  I would truly

be grateful to anyone here who knows both git and mercurial who

could contribute verifiable facts to that debate.
Thanks.
--

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

Boy, whoever has the popcorn concession must be making a fortune!
-Miles
--

Infancy, n. The period of our lives when, according to Wordsworth, 'Heaven

lies about us.' The world begins lying about us pretty soon afterward.

--

Hi,
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
--

FWIW at the Google Summer of Code Mentor Summit this past weekend

we had a "Git vs. Hg" talk with both Git and Hg represented by

contributors to each project.
Slides are online here:
  http://docs.google.com/Presentation?id=dcfz2dg9_0hqqz3dsr
--

Shawn.

--

But how do I save the presentation?  I do not seem to be able to do it.  I

would like to view it off-line.
Thanks,
--

Boyd Gerber <gerberb@zenez.com>

ZENEZ	1042 East Fort Union #135, Midvale Utah  84047

--

Hi,
Just an idea: print to PDF?  There is a link "print slides" on the lower

right.
Ciao,

Dscho
--

That worked.  I had to make my window full screen to see the option.  It

did not show-up in my normal window.
Thanks,
--

Boyd Gerber <gerberb@zenez.com>

ZENEZ	1042 East Fort Union #135, Midvale Utah  84047

--

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/

--

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

--

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

--

Hi!
Speed. I am cloning from a rather overloaded server on the other side

of the globe (the US). If I were to go the fast-export/import route, I
Looks very interesting. *adding to my things-to-examine list*
--

\\// Peter - http://www.softwolves.pp.se/

--

On Tue, Oct 28, 2008 at 04:33:54PM +0100, Pieter de Bie <pdebie@ai.rug.nl> =
That's new to me. Theodore Ts'o once mentioned on this list that there

is a "hg fast-export" but actually he just referred to "there is a

git2hg conversion tool in hg's contrib dir" and it has nothing with

fast-import.
There is an other reference to hg fast-import:
http://www.nabble.com/cvs2git-2.1-causes-git-fast-import-to-exit-with-an...

ror-td16049922.html
but I found no code so far.
To sum up, I'm not so sure about a working hg fast-import is available

at the moment.

The code I was referring to was called hg-fast-export, which is part

of the "fast export" tools that front-end into git fast-import.  The

git repository can be found here:
	http://repo.or.cz/w/fast-export.git

	git://repo.or.cz/fast-export.git
I ended up using a very customized version of that script to convert

the hg e2fsprogs repository to git.
In the past I've looked at the possibility of creating a

bi-directional, incremental gateway between hg and git repositories.

The main thing which makes this difficult is that hg stores tags

in-band inside the change-controlled .hgtags file.  This means that if

you cut a release, tag it, and then create a commit to further modify

the repository, the new commit is descended from the tag commit,

whereas in git, the tag is a "bookmark" --- perhaps signed via GPG,

but not part of the revision history.
I think the git method is much more sane, but what it means is that

topologically, the commit tree for git and hg can never be identical.

It also means that if you add a tag to a git tree after making several

commits on that branch, how you reflect that in the hg repository is

highly problematic.  Do you rewrite the branch?  Do you add the tag

later on, disturbing the parent-child relationship of later commits?

How do you keep track of when a tag hg repository topology if you are

trying to maintain a bidirectional mapping between commits?
It's not impossible, but it makes it much more difficult, since in the

hg world, tag commits can be inserted between arbitrary commits.  This

also means that if you want to create a bidrectional gateway between

hg and git, it has to be a single gateway so it can keep track of this

state information.  If you try to have multiple gateways they would

need to synchronize on when a tag entered the hg universe, and with

what commit ID (and what timestamp).
						- Ted

--

Couldn't you just keep the .hgtags file and have everyone interested

in the tags use special scripts?
(Admittedly, I'm horribly totally by Git's behavior in this area.  I

haven't figured out yet under what circumstances tags are pushed and

pulled, so I'm not totally opposed to the Mercurial model. 8-/)

--

I think you don't understand the issue here.
First, I think that we all agree here that by definition tags should

named reference (for example 'v1.0' or '1.0') to some immutable

snapshot of a state of repository, so for example when somebody says

'v1.0' everybody knows what it is.  In Git tags are immutable (you

can't checkout a tag, you can only checkout state pointed by tag)

external pointers to commits in the DAG (graph) of revisions.
Global tags (tags used to mark releases like 'v1.0') have to _not

versioned_ and _transferable_.  Transferable (global) because we want

to know for example what 'v1.0' version was in each clone / each

repository.  Non-versioned because we want to have the same set of

tags independent on what branch we are (when we are on 'master', we

want to be able to know about 'v1.0.1' which is on 'maint'), and what

revision we have checked out (for example during bisection, we want to

be able to compare to 'v1.0' even if we have checked out revision

which is earlier than 'v1.0').
Do you agree that global tags should be both non-versioned and

trasferable?
Now Mercurial has chosen to use in-tree '.hgtags' file to have global

tags transferable.  Never mind the fact that it had to treat this file

in special way to have it non-versioned (as opposed to for example

.*ignore file, which should be both transferable and versioned); the

fact that in-tree file is used means that tag is visible to outside

(transferable) only after you commit changes in .hgtags file.
In Git tags are external to object database; they reside in

refs/tags/* namespace.  They are of course non-versioned, as not being

in-tree.  In default configuration however (from what I understand) if

you transfer (get) some tagged commit, you also get a tag that points

to transferred commit.  You don't need to create "PROJECT 1.0" (or

"Tagged v1.0") commit to make tag visible to outside.
In short, if you want to have bi-directional gateway between Mercurial

and Git, Git has to be limited:

 * no...
[ message continues ]

Yes, I do.  In case of Git, I've got trouble with understanding how to

actually implement the "transferable" part with Git.  The Mercurial

way is easier to understand, but it means that tags may need some sort

of "tag at this revision" qualifier to disambiguate, which is rather
Oops, thought this file was versioned.  Things like
  <http://tycoon.hpl.hp.com/changeset/932:931d181e9f58/.hgtags>
suggest it was at some point.

--

.hgtags is stored as a versioned file in Mercurial.  That's one of the

problems, and it leads to no shortage of headaches.
Some of the problems are discussed here:
   http://www.selenic.com/mercurial/wiki/index.cgi/Tag
Specifically, to quote the Mercurial Wiki:
    The fact that tags identify changesets and are also parts of

    changesets has some potentially confusing implications:
    * The changeset that a tag refers to is always older than the

      changeset that commits the tag itself.
    * Updating a working dir to a particular tag will take that

      directory back to a point before the tag itself existed.
    * Cloning a repo to a particular tag will give you a new repo that

      does not have that tag.
In addition, Mercurial has to play interesting special case games in a

repository which has multiple heads (in git terms, "branches").  When

looking up a tag, it has to take the union of all of the .hgtags files

at the tips of each of the branches.  So if you have a large number of

heads in your Mercurial repository, tags access doesn't scale well at

all.  Mercurial is very much optimized for having a single or at best

a few heads/branches in a repository.
As I mentioned earlier this makes it much more difficult to do a

bidrectional hg/git gateway, since the two DAG's are not toplogically

equivalent, and in fact, *when* you add a tag to a particular

commit/revision can make a distinct difference to the shape of the

DAG.  If you tag right after creating the revision in question, then

there is a tag commit right after the revision.  If you commit a few

dozen changes into the repository, and *then* tag a point many commits

earlier, then the tag commit will be tacked onto the head of whatever

branch you happened to be on.
In fact, in the worst case, if you accidentally tag a revision on the

"maint" branch while you happened to be on the "devel" branch, the tag

for the commit in the "maint" branch will be attached to the "devel"

branch, and while it wil...
[ message continues ]

I told people this was insane long long ago, and I thought the hg people

had learnt to use local tags. They act sanely, as far as I know (ie they

act the same way git tags do).
Of course, the problem with hg local tags is that hg apparently has no

sane way to _propagate_ such local tag-space information from one

repository to another. But that's purely a problem with hg itself. I don't

know why that hasn't gotten fixed.
			Linus

--

Yeah, well, hg calls them _local_ tags, and so people consider that by

design, they aren't supposed to be propagated outside of the local

repository.  As I recall, hg doesn't support GPG signing local tags,

for the same reason.
							- Ted

--

In first page of git-fetch(1):
     When <refspec> stores the fetched result in  tracking  branches,  the  tags

     that  point  at  these branches are automatically followed. This is done by

     first fetching from the remote using  the  given  <refspec>s,  and  if  the

     repository has objects that are pointed by remote tags that it does not yet

     have, then fetch those missing tags. If the other end has tags  that  point

     at branches you are not interested in, you will not get them.
You push tags explicitly (using "tag <tagname>" refspec, or specifying
It is half-versioned... :-X  From what I remember of discussion on

#revctrl and reading hgbok it is treated in special way: if you

switch branches or rewind to some older version, .hgtags is always

checked out the most recent version.
I don't know how Mercurial deals with situation where one reposityr

added one tag, and other repository add other...
--

Jakub Narebski

Poland

--

Okay, checked it--.hgtags files are in fact versioned.  So my

suggestion to preserve the .hgtags file on the Git side remains.

--

Tag are pushed when you tell it so, and pulled if they are pointing to

the history you have, or you can ask to fetch them explicitly.
HTH,

Santi

--

On Tue, Oct 28, 2008 at 05:31:44PM -0400, Theodore Tso <tytso@mit.edu> wrot=
My bad, I did not quote the article properly, so here is what I meant:
http://article.gmane.org/gmane.comp.version-control.git/42298
and I just wanted to say that this one does not use fast-import, so it's

not really a "hg-fast-import" (it's not something that can parse the

output of git-fast-export).

I wrote too fast.
There is a minimal implementation here:
http://hg.opensource.lshift.net/hg-fastimport/
(I haven't tried it yet myself.)

Hi,
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 
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
--

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

--