Hacker News Reader

Comment by anton_gogolev | Hacker News Reader

That would require a MAJOR MAJOR[1] version number increment because this change would break so much.

Looking at Git as it is now, I find it very unlikely to see a clean CLI in the nearest timeframe. Changes will happen (if they will) at a very slow pace.

[1]: http://semver.org/

View on HN

I'm not saying they should change the `git` itself. They could go with `git2`, `giit` or whatever else and just use new interface for common backend code.

Why "they"? Why not you? There have been other Git frontends in the past; why not write a new one that behaves as you'd like?

A number of reasons: Writing your own means dealing with changing internal behaviour. It means following changing output. It means not being able to reuse parts that already exist but are not exposed. It means deploying separate software where you don't necessarily have root/install rights.

Even if the interface you see as a user doesn't change, the internals do - for example submodules handling has been changed from a standard git dir to git file with directory link. This broke some of my scripts that made git interaction easier.

I don't want to slap something on top of git and hope that there are no edge cases in state/output parsing. I want an actual first-class interface that has at least a bit of consistency between commands.

As you can see, I went that way and it's not usable long-term.

Edit: changed symlink to git file, bad memory

I don't buy this. Give me some concrete examples of how internals need to change. I have lot of git scripts which work off git plumbing and they didn't require any of what you mention. You just sound like an armchair critic otherwise.

I gave one example already. The implementation of submodule .git directory changed (git-file instead of a directory). The change meant I had to check the git version and have two different ways of doing the same thing or the interface I wrote failed.

For an example of difference in output, see http://stackoverflow.com/questions/3921409/how-to-know-if-th...

"""As of git version 1.7.3.1, git status doesn't say anything about the rebase status.""" - so you're left with "does some file under .git exist" approach. It's unlikely to change, but I don't believe it's part of any external interface - when it changes in the future, it changes.

What does MAJOR MAJOR mean? I can't find it in the semver spec. They've changed the major version number - doesn't that mean they can change the API in any way they like?

MAJOR MAJOR is my very own invention and me being overly snarky. What I meant by that is that changing the CLI is a huge breaking change, and incrementing just the MAJOR component will not reflect the hugeness of what has happened.

And something like is announced waaay before it comes out so people are ready for it.

I feel like the addition of a SERGEANT version would be more appropriate.

Just because semantic versioning allows breaking changes doesn't mean Git SHOULD break compatibility.

Reply on news.ycombinator.com