Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

gitless.com

Post reply on HN
Print view View original

81–90 of 143 posts

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

#81

Post by kreetx »

black-tea wrote: post #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.

Does gitless really achieve the depths of subversion? Judging by the command list it looks like to add more easily understandable commands, some maskin the originals, ethers doing something more elaborate without requiring the use of flags, etc.

(I'm definitely not going to start using this since I already know the real git, but I can understand where it is coming from)

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

#82

Post by Certhas »

black-tea wrote: post #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.

gitless is just as expressive as git though. It's just a better interface with less state. Nor is it new. Check out their research paper.

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

#83

Post by Certhas »

saagarjha wrote: post #49
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…

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

Which is why I like gutless. Same VCS, sane interfaces, less state to juggle.

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

#84

Post by reacweb »

sigsergv wrote: post #62
hackpr wrote: post #3

Yes. Git is powerful, but sadly has deep problems in its conceptual design. This is the reason why even mid-level engineers don't understand it fully. Love this work!

Git design is surprisingly clean and simple. The main issue of git is its CLI and commands naming. They are indeed unclear. But again, concept behind is absolutely amazing. You just need to understand that git repo is a series of snapshots and after that all other details become clear.

Naming is difficult. Good names suggest the right metaphore to understand something. But for git, there is nothing similar in physical world. "push" "pull" and "merge" seem ok, but even "branch" is an original concept different of its usual meaning. Maybe git should have used non english words to avoid confusion.

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

#85

Post by apichat »

pantalaimon wrote: post #26
apichat wrote: post #18

Earlier quoted context omitted.

I think that you can find good explanations of these problems here : https://jneem.github.io/merging/ https://pijul.org/model/#why-care-about-patch-theory Unfortunatly Gitless doesn't solve them. But Pijul solve many problems of Git (and Darcs) and is easier to use. https://pijul.org

It appears as https://nest.pijul.com/pijul_org/pijul is currently being hugged to death?

It's ok now. They published a new version of Pijul and it seems that it cause some problems.

https://pijul.org/posts/2018-11-20-pijul-0.11/

https://pijul.org/posts/2018-04-21-pijul-0.10/

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

#86

Post by Certhas »

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

Gatekeeping much?

Funnily enough your complaints also completely ignore what gitless actually is. It does not hide the underlying git structure, it just exposes it in a sane way. Check out the research papers. It's really well thought out. Same power with less exposed state is to me the definition of good software design.

I don't teach gitless to novices because all the rest of git tooling uses the original git vocab. Unfortunately we seem to be locked into using the bad interface design of the original git forever and ever, along with the chorus of people who claim it's perfectly intuitive (once you spent a few thousand hours debugging user errors).

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

#87

Post by Certhas »

chousuke wrote: post #72
ufo wrote: post #61

Earlier quoted context omitted.

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

It makes sense as a tool that should be available. It does not make sense as a default hoop everyone has to jump through. The way that stash, index, working directory and branches interact is completely non-obvious and induces a lot of accidental complexity

As far as I can see the use case you describe is actually covered in gl commit.

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

#88

Post by cyphar »

rawoke083600 wrote: post #73
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…

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 ?

There are some projects that aim to improve the merging model of Git, such as pijul[1]. Git uses "three-way merge" and it is fairly well-known that the repository state you end up with for non-fast-forward merges (merges that need merge commits) is not necessarily well-understood in all cases. Pijul uses a more efficient algorithm that has well-understood merge characteristics, and is designed around patches not repository states (which means that conceptually patches are the core -- rather than in Git where patches appear to be core but are actually all generated on-the-fly).

It should be noted that Git was not unique in its design. There were many source-control systems that had the same model that pre-dated Git, it's just that Git was fast and significantly easier to use than the other tools. The previous tools would not have been usable for developing Linux, and so Git was obviously necessary.

[1]: https://pijul.org/

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

#89

Post by cyphar »

davnicwil wrote: post #33
maxxxxx wrote: post #9

Removing staging seems a little odd. To me staging, especially with a GUI like Sourcetree, is almost the best part of git.

Curious as to why - What usecases do you have for staging? Why does sourcetree make it better? To me it's just an inconvenience and a redundant step on the way to committing stuff. I get that you can use it for partial commits of in flight work but that's never something I've needed in practice. Usually I just want to commit everything I'm working on at once.

What is the redundant step? Do you not use "git commit -a" -- or does it not work in certain cases?

Staging is quite useful if you want to create several commits (perhaps fixup commits, perhaps whole commits) based on the current repository state. This is why you can do "git add -p" to add parts of files to staging.

You mentioned later in the thread that you prefer stashing -- but Git doesn't let you stash certain files (you have to stash the entire state), and in addition stashing has a much more awful UX than commits (it's represented as a stack which means you have to pop elements off it -- and you've then lost that stack entry and you can't pop the stack with uncommitted changes). If there is one aspect of Git's UX that needs to be massively redesigned it would be "git stash".

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

#90

Post by cyphar »

Certhas wrote: post #87
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…

It makes sense as a tool that should be available. It does not make sense as a default hoop everyone has to jump through. The way that stash, index, working directory and branches interact is completely non-obvious and induces a lot of accidental complexity As far as I can see the use case you describe is actually covered in gl commit.

"git commit -a" will skip staging entirely if that's what you'd like to do. Should "-a" have been the default? Maybe, but that doesn't mean that you can't use it.

Now, if you want to exclude certain files from a commit I will freely admit this is a pain. The easiest way, especially if you have loads of untracked files you don't want to commit, is to do:

    % git commit -a && git reset HEAD~  && git commit --amend
Which is pretty awful, I will admit. I had an alias to do this a while ago (without the need to amend the commit) but it wasn't great fun.

However staging is still a useful concept, and "gl commit" as far as I can tell doesn't really allow me to do something I do quite often ("git add -p" to add partial hunks of a change to staging for a commit). I recognise that I'm probably in the vast minority (outside of the kernel community) when it comes to my Git usage, but staging is definitely quite important for some Git usecases.

Post reply on HN