I have started to sign the commits to the source repository using GnuPG and will expect the same from future contributors to the project (although OpenSSL with X509 certificates will also be accepted, of course).
It provides a level of trust and the possibility of additional integrity-checking for the source code. Starting with revision 300 on the master repository (on SF.net) this takes effect.
The commitsigs.py extension will be used for the purpose. It can be cloned from here.
Additionally I am keeping a clone on Bitbucket, for “backup purposes” 😉
// Oliver
Which seems to suggest that WinDirStat is still alive, which I, in turn, cherish.
One huge feature which is still missing from the latest release is still accurate representation of NTFS special nodes, such as symlinks, hardlinks, junctions, and possibly compressed files (not sure about this last one).
Andrea, I think junctions and volume mount points are catered just fine, except for the possible additional information in another (possibly optional column).
And yes, it’s still alive. But spare time is a very scarce resource. Still, I’m using a big chunk of it for WDS again now.
Umm… why not just use git? Git guarantees integrity and authenticity, given just the top commit hash. http://www.youtube.com/watch?v=4XpnKHJAok8
SVN is quickly going the way of the dinosaur, and Mercurial has lost:
http://www.google.com/trends/explore#q=git,svn&geo=US
Okay, shall I be honest or diplomatic? Let me be honest:
Whatever you say … 🙄
That said: Git, no thanks!
Regardless of Git’s flaws, it is quickly becoming the VCS of choice for the great majority of programmers. Using SVN in 2013 is like using CVS in 2010 or RCS in 2005.
GitHub makes it trivial to contribute code to a project. Making a small change is a few clicks away. Merging a proposed change after reviewing it takes 1 click. These are some of the reasons why GitHub is becoming the de-facto code forge, and SourceForge and Google Code are slowly sliding into obscurity.
You’re trying to be constructive, but you’re just being stubborn. Git’s flaws are by far outweighed by its benefits.
Regarding signing – what I meant is that you only need to publish the repository’s HEAD SHA-1 via a verifiable channel (e.g. PGP-signed message). Git also allows you to sign tags ( see http://git-scm.com/book/en/Git-Basics-Tagging#Signed-Tags )
Link in first post was meant to include Mercurial:
http://www.google.com/trends/explore#q=git,svn,mercurial&geo=US
As you can see, (search query) interest in Mercurial has remained the same for the past 3 years, while Git skyrockets.
By the way, you’ve surely heard that Microsoft is adding native Git support to Visual Studio. Guess which VCSes they are NOT adding support for? SVN, Hg, and Bazaar.
I’ve re-read your first reply. You wrote:
I see you’re speaking from your prior experience with working with a centralized VCS, wherein everyone who wants to contribute to a project must have commit access.
This is not necessary with distributed VCSes. In fact, it’s not advised to do that. Consider the following model instead:
– There is one project maintainer (you), who everyone else ultimately trusts. The maintainer compiles executables, signs / publishes tarballs, etc.
– Everyone else who wishes to contribute, formulate a contribution as a series of commits, upload and record it as a pull request. GitHub provides the tools to do this.
– The pull request can be reviewed by all project members. GitHub displays diffs, and allows starting a discussion on each individual line of the diff.
– Once everyone is happy with the proposed change, and the maintainer has verified that there is nothing malicious in the changeset, the maintainer clicks “Merge pull request” – and the change is folded into the repository.
Isn’t this much better than the commit-rights drama, patches sent as huge diffs via emails or pasted in issue trackers, private SVN branches, etc.?
You don’t mean by any chance to “cheat” with the trends, hmm? Setting the location to US and using mercurial instead of the short form?!
http://www.google.com/trends/explore#q=git,svn,hg,mercurial
Well, they have to, because there is no proper tool support for Git on Windows in the first place.
Ever considered to write “NOT yet”? 😉
Bazaar wouldn’t make sense and SVN, while it makes progress, can’t compete with a DVCS. And then of course the support for Mercurial on Windows is good enough to get on without direct support for it in VS for some more time.
Also Microsoft’s own Codeplex supports Mercurial just fine, so claiming it’s lost is a bit far-fetched.
Your point being? Am I using SVN except at work in projects where I’m forced
So does Bitbucket. And unlike Github, which cemented it in its name, Bitbucket actually supports not only Mercurial (though this is where they come from) but also Git. But I bet you’re going to bend this argument so that this proves somehow how Git wins/won over other DVCS. Whatever rocks your boat …
Fair enough and I have contemplated to move on to Bitbucket completely, but not at this time. And Github is obviously out because they offered no Mercurial support last time I checked. Mind you, of course I am using Git as well when on *nix, but on Windows I use a Git-extension for Mercurial.
Oh yes? So you have worked with my work flow with both Git and Hg to make that call? Wow!
Unlike most programmers, who simply run after a hype or what some programmer on the web claims, I have actually tested Bazaar, Git and Mercurial over the course of a few months. This was more than three years back. The clear winner was Mercurial. Even though I understand the concepts in Git, the ideas behind them, I simply wouldn’t use most of those that people who compare the VCSs and then claim a victory for one or the other regard so highly. In short: the sucky tool support is the big issue, but there are many smaller issues with it.
Bazaar was a completely different story. While I didn’t like the repo layout, I can see how it has merits in many areas. Also there is a visible concept, which can’t be said of Git. The fact I didn’t choose Bazaar was because the tool support wasn’t as splendid at the time plus it seemed not as mature as Mercurial.
That doesn’t guarantee anything for the individual commits. It just guarantees that the succession of tags (or revisions). An individual commit could have been tampered with, if the hash algorithm was to be proven flawed.
Side-note: SHA-1 is known to have its weaknesses. It’s a matter of time until preimaging attacks and similar become feasible. It’s the reason SHA-3 was just recently chosen in a contest, because even though SHA-2 is unrelated to SHA-1 and MD5 (which both use very similar methods, in layman’s terms), it is expected that in time even SHA-2 will be broken. MD5 has been for about eight years now and many people still use it.
Signing a commit with GPG significantly raises the bar for someone intending to tamper with the commit.
I know, and I even said that. But I was almost certain that last time I checked you needed an extension to do it. Apparently it’s a core feature (at least now).
Edit 1: Actually your other comment with the
merely shows that you haven’t understood the difference (and presumably different use cases) for checksums, hashes and signatures and how the potential breakage of one affects the others. But that’s fine, I’ll leave you to your opinion and simply ask you grant me the same in return
People are welcome to send proper patches as bundles or pull requests already. I’m not at all stuck in the centralized work flow, even if you like to put that up as a straw man. All I ask is that they be signed by a key that has been signed by a number of other people, so that with reasonable certainty I can tell that the person is who s/he claims.
Well, judging from your tone, it doesn’t look like any constructive argument is going to change your mind, which is sad. I’ll just say a few more things, anyway:
“Hg” is the chemical symbol for mercury. Considering its nonsensical (as related to VCS) value indicated for 2005, it adds no relevance to your query.
With the assumption that “hg” and “mercurial” are used as often as the other (when referring to the VCS, of course), then my argument that search interest has remained the name does not change.
Also, I selected US only because “git” is a Turkish word, and it skewed the results. Not filtering by region would’ve been in “my favor” – but I’m not a Git advocate, I’m a common sense advocate. I’m having this conversation because I want to help this project, not spread some fanboy’s agenda.
GitHub over Bitbucket simply because it is what’s popular. There are far more GitHub users that BitBucket users. This is not a “let’s follow the herd” argument: Unlike for code forges with a centralized development model, this is very important, because contributing code makes heavy use of GitHub features. If I’m familiar with GitHub but not BitBucket, then registering a BB account and figuring out how to submit a change may be enough of a burden to reconsider contributing to your project, and investing my time elsewhere. GitHub’s motto is “social coding”, and they mean it.
Aside from its choice of exclusively supporting Git, GitHub provides richer collaboration features as well. For example, the project network graph displays the interconnections between all branches and forks.
But seriously, BitBucket would be a great step up from SVN already.
Are you serious? Do you realize how many years it’s been? Have you read Microsoft’s announcement?
What are you hoping for? That suddenly some of the lesser VCSes will magically improve and everyone will jump ship? Please be realistic, or at least back up your arguments.
Are you intentionally misinterpreting what I wrote? Surely you understood that by “lost” I meant, is less popular than the winner, and will almost certainly remain so in the future. I did not mean that no one uses it any more.
If your work flow is structured in a way that an older and inferior VCS fits better, then I suggest that you reconsider your work flow.
Very much has changed in the past three years. GitHub recently celebrated its 5th birthday, so it was only 2 years old when you did your tests. Git on Windows is now officially supported. Tooling has drastically improved, with great open-source and commercial Git UIs available. I suggest you check again.
I think the problem is that I’m missing the point for why you wish to do this. What are you trying to accomplish (what is the ultimate goal)?
Wait a moment. Hold your horses. So you find it constructive to botch into a discussion about signed commits by “proposing” a different VCS entirely but resent when people stick by decisions made on own judgments as opposed to following the herd?
I know it is, you know it is. Your point is moot, though, because neither of us has a comparison with the baseline use of the word “git” (which is also an English word, not just a Turkish one) and the term “hg” before the version control systems came around. Google Trends doesn’t go back that far.
And the fact that the project is using Mercurial is preventing you from contributing actively? I see.
In that case I will put up a Git clone on Github which I will use for the Git world to allow people like you who don’t want to use the great interoperability features in all of the distributed VCSs (including Git and Mercurial) to contribute.
Uhm, actually that is exactly what it is. Take a step back, look at it and you’ll see it.
So basically you say – let’s ignore the fact that I am working with Git and on Github as well – that I should switch the VCS (which will cost me hours and will cost those that use the current repo hours as well), learn a new system, learn how to use Github (as opposed to the other way around). Which is better exactly how?
Uhm … in case it still hasn’t registered with you: this project is using Mercurial, not SVN. We have moved quite some time ago to Mercurial. There is no active development in SVN anymore in this project.
Ah, yes, refreshing. I think you just contradicted and discredited yourself from here
purely by the choice of words. “Lesser VCSs” – way to go!
That first question I would like to pass back, just like the very first comment you made in the answer from which I am quoting right now. However, realizing that written communication doesn’t lend itself to convey a tone very well and that indeed it lends itself to misunderstandings, I will assume best intent on your part even now.
Let me bend your argument a bit further, to follow your logic. Windows is clearly the winner in the arena of operating systems. You must realize that. Because the majority of Git use happens on Linux, Git use on Linux has to be deducted from the overall use. Making … well, we can’t make a claim about the victor, but we can claim Git is definitely not the winner anymore.</sarcasm>
Oh wow. This is more ignorant than I would expect someone who is so easily offended by a few sarcastic remarks, given the circumstances of “choice of DVCS” not being a sub-topic of “signing commits” by any standards.
Mercurial and Git are about the same age. I consider neither of them inferior for my daily use. I do however consider SVN and CVS inferior by a huge margin.
Even if you argue that Hg doesn’t provide all of the features out of the box that Git does. Even if you put up the straw man staging area to claim “Hg doesn’t have that” or any other for that matter, it won’t change the fact that I am not using those features in my daily work and never actually saw the need for it during my testing period. So even then there is no compelling reason to switch from Mercurial to Git now. Let alone the irrelevance w.r.t. the discussion about signed commits.
I might actually do that if you help me with a few of my projects, including this one, so I can make the time to check again.
And no, even now the tool support on Windows is not great by any means for Git. It’s better than it used to be, though. At the risk of repeating myself, I am using Git on *nix and I have used it via Hg on Windows, but I am also giving the Git tools a try on Windows every now and then. None of the points you brought up so far are new to me and even in full awareness of them this project sticks with Mercurial for now.
If it gives you anything, keep in mind that the migration path from Mercurial to Git is lossless and pain-free (yes, done it … both ways actually).
Oh, this would be too long a talk. Let’s put it this way, I’ve been involved in FLOSS projects for the past thirteen or fourteen years and I have seen my share of crap. An example why a signed commit is better, aside from proving the authorship (as opposed to commits which can be faked to stem from a particular author), because the author cannot later go and claim they didn’t commit it or they disagree with the license of the project. If you’d look around you would see some other projects doing the same – many of them waaaaaay before this one.
OK, this is quickly spiraling out of control.
You are right on many points, and I apologize. I did not take into account the cost of moving the project elsewhere, because I thought you were the only active maintainer. I also was working on the wrong assumption that you still used SVN. Considering the above, I can’t recommend that the project moves to GitHub.
I also apologize for my tone in my previous posts. I got carried away, and for someone claiming to care about the project, that was obviously hypocritical.
I’ve probably stolen too much of your time already, so I’d just like to close a few points:
Yes, you’re right. However, the search volume for the word has grown dramatically in the past decade, and I doubt a significant part of it can be attributed to the use of “git” as an English word. Considering the graph starts at the 10 mark or under for all terms, I think it’s fine to consider that as the margin of error.
This is a hairy phrase by itself, but I intended to use it with a specific meaning: using something because it is popular by itself, and not counting any indirect consequences of such. You’re right in that, if we consider that “the herd” is the collective of developers that can effortlessly contribute to your project, then my recommendation is exactly that – but then it’s not a bad thing, is it? 😉
Sorry, I don’t follow the logic here. The sarcasm is lost on me.
That’s a mouthful…
1. I’m not offended, but you did make me feel guilty (and rightly so);
2. Where should have I posted this? How is this blog comment system a worse place to discuss the matter than anywhere else? The post reminded me of the subject, so I spoke my mind;
3. Inefficient workflow internalized by old tools can a real problem.
I’ve had the opportunity to occasionally collaborate with a software developer in his 50s. His workflow clearly originated from the limitations of software once popular a long time ago. When a new tool was introduced – instead of adapting his workflow around it, he would simply attempt to hammer the tool into his existing workflow, resulting in a process that was very inefficient and problematic to those around him. He refused to sit down and read the documentation, to figure out how the tool works and the best ways to use it, and instead simply sought answers to the problem directly in front of him, as dictated by his outdated workflow. And this is not an isolated case – old-school programmers tend to stick to their tools and workflow tooth-and-nail, much to the chagrin of younger people they collaborate with. I don’t know why, maybe they’re afraid of change?
So, without making any undue accusations, I’d like to ask you: are you sure the above doesn’t apply to you?
I’d also like to reiterate that 3 years is a long time for modern VCS development. If the Google Trends are any indication, then the popularity of Git has increased, substantially, and the “trend” does not look to be in favor of Mercurial and others.
Can you list some? I’ve contributed to a number of projects, but this is the first time I’ve seen this. I’ve seen some projects asking contributors to sign an agreement, but not this.
Hey, no problem at all. Just to make sure, I also didn’t mean to offend you in any way and apologize if this is how it came across. No offense taken, none intended either. I’ve been communicating on the web for long enough to know the limitations of written conversations in conveying the finer points (even with smilies).
On Bitbucket the project is currently (mainly to give it some exposure and attract more contributors) here.
Not if this leads to you becoming an actual contributor. And I was sincere about the Github stuff. Although won’t move I would certainly create a copy of the project there.
I don’t blame you at all. This is exactly the forum for this (the tracker perhaps being another), although the hook (i.e. the topic of signing commits) didn’t really make sense to me.
Tell me about it. I’ve been campaigning inside the company for some time. A few teams switched to Bazaar, others to Git, others to Hg, but some actually stick with SVN and CVS.
You met my boss?
Everybody is more or less. Change exposes weaknesses. Showing weaknesses tends to be considered a bad thing these days.
I am not 100% sure. I am able of self-reflexion, though, so I hope that the answer is no.
Ubuntu (Launchpad), SQLite and there was one more where I noticed it some time ago, but I don’t remember which one. And yes, this is the electronic form of a physical signature.