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!
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.
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 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.
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.
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.
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.
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.
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.
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 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).
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.
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 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.
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
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...
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!
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.
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.
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.)
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
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.
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.
67 comments
[ 4.4 ms ] story [ 137 ms ] threadSome discussion with the author present on reddit: http://www.reddit.com/r/programming/comments/1kqotu/ungit_ne...
Excellent.
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).
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.
Otherwise, it looks very very cool.
If you ignore the staging area, you become much more tempted to make several unrelated changes in one commit, rather than untangling them.
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....
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 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.
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 really love bzr's UI in this respect, and I understand Mercurial is similar too.
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.
YMMV, of course.
The staging area surely adds complexity, but if you do not like it then simply don't use git.
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.
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
Then again, I guess the GUI could just implement the staging area itself and pass line numbers to "git commit" :)
He is telling the whole world what he thinks of them.
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...
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. :-)
PR -> https://github.com/FredrikNoren/ungit/pull/91
Edit: added PR
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
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
[1] http://www.sourcetreeapp.com/
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!