# Deciding between Git/Mercurial 44 messages from 2009-09-27 to 2009-10-22. Participants: Anteru, Robin Rosenberg, Alex Riesen, Mark Struberg, Pascal Obry, Erik Faye-Lund, Felipe Contreras, Matthieu Moy, Johannes Schindelin, Bruce Stephens, Dilip M, Damien Wyart, Steven Noonan, Sverre Rabbelier, Jakub Narebski, Randal L. Schwartz, Paolo Bonzini, Mike Ralphson, Daniele Segato, Leo Razoumov, Björn Steinbrink, Andreas Ericsson, Matthias Andree, Daniel Barkalow, Martin Langhoff. Thread: https://gitlist.dev/t/21071 ## Anteru, 2009-09-27 12:24 Subject: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/h9nlhj%24heq%241%40ger.gmane.org ``` Hi, I'm currently evaluating DVCS for a project, and we're at a point where it comes down to either Mercurial or Git. Right now, I'm advocating for Git, while my co-workers like Mercurial, so I'd like to provide some good arguments in favor of git. Unfortunately, I'm not a git expert, so I hope I can get some help here ... First of all, what's the matter with git and Windows, is there some long-term commitment to make git work on Windows as well as on Linux? I'm using msysgit on Windows, and personally I'm happy with it, but my co-workers constantly nag that Mercurial has superior portability ... Mercurial's revision number system: With git, I get an SHA1 hash for every commit, but it's not possible to see whether Hash1 is newer than Hash2, while Mecurial also adds a running number to each commit. What's the rationale behind this decision for git, and is it possible to emulate Mercurial's behavior somehow? Integration into tools: We're using Trac currently, which also has a nice binding to Mercurial (well, obviously easy to do as Mercurial is written in Python, just as Trac itself), while the git support is in development and looks quite alpha'ish. Do you plan to make it easier to integrate git with other tools by providing bindings to other languages, or is this a low-priority issue? So far, my key arguments are that git is more robust (more projects using it, larger developer base), of course git's excellent performance and the much better support for SVN, which is important for us as we can slowly migrate from SVN->Git, while hgmercurial is still in the making (and Python's SVN->Hg switch is for instance waiting for it). Cheers, Anteru ``` ## Robin Rosenberg, 2009-09-27 18:01 Subject: Re: Deciding between Git/Mercurial Message-ID: <200909272001.48180.robin.rosenberg.lists@dewire.com> URL: https://gitlist.dev/e/200909272001.48180.robin.rosenberg.lists%40dewire.com In-Reply-To: ``` söndag 27 september 2009 14:24:32 skrev Anteru : > Hi, > > I'm currently evaluating DVCS for a project, and we're at a point where > it comes down to either Mercurial or Git. Right now, I'm advocating for > Git, while my co-workers like Mercurial, so I'd like to provide some > good arguments in favor of git. Unfortunately, I'm not a git expert, so > I hope I can get some help here ... You have to read carefully. This (or the mercurial list) may not be the most objective sources of information. > First of all, what's the matter with git and Windows, is there some > long-term commitment to make git work on Windows as well as on Linux? Besides msysgit there is JGit and a port of it to C# (and thus any dotnet-ish language). The msysgit teams seems very committed and passionate about the project, but they need more assistance from genuine Windows users. Note that the current model of file locking can never work as well on Windows as it does on Unix. Something better is needed for flawless operation. > I'm using msysgit on Windows, and personally I'm happy with it, but my > co-workers constantly nag that Mercurial has superior portability ... Might be somewhat true, but msysgit works very well. Not sure how mercurial handles unicode issues. CRLF issues seems to be ignored (not handled). > Mercurial's revision number system: With git, I get an SHA1 hash for > every commit, but it's not possible to see whether Hash1 is newer than > Hash2, while Mecurial also adds a running number to each commit. What's But those numbers cannot be communicated since they are local to your clone. > the rationale behind this decision for git, and is it possible to > emulate Mercurial's behavior somehow? git-cvsserver has to do something along those line The numbering is per file. Maintainers tend to tag versions using the common numbered schem and that is typically enough. -- robin ``` ## Anteru, 2009-09-27 18:10 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/h9o9qr%24548%241%40ger.gmane.org In-Reply-To: <200909272001.48180.robin.rosenberg.lists@dewire.com> ``` Robin Rosenberg wrote: > You have to read carefully. This (or the mercurial list) may not be the > most objective sources of information. Sure, but at the moment, I'm advocating pro-git, so I'm biased as well :) > Might be somewhat true, but msysgit works very well. Not sure how > mercurial handles unicode issues. CRLF issues seems to be ignored (not handled). Yeah, well, the main question here is actually: Is improved support for Windows one of the goals of future git development, or is this a complete non-issue? Cheers, Anteru ``` ## Alex Riesen, 2009-09-27 18:44 Subject: Re: Deciding between Git/Mercurial Message-ID: <81b0412b0909271144o26743e05uac3132cdc5b530b@mail.gmail.com> URL: https://gitlist.dev/e/81b0412b0909271144o26743e05uac3132cdc5b530b%40mail.gmail.com In-Reply-To: ``` On Sun, Sep 27, 2009 at 20:10, Anteru wrote: > Yeah, well, the main question here is actually: Is improved support for > Windows one of the goals of future git development, or is this a > complete non-issue? I just hope it is not. Improved Windows support mostly means lots of dead code (and that's the best outcome), which no other platform can use. ``` ## Mark Struberg, 2009-09-27 18:51 Subject: Re: Deciding between Git/Mercurial Message-ID: <585748.13758.qm@web27802.mail.ukl.yahoo.com> URL: https://gitlist.dev/e/585748.13758.qm%40web27802.mail.ukl.yahoo.com In-Reply-To: <81b0412b0909271144o26743e05uac3132cdc5b530b@mail.gmail.com> ``` Another thing to consider: For what kind of project/language do you need git? What build tools are you using and how good is the integration into both git and hg? LieGrue, strub --- On Sun, 9/27/09, Alex Riesen wrote: > From: Alex Riesen > Subject: Re: Deciding between Git/Mercurial > To: newsgroups@catchall.shelter13.net > Cc: git@vger.kernel.org > Date: Sunday, September 27, 2009, 8:44 PM > On Sun, Sep 27, 2009 at 20:10, Anteru > > wrote: > > Yeah, well, the main question here is actually: Is > improved support for > > Windows one of the goals of future git development, or > is this a > > complete non-issue? > > I just hope it is not. Improved Windows support mostly > means lots of dead code (and that's the best outcome), > which no other platform can use. > -- > To unsubscribe from this list: send the line "unsubscribe > git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at  http://vger.kernel.org/majordomo-info.html > ``` ## Pascal Obry, 2009-09-27 18:55 Subject: Re: Deciding between Git/Mercurial Message-ID: <4ABFB517.6040103@obry.net> URL: https://gitlist.dev/e/4ABFB517.6040103%40obry.net In-Reply-To: ``` Le 27/09/2009 20:10, Anteru a écrit : > Yeah, well, the main question here is actually: Is improved support for > Windows one of the goals of future git development, or is this a > complete non-issue? I think it is a non-issue as Git compile out of the box with Cygwin. Since many years I'm building Git almost daily from master under my Windows box using Cygwin. git-svn works like a charm too. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net - http://v2p.fr.eu.org --| "The best way to travel is by means of imagination" --| --| gpg --keyserver keys.gnupg.net --recv-key F949BD3B ``` ## Anteru, 2009-09-27 19:18 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/h9odqq%24ig9%241%40ger.gmane.org In-Reply-To: <585748.13758.qm@web27802.mail.ukl.yahoo.com> ``` Mark Struberg schrieb: > Another thing to consider: For what kind of project/language do you need git? What build tools are you using and how good is the integration into both git and hg? The project is running on Windows/Linux (Windows being the primary development platform, and we also expect most users to run Windows.) For tooling, we use Trac at the moment (good integration with SVN), but we're evaluating GitTrac, Trac/Mercurial and Redmine now (+ possible migration paths.) For our build system, it's a non-issue anyway, as git/mercurial have command line clients, and that's all we need. Don't get me wrong with Git+msysgit on Windows, the point is simply if we switch to git, can we expect that Windows will be supported for the foreseeable future or is it possible that git may simply drop Windows support completely? For Mercurial, this is a non-issue, as it is written in Python, and Python will support both Windows and Linux. As I said, I'm happy with using msysgit, but I cannot find any roadmap etc. which helps me to determine how git and Windows is going to continue (for instance, I can find some complaints that git's performance is bad on Windows due to cygwin's fork()/exec(), is this likely to get ever "fixed"? I guess git# will solve this as soon as it's ready?) Cheers, Anteru ``` ## Alex Riesen, 2009-09-27 19:31 Subject: Re: Deciding between Git/Mercurial Message-ID: <81b0412b0909271231u54fbe035n3ce2503237b5ebf3@mail.gmail.com> URL: https://gitlist.dev/e/81b0412b0909271231u54fbe035n3ce2503237b5ebf3%40mail.gmail.com In-Reply-To: ``` On Sun, Sep 27, 2009 at 21:18, Anteru wrote: > Don't get me wrong with Git+msysgit on Windows, the point is simply if > we switch to git, can we expect that Windows will be supported for the > foreseeable future or is it possible that git may simply drop Windows > support completely? ... Despite what I said, this is very unlikely (sadly). There are active developers whose professional life happens in Windows. Besides, the project is open- source and no one can stop you from taking over the maintainership of a port. > As I said, I'm happy with using msysgit, but I cannot find any roadmap There isn't any. Roadmaps are for projects with a guaranteed end of life :-p > etc. which helps me to determine how git and Windows is going to > continue (for instance, I can find some complaints that git's > performance is bad on Windows due to cygwin's fork()/exec(), is this > likely to get ever "fixed"? Not likely. OTOH, msysGIT does not have that part of performance problem. ``` ## Erik Faye-Lund, 2009-09-27 19:34 Subject: Re: Deciding between Git/Mercurial Message-ID: <40aa078e0909271234l227e9d27i71fcdc788a78c850@mail.gmail.com> URL: https://gitlist.dev/e/40aa078e0909271234l227e9d27i71fcdc788a78c850%40mail.gmail.com In-Reply-To: ``` On Sun, Sep 27, 2009 at 9:18 PM, Anteru wrote: > Don't get me wrong with Git+msysgit on Windows, the point is simply if > we switch to git, can we expect that Windows will be supported for the > foreseeable future or is it possible that git may simply drop Windows > support completely? For Mercurial, this is a non-issue, as it is written > in Python, and Python will support both Windows and Linux. The chance of Windows support being dropped from git is very unlikely - there's way too many people depending on git for Windows already for that to happen. Besides, git is open source, so you can always fix Windows issues yourself. As for Mercurial, Python programs aren't automatically portable to Windows either. But I expect that they have the same very close to zero chance of having Windows support dropped as git has. > As I said, I'm happy with using msysgit, but I cannot find any roadmap > etc. which helps me to determine how git and Windows is going to > continue (for instance, I can find some complaints that git's > performance is bad on Windows due to cygwin's fork()/exec(), is this > likely to get ever "fixed"? I guess git# will solve this as soon as it's > ready?) Git (neither mainline nor msysgit) doesn't have any official roadmap as far as I know. People just hack away on what they feel is important. If you want to make sure something gets done, chip in the development-time yourself. As for the fork()-performance, this is only an issue for some tools (if any at all - I don't think this issue exists in msysgit). In my experience, git on Windows is faster than any other VCS I've ever used on Windows. -- Erik "kusma" Faye-Lund kusmabite@gmail.com (+47) 986 59 656 ``` ## Felipe Contreras, 2009-09-28 08:36 Subject: Re: Deciding between Git/Mercurial Message-ID: <94a0d4530909280136s1ff65004q1733bd4ef78bdc07@mail.gmail.com> URL: https://gitlist.dev/e/94a0d4530909280136s1ff65004q1733bd4ef78bdc07%40mail.gmail.com In-Reply-To: ``` On Sun, Sep 27, 2009 at 3:24 PM, Anteru wrote: > Hi, > > I'm currently evaluating DVCS for a project, and we're at a point where > it comes down to either Mercurial or Git. Right now, I'm advocating for > Git, while my co-workers like Mercurial, so I'd like to provide some > good arguments in favor of git. Unfortunately, I'm not a git expert, so > I hope I can get some help here ... IMO the key difference between hg and git is the storage model: hg stores deltas, while git stores snapshots. That would mean that certain operations are theoretically faster in git (e.g. checkout, diff) while others faster in hg, although with git's packed format I guess there's no operation faster in hg. This means that it doesn't matter how much hg's python code improves, or if they even re-write parts in C, they will never be able to match git's performance (unless they change the storage model, which essentially means changing the whole design -- won't happen). All this is just guesses, I've thought about doing some measurements but I haven't had time. Cheers. -- Felipe Contreras ``` ## Matthieu Moy, 2009-09-28 08:42 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/vpq7hvjfojb.fsf%40bauges.imag.fr In-Reply-To: <94a0d4530909280136s1ff65004q1733bd4ef78bdc07@mail.gmail.com> ``` Felipe Contreras writes: > IMO the key difference between hg and git is the storage model: hg > stores deltas, while git stores snapshots. Mercurial stores regular snapshots, to make sure you never have to apply too many deltas to get a snapshot. That's not so different from what Git does with its packed format (the difference is that Git's delta are not necessarily against the direct ancestor of the file). AFAICT, both are snapshot-oriented, but both use a compression algorithm based on delta. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ``` ## Johannes Schindelin, 2009-09-28 10:08 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/alpine.DEB.1.00.0909281059180.4985%40pacific.mpi-cbg.de In-Reply-To: <94a0d4530909280136s1ff65004q1733bd4ef78bdc07@mail.gmail.com> ``` Hi, I tried to refrain from commenting in this thread, because I do not want to encourage people just to use msysGit and never even attempt to fix their own issues. But I cannot let this go uncommented: On Mon, 28 Sep 2009, Felipe Contreras wrote: > IMO the key difference between hg and git is the storage model: hg > stores deltas, while git stores snapshots. That would mean that certain > operations are theoretically faster in git (e.g. checkout, diff) while > others faster in hg, although with git's packed format I guess there's > no operation faster in hg. This means that it doesn't matter how much > hg's python code improves, or if they even re-write parts in C, they > will never be able to match git's performance (unless they change the > storage model, which essentially means changing the whole design -- > won't happen). That is wrong. "git log -- " will always be slightly faster in Mercurial, for all the reasons you mentioned. In addition, Mercurial _has_ parts re-written in C for performance, which renders it not-exactly more portable if you ask me. Last time I checked, there was no way to compile a Python module with MinGW (or for that matter, Python itself), but you needed MSVC... Ciao, Dscho ``` ## Felipe Contreras, 2009-09-28 11:01 Subject: Re: Deciding between Git/Mercurial Message-ID: <94a0d4530909280401q4a451697re8954320682662f2@mail.gmail.com> URL: https://gitlist.dev/e/94a0d4530909280401q4a451697re8954320682662f2%40mail.gmail.com In-Reply-To: ``` On Mon, Sep 28, 2009 at 1:08 PM, Johannes Schindelin wrote: > Hi, > > I tried to refrain from commenting in this thread, because I do not want > to encourage people just to use msysGit and never even attempt to fix > their own issues. > > But I cannot let this go uncommented: > > On Mon, 28 Sep 2009, Felipe Contreras wrote: > >> IMO the key difference between hg and git is the storage model: hg >> stores deltas, while git stores snapshots. That would mean that certain >> operations are theoretically faster in git (e.g. checkout, diff) while >> others faster in hg, although with git's packed format I guess there's >> no operation faster in hg. This means that it doesn't matter how much >> hg's python code improves, or if they even re-write parts in C, they >> will never be able to match git's performance (unless they change the >> storage model, which essentially means changing the whole design -- >> won't happen). > > That is wrong.  "git log -- " will always be slightly faster in > Mercurial, for all the reasons you mentioned. Ok, thanks for pointing that out. I was thinking that maybe 'git blame' would also be slightly faster on hg, but I really don't know. Anyway, I think for most operations git would always be faster, and more importantly; some essential operations will be faster (checkout, diff ). -- Felipe Contreras ``` ## Bruce Stephens, 2009-09-28 11:17 Subject: Re: Deciding between Git/Mercurial Message-ID: <804oqn5nes.fsf@tiny.isode.net> URL: https://gitlist.dev/e/804oqn5nes.fsf%40tiny.isode.net In-Reply-To: <94a0d4530909280401q4a451697re8954320682662f2@mail.gmail.com> ``` Felipe Contreras writes: [...] > Ok, thanks for pointing that out. I was thinking that maybe 'git > blame' would also be slightly faster on hg, but I really don't know. hg (and git) store binary deltas. AFAIK neither attempts to use those to produce output for blame, diff, etc. (git's deltas may well be slightly different from mercurial's, in that git's can be deltas with respect to something arbitrary so even if they had a suitable line-based format they'd be useless for diff, blame.) Similarly for the other major systems, with the exception of (I think) bzr and darcs. (I don't know how bzr or darcs actually work, but IIRC they both have line-based storage that in principle might be usable in computing blame and diff.) [...] ``` ## Dilip M, 2009-09-28 11:32 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/c94f8e120909280432r35794641ycd50b4cee0bd89b7%40mail.gmail.com In-Reply-To: ``` You better evaluate yourself on the project you are going to use git or Hg. Hg and git are used both by big companies. Google uses git to host android, where as it also uses Hg to host google wave! So don't go which company uses what, but try to evaluate... Check what is the kind of operations your developers do often? Is it checkout, diff, blame, also are they ready to do git gc often? What about developer who is not interested in using cli? How do u care them for operations they intended to do? what is the workflow? Which tools supports it to great extent? At the end of day, it is a developer who spends much time using tool.. Just my opinion...... you put this question in Hg list, I bet you will get the different views.... The above is solely my opinion and I am not biased! I think so:) On 9/27/09, Anteru wrote: > Hi, > > I'm currently evaluating DVCS for a project, and we're at a point where > it comes down to either Mercurial or Git. Right now, I'm advocating for > Git, while my co-workers like Mercurial, so I'd like to provide some > good arguments in favor of git. Unfortunately, I'm not a git expert, so > I hope I can get some help here ... > > First of all, what's the matter with git and Windows, is there some > long-term commitment to make git work on Windows as well as on Linux? > I'm using msysgit on Windows, and personally I'm happy with it, but my > co-workers constantly nag that Mercurial has superior portability ... > > Mercurial's revision number system: With git, I get an SHA1 hash for > every commit, but it's not possible to see whether Hash1 is newer than > Hash2, while Mecurial also adds a running number to each commit. What's > the rationale behind this decision for git, and is it possible to > emulate Mercurial's behavior somehow? > > Integration into tools: We're using Trac currently, which also has a > nice binding to Mercurial (well, obviously easy to do as Mercurial is > written in Python, just as Trac itself), while the git support is in > development and looks quite alpha'ish. Do you plan to make it easier to > integrate git with other tools by providing bindings to other languages, > or is this a low-priority issue? > > So far, my key arguments are that git is more robust (more projects > using it, larger developer base), of course git's excellent performance > and the much better support for SVN, which is important for us as we can > slowly migrate from SVN->Git, while hgmercurial is still in the making > (and Python's SVN->Hg switch is for instance waiting for it). > > Cheers, > Anteru > > -- > To unsubscribe from this list: send the line "unsubscribe git" in > the body of a message to majordomo@vger.kernel.org > More majordomo info at http://vger.kernel.org/majordomo-info.html > -- Sent from my mobile device Dilip ``` ## Damien Wyart, 2009-09-28 20:54 Subject: Re: Deciding between Git/Mercurial Message-ID: <20090928205458.GA2669@brouette> URL: https://gitlist.dev/e/20090928205458.GA2669%40brouette In-Reply-To: ``` Hello, * Anteru [2009-09-27 14:24]: > Integration into tools: We're using Trac currently, which also has > a nice binding to Mercurial (well, obviously easy to do as Mercurial > is written in Python, just as Trac itself), while the git support is > in development and looks quite alpha'ish. Do you plan to make it > easier to integrate git with other tools by providing bindings to > other languages, or is this a low-priority issue? Trac is one of the the most well-known project management tools, but Indefero is also interesting, and itegrates Git better than Trac: http://www.indefero.net/ Best, -- Damien Wyart ``` ## Steven Noonan, 2009-09-28 21:09 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/f488382f0909281409n1c1f7e5ex64a10147a14e39a%40mail.gmail.com In-Reply-To: <20090928205458.GA2669@brouette> ``` On Mon, Sep 28, 2009 at 1:54 PM, Damien Wyart wrote: > Hello, > > * Anteru [2009-09-27 14:24]: >> Integration into tools: We're using Trac currently, which also has >> a nice binding to Mercurial (well, obviously easy to do as Mercurial >> is written in Python, just as Trac itself), while the git support is >> in development and looks quite alpha'ish. Do you plan to make it >> easier to integrate git with other tools by providing bindings to >> other languages, or is this a low-priority issue? > > Trac is one of the the most well-known project management tools, but > Indefero is also interesting, and itegrates Git better than Trac: > http://www.indefero.net/ > The interface looks very similar to Google Code's. I wonder, is this the same thing that Google is using, or is it just mimicking the interface? - Steven ``` ## Sverre Rabbelier, 2009-09-28 21:33 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/fabb9a1e0909281433l461086e3k93a138ad4b9b86c6%40mail.gmail.com In-Reply-To: ``` Heya, On Mon, Sep 28, 2009 at 23:09, Steven Noonan wrote: > The interface looks very similar to Google Code's. I wonder, is this > the same thing that Google is using, or is it just mimicking the > interface? Whow, it _does_ look a lot like Google Code, I doubt it's the same code as I don't think Google Code's verison is open source, pretty good copy either way. -- Cheers, Sverre Rabbelier ``` ## Jakub Narebski, 2009-09-28 23:11 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/m33a66br69.fsf%40localhost.localdomain In-Reply-To: ``` Anteru writes: > I'm currently evaluating DVCS for a project, and we're at a point where > it comes down to either Mercurial or Git. Right now, I'm advocating for > Git, while my co-workers like Mercurial, so I'd like to provide some > good arguments in favor of git. Unfortunately, I'm not a git expert, so > I hope I can get some help here ... > > First of all, what's the matter with git and Windows, is there some > long-term commitment to make git work on Windows as well as on Linux? > I'm using msysgit on Windows, and personally I'm happy with it, but my > co-workers constantly nag that Mercurial has superior portability ... On one hand side Git relies quite a bit on POSIX features; also some of git commands are implemented as shell scripts, or are written in Perl. Nevertheless even if people stopped working on msysGit ("native" Windows port), which I don't see happening, there is always and will be git from Cygwin. But the msysGit team is active, and I predict that it soon would be full equivalent of Git on Linux (there are some corner cases yet). Lately there was even some work on support infrastructore for having Git be developed in MSVC. On the other hand side Mercurial does have some parts of its code rewritten in C for efficiency. I do wonder how portable it is, and what is more important how portable is the interface between C and Python. But I do not use MS Windows for development, and I do not use Mercurial... > Mercurial's revision number system: With git, I get an SHA1 hash for > every commit, but it's not possible to see whether Hash1 is newer than > Hash2, while Mecurial also adds a running number to each commit. What's > the rationale behind this decision for git, and is it possible to > emulate Mercurial's behavior somehow? First, you have to remember that this 'number of commit' thingy is *local* to your repository, so you cannot use commit numbers to communicate with other developers. This is inherent and unavoidable property of 'revision numbering': commit identifiers must be derivable from commit contents (e.g. SHA-1 used by Git), or must be local to clone of repository (e.g. Mercurial), or there must be some central numbering authority (like in centralized SCMs like Subversion). Second, I think advantages of revision numbering (running number) are overemphasized. I don't see how numbers such as 12678 and 12687 are easier to use than even abbreviated SHA-1 IDs like f06e7eb, never mind the "~" syntax Git uses to refer to n-th ancestor of current tip of given branch. Besides with nonlinear history with revision numbers such as 12678 and 12687 you know that 12678 is older than 12687 if and only if 12678 and 12687 are on the same line of development. Third, I think it would be possible to emulate mercurial behaviour with using lightweight 'number' tags for numbering, created from a hook. > Integration into tools: We're using Trac currently, which also has a > nice binding to Mercurial (well, obviously easy to do as Mercurial is > written in Python, just as Trac itself), while the git support is in > development and looks quite alpha'ish. Do you plan to make it easier to > integrate git with other tools by providing bindings to other languages, > or is this a low-priority issue? Well, I think that the problem with implementing bindings to other programming languages is that there is currently no such thing like the Git library (well, there are beginnings of one). This is caused by the fact that originally git commands were written in run-once philosophy, and e.g. rely on operating system to do the cleanups. So far bindings to other languages either call Git commands (like Git.pm Perl interface from Git, or JavaGit), or are native Git (re)implementations relying not on stable API, but on stable repository format (JGit for Java, Dulwich for Python, partially Grit for Ruby). The emphasisis in Git was (and is) for it to be *scriptable*, rather than extensible through plugins. BTW. the fact that JGit is reimplementation allows it to be use different license than Git itself; license which makes JGit and EGit to be license-compatibile with Eclipse, and allow to distribute EGit as full Eclipse project. > > So far, my key arguments are that git is more robust (more projects > using it, larger developer base), of course git's excellent performance > and the much better support for SVN, which is important for us as we can > slowly migrate from SVN->Git, while hgmercurial is still in the making > (and Python's SVN->Hg switch is for instance waiting for it). hgmercurial? or hgsubversion? There is also fact that git has superior support for multi-branch development, which I think is the workflow most suited for distributed development. -- Jakub Narebski Poland ShadeHawk on #git ``` ## Randal L. Schwartz, 2009-09-28 23:56 Subject: Re: Deciding between Git/Mercurial Message-ID: <86iqf2r5ch.fsf@blue.stonehenge.com> URL: https://gitlist.dev/e/86iqf2r5ch.fsf%40blue.stonehenge.com In-Reply-To: ``` >>>>> "Sverre" == Sverre Rabbelier writes: Sverre> Whow, it _does_ look a lot like Google Code, I doubt it's the same Sverre> code as I don't think Google Code's verison is open source, pretty Sverre> good copy either way. I gotta get these guys on FLOSS Weekly. Is anyone here a member of the team? -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion ``` ## Sverre Rabbelier, 2009-09-29 00:01 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/fabb9a1e0909281701j2d04a26dk43048133e85cd495%40mail.gmail.com In-Reply-To: <86iqf2r5ch.fsf@blue.stonehenge.com> ``` Heya, On Tue, Sep 29, 2009 at 01:56, Randal L. Schwartz wrote: > I gotta get these guys on FLOSS Weekly.  Is anyone here a member of > the team? There is of course the possiblity that the codesite team liked their design so much that they based theirs off of the Indefero thing :P. -- Cheers, Sverre Rabbelier ``` ## Jakub Narebski, 2009-09-29 00:32 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/m3y6nya8vo.fsf%40localhost.localdomain In-Reply-To: ``` Jakub Narebski writes: > Anteru writes: > > > I'm currently evaluating DVCS for a project, and we're at a point where > > it comes down to either Mercurial or Git. Right now, I'm advocating for > > Git, while my co-workers like Mercurial, so I'd like to provide some > > good arguments in favor of git. Unfortunately, I'm not a git expert, so > > I hope I can get some help here ... [...] > > So far, my key arguments are that git is more robust (more projects > > using it, larger developer base), of course git's excellent performance > > and the much better support for SVN, which is important for us as we can > > slowly migrate from SVN->Git, while hgmercurial is still in the making > > (and Python's SVN->Hg switch is for instance waiting for it). > > hgmercurial? or hgsubversion? > > There is also fact that git has superior support for multi-branch > development, which I think is the workflow most suited for distributed > development. See also http://whygitisbetterthanx.com/#hg -- Jakub Narebski Poland ShadeHawk on #git ``` ## Paolo Bonzini, 2009-09-29 01:55 Subject: Re: Deciding between Git/Mercurial Message-ID: <4AC1691D.5050600@gnu.org> URL: https://gitlist.dev/e/4AC1691D.5050600%40gnu.org In-Reply-To: ``` On 09/27/2009 02:24 PM, Anteru wrote: > What's > the rationale behind this decision for git, and is it possible to > emulate Mercurial's behavior somehow? While not exactly the same thing, 'git describe' is very helpful in comparing versions (if you know that one is an ancestor of the other). Paolo ``` ## Anteru, 2009-09-29 06:32 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/h9s9ll%24kqb%241%40ger.gmane.org In-Reply-To: ``` > First, you have to remember that this 'number of commit' thingy is > *local* to your repository, so you cannot use commit numbers to > communicate with other developers. This is inherent and unavoidable Ah cool, thanks for clarifying this. >> So far, my key arguments are that git is more robust (more projects >> using it, larger developer base), of course git's excellent performance >> and the much better support for SVN, which is important for us as we can >> slowly migrate from SVN->Git, while hgmercurial is still in the making >> (and Python's SVN->Hg switch is for instance waiting for it). > > hgmercurial? or hgsubversion? hgsubversion of course, which is supposed to be what git-svn is already. At the moment, I already use git with our SVN server, so I can show some of the advantages (for instance, renaming works much better than with SVN itself :) ), and I guess it also makes the migration easier as everyone can try with Git locally and we switch from SVN to Git once everyone has switched locally. Thanks for all the input so far! Cheers, Anteru ``` ## Mike Ralphson, 2009-09-29 07:44 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/e2b179460909290044q25c4b68fs3797764ae09ef2cb%40mail.gmail.com In-Reply-To: <86iqf2r5ch.fsf@blue.stonehenge.com> ``` 2009/9/29 Randal L. Schwartz : >>>>>> "Sverre" == Sverre Rabbelier writes: > > Sverre> Whow, it _does_ look a lot like Google Code, I doubt it's the same > Sverre> code as I don't think Google Code's verison is open source, pretty > Sverre> good copy either way. > > I gotta get these guys on FLOSS Weekly.  Is anyone here a member of > the team? Not a member of the team, just a user (and bug reporter!), but I believe Indefero is almost all the work of one pretty amazing guy, Dr Loïc d'Anterroches, cc'd above. Mike ``` ## Matthieu Moy, 2009-09-29 08:21 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/vpqljjykvpf.fsf%40bauges.imag.fr In-Reply-To: ``` Sverre Rabbelier writes: > Heya, > > On Mon, Sep 28, 2009 at 23:09, Steven Noonan wrote: >> The interface looks very similar to Google Code's. I wonder, is this >> the same thing that Google is using, or is it just mimicking the >> interface? > > Whow, it _does_ look a lot like Google Code, I doubt it's the same > code as I don't think Google Code's verison is open source, pretty > good copy either way. Indefero is a clone of Google code. http://www.google.com/search?q=indefero+clone+google+code (most links are in French, but this is what they say) -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ``` ## Sverre Rabbelier, 2009-09-29 08:22 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/fabb9a1e0909290122p65b01a5bh619b025852857110%40mail.gmail.com In-Reply-To: ``` Heya, On Tue, Sep 29, 2009 at 10:21, Matthieu Moy wrote: >  http://www.google.com/search?q=indefero+clone+google+code > > (most links are in French, but this is what they say) Might I suggest for those that are no masters of the french language: http://translate.google.com/translate_s?hl=en&clss=&q=indefero+clone+google+code&sl=en&tl=fr -- Cheers, Sverre Rabbelier ``` ## Daniele Segato, 2009-09-29 08:44 Subject: Re: Deciding between Git/Mercurial Message-ID: <9accb4400909290144t1363b5c6t8886bfa01e486c94@mail.gmail.com> URL: https://gitlist.dev/e/9accb4400909290144t1363b5c6t8886bfa01e486c94%40mail.gmail.com In-Reply-To: ``` On Sun, Sep 27, 2009 at 2:24 PM, Anteru wrote: > I'm currently evaluating DVCS for a project, and we're at a point where > it comes down to either Mercurial or Git. Right now, I'm advocating for > Git, while my co-workers like Mercurial, so I'd like to provide some > good arguments in favor of git. Unfortunately, I'm not a git expert, so > I hope I can get some help here ... > > First of all, what's the matter with git and Windows, is there some > long-term commitment to make git work on Windows as well as on Linux? > I'm using msysgit on Windows, and personally I'm happy with it, but my > co-workers constantly nag that Mercurial has superior portability ... Can I propose to make this discussion cross-mailing list adding the hg mailing list to the CC? I think it would be a good discussion if we don't end up flaming. Let me know what you think about it about the Windows+Git compatibility, you may consider TortoiseGit too for the not-CLI-oriented guys; I've seen it a while ago and it seems pettry well integrated with windows > Mercurial's revision number system: With git, I get an SHA1 hash for > every commit, but it's not possible to see whether Hash1 is newer than > Hash2, while Mecurial also adds a running number to each commit. What's > the rationale behind this decision for git, and is it possible to > emulate Mercurial's behavior somehow? If you tag a commit then you should be able to see how many commits there are from that one issuing a git describe (found on the internet) git commit -m'Commit One.' git tag -a -m'Tag One.' 1.2.3 git describe # => 1.2.3 git commit -m'Commit Two.' git describe # => 1.2.3-1-gaac161d git commit -m'Commit Three.' git describe # => 1.2.3-2-g462715d git tag -a -m'Tag Two.' 2.0.0 git describe # => 2.0.0 > So far, my key arguments are that git is more robust (more projects > using it, larger developer base), of course git's excellent performance > and the much better support for SVN, which is important for us as we can > slowly migrate from SVN->Git, while hgmercurial is still in the making > (and Python's SVN->Hg switch is for instance waiting for it). ``` ## Dilip M, 2009-09-29 08:54 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/c94f8e120909290154y5edc666ap22d261e7b4201a89%40mail.gmail.com In-Reply-To: <9accb4400909290144t1363b5c6t8886bfa01e486c94@mail.gmail.com> ``` On Tue, Sep 29, 2009 at 2:14 PM, Daniele Segato wrote: > Can I propose to make this discussion cross-mailing list adding the hg > mailing list to the CC? I think it would be a good discussion if we don't > end up flaming. Let me know what you think about it We will probably end in flames. Its same as comparing Vim and Emacs, Python and Perl... ...this comparison is all ver web. Checkout! http://importantshock.wordpress.com/2008/08/07/git-vs-mercurial/ My *personnel* opinion is, If it is for project _only_ on UNIX, than GIT and repo tool from Google will be killing combination. If project is on both Windows & UNIX (But consider where do you compile your code), than hg doesn't have matching! -- Dilip ``` ## Leo Razoumov, 2009-09-29 18:44 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/ee2a733e0909291144g4b99ab7ay9e63bfac935013aa%40mail.gmail.com In-Reply-To: ``` On 2009-09-28, Jakub Narebski wrote: > [..snip..] > Besides with nonlinear history with > revision numbers such as 12678 and 12687 you know that 12678 is older > than 12687 if and only if 12678 and 12687 are on the same line of > development. > The statement above is incorrect!! In a Mercurial repo local revision numbers are strictly ordered in commit time. 12678 < 12687 means that 12678 was committed prior to 12687. But these two commits could belong to two completely unrelated lines of development. --Leo-- ``` ## Jakub Narebski, 2009-09-29 18:58 Subject: Re: Deciding between Git/Mercurial Message-ID: <200909292058.53045.jnareb@gmail.com> URL: https://gitlist.dev/e/200909292058.53045.jnareb%40gmail.com In-Reply-To: ``` On Tue, 29 Sep 2009, Leo Razoumov wrote: > On 2009-09-28, Jakub Narebski wrote: > > [..snip..] > > Besides with nonlinear history with > > revision numbers such as 12678 and 12687 you know that 12678 is older > > than 12687 if and only if 12678 and 12687 are on the same line of > > development. > > The statement above is incorrect!! In a Mercurial repo local revision > numbers are strictly ordered in commit time. 12678 < 12687 means that > 12678 was committed prior to 12687. But these two commits could belong > to two completely unrelated lines of development. This is impossible with distributed development. If the second branch comes from other repository, with commits _created_ (in that repository) earlier than commits in current repository, but commits in first branch (from current repository) were created earlier than _fetching_ those commits in second branch: .---.---.---.---x---1---2---3---M---. \ / \-A---B---C-/ <-- from repository B Either you would have to change commits numbers, and therefore they would be not stable, or you would have to change commit time to mean 'time this commit got into current repository', which would kill performance for sure. -- Jakub Narebski Poland ``` ## Matthieu Moy, 2009-09-29 19:55 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/vpqk4zhplty.fsf%40bauges.imag.fr In-Reply-To: <200909292058.53045.jnareb@gmail.com> ``` Jakub Narebski writes: > On Tue, 29 Sep 2009, Leo Razoumov wrote: >> On 2009-09-28, Jakub Narebski wrote: >> > [..snip..] >> > Besides with nonlinear history with >> > revision numbers such as 12678 and 12687 you know that 12678 is older >> > than 12687 if and only if 12678 and 12687 are on the same line of >> > development. >> >> The statement above is incorrect!! In a Mercurial repo local revision >> numbers are strictly ordered in commit time. 12678 < 12687 means that >> 12678 was committed prior to 12687. But these two commits could belong >> to two completely unrelated lines of development. > > This is impossible with distributed development. Yes, the accurate statement is (I think): "In a Mercurial repo local revision numbers are strictly ordered according _the time when the_ _commit entered the repository_" (i.e. the time you did a merge, not the time the other guy did the commit). Just tested: $ hg log changeset: 3:4d6db21df0cd tag: tip parent: 1:31f8406ae59c parent: 2:33bfb84a5113 user: Matthieu Moy date: Tue Sep 29 21:54:25 2009 +0200 summary: merge changeset: 2:33bfb84a5113 parent: 0:a508b050e5ae user: Matthieu Moy date: Tue Sep 29 21:54:02 2009 +0200 summary: in branch bar changeset: 1:31f8406ae59c user: Matthieu Moy date: Tue Sep 29 21:54:11 2009 +0200 summary: in branch foo changeset: 0:a508b050e5ae user: Matthieu Moy date: Tue Sep 29 21:53:33 2009 +0200 summary: init Either I have a time machine at home, or changesets 1 was not made before changeset 2. -- Matthieu Moy http://www-verimag.imag.fr/~moy/ ``` ## Leo Razoumov, 2009-09-30 00:49 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/ee2a733e0909291749s71801b29ufa827cab715d0abb%40mail.gmail.com In-Reply-To: <200909292058.53045.jnareb@gmail.com> ``` On 2009-09-29, Jakub Narebski wrote: > On Tue, 29 Sep 2009, Leo Razoumov wrote: > > On 2009-09-28, Jakub Narebski wrote: > > > [..snip..] > > > Besides with nonlinear history with > > > revision numbers such as 12678 and 12687 you know that 12678 is older > > > than 12687 if and only if 12678 and 12687 are on the same line of > > > development. > > > > The statement above is incorrect!! In a Mercurial repo local revision > > numbers are strictly ordered in commit time. 12678 < 12687 means that > > 12678 was committed prior to 12687. But these two commits could belong > > to two completely unrelated lines of development. > > > This is impossible with distributed development. If the second branch > comes from other repository, with commits _created_ (in that repository) > earlier than commits in current repository, but commits in first > branch (from current repository) were created earlier than _fetching_ > those commits in second branch: > > .---.---.---.---x---1---2---3---M---. > \ / > \-A---B---C-/ <-- from repository B > > > Either you would have to change commits numbers, and therefore they would > be not stable, or you would have to change commit time to mean 'time this > commit got into current repository', which would kill performance for sure. > Jakub, in Mercurial sequential commit numbers are local to a repo and are not unique between the clones. Unique ID is SHA1 as in git. So mercurial commit 127:aaf123453dfgdfgddd... means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..." In another clone commit 127 might mean completely different thing. Sequential commit numbers are strictly for "local convenience". --Leo-- ``` ## Björn Steinbrink, 2009-09-30 06:28 Subject: Re: Deciding between Git/Mercurial Message-ID: <20090930062816.GA27901@atjola.homenet> URL: https://gitlist.dev/e/20090930062816.GA27901%40atjola.homenet In-Reply-To: ``` On 2009.09.29 20:49:52 -0400, Leo Razoumov wrote: > On 2009-09-29, Jakub Narebski wrote: > > On Tue, 29 Sep 2009, Leo Razoumov wrote: > > > On 2009-09-28, Jakub Narebski wrote: > > > > [..snip..] > > > > Besides with nonlinear history with > > > > revision numbers such as 12678 and 12687 you know that 12678 is older > > > > than 12687 if and only if 12678 and 12687 are on the same line of > > > > development. > > > > > > The statement above is incorrect!! In a Mercurial repo local revision > > > numbers are strictly ordered in commit time. 12678 < 12687 means that > > > 12678 was committed prior to 12687. But these two commits could belong > > > to two completely unrelated lines of development. > > > > This is impossible with distributed development. If the second branch > > comes from other repository, with commits _created_ (in that repository) > > earlier than commits in current repository, but commits in first > > branch (from current repository) were created earlier than _fetching_ > > those commits in second branch: > > > > .---.---.---.---x---1---2---3---M---. > > \ / > > \-A---B---C-/ <-- from repository B > > > > > > Either you would have to change commits numbers, and therefore they would > > be not stable, or you would have to change commit time to mean 'time this > > commit got into current repository', which would kill performance for sure. > > > > Jakub, > in Mercurial sequential commit numbers are local to a repo and are not > unique between the clones. Unique ID is SHA1 as in git. So mercurial > commit 127:aaf123453dfgdfgddd... > means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..." > In another clone commit 127 might mean completely different thing. > Sequential commit numbers are strictly for "local convenience". To quote his first mail: First, you have to remember that this 'number of commit' thingy is *local* to your repository, so you cannot use commit numbers to communicate with other developers. With the above example, he has just shown that even with those local commit numbers, you can't tell that commit X is older than commit Y just because X < Y. Björn ``` ## Andreas Ericsson, 2009-09-30 09:17 Subject: Re: Deciding between Git/Mercurial Message-ID: <4AC3222A.2040305@op5.se> URL: https://gitlist.dev/e/4AC3222A.2040305%40op5.se In-Reply-To: ``` On 09/30/2009 02:49 AM, Leo Razoumov wrote: > On 2009-09-29, Jakub Narebski wrote: >> On Tue, 29 Sep 2009, Leo Razoumov wrote: >> > On 2009-09-28, Jakub Narebski wrote: >> > > [..snip..] >> > > Besides with nonlinear history with >> > > revision numbers such as 12678 and 12687 you know that 12678 is older >> > > than 12687 if and only if 12678 and 12687 are on the same line of >> > > development. >> > >> > The statement above is incorrect!! In a Mercurial repo local revision >> > numbers are strictly ordered in commit time. 12678< 12687 means that >> > 12678 was committed prior to 12687. But these two commits could belong >> > to two completely unrelated lines of development. >> >> >> This is impossible with distributed development. If the second branch >> comes from other repository, with commits _created_ (in that repository) >> earlier than commits in current repository, but commits in first >> branch (from current repository) were created earlier than _fetching_ >> those commits in second branch: >> >> .---.---.---.---x---1---2---3---M---. >> \ / >> \-A---B---C-/<-- from repository B >> >> >> Either you would have to change commits numbers, and therefore they would >> be not stable, or you would have to change commit time to mean 'time this >> commit got into current repository', which would kill performance for sure. >> > > Jakub, > in Mercurial sequential commit numbers are local to a repo and are not > unique between the clones. Unique ID is SHA1 as in git. So mercurial > commit 127:aaf123453dfgdfgddd... > means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..." > In another clone commit 127 might mean completely different thing. > Sequential commit numbers are strictly for "local convenience". > Personally I much prefer the "commit'ish-backward" notation of git, where HEAD~4 means "the commit 4 commits back from HEAD". You'd get awfully tired of writing the six-digit "shorthand" numbers of large projects fairly quickly, I imagine. -- Andreas Ericsson andreas.ericsson@op5.se OP5 AB www.op5.se Tel: +46 8-230225 Fax: +46 8-230231 Considering the successes of the wars on alcohol, poverty, drugs and terror, I think we should give some serious thought to declaring war on peace. ``` ## Matthias Andree, 2009-09-30 11:09 Subject: Re: Deciding between Git/Mercurial Message-ID: <4AC33C56.8060202@gmx.de> URL: https://gitlist.dev/e/4AC33C56.8060202%40gmx.de In-Reply-To: ``` Anteru schrieb: > First of all, what's the matter with git and Windows, is there some > long-term commitment to make git work on Windows as well as on Linux? > I'm using msysgit on Windows, and personally I'm happy with it, but my > co-workers constantly nag that Mercurial has superior portability ... That tale is told all over, but that doesn't make it truer. I've never had issues getting a Cygwin version of git to work properly (haven't tried the msysgit or jgit variants, never felt the need), and integration went smooth. With Mercurial, getting it integrated with a Windows-native Emacs (Cygwin emacs doesn't work for me but hangs on startup) was somewhat of an undertaking even with Cygwin's bash (rather than cmdproxy) underneath Emacs. It boiled down to building Mercurial with py2exe and create an installer and use the compiled hg.exe which I find starts rather slowly. > So far, my key arguments are that git is more robust (more projects > using it, larger developer base), of course git's excellent performance > and the much better support for SVN, which is important for us as we can > slowly migrate from SVN->Git, while hgmercurial is still in the making > (and Python's SVN->Hg switch is for instance waiting for it). Yes, but beware of git-svn under Cygwin 1.5 - that works for svn+ssh:// URLs, but https:// or file:// don't work well because the underdocumented gazillion of dependencies piece of sh.. called apr does stupid things WRT temporary files since the Cygwin Subversion 1.6 days. Cygwin's Subversion 1.5 fared better. I'm not sure about msysgit or jgit projects, but for Cygwin you'll definitely want to take the plunge and go for Cygwin 1.7 which is still in Beta (because that allows you to remove a file and create a file with the same name, which doesn't work with Cygwin 1.5). ``` ## Jakub Narebski, 2009-09-30 11:09 Subject: Re: Deciding between Git/Mercurial Message-ID: <200909301309.51283.jnareb@gmail.com> URL: https://gitlist.dev/e/200909301309.51283.jnareb%40gmail.com In-Reply-To: ``` On Wed, 30 Sep 2009, Leo Razoumov wrote: > On 2009-09-29, Jakub Narebski wrote: >> On Tue, 29 Sep 2009, Leo Razoumov wrote: >>> On 2009-09-28, Jakub Narebski wrote: >>>> [..snip..] >>>> Besides with nonlinear history with >>>> revision numbers such as 12678 and 12687 you know that 12678 is older >>>> than 12687 if and only if 12678 and 12687 are on the same line of >>>> development. >>> >>> The statement above is incorrect!! In a Mercurial repo local revision >>> numbers are strictly ordered in commit time. 12678 < 12687 means that >>> 12678 was committed prior to 12687. But these two commits could belong >>> to two completely unrelated lines of development. >> >> This is impossible with distributed development. If the second branch >> comes from other repository, with commits _created_ (in that repository) >> earlier than commits in current repository, but commits in first >> branch (from current repository) were created earlier than _fetching_ >> those commits in second branch: >> >> .---.---.---.---x---1---2---3---M---. >> \ / >> \-A---B---C-/ <-- from repository B >> >> >> Either you would have to change commits numbers, and therefore they would >> be not stable, or you would have to change commit time to mean 'time this >> commit got into current repository', which would kill performance for sure. > > Jakub, > in Mercurial sequential commit numbers are local to a repo and are not > unique between the clones. Unique ID is SHA1 as in git. So mercurial > commit 127:aaf123453dfgdfgddd... > means commit number 127 in this repo with SHA1 "aaf123453dfgdfgddd..." > In another clone commit 127 might mean completely different thing. > Sequential commit numbers are strictly for "local convenience". Yes, I know that in Mercurial commit numbers are local to repository, and even written about it (that sequential commit numbers are possible only either as local identifiers, or in centralized workflow). The issue I was writing about that sequential commit numbers cannot tell us if commit was earlier or later than some other commit based solely on those commit numbers. As other people in this thread wrote Mercurial numbers commits not in order of commit creation, but in order of commit arriving (being present) in given repository. So commit numbers are not 'strictly ordered in commit time', but ordered in 'time commit got into current (local) repository'. I'd like also to note that this means that at some time Mercurial has to number all those commit it got on fetch / pull from remote repository. This can be a lot of work... work which Git doesn't have to do (OTOH Git creates index for packfile on local side after fetch...). -- Jakub Narebski Poland ``` ## Matthias Andree, 2009-09-30 11:14 Subject: Re: Deciding between Git/Mercurial Message-ID: <4AC33D84.406@gmx.de> URL: https://gitlist.dev/e/4AC33D84.406%40gmx.de In-Reply-To: ``` Johannes Schindelin schrieb: > Hi, > > I tried to refrain from commenting in this thread, because I do not want > to encourage people just to use msysGit and never even attempt to fix > their own issues. > > But I cannot let this go uncommented: > > On Mon, 28 Sep 2009, Felipe Contreras wrote: > >> IMO the key difference between hg and git is the storage model: hg >> stores deltas, while git stores snapshots. That would mean that certain >> operations are theoretically faster in git (e.g. checkout, diff) while >> others faster in hg, although with git's packed format I guess there's >> no operation faster in hg. This means that it doesn't matter how much >> hg's python code improves, or if they even re-write parts in C, they >> will never be able to match git's performance (unless they change the >> storage model, which essentially means changing the whole design -- >> won't happen). > > That is wrong. "git log -- " will always be slightly faster in > Mercurial, for all the reasons you mentioned. > > In addition, Mercurial _has_ parts re-written in C for performance, which > renders it not-exactly more portable if you ask me. Last time I checked, > there was no way to compile a Python module with MinGW (or for that > matter, Python itself), but you needed MSVC... I have a shortish mercurial build script that works under Cygwin 1.5 and uses msys, py2exe and iscc to build an installable Mercurial package, but I'm not sure what this boils down to WRT C-versions of "modules". Maybe these are lumped into the resulting hg.exe, I never bothered to check the details. ``` ## Daniel Barkalow, 2009-09-30 22:05 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/alpine.LNX.2.00.0909301752450.14907%40iabervon.org In-Reply-To: <4AC33C56.8060202@gmx.de> ``` On Wed, 30 Sep 2009, Matthias Andree wrote: > Anteru schrieb: > > > First of all, what's the matter with git and Windows, is there some > > long-term commitment to make git work on Windows as well as on Linux? > > I'm using msysgit on Windows, and personally I'm happy with it, but my > > co-workers constantly nag that Mercurial has superior portability ... > > That tale is told all over, but that doesn't make it truer. I've never had > issues getting a Cygwin version of git to work properly (haven't tried the > msysgit or jgit variants, never felt the need), and integration went smooth. Git works fine under Windows for people who use Cygwin. Portability to Windows is more about working for users who don't use a shell of any sort or the "Run..." dialog. I don't know how Mercurial does on that metric, anyway, but it's a lot more meaningful that the question of whether the software works in your POSIX environment when the underlying kernel is not very suitable. -Daniel *This .sig left intentionally blank* ``` ## Dilip M, 2009-10-22 02:38 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/c94f8e120910211938v3cc7991en3c385fc2f98b28a3%40mail.gmail.com In-Reply-To: ``` Hi Anteru, On Sun, Sep 27, 2009 at 5:54 PM, Anteru wrote: ..snip.. > So far, my key arguments are that git is more robust (more projects using > it, larger developer base), of course git's excellent performance and the > much better support for SVN, which is important for us as we can slowly > migrate from SVN->Git, while hgmercurial is still in the making (and > Python's SVN->Hg switch is for instance waiting for it). So finally which you choosed? Just curious? -- Dilip ``` ## Anteru, 2009-10-22 06:50 Subject: Re: Deciding between Git/Mercurial Message-ID: <4AE000B7.4090708@shelter13.net> URL: https://gitlist.dev/e/4AE000B7.4090708%40shelter13.net In-Reply-To: ``` Dilip M schrieb: > Hi Anteru, > > On Sun, Sep 27, 2009 at 5:54 PM, Anteru wrote: > > ..snip.. > >> So far, my key arguments are that git is more robust (more projects using >> it, larger developer base), of course git's excellent performance and the >> much better support for SVN, which is important for us as we can slowly >> migrate from SVN->Git, while hgmercurial is still in the making (and >> Python's SVN->Hg switch is for instance waiting for it). > > So finally which you choosed? Just curious? Bzr, it has even better SVN interop, works the same across all platforms, performance-wise, Bzr 2.x turned out to be more than sufficient and the UI tools are quite polished. Thanks for all the comments on Git and Hg! Cheers, Anteru ``` ## Dilip M, 2009-10-22 07:12 Subject: Re: Deciding between Git/Mercurial Message-ID: URL: https://gitlist.dev/e/c94f8e120910220012r6d53f759u374a69d41dc4a4db%40mail.gmail.com In-Reply-To: <4AE000B7.4090708@shelter13.net> ``` On Thu, Oct 22, 2009 at 12:20 PM, Anteru wrote: > Bzr, it has even better SVN interop, works the same across all > platforms, performance-wise, Bzr 2.x turned out to be more than > sufficient and the UI tools are quite polished. > > Thanks for all the comments on Git and Hg! Surprised to know. I was expecting hg or GIT :) Do you mind to share the checks done / piloting done while choosing Bzr over GIT or HG I bet, it is useful for many ppl in this list too. -- Dilip ``` ## Anteru, 2009-10-22 07:35 Subject: Re: Deciding between Git/Mercurial Message-ID: <4AE00B45.5040900@shelter13.net> URL: https://gitlist.dev/e/4AE00B45.5040900%40shelter13.net In-Reply-To: ``` Dilip M schrieb: > Surprised to know. I was expecting hg or GIT :) Yeah, me too, actually, Bzr was no contender at first. > Do you mind to share the checks done / piloting done while choosing > Bzr over GIT or HG > > I bet, it is useful for many ppl in this list too. I'm going to blog about this, in the hope that it will help more people who want to switch away from SVN. I'm not so sure whether sending it here will help, because in order to be fair, I would have to send the same to the Bzr and Hg mailing lists, and this is a sure recipe for a flame-war :) Cheers, Anteru ``` ## Martin Langhoff, 2009-10-22 08:01 Subject: Re: Deciding between Git/Mercurial Message-ID: <46a038f90910220101h4f3ecf22x6923ac41e8b6d4f9@mail.gmail.com> URL: https://gitlist.dev/e/46a038f90910220101h4f3ecf22x6923ac41e8b6d4f9%40mail.gmail.com In-Reply-To: <200909272001.48180.robin.rosenberg.lists@dewire.com> ``` On Sun, Sep 27, 2009 at 8:01 PM, Robin Rosenberg wrote: > söndag 27 september 2009 14:24:32 skrev Anteru : >> Mercurial's revision number system: With git, I get an SHA1 hash for >> every commit, but it's not possible to see whether Hash1 is newer than >> Hash2, while Mecurial also adds a running number to each commit. What's > > But those numbers cannot be communicated since they are local to your > clone. You can use git-describe, which will look for the latest tag, and make a combo of latest tag, commits since the tag, short form of sha1. So you get "v1.6.3-33-g1234" - 33 commits after 1.6.3. Works very well to integrate in versioning. The git project itself uses it in the Makefile to set the versions, same as the kernel folk do -- I use it to version even RPM/DEBs. hth, m -- martin.langhoff@gmail.com martin@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ```