Ungit – Git UI that makes you understand git | Hacker News Reader

Ungit – Git UI that makes you understand git

github.com

243 pointsrplnt65 comments

Quick video introduction: 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...

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

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.

YES! When I realized I had to run it to see what it does, I was immediately turned off. The demo of the thing that is supposed to make things easy should also be easy. Still looks like a pretty cool tool!

Just submitted a pull request with a screenshot.

I love git on the command line but you definitely need to expose this to people, as it's a really sexy UI with all the animations and all. I almost wish I could see this representation alongside traditional git add/commit/push/pulls

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

Edit: added PR

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

Yup you're absolutely right, this was something I just left from the dev days and didn't think too much about. I've merged the PR.

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.

Agreed; the ability to commit a subset of the changes in your working directory makes it far easier to make a large number of small, focused, single-change commits. Tools like "git add -p" make that even easier.

If you ignore the staging area, you become much more tempted to make several unrelated changes in one commit, rather than untangling them.

I agree.

The git UI has some warts, but the staging area isn't one of them. It's an extremely useful feature, and a true improvement over traditional SCM interfaces.

It's nice to see people wanting to improve git's interface, but please, don't just dumb it down....

The staging area doesn't really help much with that, though. Too often there are unrelated changes to the same file, which are precisely as inconvenient to split up as those in separate files without a staging area.

That's exactly what git add -p does, and it's vastly more convenient than when you don't have a staging area.

I find the problem with git add -p is when you have changes that are overlapping - e.g. you've tried a few variations of implementing something, that have many commonalities - but sadly you didn't commit them as you went along, but now what to, for reference in case they are needed later.

git add -p doesn't help tease them apart, because its hunks are based on diffs, and the granularity usually does not coincide with actual changes (nor syntax or semantics of the languages). Which is really expecting a bit too much! Diff's implementation of LCS algorithm is incredibly fast and works amazingly well for changes in different places.

So what I do is edit the file to what I want, stage and commit, then undo and continue. This doesn't really use the staging area, and I'm hoping there's a better way to do it... if anyone can think of one?

I don't use `git add -p` much, since i commit exclusively with `git gui`. The reason being that `git gui` allows me to stage single lines, or hunks AND allows me to change the granularity of hunks on the fly. Even if that isn't an option for you, i'm sure that `git add -p` has a command to modify hunk granilarity.

One thing that I've found handy on a few occasions is Atlassian Source Tree. You can stage individual lines, not just individual hunks. Sometimes that makes it much easier to pull apart the changes.

git add -p, then "s" until it can't split the hunk any more, then "e" to edit the hunk manually?

you can do it, but I've found in some cases that modifying patches (including "e") becomes more complex than stating the desired result directly.

The staging area makes it possible to split them up by selectively adding lines to it with `git add -p` or the much superior `git gui`.

I actually started of having the staging area use git add etc. and being just a reflection of what was staged. But that meant I either had to manually add each file (or have an "add all" button), or automatically stage them. The first option felt wrong because most of the time you just want to commit all the changes, so in most cases it's just more work for the user. The second option felt wrong because I didn't want to change around the git structure "behind your back" (just starting ungit shouldn't mess up your repo); so I went with just having it in the ui and doing the real git work on commit. In general I want it to be as close to git as possible but I hope this trade off made sense with this little explanation :)

In the small scale your rationalization is logical, however in the big picture you're going to end up with teaching people to make useless commits. As long as this is true of ungit, it is a project i will have to vehemently recommend against in any circumstance.

What ungit should do is the same thing as git gui: When you go to make a commit, you can view diffs of your files and select single lines to be added to your next commit.

Edit: I've created an issue for this: https://github.com/FredrikNoren/ungit/issues/98

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.

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.

> 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.

If you are using a recent git version, you can use diff --staged instead - diff --cached is there for existing users.

Specifying names at commit time is really horrible - it's more error prone and harder to get a diff of exactly what you are committing.

You can also commit part of files using the staging area by doing git add -p. My workflow is often git add -p; git diff --staged; git commit

And, alternatively, you can use `git commit -a` if you want to bypass the staging area.

You could use git commit -a, but I've found that seldom does what you want. Usually, you don't want to commit all files, because you've made unrelated changes to configuration, debug logging etc. And sometimes you don't even want to commit all the changes in a single file, and git lets you choose which diff sections ("hunks") to commit with git add -p.

I came to git already knowing what a dag was, and after having cobbled together my own patch management system to make up for deficiencies in svn, so I didn't have much difficulty intuiting almost the whole of git after very little time.

I came to git from bzr, and I always use commit -a these days. If I want to ignore a file, I just specify the ones I actually want to commit, and it works just fine for my purposes (I don't generally make irrelevant changes).

YMMV, of course.

I am avoiding git's CLI like the plague, but IMHO the staging area is awesome to use with a GUI like Git Tower - it was never that easy to stage (and commit) line by line, leaving out stuff like printf debugging that shouldn't go down the wire.

Then again, I guess the GUI could just implement the staging area itself and pass line numbers to "git commit" :)

Yes, exactly. Atlassian's client (I forget the name) has that feature too, and it's great, but it can just do it directly if there's no staging area (as it does with hg, I assume). If you're in the CLI, you can use the exact same command you use to stage stuff to commit stuff, and then there's exactly zero benefit.

I spent a depressingly long time using git before understanding how the staging area worked.

I think hiding it under a novice/expert flag is a terribad idea, but I'm not sure what the right way to expose the staging area in this interface would be.

Not at all -- you can uncheck some files, and only the checked ones will be committed.

screenshot: 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...

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

That is hilarious!

He is telling the whole world what he thinks of them.

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

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.

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

What's wrong with his avatar?

It's one of the ways (maybe the most common way) to draw a pixelised middle finger.

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).

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.)

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.

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.

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.

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

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!

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

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/

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!

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.

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

Excellent.

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

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.

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.

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. :-)

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

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

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

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

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

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

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

How does this compare to gitorius or gitlab?

Reply on news.ycombinator.com