Live data from Hacker News

Gitless: A simple version control system built on top of Git

gitless.com

71–80 of 143 posts

Re: Gitless: A simple version control system built on top of Git

#71
post #45
post #23

Earlier quoted context omitted.

Yup, second that. My old boss introduced the whole team to Scala and made us attend a weekly tutorial as part of training/team-building. Since then, I try to write stateless functions, methods and objects as much as possible regardless of language or platform. Git is quite elegant if one has a good grasp of graph theory.

Git is certainly great technically. But one should not need to know graph theory to source control files. And I believe that any version control system that does not follow the convention (that probably predates Linus' existence on Earth) that commit should actually commit changes to server, is, by definition, more4 hard to use than it has any reason to be. But this might be a good study in why Linux is not taking ov…

> But one should not need to know graph theory to source control files.

You have two pills. Or you know few basic DAG concepts, or you need to know a lot of "semantic" VCS commands.

Re: Gitless: A simple version control system built on top of Git

#72
post #61

Earlier quoted context omitted.

Incremental staging of the next commit is absolutely a valuable feature. I'll often touch multiple files over the course of a few hours, sometimes for slightly unrelated changes, and then want to pull apart the changes into several smaller logical commits. Sometimes a couple hunks in a file might need to go into Commit A, while others go into Commit B. You can do piecemeal adding of hunks via the CLI, but the interfa…

You can get that kind of interface without a staging area. TortoiseHg would do it using Mercurial's shelving feature (similar to git stash) and IMO that was simpler to understand than staging. In particular, I liked that at all times there was a correspondence between the current working directory and what was being commited. It made it easier to run tests.

I would hate to be restricted to a GUI tool to achieve what git add can do from the command line. Using stashes would be just reimplementing the index using less convenient UI.

I really don't understand what's so difficult about the index... It's just the stuff you will be inserting into the repository when you next commit. Having it separated enables a very convenient workflow that would've required manually using patch and diff when using tools that don't support you.

Git is more than just revision storage. I like to think of code as clay, and the index as a tool you use to mould that into the final construct that gets baked

Re: Gitless: A simple version control system built on top of Git

#73
post #15

I must admit I'm a little bit confused. It opens with a discussion that people find Git hard to use, and a statement that these problems are likely more than skin-deep but then goes on to describe a wrapper around Git which is mostly a bunch of aliases. Don't get me wrong, I'm know that many people do find Git hard-to-use, but I don't see anything in the eventual project implementation which backs up the original cla…

Well I'm definitely not a git expert ( i guess I should just invest more time into it). But was wondering the other day. Isn't GIT "as good" as its(source control) going to get ? Giving the problem its trying to solve:source control,distributed teams/repo's, branching etc... I mean what comes after GIT ?

Re: Gitless: A simple version control system built on top of Git

#74
post #47
post #40

I feel like this is just another "git is hard so lets make it easier" program that makes collaborative development a pain. maybe its just my puritan work ethic. first we had git, and anyone who cared to spend the time could pick it up and understand it well enough to use it. Then we got github and gitlab, which made remote branches more manageable but introduced and entirely new class of developers who only added cod…

Git was not first, and it arguably didn't achieve its dominance based on technical superiority. It almost certainly didn't achieve that dominance based on offering a better learning curve or a bizarre interface choice, even though I might personally understand and appreciate the relative tightness to its underlying systems. I also don't think we should defend a technology or tool by portraying it as a sort of null-hy…

What do you recommend for simplicity on a distributed team (open source)?

Re: Gitless: A simple version control system built on top of Git

#75
post #15

I must admit I'm a little bit confused. It opens with a discussion that people find Git hard to use, and a statement that these problems are likely more than skin-deep but then goes on to describe a wrapper around Git which is mostly a bunch of aliases. Don't get me wrong, I'm know that many people do find Git hard-to-use, but I don't see anything in the eventual project implementation which backs up the original cla…

I'm now roughly one year into my experiment to not use the index. I made some aliases to do that. My conclusion is: The index is unnecessary complexity. Amend to commits instead.

My aliases do not work cleanly, so I don't want to advertise them. Still, a git wrapper which removes the index would be an improvement.

By the way, can we still call it "porcelain" or is that outdated?

Re: Gitless: A simple version control system built on top of Git

#76
This was bound to happen. The whole world moved to git without really understanding why. First we started to make "hubs" and bless their copies of the repo. Then people will start to strip and simplify git itself. Slowly but surely they will reinvent Subversion.

Re: Gitless: A simple version control system built on top of Git

#78

Earlier quoted context omitted.

I could never understand the complaint that Git is "hard to use". Having used a plethora of version control systems over many years, I never found Git to significantly more or less complicated than any other system. Version management includes many use cases, some of which are inherently complex. Therefore any version control tool must be able to perform both simple and complex tasks, and the latter ones will obvious…

Git, the version control system, is pretty simple. Git, the command line tool that helps manage repositories, is not.

Linus' power had lasted that much.

Re: Gitless: A simple version control system built on top of Git

#79
post #58
post #37

Earlier quoted context omitted.

You might not use it to do partial commits but many others do.

Don't partial commits run the big risk of commiting code that may not work, since the partial commit on your own computer will be tested against your working tree, wheras after it's committed it run with a different view of the files?

Not if you know what you're doing. For example, say you added a bunch of TODOs and FIXMEs you noticed in existing code while working on something. Now, you're ready to commit. The TODOs and FIXMEs don't necessarily correlate to the code changes you made. Should they all be committed with the code?

Using the index to stage and commit hunks separately lets you easily add and commit the unrelated TODO and FIXME comments separately from the code. A tool like Magit makes it trivially easy to do.

And since they're comments, they have no effect on tests or the code.

Re: Gitless: A simple version control system built on top of Git

#80

Earlier quoted context omitted.

I could never understand the complaint that Git is "hard to use". Having used a plethora of version control systems over many years, I never found Git to significantly more or less complicated than any other system. Version management includes many use cases, some of which are inherently complex. Therefore any version control tool must be able to perform both simple and complex tasks, and the latter ones will obvious…

Not everyone here is a 'professional' software developer. Git does have a steep learning curve. (I've used git extensively for years, just playing devil's advocate)

To reinforce your point - I have worked with people in the past, mostly older, that struggled a lot with Git when all they were trying to do was something simple like commit some static files generated from third-party software to my project. These people only needed the bare minimum (stage, commit, push) of Git yet found themselves baffled and fighting with the tool because of all the possibilities and things it could do that they didn’t really need.
Post reply on HN