101–110 of 144 posts
Great work. I recently found a very practical use of Git. I call it the "Poor man's hot code loading". This is a post i just wrote on it http://blog.mawuli.me/2013/02/poor-mans-hot-code-loading-git...
Earlier quoted context omitted.
What's the point of having a close button on a dialog window that doesn't close the dialog?
I also found this really confusing, just in general the "OSX window" design made me think I could close them, minimize them, move them, etc (which would have been really useful, especially the 'goal' window). The app in general is supremely awesome though, I love it, I hope github hires the author to fully flesh it out and make it part of their tutorial. It is insanely useful for people whom are new to git.
Earlier quoted context omitted.
I also found this really confusing, just in general the "OSX window" design made me think I could close them, minimize them, move them, etc (which would have been really useful, especially the 'goal' window). The app in general is supremely awesome though, I love it, I hope github hires the author to fully flesh it out and make it part of their tutorial. It is insanely useful for people whom are new to git.
Ah!! I just realized people were clicking on those silly little buttons I had on the top... I totally added them simply for design flair. For now I'll add a nasty alert that they don't actually work, but eventually it would be cool to bind them to close events...
If you created a way for a company to easily define levels that mimic their typical workflow it would be a great on-boarding tool for new employees, a great interview tool and also a great reference tool for 'i need to do X, how does the company prefer I do X?'. I can definitely see this justifying a subscription fee for a lot of companies.
Awesome work! I really wish this had existed when I first learned git.
Earlier quoted context omitted.
Thanks a ton for catching this. I guess there is a distinction to be made -- the compression might use delta's, but a commit specifies the entire state of the repository. It's a tricky line to walk though, because commands like "git show" and "git patch" clearly show the delta-like nature of a single commit. I also don't want newcomers to think that commits are heavy and should be used sparingly. I'm totally down to…
This is still not quite correct. Let me outline the structure, and then I will try and submit a PR addressing it. The first step to committing is staging what should be included. The staging process specifies an index of files that are to be added to the next commit. When the commit is recorded, git checks every file/chunk in the index; a hash is calculated per each of these blobs , each blob and hash are stored in a…
Do you think it's important for beginners to understand all these subtleties? I think I could maybe eventually introduce them, but for the first level on the first screen, I don't think throwing a bunch of concepts at them will help with learning. Feel free to re-open the task if you disagree
This tutorial is great, but it propagates a misconception about git. "A commit in git is a recorded set of changes that you have made" Git commits are _not_ deltas. They are entire snapshots of the repository and a single (optional) pointer to an ancestor commit[1]. Git may handle _compression_ in terms of deltas (see 'Packfiles' in [2]), but logically, a commit should be thought of as equivalent to the state of all…
Nit: A commit can have multiple ancestors, as in a merge.
shameless plug: www.srctree.net - Ace editor + git + canvas for viewing commits/branches. I built it about a year ago, mostly for learning and fun. I haven't advertised it a lot but it seems relevant in here. I hope it's not off topic!
Earlier quoted context omitted.
This is still not quite correct. Let me outline the structure, and then I will try and submit a PR addressing it. The first step to committing is staging what should be included. The staging process specifies an index of files that are to be added to the next commit. When the commit is recorded, git checks every file/chunk in the index; a hash is calculated per each of these blobs , each blob and hash are stored in a…
I'll be honest -- that was hard to understand. I don't know the low-level plumbing of git very well, which is why I made a higher level tool like this. Do you think it's important for beginners to understand all these subtleties? I think I could maybe eventually introduce them, but for the first level on the first screen, I don't think throwing a bunch of concepts at them will help with learning. Feel free to re-open…
I don't think that you need to understand all the plumbing, however it is important to understand how the index works, and that git stores the entire snapshot. The way it currently appears makes it seem like every time you switch branches git has to figure out the end state based on deltas, which is not true. Git has fast branch switching precisely because it stores the snapshot in its entirety.
[EDIT] Here is what I wrote if anyone is interested: http://gist.io/4969804
Wow! Author here, did not expect this to get submitted to HN yet (was going to finish out a few more levels this weekend and clean everything up). Forgive the giant "TODO" in the help dialog The link everyone should see is the demo: http://pcottle.github.com/learnGitBranching/?demo That shows a few example commands, the completion of a level, and finishes with the help dialog. Some interesting technical highlights -…
I would seriously consider packaging this as an enterprise teaching tool for developers. Companies buy this sort of tools for training. Very good commercial potential here.
I also spoke to the Github guys about integrating this into their set of training tools (try.github and a few docs), but I think they got caught up with their full time responsibilities because I haven't heard back in a while. I could commercialize it but it deserves to be free!