5 ms·

Gitless: experimental version control system

43 points by deegles 12y ago

jennings223 12y ago
As a novice git user, I can't really tell how Gitless is really different from Git in daily use cases. Any explanations?
- Lazare 12y ago
  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 <url> 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.)
  - jennings223 12y ago
    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.
  - br3w5 12y ago
    So is gitless against working with hunks of files because the docs say that having files with parts in multiple states is a problem? But this actually gives more flexibility. Yes it's more complex but that's the trade-off.
    - Lazare 12y ago
      I'm not sure I'd say gitless is "against" it so much as it's focused on making the tasks people do every day easier. I use git every day, but I think I ended up staging individual hunks of files maybe...twice in the past year? (And you can still drop back to git if you do need that functionality. As the docs note, gitless and git are entirely compatible.)
      - br3w5 12y ago
        true...i guess for me it's another potential option for working with git like the prezto git module and git plugins for vim
- mikekchar 12y ago
  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.
  - jennings223 12y ago
    I got the exact feeling as yours at first. :) My understanding of your concern of rebase is that if they are gonna change that (or get rid of that), it will be a change of the workflow instead of just a simplification of it. I used to rely on merge other than rebase when my local tree is diverted. That usually ended up with two commits (one for my local changes, one for the merge). But later I learned to use rebase. It would only result in one commit, which I feel is kinda nice coz you have a cleaner and more correct(time-wise) commit history. I don't know if this is the fundamental purpose of rebase. Advice welcome.
    - mikekchar 12y ago
      This was a long time ago, so maybe you won't see this reply :-) Rebase is awesome as long as you never publish the branch before you rebase. If anyone uses your branch, then the history will not match up and they will not be able to merge their changes because Git will not be able to determine the order of the commits. I have gone through this more than once and it is not fun at all. Rebase works extremely well for what is was designed for: You have a lot of people working completely independently and you want to submit your changes to a central maintainer. You rebase your branch so that the changes appear to be applied directly onto their branch. It makes it much, much easier to review. If the change is accepted then it is merged and everybody uses the merged version. If not, the branch is destroyed (of course you still have your changes in your repository). As long as nobody makes any changes to (or branches off of) a branch that will be rebased, then there will be no problem. Because the vast majority of people use git as kind of a "better SVN", with a centralized repository and published branches (using Github or the like), most people should never, ever use rebase. Especially if you are trying to design a simple workflow for neophytes, then you should almost certainly not make rebase easy to reach. Like I said, I like rebase, but it is not something that fits well in a collaborative office environment. It works much better in a hugely distributed open source project, or a personal project (if you are being very careful).
s3nnyy 12y ago
I like the idea of an easier to use Git but I'd wish for a clearer side-by-side explanation how Gitless is supposed to be simpler than Git (for instance, the CoffeeScript website shows clearly how it compares to JavaScript: http://coffeescript.org/ http://coffeescript.org/)
JonathonW 12y ago
So... if I'm reading this right, this is basically Git without the staging area/index? (Or, alternatively, Git where tracked files are always in the staging area?)
112percent 12y ago
I think the problem lies with the expectation that people will just pick up how to use git and how it works. Wouldn't it be better to provide small classes to people where understanding can be gained, rather than abstract how to use Git with a different client?
jammycakes 12y ago
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 use the command line a lot more, and I would strongly recommend people to do so once they've mastered the core concepts, but I still like to have a GUI to hand so I can see at a glance where things are at with my branches, staging area, etc.
- therealidiot 12y ago
  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
  - jammycakes 12y ago
    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.
    - austinz 12y ago
      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?
nulltype 12y ago
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 tool (I feel like kaleidoscope is the minimum here) submodules Gitless seems to address #3 there but not the others. Actually making a tool that improves git to where it could be would probably be a huge undertaking, and most people do alright with git so maybe it's not worth it. Or maybe there's some graphical git client like tower that fixes all this stuff.
- jsprogrammer 12y ago
  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 the existing git CLI code might not be feasible though.
  - nulltype 12y ago
    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.
    - jsprogrammer 12y ago
      Conceptually it is very simple. Integrating it with existing tools is where the real work is. Ideally, I think you'd want it integrated with your text editor and it should be useful not only for code, but more general composition (I'm thinking scientific literature) as well. Of course, getting this to work in real-time with your collaborators is probably the holy grail and has been implemented to some extent over the years in quite a few products.
hbogert 12y ago
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 magic, but all those commands just function on a handful of data structures. (though some of the commands are not always intuitively named) Recommended reading: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf http://ftp.newartisans.com/pub/git.from.bottom.up.pdf
- viraptor 12y ago
  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 <name>/?/-d git branch <name>/-m/-d
  - faceplanter 12y ago
    This so much. People consistently complain about PHPs' stdlib and how the naming and parameter order are not streamlined. Git is very similar to PHP in this case. It's not something that's going to keep people from using it but it is one of those warts that people just have accepted.
  - e12e 12y ago
    Very much my main reason for preferring mercurial to git. Has there been any real talk in re-factoring the UI for a major-version of git? Clearly it would break some things, but simple stuff, like settling on rm or remove or delete etc... seems like a good idea? On the other hand, I suppose the git-plugin[1] for mercurial is good enough, that there's really no reason to use git for those that feel strongly about the UI? [1] http://hg-git.github.io/ http://hg-git.github.io/
  - StavrosK 12y ago
pain 12y ago
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.)
- Mathiasdm 12y ago
  I believe this was a step in that direction: https://bitbucket.org/durin42/hgit https://bitbucket.org/durin42/hgit
jermo 12y ago
Would be interested in how this compares to Legit [1] which has been around for a while. [1] http://git-legit.org/ http://git-legit.org/
deleted 12y ago
[deleted]
Mathiasdm 12y ago
I wish Git would have used a different name than 'branch'. It's completely at odds with branches in any other version control system and only adds confusion for people switching to/from Git. Mercurial uses the term 'bookmarks' for Git-style branches, I feel that would have been a much better choice.
- riquito 12y ago
  cvs, svn, bazaar use "branch". 'Bookmark' is way more awkward to me.
alexband 12y ago
as I see it use gitpylib instead of pygit2, I stopped to give it a try
- isxek 12y ago
  I'm not familiar with either of them. What's wrong with using gitpylib?
erikb 12y ago
After reading the comments I found a few ideas that were not represented, so I write them here: 1. Git thinks around a commit, Gitless thinks around a file. Comparing two tools on a different basis might result in a flawed comparison. The reason that git uses for considering commits over single files is as far as I know, that you as a developer consider consistent states of your project. Before and after a change a project should be able to build, for instance. Often these changes can not happen in a single file and still be consistent. Therefore a project state is considered a unit, not a set of files that are changed on their own. 2. The staging area. Gitless thinks the staging area is a problem so it seems to be removed (might be a wrong interpretation by me). The staging area is quite important though. Sometimes I have made many changes, but I don't want all of them in one commit. In another scenario I did many changes that after squashing plus a few edits here and there might be better represented by a much smaller amount of commits. In both cases I need a space that is not the repository space of completed commits nor the workspace to represent a commit in its creation. The staging area might not be the best way to do it (I don't know a better one, though), but completely removing it without an alternative does not solve the problem.

43 points by deegles 12y ago

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

Lazare 12y ago
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 <url> 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.)
- jennings223 12y ago
  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.
- br3w5 12y ago
  So is gitless against working with hunks of files because the docs say that having files with parts in multiple states is a problem? But this actually gives more flexibility. Yes it's more complex but that's the trade-off.
  - Lazare 12y ago
    I'm not sure I'd say gitless is "against" it so much as it's focused on making the tasks people do every day easier. I use git every day, but I think I ended up staging individual hunks of files maybe...twice in the past year? (And you can still drop back to git if you do need that functionality. As the docs note, gitless and git are entirely compatible.)
    - br3w5 12y ago
      true...i guess for me it's another potential option for working with git like the prezto git module and git plugins for vim
mikekchar 12y ago
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.
- jennings223 12y ago
  I got the exact feeling as yours at first. :) My understanding of your concern of rebase is that if they are gonna change that (or get rid of that), it will be a change of the workflow instead of just a simplification of it. I used to rely on merge other than rebase when my local tree is diverted. That usually ended up with two commits (one for my local changes, one for the merge). But later I learned to use rebase. It would only result in one commit, which I feel is kinda nice coz you have a cleaner and more correct(time-wise) commit history. I don't know if this is the fundamental purpose of rebase. Advice welcome.
  - mikekchar 12y ago
    This was a long time ago, so maybe you won't see this reply :-) Rebase is awesome as long as you never publish the branch before you rebase. If anyone uses your branch, then the history will not match up and they will not be able to merge their changes because Git will not be able to determine the order of the commits. I have gone through this more than once and it is not fun at all. Rebase works extremely well for what is was designed for: You have a lot of people working completely independently and you want to submit your changes to a central maintainer. You rebase your branch so that the changes appear to be applied directly onto their branch. It makes it much, much easier to review. If the change is accepted then it is merged and everybody uses the merged version. If not, the branch is destroyed (of course you still have your changes in your repository). As long as nobody makes any changes to (or branches off of) a branch that will be rebased, then there will be no problem. Because the vast majority of people use git as kind of a "better SVN", with a centralized repository and published branches (using Github or the like), most people should never, ever use rebase. Especially if you are trying to design a simple workflow for neophytes, then you should almost certainly not make rebase easy to reach. Like I said, I like rebase, but it is not something that fits well in a collaborative office environment. It works much better in a hugely distributed open source project, or a personal project (if you are being very careful).

s3nnyy 12y ago

I like the idea of an easier to use Git but I'd wish for a clearer side-by-side explanation how Gitless is supposed to be simpler than Git (for instance, the CoffeeScript website shows clearly how it compares to JavaScript: http://coffeescript.org/ http://coffeescript.org/)

JonathonW 12y ago

So... if I'm reading this right, this is basically Git without the staging area/index? (Or, alternatively, Git where tracked files are always in the staging area?)

112percent 12y ago

I think the problem lies with the expectation that people will just pick up how to use git and how it works. Wouldn't it be better to provide small classes to people where understanding can be gained, rather than abstract how to use Git with a different client?

jammycakes 12y ago

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 use the command line a lot more, and I would strongly recommend people to do so once they've mastered the core concepts, but I still like to have a GUI to hand so I can see at a glance where things are at with my branches, staging area, etc.

therealidiot 12y ago
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
- jammycakes 12y ago
  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.
  - austinz 12y ago
    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?

nulltype 12y ago

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 tool (I feel like kaleidoscope is the minimum here) submodules Gitless seems to address #3 there but not the others. Actually making a tool that improves git to where it could be would probably be a huge undertaking, and most people do alright with git so maybe it's not worth it. Or maybe there's some graphical git client like tower that fixes all this stuff.

jsprogrammer 12y ago
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 the existing git CLI code might not be feasible though.
- nulltype 12y ago
  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.
  - jsprogrammer 12y ago
    Conceptually it is very simple. Integrating it with existing tools is where the real work is. Ideally, I think you'd want it integrated with your text editor and it should be useful not only for code, but more general composition (I'm thinking scientific literature) as well. Of course, getting this to work in real-time with your collaborators is probably the holy grail and has been implemented to some extent over the years in quite a few products.

hbogert 12y ago

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 magic, but all those commands just function on a handful of data structures. (though some of the commands are not always intuitively named) Recommended reading: http://ftp.newartisans.com/pub/git.from.bottom.up.pdf http://ftp.newartisans.com/pub/git.from.bottom.up.pdf

viraptor 12y ago
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 <name>/?/-d git branch <name>/-m/-d
- faceplanter 12y ago
  This so much. People consistently complain about PHPs' stdlib and how the naming and parameter order are not streamlined. Git is very similar to PHP in this case. It's not something that's going to keep people from using it but it is one of those warts that people just have accepted.
- e12e 12y ago
  Very much my main reason for preferring mercurial to git. Has there been any real talk in re-factoring the UI for a major-version of git? Clearly it would break some things, but simple stuff, like settling on rm or remove or delete etc... seems like a good idea? On the other hand, I suppose the git-plugin[1] for mercurial is good enough, that there's really no reason to use git for those that feel strongly about the UI? [1] http://hg-git.github.io/ http://hg-git.github.io/
- StavrosK 12y ago

pain 12y ago

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.)

Mathiasdm 12y ago
I believe this was a step in that direction: https://bitbucket.org/durin42/hgit https://bitbucket.org/durin42/hgit

jermo 12y ago

Would be interested in how this compares to Legit [1] which has been around for a while. [1] http://git-legit.org/ http://git-legit.org/

deleted 12y ago

[deleted]

Mathiasdm 12y ago

I wish Git would have used a different name than 'branch'. It's completely at odds with branches in any other version control system and only adds confusion for people switching to/from Git. Mercurial uses the term 'bookmarks' for Git-style branches, I feel that would have been a much better choice.

riquito 12y ago
cvs, svn, bazaar use "branch". 'Bookmark' is way more awkward to me.

alexband 12y ago

as I see it use gitpylib instead of pygit2, I stopped to give it a try

isxek 12y ago
I'm not familiar with either of them. What's wrong with using gitpylib?

erikb 12y ago

After reading the comments I found a few ideas that were not represented, so I write them here: 1. Git thinks around a commit, Gitless thinks around a file. Comparing two tools on a different basis might result in a flawed comparison. The reason that git uses for considering commits over single files is as far as I know, that you as a developer consider consistent states of your project. Before and after a change a project should be able to build, for instance. Often these changes can not happen in a single file and still be consistent. Therefore a project state is considered a unit, not a set of files that are changed on their own. 2. The staging area. Gitless thinks the staging area is a problem so it seems to be removed (might be a wrong interpretation by me). The staging area is quite important though. Sometimes I have made many changes, but I don't want all of them in one commit. In another scenario I did many changes that after squashing plus a few edits here and there might be better represented by a much smaller amount of commits. In both cases I need a space that is not the repository space of completed commits nor the workspace to represent a commit in its creation. The staging area might not be the best way to do it (I don't know a better one, though), but completely removing it without an alternative does not solve the problem.