Live data from Hacker News

Gitless: a version control system

gitless.com

21–30 of 390 posts

Re: Gitless: a version control system

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

I disagree. It's one of the best command line tools I've seen. It detects errors, gives you suggestions and you can get along with a few basic commands. Yes, there are multiple steps, but that's okay because it can't figure out your intentions.

Look: http://imgur.com/xY8dKWD no verbosity here and this is 99% of my git workflow. Working in a team is more tricky, but you should use and IDE with built in git support.

If you want to see a bad command line tool, try FFMPEG.

Re: Gitless: a version control system

#22
post #19

It does seem in some ways similar to Mercurial, but changes things which both Mercurial and Git share (like having to resolve tracked modified files before switching branches/bookmarks). I think if you want to make a fast and simple interface though, you should go a step further towards gui (like https://github.com/xixixao/hg-sl-up ) and remove the concept of branches/bookmarks altogether (I stopped using bookmarks i…

That sounds a lot like Darcs's model, which is pretty fun to play with (and darcs has a really nice CLI). You may want to take a gander at it.

Re: Gitless: a version control system

#23
post #4

> Gitless is an experiment to see what happens if you put a simple veneer on an app that changes the underlying concepts. ... changes them how exactly? A big part of what I like about Git is that its underlying concepts are simple and clear and feel like the right building blocks for version control. So I'm curious to know how they believe they can improve on that.

It's not a quick answer but they cover this in the Gitless vs. Git section.[0] One main difference seems to be with branching "The main thing to understand is that in Gitless a branch is a completely independent line of development."

[0] http://gitless.com/#vs

Re: Gitless: a version control system

#24
I wonder why there is no context-aware vcs; e.g. one that understanding the language and resolve diffs at a functional level. Would make change tracking and merging so much easier. Alternative would be to split each function into a separate file, for C# that would mean partials and the compiler just joins them.

Re: Gitless: a version control system

#25
post #19

It does seem in some ways similar to Mercurial, but changes things which both Mercurial and Git share (like having to resolve tracked modified files before switching branches/bookmarks). I think if you want to make a fast and simple interface though, you should go a step further towards gui (like https://github.com/xixixao/hg-sl-up ) and remove the concept of branches/bookmarks altogether (I stopped using bookmarks i…

That sounds a lot like Darcs's model, which is pretty fun to play with (and darcs has a really nice CLI). You may want to take a gander at it.

Or pijul.

https://pijul.org/

Re: Gitless: a version control system

#26
post #24

I wonder why there is no context-aware vcs; e.g. one that understanding the language and resolve diffs at a functional level. Would make change tracking and merging so much easier. Alternative would be to split each function into a separate file, for C# that would mean partials and the compiler just joins them.

Possibly because then you'd need a parser for every language someone might use.

But, since you mention C#, see: https://www.semanticmerge.com

Re: Gitless: a version control system

#27
post #11

Earlier quoted context omitted.

You can create aliases to execute multiple commands at once.

But why should each developer need to do that on each system they use? The whole point of this tool is to add a common set of things on top of git.

I don't see why each developer should. I'm perfectly fine with commands as they are by default.

I'm just saying that if your problem is that you need to enter multiple commands instead of one, then instead of new VCS you may as well just put a config file in your home dir.

Re: Gitless: a version control system

#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 kind of laziness he speaks of).

Re: Gitless: a version control system

#29
post #19

It does seem in some ways similar to Mercurial, but changes things which both Mercurial and Git share (like having to resolve tracked modified files before switching branches/bookmarks). I think if you want to make a fast and simple interface though, you should go a step further towards gui (like https://github.com/xixixao/hg-sl-up ) and remove the concept of branches/bookmarks altogether (I stopped using bookmarks i…

That sounds a lot like Darcs's model, which is pretty fun to play with (and darcs has a really nice CLI). You may want to take a gander at it.

git and hg are somewhere between Subversion and Darcs/Pijul. You kinda deal with individual patches (commits) but not quite as prominently as in Darcs/Pijul. It's all a compromise, and even Subversion gained merge features, leaning more into the git/hg realm. Tracking patches has huge advantages, especially in open source work, whereas it's not really needed if you just commit to master/trunk all the time and merge with a tool and not by tracking patches. Darcs and Pijul are what would be a perfect fit for the patch queue model used by kernel maintainers.

Re: Gitless: a version control system

#30
Very cool. The idea which I liked most, is the ability to switch between branches, even though you still have uncommitted changes. With git, I'm forced to either make an extraneous commit, just to enable branch switching, or stash all my changes into a stack which I may later forget all about. Both of the solutions above are really cumbersome and prevent easy context switching.

The only feature I noticed missing, is the ability to stash changes. I use this most often to move changes from one branch to another branch, without cluttering history with an extraneous commit. How would this work on gitless?

Post reply on HN