
Ungit – Git UI that makes you understand git - rplnt
https://github.com/FredrikNoren/ungit
======
rplnt
Quick video introduction:
[http://www.youtube.com/watch?v=hkBVAi3oKvo](http://www.youtube.com/watch?v=hkBVAi3oKvo)

Some discussion with the author present on reddit:
[http://www.reddit.com/r/programming/comments/1kqotu/ungit_ne...](http://www.reddit.com/r/programming/comments/1kqotu/ungit_new_git_ui_that_makes_you_understand_git/)

~~~
fuddle
You should add this or a screenshot to the Github page.

~~~
anigbrowl
Indeed. Life is short - if there aren't screenshots, I'm not willing to put in
the time to find out whether I'm interested or not. As it happens, this is a
very nice looking project, which makes the absence of screenshots even more
surprising.

------
dz0ny
I'am not comfortable using this, because by default he is collecting all debug
and analytics data. If he is from Europe he might be also breaking the
law(depends on country) by doing this.

PR ->
[https://github.com/FredrikNoren/ungit/pull/91](https://github.com/FredrikNoren/ungit/pull/91)

Edit: added PR

~~~
mjs
Going from the comment in the config file, "debug" data is only collected if
the application crashes.

Google Analytics is hooked up by default though, which is unusual. (Actually
I'm not sure how that's going to work, since everyone's going to be on a
different domain name.)

[https://github.com/FredrikNoren/ungit/pull/91/files#L0L16](https://github.com/FredrikNoren/ungit/pull/91/files#L0L16)

------
norswap
From the video, it looks like all changes are automatically staged. Ignoring
the staging area is not going help users understand git I think.

Otherwise, it looks very very cool.

~~~
StavrosK
I think the staging area is a horrible idea. It greatly complicates the UI
("diff --cached"? Really?) without providing many benefits (if you want to
commit just some files, you could simply specify the names at commit time.

I really love bzr's UI in this respect, and I understand Mercurial is similar
too.

~~~
Nervetattoo
You couldn't run tests only on your staged changes pre-commit without the
staging area. Right now my pre-commit hook stashes any non-staged changes,
from inside the same files that has staged content, and then runs tests. This
ensures I can create commits with just the stuff that works of my changes
without first removing the ongoing work.

The staging area surely adds complexity, but if you do not like it then simply
don't use git.

~~~
StavrosK
> This ensures I can create commits with just the stuff that works of my
> changes without first removing the ongoing work.

If I have ongoing work I want to remove, I just stash it, as you said. I don't
need a staging area to stash things, and it's pretty rare that I'll have
unrelated work anyway.

> The staging area surely adds complexity, but if you do not like it then
> simply don't use git.

Ah, the old "your arm hurts? Just cut it off!" solution. Yes, I will just not
use git, I will just email my team diffs.

------
ivan_ah
screenshot: [http://i.imgur.com/hovCdWP.png](http://i.imgur.com/hovCdWP.png)

VERY COOL. I love the idea.

If you can make somehow easier to use (for non developers) this could be a
life saver. Your designer is not expert at git... so you decide to just email
each other stuff.... OR.... you show him/her how to use ungit and BAM! they
are in your world with no command line invocations required.

Could you drop the node.js dependence and wrap the entire UI as a chrome
extension? Is there git in the browser? Of course, you would still need some
"server" to access the file system...

------
iaskwhy
GitHubg related: FredrikNoren got unlucky with the GitHub generated avatar.
Maybe they could provide the users with a way to generate a new one.

~~~
Mithaldu
He can upload whatever he wants, so i don't see the issue.

~~~
iaskwhy
I believe he can only upload a picture to Gravatar which then is used by lots
of apps. Even Gmail if I'm not mistaken. So it's either the middle finger or a
selected Gravatar everywhere. I still prefer my suggestion.

~~~
killercup
If you have more than one email address set up in GitHub, you can choose which
one's Gravatar to display.

------
pedalpete
I watched the video, and it looks really cool, but the way I was taught to use
git was to create a branch, make your changes, commit the changes, then merge
back to master, rinse and repeat.

Is that not the standard way of using github? How does that look in this
scenario? Everything almost always being in a straight line, and the author
always working on 'master' makes it a bit confusing to imagine in a real-world
scenario (based on my Git usage).

~~~
jlgreco
If I am only working on one thing at the moment, I typically just make a lot
of commits on master then rebase them all before publishing them. I only start
branching if I'm doing multiple things at once. (And it is pretty easy to move
changes to a branch later if you want to start work on something else.)

~~~
zeppelinnn
I think this is correct for personal projects, but when working with teams
it's better to create dev branches especially for major feature/functionality
additions. I personally try to stick with separate branches and then merge
just to uphold that practice, as well as being able to revert/find your mess-
ups quicker.

~~~
jlgreco
Feature branches in git most frequently only live on the developers machine,
often for only a few hours, _(unlike feature branches in centralized version
control systems, which are almost always long-lived)_ so there is no harm in
not branching if you're only working on something thing . If it is a feature
that multiple people need to work on, or needs to be worked on for more than a
few hours, then a separate feature branch is of course the correct thing to
do.

Branches in git are literally just pointers to commits _(write a sha1 object
to any file under refs /heads to see what I mean)_ so they don't really buy
you much if you're not frequently switching between locations in the DAG, but
can be created retroactively with zero hassle if you do find yourself needing
them.

Basically, what you do with your private DAG doesn't matter at all, what is
important is that you only publish things that are sensible.

------
tunesmith
The tree graphics are really cool. I'm trying to figure out how that was done
- it doesn't look like it's D3.js, which still lacks graphviz-style layout of
trees. It looks like it might actually use graphviz behind the scenes, but
then I'm not sure how it animates from one tree to the next when it changes.

~~~
xxbondsxx
Most likely a custom algorithm -- I had to make my own for LearnGitBranching
since most tree algorithms don't exactly fit the needs of a VCS visualization.
Imagine the author did the same, but its all open source

------
btbuildem
Very nice, installing now.

Please add the video to the GH page.. I almost meh'd out of there, but was
lucky to notice someone's comment here mentioning the youtube vid.

EDIT: just tried it.. Dear god, our repo looks like a swarm of drunken spiders
was hard at work there..

Also, +1 to the request to change the default config and not track everything!

------
flog
Great. I hate the git CLI and constantly shoot myself in the foot with my
ignorance.

UX wise I don't know if the drag and drop works 100%. As a suggestion to the
author, how about drawing lines instead from the working node to a future node
state? 2c

------
contingencies
I put some of our non-devs on _git_ today for managing a complex and growing
set of legal documents. They use SourceTree[1], which is a great GUI that
Atlassian bought recently. All they needed to understand was 'add' (to index),
'commit', 'push' and 'pull', which took about 10 minutes to communicate on
Skype.

[1] [http://www.sourcetreeapp.com/](http://www.sourcetreeapp.com/)

------
guynamedloren
This is awesome. I'm building a 'github for non-developers' and I think I'm
going to fork this and integrate it into my project. One of the goals is to
have all of the features and benefits of git but masked behind a clean,
intuitive UI. This project fits that goal perfectly. Thank you!

------
ecuzzillo
One of the most common failures of understanding I come across when people
first start trying to use git is that there are two dimensions of parallelism:
between branches in one repo, and between repos. This can't address that, as I
understand it, because it works on one repo at a time.

------
jtagen
info: Inception error sending error to bugsense 0=null, status=402, data=[],
error=Throttling limit reached.

Excellent.

------
pertinhower
Neat. Not vastly different from gitk. Crashes for me after I try the fetch
button.

------
perlgeek
I teach introductory git courses at work, and I think I'm going to use ungit
to show the commit graph is built, what happens when you leave a comit behind
etc.

------
kemist
Great work! You're off to a good start. I like the visualization, the intro
video, and the easy install. I look forward to seeing it improve.

------
johnnyg
Love the concept.

The npm install errored out, I got it going via sudo, loaded a large project
with it and it crashed.

I will be back in a month to have another go. :-)

------
shangxiao
I personally believe that "tig", a TUI for git, is easier to use than this.

------
denrober
Works for me but almost unusable on anything but the simplest of repositories.

------
jonahx
This UI is slick. The whole thing seems well designed. Very nice work!

------
jtagen
Crashes like crazy for me. Hopefully report to bugsense will help.

------
twodayslate
This is awesome. Thanks for sharing. It looks really clean.

------
jliptzin
Cool. Won't replace Tower though, for me at least.

------
denysonique
It would be nice if you packaged it in node-webkit

------
a5m0
How does this compare to gitorius or gitlab?

