[Tobu]

I've started the thread on Linus's first reply, and the guy is completely unconvincing. He was after a quick feature improvement (I don't really know what but Linus seemed to) and implemented it, but he gave little thought to the overall design (either his or Git's).

Big meh, and I'm normally interested in the evolution of Git.

[tinco]

I don't know man, anyone who uses gitmodules knows that they are a pain and really unlike anything else in git. This guy had an idea on how to improve it, introduce a cool new basic object type to git and he even wrote a PoC, I'd say hats off to that.

Linus makes a rather unconvincing argument against the system, saying the current system allows for submodules be different for local sites. As if the proposed system would not support that, and as if the current 'dirty submodule' system is a better solution. He's being an absolute moron.

And Junio is just being very unproductive, he seems fully incapable of inducing anything from the design Ramkumar proposes and fails to see implications that anyone could see, even though he is a core git guy. And frankly he's being an ass too.

What I see is someone enthousiastically trying to fix a core problem of git in an ambitious but well constructed way, and a bunch of old guys just bashing the life out of him.

I think he's better off just not asking Juno or Linus for advice and just keep on hacking on his fork. I know I would use it.

[snprbob86]

> just keep on hacking on his fork. I know I would use it.

Correct me if I'm wrong, but isn't the problem that Linus brought up this: If you introduce a new object type, you need to get it right. A new object type would create non-backwards-compatible repositories, so you'd have a new minimum Git version. If you were to use this fork, then everyone who checks out your code would have to use it. Also, it would preclude tooling support (eg GitHub). Once such important repository versioning decisions are made, they can't be unmade. Git, at it's core, is basically just a well designed repository model.

[tinco]

Yes, precisely :)

[Tobu]

He's not the only one working on this. But he doesn't have the skills to defend his ideas (it might be just communication skills, it might not). As it is he won't be able to make the big revolutionary step the patch was promising.

If he had been making his own VCS he wouldn't need this kind of review, but Git is an agreed-upon format and protocol; it is absolutely necessary to start by considering the downsides when core changes will affect a large user base.

[kelnos]

Linus makes a rather unconvincing argument against the system, saying the current system allows for submodules be different for local sites. As if the proposed system would not support that, and as if the current 'dirty submodule' system is a better solution.

Yes! And in the next breath, Linus flat-out admits he doesn't know if anyone uses/keeps a dirty local .gitmodules file. A great example of being out of touch with your users and still thinking you know best. Arguing to keep a (IMO minor & weird) feature around without knowing if anyone even uses it is folly.

I think he's better off just not asking Juno or Linus for advice and just keep on hacking on his fork. I know I would use it.

If only it were that easy. His changes would create a git implementation incompatible with everyone else's.

[kzrdude]

Linus' first reply just laid bare that the object format matters much more than the implementation around it. That's how git got as far as it did until now, by using a sound data model.

[kelnos]

Then you missed his earlier emails that explicitly acknowledge that the code he wrote is not at all intended to be mergeable and is just a proof-of-concept.

He also, in the thread, explicitly acknowledges that he's not sure about the best design and asks for help.