
Gitless: A simple version control system built on top of Git - jackbravo
https://gitless.com/
======
cyphar
I must admit I'm a little bit confused. It opens with a discussion that people
find Git hard to use, and a statement that these problems are likely more than
skin-deep but then goes on to describe a wrapper around Git which is mostly a
bunch of aliases. Don't get me wrong, I'm know that many people do find Git
hard-to-use, but I don't see anything in the eventual project implementation
which backs up the original claim that the problems are conceptual. I don't
think it's possible to fix conceptual problems in a tool by just wrapping it.

I have heard people complain about the staging concept (personally I find it
useful, because you can do 'git add -p' which allows you to craft intermediate
commits or to-be-squashed fixup commits after you've finished some
development), so it's removal in this tool is unsurprising. And it is nice to
auto-stash on branch change (though personally I think that they should've
made stashing a much better-supported concept in their Git wrapper -- I've
never really liked how stashing was implemented in Git).

I do really like that they appear to have worked hard to remove all of the
super-scary warnings that Git likes to spit out. As someone who has taught
high-school students how to use Git (among other things), I've learned that
the easiest way to scare away people from your project is to have bright-red
warnings in response to a user doing something. Most students describe it as
though the computer is effectively screaming at them. Some tools over-
compensate for this is and spew emoji in response to user input, so I'm happy
this tool has struck the right balance.

~~~
deepspace
I could never understand the complaint that Git is "hard to use". Having used
a plethora of version control systems over many years, I never found Git to
significantly more or less complicated than any other system. Version
management includes many use cases, some of which are inherently complex.
Therefore any version control tool must be able to perform both simple and
complex tasks, and the latter ones will obviously require a more complicated
syntax and conceptual model.

In any case, we are supposed to be professionals. Complaining that Git is hard
to use is a bit like a machinist complaining that a CNC machine is hard to
use. If you want to accomplish non-trivial things in any field, you have to be
prepared to deal with some level of complexity. /rant

~~~
saagarjha
Git, the version control system, is pretty simple. Git, the command line tool
that helps manage repositories, is not.

~~~
Certhas
Which is why I like gutless. Same VCS, sane interfaces, less state to juggle.

------
dustfinger
If anyone wants to know what it is like working with a "hard to use" revision
control system then I highly recommend trying out IBM Rational ClearCase [1].
Or as I lovingly used to refer to it as Irrational ClearCase. To be fair, I
have not used it since 2009, so perhaps it has been improved?

If you use emacs and you find git difficult then please try out magit [2]. I
actually really like the git cli, but I use magit a fair amount also. Plus,
emacs is awsome :-P

[1]
[https://en.m.wikipedia.org/wiki/Rational_ClearCase](https://en.m.wikipedia.org/wiki/Rational_ClearCase)

[2]
[https://en.m.wikipedia.org/wiki/GNU_Emacs#Extensibility](https://en.m.wikipedia.org/wiki/GNU_Emacs#Extensibility)

~~~
kruczek
I used ClearCase 3 years ago and this is spot on. ClearCase is little better
than keeping revision history manually by zipping old versions of files. I
sometimes wonder what kind of insane mind came up with its workflow.

First of all, to checkout a branch, you don't simply select its name. You need
to write a freaking configuration file to tell CC what you want to checkout.
And it is entirely possible to accidentally write that configuration file in
such a way that you'll have half of repository checked out from one version of
code, while the other half is checked out from another version of code.

Then there is history of changes. Or in case of ClearCase: histories of
changes. Because there are many, in fact as many as there are files. Yes, each
file has its own history of changes, completely independent from other files.
So if you make a commit which changes 10 files, CC will create separate commit
for each of those 10 files, each with the same commit message. Needless to
say, browsing history with same commit messages repeated tens or hundred of
times, is quite an adventure.

Oh, and because of that, it is not possible to simply checkout some old
version of code. If you are lucky, you will have put labels on all files of
needed version of code, so then you can checkout that label. Otherwise the
only option is to checkout based on dates of commits, and hope that your
provided date won't actually cut any commit in half.

~~~
adrianN
The model is fairly similar to CVS, which also keeps histories of files
instead of a history of the repository. The ability to have half of your
repository come from one "branch" and the other half from a different branch
is actually seen as a feature. This enables workflows similar to what you can
do with submodules in git.

Having to manage your config specs and the inability to go back to old
versions of your software (or in fact just have something reproducible for
your build servers) unless you meticulously label everything makes Clearcase
of course barely useable. It gets extra interesting if you use multi-site
Clearcase and your replicas stop synching.

~~~
bdavis__
You have to label (tag) every change or it would be impossible.

------
maxxxxx
Removing staging seems a little odd. To me staging, especially with a GUI like
Sourcetree, is almost the best part of git.

~~~
davnicwil
Curious as to why - What usecases do you have for staging? Why does sourcetree
make it better? To me it's just an inconvenience and a redundant step on the
way to committing stuff.

I get that you can use it for partial commits of in flight work but that's
never something I've needed in practice. Usually I just want to commit
everything I'm working on at once.

~~~
acemarke
Incremental staging of the next commit is absolutely a valuable feature.

I'll often touch multiple files over the course of a few hours, sometimes for
slightly unrelated changes, and then want to pull apart the changes into
several smaller logical commits. Sometimes a couple hunks in a file might need
to go into Commit A, while others go into Commit B.

You can do piecemeal adding of hunks via the CLI, but the interface is
horrible. Being able to simply click "Add Hunk" in a GUI is incredibly
valuable (or even in some cases shift-clicking a couple lines and "Add
Lines").

~~~
ufo
You can get that kind of interface without a staging area. TortoiseHg would do
it using Mercurial's shelving feature (similar to git stash) and IMO that was
simpler to understand than staging. In particular, I liked that at all times
there was a correspondence between the current working directory and what was
being commited. It made it easier to run tests.

~~~
chousuke
I would hate to be restricted to a GUI tool to achieve what git add can do
from the command line. Using stashes would be just reimplementing the index
using less convenient UI.

I really don't understand what's so difficult about the index... It's just the
stuff you will be inserting into the repository when you next commit. Having
it separated enables a very convenient workflow that would've required
manually using patch and diff when using tools that don't support you.

Git is more than just revision storage. I like to think of code as clay, and
the index as a tool you use to mould that into the final construct that gets
baked

~~~
jobigoud
> I would hate to be restricted to a GUI tool to achieve what git add can do
> from the command line.

I don't quite understand the use of the command line for git or hg.

In my typical workflow before I commit I want to quickly review all the
changes I just made. With the GUI you have a list of files and when a file is
selected a diff of that file, without opening a new window. That means you can
browse all the diffs in a few seconds just by moving the cursor along the
changed files. If you see an unrelated change that doesn't have an impact you
can just uncheck these lines to remove these changes from the commit. Or
uncheck the file itself if all its changes are unrelated. I feel I'm much more
confident of what ends up in the commit than using the cli.

~~~
chousuke
I often find GUIs restrictive because they don't lend themselves well to ad-
hoc scripting. I also don't use GUI editors, so that may be a part of it.

I can see how a TUI/GUI for being able to quickly stage things from the UI is
useful, but it doesn't make the concept of the index useless on the command
line either.

Using git from the command line is second nature to me at this point, and the
index is a large part of my workflow. When I use git for revision control (as
opposed to eg. Subversion. Or anything that doesn't have lightweight
branching, something akin to an index, and rebases), it feels like the tool is
helping me organize my commits instead of just being a place to shove things
after I'm done coding.

------
Piskvorrr
Interesting. It seemed to be just git-renamed, but the concept of "no staging
area, smart-add everything" and "autostash everything on branch change" looks
useful. Not as powerful as git, but it's always possible to fall back to non-
abstracted git.

------
nimbius
I feel like this is just another "git is hard so lets make it easier" program
that makes collaborative development a pain. maybe its just my puritan work
ethic.

first we had git, and anyone who cared to spend the time could pick it up and
understand it well enough to use it. Then we got github and gitlab, which made
remote branches more manageable but introduced and entirely new class of
developers who only added code through the web interface and emailed/called
when they needed a merge or just merged to master because you were sick of the
hand-holding.

then we got the GUI clients for windows, which resulted in armies of
programmers who didnt understand keys, or authentication, or why the
gitlab/github server existed but just wanted to commit their code and as a
result left the codebase with a graveyard of rebase --hard and reset head
garbage that had to be explained later. supporting them became a nightmare of
screen sharing and shouting.

finally we have gitless? and developers now have to keep straight gui,
console, gitlab/hub and some asinine wrapper script between the teams? so when
jack commits with his GUI and accidentally drags and drops 3 branches, while
jills gitless command wiped half the unprotected master, how does it get
sorted out?

~~~
pryce
Git was not first, and it arguably didn't achieve its dominance based on
technical superiority. It almost certainly didn't achieve that dominance based
on offering a better learning curve or a bizarre interface choice, even though
I might personally understand and appreciate the relative tightness to its
underlying systems. I also don't think we should defend a technology or tool
by portraying it as a sort of null-hypothesis, a default automatically
suitable for anyone except in special circumstances.

I'm currently making source control recommendations for my new client. No one
there is a full-time programmer, and they mostly do engineering and PLC work,
but more recently they have to work with higher level languages from time to
time. They absolutely need something they won't have to fight to learn. Other
times I've recommended source control during my career include tutoring first-
year/some second-year university students, who are often still only becoming
familiar with programming and CLIs, and for whom Git seems both arcane and
stress-inducing, two things you absolutely don't want from a source-control
system.

I am adamant that in neither of these above cases would git be the right
choice. I'm also not convinced its the right choice for many development
companies, which often have staff of a range of skill levels. I'm lucky in
that I've nearly always been working with passionate programmers, where we can
and do happily make the choice to adopt git without a second thought.

~~~
kungtotte
Git did beat both of the other main contenders in the DVCS space (Darcs,
Mercurial) hands down when it came to performance around the time it rose to
prominence, so I think it's unfair to say that it had no technical
superiority.

------
bg4
It's amazing the lengths people will go to avoid properly learning something.

~~~
brianpgordon
I have a fairly advanced knowledge of git (that is, at the level of porcelain
and plumbing commands; I haven't touched the C codebase itself) and I intend
to give gitless a try when I get back to work on Monday.

My reason is that, while I'm a fan of git the technology, I think the default
git CLI is an _unmitigated fucking nightmare_ and I begrudge every neuron of
space that I have to waste remembering how it works. Unfortunately, none of
the graphical tools I've tried are as good. So I'm eager to try an alternative
command line porcelain that's not so completely batshit insane. If it works
out, maybe I can reclaim some of that wasted space.

~~~
jnurmine
Can you please give an example of the things you mean?

Edit: wording.

~~~
brianpgordon
Sure, here are a few:

\- Command line switches are inconsistent. For example, to list remotes you
use -v but to list branches you use -l

\- Speaking of command line switches, how about that bizarre need to separate
paths in certain commands with "\--" so that the parser doesn't get confused?
I can never remember when that's necessary.

\- There's weird overlap between the porcelain commands that make them harder
to learn than they should be. For example, git checkout can do the work of git
branch. git pull usually does the work of git fetch. Some common operations
get their own commands, while others require you to use switches on other
commands. It really shows that git evolved organically from a bunch of shell
scripts used by one particular dev team until it katamari damacy'd into a big
agglomeration of random parts.

\- Poor defaults, such as git push --force not having the behavior of --force-
with-lease, and also git push pushing all branches at once by default.

\- A bunch of commands are ridiculously overloaded or encumbered by historical
limitations that don't make sense anymore. See
[https://redfin.engineering/two-commits-that-wrecked-the-
user...](https://redfin.engineering/two-commits-that-wrecked-the-user-
experience-of-git-f0075b77eab1)

\- Many of git's mechanisms are overly complex and lead to a depressing number
of bewildered users. E.g. witness the confusion and conflicting advice at
[https://stackoverflow.com/questions/6089294/why-do-i-need-
to...](https://stackoverflow.com/questions/6089294/why-do-i-need-to-do-set-
upstream-all-the-time) Another example is git reset, which is invariably a
nightmare to explain to an intern or new developer who hasn't used git yet.
Trying to learn what git reset does from reading the man page is like trying
to learn calculus by examining the digits of pi.

\- Speaking of man pages, the man pages are comically bad. I find the git man
page generator endlessly amusing: [https://git-man-page-
generator.lokaltog.net/](https://git-man-page-generator.lokaltog.net/)

~~~
jnurmine
Thank you, I see what you mean.

Firstly, I agree that Git has a learning curve. However, trying to learn
anything based on man pages alone is not a good idea, in my opinion man pages
are for reference and not a substitute for more extensive documentation. Of
course, sometimes man pages are the only document one has, but this is not so
in the case of Git. I myself am not a Git expert, but after reading about what
problems people have with Git, it feels like people should perhaps not go for
the most exotic commands by default, and they should use a topic branch based
workflow. And they should read the Pro Git book and I mean this in a good way
:)

As for the switches, one can just as well use "git branch -v" to list
branches, I usually pipe to grep if looking for a branch. For the "git
remote", it actually does show you the remotes without any switches, but the
URL of the remote is not the remote... To see the URLs you'll need the verbose
switch. Maybe this is right, maybe not, I do think it makes sense.

The two dashes is actually not a Git peculiarity. It comes from getopt and
POSIX.2 to signal the end of options. Compare with e.g. to rm a file that's
called "-rf", you'll have to do "rm -- -rf" in the shell.

As for the intern, just tell them "Git reset moves backwards in commit
history". Of course there are details (and you can get back to the future with
e.g. git reflog), but it should be accurate enough description to an intern
who is new to Git, since that's what "git reset" is mostly used for anyway.
IMO "git reset -p" and such are somewhat advanced usage.

The problem with the Stack Overflow link is that Git is not tracking that
upstream branch, just because the local and remote branches happen to have the
same name after a push does not mean they are the same and should be tracked.
I'd argue that if one works with topic branches, that kind of situation is
kind of remedied automagically through the workflow... Anyway, Tzen's answer
there is the correct one (when including the typofixes in the comments).

Also, thanks for the link to the Git man page generator, it's great!

------
norswap
Finally gave this a proper read. It's a bit disappointing indeed. Besides
removing the index (which, as other commenters have pointed out, is
questionable), there is one BIG change from Git to be noted:

You can always switch branches, without losing your working directory changes.
In the common case, this amounts to automatic stashing and unstashing,
enabling you to quickly move around to an alternative repository state to
check something out (with real git, this is too annoying and I resort to
browsing the history on github more often than not).

The second case illustrated in the comparison section is switching branches
during a rebase, which git doesn't support without aborting the rebase.

My recommendation: if that seems like a killer feature to you, use gitless.
Otherwise, the slight simplification of commands isn't worth adding a layer on
top of git.

------
amelius
My biggest problems with Git are that it doesn't handle large binary objects
efficiently, and that it's difficult to treat multiple git repos as a single
repo (useful for many things, including keeping versions coherent).

~~~
lm2s
git-lfs doesn't solve the large binary issue?

~~~
amelius
It may, but it's a hassle to set up as it requires a separate server daemon
(for which I don't understand the necessity, as a git repo itself can be
stored on a server over ssh).

------
Vanderson
What I see this seems to be doing is auto-staging every file that changes? And
beyond that it has a few aliases for some commands. Is anyone else getting the
same thing?

I use git in my CMS which auto-commits a template file (text) on save. Which
works great in a browser editor online. (ie, editing files remotely)

But I am not seeing an advantage to "not staging" with local files. What does
this save when working locally?

Is there some disadvantage to staging I am not seeing here? Changing to "not
tracking" seems like you removed the file from the repo, which in my opinion
goes against the grain on how git works, and in a sorta bad way.

------
huntie
I remember seeing gitless a while ago and thinking it was interesting, but I
found it to be very slow due to Python's startup time.

------
not_kurt_godel
After reading the referenced papers explaining the academic rationale, Gitless
gets a big "meh" from me.

A quick tl;dr of the referenced paper "Purposes, Concepts, Misfits, and a
Redesign of Git"
([https://spderosso.github.io/oopsla16.pdf](https://spderosso.github.io/oopsla16.pdf)):

> The changes made to Git’s concept model are:

> 1\. The redefinition of “tracked” and “untracked,” and the elimination of
> “assume unchanged” and the “staging area.”

> 2\. The redefinition of the concept of “branch,” and the elimination of
> “stash.”

> 3\. The creation of the notion of a “current branch,” and the redefinition
> of “head.

I would agree that most of the delta from git represents an incremental
improvement in usability; staging, stashing, and complex ignore rules are all
things that are more likely to get in the way of novice to intermediate git
users than help them. That being said, I'd classify those usability issues as
minor in the overall picture. Most of them are trivial to smooth out either
via git aliases or shell aliases - for example, I've had `ignore`, `show-
ignored`, and `unignore` aliases for so long that seeing `git update-index
--assume-unchanged foo` on the Gitless site made me realize I'd forgotten that
that's what my `ignore` alias is actually doing under the hood.

By far the most complex & difficult aspect of using git (and source control in
general) is merge conflict resolution. I'm not convinced Gitless offers much
benefit in this aspect and in fact I suspect it may actually make things
worse. Complex conflict resolution is when the ability to distinguish between
staged and unstaged changes is most useful and sometimes even crucial.
Furthermore, while Gitless offering capability to 'pause' a conflict
resolution by switching to another branch is neat, I would say it's very rare
that I need to ever do so in the middle of a conflict resolution. Difficult
resolutions require full concentration - if I find myself needing to switch to
another branch in the middle of one, the context switch usually renders me
unable to pick up where I left off and I wind up starting over to make sure
I'm working from a clean slate.

On the whole, I could see Gitless being valuable in academic environments to
facilitate desparately-needed use of source control among
researchers/postgrads/scientists. But I would steer clear of it in a software
development career as I think it would stunt user's abilities to truly master
a core tool of their profession in the long run.

~~~
hrktb
Good points overall, I don’t disagree but I’ll try to give another POV.

I think the focus on stashing is that it’s basically an hidden state. If for
instance you switch back to a branch after a while and you don’t remember you
stashed, it will just be lost work. Overall I wish stashed were shown as
candidate commits, I actually end up making temporary commits that I amend
afterward, most of the time.

For the switching between branches during conflict resolution, it might be for
people like me who check back and forth reference branches when merging code.

For instance a conflict can be between two feature branches I want to merge,
and I’d need to check on master what is the current behavior. Or what’s the
behavior on other branches that will need merging as well. Currently I’d just
open github/gitlab on the other branches and compare from there, but I’d see
the value in switching the local files.

All in all I feel git is too aggressive in making the user deal with all the
details when it could have sane non destructive defaults

~~~
not_kurt_godel
Yep, I basically agree with all of that. To clarify my main point, I don't
think the marginal benefit that Gitless provides for working around these
rough edges outweighs the disadvantage of not learning the underlying git
functionality and thereby being unable to utilize advanced techniques that are
inevitably required in the course of a serious software engineering career.

------
Shorel
Sounds like something I would use, if I had not a bunch of git aliases that do
similar things.

In other words, yes, this is useful.

------
SlowRobotAhead
Git with a veneer on it, that if there are problems you can revert to git-
proper...

How is that different from Git Desktop?

~~~
fudged71
You don't leave the command line

~~~
erikb
> You don't leave the command line

An advantage of gitless on one side, a statement about how to live life on the
other side.

------
hyperpallium
I like the idea of working with the simple datastore of git - immutable
objects pointing to each other - and manipulate them with a programming
language.

But there's lots of things you routinely want to do that aren't convenient
this way. Still has some appeal.

------
bvrmn
I recommend to visit
[https://learngitbranching.js.org/](https://learngitbranching.js.org/) to
understand git better instead of using various wrappers.

------
black-tea
This was bound to happen. The whole world moved to git without really
understanding why. First we started to make "hubs" and bless their copies of
the repo. Then people will start to strip and simplify git itself. Slowly but
surely they will reinvent Subversion.

~~~
Certhas
gitless is just as expressive as git though. It's just a better interface with
less state. Nor is it new. Check out their research paper.

~~~
kernelpicnic
It's not. They removed staging and haven't implemented all the features and
flags the git CLI has.

------
byteface
so put this in my .bashrc?

function gl() { git $* }

------
yarrel
A simple text editor built on top of Emacs.

~~~
bendunatosia
2.50 per cent, that born in Asia by 4.47 per cent, that aged less than 15
years by only 0.46 per cent. Interstate annual population growth rates
currently (1999–2000) vary between 1.7 per cent (Queensland) and –0.1 per cent
(Tasmania), while massive differences exist in the direction, scale and
components of population change in regions and communities. This paper takes
the approach not so much of predicting the future as of exploring what will
happen if demographic trends and tendencies evident in the mid- to late 1990s
continue to evolve in the directions they seem to be moving in. No startling
predictions are made of major reversals of trends. Instead the emphasis is
placed on what seems likely given current trends and patterns in other
developed societies. In many respects Australia’s current situation is in the
middle among OECD nations, and seems to have further to go in some areas,
including population distribution

------
hackpr
Yes. Git is powerful, but sadly has deep problems in its conceptual design.
This is the reason why even mid-level engineers don't understand it fully.

Love this work!

~~~
arximboldi
Can you elaborate on the deep problems? I personally find it relatively
conceptually elegant.

~~~
paulddraper
I compare it to 10-15 years ago, when functional programming was rather rare.
Mid-level OO programmers would complain it was confusing and unfamilar,
whereas in reality has beautiful and simple concepts.

Git's use of a DAG is confusing and unfamilar for many programmers, though in
reality it's beautiful and simple.

~~~
theonemind
The DAG is the easy part. I can understand perfectly well what I want to do
with the DAG and have no idea how to get git to DO it.

~~~
adrusi
Pretty much this. Fortunately the command you need is usually a quick Google
search away, and a sequence of basic invocations of branch, checkout, merge,
rebase and commit are usually enough to transform the DAG however you want,
even if there are simpler ways to do it.

