Reinventing Git interface

peterlada · on June 19, 2014

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.

jeenajeena · on June 19, 2014

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

tomp · on June 19, 2014

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

tonsky · on June 20, 2014

Just a concept

delfinom · on June 19, 2014

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 · on June 19, 2014

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

donaldisfreak · on June 18, 2014

That's great idea. #git

cryptonector · on June 18, 2014

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.

dnr · on June 18, 2014

Did you actually read the article? It sounds like you're in violent agreement with the author.

tonsky · on June 18, 2014

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 · on June 19, 2014

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

cryptonector · on June 18, 2014

Maybe "hiding what a process is" is not that good an analogy for "hiding what a modern VCS is under the covers", after all, users know to use task killers on just about... every OS. Or maybe that is a good analogy: users need to know how to kill runaway/non-responsive apps. Calling processes "tasks" or "apps", or something that will mean more to users is a very good idea, but you can't entirely hide the concept from them. (For many elderly people even that is too much.)

Here's what I think might help users: a) better diff/merge tools (like github's new image diffs), b) better integration with VCSes in every application that produces content (e.g., Adobe Photoshop), c) better visualization of the history tree.

For (c) I'm thinking of a D3-style graph, with recent branches taking prominence (whether named or not). Mouse around the graph to pick out branches, mouse over commits/heads to get a blurb (branch/tag name, last commit metadata). Something that feels alive and dynamic. Not these static, boring branching graphs we've all seen before that look like SVG renderings of ASCII art graphs taken from manpages. Static graphs become difficult to display and use when the number of branches increases past a handful.