Live data from Hacker News

Gitless: experimental version control system

people.csail.mit.edu

11–20 of 50 posts

Re: Gitless: experimental version control system

#11

In my experience, if you are to learn Git properly, you need to start off with a GUI. Some of the concepts behind DVCS, such as the DAG, merging, resolving conflicts, even the staging area, are much easier to understand when you can actually visualise them. I've found that people who try to jump in at the deep end with the command line sometimes don't understand Git as well as they think they do. These days I tend to…

I agree that visualisation is key, but ASCII art from `git log --graph` isn't too bad for getting the point across IMHO. Merging/conflicts/etc. are a straightforward extension of regular `diff` usage, which can be learned in a standalone way before approaching git.

Personally I'm in love with Magit which is a thin Emacs wrapper around git.

Re: Gitless: experimental version control system

#12
post #7

Git is pretty atrocious, so I like the idea here, but I'm not sure it goes far enough. My main complaints about git are probably having to commit changes manually (I haven't had to do this in Dropbox) terrible history and branch navigation (chrome does a better job and that's not even like an important feature of a browser) confusing command structure and options history rewriting and the resulting issues no merge to…

I wonder if there are any benchmarks or case-studies on very large git repos? Ideally you'd want to track (commit) every change to files and allow the user to place tags at certain places in the graph (similar to how commits are currently used) to represent aggregated logical changes. It would also be nice to have a visualization of the graph that could easily be 'seeked' through like a video. Putting this on top of…

Nice! Yeah that's along the lines I was thinking. There have been attempts at visualizations, like I remember clearcase had one that was probably pretty advanced 30 years ago.

I think it's very doable without any serious R&D, and you could build it on top of git/maybe github. The real question to me is: is it worth the effort, and would anyone actually pay for it.

People pay for tower and kaleidoscope so I assume it's possible. I think this is totally something GitHub should make but they seem to be focussing on other things.

Re: Gitless: experimental version control system

#13
I have waited for a form-fit time to ask if we can experiment with Git using Mercurial syntax as well.

While I have a feeling many would change Distributed Version Control System if there was immediately human translatable command knowledge between formats.

Begs a question of if many software libraries with their typed dictionaries could counter a built-in thesaurus for alternative tool chains, and end a war between literacy.

(What technical limits are aside from fighting for how to pattern match each element and differentiate what is integral to relate.. and committing that a base human localization.)

Re: Gitless: experimental version control system

#14
post #10

A lot of people want to use powerful tools but want it through an iPad-ish interface. If I'm using a space-rocket to get to the moon, I'm certainly going to learn how this shit is working and not fooling myself that if I just know what the buttons should do,I understand the system. GIT is marvelous if you understand the data-structures, people are too fixated on the commands and think everyone one of them is like mag…

Well, you can understand the data-structures and still not like git's interface. The data structures or your familiarity with the git internals don't change the fact that the CLI is annoyingly inconsistent. Learning more of internals won't save you from memorising which variation of the option is being used this time. For example:

    git remote add/rename/remove
    git add/mv/rm
    git tag /?/-d
    git branch /-m/-d

Re: Gitless: experimental version control system

#15

In my experience, if you are to learn Git properly, you need to start off with a GUI. Some of the concepts behind DVCS, such as the DAG, merging, resolving conflicts, even the staging area, are much easier to understand when you can actually visualise them. I've found that people who try to jump in at the deep end with the command line sometimes don't understand Git as well as they think they do. These days I tend to…

Whenever I've tried GUI Git tools I've always found them confusing than the command line Git In trying to be simple they often left me feeling powerless

Depends on the GUI tool. Some of them do over-simplify things, for example, by omitting the DAG view. This is misleading because it tries to make the source history appear linear when it isn't. GitHub for Windows and Visual Studio's source history both make this mistake, for instance.

Have you tried SourceTree? That's the one I tend to recommend these days. Alternatively, if you're prepared to splash out a bit, SmartGit is worth considering too.

Re: Gitless: experimental version control system

#16

As a novice git user, I can't really tell how Gitless is really different from Git in daily use cases. Any explanations?

Merges and simplifies a lot of common cases. For example, creating a new blank repo in gitless is:

    gl init
And getting a local copy of a remote repo in gitless is:

    gl init 
Whereas in git, it's:

    git init
and:

    git clone
Similarly, the operations to switch to (and create) a new branch, switch to an existing branch, and list branches, in git, is:

    git checkout -b newbranch
    git checkout oldbranch
    git branch
In gitless, its:

    gl branch newbranch
    gl branch oldbranch
    gl branch
Similarly, git has a somewhat complex situation where files can be staged, changed, tracked, and/or ignored; confusingly files can be odd mixtures of all four, and it can be quite hard to understand how to change the state of a file in some cases.

Gitless simplifies this a bit by removing the "stage", so files are either tracked, untracked, or ignored, with no ability to mix states. And instead of selectively staging changed files and then committing them in two separate steps (as you do in git), you stage and commit in one go.

Gitless is built on git; someone familiar with git can easily tranlate the gitless commands into the underlying git commands. It's not doing anything magic, but for day-to-day use the commands are probably a little more consistent and sensible.

Personally, my biggest pain point with git comes from managing complex branching situations; trying to figure when/how to merge, rebase, and cherry pick can be frustrating. Sadly, gitless doesn't (yet) help with this area.

(Short form: Gitless tries to make git's syntax simpler and more consistent.)

Re: Gitless: experimental version control system

#17

As a novice git user, I can't really tell how Gitless is really different from Git in daily use cases. Any explanations?

As an experienced git user, as far as I can tell s/git/gl ;-) I couldn't really see any differences at all from the documentation. Perhaps I missed something. An overview of the differences would be very nice.

The one thing that concerns me is the inclusion of rebase. If a wrapper is supposed to change difficult underlying concepts in git, why keep the most difficult concept: rebase. I like rebase, but for many common workflows you really don't want to use it.

Re: Gitless: experimental version control system

#18

Earlier quoted context omitted.

Whenever I've tried GUI Git tools I've always found them confusing than the command line Git In trying to be simple they often left me feeling powerless

Depends on the GUI tool. Some of them do over-simplify things, for example, by omitting the DAG view. This is misleading because it tries to make the source history appear linear when it isn't. GitHub for Windows and Visual Studio's source history both make this mistake, for instance. Have you tried SourceTree? That's the one I tend to recommend these days. Alternatively, if you're prepared to splash out a bit, Smart…

I use a combination of SourceTree and the command line for my workflow, and can heartily recommend it. Some operations are just more intuitive to me when using the GUI such as:

  - staging portions of many files scattered across a directory tree
  - quickly glancing over diffs for a given commit
  - understanding the commit graph and the relationship between local and remote branches
Each developer's experience may vary, but in general I feel like a good GUI tool can help a novice user develop and reinforce the mental model necessary to understand what git is doing. For example, what am I doing when I rebase my commit onto master vs merging it?

Re: Gitless: experimental version control system

#19
post #16

As a novice git user, I can't really tell how Gitless is really different from Git in daily use cases. Any explanations?

Merges and simplifies a lot of common cases. For example, creating a new blank repo in gitless is: gl init And getting a local copy of a remote repo in gitless is: gl init Whereas in git, it's: git init and: git clone Similarly, the operations to switch to (and create) a new branch, switch to an existing branch, and list branches, in git, is: git checkout -b newbranch git checkout oldbranch git branch In gitless, its…

Thank you so much. I think they should definitely put something like your explanation in their documentation to show the difference in a more expressive way.

Re: Gitless: experimental version control system

#20

Earlier quoted context omitted.

Whenever I've tried GUI Git tools I've always found them confusing than the command line Git In trying to be simple they often left me feeling powerless

Depends on the GUI tool. Some of them do over-simplify things, for example, by omitting the DAG view. This is misleading because it tries to make the source history appear linear when it isn't. GitHub for Windows and Visual Studio's source history both make this mistake, for instance. Have you tried SourceTree? That's the one I tend to recommend these days. Alternatively, if you're prepared to splash out a bit, Smart…

I do much prefer the command line (actually because of its simplicity and directness but that's just my perspective). However, having just trained a team on using git (yes they have only just adopted it!) and finding that the most confusing parts for them were the relation of the working copy to staging to remote then a GUI could have helped.
Post reply on HN