Live data from Hacker News

Gitless: a version control system

gitless.com

161–170 of 390 posts

Re: Gitless: a version control system

#161
post #115

Earlier quoted context omitted.

You have such a toxic and arrogant attitude about people trying to make the world a better place. It's shameful.

Uh, what? You respond to my post with some of the problems with this system in a hyperbolic, confronting manner without contributing anything. They are not "making the world a better place." Please don't post such non-sense here.

Someone makes a project trying to make something easier to learn (so, trying to make the world a better place), and you call it "extremely pointless", you tell them they "don't understand Git", they're "brain-damaged", "erroneous", they should "take the time to understand their tools", because the tools are "not complicated" and "incredibly simple".

Besides your arrogant "I'm right, you're stupid and wrong, and there's no questioning me" attitude, why would you take such a hostile tone towards anyone's work, ever? How could you think that's okay or constructive?

I'm hugely sympathetic to the opinion that Git is needlessly difficult to learn and needless easy to make mistakes in due to huge flaws in the CLI. I'd present that case, but, hey, it's presented a hundred times here and everywhere else. It's clear there's no point arguing that point to you, though, because I'd be stupid and wrong just for disagreeing with you. So instead I'm trying to convey that your arrogance is unacceptable in the community in the hopes that it will not reappear.

Re: Gitless: a version control system

#162
post #156

Earlier quoted context omitted.

How do you know that they misunderstand it, as opposed to disagree with it?

Please refer to the linked discussion.

Okay, I referred to it again. Still not seeing where you know that they misunderstand it, as opposed to disagreeing with it.

Re: Gitless: a version control system

#163
post #102

Git is, like many professional tools, something you simply got to learn. But like with many professinal tools, you don't need to know everything to get to work. I don't know all Photoshop or Ableton Live features, but I can improve my photos or create songs non the less. With these commands you can already start your own repo and work on it locally: git init // crate new repo git status // show which files are change…

I'm quite comfortable with git now but I also remember what a pain it was to learn. This included making mistakes and diving deep into git's internals to recover. The question is whether we should make things easier for new versus experienced developers? If switching to gitless became a thing I'd have to learn something new, but if it made things significantly easier for beginners, maybe my personal inconvenience isn…

Version control is arguably confusing for beginners, but building a shim instead of learning the tool isn't the answer in my head.

I always struggle with "lowering the barrier of entry" and it's not a "I did it they need too do it" it's more of a "Usually high barriers mean it's complex, and learning how to understand complex things is important."

If this was some new novel way to version that wasn't just pretty git, I'd be a lil more excited.

Re: Gitless: a version control system

#164
post #147

Earlier quoted context omitted.

As a tangent, I think calling git a distributed system is misleading. Git is primarily a history manager for a local directory tree that has commands to sync with remote machines. Having to type stuff like git remote add mothership ssh://foo@bar.baz git push mothership in order to sync is not what I usually associate with a distributed system. The word distributed conjures something that's more like dropbox, where th…

"Distributed" means something other than what you think it does. Dropbox is not a distributed system. In fact it is a good example of a centralised system.

[deleted]

Re: Gitless: a version control system

#165
post #134

Earlier quoted context omitted.

Let me just start by saying that while gitless seems fine, it tries to hide the index and thus encourages bad habits in git users. The index is by far one of the best features git has in comparison to other VCS, and trying to hide it because it can be confusing to users is doing them a disservice. EDIT: editing this to expand on why I think the index is essential: Being able to use the VCS tool to fashion a commit se…

> The index is by far one of the best features git has in comparison to other VCS, and trying to hide it because it can be confusing to users is doing them a disservice. I can't disagree more. The index is entirely unnecessary, as umpty thousands of happy Mercurial users can testify. > Being able to use the VCS tool to fashion a commit separately from what is in the worktree allows you to ... record states which neve…

Sure you can make do without the index, that doesn't mean it's better not to have it.

I personally don't feel comfortable with mercurial, but that may be because I don't understand it. It's been a long time since I last touched it, but I remember thinking that the way it does branches was just needlessly complicated and cumbersome. Why does closing a branch even need to be a thing?

> you don't need the index for this, you need to track conflict state

This is what the index does. You don't need the index in mercurial, because you have something that is like the index, but not called the index.

Maybe the UI is better because "add" is called resolve, but that is really just an alias away.

> and then ... what?

Then you push it to remote somewhere and a CI system runs tests for you. Maybe you can do something productive in the meantime.

If you're just testing locally, then there's little difference, but I would still prefer testing a committed state, knowing it's safe in the repository and I can't clobber it afterwards.

Re: Gitless: a version control system

#166
post #47
post #36

Earlier quoted context omitted.

I work with a whole bunch of scientists that program. Some mathematicians, some theoretical physicists. We run into git issues more often than we should. It's lazy to blame git issues on intellectual laziness. Any human designed system can be learned with enough effort but in git there seems to be significant superfluous effort. Effort that probably makes sense for some use-cases that git was developed for, but as it…

It's really not though. And posting articles that pretend like "git rev-parse --abbrev-ref HEAD" is the best way to view what branch you're working on just makes you look dumber than you do for acting like git is difficult to work with. If people writing blog posts about "how bad the git interface is" and more time instructing newer programmers (the only ones who have any reason to complain about git) on how to corre…

"It's really not though."

That's not an argument. Especially vis a vis the detailed reasoning behind gitless. In my view gitless has a superior experience without losing any power.

Also no one is comparing git to CVS/SVN. It can stand miles above these and still have severe usability flaws.

And I don't work with programmers.

Re: Gitless: a version control system

#167
post #9

It seems inspired by Mercurial?

Not really. Mercurial doesn't use `checkout` in that way (it's an alias for `update` which updates the working copy to a specific changeset — or the tip of the current branch, the hg version of TFA's checkout is `revert`), prints a list of revisions with `log` and uses `add` and `remove` to track and untrack files. It doesn't match Darcs's CLI either.

I meant more from the perspective that it wraps a more friendly CLI on top of a DAG of commits. Didn't mean that it's 1:1 copying Mercurial :)

Re: Gitless: a version control system

#168
post #163

Earlier quoted context omitted.

I'm quite comfortable with git now but I also remember what a pain it was to learn. This included making mistakes and diving deep into git's internals to recover. The question is whether we should make things easier for new versus experienced developers? If switching to gitless became a thing I'd have to learn something new, but if it made things significantly easier for beginners, maybe my personal inconvenience isn…

Version control is arguably confusing for beginners, but building a shim instead of learning the tool isn't the answer in my head. I always struggle with "lowering the barrier of entry" and it's not a "I did it they need too do it" it's more of a "Usually high barriers mean it's complex, and learning how to understand complex things is important." If this was some new novel way to version that wasn't just pretty git,…

It's like with IDEs.

Eclipse has stuff like workspaces with multiple projects and others have simply projects. What to do with these workspaces?

Same goes with Git. Simple VCS have central repositories and a working copy. Git has multiple repositories and every one of them can have a working copy. Other VCS don't have a stage, you simply commit your changes directly into your repository.

It's not only that these tools have different commands and stuff like Mercurial or Subversion has easier commands etc. but they really have different concepts that need to be considered while working with these tools on a daily basis.

But you don't have to internalize them on your first week or month working with them. When you got your project in the System it's mostly save and if you don't have complex workflows you can still reap the benefits of VCS with Git without knowing everything.

Re: Gitless: a version control system

#169
post #161

Earlier quoted context omitted.

Uh, what? You respond to my post with some of the problems with this system in a hyperbolic, confronting manner without contributing anything. They are not "making the world a better place." Please don't post such non-sense here.

Someone makes a project trying to make something easier to learn (so, trying to make the world a better place), and you call it "extremely pointless", you tell them they "don't understand Git", they're "brain-damaged", "erroneous", they should "take the time to understand their tools", because the tools are "not complicated" and "incredibly simple". Besides your arrogant "I'm right, you're stupid and wrong, and there…

>Someone makes a project trying to make something easier to learn (so, trying to make the world a better place)

Again, spare me the hyperbolic the "trying to make the world a better place." The principle behind my post, as given in my very first statement is that they basically failed. They are gearing people towards failure. It would have been better to just create a thin layer on top of git with slightly renamed or alias commands -- all while having "release valves" that guide you into the true, underlying community crafted toolset underneath that git has been using for years (and for very good reason). Any errors you're likely to come across while using git have been documented either by the team or in various posts around the internet. It's easy to search for these errors. If your target audience are developers who have a hard time with Git, why would you make it needlessly hard to research errors that are likely to happen (given how new this tooling is). For example: labeling rebasing as "fusing" is basically telling them: "haha, good luck googling what just went wrong!". Good luck hopping on an IRC or Slack channel and getting someone to help you. A decade of community problem solving and documentation just went out the window because the Gitless team decided to play musical semantics with commands.

>why would you take such a hostile tone towards anyone's work, ever?

Leave your ego at the door. We're talking about a toolset.

>Besides your arrogant "I'm right, you're stupid and wrong, and there's no questioning me" attitude

Please do not respond to any of my posts in this thread anymore, especially if that is the basis of this comment chain. That is a ridiculous sentiment and I'm not going to devote any effort into addressing it.

>I'm hugely sympathetic to the opinion that Git is needlessly difficult to learn and needless easy to make mistakes

I would strongly disagree about the "needlessly difficult" part, but I would also claim that the "easy to make mistakes" is demonstrably false with Git. Git makes it extremely difficult again to do something you should not be doing in the first place and then the community over the years has placed plenty of warnings when you do those questionable actions anyways; on top of giving you the ability to revert the mistake and bring your repository to a sane place with one simple command. Checking out branches with conflicting changes is just one of the simpler safety checks and roadblock that Git provides where Gitless decided to just go "Nah, you can actually do that." with seemingly no apology as to why you would ever want to allow such a thing -- other than just for the sake of convenience, but I would label it as laziness as it makes it incredibly easy to pollute your repository at that point. It doesn't even provide any kind of warning mechanism or cleanup tool for this handy "feature."

>So instead I'm trying to convey that your arrogance is unacceptable in the community in the hopes that it will not reappear.

The only thing worse than calling me arrogant is your complete, unconstructive obliviousness towards your own attitude. Not only have you still failed to say anything worthwhile or present any kind of counter to my opinion, but you're being a complete dick about it and trying to label me in a negative light for no reason. Which ends up really at the end of the day making you a troll at worst and a hypocrite at best.

Re: Gitless: a version control system

#170
post #163

Earlier quoted context omitted.

I'm quite comfortable with git now but I also remember what a pain it was to learn. This included making mistakes and diving deep into git's internals to recover. The question is whether we should make things easier for new versus experienced developers? If switching to gitless became a thing I'd have to learn something new, but if it made things significantly easier for beginners, maybe my personal inconvenience isn…

Version control is arguably confusing for beginners, but building a shim instead of learning the tool isn't the answer in my head. I always struggle with "lowering the barrier of entry" and it's not a "I did it they need too do it" it's more of a "Usually high barriers mean it's complex, and learning how to understand complex things is important." If this was some new novel way to version that wasn't just pretty git,…

I think there's a difference between learning something that's necessarily complex and learning something with an overly complex design. According to their analysis, the design changes they've made do away with unnecessary complexity.
Post reply on HN