login
Search
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! --
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 --
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/ --
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 --
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 --
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-er= 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.
I wrote too fast. There is a minimal implementation here: http://hg.opensource.lshift.net/hg-fastimport/ (I haven't tried it yet myself.)
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 --
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).
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-/) --
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 --
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: ...
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. --
Okay, checked it--.hgtags files are in fact versioned. So my suggestion to preserve the .hgtags file on the Git side remains. --
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
--
.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 ...
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 --
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/ --
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 --
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 --
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. --
