Live data from Hacker News

Gitless: a version control system

gitless.com

81–90 of 390 posts

Re: Gitless: a version control system

#81
post #49

Earlier quoted context omitted.

> What does it say when resolving these problems the easiest thing is to just reclone the remote repo? It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. The real reason people struggle with git, and I've seen this in many other programs/places is that they rely on discoverability and just randomly try commands until they work. Git's simplicity is it's downfall.…

> It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. This let's the design off the hook to easily. Yes, on the one hand this is a great feature, but on the other, you are deleting and restarting your workspace. It's not a great UX, it's just a simple workaround for a bad one. > - every engineer when first experiencing version control no, wrong. git is unique in t…

> no, wrong. git is unique in the amount of information that you need to know just to get started with it.

Have you ever worked with a different VCS? How is setting up subversion or CVS any more difficult than going

git init

git add .

git commit -m "initial commit"

Yes, truly a monumental barrier to entry to get started.

http://vasc.ri.cmu.edu/old_help/Archiving/Cvs/cvs_tutorial.t...

If you think git is unique in the amount of information it takes to get started... I pray you work on nothing that even broaches complex.

Re: Gitless: a version control system

#82
post #56

I highly recommend GitX-dev, which is a free, open-source GUI for Git on the Mac. https://rowanj.github.io/gitx/ The ability to stage/unstage individual lines using a graphical interface is really nice, and after some years using it I can't think me going without it anymore. Nowadays I only use the command line when I want to do interactive rebase.

Is there a better maintained version?

Re: Gitless: a version control system

#83
post #28

When people say they don't like git, I lose a little faith in them as a programmer and/or engineer. This is probably due to my own biases of having worked with folks that just don't want to invest the time in learning it. That or they are afraid of branching/merging. To me this indicates intellectual laziness which isn't the kind of laziness that makes a good programmer (as is with the quote from Larry Wall and the k…

I like git a lot and wish everyone standardized on it. I use the CLI almost exclusively but from my perspective it's terrible: cryptic and very inconsistent.

Looking back at my RCS history (RCS->VSS->MKSSI->CVS->SVN->git) I have to say that all of them were either hard to use or plain bad (VSS).

The problem RCSs are trying to solve is hard, that's why the tools are simultaneously indispensible and frustrating.

Re: Gitless: a version control system

#84
post #56

I highly recommend GitX-dev, which is a free, open-source GUI for Git on the Mac. https://rowanj.github.io/gitx/ The ability to stage/unstage individual lines using a graphical interface is really nice, and after some years using it I can't think me going without it anymore. Nowadays I only use the command line when I want to do interactive rebase.

I knew that you can already interactively stage individual lines via the command line using git add -p, which is what I use. But you mentioned unstage as well which I've never done before, so I looked it up. Looks like if you want to do that on the command line it's git reset -p

Re: Gitless: a version control system

#85
post #81

Earlier quoted context omitted.

> It says the git works really well because the CLI offers a simple way to "undo" any mistakes you've made. This let's the design off the hook to easily. Yes, on the one hand this is a great feature, but on the other, you are deleting and restarting your workspace. It's not a great UX, it's just a simple workaround for a bad one. > - every engineer when first experiencing version control no, wrong. git is unique in t…

> no, wrong. git is unique in the amount of information that you need to know just to get started with it. Have you ever worked with a different VCS? How is setting up subversion or CVS any more difficult than going git init git add . git commit -m "initial commit" Yes, truly a monumental barrier to entry to get started. http://vasc.ri.cmu.edu/old_help/Archiving/Cvs/cvs_tutorial.t... If you think git is unique in the…

> Have you ever worked with a different VCS?

Yes, I've worked with RCS, CVS, SVN, SourceSafe, Perforce and some others, though know them less well.

Git is bar none the best of all (of which I've had experience) the VCS' out there. I would pick it over anything else. The issues I'm pointing out are not because I don't use it, don't understand it, or don't appreciate it. I just believe that it's too complex.

If git was literally just the set of commands you listed, that would be great. As a single user experience it's hardly ever an issue. But that doesn't mean that it can't be better! And that's why I like this gitless project (and some of the other similar ones out there), it's trying to create a decent experience that will scale.

Also, your example is about creating a new git repo, I find this to be much more rare than getting involved in an already built and multi-member team, which may have all sorts of rules about proper merges or rebases, and such.

Re: Gitless: a version control system

#86
post #7

To me the really bad thing about git is its command-line interface. It has extremely verbose messages (writes out a lot of stuff that you don't need to know) and common use cases often requires multiple steps (ie. add, commit, push if you just want to send a change from your work machine a github repository). Compare this to subversion which is much less verbose, and in general just have one operation pr. use case.

The CLI is indeed hard to learn. But the simplicity of git is not using it, it's its internal structures: http://eagain.net/articles/git-for-computer-scientists/ If you understand these, then three stages to "commit to server" won't seem too many to you. (Often you don't need the index-building stage ("add"), and then you can say "git commit -a"). What people complain about is often the CLI's inconsistency. For examp…

You shouldn't have to learn how the data structures of the tool work beneath the surface to successfully know how to use a tool.

Re: Gitless: a version control system

#88
post #67
post #62

Earlier quoted context omitted.

Is there a gentle introduction, comparable to hginit.com for mercurial? When I first started version control I was trying to choose between hg and git. The site hginit was huge for getting me to swing towards hg.

https://www.atlassian.com/git/tutorials/ This is generally where I point people who have a technical background

Thank you.

Re: Gitless: a version control system

#89
post #81

Earlier quoted context omitted.

> no, wrong. git is unique in the amount of information that you need to know just to get started with it. Have you ever worked with a different VCS? How is setting up subversion or CVS any more difficult than going git init git add . git commit -m "initial commit" Yes, truly a monumental barrier to entry to get started. http://vasc.ri.cmu.edu/old_help/Archiving/Cvs/cvs_tutorial.t... If you think git is unique in the…

> Have you ever worked with a different VCS? Yes, I've worked with RCS, CVS, SVN, SourceSafe, Perforce and some others, though know them less well. Git is bar none the best of all (of which I've had experience) the VCS' out there. I would pick it over anything else. The issues I'm pointing out are not because I don't use it, don't understand it, or don't appreciate it. I just believe that it's too complex. If git was…

It can be though. That's like saying Linux would be better if they only gave you ls, cat and nano because vi, sed and xargs were too complicated.

There is nothing about gitless that provides a decent experience (compared to git) and certainly nothing about gitless that has anything to do with operating at "scale".

The truth is commands like filter-branch, rebase, cherry-pick, etc. which are notoriously difficult to use... you don't even have to use them.

I'm not saying the git experience can't get better, but the way forward is to modify the existing tools and contribute to the project, not make git wrapper number 84 that does nothing special.

Re: Gitless: a version control system

#90
post #51

Earlier quoted context omitted.

> You kinda deal with individual patches (commits) but not quite as prominently as in Darcs/Pijul. Darcs patches and git commits are markedly different. A git commit is a snapshot. A Darcs patch is a set of changes (that is, the difference between two snapshot). Any similarity necessarily comes from the ability to recover a snapshot from sets of changes, or deduce a set of changes from two snapshots. As far as I know…

I was referring to the fact that in git you can cherry-pick a commit as the similar mechanism.

Ah, such a misnomer: you don't cherry pick a commit, you cherry pick the patch that lies between the selected commit and its parent.

It may feel like nitpicking, but it's quite important when trying to understand the differences and commonalities between various version control systems.

Post reply on HN