Prefer mercurial to git(lists.gnu.org)
lists.gnu.org
Prefer mercurial to git
https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00343.html
186 comments
I can relate to these comments because when I was a Git user forced to use Mercurial for Firefox development, I initially thought much of the same. I have since come around [1].
Mercurial has come a long way in the last few years. While I used to see repo corruption semi-frequently, I have not seen it once in the last year or so. This can be attributed to bug fixes and less reliance on mq. mq is a giant hack on top of Mercurial's storage model and there were many corner cases in older Mercurials where mq could lead to repo corruption. I use the experimental evolve extension now, but I can't yet recommend that to the masses because it's very rough around the edges. Hopefully in the next 6-12 months.
I strongly disagree with the statement that Mercurial is less flexible than Git. I find Mercurial to be more flexible. If you don't take my word for it, ask Facebook [2]: "Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project." The article goes on to describe some key areas where Mercurial is more flexible.
Some things possible in Mercurial that aren't with Git:
* Extending the wire protocol. Git's wire protocol is the exchange of objects (key-value pairs) and refs to said objects. Mercurial's is command-based and you can have client and server talk their own commands.
* Revision sets [3]. Extremely useful feature. See [4] for how I've used this as Mozilla.
* Phases. Mercurial knows when you are changing a published and should-be-immutable changeset/commit and by default prevents you from footgunning yourself.
* Changeset evolution. The mindset about "pushing rebases is evil" has its roots almost completely in limitations of tools. Changeset evolution removes that limitation.
As I wrote at [1], I believe the future of Mercurial is bright. Don't discount Mercurial because of past experiences with ancient versions or because you assume the Git way is the only and right way.
[1] http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercuria... [2] https://code.facebook.com/posts/218678814984400/scaling-merc... [3] http://www.selenic.com/hg/help/revsets [4] http://gregoryszorc.com/blog/2013/11/08/using-mercurial-to-q...
Mercurial has come a long way in the last few years. While I used to see repo corruption semi-frequently, I have not seen it once in the last year or so. This can be attributed to bug fixes and less reliance on mq. mq is a giant hack on top of Mercurial's storage model and there were many corner cases in older Mercurials where mq could lead to repo corruption. I use the experimental evolve extension now, but I can't yet recommend that to the masses because it's very rough around the edges. Hopefully in the next 6-12 months.
I strongly disagree with the statement that Mercurial is less flexible than Git. I find Mercurial to be more flexible. If you don't take my word for it, ask Facebook [2]: "Our engineers were comfortable with Git and we preferred to stay with a familiar tool, so we took a long, hard look at improving it to work at scale. After much deliberation, we concluded that Git's internals would be difficult to work with for an ambitious scaling project." The article goes on to describe some key areas where Mercurial is more flexible.
Some things possible in Mercurial that aren't with Git:
* Extending the wire protocol. Git's wire protocol is the exchange of objects (key-value pairs) and refs to said objects. Mercurial's is command-based and you can have client and server talk their own commands.
* Revision sets [3]. Extremely useful feature. See [4] for how I've used this as Mozilla.
* Phases. Mercurial knows when you are changing a published and should-be-immutable changeset/commit and by default prevents you from footgunning yourself.
* Changeset evolution. The mindset about "pushing rebases is evil" has its roots almost completely in limitations of tools. Changeset evolution removes that limitation.
As I wrote at [1], I believe the future of Mercurial is bright. Don't discount Mercurial because of past experiences with ancient versions or because you assume the Git way is the only and right way.
[1] http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercuria... [2] https://code.facebook.com/posts/218678814984400/scaling-merc... [3] http://www.selenic.com/hg/help/revsets [4] http://gregoryszorc.com/blog/2013/11/08/using-mercurial-to-q...
Maybe it's just me, but recommending a DVCS because it hasn't corrupted your data lately is like recommending a car because it hasn't had the wheels randomly fall off lately.
The parent's recommendation was not based upon data not being corrupted lately. He stated that this issue is not as prevalent as it used to be, countering the commentor's slightly outdated experience, and then went on to list off features as the basis of his recommendation.
[deleted]
> but I found it to be incredibly frustrating already knowing git.
From my understanding, the terminology and behavior of Mercurial is more in-line with other SCMs out there (like SVN), while Git seems to do things a bit differently. A lot of it is terminology differences or default behavior for various commands.
> I found it to be slower, less flexible,
Mercurial should be about the same speed as Git now adays. I'd be interested to hear what parts of HG you thought were slow. Also, for flexibility, Mercurial disables a lot of more advanced features by defaults (anything that could get a developer in trouble or mess with history). All of the extensions that ship with Mercurial are officially supported and can be used if you want that functionality.
> prone to permanent repository corruption
I'd be interested to hear if you ever found out what caused your problems. Mercurial has a page talking about this [0].
> IMO if you are already proficient with git there is absolutely nothing about mercurial that is preferable and some considerable downsides I have been subjected to.
For almost all features, I'd totally agree. There are 3 things in Mercurial that I see as an advantage over Git. (1) named branches (every commit on the branch will be tagged with the branch name). (2) LargeFile[1] extension for handling very large files you don't want people having to pull, though this breaks DVCS concepts. (3) A future feature that looks really promising, ChangesetEvolution[2], that will basically allow history rewriting that can be pushed to others.
[0] http://mercurial.selenic.com/wiki/RepositoryCorruption
[1] http://mercurial.selenic.com/wiki/LargefilesExtension
[2] http://mercurial.selenic.com/wiki/ChangesetEvolution
From my understanding, the terminology and behavior of Mercurial is more in-line with other SCMs out there (like SVN), while Git seems to do things a bit differently. A lot of it is terminology differences or default behavior for various commands.
> I found it to be slower, less flexible,
Mercurial should be about the same speed as Git now adays. I'd be interested to hear what parts of HG you thought were slow. Also, for flexibility, Mercurial disables a lot of more advanced features by defaults (anything that could get a developer in trouble or mess with history). All of the extensions that ship with Mercurial are officially supported and can be used if you want that functionality.
> prone to permanent repository corruption
I'd be interested to hear if you ever found out what caused your problems. Mercurial has a page talking about this [0].
> IMO if you are already proficient with git there is absolutely nothing about mercurial that is preferable and some considerable downsides I have been subjected to.
For almost all features, I'd totally agree. There are 3 things in Mercurial that I see as an advantage over Git. (1) named branches (every commit on the branch will be tagged with the branch name). (2) LargeFile[1] extension for handling very large files you don't want people having to pull, though this breaks DVCS concepts. (3) A future feature that looks really promising, ChangesetEvolution[2], that will basically allow history rewriting that can be pushed to others.
[0] http://mercurial.selenic.com/wiki/RepositoryCorruption
[1] http://mercurial.selenic.com/wiki/LargefilesExtension
[2] http://mercurial.selenic.com/wiki/ChangesetEvolution
Funny, at my company it is the oppositive.
If you give the developers the choice, they would drop git and go back to mercurial.
If you give the developers the choice, they would drop git and go back to mercurial.
Then why not switch to mercurial?
I don't know the specifics of his case, but there could be several reasons.
A likely one is that the benefits of a switch wouldn't outweigh the costs, at least not within a reasonable timeframe.
Another is that there may not be resources to dedicate to such an effort, even if the return would be suitable.
And yet another could be management buying into all of the git hype we've been subjected to a lot lately. Git (and GitHub) today are like Ruby on Rails was a few years back. Even though there are several alternatives, some of them much better in some ways, they just don't get the media attention, and thus don't get hyped, and thus don't get onto the radar of managers who decide which VCS to use, and thus don't see as much use, and thus aren't even seen as viable options by said managers.
A likely one is that the benefits of a switch wouldn't outweigh the costs, at least not within a reasonable timeframe.
Another is that there may not be resources to dedicate to such an effort, even if the return would be suitable.
And yet another could be management buying into all of the git hype we've been subjected to a lot lately. Git (and GitHub) today are like Ruby on Rails was a few years back. Even though there are several alternatives, some of them much better in some ways, they just don't get the media attention, and thus don't get hyped, and thus don't get onto the radar of managers who decide which VCS to use, and thus don't see as much use, and thus aren't even seen as viable options by said managers.
You got it almost right.
We do enterprise consulting and are bound to the technology that is already in place. In 90% of our projects we seldom introduce anything new.
Many of our customers have been sold into git hype and have been moving or have recently moved to git.
We do enterprise consulting and are bound to the technology that is already in place. In 90% of our projects we seldom introduce anything new.
Many of our customers have been sold into git hype and have been moving or have recently moved to git.
Because as enterprise consultants we use what the customers require, it is not up to us to choose our tooling.
Many of those customers have been sold to git hype before getting us on board.
Many of those customers have been sold to git hype before getting us on board.
I'm interested in your comment about the cryptographic nature of git objects. I know that hashes are used to identify commits, but I'm not sure how Git uses cryptography elsewhere — e.g. to check the integrity of repos, as you said. Can you explain this aspect in more detail? (Not being argumentative; just curious.)
In git a commit is basically the root of a Merkle Tree[1], i.e. every reference is the sha1 sum of the object being referenced. If you take a commit apart what you see is a commit message, a hash of its parent commit and a hash of a tree object. That tree object itself contains hashes of file objects and tree object as well as their corresponding names. Thus assuming you would want to tamper with a file of a commit this files hash would change and therefore the parent tree objects hash would change and therefore the commit hash would change. So the complete state of the repository is cryptographically secured with just the hash of the commit object. You can find out more about git innards here: http://git-scm.com/book/en/Git-Internals-Git-Objects
To be fair: I believe mercurial commits enjoy the same level of protection, although via different means.
[1] https://en.wikipedia.org/wiki/Merkle_tree
To be fair: I believe mercurial commits enjoy the same level of protection, although via different means.
[1] https://en.wikipedia.org/wiki/Merkle_tree
> So the complete state of the repository is cryptographically secured
It should be noted, however, that Linus and others specifically disclaim that this is a security mechanism:
"Git uses SHA-1 in a way which has nothing at all to do with security.... It's just the best hash you can get.... It's about the ability to trust your data." --Linus (http://en.wikipedia.org/wiki/SHA-1#Data_integrity)
And in the midst of a discussion about how only professional cryptographers should design crypto, pretty much everyone insists that Git is not crypto (see replies to: https://news.ycombinator.com/item?id=6961683)
It should be noted, however, that Linus and others specifically disclaim that this is a security mechanism:
"Git uses SHA-1 in a way which has nothing at all to do with security.... It's just the best hash you can get.... It's about the ability to trust your data." --Linus (http://en.wikipedia.org/wiki/SHA-1#Data_integrity)
And in the midst of a discussion about how only professional cryptographers should design crypto, pretty much everyone insists that Git is not crypto (see replies to: https://news.ycombinator.com/item?id=6961683)
To be honest I don't buy his argument. If it is not about security, why not use md5? It is faster after all and gives you the same protection against accidental data corruption as sha1. And if he cared about security then he should have chosen sha256 or sha512, the latter of which is even faster than sha1 on 64bit systems [1] and can be truncated if you think it is too long.
And really there is no denying that git relies on the security of sha1, especially its second preimage resistance[2]. Otherwise all the signed Linux releases would be useless, because you could exchange the files in the release with your own, malicious ones. Even collision resistance is important, as if you are a rogue kernel developer you can craft two files with identical hashes: One that passes scrutiny upstream and one that has a subtle backdoor. If it is in one those binary blobs there is a very low chance of it ever being found.
My guess is that he did not really put more than 5 minutes of thought into the decision. He has a track record of mediocre understanding of and low regard for cryptographic topics, see for example: http://thread.gmane.org/gmane.linux.kernel/1173350/focus=117... .
[1] http://bench.cr.yp.to/results-hash.html
[2] You cannot find another file with the same hash as the given file.
And really there is no denying that git relies on the security of sha1, especially its second preimage resistance[2]. Otherwise all the signed Linux releases would be useless, because you could exchange the files in the release with your own, malicious ones. Even collision resistance is important, as if you are a rogue kernel developer you can craft two files with identical hashes: One that passes scrutiny upstream and one that has a subtle backdoor. If it is in one those binary blobs there is a very low chance of it ever being found.
My guess is that he did not really put more than 5 minutes of thought into the decision. He has a track record of mediocre understanding of and low regard for cryptographic topics, see for example: http://thread.gmane.org/gmane.linux.kernel/1173350/focus=117... .
[1] http://bench.cr.yp.to/results-hash.html
[2] You cannot find another file with the same hash as the given file.
Intel is adding native SHA instructions to x86... so sha1 will probably be much faster on those CPUs.
http://en.wikipedia.org/wiki/Intel_SHA_extensions
http://en.wikipedia.org/wiki/Intel_SHA_extensions
Interesting…
Note that they also add sha256 specific instructions. Which is good, because sha1 should no longer be used for new application and existing application should definitely start looking into an update path. See [1] for a rough estimate how fast the existing (publicly known) attacks become feasible.
I hope they are also working on implementing the sha3 permutation. That would allow for some really cool features to be super fast and simple like authenticated encryption or reseedable pseudo random number generation[2].
[1] https://www.schneier.com/blog/archives/2012/10/when_will_we_... [2] For details see section 5 and 6 of https://eprint.iacr.org/2011/499.pdf
Note that they also add sha256 specific instructions. Which is good, because sha1 should no longer be used for new application and existing application should definitely start looking into an update path. See [1] for a rough estimate how fast the existing (publicly known) attacks become feasible.
I hope they are also working on implementing the sha3 permutation. That would allow for some really cool features to be super fast and simple like authenticated encryption or reseedable pseudo random number generation[2].
[1] https://www.schneier.com/blog/archives/2012/10/when_will_we_... [2] For details see section 5 and 6 of https://eprint.iacr.org/2011/499.pdf
I am not sure I buy it either. To me it comes off as cognitive dissonance between the party line of "don't invent your own crypto" and the pervasive love and acceptance of Git.
No one wants to say that Git, on which many of our SCM processes are now built, is suspect. But also no one wants to argue that Linus is somehow an exception to the rule against amateur cryptography.
So what we're left with a somewhat ambiguous situation where Git is described as not being crypto despite the fact that in practice people assume it is resistant to malicious attack.
No one wants to say that Git, on which many of our SCM processes are now built, is suspect. But also no one wants to argue that Linus is somehow an exception to the rule against amateur cryptography.
So what we're left with a somewhat ambiguous situation where Git is described as not being crypto despite the fact that in practice people assume it is resistant to malicious attack.
> Git is described as not being crypto
Git has plenty of crypto in it, namely GPG (for signing tags), SSH and SSL (for transport). Using off-the-shelf crypto like this doesn't strike me as "inventing your own crypto".
> people assume it is resistant to malicious attack
Exactly what's the threat model here? I can't conceive of a malicious attack that exploits gits reliance of on SHA1 as a message digest that doesn't also require write access to your filesystem.
I think your argument stems from the fact that SHA1 is deemed insecure and therefore anything associated with it must also be insecure. As I said in the previous thread, git doesn't use SHA1 to make any of the guarantees that cryptography is typically used to make.
It's usage is to prevent accidental corruption in the everyday usage of git (the sort that mercurial appears to have been prone to in the past), not to protect against a malicious adversary with write access to the filesystem.
Git has plenty of crypto in it, namely GPG (for signing tags), SSH and SSL (for transport). Using off-the-shelf crypto like this doesn't strike me as "inventing your own crypto".
> people assume it is resistant to malicious attack
Exactly what's the threat model here? I can't conceive of a malicious attack that exploits gits reliance of on SHA1 as a message digest that doesn't also require write access to your filesystem.
I think your argument stems from the fact that SHA1 is deemed insecure and therefore anything associated with it must also be insecure. As I said in the previous thread, git doesn't use SHA1 to make any of the guarantees that cryptography is typically used to make.
It's usage is to prevent accidental corruption in the everyday usage of git (the sort that mercurial appears to have been prone to in the past), not to protect against a malicious adversary with write access to the filesystem.
> Exactly what's the threat model here? I can't conceive of a malicious attack that exploits gits reliance of on SHA1 as a message digest that doesn't also require write access to your filesystem.
Write access to your filesystem is a threat git is supposed to be secure against (more precisely: the filesystem of your git server) as Haberman has pointed out. Another incident this was relevant is the kernel.org hack: http://www.linuxfoundation.org/news-media/blogs/browse/2011/...
Furthermore, the signed tags are completely worthless if you assume second preimage resistance of sha1 to be broken. Imagine I sit between kernel.org and your computer. When you download the next Linus blessed Linux release I manipulate some of the files to contain some backdoor while still having the same sha1. As you will certainly not check every file manually for bogus content you happily compile and run the manipulated kernel and I have access to your PC via my planted backdoor.
Write access to your filesystem is a threat git is supposed to be secure against (more precisely: the filesystem of your git server) as Haberman has pointed out. Another incident this was relevant is the kernel.org hack: http://www.linuxfoundation.org/news-media/blogs/browse/2011/...
Furthermore, the signed tags are completely worthless if you assume second preimage resistance of sha1 to be broken. Imagine I sit between kernel.org and your computer. When you download the next Linus blessed Linux release I manipulate some of the files to contain some backdoor while still having the same sha1. As you will certainly not check every file manually for bogus content you happily compile and run the manipulated kernel and I have access to your PC via my planted backdoor.
> It's usage is to prevent accidental corruption in the everyday usage of git (the sort that mercurial appears to have been prone to in the past), not to protect against a malicious adversary with write access to the filesystem.
I have evidence that people in practice use it to protect against just this sort of thing: https://news.ycombinator.com/item?id=7003900
I have evidence that people in practice use it to protect against just this sort of thing: https://news.ycombinator.com/item?id=7003900
> To be fair: I believe mercurial commits enjoy the same level of protection, although via different means.
Actually they have almost exactly the same Merkel tree (there are some minor differences in the metadata that is included, mercurial also includes the file level parents while git does not, for example).
The inspiration came from Monotone.
Actually they have almost exactly the same Merkel tree (there are some minor differences in the metadata that is included, mercurial also includes the file level parents while git does not, for example).
The inspiration came from Monotone.
It's worth noting that Git's hashes guard against accidental corruption; they aren't widely thought to be strong against attack by an intelligent adversary.
That's true, and AFAIK Linus says much the same. SHA1 is used for practical purposes and not security in the face of a determined attacker with cryptanalytic ability.
Every object in the repository, including commits and trees, is hashed via SHA-1. Commits also include the SHA of the previous commit, so if you verify each commit, then compare the SHA at the top to the "correct" one, then that means your entire repository is valid.
> Every object in the repository, including commits and trees, is hashed via SHA-1. Commits also include the SHA of the previous commit
mercurial does pretty much the same, as far as I know.
> so if you verify each commit
But surely that does not happen on every CLI operation does it? So you only find out about corruption when all the repository is traversed and checked, which will usually be explicitly or on clone. Thus the same as hg.
mercurial does pretty much the same, as far as I know.
> so if you verify each commit
But surely that does not happen on every CLI operation does it? So you only find out about corruption when all the repository is traversed and checked, which will usually be explicitly or on clone. Thus the same as hg.
actually, it's possible to execute clone in git without it checking. If you do a local clone, it will happily hand you a broken repo.
Committers are able to sign their commit with their GPG key.
Edit: I was wrong and changed all the words
Edit: I was wrong and changed all the words
Everything about this comment is wrong. Commits are never signed [EDIT: it is possible since 2011, but rarely used; thanks zobzu]. Annotated tags can be signed via PGP (not SSH keys), but the public key is not stored in the repository (unless you put it there manually, as with the tag "junio-gpg-pub" in git.git, which is not even Junio's current signing key). In practice, people obtain keys from PGP keyservers.
I can't reply to a child of this comment, but yes, this comment is entirely wrong.
However, Git can indeed sign commits (using gpg), not just tags.
"git commit -S"
Most people prefer what they already know (learning any new system or process is always frustrating because you are attempting to map concept rather than learn concepts - square peg, round hole).
I prefer (and use) git myself, but it took awhile (and much of my developer/friend network to go first) for me to commit to the switch from subversion...my main issue was that subversion worked well enough for what I needed/wanted at the time. I didn't really switch until it became harder to work with others because of my subversion use and easier to work with others if/when I adopted git.
I prefer (and use) git myself, but it took awhile (and much of my developer/friend network to go first) for me to commit to the switch from subversion...my main issue was that subversion worked well enough for what I needed/wanted at the time. I didn't really switch until it became harder to work with others because of my subversion use and easier to work with others if/when I adopted git.
git is as prone to bitrot as hg.
git doesn't run fsck on the entire repo for each operation, and unless you fsck or clone you won't detect corruption for quite a while.
it's exactly the same for hg, which is built on the same hashing concept as git (actually the other way round, as hg came first).
git doesn't run fsck on the entire repo for each operation, and unless you fsck or clone you won't detect corruption for quite a while.
it's exactly the same for hg, which is built on the same hashing concept as git (actually the other way round, as hg came first).
Moreover, Mercurial's storage scheme is built on append-only files, whereas Git periodically repacks its objects, which means that Mercurial actually has fewer opportunities for cosmic rays to hit the bits while they are in motion, and so less chance of corruption.
Most bit rot isn't due to cosmic rays, but rather to decay on the disk itself.
Apparently, decay on the disk itself is sometimes caused by cosmic rays:
http://docs.oracle.com/cd/E19253-01/819-5461/gbbym/index.htm...
http://docs.oracle.com/cd/E19253-01/819-5461/gbbym/index.htm...
Mercurial was announced on 2005-04-19 and git on 2005-04-07, so no Mercurial was not first.
Edit: Monotone is older than git though.
Edit: Monotone is older than git though.
I think we can state they weren't copying each other.
I think both started on the same day (due to both authors being part of the kernel "kabal" and already in the known about the upcoming bk debacle).
Mercurial was usable earlier though ;-)
(the first git versions were really really low level, and did not include features like packs, while hg had high kevel command line and its compressed storage format from the first release)
Mercurial was usable earlier though ;-)
(the first git versions were really really low level, and did not include features like packs, while hg had high kevel command line and its compressed storage format from the first release)
Indeed, they both were developed separately as a reaction to the BitKeeper drama.
I've been using mercurial and git for about 8 years and I've never had corruption problems from either. What are you doing to get corruption errors. Also, mercurial hashes just like git and has for a long time. Are you sure that's not enough to detect corruption issues?
I personally find git staging to be a major inconvenience and would rather not have it around.
my first run with git also got me a corrupted repo. never got support for it.
but this os pointless, the keyword in your post is "forced".
but this os pointless, the keyword in your post is "forced".
You should have linked the first post in that thread. It explains what the whole thing is actually about:
https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00...
Tl;dr: Mercurial is a free software project sharing GNU's goals, while Git is made by anti-GNU people who do not believe in free software and has an incompatible license.
https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00...
Tl;dr: Mercurial is a free software project sharing GNU's goals, while Git is made by anti-GNU people who do not believe in free software and has an incompatible license.
>while Git is made by anti-GNU people who do not believe in free software and has an incompatible license.
WTF? Git is GPLv2 - the exact same as the Linux kernel. A great many developers are avoiding v3 due to the changes it made. And "anti-GNU people" is just a lame insult.
WTF? Git is GPLv2 - the exact same as the Linux kernel. A great many developers are avoiding v3 due to the changes it made. And "anti-GNU people" is just a lame insult.
The people who avoid the GPL3 do it because they do not share the goals of the GNU project. The GPL3 expresses the same philosophy as the GPL2. GNU released a new version only because companies discovered a loophole (a bug if you will) in the GPL which allowed them to build non-free (as in GNU) systems based on GPL software. GNU was founded to fight such systems.
However, Linus Torvalds (Linux and git) has no problems with non-free at all and in fact wanted to support the production of such systems. Like many users of the GPL2 he never actually shared the goals of GNU.
Git's license was deliberately chosen to support the building of non-free systems. According to GNU ideology that is evil. If you are a GNU contributor you are not supposed to even link to non-free solutions. So yeah, of course the hardcore GNU ideologues do not like git or the people behind it.
However, Linus Torvalds (Linux and git) has no problems with non-free at all and in fact wanted to support the production of such systems. Like many users of the GPL2 he never actually shared the goals of GNU.
Git's license was deliberately chosen to support the building of non-free systems. According to GNU ideology that is evil. If you are a GNU contributor you are not supposed to even link to non-free solutions. So yeah, of course the hardcore GNU ideologues do not like git or the people behind it.
Not agreeing with the FSF's rather dogmatic stances does not make you "anti-free-software". Having no problem with closed source does not make you "anti-free-software".
(Except in the eyes of zealots, but who cares about them?)
(Except in the eyes of zealots, but who cares about them?)
Agreeing with Karunamon completely, it's the with-us-or-against-us attitude that makes people not want to work with GNU people... they can feel like the PETA of software.
What was stated was "anti-GNU". Decoupling GNU from the FSF is weird.
That still doesn't wash. It is quite possible to believe that the GNU project and what's associated with it (FSF) is a net positive while disagreeing with some of the actions of its founders or boosters, or some of their ideology.
The GNU/FSF mindset is one of "You're either with us or against us" - but over here in the real world, things are not so black and white.
The GNU/FSF mindset is one of "You're either with us or against us" - but over here in the real world, things are not so black and white.
> The GNU/FSF mindset is one of "You're either with us or against us" - but over here in the real world, things are not so black and white.
That isn't in the least true. You should be very careful when trying to decode someones mindset because now you are putting words in someones mouth that never was there in the first place.
That isn't in the least true. You should be very careful when trying to decode someones mindset because now you are putting words in someones mouth that never was there in the first place.
I don't thinks words are being put into anyone's mouth, what was said was quite clear:
> while Git is made by anti-GNU people who do not believe in free software
As stated in above comments I would find it hard to believe Linus would not say that GNU is a valuable asset or software built strictly promoting GNU/FSF principles is bad ... but he's been labeled as anti-GNU for writing software that has a more permissible license. I don't see how this could be an even more "with us or against us" attitude.
You could argue the above statement is an overgeneralization of what the OP said to the whole movement. But there are plenty of thing that prominent individuals, who work on GNU and represent the FSF, have said that would support this attitude.
> while Git is made by anti-GNU people who do not believe in free software
As stated in above comments I would find it hard to believe Linus would not say that GNU is a valuable asset or software built strictly promoting GNU/FSF principles is bad ... but he's been labeled as anti-GNU for writing software that has a more permissible license. I don't see how this could be an even more "with us or against us" attitude.
You could argue the above statement is an overgeneralization of what the OP said to the whole movement. But there are plenty of thing that prominent individuals, who work on GNU and represent the FSF, have said that would support this attitude.
> but he's been labeled as anti-GNU for writing software that has a more permissible license
No. he has been labeled as anti-gnu because of torvalds own statement like:
No. he has been labeled as anti-gnu because of torvalds own statement like:
"So I'm pretty well-known for not exactly being a huge fan
of the FSF and Richard Stallman"
"Linux from the very beginning was not about the FSF ideals."
I don't like the FSF or Stallman's ideals myself (I find them dogmatic, unrealistic, and probably a bunch of other negative adjectives) but I cannot deny they are a net positive influence on the world. I'm also annoyed because that very dogmatism weakens their very positive message.
I have a hard time seeing how the world would work if people did not strive to achieve their goals.
Take a for-profit company. Their goal is to make money. If I ask them to compromise on this and stop earning money, they get very dogmatic about it and completely refuse.
If I ask a politician to start promoting a competitor, he will also dogmatic refuse. I can not even get him to compromise. I offer him nice bribe money, and he should accept it and step down.
What I am trying to say is that dogma and compromises are not the black and white, good and evil. Dogma is required to make the world work, and compromises are only good when it doesn't interfere too much with it.
Take a for-profit company. Their goal is to make money. If I ask them to compromise on this and stop earning money, they get very dogmatic about it and completely refuse.
If I ask a politician to start promoting a competitor, he will also dogmatic refuse. I can not even get him to compromise. I offer him nice bribe money, and he should accept it and step down.
What I am trying to say is that dogma and compromises are not the black and white, good and evil. Dogma is required to make the world work, and compromises are only good when it doesn't interfere too much with it.
Well I Googl'ed:
That includes this interesting post on Slashdot from 2001:
http://interviews.slashdot.org/story/01/12/13/0242205/miguel...
In particular, a comment by ukryule seems especially applicable:
"Taken in the spirit intended. I accept that the GNU principles are quite clearly defined - but is it really the case that "you're either with us or against us"? The original post was asking about Ximian "abandoning it's GNU values" - to which I think pointing out the open-source work it is doing is a perfectly valid response (it shows that the company at least has common ground with GNU). To be fair, I don't know if Ximian (the company) ever supported GNU values ... but if they continue to spend say 80% of their time on GPL'd sw and the other 20% on prorietory sw does this imply they do or don't support GNU values? "
gnu fsf "you're either with us or against us"
That includes this interesting post on Slashdot from 2001:
http://interviews.slashdot.org/story/01/12/13/0242205/miguel...
In particular, a comment by ukryule seems especially applicable:
"Taken in the spirit intended. I accept that the GNU principles are quite clearly defined - but is it really the case that "you're either with us or against us"? The original post was asking about Ximian "abandoning it's GNU values" - to which I think pointing out the open-source work it is doing is a perfectly valid response (it shows that the company at least has common ground with GNU). To be fair, I don't know if Ximian (the company) ever supported GNU values ... but if they continue to spend say 80% of their time on GPL'd sw and the other 20% on prorietory sw does this imply they do or don't support GNU values? "
This must be the most intellectually dishonest comment I've read in a while. Either find someone from FSF who's written what you're claiming or this discussion is over. Finding unrelated people who feels something about the FSF's position and quoting that.. is just silly.
You must be confused. I'm not claiming anything at all. I'm saying Google something and I'm saying someone wrote something 13 years ago. Any conclusions you draw are your own.
I don't think anyone was arguing that the FSF being all-or-nothing, us-and-them, with-us-or-against-us was not a prevalent meme amongst their detractors. It long has been. The question was whether it is an accurate description of their positions.
"That still doesn't wash. It is quite possible to believe that the GNU project and what's associated with it (FSF) is a net positive while disagreeing with some of the actions of its founders or boosters, or some of their ideology."
A fair point. Picking licenses that explicitly forbid incorporation of your code in modern GNU projects is a little more than that, though.
'The GNU/FSF mindset is one of "You're either with us or against us"'
I don't think that's quite as true as you think it is.
A fair point. Picking licenses that explicitly forbid incorporation of your code in modern GNU projects is a little more than that, though.
'The GNU/FSF mindset is one of "You're either with us or against us"'
I don't think that's quite as true as you think it is.
I'd love to be proven wrong on this. Considering that their figurehead regards closed source software as unambiguously evil, I don't see many other ways to interpret their behvaior.
But:
>Picking licenses that explicitly forbid incorporation of your code in modern GNU projects
By GNU fiat and nothing more. Some of us would rather code than get involved in tiresome political disputes. (See also the BSD class of licenses)
But:
>Picking licenses that explicitly forbid incorporation of your code in modern GNU projects
By GNU fiat and nothing more. Some of us would rather code than get involved in tiresome political disputes. (See also the BSD class of licenses)
"I'd love to be proven wrong on this. Considering that their figurehead regards closed source software as unambiguously evil, I don't see many other ways to interpret their behvaior."
Assuming (with confidence) that you mean RMS, he regards it as evil but my understanding is that his framework for making the assertion is more consequentialist than his detractors believe. With "evil" usually used in more deontological frameworks, I think the confusion is understandable but also understand his not wanting to give up the forcefulness implied by the term (we see time and again that people seem to underweight the risks implied by giving up their rights); I'm not sure if it's a mistake or not.
"By GNU fiat and nothing more. Some of us would rather code than get involved in tiresome political disputes. (See also the BSD class of licenses)"
No, by technicality of the licenses. It is not possible to write a license that 1) adds more restrictions, and 2) is compatible with GPLv2. 1) was deemed necessary because of what were seen as loopholes in GPLv2 - this may be construed as choice but "fiat" implies an arbitrariness that was not present. If instead Git was released under "GPLv2 or later", that code could be used more broadly - which is usually the rallying cry behind those endorsing more permissive licenses. It would still be entirely possible to move code from the work to GPLv2-only licensed projects.
Assuming (with confidence) that you mean RMS, he regards it as evil but my understanding is that his framework for making the assertion is more consequentialist than his detractors believe. With "evil" usually used in more deontological frameworks, I think the confusion is understandable but also understand his not wanting to give up the forcefulness implied by the term (we see time and again that people seem to underweight the risks implied by giving up their rights); I'm not sure if it's a mistake or not.
"By GNU fiat and nothing more. Some of us would rather code than get involved in tiresome political disputes. (See also the BSD class of licenses)"
No, by technicality of the licenses. It is not possible to write a license that 1) adds more restrictions, and 2) is compatible with GPLv2. 1) was deemed necessary because of what were seen as loopholes in GPLv2 - this may be construed as choice but "fiat" implies an arbitrariness that was not present. If instead Git was released under "GPLv2 or later", that code could be used more broadly - which is usually the rallying cry behind those endorsing more permissive licenses. It would still be entirely possible to move code from the work to GPLv2-only licensed projects.
> No, by technicality of the licenses ...
This teacup tempest is entirely of GNU's own making. It's nobody else's fault that their licenses are so onerous that they can't even keep them compatible with later revisions they themselves produce.
This teacup tempest is entirely of GNU's own making. It's nobody else's fault that their licenses are so onerous that they can't even keep them compatible with later revisions they themselves produce.
This is bullshit rhetorical sophistry, and I'm pretty sure you know it.
Choosing an incompatible license is the fault of the person who chose the license. The FSF made a mistake in not building "... or any later version" into the GPLv2; they acknowledge this. They've been recommending for some time - since long before the start of the Git project - that projects interested in being GPLv2 compatible include "... or any later version."
Imagine it was a piece of software with a bug. There's a patched version, it's been broadly announced that there was a bug and there is a fix. You ignore that and use the buggy version. Whose fault is it when you trip over the bug? Claiming it is "entirely of [the programmer]'s own making" is absurd.
Choosing an incompatible license is the fault of the person who chose the license. The FSF made a mistake in not building "... or any later version" into the GPLv2; they acknowledge this. They've been recommending for some time - since long before the start of the Git project - that projects interested in being GPLv2 compatible include "... or any later version."
Imagine it was a piece of software with a bug. There's a patched version, it's been broadly announced that there was a bug and there is a fix. You ignore that and use the buggy version. Whose fault is it when you trip over the bug? Claiming it is "entirely of [the programmer]'s own making" is absurd.
> This is bullshit rhetorical sophistry, and I'm pretty sure you know it.
No, I don't know it. The GNU's license absolutism is what got them into this mess in the first place. It's inherent in their aims.
> Imagine it was a piece of software with a bug.
Imagine that it's a piece of software with a new UX direction not everyone agrees with.
No, I don't know it. The GNU's license absolutism is what got them into this mess in the first place. It's inherent in their aims.
> Imagine it was a piece of software with a bug.
Imagine that it's a piece of software with a new UX direction not everyone agrees with.
[deleted]
> Having no problem with closed source does not make you "anti-free-software".
While true, its a bit odd of a statement. The following statements are also equally true:
Having no problem with deforestation does not make you "anti-environmentalist".
Having no problem with Ku Klux Klan members does not make you "anti-tolerance".
Having no problem with murder and theft does not make you "anti-government".
Except... if you are helping others in deforestation, the environmentalism movement will dislike you. If you are helping the Ku Klux Klan, the tolerance movement will dislike you. If you are helping murders, the government will lock you in.
So why do you label FSF as zealots for disliking actions that helps those that want to threaten users with lawsuits and prevent new versions of software for being used, shared or modified?
While true, its a bit odd of a statement. The following statements are also equally true:
Having no problem with deforestation does not make you "anti-environmentalist".
Having no problem with Ku Klux Klan members does not make you "anti-tolerance".
Having no problem with murder and theft does not make you "anti-government".
Except... if you are helping others in deforestation, the environmentalism movement will dislike you. If you are helping the Ku Klux Klan, the tolerance movement will dislike you. If you are helping murders, the government will lock you in.
So why do you label FSF as zealots for disliking actions that helps those that want to threaten users with lawsuits and prevent new versions of software for being used, shared or modified?
>So why do you label FSF as zealots for disliking actions that helps those that want to threaten users with lawsuits
Without even getting into the broken-ness of your analogies, being anti-DRM and anti-patent-abuse and so on is one thing. Calling someone evil because they don't publish the source of their app is quite another. According to their dogma, if I write a program and don't release the source code, I have perpetrated some horrible thing on the world. Regardless of any other interaction I might have with a user of my app.
Pardon my French, but that's fucking idiotic.
And even if I do release the source, I'm in the wrong if I don't release it under their pet license of choice. (Though not exactly "evil".)
What if my goal is to just see my code in use, not get embroiled in political battles? BSD is a de-facto more permissive license. What if I don't care if some corporation comes along and takes my code and releases a product based on it? Cool! I've helped the world somehow! And people who want to use my code don't have to get involved in GPL politics and drama!
My problem with the FSF is that they assume they are Right, their stance is Right, and anyone who disagrees or dissents is Wrong. Hence dogma. I know religions with more ideological tolerance.
Without even getting into the broken-ness of your analogies, being anti-DRM and anti-patent-abuse and so on is one thing. Calling someone evil because they don't publish the source of their app is quite another. According to their dogma, if I write a program and don't release the source code, I have perpetrated some horrible thing on the world. Regardless of any other interaction I might have with a user of my app.
Pardon my French, but that's fucking idiotic.
And even if I do release the source, I'm in the wrong if I don't release it under their pet license of choice. (Though not exactly "evil".)
What if my goal is to just see my code in use, not get embroiled in political battles? BSD is a de-facto more permissive license. What if I don't care if some corporation comes along and takes my code and releases a product based on it? Cool! I've helped the world somehow! And people who want to use my code don't have to get involved in GPL politics and drama!
My problem with the FSF is that they assume they are Right, their stance is Right, and anyone who disagrees or dissents is Wrong. Hence dogma. I know religions with more ideological tolerance.
> What if I don't care if some corporation comes along and takes my code and releases a product based on it? Cool! I've helped the world somehow!
Say you developed a program that keep tracks of group of people. The Ku Klux Klan use it to track down black people, and the anti-tolerance movement use it to track Ku Klux Klan. You helped the world and the anti-tolerance movement should be happy right? If they would prefer that the tool could not be used by the Ku Klux Klan, then they are evil zealots with no ideological tolerance.
Pardon my French too, but that's is fucking idiotic.
> And people who want to use my code don't have to get involved in GPL politics and drama!
That is a very dishonest statement. People can use Debian without becoming involved with politics and drama. I will state fact-less that most people who use GPL have not becoming involved with politics and drama.
> I know religions with more ideological tolerance.
Like BSD proponents I suppose? You own comment stated BSD as the right choice and anyone who disagrees is wrong. Maybe instead of preaching tolerance, you practice tolerance of people that disagree with you. Is it not more tolerant behavior avoid derogatory terms?
Say you developed a program that keep tracks of group of people. The Ku Klux Klan use it to track down black people, and the anti-tolerance movement use it to track Ku Klux Klan. You helped the world and the anti-tolerance movement should be happy right? If they would prefer that the tool could not be used by the Ku Klux Klan, then they are evil zealots with no ideological tolerance.
Pardon my French too, but that's is fucking idiotic.
> And people who want to use my code don't have to get involved in GPL politics and drama!
That is a very dishonest statement. People can use Debian without becoming involved with politics and drama. I will state fact-less that most people who use GPL have not becoming involved with politics and drama.
> I know religions with more ideological tolerance.
Like BSD proponents I suppose? You own comment stated BSD as the right choice and anyone who disagrees is wrong. Maybe instead of preaching tolerance, you practice tolerance of people that disagree with you. Is it not more tolerant behavior avoid derogatory terms?
>Say you developed a program that keep tracks of group of people. The Ku Klux Klan use it to track down black people, and the anti-tolerance movement use it to track Ku Klux Klan.
Stop it. You're basically engaging in a not-hitler version of Godwin's Law. And it's not even relevant, since the GPL is only about source code, not about whatever that code is used for. In your completely arbitrary and fucked up example, as long as the KKK released the source code to their tracking app, the GPL has nothing to say.
>You own comment stated BSD as the right choice and anyone who disagrees is wrong.
No, I said BSD is a de-facto more permissive license. It objectively has fewer restrictions on a developer than the GPL. Read what I said, not what you want me to have said, please.
Stop it. You're basically engaging in a not-hitler version of Godwin's Law. And it's not even relevant, since the GPL is only about source code, not about whatever that code is used for. In your completely arbitrary and fucked up example, as long as the KKK released the source code to their tracking app, the GPL has nothing to say.
>You own comment stated BSD as the right choice and anyone who disagrees is wrong.
No, I said BSD is a de-facto more permissive license. It objectively has fewer restrictions on a developer than the GPL. Read what I said, not what you want me to have said, please.
What you said was:
> BSD is a de-facto more permissive license. ... And people who want to use my code don't have to get involved in GPL politics and drama!
So yes, you statement was an "BSD as the right choice, GPL is the wrong choice". If you actually want to be tolerant of people right to license what they want, you should not badmouth their choices when they don't pick the same as you.
> as long as the KKK released the source code to their tracking app, the GPL has nothing to say.
I have said nothing about the license. I have said that the anti-tolerance movement would have something to say when that program helps KKK. I also said that it is an understandable reaction from the anti-tolerance movement. They are allowed to be both thankful for the help they got, and scornful about the fact that it is helping KKK.
This is the same complain when FSF dislike when proprietarization is made easier by other peoples license choices. They are thankful for the help, and also scornful about the fact that it makes their goal harder to achieve. If you don't find that relevant because "its a license" or because of godwin, then that is up to you.
> BSD is a de-facto more permissive license. ... And people who want to use my code don't have to get involved in GPL politics and drama!
So yes, you statement was an "BSD as the right choice, GPL is the wrong choice". If you actually want to be tolerant of people right to license what they want, you should not badmouth their choices when they don't pick the same as you.
> as long as the KKK released the source code to their tracking app, the GPL has nothing to say.
I have said nothing about the license. I have said that the anti-tolerance movement would have something to say when that program helps KKK. I also said that it is an understandable reaction from the anti-tolerance movement. They are allowed to be both thankful for the help they got, and scornful about the fact that it is helping KKK.
This is the same complain when FSF dislike when proprietarization is made easier by other peoples license choices. They are thankful for the help, and also scornful about the fact that it makes their goal harder to achieve. If you don't find that relevant because "its a license" or because of godwin, then that is up to you.
I wonder why is it always the anti-GNU people who are behaving like raging teenagers? I have never heard FSF advocate call people zealot or "fucking idiotic" for preferring other license, but the other way around it's a rather common occurrence. I don't want to generalize, but I guess it has to do with they kinds of people who like and dislike GNU.
The day when people will say "oh I like BSD better" instead of "OMG BSD is much more free you are fucking idiots for liking GPL" will be a good day.
The day when people will say "oh I like BSD better" instead of "OMG BSD is much more free you are fucking idiots for liking GPL" will be a good day.
Who'd have thought? Some people don't like being called "evil" for what they choose to do with their code.
Who has ever called BSD "evil"? They do have a devil icon (a point Uncyclopedia is having fun with), but who in their right mind would call BSD evil as a concept?
Proprietary software is sometimes called evil by the free software movement. It is after all the very model that the movement was created to destroy. The environmentalist movement will also call deforestation "evil", as well as anyone who dump oil into the oceans.
BSD however are not Proprietary software. Is it possible, that this discussion is not really about BSD, but rather you using it as a front for your own interesting in proprietary software model. In that case, you are being very dishonest.
Proprietary software is sometimes called evil by the free software movement. It is after all the very model that the movement was created to destroy. The environmentalist movement will also call deforestation "evil", as well as anyone who dump oil into the oceans.
BSD however are not Proprietary software. Is it possible, that this discussion is not really about BSD, but rather you using it as a front for your own interesting in proprietary software model. In that case, you are being very dishonest.
> BSD is a de-facto more permissive license.
Just saying something like this seems slightly dishonest. It's more permissive for the first receiver of the code, but that therefore means that they are permitted to reduce the persmissions of subsequent receivers of the code.
So 'more permissive' in a sense yes, but not in the sense that the FSF care about - the freedoms that the end user is guaranteed. It's quite possible that the end user is ultimately granted fewer permissions because code was licensed BSD rather than GPL.
Just saying something like this seems slightly dishonest. It's more permissive for the first receiver of the code, but that therefore means that they are permitted to reduce the persmissions of subsequent receivers of the code.
So 'more permissive' in a sense yes, but not in the sense that the FSF care about - the freedoms that the end user is guaranteed. It's quite possible that the end user is ultimately granted fewer permissions because code was licensed BSD rather than GPL.
[deleted]
I guess part of the issue is that Stallman came up with "Free Software," so there's obviously a version of the meaning of the term which is entirely up to Stallman.
If you agree there's a wider meaning of the term, then it's up to context whether someone's making a no true Scotsman argument or rationalizing the behavior of an antagonist.
Just pointing this out, because you might as well be arguing the meta-point about there being a cathedral of the meaning of "Free Software," or a bazaar. Hah.
If you agree there's a wider meaning of the term, then it's up to context whether someone's making a no true Scotsman argument or rationalizing the behavior of an antagonist.
Just pointing this out, because you might as well be arguing the meta-point about there being a cathedral of the meaning of "Free Software," or a bazaar. Hah.
> The people who avoid the GPL3 do it because they do not share the goals of the GNU project.
Plenty of people share the (publicly stated) goals of the GNU project regarding free software, but disagree with the FSF's approach to realizing those goals, particularly with the GPLv3. (With the GPLv2 I merely thought that the FSF's approach was more restrictive than was necessary, with the GPLv3 and the use-based discrimination in the anti-tivoization clause, I find it actively harmful.)
Plenty of people share the (publicly stated) goals of the GNU project regarding free software, but disagree with the FSF's approach to realizing those goals, particularly with the GPLv3. (With the GPLv2 I merely thought that the FSF's approach was more restrictive than was necessary, with the GPLv3 and the use-based discrimination in the anti-tivoization clause, I find it actively harmful.)
> The people who avoid the GPL3 do it because they do not share the goals of the GNU project.
Not necessarily true... it might simply be that they feel the goals of GNU are better pushed for via means other than GPLv3.
E.g. read a statement by Linux kernel devs regarding the second draft of GPLv3: http://lkml.org/lkml/2006/9/22/217
Has nothing to do with not supporting the goals of GNU, and more to do with not introducing end use restrictions (which is a significant restraint on software freedom), the risk of balkanizing the FLOSS community (which has actually come true to some extent), etc.
Not necessarily true... it might simply be that they feel the goals of GNU are better pushed for via means other than GPLv3.
E.g. read a statement by Linux kernel devs regarding the second draft of GPLv3: http://lkml.org/lkml/2006/9/22/217
Has nothing to do with not supporting the goals of GNU, and more to do with not introducing end use restrictions (which is a significant restraint on software freedom), the risk of balkanizing the FLOSS community (which has actually come true to some extent), etc.
Please don't bring up that old discussion about an 7 old draft of a license. There is better articles about the actually license as it exist (like http://www.computerworlduk.com/news/open-source/6882/torvald...).
> And "anti-GNU people" is just a lame insult.
My point was that in the context of Emacs, arguably the GNUest of the GNU, being anti-GNU is nothing to scoff at. Indeed, bzr was chosen for a long time because it was an official GNU project and was usable enough.
The hg devs went through great pains to change the license from GPLv2 to GPLv2-or-later. Lead dev Matt Mackall calls himself a free software advocate (not open source) is good friends with the likes of Bradley Kuhn and Eben Moglen of Software Freedom Conservancy and the Software Freedom Law Center respectively, and makes a point about defending Mercurial's copyleft. Ideology being important for GNU Emacs, it also seemed important to me to argue in favour of Mercurial on these grounds.
That Mercurial also happens to be fast, featureful, innovative, and generally kickass is a nice cherry on top. Its only significant drawback is that it's not as popular as git.
My point was that in the context of Emacs, arguably the GNUest of the GNU, being anti-GNU is nothing to scoff at. Indeed, bzr was chosen for a long time because it was an official GNU project and was usable enough.
The hg devs went through great pains to change the license from GPLv2 to GPLv2-or-later. Lead dev Matt Mackall calls himself a free software advocate (not open source) is good friends with the likes of Bradley Kuhn and Eben Moglen of Software Freedom Conservancy and the Software Freedom Law Center respectively, and makes a point about defending Mercurial's copyleft. Ideology being important for GNU Emacs, it also seemed important to me to argue in favour of Mercurial on these grounds.
That Mercurial also happens to be fast, featureful, innovative, and generally kickass is a nice cherry on top. Its only significant drawback is that it's not as popular as git.
Aaah, so I see you have not yet encountered the ideological spit between the "open source" and "free software" movements. The difference may be nigh-indistinguishable, but the participants get very worked up about it. More so on the FSF side, but people like esr also get quite worked up on the OSI side.
>And "anti-GNU people" is just a lame insult
It is an insult? Like "people with common sense" or "individuals of sound mind"?
It is an insult? Like "people with common sense" or "individuals of sound mind"?
Or "chair-throwers"?
A slight exaggeration, but yes, that's quite close to the OP's argument (Git is GPLv2 and will not change; Hg is GPLv2+ and therefore closer in spirit to GNU's goals and a GNU project like Emacs should favor GPLv3 and AGPL tools).
Luckily, that particular argument is thoroughly rebutted downthread. Choice quote: "Emacs shot itself in this foot already" by choosing Bzr, GNU's blessed VCS, for such political reasons. (Worth noting: RMS raised no strong objections to Git.) Also, the OP is called out for not understanding the driving reasons for moving Emacs to Git.
Edit: Corrected reference to Hg's license; it's GPLv2+, not GPLv3.
Luckily, that particular argument is thoroughly rebutted downthread. Choice quote: "Emacs shot itself in this foot already" by choosing Bzr, GNU's blessed VCS, for such political reasons. (Worth noting: RMS raised no strong objections to Git.) Also, the OP is called out for not understanding the driving reasons for moving Emacs to Git.
Edit: Corrected reference to Hg's license; it's GPLv2+, not GPLv3.
Quite frankly, not sharing GNU's goals is a feature, not a bug. The less the source code is encumbered by onerous political restrictions, the better.
I don't think that you'll find a lot of contributors to GNU Emacs who agree with that stance.
Onerous political restrictions, like, giving downstream users the same freedoms you got from the upstream author; the freedoms that the author wanted all users of their code to have?
Not even RMS holds that position. You should read the thread.
I find git's GPLv2-only license to be a disadvantage when
contrasted with hg's GPLv2-or-later. For example,
this makes it more awkward to combine git with AGPL code, which is
something that we reasonably might want to do for web front-ends.
GPLv3 and AGPL have mutual cross-compatibility clauses with each
other, but AIUI, GPLv2-only and AGPL don't.
Summary of main arguments:
Jordi Gutiérrez Hermoso:
The discussion evolved in the meantime, so it's probably better to read the thread yourself: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00...
Jordi Gutiérrez Hermoso:
[...] main argument in favour of hg is not technical, but
rather social. For GNU, I think it is far more important
to support a project that aligns with GNU's aims [...] GPL2+
+1. And I say that as someone who *likes* hg and wishes
it had won. Repeating the bzr mistake would be stupid, stupid, *stupid*.
The discussion evolved in the meantime, so it's probably better to read the thread yourself: https://lists.gnu.org/archive/html/emacs-devel/2014-01/msg00...
That's not an accurate summary of the main arguments. For one thing, on the pro-hg side you've quoted only the opinion of someone (Jordi Gutiérrez Hermoso) who isn't even an emacs dev: the email starts with a note to please cc him on replies because he isn't subscribed to the list! This isn't the view of the GNU project, the opinion of the Emacs developers on why they prefer hg over git, or even the personal view of RMS. You'll get a better summary if you read the thread.
I don't know why people quote ESR like that's still a thing either. He wrote some essays in the 90s, wrote some possibly important code before that time, but one must understand his position on this list is basically troll.
You completely misquoted the replies. ESR was NOT replying to the OP, he was agreeing with a rebuttal of the OP's argument.
Off-topic, but that's not how Spanish and Latin American names work. His "primary" last name is Gutiérrez, not Hermoso.
Your Tl;dr: is wrong.
For those of us less aware, could your or copx link to an explanation or why the tl;dr is or isn't wrong, or give us a quick one?
Petty factionalism within Open Source where if you don't support the latest views of the GNU committee and Dear Leader then you are against open source (which is ridiculous). Largest dispute has been a lot of GPL projects that won't move to v3 since there are a lot of problems with it.
Not even worth replying to, in my opinion.
Not even worth replying to, in my opinion.
> Not even worth replying to, in my opinion.
I agree with this, so I hesitated to reply... BUT I feel it's important to point out one thing.
You're using the term "Open Source" (capitalized, even), which is a related ideology, but still distinct. It's jarring to read:
> If you don't support the latest views of the GNU committee and Dear Leader then you are against open source
when the FSF discourages use of the term "open source"[0]!
That said, you're right that this is all pretty silly factionalism. People love to focus on less important differences[1], while ignoring the more important larger picture.
Even the FSF doesn't consider "open source" (or the GPLv2) to be bad; they consider themselves both fighting for the same result, just with different motivations. As far as they are concerned, the GPLv2 is fine; the GPLv3 just happens to be a bit better.
[0] https://www.gnu.org/philosophy/free-software-for-freedom.htm... (Don't be fooled by the title - the FSF views "Open Source" as an ally, not a rival).
[1] https://en.wikipedia.org/wiki/Narcissism_of_small_difference...
I agree with this, so I hesitated to reply... BUT I feel it's important to point out one thing.
You're using the term "Open Source" (capitalized, even), which is a related ideology, but still distinct. It's jarring to read:
> If you don't support the latest views of the GNU committee and Dear Leader then you are against open source
when the FSF discourages use of the term "open source"[0]!
That said, you're right that this is all pretty silly factionalism. People love to focus on less important differences[1], while ignoring the more important larger picture.
Even the FSF doesn't consider "open source" (or the GPLv2) to be bad; they consider themselves both fighting for the same result, just with different motivations. As far as they are concerned, the GPLv2 is fine; the GPLv3 just happens to be a bit better.
[0] https://www.gnu.org/philosophy/free-software-for-freedom.htm... (Don't be fooled by the title - the FSF views "Open Source" as an ally, not a rival).
[1] https://en.wikipedia.org/wiki/Narcissism_of_small_difference...
Context? This just seems to be a post from a Mercurial/Hg advocate.
Mercurial could be 10% better than git, but unless it's 500% better, it will never displace it.
Mercurial could be 10% better than git, but unless it's 500% better, it will never displace it.
Context matters here. Emacs uses bzr because it is an official Gnu project, but it's buggy and increasingly unmaintained, so there are reasons to switch. Jordi seems to have some personal thing against Git, while ESR favors Git but is bad at interacting with humans. It's standard mailing list politics, with technical considerations irrelevant; IMHO the two most likely outcomes are sticking with Bzr and moving to Git, depending on how much ESR manages to piss people off.
I think this is the exact right question - without context hg advocacy makes little sense.
And when I personally engage in mercurial advocacy it with an understanding that as you say, unless it's 500% better than git – which it is not – it will never displace git. However hg is every bit as good as git and most of my advocacy (as in this mail) is merely point this fact out and dispelling quite a lot of FUD, which seems to pop up in these discussions.
My goal is to see Mercurial continue in its position as the Mac (or Linux) of dvcs' to gits Windows. That is as an honest, respectable choice that you might, or might not make for valid reasons.
And when I personally engage in mercurial advocacy it with an understanding that as you say, unless it's 500% better than git – which it is not – it will never displace git. However hg is every bit as good as git and most of my advocacy (as in this mail) is merely point this fact out and dispelling quite a lot of FUD, which seems to pop up in these discussions.
My goal is to see Mercurial continue in its position as the Mac (or Linux) of dvcs' to gits Windows. That is as an honest, respectable choice that you might, or might not make for valid reasons.
or it could be 10% lesser than git. arguably, feels 50% slower. ;-)
I've been meaning to do a blog post about this for a while, but I've tried both, and so far, I prefer Git because of the way it treats branches. Git seems far friendlier to the workflow of just doing stuff, and deciding how you want to commit it later. In Git, it's easy to work for a while, then decide you have 3 commits worth of changes, and one of them really ought to be in its own branch, and commit it all like that. The code that you branched off stays out of your mainline for now, but is easy to switch back to and work on some more. At any time, you can easily delete the branch, and it all effectively disappears, push it somewhere else for somebody else to work on, or merge it back into main when it's ready. Well, merging might be tricky if you wait too long, but you get the idea.
Where Mercurial falls short to me is that if you create a branch in your main repository like that, then it never goes away as far as I can tell. What Mercurial really wants you to do is clone your repo, and do that work that would be a Git branch in the clone. But to do that, you have to start with a clean repo, actively decide you want to create a new branch/clone, clone your repo, and only then start doing that work in the clone. If you've already done some work, and then decided that a piece of it ought to be branched off, then your workflow is pretty messy - you have to clone with the work uncommitted, then manually move the changes over to the clone and commit them there. And switch any working directories you might have open to the clone directory to work in it.
Yeah, no thanks, I'll stick with Git.
Where Mercurial falls short to me is that if you create a branch in your main repository like that, then it never goes away as far as I can tell. What Mercurial really wants you to do is clone your repo, and do that work that would be a Git branch in the clone. But to do that, you have to start with a clean repo, actively decide you want to create a new branch/clone, clone your repo, and only then start doing that work in the clone. If you've already done some work, and then decided that a piece of it ought to be branched off, then your workflow is pretty messy - you have to clone with the work uncommitted, then manually move the changes over to the clone and commit them there. And switch any working directories you might have open to the clone directory to work in it.
Yeah, no thanks, I'll stick with Git.
> Where Mercurial falls short to me is that if you create a branch in your main repository like that, then it never goes away as far as I can tell.
`bookmarks` will do that. Or you can use unnamed heads and track them manually[0] (that's essentially what bookmarks — and git branches — do). "Detached heads" are not a thing in mercurial, heads don't have to be named.
[0] obviously there's nothing to track if you're just going on a short tangent, just commit your stuff, and go back to the original to merge if it was a good idea or forget if it was not. And yes you can create a bookmark "after the fact" e.g. do half a dozen commits, realise that it's going to take longer than you thought and create a bookmark for the current experiment on the tip.
`bookmarks` will do that. Or you can use unnamed heads and track them manually[0] (that's essentially what bookmarks — and git branches — do). "Detached heads" are not a thing in mercurial, heads don't have to be named.
[0] obviously there's nothing to track if you're just going on a short tangent, just commit your stuff, and go back to the original to merge if it was a good idea or forget if it was not. And yes you can create a bookmark "after the fact" e.g. do half a dozen commits, realise that it's going to take longer than you thought and create a bookmark for the current experiment on the tip.
This is it exactly. A lot of people miss this with hg. hg bookmarks are the equivalency to git branches. hg branches are "permanent." So you have, say, 'dev,' 'test' and 'stable' branches. Then you do hot-fixes and feature development on bookmarks, and merge them back into the branches.
It's a beautiful thing, really <tears up a bit..../>
It's a beautiful thing, really <tears up a bit..../>
> hg bookmarks are the equivalency to git branches.
In my opinion, this is not all good although it clearly solves a problem. Having two somewhat non-orthogonal features for branching undoes a part of the easier learning curve argument. You end up having to educate people whether to use bookmarks or branches and in what situations.
If branches are permanent, who are allowed to create branches? Everyone or just maintainers/core developers? What if a would-be contributor creates a branch that isn't wanted as a permanent branch or has a bad name? Need to rename a branch or do some tricks to comply with the upstream conventions? It ends up being a similar social/political issue to git rebase vs. git merge.
The easier learning curve argument was more relevant when people were coming to hg from svn/cvs backgrounds. These days more and more people are coming from a git background.
In my opinion, this is not all good although it clearly solves a problem. Having two somewhat non-orthogonal features for branching undoes a part of the easier learning curve argument. You end up having to educate people whether to use bookmarks or branches and in what situations.
If branches are permanent, who are allowed to create branches? Everyone or just maintainers/core developers? What if a would-be contributor creates a branch that isn't wanted as a permanent branch or has a bad name? Need to rename a branch or do some tricks to comply with the upstream conventions? It ends up being a similar social/political issue to git rebase vs. git merge.
The easier learning curve argument was more relevant when people were coming to hg from svn/cvs backgrounds. These days more and more people are coming from a git background.
>Having two somewhat non-orthogonal features for branching undoes a part of the easier learning curve argument. You end up having to educate people whether to use bookmarks or branches and in what situations.
Like most things, it depends. But mostly no, it doesn't impact the learning curve issue, especially if your team uses the git branching model, you never even have to address Mercurials named branches.
I'd also say all the other advantages of Mercurial far out-weigh something a conceptually simple as "use bookmarks for git-like, non-permanent branches; use named branches for permanent branches." Done.
Like most things, it depends. But mostly no, it doesn't impact the learning curve issue, especially if your team uses the git branching model, you never even have to address Mercurials named branches.
I'd also say all the other advantages of Mercurial far out-weigh something a conceptually simple as "use bookmarks for git-like, non-permanent branches; use named branches for permanent branches." Done.
This article is a little dated, but it conveys the flexibility of Mercurial branching.[1]
I don't know why git users get so hung up on named branches—you never have to use them if they don't make sense for your project.
[1] http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...
I don't know why git users get so hung up on named branches—you never have to use them if they don't make sense for your project.
[1] http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me...
Indeed, without a dictator controlling the 'central repo' you do have the issue of contributors borking your branches.
As far as learning curve, the branch/bookmark confusion doesn't seem to be all that big in practice IMO.
As far as learning curve, the branch/bookmark confusion doesn't seem to be all that big in practice IMO.
I hadn't heard of that, and it does sound like a nice feature, but it still seems a little hacky compared to Git branches. At best, it would be as good as them, but then why not stick with the original?
Oddly enough, I find myself liking the simplicity of Git here. You can do pretty complex stuff with it, but having only one type of branch seems to help some. That, and the local-only stashsets, which seem to be intentionally kept as simple as possible. In Mercurial, you have named branches, unnamed branches, cloned repos, bookmarks, maybe some other stuff that I don't know about, and I'm not really sure how they all interact and what's used for what.
Oddly enough, I find myself liking the simplicity of Git here. You can do pretty complex stuff with it, but having only one type of branch seems to help some. That, and the local-only stashsets, which seem to be intentionally kept as simple as possible. In Mercurial, you have named branches, unnamed branches, cloned repos, bookmarks, maybe some other stuff that I don't know about, and I'm not really sure how they all interact and what's used for what.
> I hadn't heard of that, and it does sound like a nice feature, but it still seems a little hacky compared to Git branches.
It's exactly the same thing git branches do. If it seems hacky, it's also hacky in git.
> At best, it would be as good as them, but then why not stick with the original?
Stick with what original? The originals in mercurial are branches (where the branch name is part of the commit metadata and thus of the repository's history forever, save for history rewriting) and "anonymous heads".
Then users clamoured for transient (movable, renamable, deletable) git-style branches, so bookmarks were added as an option.
> cloned repos
Erm… you can also clone repositories in git.
> I'm not really sure how they all interact
At the end of the day, it's all commit DAG.
It's exactly the same thing git branches do. If it seems hacky, it's also hacky in git.
> At best, it would be as good as them, but then why not stick with the original?
Stick with what original? The originals in mercurial are branches (where the branch name is part of the commit metadata and thus of the repository's history forever, save for history rewriting) and "anonymous heads".
Then users clamoured for transient (movable, renamable, deletable) git-style branches, so bookmarks were added as an option.
> cloned repos
Erm… you can also clone repositories in git.
> I'm not really sure how they all interact
At the end of the day, it's all commit DAG.
> It's exactly the same thing git branches do. If it seems hacky, it's also hacky in git.
I more meant that it seems hacky to add a feature that's mostly-sorta like Git branches to Mercurial now.
> Stick with what original? The originals in mercurial are branches (where the branch name is part of the commit metadata and thus of the repository's history forever, save for history rewriting) and "anonymous heads".
I meant original as in Git vs Mercurial. Like if you want Git-like branches, then why not just stick with Git?
> Erm… you can also clone repositories in git.
Yeah, you could, but I've never seen anybody recommend cloning a Git repo on the same computer for the purpose of separating out work from the main branch. At least for a while, this seemed to be widely recommended way of separating code out in Mercurial.
Where things get kinda weird - in Git, if you want to commit code somewhere that doesn't go into main just yet, there are only 2 options - branches and stash, and stash is explicitly meant to be a very short-term, local thing, since you can't really share them easily and they aren't really part of the commit hierarchy. That makes things simpler, as you never have to wonder what the right feature to use is for keeping separate work somewhere and sharing it with other people. You can create complex structures with branches, but at least there's only one 'type' of thing to keep track of.
I'm not as familiar with Mercurial, but for ways to keep temporary work somewhere, it seems we have named branches, anonymous branches, bookmarks, cloned repos on the same system, and apparently shelve too. According to this guy[1], the workflows for sharing bookmarks around don't seem to be fleshed out all that well either. So how do I know which one to use for what tasks?
[1] http://www.kevinberridge.com/2012/05/hg-bookmarks-made-me-sa...
I more meant that it seems hacky to add a feature that's mostly-sorta like Git branches to Mercurial now.
> Stick with what original? The originals in mercurial are branches (where the branch name is part of the commit metadata and thus of the repository's history forever, save for history rewriting) and "anonymous heads".
I meant original as in Git vs Mercurial. Like if you want Git-like branches, then why not just stick with Git?
> Erm… you can also clone repositories in git.
Yeah, you could, but I've never seen anybody recommend cloning a Git repo on the same computer for the purpose of separating out work from the main branch. At least for a while, this seemed to be widely recommended way of separating code out in Mercurial.
Where things get kinda weird - in Git, if you want to commit code somewhere that doesn't go into main just yet, there are only 2 options - branches and stash, and stash is explicitly meant to be a very short-term, local thing, since you can't really share them easily and they aren't really part of the commit hierarchy. That makes things simpler, as you never have to wonder what the right feature to use is for keeping separate work somewhere and sharing it with other people. You can create complex structures with branches, but at least there's only one 'type' of thing to keep track of.
I'm not as familiar with Mercurial, but for ways to keep temporary work somewhere, it seems we have named branches, anonymous branches, bookmarks, cloned repos on the same system, and apparently shelve too. According to this guy[1], the workflows for sharing bookmarks around don't seem to be fleshed out all that well either. So how do I know which one to use for what tasks?
[1] http://www.kevinberridge.com/2012/05/hg-bookmarks-made-me-sa...
hg's equivalent of stash is shelve:
http://mercurial.selenic.com/wiki/ShelveExtension
It does pretty much exactly the same thing.
http://mercurial.selenic.com/wiki/ShelveExtension
It does pretty much exactly the same thing.
That's only true for named branches. You can create an unnamed branch in hg simply by going to a point in the history (what Git would call detached head) and committing.
That said, the handling of named branches remains a pain point, and at this point I would recommend people just go with Git despite the steeper learning curve.
That said, the handling of named branches remains a pain point, and at this point I would recommend people just go with Git despite the steeper learning curve.
or just use bookmarks and enjoy the exact same workflow as git.
Relevant: Facebook migrated from git to hg awhile back.
Here's a blog post on how they are scaling hg for their monolithic repos https://code.facebook.com/posts/218678814984400/scaling-merc...
Here's a blog post on how they are scaling hg for their monolithic repos https://code.facebook.com/posts/218678814984400/scaling-merc...
And by scale they really mean swapped out whole parts of hg, which they could have done with git as well.
My biggest issues with hg are that hg's revision numbers aren't synchronized across instances, they are local only[1] making them kind of useless, you can't easily have local branches[2], and it stores changesets instead of objects.
I've ever seen a convincing argument to choose hg over git. Sure you can do a lot of things with it and I'm sure it's perfectly fine to use, but if you know git, and you like git, there's no reason to switch. What does hg have that makes it better than git that you should give up git? Popularity is what git has over hg. Someone using git will probably never have to spend anytime worrying about learning hg, but an hg user will have to become familiar with git because git is used everywhere nowadays. So my recommendation to people new to versioning systems is to pick git. I can't for the life of me understand why someone would pick hg for an open source project unless they wanted to throw learning curves and barriers at developers, or they just really really liked hg (probably because they chose it over git a long time ago).
[1] http://mercurial.selenic.com/wiki/RevisionNumber
[2] http://stackoverflow.com/questions/8995598/can-i-mark-a-bran...
I've ever seen a convincing argument to choose hg over git. Sure you can do a lot of things with it and I'm sure it's perfectly fine to use, but if you know git, and you like git, there's no reason to switch. What does hg have that makes it better than git that you should give up git? Popularity is what git has over hg. Someone using git will probably never have to spend anytime worrying about learning hg, but an hg user will have to become familiar with git because git is used everywhere nowadays. So my recommendation to people new to versioning systems is to pick git. I can't for the life of me understand why someone would pick hg for an open source project unless they wanted to throw learning curves and barriers at developers, or they just really really liked hg (probably because they chose it over git a long time ago).
[1] http://mercurial.selenic.com/wiki/RevisionNumber
[2] http://stackoverflow.com/questions/8995598/can-i-mark-a-bran...
> you can't easily have local branches [2]
>
> http://stackoverflow.com/questions/8995598/can-i-mark-a-bran...
I don't get it. As a citation for your assertion that you can't easily have local branches, you link to a StackOverflow question for which the accepted answer explains how to easily have local branches.
What were you trying to say with that link?
I don't get it. As a citation for your assertion that you can't easily have local branches, you link to a StackOverflow question for which the accepted answer explains how to easily have local branches.
What were you trying to say with that link?
I'm not going to answer your question because I feel like what I said (not tried to say, but said) was obvious, but I will point out that things like this kinda throw a wrench into the whole "hg's UI is better than git" don't ya think?
As stated by the documentation, those numbers are purely a convenience feature for when you don't want to give the actual revision hash to a command. The latter is what you have to do in git anyway.
Exactly. Git has one way to refer to commits: hashes. Mercurial has two: hashes and revision numbers. If you don't like revision numbers, ignore them, and you're in exactly the same position as with Git.
> What does hg have that makes it better than git that you should give up git?
Better user experience out of the box for Windows shops.
This might change with Microsoft's adoption of git for TFS, but you won't find many appraisals for git at my workplace. Many people still miss hg.
Better user experience out of the box for Windows shops.
This might change with Microsoft's adoption of git for TFS, but you won't find many appraisals for git at my workplace. Many people still miss hg.
You mean tortoiseHG? There's tortoisegit as well. And the first Windows-only proprietary client I could find supports both systems (Smartgithg: http://www.syntevo.com/smartgithg/)
The place I'm currently working is (sadly) a Windows shop, and we've never had any issues using msys-git.
Some of us use TortiseGit for logs, diffs, etc (we used to use TortiseSVN pretty much exclusively before we moved)
Some of us use TortiseGit for logs, diffs, etc (we used to use TortiseSVN pretty much exclusively before we moved)
>My biggest issues with hg are that hg's revision numbers aren't synchronized across instances, they are local only[1] making them kind of useless, you can't easily have local branches[2], and it stores changesets instead of objects.
Nope. Revision numbers are just a convenience when you're working locally in a repo. Just like Git, each commit is uniquely identified using a SHA hash.
No again on the local branches. Again, Mercurial is even more flexible when it comes to branching that Git is: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me....
Nope. Revision numbers are just a convenience when you're working locally in a repo. Just like Git, each commit is uniquely identified using a SHA hash.
No again on the local branches. Again, Mercurial is even more flexible when it comes to branching that Git is: http://stevelosh.com/blog/2009/08/a-guide-to-branching-in-me....
Why are people sweating small stuff like version control systems? How can you be a fanboy of a thing that keeps track of branches and patches. It's only incidentally related to Software development, you shouldn't feel as if a limb of yours was amputated if you \gasp\ had to use a different one for another project.
It's like using a different mail client or a different bug tracker; it doesn't affect what you can express or how can you build a program. It's just Version Control.
It's like using a different mail client or a different bug tracker; it doesn't affect what you can express or how can you build a program. It's just Version Control.
Because developers spend a lot of their day working with them.
And it can take a significant amount of time getting to grips with a new one you are unfamiliar with.
And you can often quite easily get yourself in quite a serious tangle with complex merges and operations done with VCSs leading to a lot of cursing and hatred for a particular tool.
A pair of shoes is just a pair of shoes, but I'd still quite like a pair I find comfortable, thanks.
And it can take a significant amount of time getting to grips with a new one you are unfamiliar with.
And you can often quite easily get yourself in quite a serious tangle with complex merges and operations done with VCSs leading to a lot of cursing and hatred for a particular tool.
A pair of shoes is just a pair of shoes, but I'd still quite like a pair I find comfortable, thanks.
Maybe, but it's not something worth making into a political issue into itself, when the GNU project has actual political issues in mind, as close as they get to when speaking of a Software stack, like making sure that the management of a certain project is as close to their ideology as possible, as a political organization which writes Software (which is what the FSF and the GNU project always were, and a pair of beneficial ones at that).
That's true, in a way, until someone tries to force CVS on you. Yes they are all sideline tools but once you get used to something, its the best thing in the world, until you get used to something else. Change is great, but not quite appreciated enough.
At work (where my script to convert all of our projects from CVS to Hg is complete for almost ¾ of a year now) I now resort to a hacky PowerShell script that allows me to work locally with Hg and then push selected revisions to CVS. Mostly because I fear that we won't ditch CVS for quite a while and when we do I'm probably the one to blame for lost developer productivity while we're coming to grips with a new tool.
So many wrongs in one comment. The fact you believe you'll be blamed for dev productivity loss is just not right. Blame? The fact you have to write scripts converting from one source control to another is not good, the fact you resort to hacky powershelling is scary. I wasn't even thinking the "are they still using cvs in 2014" even but I guess I should have.
"blame" should exist in source control systems only.
Actually I was agreeing to your point that at the time when CVS is used version control is no longer "just a tool" but a PITA.
I'm the one who suggested conversion to a newer system, so when the other developers need to re-learn and lose a week of productivity that way it is my fault, to some extent.
My conversion script is essentially just automating creating cvs2hg config files for a number of CVS modules (and cleaning up before/after conversion) because our CVS repo is a few GiB in size, containing everything that ever existed (and plenty of things beside that) so a 1:1 conversion isn't that ideal, especially because it will lead to frequent (harmless) merges. But to developers with a CVS background merges are scary.
My cvshg PowerShell script is based around https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS and http://pavelchikulaev.wordpress.com/2012/04/09/using-mercuri..., but tailored to how I use the tools. It allows me to commit happily locally and histedit later when I need commits I can actually share with others.
I'm the one who suggested conversion to a newer system, so when the other developers need to re-learn and lose a week of productivity that way it is my fault, to some extent.
My conversion script is essentially just automating creating cvs2hg config files for a number of CVS modules (and cleaning up before/after conversion) because our CVS repo is a few GiB in size, containing everything that ever existed (and plenty of things beside that) so a 1:1 conversion isn't that ideal, especially because it will lead to frequent (harmless) merges. But to developers with a CVS background merges are scary.
My cvshg PowerShell script is based around https://wiki.mozilla.org/Using_Mercurial_locally_with_CVS and http://pavelchikulaev.wordpress.com/2012/04/09/using-mercuri..., but tailored to how I use the tools. It allows me to commit happily locally and histedit later when I need commits I can actually share with others.
That's different then, I agree. I read your original comment as if you're tasked with something and then expect to be blamed for it.
Yeah, well, there are hammers of many brands, but few have claws on both ends, as the analogy for a certain controversial piece of technology went.
Some people will be fanboys of anything they spend a meaningful part of their day with, because (a) it makes them feel good about themselves, and (b) they don't know any better. They're still in the larval hacker stage where they still have binary opinions about everything, because they don't yet have the technical depth to have more nuanced and informed opinions about this stuff.
If they can convince themselves that the few things they know really well are the only things that are important to know, then maybe they don't feel bad about all of the things that they're just starting to realize that they don't know. That's my interpretation at least.
If they can convince themselves that the few things they know really well are the only things that are important to know, then maybe they don't feel bad about all of the things that they're just starting to realize that they don't know. That's my interpretation at least.
Well said! And that's exactly why i cheerlead for Mercurial. Because of all the rabid Git fanboys.
I use Git and Mercurial daily. They're both ok. However..
I prefer Git to mercurial, mainly because:
- Git is noticeably faster for all operations (yeah, specially if you don't use GitHub for pull/push as they're slow as hell ;-)
- Git has sensible default settings, for example, git log is easier than hg log|less. Similarly, git show HEAD^ is easier than hg log --patch --rev tip. (Both are easier to remember, type, and keep the logic across the tool).
- Finally, Git handles everything in a generic fashion. Want to make a test branch and play around? git branch blahtest and play. With hg, you have to use queues, and weird commands such as qpop, qremove, qseries, qnew <= this is very confusing to newcomers. Basically, I feel like Git knows how to KISS better than Mercurial.
- Git is noticeably faster for all operations (yeah, specially if you don't use GitHub for pull/push as they're slow as hell ;-)
- Git has sensible default settings, for example, git log is easier than hg log|less. Similarly, git show HEAD^ is easier than hg log --patch --rev tip. (Both are easier to remember, type, and keep the logic across the tool).
- Finally, Git handles everything in a generic fashion. Want to make a test branch and play around? git branch blahtest and play. With hg, you have to use queues, and weird commands such as qpop, qremove, qseries, qnew <= this is very confusing to newcomers. Basically, I feel like Git knows how to KISS better than Mercurial.
> Git has sensible default settings, for example, git log is easier than hg log|less.
> Similarly, git show HEAD^ is easier than hg log --patch --rev tip
Wait, what? Those commands do completely different things. What are you trying to do?
Furthermore, the assertion that `git show` is "easier" than `hg log` seems odd on its face, why is it easier to have two different commands to see the same thing, with the only difference being the length of the revision set? (yes I know `git show` can also show other objects, but that's now how you used it here).
> Want to make a test branch and play around? git branch blahtest and play. With hg, you have to use queues
Uh… no. You can create a bookmark, or just commit stuff (hg has no prohibition against what git calls "detached heads", they're just anonymous branches).
You have to use MQ if you want to do quilt-type things. Used to be you also had to use it if you wanted to perform extensive history-rewriting, but that hasn't been the case for a few years now.
cat >> ~/.hgrc
[pager]
pager = less -FRX
[extensions]
pager=
> Similarly, git show HEAD^ is easier than hg log --patch --rev tip
Wait, what? Those commands do completely different things. What are you trying to do?
Furthermore, the assertion that `git show` is "easier" than `hg log` seems odd on its face, why is it easier to have two different commands to see the same thing, with the only difference being the length of the revision set? (yes I know `git show` can also show other objects, but that's now how you used it here).
> Want to make a test branch and play around? git branch blahtest and play. With hg, you have to use queues
Uh… no. You can create a bookmark, or just commit stuff (hg has no prohibition against what git calls "detached heads", they're just anonymous branches).
You have to use MQ if you want to do quilt-type things. Used to be you also had to use it if you wanted to perform extensive history-rewriting, but that hasn't been the case for a few years now.
> There, I fixed it.
GP's point was about defaults, not what you can configure. Even being somewhat familiar with hg, I didn't know about the "pager" extension.
> `git show` does not show a patch by default[...]
It does for me, with git 1.7.9.5.
> (hg has no prohibition against what git calls "detached heads", they're just anonymous branches)
I have never understood why this is useful. Why not just name your heads something, anything? I wouldn't otherwise care, but I always seemed to end up with mysterious heads from who-knows-where left behind by long-ago merges.
GP's point was about defaults, not what you can configure. Even being somewhat familiar with hg, I didn't know about the "pager" extension.
> `git show` does not show a patch by default[...]
It does for me, with git 1.7.9.5.
> (hg has no prohibition against what git calls "detached heads", they're just anonymous branches)
I have never understood why this is useful. Why not just name your heads something, anything? I wouldn't otherwise care, but I always seemed to end up with mysterious heads from who-knows-where left behind by long-ago merges.
> GP's point was about defaults
Granted, but he then describes the difficulty of typing `hg log | less`. And defaults cut both ways, I still can't fathom why `git log HEAD` would display the whole repository history.
> It does for me, with git 1.7.9.5.
Doesn't for me with git 1.8.5.4. Regardless I removed that part since it's not the gist of the issue and the official documentation asserts it should.
> I have never understood why this is useful. Why not just name your heads something, anything?
Why is a meaningless name better than no name at all? Why is git's default behaviour of losing unnamed heads altogether better than just leaving them alone?
Granted, but he then describes the difficulty of typing `hg log | less`. And defaults cut both ways, I still can't fathom why `git log HEAD` would display the whole repository history.
> It does for me, with git 1.7.9.5.
Doesn't for me with git 1.8.5.4. Regardless I removed that part since it's not the gist of the issue and the official documentation asserts it should.
> I have never understood why this is useful. Why not just name your heads something, anything?
Why is a meaningless name better than no name at all? Why is git's default behaviour of losing unnamed heads altogether better than just leaving them alone?
> And defaults cut both ways, I still can't fathom why `git log HEAD` would display the whole repository history.
I don't know why that's part of the defaults discussion, but okay.
> Why is a meaningless name better than no name at all? Why is git's default behaviour of losing unnamed heads altogether better than just leaving them alone?
Why would you give a meaningless name? That's a red herring. Do hg users just memorize which head is which?
Mercurial users seem to get hung up on detached heads a lot. They seem to be part of the Mercurial workflow in a way that I've never really understood. But git's detached heads are at least created when I expect them to be, are easily deleted, and are easily saved.
Mercurial's detached heads (or whatever they're called) want me to either merge them (why would I merge commits that popped up out of nowhere?), or close them as described in http://stackoverflow.com/questions/3688263/mercurial-beheadi... (apparently causing these mysterious heads to be saved forever). I much prefer a DAG with labels, instead of all this state specific to Mercurial that I have to manage.
I don't know why that's part of the defaults discussion, but okay.
> Why is a meaningless name better than no name at all? Why is git's default behaviour of losing unnamed heads altogether better than just leaving them alone?
Why would you give a meaningless name? That's a red herring. Do hg users just memorize which head is which?
Mercurial users seem to get hung up on detached heads a lot. They seem to be part of the Mercurial workflow in a way that I've never really understood. But git's detached heads are at least created when I expect them to be, are easily deleted, and are easily saved.
Mercurial's detached heads (or whatever they're called) want me to either merge them (why would I merge commits that popped up out of nowhere?), or close them as described in http://stackoverflow.com/questions/3688263/mercurial-beheadi... (apparently causing these mysterious heads to be saved forever). I much prefer a DAG with labels, instead of all this state specific to Mercurial that I have to manage.
> Do hg users just memorize which head is which?
Its not that bad if its only a couple of commits deep since you can look at the commit messages for context. And if you are using a gui like tortoiseHg then reading a commit message is basically the same amount of work as reading the bookmark name.
And if you really want to add a name you can add one, you just don't necessarily need to.
Its not that bad if its only a couple of commits deep since you can look at the commit messages for context. And if you are using a gui like tortoiseHg then reading a commit message is basically the same amount of work as reading the bookmark name.
And if you really want to add a name you can add one, you just don't necessarily need to.
note that if you use queues it works okay ;-)
FWIW, my equivalent of 'git show' is 'hg diff -c'. It shows the patch but not the metadata; this is usually what i want.
I know what you mean about hg not invoking a pager by default. I understand why the hg maintainers haven't done it, but it's still mildly annoying every time i have to throw in a |less.
I have no idea what you're talking about with queues. The last time i used queues was to do stashing back before hg got a proper shelve in the core. I don't think there's any sane use case which requires them now.
I know what you mean about hg not invoking a pager by default. I understand why the hg maintainers haven't done it, but it's still mildly annoying every time i have to throw in a |less.
I have no idea what you're talking about with queues. The last time i used queues was to do stashing back before hg got a proper shelve in the core. I don't think there's any sane use case which requires them now.
This is a great blog post about Mercurial and git:
http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercuria...
tl;dr: "If you take anything away from this post it should be that Mercurial is a flexible and agile tool."
http://gregoryszorc.com/blog/2013/05/12/thoughts-on-mercuria...
tl;dr: "If you take anything away from this post it should be that Mercurial is a flexible and agile tool."
Mine might be a very unpopular opinion, but I couldn't care less about different kinds of (D)VCS. I've got a feeling that recently I, and other team members, spend more and more time on branching, rebasing, cloning, merging etc. and less time on actual code writing.
Given that you "spend more and more time on branching, rebasing, cloning, merging, etc. and less time on actual code writing", shouldn't you care more about the different kinds of VCS?
Seems having the right tool should be important.
Seems having the right tool should be important.
> I don't get this argument. Windows and Mac OS X are also more popular; does this mean we shouldn't use any other OS because all of the cool games are almost exclusively developed on Windows?
Seems like that isn't the same situation. Rather the author should have asked " Windows and Mac OS X are also more popular; does this mean we shouldn't restrict developers to using a non-Windows, non-OS X system?" and the answer is quite simply "no, you shouldn't". Choosing a VCS means every needs to use that VCS. The same is not [necessarily] true for which operating systems can be used for development.
Seems like that isn't the same situation. Rather the author should have asked " Windows and Mac OS X are also more popular; does this mean we shouldn't restrict developers to using a non-Windows, non-OS X system?" and the answer is quite simply "no, you shouldn't". Choosing a VCS means every needs to use that VCS. The same is not [necessarily] true for which operating systems can be used for development.
A lot of these arguments seem to stem about whether git or hg is better, which seems about as useful as arguing vim/emacs or Windows/Linux/OS X -- it depends on what you need and what you already know.
If you're okay with using closed-source services, Fog Creek's Kiln allows you to have repositories that can be accessed with both git and hg; commits/branches/bookmarks in one will show up in the other automatically.
It seems to me that this argument could be solved if someone went and built a F/OSS equivalent that did the same thing for the emacs devs.
If you're okay with using closed-source services, Fog Creek's Kiln allows you to have repositories that can be accessed with both git and hg; commits/branches/bookmarks in one will show up in the other automatically.
It seems to me that this argument could be solved if someone went and built a F/OSS equivalent that did the same thing for the emacs devs.
One of his last points seems to be incorrect (or I'm misreading him).
One that I like that replaces my most frequent usage of magit is crecord: interactively select hunks for committing.
You're misreading him. 'hg record' is like 'git add -p', but 'hg crecord' (note the c) is a curses interface: https://bitbucket.org/edgimar/crecord/wiki/Home
Seems like discussing religion or politics to me.
A lot of this just seems like the GNU and FSF being anti-Torvalds, an extension of their clash over the naming of [Linux|GNU/Linux] issue.
Wait, I thought the whole reason they are ditching bzr is that nobody uses it. Why move to mercurial for the same problem?
For 99% devs out there these tools boils down to pretty much the same. UPS of git is Github and Linus
These kinds of posts are on the same level as programming language bashing posts.
In addition, I found it to be slower, less flexible, and prone to permanent repository corruption - yes, in git you do see repo corruption but because of the cryptographic nature of git objects you know immediately. HG will (did?) happily let you work away at a corrupted repo for weeks until a fresh clone was attempted and the dreaded repo corrupted message killed development for days until the problem was painstakingly manually fixed.
This is just personal experience and a lot of it comes down to taste, but IMO if you are already proficient with git there is absolutely nothing about mercurial that is preferable and some considerable downsides I have been subjected to.
Disclaimer: This was a few years ago now, perhaps the project is more mature than it was.