
Purposes, Concepts, Misfits, and a Redesign of Git - ingve
http://neverworkintheory.org/2016/09/30/rethinking-git.html
======
zokier
While I don't think git couldn't be improved, especially in terms of ux, I do
feel like losing staging area altogether is quite significant sacrifice, like
throwing the baby with the bathwater. The ability to build up and massage the
commit in staging is really powerful method, and I think it makes git actually
easier to learn once you get beyond the initial hump due its interactive
nature.

~~~
rspeer
Aside from selective commits (which they provide a different interface for),
what do you use the staging area for?

~~~
acemarke
That's kinda the point, though. I don't want to run a single command to both
define and complete the commit. I want to be able to do it in steps. Review my
modified files, pick and choose what's staged, maybe make some more edits,
stage those, double-check the staged diffs, verify the commit has what I want,
and _then_ hit the button.

~~~
david-given
But isn't this what changelists do? I've certainly done pretty much what you
describe in hg, svn and Perforce, which don't have staging areas.

Also, if you end up committing only _parts_ of files, then how do you know
that what you commit works?

~~~
to3m
Well, you don't, so... don't do that. Same thing goes for Perforce; you can
already create multiple changelists that you commit independently, so it's
easy enough to create a bad commit, because it contains only some of the
changes you've got locally.

What you're supposed to do in Perforce of course is to create your changelist,
shelves the others, make sure your proposed changelist works independently,
and commit it only when it does. Which is analogous to what you're supposed to
do with git:

    
    
        - stage parts of files
        - `git stash -k'
        - check it works
        - `git stash pop'
        - commit
    

But let's be serious here - the true advantage of git comes when you do the
pro move.

    
    
        - stage parts of files
        - commit
        - (90% of the time) it's good
        - (10% of the time) bzzt... it's bad
    

Now, if you were using Perforce, in the 10% case, you'd be stuffed. Somebody
would come over to your desk.

    
    
        - (them) "Your commit is broken"
    

Now what can you do? There's no denying it... you gone done fucked up, and
there's no denying it.

But with git, you have options. So let's try that again.

    
    
        - (them) "Your commit is broken"
        - (you) (confident tone of voice) "Ah no, you are using git incorrectly, you forgot to git fetchpack
          --inflate-upstream-probability-leaves --deny-downstream-packs 
          --integrate-sideway-arguments --discombobulate-flat-file-compressed-alignment-jobs
          -P -Q -J 5 -N 311 -X 0771 -R 0x134774"
        - (them) (uncertain)
        - (you) (confident gaze. Straight into their eyes. YOU = TIGER)
        - (them) (increasingly uncertain)
        - (you) (unblinking gaze. You have the upper hand. YOU = 2 TIGERS)
        - (them) (wanders off to try your technobabble)
        - (you) (fixes your commit)
    

There's an xkcd about this.

The advantages, I think, are clear.

~~~
rakpol
Aah, sweet, someone else who uses Perforce! I've been wondering, do you use
version control as:

1\. a way to record logical changes to files (e.g. implement two features
without making any commits, then when you're done, pick out the files/chunks
that encode each feature and create commits out of them),

2\. a record of history (e.g. just start writing code and make a commit every
time you compile/run tests without unexpected failures),

3\. something else?

I've found it very painful to apply my git-adapted workflow to Perforce: I
_want_ to just start coding, testing out various possible design choices and
implementations instead of only theorizing about them, but can't (e.g. "I
wonder if I could factor out these methods + fields into a different class?"
Perforce: oh well, I guess I should write it down somewhere to remember for
later. Git: branch my current work, spend five minutes sketching an
extraction, then realize it's insane and continue working). Am I crazy and
just don't realize ow much better the Perforce model is?

~~~
to3m
Well, I used to use it, at least!

I actually came to quite like it, but the workflow was sometimes a bit
tiresome :( When I found myself the situation you describe, potentially
wanting to make an additional change while already working on another, I did
exactly what you suggest: add a todo item, and carry on until I'm done with
the task at hand. Then start my second change with nothing checked out, so I
can undo checkout on everything should I make a mess.

This works, and you get used to it, and of course many would say that it's a
better approach - but it would be nice if the Perforce client tools could be a
bit more imaginative.

As for how I think of version control, if it's git, #1. If it's Perforce, #2,
plus #3 - backup and distribution.

I don't know how much value I get from being careful about my commits with
git, but it does make me feel better (which I suppose could be reason enough).
On the large-scale, goal-oriented projects that I've used Perforce for,
worrying about logical changes has never felt very important. Does it make a
big difference if you have one commit that implements 3 features, or 3
commits? When you're trying to fix a bug, you don't really mind either way,
because (a) bugs don't respect feature boundaries, (b) all the features are
non-negotiable, so it's not like you can back one out and carry on anyway, and
(c) the project is large and fast-moving enough that even if you could,
there'd be a good chance that actually, you couldn't.

What history tends to come in useful for when it comes to this sort of
project: finding the code that corresponds to a particular build that you have
a bug report for, and finding who made a particular change so that you can ask
them about it (using the imeline view say). These both work fine whether you
make granular changes or not.

You might want to be a bit more careful about things if you're working on
changes that might want to be merged into another branch on an individual
basis. (Suppose you're moving spot fixes from release branch to main branch -
some you'll want, some you won't.) But you usually know when you're making
this sort of change, and so you work that way anyway.

------
c3RlcGhlbnI_
The paper doesn't discuss much how their implementation does better on their
listed issues. One particularly interesting issue git has is referred to at
one point as "Incoherent Commit":

"The problem with commit is that it constitutes a violation of the coherence
criterion: the same concept (commit) has more than one, unrelated, purpose:
make a set of changes persistent (P1) and group logically related changes
(P2).

"These two purposes are not only unrelated, but in tension with each other. On
the one hand, you would like to save your changes as often as possible, so
that if something bad happens you lose as little data as possible (thus
encouraging early committing). On the other hand, a logically related group of
changes usually involves multiple individual changes, which means that you
might be working for quite some time before you have enough changes to group
(thus encouraging late committing).

Now a fix for that would be useful. Git only provides you with the ability to
create a graph, and you get to choose what you use it for. You have to choose
though because there is only one graph. Gitless doesn't seem to fix this
problem, you still have to choose what goes into your final commits. Though I
don't know what you could do about it without changing git to support
something like grouping commits into blocks that are modified as a unit.

~~~
tbrownaw
Git allows you to do violence to history: it's very much _possible_ to commit
regularly as you work, and then rearrange those commits later to be more
logical.

I have no idea how _easy_ this is, but I've seen plenty about how horribly
impolite it is when you rearrange any history that other people have seen.

~~~
tylorr
It helps if you keep unrelated code in separate commits. That way all you have
to do is rearrange and merge commits. It gets more complicated if you have to
split commits. I've been wanting to make a GUI for this purpose that allows
you to drag and drop hunks/commits. Essentially a GUI for interactive rebase.

And yes, don't change history others have seen, but do it as much as you need
locally.

EDIT: typo/clarity

~~~
convolvatron
what this really means in practice is "never branch off anything but master"

which is ok for maintenance bug fixes, but precludes a lot of interesting
workflows involving speculative work, late binding the order of commits, early
integration branches, etc.

my workaround for this usually just involves doing what i want up front, and
then abandoning git for the merge process (since my history is polluted by
false conflicts), constructing diffs and applying them as single commits
against master.

which works, its just a bit silly

------
toomim
Wow, I'm trying this out on my git repositories and it's great! Look how
simple it is to "install":

    
    
        tar xzvf gl-v0.8.3-darwin-x86_64.tar.gz
        sudo cp gl-v0.8.3-darwin-x86_64/gl /usr/local/bin/
    

Now you can play with the commands on any git repository:

    
    
        $ cd ~/projects/farmhouse
        $ gl diff
        
          # Woah cool!  It uses whitespace to separate blocks!
        
        $ gl branch
        
          # Wow, this not only shows you the branches, but explains
          # all the other branching commands, like how to switch
          # branches!  Now I know that I can just:
        
        $ gl switch master
        
          # done!
    

And because it's just an alternative wrapper for git, you can switch back and
forth, at any time, on any repo.

------
Pharylon
The original paper is here: [http://people.csail.mit.edu/sperezde/pre-print-
oopsla16.pdf](http://people.csail.mit.edu/sperezde/pre-print-oopsla16.pdf)

Their "veneer" of git is here: [http://gitless.com/](http://gitless.com/)

~~~
randomsofr
> Many people complain that Git is hard to use.

Really? Do people think that?

~~~
wbkang
Yes and the paper in the article tries to explain conceptually why it can be
hard to understand.

------
gwenzek
I had to teach git to 10 non-developer (for small configuration code, and
configuration files) used to SVN. The stagging area wasn't really a problem to
learn.

Most of the problem they had came from stashing: "I want to pull but git
doesn't want to !"

Or changes following you when switching branches: "I worked in developed, now
I'm back to master and I have all this files modified!" Which could lead to a
"reset --hard" for getting rid of those changes, which was generally regretted
after that!

Also I had a few detached head states due to simple double-click on a commit
name in the UI that resulted in a checkout, when they just wanted to see the
commit log.

Finally a lot of confusion arised from using SourceTree that shows you a
window with ten options every time you try to pull. (SourceTree wasn't my
choice)

So I think gitless does provide an improvement by getting rid of the stash,
but I don't really see the point of removing the staging area.

------
no_protocol
Can anyone share other git porcelain projects? I'm especially interested in
any that are not necessarily intended for use with code. Think more along the
lines of writing or something, maybe. Any kind of refs juggling that isn't
just standard git.

~~~
rurban
magit being the most prominent and most widely used. Within the emacs GUI.
Makes most of those tasks much easier.

Hub is a prominent GitHub remote porcelain tool.

I also want to point out shell prompt tools to display the current git status,
which would have helped in many of those misfits.

~~~
isxek
_magit being the most prominent and most widely used. Within the emacs GUI._

Since magit was mentioned, I'll add 'fugitive', the Git wrapper for Vim
described to be 'so awesome, it should be illegal.'

------
throw2016
I am sure like all things Git can be improved and I think the idea that users
are not open to improvement is more often than not a defensive response from
those whose idea of 'improvements' do not resonate.

It's always dubious for those with new offerings to dismiss criticism as
'resistance' and 'defensiveness'. This is extremely disingenious and
intentionally takes things from the technical to the political.

They have taken up a marginal use case which matters to them which is fair but
then try to dress it up as a git weakness with an elaborate paper which plays
up their use case and scatters around strawmen like 'Git is difficult to use'
unquestioned. Isn't it possible that the 'shortcomings' are not an issue to
other users who may not identify with the use case highlighted and may not
perceive it as an 'improvement'.

I think git stands alone in stark defiance to a growing culture of complexity.
Given the scope Git could have been an extremely complex and bulky piece of
software.

Its a testament to the experience of the authors that it is accesible to most
and used by millions.

I have no doubt in lesser hands Git would be hugely more intricate and a
complete pain to use.

------
robot
People take version control for granted (thanks to git) and then claim it has
" design flaws and misfits".

It can be tailored to be more user friendly sure. But the original philosophy
of git was to build distributed version control system that is efficient,
straightforward, and dependable.

All of those goals are achieved with its design and improving on this
foundation is certainly possible. These were all hard problems to solve at the
time, given the state of the art was CVS, subversion and perforce.

~~~
NumberSix
"People take version control for granted (thanks to git)..."

Nonsense. Version control software has existed and been in widespread use
since at least the 1980's.

[https://en.wikipedia.org/wiki/Revision_Control_System](https://en.wikipedia.org/wiki/Revision_Control_System)

Walter Tichy released RCS in 1982. CVS is derived from RCS, Subversion from
CVS.

~~~
kazinator
CVS was released to Usenet as shell script sources only in 1986; not that far
after RCS.

Subversion is not derived from CVS; it was a project inspired by problems in
CVS, to replace it.

~~~
NumberSix
From [http://svnbook.red-
bean.com/en/1.7/svn.intro.whatis.html#svn...](http://svnbook.red-
bean.com/en/1.7/svn.intro.whatis.html#svn.intro.history)

Subversion's History

In early 2000, CollabNet, Inc.
([http://www.collab.net](http://www.collab.net)) began seeking developers to
write a replacement for CVS. CollabNet offered[3] a collaboration software
suite called CollabNet Enterprise Edition (CEE), of which one component was
version control. Although CEE used CVS as its initial version control system,
CVS's limitations were obvious from the beginning, and CollabNet knew it would
eventually have to find something better. Unfortunately, CVS had become the de
facto standard in the open source world largely because there wasn't anything
better, at least not under a free license. So CollabNet determined to write a
new version control system from scratch, retaining the basic ideas of CVS, but
without the bugs and misfeatures.

Note "retaining the basic ideas of CVS, but without the bugs and misfeatures."

derive

base a concept on a logical extension or modification of (another concept).

~~~
kazinator
Subversion doesn't have a shred of CVS code in it and uses completely
different storage algorithm and versioning paradigm, radically different than
CVS's "tree of RCS files permanently shaped like the working copy and
individually versioned".

The basic ideas of CVS in SVN are the central repo mode with unreserved
checkouts.

In SVN, new versions create new entire tree nodes which hare numbered.
Branches look like subdirectories and there is renaming support. It's just an
entirely different animal.

The SVN project blogged about CVS because that was their target "market" that
they wanted to overtake. They trumpeted that they are making something better
than CVS to which CVS users could convert.

It's not derived from CVS any more than Adobe Photoshop is derived from MS
Paint.

------
js8
I fail to see how Git has a bad UX.. the way it took over other CVSs by storm
suggest that those systems had UX that was significantly worse. In fact, I
think you would be hard-pressed to find a recent piece of software which was a
bigger success, UX-wise.

Or why is Git popular, then? Could Github be built on, say, SVN? Many times in
IT, popularity is also driven by support of a large corporation, but it was
non-existent in this case.

~~~
sofal
I think Git's success over solutions like CVS or SVN is the superiority of the
underlying data model in its ability to take into account the complexity
inherent in software being developed by multiple people at once, while at the
same time allowing for individual developers to effortlessly fork their own
various tasks.

~~~
gkya
I guess git's success owes most to the Torvalds as mercurial was started
contemporaneously and quite similar in being a DVCS.

------
Meic
Those who do not remember cogito and easygit are doomed to reimplement them.

------
PrimeDirective
There's not a goddamn thing that's fundamentally wrong with git. My worthless
2c.

~~~
forrestthewoods
Sure there is. It's inscrutable and utterly non-discoverable. Even programmers
need a dedicated Git expert on staff to help escape bad states. Non
programmers are utterly helpless.

Also it fundamentally can't handle binary files well. This causes great pain.

~~~
PrimeDirective
I guess lots of things have barriers and might not be for everyone. Don't mean
they're flawed. Also, git can't handle my laundry. That causes great pain.

~~~
crimsonalucard
Right, but barriers that a high percentage of users experience means it's a
flaw. This factor cannot be ignored.

Taken to the extreme your statement is essentially: "Git works for me and me
only therefore it is flawless."

