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

121–130 of 143 posts

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

#121

Post by jnurmine »

dustfinger wrote: post #35

If anyone wants to know what it is like working with a "hard to use" revision control system then I highly recommend trying out IBM Rational ClearCase [1]. Or as I lovingly used to refer to it as Irrational ClearCase. To be fair, I have not used it since 2009, so perhaps it has been improved? If you use emacs and you find git difficult then please try out magit [2]. I actually really like the git cli, but I use magit…

Once upon a time, I remember having to use Visual Sourcesafe, and it started silently corrupting the repository after 2 Gb. Probably some length somewhere was a 32-bit signed variable.

I remember that the corruption was silent. That was bad. But nowhere as bad as Clearcase was in general.

Clearcase is like the bastard child of a barrel of horseshit and a mountain of self-inflicted hurt. One had to use "views" of which there were two types, and some kind of special mount point where the view loaded things from a source repository, given a "config specification" which defined from which versions (branches?) files should be loaded. Making a branch took a huge amount of time for a non-trivial source repository. It was "take a coffee" long time. Sometimes the views went bad. I don't luckily even remember all the problems, this was over 10 years ago.

The config specs seemed somehow to defy logic. Something always broke with them. Usually one just copied premade config specs made by someone with a transcended mind who seemed to have somehow figured out the underlying logic.

And... I can't just put to words how bad Clearcase was (is?). That is my experience with it, and I will without a doubt choose Git over VSS, SVN, CVS, RCS, Clearcase and whatnot any day.

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

#122

Post by brianpgordon »

bg4 wrote: post #77

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

I have a fairly advanced knowledge of git (that is, at the level of porcelain and plumbing commands; I haven't touched the C codebase itself) and I intend to give gitless a try when I get back to work on Monday.

My reason is that, while I'm a fan of git the technology, I think the default git CLI is an unmitigated fucking nightmare and I begrudge every neuron of space that I have to waste remembering how it works. Unfortunately, none of the graphical tools I've tried are as good. So I'm eager to try an alternative command line porcelain that's not so completely batshit insane. If it works out, maybe I can reclaim some of that wasted space.

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

#123

Post by bdavis__ »

dustfinger wrote: post #35

If anyone wants to know what it is like working with a "hard to use" revision control system then I highly recommend trying out IBM Rational ClearCase [1]. Or as I lovingly used to refer to it as Irrational ClearCase. To be fair, I have not used it since 2009, so perhaps it has been improved? If you use emacs and you find git difficult then please try out magit [2]. I actually really like the git cli, but I use magit…

it has not been improved or even updated in but minimal ways. i am surprised you did not experience the intellectual delight of using the ClearCase 'config spec' with it's ability to use rules to extract the source baseline you wish to work with. In all seriousness, it is very flexible and allows significant innovation in baseline management.

In 1995, it was state of the art and revolutionary. Today a bit clunky and off the mainstream. Compared to CVS it was a very sophisticated tool.

The 'visual tree view' it provides is still very good, even today.

(note: i don't really like it and will not mind changing to a different system sometime this century)

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

#124

Post by bdavis__ »

adrianN wrote: post #100
kruczek wrote: post #91

Earlier quoted context omitted.

I used ClearCase 3 years ago and this is spot on. ClearCase is little better than keeping revision history manually by zipping old versions of files. I sometimes wonder what kind of insane mind came up with its workflow. First of all, to checkout a branch, you don't simply select its name. You need to write a freaking configuration file to tell CC what you want to checkout. And it is entirely possible to accidentally…

The model is fairly similar to CVS, which also keeps histories of files instead of a history of the repository. The ability to have half of your repository come from one "branch" and the other half from a different branch is actually seen as a feature. This enables workflows similar to what you can do with submodules in git. Having to manage your config specs and the inability to go back to old versions of your softw…

You have to label (tag) every change or it would be impossible.

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

#125

Post by jnurmine »

oppositelock wrote: post #67
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…

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.

There's also "repo" from Google. And many other tools.

Git is not a panacea for bad design. If you have interdependent repositories (I read that the same as a cyclical dependency, A needs B needs A), then you should fix that first. I mean, if you have the described setup, you will have other problems too...

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

#126

Post by kernelpicnic »

Certhas wrote: post #82
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.

It's not. They removed staging and haven't implemented all the features and flags the git CLI has.

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

#127

Post by chousuke »

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…

I often find GUIs restrictive because they don't lend themselves well to ad-hoc scripting. I also don't use GUI editors, so that may be a part of it.

I can see how a TUI/GUI for being able to quickly stage things from the UI is useful, but it doesn't make the concept of the index useless on the command line either.

Using git from the command line is second nature to me at this point, and the index is a large part of my workflow. When I use git for revision control (as opposed to eg. Subversion. Or anything that doesn't have lightweight branching, something akin to an index, and rebases), it feels like the tool is helping me organize my commits instead of just being a place to shove things after I'm done coding.

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

#128

Post by chousuke »

quietbritishjim wrote: post #107
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 have a different workflow in TortoiseHg than ufo. In your terminology, I only consider revisions that have been pushed as being baked, while unpushed revisions are the clay. We already have tools to manipulate revisions, while the index, stash/shelve and patches are all just reimplementations of revisions with less convenient UIs. I just go ahead and commit whenever I like (without having to stage!), and sort it ou…

> Mercurial has a few properties that make this easier than in git. For example, there is no concept of detached head / garbage collection; when you save a commit, it is simply saved forever unless you choose to forcably remove it. (I have never found myself wishing for Git's refs and heads; they are just straight up unnecessary.) But I could imagine a git wrapper that had these properties too (e.g. when I checkout an old revision, it automatically creates a new branch with a special name that refs the commit I'm leaving behind).

I don't get it. What does mercurial have instead of refs?

HEAD in git is just one kind of a ref; differentiated from a branch only by when the tooling updates it (ie. when you create a commit in the checked out branch, or when you check out another commit)

"branches" are mutable references. "remote" branches are just refs pointing at the commit that was the remote branch the last time you fetched it to your local repository. They're all the same thing in the end, though.

The way Mercurial branches seem to be a special thing instead of a property of the structure of a repository is partially why I prefer git.

In git, the fact that a "named branch" is actually just a ref to a particular commit that gets updated occasionally makes perfect sense to me. The way mercurial does it has never clicked; why does a branch have to be something special?

I mean, in git, a branch that has no ref pointing to it is still a branch, but if you have no reference to a commit, why would its existence matter? Sure, you can end up "losing" commits when working with rebase, but no-one actually leaves their repo that way if the commit was important; you just look it up from the reflog and give it a name again, and it won't get garbage collected.

And after a branch is merged, why would you keep around a named reference to a branch head that no longer matters? IIRC mercurial has a feature to "close" branches, but I don't understand why that even needs to be a thing? In git, you just delete unnecessary branches (that is, refs), and you're done.

Maybe I misunderstand how mercurial works, but I've not found a source explaining the rationale behind why it works this way.

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

#129

Post by tedmiston »

dustfinger wrote: post #35

If anyone wants to know what it is like working with a "hard to use" revision control system then I highly recommend trying out IBM Rational ClearCase [1]. Or as I lovingly used to refer to it as Irrational ClearCase. To be fair, I have not used it since 2009, so perhaps it has been improved? If you use emacs and you find git difficult then please try out magit [2]. I actually really like the git cli, but I use magit…

ClearCase was my first VCS and I couldn't agree more. Compared to that nearly everything with git is easy and few things aside from complex merge conflicts / unstashing conflicts are difficult.

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

#130

Post by jnurmine »

brianpgordon wrote: post #122
bg4 wrote: post #77

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

I have a fairly advanced knowledge of git (that is, at the level of porcelain and plumbing commands; I haven't touched the C codebase itself) and I intend to give gitless a try when I get back to work on Monday. My reason is that, while I'm a fan of git the technology, I think the default git CLI is an unmitigated fucking nightmare and I begrudge every neuron of space that I have to waste remembering how it works. Un…

Can you please give an example of the things you mean?

Edit: wording.

Post reply on HN