7 ms·

Gitless – An experimental version control system built on top of Git

42 points by mseri 12y ago

zatkin 12y ago
I don't understand the difference between this and "alias gl=git" in a bash config.
- Guvante 12y ago
  Implicit index and renaming several things to try and be more consistent.
chousuke 12y ago
This seems blog fails to convey the why of gitless. It looks like a very thin veneer that's trying to hide the index, which I think is a really bad idea. The index is one of the two main reasons I prefer git over mercurial. The first paragraph says that git has usability issues, but no attempt is made to explain the reasoning and convince the reader that gitless solves these. I also have a UI nitpick: long parameters should have two dashes instead of one so that short parameters can be freely combined; switches like -exc, -inc and -su go needlessly against common convention. You should also not do such arbitrary truncation... --exc and --inc match --exclude and --include unambiguously, so you get shortened forms for free if you simply do a prefix search.
- adekok 12y ago
  The index seems to be a git-only feature. It's one of those concepts that's so simple, it makes you go "Why the hell didn't I think of that?" The index allows you to have partially staged commits. This is most important during merges. The merged changes are staged. The unmerged ones are left in the file system. So the diffs are small. Every other VCS I've used doesn't handle that case. Merge conflict? Here's a 2000 line diff, of which only 2-3 lines are in conflict. Where are they? Have fun finding them! Arg. Hiding the index makes git easier for newcomers. It also hides a new workflow, unique to git. That workflow is better and more efficient than the ones for other VCS.
  - rbehrends 12y ago
    > Every other VCS I've used doesn't handle that case. Merge conflict? Here's a 2000 line diff, of which only 2-3 lines are in conflict. Where are they? Have fun finding them! I am not sure what you're talking about. Every semi-popular VCS I know of allows you to differentiate between files with and without (or with resolved) merge conflicts. Examples (in alphabetical order, because people can get religious here, and I don't want to appear to favor one over the other): Bazaar: Integrated in bzr status and also available as a separate bzr conflicts command. Fossil: Part of fossil status and fossil changes; will display files with conflicts with a CONFLICT rather than EDITED marker. Mercurial: Here, hg resolve --list or hg resolve -l will list merged files, both resolved snd unresolved (marked with R and U, respectively). Monotone: Monotone has mtn show_conflicts and mtn conflicts show_remaining and in general a fairly sophisticated (or complicated, depending on who you ask) set of commands for analyzing and resolving merge conflicts [1]. Subversion: Conflicts are marked with "C" in svn status. (I've excluded Darcs, which has a model that's quite different from the traditional merge command, but for the same reason has fairly extensive machinery for dealing with conflicts, for better or worse.) [1] http://www.monotone.ca/docs/Conflicts.html http://www.monotone.ca/docs/Conflicts.html
    - david-given 12y ago
      Is the git index just a changelist? (Genuine question --- I've never been able to get my head around what it's for.) Most VCSes support these, even Subversion.
      - rbehrends 12y ago
        Not quite. The git index (also called staging area) is basically the schedule of changes that are to make up the next changeset once you hit "git commit". This is actually why I consider the index an anti-feature. It not only allows you to do partial commits (practically every VCS does), but encourages it and there's a good chance that you may do it wrong by accident. This can result in broken revisions (because you're committing a state that may have never actually existed on your disk, let alone did compile or passed tests) and create problems for anything from "git bisect" to nightly builds. The proper way, as far as I'm concerned, is to do the inverse: use "git stash" instead to remove all changes that you do not need, then compile and test what is in your working tree and only then commit the tested version. Afterwards, apply the stashed changes to get the working tree back to its original state. This way you can minimize the risk of broken commits.
err4nt 12y ago
I think the problem with a lot of User-Interfaces for Git (whether GUI or TUI) is that they rename or 'hide' the Git terminology from users. You still need to know Git to operate the UI, but you often have to learn how Git concepts and terminology map to the UI's terminology. Here are the commands I use with Git, they're not that different: - git co branchNameHere - pull - git st - git add -all - git commit -m "Message here" - git push I am not sure where Gitless would save me time based on what I'm seeing, it looks like a simplification of Git. What might save me time would be more features for managing and applying stashes from the command-line, or making it easier to check the changes I've made (git diff). Here is my all-time favorite Git command, and I've created an alias called 'showtree' for it, but it helps me to understand where different branches are: git log --all --graph --decorate --oneline --simplify-by-decoration
- lsjroberts 12y ago
  I think you might like tig - https://github.com/jonas/tig https://github.com/jonas/tig - it provides a more interactive version of your showtree command
mbil 12y ago
It'd be nice to see, for some of the most common version control tasks: 1. The common version control task (e.g. make a new branch and switch to it) 2. How it's accomplished with Git (e.g. git checkout -b my_new_branch) 3. How it's accomplished (ostensibly more easily) with Gitless (e.g. gl branch my_new_branch)
jobvandervoort 12y ago
I'd love to see something that makes git easier to use. Gitless does not make it clear to me how to work with it in only a handful of sentences. By that measure, it doesn't seem easier than git. You say: " We think the problem lies deeper than the user interface, in the concepts underlying Git" But it seems to me that you just rely on the same concepts, but rename them or do nothing at all with them. One of the concepts underlying git is a history made of unique deltas that can be referred to at any point in time (+ some change). It'd be cool if you made it easier to navigate or make those unique deltas (commits), rather than put a thin wrapper around them.
- e12e 12y ago
  > I'd love to see something that makes git easier to use. I'm not really aware of any problems with mercurial's git-support[1]. It might not really be "working with git", but does support working with (as in pushing and pulling) git repos. And while I think there'll never be a consensus on mercurial versus git -- I find that the interface is much cleaner in mercurial, than with git. So if by "easier" you mean "easier command line use", I think mercurial is worth a look. If not, perhaps look at various guis -- but I've not got any experience with them. hg help git Working with Git Repositories """"""""""""""""""""""""""""" Basic Use --------- You can clone a Git repository from Hg by running "hg clone <url> [dest]". For example, if you were to run: $ hg clone git://github.com/schacon/hg-git.git Hg-Git would clone the repository and convert it to an Hg repository for you. (...) If you are starting from an existing Hg repository, you have to set up a Git repository somewhere that you have push access to, add a path entry for it in your .hg/hgrc file, and then run "hg push [name]" from within your repository. For example: $ cd hg-git # (an Hg repository) $ # edit .hg/hgrc and add the target Git URL in # the paths section $ hg push [1] http://hg-git.github.io/ http://hg-git.github.io/
  - david-given 12y ago
    Unfortunately, it's not quite that easy --- to be able to push, you need git+ssh, and I've never made that work with github (it just hangs saying something about git-upload-pack), and it doesn't seem to help you with some of the more horrible git interactions, such as doing a pull from upstream to your forked github repository. (And I suspect that if I could do that reliably I would have internalised enough git to use that natively.)
shreve 12y ago
Why can't we all just admit that git is terrible software and move on?
- tree_of_item 12y ago
  The same reason we can't just admit that JavaScript is a terrible language and move on: network effects.
- balabaster 12y ago
  Git isn't really terrible software. Git is really powerful and quite brilliant in many cases. However, the user experience sucks. Sourcetree went a fair way to take the pain out of it and have largely done a reasonably good job. Again, it has its shortcomings, lord knows we could do with a nice easy wrapper that takes the sting out of nagivating Git and walking us through the work flow better than the current system. If you wanna drive stick, you've gotta learn how to use a clutch and gearshift. You can't expect all of the power without being willing to put in some sweat equity to learning it.
  - shreve 12y ago
    TL;DR: Git really _is_ terrible software. You're defending VCS in general. Git is a single VCS implementation, and a shitty one at that. Git is hacked together from C, Shell, Tcl (which tbh, I've never even heard of), Python, and C++. Mercurial, by comparison, is Python and C. Git has an awful UI out of the box. Why? There's no reason other than fuck you. Mercurial's UI out of the box is similar to every project that has tried to make Git easier to use. It's for _people_ to use, not Linux kernel developers. [Humor on this topic: http://homes.cs.washington.edu/~asampson/blog/git.html http://homes.cs.washington.edu/~asampson/blog/git.html] Git's documentation also sucks. Suppose you don't understand rebasing. Try running `git help rebase` and you'll get this back: "git-rebase - Forward-port local commits to the updated upstream head". WHAT THE FUCK DOES THAT MEAN? Another example: `git help push` returns "git-push - Update remote refs along with associated objects". Why is this so goddamn complicated? It's almost like it was written by developers that have no idea what it's like to not understand how git works. Oh wait. Mercurial on the other hand, has simple explanations at first, with more in-depth explanations if you look further. `hg help push` returns "push changes to the specified destination". Which is how someone would explain VCS pushing to another human being. Linus Torvalds isn't running `git help`, people that don't understand git are. Documentation should be written for them.
StavrosK 12y ago
I don't understand all the criticism here. Personally, I don't like and barely ever use the index, I think that git is completely inconsistent with itself, and find the design of gitless very consistent and easy to use. I saw it the other day and learned to use it with only a page's worth of reading. Why are so many people confused?
- scrollaway 12y ago
  > I don't understand all the criticism here. Okay. > Personally, I don't like and barely ever use the index And there's why. A lot of us actually like and use the index a lot. It's incredibly powerful; one of git's most powerful features in fact.
  - StavrosK 12y ago
    You took one of my points and used it to dismiss my entire post. How does my not liking the index nullify the fact that git is entirely inconsistent?
    - scrollaway 12y ago
      Sorry, I did not mean to dismiss your entire post. Your wording suggests that you don't understand the criticism and confusion, but 90% of it in here (at the time of this writing) is due to the index being removed which is just: "wtf?". I agree that git is insanely inconsistent. I could talk about this for hours. I'd love a better porcelain. But gitless is removing some pretty critical stuff here. On the positive side, I really like the rest of their UI. I especially like the usage of "track" and "untrack" as core words.
      - StavrosK 12y ago
        Some of the criticism is about the index, but most of the rest seems to be "why gitless?" and "how do I use it?", which are pretty well covered in the docs, I think. I agree with you that the removal of the index was a bit orthogonal to the end goal of making gitless more consistent. I do agree with their decision (because I don't find the index that useful), but you're right in that they dumped the baby out with the bathwater by going with simplicity rather than just consistency.
jacobsimon 12y ago
I don't think I'd be able to live without "git add -p"
- tokenrove 12y ago
  Seriously. I can't even contemplate what life would be like without it. (And, particularly, magit's interface for it in emacs)
vasco 12y ago
Git is so powerful and complex. I do agree that the user interface is poor and most of the arguments I've heard in favor just sound like the person already invested a great deal of time learning, and so won't accept change. A great coat on top of a powerful kernel which eases the 90% use case of git is very welcome in my opinion. I can't wait to see what they mean to do with merge/rebase in gitless 1.0.
awkward 12y ago
I read, and was perplexed by, this description of git as a "DVCS building tool" the other day: http://lucumr.pocoo.org/2015/2/17/ui-and-hidden-consistency/ http://lucumr.pocoo.org/2015/2/17/ui-and-hidden-consistency/ Among other things, I hadn't seen anyone call git consistent before. Still, it made a good case for a project like gitless - because the data structures that back git are very well defined and well specified, the standard command set is more of a suggestion than a necessity.
ajanuary 12y ago
> gl branch name switches to branch name and it creates that branch if it doesn't exist This seems like it would be annoying when you misspell a branch name. Maybe something like "gl branch -c/--create"?
- enricosada 12y ago
  like "git checkout -b"
hasenj 12y ago
> We think the problem lies deeper than the user interface, in the concepts underlying Git Like what? And how can you solve "fundamental" conceptual issues by creating a thin layer on top of git?

42 points by mseri 12y ago

zatkin 12y ago

I don't understand the difference between this and "alias gl=git" in a bash config.

Guvante 12y ago
Implicit index and renaming several things to try and be more consistent.

chousuke 12y ago

This seems blog fails to convey the why of gitless. It looks like a very thin veneer that's trying to hide the index, which I think is a really bad idea. The index is one of the two main reasons I prefer git over mercurial. The first paragraph says that git has usability issues, but no attempt is made to explain the reasoning and convince the reader that gitless solves these. I also have a UI nitpick: long parameters should have two dashes instead of one so that short parameters can be freely combined; switches like -exc, -inc and -su go needlessly against common convention. You should also not do such arbitrary truncation... --exc and --inc match --exclude and --include unambiguously, so you get shortened forms for free if you simply do a prefix search.

adekok 12y ago
The index seems to be a git-only feature. It's one of those concepts that's so simple, it makes you go "Why the hell didn't I think of that?" The index allows you to have partially staged commits. This is most important during merges. The merged changes are staged. The unmerged ones are left in the file system. So the diffs are small. Every other VCS I've used doesn't handle that case. Merge conflict? Here's a 2000 line diff, of which only 2-3 lines are in conflict. Where are they? Have fun finding them! Arg. Hiding the index makes git easier for newcomers. It also hides a new workflow, unique to git. That workflow is better and more efficient than the ones for other VCS.
- rbehrends 12y ago
  > Every other VCS I've used doesn't handle that case. Merge conflict? Here's a 2000 line diff, of which only 2-3 lines are in conflict. Where are they? Have fun finding them! I am not sure what you're talking about. Every semi-popular VCS I know of allows you to differentiate between files with and without (or with resolved) merge conflicts. Examples (in alphabetical order, because people can get religious here, and I don't want to appear to favor one over the other): Bazaar: Integrated in bzr status and also available as a separate bzr conflicts command. Fossil: Part of fossil status and fossil changes; will display files with conflicts with a CONFLICT rather than EDITED marker. Mercurial: Here, hg resolve --list or hg resolve -l will list merged files, both resolved snd unresolved (marked with R and U, respectively). Monotone: Monotone has mtn show_conflicts and mtn conflicts show_remaining and in general a fairly sophisticated (or complicated, depending on who you ask) set of commands for analyzing and resolving merge conflicts [1]. Subversion: Conflicts are marked with "C" in svn status. (I've excluded Darcs, which has a model that's quite different from the traditional merge command, but for the same reason has fairly extensive machinery for dealing with conflicts, for better or worse.) [1] http://www.monotone.ca/docs/Conflicts.html http://www.monotone.ca/docs/Conflicts.html
  - david-given 12y ago
    Is the git index just a changelist? (Genuine question --- I've never been able to get my head around what it's for.) Most VCSes support these, even Subversion.
    - rbehrends 12y ago
      Not quite. The git index (also called staging area) is basically the schedule of changes that are to make up the next changeset once you hit "git commit". This is actually why I consider the index an anti-feature. It not only allows you to do partial commits (practically every VCS does), but encourages it and there's a good chance that you may do it wrong by accident. This can result in broken revisions (because you're committing a state that may have never actually existed on your disk, let alone did compile or passed tests) and create problems for anything from "git bisect" to nightly builds. The proper way, as far as I'm concerned, is to do the inverse: use "git stash" instead to remove all changes that you do not need, then compile and test what is in your working tree and only then commit the tested version. Afterwards, apply the stashed changes to get the working tree back to its original state. This way you can minimize the risk of broken commits.

err4nt 12y ago

I think the problem with a lot of User-Interfaces for Git (whether GUI or TUI) is that they rename or 'hide' the Git terminology from users. You still need to know Git to operate the UI, but you often have to learn how Git concepts and terminology map to the UI's terminology. Here are the commands I use with Git, they're not that different: - git co branchNameHere - pull - git st - git add -all - git commit -m "Message here" - git push I am not sure where Gitless would save me time based on what I'm seeing, it looks like a simplification of Git. What might save me time would be more features for managing and applying stashes from the command-line, or making it easier to check the changes I've made (git diff). Here is my all-time favorite Git command, and I've created an alias called 'showtree' for it, but it helps me to understand where different branches are: git log --all --graph --decorate --oneline --simplify-by-decoration

lsjroberts 12y ago
I think you might like tig - https://github.com/jonas/tig https://github.com/jonas/tig - it provides a more interactive version of your showtree command

mbil 12y ago

It'd be nice to see, for some of the most common version control tasks: 1. The common version control task (e.g. make a new branch and switch to it) 2. How it's accomplished with Git (e.g. git checkout -b my_new_branch) 3. How it's accomplished (ostensibly more easily) with Gitless (e.g. gl branch my_new_branch)

jobvandervoort 12y ago

I'd love to see something that makes git easier to use. Gitless does not make it clear to me how to work with it in only a handful of sentences. By that measure, it doesn't seem easier than git. You say: " We think the problem lies deeper than the user interface, in the concepts underlying Git" But it seems to me that you just rely on the same concepts, but rename them or do nothing at all with them. One of the concepts underlying git is a history made of unique deltas that can be referred to at any point in time (+ some change). It'd be cool if you made it easier to navigate or make those unique deltas (commits), rather than put a thin wrapper around them.

e12e 12y ago
> I'd love to see something that makes git easier to use. I'm not really aware of any problems with mercurial's git-support[1]. It might not really be "working with git", but does support working with (as in pushing and pulling) git repos. And while I think there'll never be a consensus on mercurial versus git -- I find that the interface is much cleaner in mercurial, than with git. So if by "easier" you mean "easier command line use", I think mercurial is worth a look. If not, perhaps look at various guis -- but I've not got any experience with them. hg help git Working with Git Repositories """"""""""""""""""""""""""""" Basic Use --------- You can clone a Git repository from Hg by running "hg clone <url> [dest]". For example, if you were to run: $ hg clone git://github.com/schacon/hg-git.git Hg-Git would clone the repository and convert it to an Hg repository for you. (...) If you are starting from an existing Hg repository, you have to set up a Git repository somewhere that you have push access to, add a path entry for it in your .hg/hgrc file, and then run "hg push [name]" from within your repository. For example: $ cd hg-git # (an Hg repository) $ # edit .hg/hgrc and add the target Git URL in # the paths section $ hg push [1] http://hg-git.github.io/ http://hg-git.github.io/
- david-given 12y ago
  Unfortunately, it's not quite that easy --- to be able to push, you need git+ssh, and I've never made that work with github (it just hangs saying something about git-upload-pack), and it doesn't seem to help you with some of the more horrible git interactions, such as doing a pull from upstream to your forked github repository. (And I suspect that if I could do that reliably I would have internalised enough git to use that natively.)

shreve 12y ago

Why can't we all just admit that git is terrible software and move on?

tree_of_item 12y ago
The same reason we can't just admit that JavaScript is a terrible language and move on: network effects.
balabaster 12y ago
Git isn't really terrible software. Git is really powerful and quite brilliant in many cases. However, the user experience sucks. Sourcetree went a fair way to take the pain out of it and have largely done a reasonably good job. Again, it has its shortcomings, lord knows we could do with a nice easy wrapper that takes the sting out of nagivating Git and walking us through the work flow better than the current system. If you wanna drive stick, you've gotta learn how to use a clutch and gearshift. You can't expect all of the power without being willing to put in some sweat equity to learning it.
- shreve 12y ago
  TL;DR: Git really _is_ terrible software. You're defending VCS in general. Git is a single VCS implementation, and a shitty one at that. Git is hacked together from C, Shell, Tcl (which tbh, I've never even heard of), Python, and C++. Mercurial, by comparison, is Python and C. Git has an awful UI out of the box. Why? There's no reason other than fuck you. Mercurial's UI out of the box is similar to every project that has tried to make Git easier to use. It's for _people_ to use, not Linux kernel developers. [Humor on this topic: http://homes.cs.washington.edu/~asampson/blog/git.html http://homes.cs.washington.edu/~asampson/blog/git.html] Git's documentation also sucks. Suppose you don't understand rebasing. Try running `git help rebase` and you'll get this back: "git-rebase - Forward-port local commits to the updated upstream head". WHAT THE FUCK DOES THAT MEAN? Another example: `git help push` returns "git-push - Update remote refs along with associated objects". Why is this so goddamn complicated? It's almost like it was written by developers that have no idea what it's like to not understand how git works. Oh wait. Mercurial on the other hand, has simple explanations at first, with more in-depth explanations if you look further. `hg help push` returns "push changes to the specified destination". Which is how someone would explain VCS pushing to another human being. Linus Torvalds isn't running `git help`, people that don't understand git are. Documentation should be written for them.

StavrosK 12y ago

I don't understand all the criticism here. Personally, I don't like and barely ever use the index, I think that git is completely inconsistent with itself, and find the design of gitless very consistent and easy to use. I saw it the other day and learned to use it with only a page's worth of reading. Why are so many people confused?

scrollaway 12y ago
> I don't understand all the criticism here. Okay. > Personally, I don't like and barely ever use the index And there's why. A lot of us actually like and use the index a lot. It's incredibly powerful; one of git's most powerful features in fact.
- StavrosK 12y ago
  You took one of my points and used it to dismiss my entire post. How does my not liking the index nullify the fact that git is entirely inconsistent?
  - scrollaway 12y ago
    Sorry, I did not mean to dismiss your entire post. Your wording suggests that you don't understand the criticism and confusion, but 90% of it in here (at the time of this writing) is due to the index being removed which is just: "wtf?". I agree that git is insanely inconsistent. I could talk about this for hours. I'd love a better porcelain. But gitless is removing some pretty critical stuff here. On the positive side, I really like the rest of their UI. I especially like the usage of "track" and "untrack" as core words.
    - StavrosK 12y ago
      Some of the criticism is about the index, but most of the rest seems to be "why gitless?" and "how do I use it?", which are pretty well covered in the docs, I think. I agree with you that the removal of the index was a bit orthogonal to the end goal of making gitless more consistent. I do agree with their decision (because I don't find the index that useful), but you're right in that they dumped the baby out with the bathwater by going with simplicity rather than just consistency.

jacobsimon 12y ago

I don't think I'd be able to live without "git add -p"

tokenrove 12y ago
Seriously. I can't even contemplate what life would be like without it. (And, particularly, magit's interface for it in emacs)

vasco 12y ago

Git is so powerful and complex. I do agree that the user interface is poor and most of the arguments I've heard in favor just sound like the person already invested a great deal of time learning, and so won't accept change. A great coat on top of a powerful kernel which eases the 90% use case of git is very welcome in my opinion. I can't wait to see what they mean to do with merge/rebase in gitless 1.0.

awkward 12y ago

I read, and was perplexed by, this description of git as a "DVCS building tool" the other day: http://lucumr.pocoo.org/2015/2/17/ui-and-hidden-consistency/ http://lucumr.pocoo.org/2015/2/17/ui-and-hidden-consistency/ Among other things, I hadn't seen anyone call git consistent before. Still, it made a good case for a project like gitless - because the data structures that back git are very well defined and well specified, the standard command set is more of a suggestion than a necessity.

ajanuary 12y ago

> gl branch name switches to branch name and it creates that branch if it doesn't exist This seems like it would be annoying when you misspell a branch name. Maybe something like "gl branch -c/--create"?

enricosada 12y ago
like "git checkout -b"

hasenj 12y ago

> We think the problem lies deeper than the user interface, in the concepts underlying Git Like what? And how can you solve "fundamental" conceptual issues by creating a thin layer on top of git?