Live data from Hacker News

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

gitless.com

61–70 of 143 posts

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

#61

Earlier quoted context omitted.

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.

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.

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

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

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

#63

Git with a veneer on it, that if there are problems you can revert to git-proper... How is that different from Git Desktop?

You don't leave the command line

> You don't leave the command line

An advantage of gitless on one side, a statement about how to live life on the other side.

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

#64
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?

In reality I use it to do partial stashes more often than partial commits.

That said, you could extend your argument such that you should always commit every touched file but that would be awful.

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

#65

Earlier quoted context omitted.

It is common for me to have miscellaneous changes I don’t want to commit, but I think this is problematic on my part, and I shouldn’t typically be doing it. The only defensible version of this I can think of offhand is changes that are necessary to get the repo to work in my local, but which I am not yet able or willing to commit and push.

You can always use the stash for changes like this.

It depends. If you have, as we do at my work, a pre-commit hook that runs acceptance tests on each commit, and if the changes you've made are to get it to work on your local, then leaving those changes in for the test run is really the only option.

Should I get those changes committed? I should. But that involves a lot more testing and thought, since it still has to work for other people with different local dev setups.

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

#66
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…

Git did beat both of the other main contenders in the DVCS space (Darcs, Mercurial) hands down when it came to performance around the time it rose to prominence, so I think it's unfair to say that it had no technical superiority.

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

#67
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 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…

Try managing a massive set of inter-dependent repositories too big for a mono-repo with git, then you will know "hard to use". Your only real choice in this case is submodules, and those bring in an additional layer of pain.

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

#68
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…

In my own experience, https://www.sbf5.com/~cduan/technical/git/ makes all the difference in this world. The main complaint still remains: the CLI UX (yes, CLI has a user experience!) is really bewildeirng because switches change commands in really, really significant ways, so much so they ought to be different commands. And operations have totally different ways to express "work with repo only" "work with index" "work with working tree". And then git reset does not touch your working files but git reset --hard ruins your day unless you build a safety net: https://gist.github.com/chx/85db0ebed1e02ab14b1a65b6024dea29

Back to the tutorial:

> you can only really use Git if you understand how Git works. Merely memorizing which commands you should run at what times will work in the short run, but it’s only a matter of time before you get stuck or, worse, break something.

> Half of the existing resources on Git, unfortunately, take just that approach: they walk you through which commands to run when, and expect that you should do fine if you just mimic those commands. The other half does go through all the concepts, but from what I have seen, they explain Git in a manner that assumes you already understand how Git works.

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

#70

Earlier quoted context omitted.

The other half of the issue is that git's commands don't follow the abstraction. If each command mapped to a single dag operation, it might make more sense. But they don't (revert).

They shouldn't. I'm not saying that Git doesn't have commands that can be hard to understand fully, but the whole point of any abstraction is to hide the "insides" of any operation so you don't have to think about them. Having commands for each DAG operation will just add more complexity and expose a structure which you shouldn't be handling manually.

I think in order to really feel comfortable with Git you have reverse that and think about the DAG as the actual interface and the CLI as the clunky implementation you use to modify the DAG.
Post reply on HN