
Reinventing Git interface - atemerev
http://tonsky.me/blog/reinventing-git-interface/
======
peterlada
Love it, I've always understood the conceptual model (perforce has the same
one) but I'm always running afoul on git's "helpful" CLI commands. This would
solve almost all the issues and has the promise to educate designers/analysts
on how to correctly think of versioning by making it visual.

The project could start out by creating the visual interface (D3,js?) and
spitting out the appropriate git CLI commands for whatever was done by
dragging and dropping. Phase 2 would be to integrate the web server into the
git project.

------
tomp
Wow, this is totally the Git Interface of my dreams. Is this just a concept,
or do you have a working prototype?

~~~
tonsky
Just a concept

------
jeenajeena
Love the drag and drop argument. As a matter of facts SmartGit allows several
operation via d&d: you can reset, rebase and rebase interactively just using
the mouse

------
delfinom
I just wish people stop calling it GIT instead of git. It's not an
abbreviation for anything, it's literally the same as the english insult.

~~~
dragonwriter
And, anyway, abbreviations in general aren't usually all-caps either (
_initialisms_ often are, but that's a very specific subset of abbreviations.)

------
donaldisfreak
That's great idea. #git

------
cryptonector
Sigh. "grow-only", "rebase is dangerous", "detached head state is dangerous".
STOP. Stop it now.

git is a bag of commits organized into a tree (a tree of Merkle hash chains).
Branches and tags are symbolic names for these. Think of it this way and
there's no danger.

Indeed, _published_ repos/branches must not be rebased. That's what receive
hooks are for: to reject non-fast-forward merges. If you don't understand a
word of the previous sentence, don't worry: you're just not ready to run a
public repo.

What is dangerous is:

\- pruning repositories

\- lack of pushable (and pullable) reflogs

Reflogs are what makes it easy to recover if you lose a symbolic name and
you're left with a pile of commits you'd not find your way through: the reflog
tells you what you did and gives you the commit hashes you need to find your
way home.

I often push from detached head state, and I did so today. Here's what I did:

    
    
        $ git remote add contributor https://github.com/contributor/project
        $ git fetch contributor
        $ git checkout contributor/their-branch
        $ git rebase -i origin/master
        <fix up some things>
        $ git push origin HEAD:master
        $ git checkout master
        $ git merge origin/master
    

Yes, that's advanced usage, and in particular the push command-line can be
dangerous, so learn exactly what "git push origin HEAD:master" means before
copying that, but compare now to the crutches equivalent of the above:

    
    
        $ git remote add contributor https://github.com/contributor/project
        $ git fetch contributor
        $ git checkout contributor/their-branch
        $ git checkout -b their-branch
        $ git rebase -i master
        <fix up some things>
        $ git push origin master
        $ git checkout master
    

Or, maybe I could have told the contributor to rebase and fix those things. Or
maybe I could have merged the contribution and then committed said fixes. But
I like clean history -- I've been taught to by the very best.

I didn't need a local branch crutch to find my way around because I know the
model: a tree of commits.

Understanding the model is the key.

There are other VCSes that also use Merkle hash trees. Internally they have
the power that git has. Mercurial's language for expressing refs is great.
Fossil has all the power of SQL, and it shows. But they all try oh so hard to
hide the model from me. It's not like hiding what a process is from a non-
developer user. SourceTree does a great job allowing non-developers to
understand their version trees, so I know this is not too hard on non-
developers. Yes, non-developers should mostly never rebase, but detached head
state is useful for them: because sometimes they need to "see" old versions,
so they end up branching, and so they end up merging, and guess what: merging
is what's not easy for them.

If you want to help non-developers use a VCS, give them a better UI for
dealing with diffs. Don't punish the rest of us by hiding the wrong thing from
everyone.

~~~
tonsky
I’m writing exactly about that. GIT model is simple and operable, so UI should
not hide it behind “wizards”, but incorporate more direct use of it.

~~~
delfinom
It's git not GIT. Stop making it an abbreviation.

