

Gitless: experimental version control system - deegles
http://people.csail.mit.edu/sperezde/gitless/index.html

======
hbogert
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
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

~~~
StavrosK
Exactly. Git's porcelain is just amazingly inconsistent and really badly
designed. I wonder why nobody has come up with a better design yet, I can't
imagine it would be that hard to do... Maybe I'll give it a shot.

~~~
Lazare
Well, there's gitless. :)

~~~
StavrosK
That is true. Last I tried it, it wasn't very mature. I'll give it another go
and see if it's changed.

------
jammycakes
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
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
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
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?

~~~
biehl
Exactly! And the cli is much better for the little workflows around rebase and
cherry-pick.

------
s3nnyy
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/))

------
Mathiasdm
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
cvs, svn, bazaar use "branch". 'Bookmark' is way more awkward to me.

------
pain
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
I believe this was a step in that direction:
[https://bitbucket.org/durin42/hgit](https://bitbucket.org/durin42/hgit)

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

------
JonathonW
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?)

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

~~~
pja
At least some of these are what makes git awesome.

* commit changes manually \- I find my self picking individual changes out of the current state of my source & committing them individually all the time, so this is just perfect.

* history & branch navigation. \- Um. Not sure what the problem is here. I can checkout anything I like, hop around the history at will, tag any version with meaningful names etc. Am I missing something?

* confusing command structure. \- Yeah, have to give you this one. It is (slowly) getting more consistent over time at least.

* history rewriting \- this means I can hack & commit away then rewrite my changes into a logically consistent series of changesets that make sense individually before pushing to the main repo. I rewrite history _all_ the time before pushing.

* no merge tool \- but is happy to use whatever merge tool you plug into it, which works pretty well in my experience. (See the git-mergetool manpage.)

* submodules \- Yeah, these are mostly awful.

I think git (or mercurial for that matter) is great for people who see having
a clean, well documented change history where every commit makes sense in and
of itself as a worthwhile thing to have. If you're the kind of developer who
just uses a VCS as a sort of 'source code backup' and your revision history
consists mostly of a long series of "Update" comments then all the extra power
that git has is just extra complexity that you don't need.

~~~
nulltype
Git makes it way harder than necessary to do all these things and has a steep
learning curve (generally a euphemism for bad design).

I'm proposing that you can get all the benefits you talk about but in a far
more usable manner. I like a clean master branch with atomic sensible commit
messages as much as the next man. Git just makes it a real chore to get there.

You seemed confused about the history and branch navigation, so maybe I can
explain that one better.

What I want is to visually view the history of a file, and trace, for
instance, a function as it moves through my project, into different files,
etc. I also want to easily find code that I deleted in the past to use as a
reference for implementing a new version of the code, rather than keeping it
in some "obsolete" folder in source control. I have seen people who do that.
There are ways to do these things now involving searching git logs and viewing
diffs or checking out old branches, but the interface is very poor. Even the
interface on Time Machine is better than git, and that thing isn't build to
source code.

But perhaps you are correct. Maybe most people use git primarily as a backup
service for code. If so I guess git should make that a way better process. I
will point out that github actually offers a way better interface to git than
git does. It just still has a long way it can go.

------
112percent
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?

------
jermo
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/)

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

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

~~~
br3w5
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
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
true...i guess for me it's another potential option for working with git like
the prezto git module and git plugins for vim

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

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

