This is why the frequently brought up "just do it yourself, it's open-source" is easier said than done with major established projects. You either spend time and energy trying to manoeuvre project's politics/build system or go nuclear and maintain a fork of a large codebase, which is no small task either.

I'm not sure that answer is very helpful. He keeps referring to backwards-incompatible changes, but this fork is supposed to be only backwards-compatible changes anyway, so that's not terribly relevant.

The precedent here, which he is invoking with the naming scheme, are the famous kernel patchsets like linux-ac and linux-ck. The alternative isn't that the changes are in mainline, the alternative is that the changes aren't published at all.

Because Ruby is much closer to C, shell, and perl, which are the languages used by Git

Because Python's syntax is horrendous. I have contributed a lot of Python code for Git, so I would know.

Because Ruby's syntax is amazing

But more importantly:

Because that's the language I chose

If you (or anybody else) wants Python (or any other language), feel free to do the same thing I did for Ruby in a 44-patch series. I bet you my series would look better, because Ruby is a better fit. Go ahead, prove me wrong.

Even if someone did the work and rewrote them in Python, you would still find them reprehensible, regardless of their quality.

What's worse is that it makes git depend on a scripting language that's not default on any operating system, adding even more to the Bill of Materials for our Linux platforms. This is not to be commended. Whenever possible, we should be looking to standardize on one scripting language, and the momentum simply says Ruby ain't it.

Were I the maintainer of git, I too would ignore this patch series. It's absolutely uninteresting except to the "I love Ruby" camp.

Were I the maintainer of git, I too would ignore this patch series. It's absolutely uninteresting except to the "I love Ruby" camp.

I would disagree. While Ruby may not be the de facto standard for any operating system does not mean it should be discounted. Linux doesn't need a single standard scripting language, isn't this patch series trying to provide a single standard scripting language for git?

I don't know the exact details of the patch series, but if Ruby replaced sh and Perl scripts completely I think it should be considered. Granted I would say the same if all the sh scripts where replaced with Perl.

A Ruby based build script didn't really get traction for D either. Build systems have struggled in general, and in the case of D it didn't already have dependencies on several other script languages with the offer to reduce it to one standard.

I'm not usually one to do drive by comments like this, but dude, you are a serious asshole. I even agree with most of your changes in Git, but you need to tone it down a bit, and stop being so combative with people.

1) Many core commands in git are implemented in shell, and some in perl, which is not ideal, specially in platforms like Windows, where forks are expensive. I showed how it's trivial to rewrite a shell script to Ruby, and then slowly transform all the 'git foo' calls into native code using the bindings, at which point the Ruby code resembles C code. Then it's trivial to simply rewrite the Ruby code to C. So Ruby is a perfect choice to slowly convert scripts not only because Ruby is close to shell, perl and C, but also because it's very easy to write C bindings for Ruby.

Look at the thread where he argues for Ruby. Most of his arguments are completely arbitrary in favor of Ruby. When people propose lua (which pulls in way less dependencies due to the fact that it can be compiled in) he starts spreading a bunch of FUD.

The related thread and links there were an interesting read. Thanks for sharing. I guess all this has an important lesson about social dynamics in open source projects in it (either about bullies or butt-hurt contributors).

Filtering out the drama, I see Contreras asking a simple question: "would my patches be ever accepted, yes or no?" Twice in the same message, with Hamano studiously ignoring the question and choosing to reply instead to a narrow point. I think this is petty and unprofessional, no matter how disruptive Contreras is.

That simple question was preceded by months of OP's very trollish behavior on the list. His threads always turn into centi-threads that go nowhere. Apparently he got bored and has decided to troll reddit instead.

I don't think Junio is a bully, and I don't think I'm a butt-hurt contributor. I see it more like a culture of yes-men, and a dissident who questions authorities and dogmas. It's not surprising that a person like that doesn't thrive in such a culture.

The yes-men might be absolutely amazing at what they do, but there's only so much you can do with a monoculture, and I think Git's user-interface shows that perfectly.

I would strongly recommend watching this video to get a good idea as to the amount of red flags you are raising in these mailing threads.

I actually watched this video and this slide is particularly interesting:

You need to avoid paralysis

OCD people can derail forward progress

Perfectionists

People obsessed with process

We should not let the perfect be the enemy of the good

This perfectly describes Git developers, not me. I actually urge them very often to not let the perfect be the enemy of the good, they do the opposite.

I give you three examples:

1) The kind of patches that excite Git developers is for example "pack bitmaps" which reduced the load of Git servers, so it basically is totally irrelevant for users. This gets a "Woo-hoo" response from the maintainer. My patch to start moving to the "staging area", which is something all users would benefit from and desperately need. That doesn't get any traction at all.

2) A very very trivial patch to improve the defaults of 'git send-email' required endless discussions and a deep analysis, and even then it barely went through because a single person was adamant against change, even though I pretty much demonstrated nobody would be affected negatively. This is the kind of person they describe in the video as "poisonous" and yet he is basically #2 in the Git dev community.

3) A patch series to add the --except option for revisions, which was agreed to be a good feature ended up nowhere, why? Exactly the same reason the warn in the video; letting the perfect be the enemy of the good. Somebody wanted the feature to be fully designed before trying to implement the code, I already had the code that did what everybody wanted. Since nobody came up with a full definition, nothing moved forward. Paralysis.

I did exactly that, and after the break I decided to send my patches one more time, address the comments, and then fork, which is exactly what I did. What is the problem?

And for the record, I din't start the drama, I sent patches, and I replied to the comments. I stayed on the technical side and avoided personal confrontations. Sometimes people disagree, there's nothing wrong with that. It's not my fault that they don't like disagreement and started a drama about that.

Moreover in my announcement I did exactly the same thing, I avoided all the drama. In this thread I was merely clarifying the bullies vs. butt-hurt comment, if you don't like my clarification then just ignore it.

Did you actually looked at the patches? No? Then how could you possibly know if programming is for me? Do you judge people's ability to program based on what other people say about personal altercations you know nothing about?

Thanks for doing this. I love small enhancements like these, made by someone with good taste and an eye for detail. It's a shame that your patches are not getting merged. I hope that your fork takes off and that upstream gets the message. I intend to make the switch.

felipec I think you do great work and I hope you don't let all the haters put you down. Don't bother with answering everybody spewing negative comments. They are not necesserely representative of users of git or anybody else interested in git.

It is your code, do with it as you like. I will consider using git-fc. I can understand why people has issues with going specifically for ruby. But being practical it does make a lot of sense to me. When converting from messed up SVN projects to git I used a lot of ruby code. Mainly because a lot of the example code for custom stuff in git is written in ruby.

I also love lua, and might even think julia would be more awsome. But let us face it that ruby is pretty well known and has gotten a strong following for all kinds of DSLs. While lua is cool for scripting games engines it isn't that great as a generic scripting language which needs to do a lot of string manipulation.

So many people like this have invested a lot of their time and effort into learning git. So now they are trying to protect their investment by not switching to simpler but as powerful tools, like Mercurial. Instead they write wrappers and wrappers upon its interface in hopes of turning it into something usable.

No seriously, you seem to not know about the features git provides compared to e.g. mercurial

Like what? I hope you don't reply with a link to pro-git book or something like that. Because I have searched a lot to find one good reason worthy enough to adopt and learn the horrible thing that is git.

First off Mercurial is good, it works fine and you can use various extensions to customize it. It's CLI is pure bliss and makes a lot of sense. You can setup remote repository (on Windows!) easily.

Second, Git is great. It's more human to programmer and accepting that Hg's strict default tools. It's actually safer for data. You can commit horrible garbage and then prettify it later. It adapts to you, instead of other way around. That part is great. But Git's CLI is Bad. You can do stuff in several different ways, the commands have little rhyme or reason.

Mercurial is a sleek limousine that can't go off finely asphalted roads, while Git is an all terrain vehicle that can jump off cliffs and survive. Since my code is generally messy, I prefer Git for that reason.

I don't know if it's possible in hg, but in git he's probably talking about committing tens/hundreds of tiny commits that are broken and unfinished and using a rebase -i before merging the feature branch.

Here is a story of a programmer named Stanley. Stanely works at Indigo Soft with his friend Cuberick. One day after a long crunchtime Cuberick asks Stanely out on a few drinks. Happily, Stanely agrees to this arrangement and goes to a nearby pub. But since Stanely has alcohol tolerance of a tiny, church mouse he gets drunk after a single pint of beer.

Several hours later, with a screeching headache Stanely realizes that in his drunken state he has committed several rather nasty lines about his boss into the ReadMe.txt. To make matters more extraordinary intermingled with those foul words about his boss, are commits on some stuff he did on ReallyImportantJavaFactoryClass.java which is important for his work tomorrow.

+1 for a great reply. But this should be a very easy operation in any DVCS. you just have to

update to the last clean revision.

Then you can revert the files to any of the dirty revisions, make the necessary edits and commit the clean changes.

This will result in a new clean branch running parallel to the old dirty series of commits. After this, you can just delete the first dirty commit to completely get rid of the dirty series.

Using mercurial this would look something like,

hg update 'revison-number-of-last-clean-revision'

hg revert -all -r 'revision-number-of-dirty-commit'

Now you have all the files in the state they were during 'revison-number-of-dirty-commit'. Now you are free to remove any offending comments from any of the files and commit. You can do this for each of the dirty revision to obtain the series of clean commits.

I don't think you get what the fork is about, it's not a wrapper of any kind, it's git+extra-features.

Also, I've studied the differences between Mercurial and Git for years, I've put challenges to Mercurial users and developers and my conclusion is that Mercurial is simply not as powerful as Git, and nobody has provided evidence to the contrary.

Anyway, I do agree that Git's user-interface leaves a lot to desire, but I don't think it would be that hard to fix, and probably git-fc will head that way at some point, specially if more people start contributing. But Mercurial most definitely is not as powerful, and I don't see it becoming as powerful any time soon.

What ignorant bullshit. Mercurial isn't much easier at all, it's on the same level and has much more annoying quirks, particularly with setup and configuration. Stop spouting nonsense to feel superior. You might be too much of a simpleton to use git, but everybody else on this subreddit seems to be having no trouble with it.

When most people are happy with a tool and you aren't then it's likely you are at fault.

Many of us are only happy with git after weeks or months of slogging through documentation and Stack overflow questions trying to use it's terrible interface. Were it not for Github, I doubt many developers like myself would have made the effort to understand git when Mercurial is MUCH easier to use.

That said, I am glad I made the effort because git is awesome once you get past the steep learning curve.

The same argument can be made with languages too and the end result, if we follow /u/i_make_snow_flakes argument is that we only use PHP or some similarly "easy" language (I say "easy" since it's still full of massive pitholes).

Git has a steep learning curve because it's powerful and designed with CLI users in mind. Yes the CLI for Mercurial is slightly better, but the learning curve for git pays off fairly quickly. A GUI can also solve the problem for both of these tools for anybody who isn't willing to learn the CLI for either.

Python is an "easy" tool with a nice learning curve yet it remains powerful and productive for advanced users. The two characteristics are not mutually exclusive. Git's underlying technology is elegant and flexible but that's no excuse for the haphazard design of its CLI: just look at git reset command.

You are talking about a system that calls pointers to commits as 'Branches'. I am not trying to convert you to Mercurial. But please don't go about spreading the idea that the capabilities of git are unique to git only, and there are things git can do that other DVCS cannot do.