For me Git has also worked very well for small projects. I actually learned it initially by using it for my masters thesis.
One correction: Git does not store changes at all. It stores all the versions of files as separate "blobs". What keeps .git small, is that Git compresses the object database to pack-files. "git gc" does this for you.
Extending code review to commit messages is a big help.
If I can't understand from the commit message, what the change is trying to achieve, I won't even look at the code. Instead I'll ask to clarify the commit message first.
I've worked in a couple of big projects (250+ developers) where we have introduced Gerrit Code Review [1] that has mandatory code reviews.
In all cases, there has been a lot of initial scepticism and worries.
Some things that I feel have contributed to people accepting code review, are:
1) Gerrit enforces code review, you have to get it done somehow, in order to get your changes in. It's integrated in the workflow.
2) You choose your own reviewers.
3) We have had a clear message, that code review is about communication, knowledge sharing and bug hunting is just an added bonus. And communication is always our biggest problem in big projects. Just by letting someone do code review of your changes, the knowledge inside the organization about the change has almost doubled.
4) We ask people to treat code review request as number one priority, as the changes can not get in before it.
Before Gerrit we tried to encourage the culture by using Reviewboard [2], but in our case it just wasn't used that much. People did not treat review request as a high priority. Maybe because it was not enforced and sometimes you'd do a review for a change that the developer already merged in.
It's interesting to see how small tricks can change peoples behaviour...
One thing the article unfortunately fails to mention is the motivation for this model. A branching model, as any other policy or technical solution, should be an answer to an existing problem. So decoupling the branching model from projects details makes no sense to me, although the article does a fair job describing the technical aspects.
I've been asked many times by units (big corporation) if this would be a good branching model for them when they are migrating to Git. I always tell them it's probably too complicated for their situation. Most of the units are trying to implement some form of Continuous Integration. Obfuscating that with complex branching models would only confuse them. Only when they encounter a real problem, that could be solved with this branching model, I suggest they try this out. I haven't still seen it happen.
However I must say, that the situation might be different in different types of projects. I've seen only these kind of CI-projects with a couple of hundreds developers with long lead times.
I hope this catches fire like Airbnb! At least here in Finland "Restaurant Day" [1] has already become somewhat of an institution, so I bet there's potential for Cookening too!
A minor detail: I'd appreciate the _full_ price to be displayed with a side note like "including Cookening service free 3€".
Or is the service fee per group? In that case it could be something like: "15€ per guest + 3€ Cookening service fee per group"
With the current layout the service fee feels almost hidden.
I like the practicalness of the advice. It might actually lead to some good in this world.
It's times like this when people stop to think about other human beings and might actually act on something. Unfortunately during normal times we are really bad at that.
I guess the most notable difference between Arch and Unbuntu is Arch's quest for simplicity as a system, where Ubuntu tries to be simple for the "common man" by abstracting implementation details, adding to overall complexity of the system.
A warning about the ours and theirs commands: when you're rebasing, they will do the exact opposite what most people await them to do (thanks to git rebase's implementation).
From the git rebase man-page, --merge:
Note that a rebase merge works by replaying each commit from the working branch on top of the <upstream> branch. Because of this, when a merge conflict happens, the side reported as ours is the so-far rebased series, starting with <upstream>, and theirs is the working branch. In other words, the sides are swapped.
I have found branching in Git to be a pleasure to teach, even to large groups. There is nothing I have to hide about them, implementation or otherwise. "This is how it works and this is what you can do thanks to that"
That, and constantly creating your own test repositories to test new commands/concepts. With a distributed VCS it's easy and fast. Just run "git init test" somewhere and start committing!
I also recommend you to use "gitk" when you're learning to constantly look at your history tree. That should clarify the concept "branches are pointers" after a few tests.
This is exactly what I tell students in my Git courses during the first hour.
Git checkout is a command to read something from your .git-folder to your working directory.
Especially for people coming from ClearCase, the concept of Git checkout needs to be clarified as fast as possible. (In CC checkout means you make an element (file) editable for you, and possibly reserve it to you too)
As explained above, this will help only against the first line of the attack (until the first newline character). The subsequent lines will be executed.
A better solution would be to paste the text in to an editor.
I feel the problem is not the Internet becoming crappier, it's more that our "real" experiences are becoming crappier as instead of living them, (too) many are completely indulged in documenting them.
An example is at a concert or club where more people are holding devices then dancing.
I've started carefully choosing where to take my camera with, as I'll be completely absorbed in taking photographs, later not having "real" memories of the event at all.
A classical xkcd sums up my feelings about this quite nicely:
http://xkcd.com/77/
More powerful history browsers to "lola": * gitk (graphical, developed in git's own repo) https://lostechies.com/joshuaflanagan/2010/09/03/use-gitk-to... * tig (console) http://jonas.nitro.dk/tig/manual.html