Gitless: A simple version control system built on top of Git • Hacker News Board

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

#111

Post by maxxxxx » Fri, Nov 23, 2018, 3:26 PM UTC

jobigoud wrote: post #106

chousuke wrote: post #72

Earlier quoted context omitted.

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 p…

> I would hate to be restricted to a GUI tool to achieve what git add can do from the command line. I don't quite understand the use of the command line for git or hg. In my typical workflow before I commit I want to quickly review all the changes I just made. With the GUI you have a list of files and when a file is selected a diff of that file, without opening a new window. That means you can browse all the diffs in…

Sounds like how I work.

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

#112

Post by maxxxxx » Fri, Nov 23, 2018, 4:05 PM UTC

qznc wrote: post #75

cyphar wrote: 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?

"The index is unnecessary complexity. Amend to commits instead."

How is that easier than the index and how do you undo changes?

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

#113

Post by maxxxxx » Fri, Nov 23, 2018, 4:06 PM UTC

bg4 wrote: post #77

It's amazing the lengths people will go to avoid properly learning something.

Because they have a lot of other things to deal with. I have enough other things I have to learn and I simply don't have the time to become a git expert.

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

#114

Post by amelius » Fri, Nov 23, 2018, 4:49 PM UTC

lm2s wrote: post #104

amelius wrote: post #103

My biggest problems with Git are that it doesn't handle large binary objects efficiently, and that it's difficult to treat multiple git repos as a single repo (useful for many things, including keeping versions coherent).

git-lfs doesn't solve the large binary issue?

It may, but it's a hassle to set up as it requires a separate server daemon (for which I don't understand the necessity, as a git repo itself can be stored on a server over ssh).

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

#115

Post by kurtisc » Fri, Nov 23, 2018, 5:51 PM UTC

Fins wrote: post #45

glitchc wrote: 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…

>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.

This is just 'your use-case is wrong'.

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

#116

Post by paulddraper » Fri, Nov 23, 2018, 6:02 PM UTC

theonemind wrote: post #41

paulddraper wrote: post #8

Earlier quoted context omitted.

I compare it to 10-15 years ago, when functional programming was rather rare. Mid-level OO programmers would complain it was confusing and unfamilar, whereas in reality has beautiful and simple concepts. Git's use of a DAG is confusing and unfamilar for many programmers, though in reality it's beautiful and simple.

The DAG is the easy part. I can understand perfectly well what I want to do with the DAG and have no idea how to get git to DO it.

> The DAG is the easy part.

Excellent. I responded to the comment that claimed "deep problems in its conceptual design".

> have no idea how to get git to DO it.

Yes, the ergonomics of git could be significantly better. Branches vs tags, manipulating local refs vs remote refs, etc.

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

#117

Post by Fins » Fri, Nov 23, 2018, 6:32 PM UTC

kurtisc wrote: post #115

Fins wrote: post #45

Earlier quoted context omitted.

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…

>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. This is just 'your use-case is wrong'.

Or maybe one needs to drink more kool-aid?

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

#118

Post by Fins » Fri, Nov 23, 2018, 6:34 PM UTC

bvrmn wrote: post #71

Fins wrote: post #45

Earlier quoted context omitted.

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.

Usually, VCS commands makes some sense (i.e. commit commits), which isn't always the case with Git. THere are only two version control systems where I ever needed to use commands, rather than being able to do what I need in GUI -- SVN (because it is crap and would corrupt repository all the time, and then you needed to fix it up by hand) and Git, because... well, because Git.

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

#119

Post by russdpale » Fri, Nov 23, 2018, 7:14 PM UTC

pytester wrote: post #105

deepspace wrote: post #31

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…

>I could never understand the complaint that Git is "hard to use". It uses horribly unintuitive metaphors and has weird cryptic methods for doing common, simple tasks that practically require the use of google unless you've memorized the UI. There's a reason that there is a plethora of wrappers around the system (most of them not very good, unfortunately :(). >In any case, we are supposed to be professionals. Complai…

The language is part of the reason its so confusing. Why is called a commit? Makes no sense and is confusing. The commands should be obvious by looking at it. Why does someone make a pull request? It seems backwards as people push to a repository.

And then there is all the flags. Why in 2018 are we not writing full words?

Linus is a genius, but he makes things that works for him and without much consideration for others. This is just human nature I think.

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

#120

Post by jnurmine » Fri, Nov 23, 2018, 8:36 PM UTC

russdpale wrote: post #119

pytester wrote: post #105

Earlier quoted context omitted.

>I could never understand the complaint that Git is "hard to use". It uses horribly unintuitive metaphors and has weird cryptic methods for doing common, simple tasks that practically require the use of google unless you've memorized the UI. There's a reason that there is a plethora of wrappers around the system (most of them not very good, unfortunately :(). >In any case, we are supposed to be professionals. Complai…

The language is part of the reason its so confusing. Why is called a commit? Makes no sense and is confusing. The commands should be obvious by looking at it. Why does someone make a pull request? It seems backwards as people push to a repository. And then there is all the flags. Why in 2018 are we not writing full words? Linus is a genius, but he makes things that works for him and without much consideration for oth…

The way I see it the Git nomenclature makes much sense.

You "push" to a repository, if it is yours, but you cannot just push to the repositories of others. You make a "pull request" for others to fetch changes from you.

Commit is a "commit" because you "commit a change" as in make something new which differs from the previous state.

"Rebase" just puts your commits on top of the other branch, using the other branch as a "base". (It helps to think of the graph structure)

"Branch" is a branch because what you have is a kind of tree of commits, often more or less a straight line if you've done it right (IMO), and when you make something to work with you deviate from this other history of commits by branching off from it.

I mean it is rather standard terminology, and most importantly, it makes sense. Don't get me started with e.g. Clearcase which frankly makes no sense and should be killed with atomic weapons from low Earth orbit (or any orbit as long as it does the job), just to be sure.

As for hard to use, I never understood this either... I usually use a handful of commands and get things done just fine. If I ever feel like absolutely having to use some kind exotic merge with --onto and looking up octopus merges and whatnot I am probably doing something wrong.

There are plenty of good Git resources available, for example https://git-scm.com/