Aga

Looking at the history tree with all the branches and remote branches is a great way really understand Git.

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

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.

Pro Git has a great chapter about how Gits internals work: https://git-scm.herokuapp.com/book/en/v2/Git-Internals-Plumb...

This picture sums the model nicely: https://git-scm.herokuapp.com/book/en/v2/book/10-git-interna...

For me studying Git internals has been a good lesson in software design. Git's core is very simple, yet somehow that makes it a really versatile tool.

Gerrit, a Git server with code review, lets users write custom submit-rules with Prolog: https://gerrit-review.googlesource.com/Documentation/prolog-...

Shawn Pearce, the author of Gerrit, explains why he thinks Prolog is well suited for this: https://groups.google.com/forum/#!msg/repo-discuss/wJxTGhlHZ...

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.

FlasForth is another fun Forth for AVR and PIC microcontrollers. You can even try it out over telnet... :-)

http://flashforth.sourceforge.net/

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

[1] http://code.google.com/p/gerrit/ [2] http://www.reviewboard.org/

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.

Very nice concept!

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.

Best of luck with this!

[1] http://www.visitfinland.com/article/restaurant-day/

Why yes! I've used it (or Gerrit code review [1], to be precise) even in two-man projects!

As important as QA is to keep others in the project aware of the latest changes.

[1] http://code.google.com/p/gerrit/

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.

Arch's philosophy: https://wiki.archlinux.org/index.php/The_Arch_Way

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.

Even if this was meant as an critique to Git, I (some kind of a Git-evangelist) enjoyed it a lot. I even learned something new!

The critique is quite well established. One needs to understand these quirks to be an enlightened Git user.

However we make up with them, as the overall gain from Git's approach to version control is so big.

Some things could be improved though, like introduce something like "git branch --current" to avoid the Hobgoblin...

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.

https://www.kernel.org/pub/software/scm/git/docs/git-rebase....

KDiff3 has worked nice for me and it seems to be availabe for OS X too: http://kdiff3.sourceforge.net/

(however I have not tested it on an OS X)

Git Users Survey 2012 might give some indication: http://bit.ly/ZdRDxX

Questions 10-15 are relevant and show a quite wide variety of different tools people use. GUI's seem to be popular too.

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"

I have found the Pro Git book to be the best: http://git-scm.com/book

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/

I think vimtutor does a good job as a quick-start guide.

Very nice idea! This is strangely compelling and I almost forgot it to the background despite having radio on... :-)

For those moody evenings and nights a nice choice is "You are listening to" It combines ambient tracks from Soundcloud and police/fire department/etc. radios: http://youarelistening.to/

I like this non-relativist stance. Simply stating YMMV often kills what could have led to a good conversation, thus possibly preventing us from learning more.

I'd like to couple this attitude with the great advice of having "Strong opinions, weakly held". (http://bobsutton.typepad.com/my_weblog/2006/07/strong_opinio...)

I too have been teaching Git for many years now.

I find it easy to teach, thanks the concepts being simple and clear. I don't have to transfer a lot of information before people can start reasoning about things themselves and independently finding out more.

I always try to make sure people understand two things:

1) The history tree (==how to read the metro-map that is gitk)

2) Distribution, that you are responsible for syncing with others, not the other way round

Almost everything else I prefer the students at least try to figure out themselves.

Albert Einstein is attributed with a great quote: “Everything should be made as simple as possible, but no simpler.”

I would argue that in the case of Git it's not about a single design decision. The whole design is very simple and easily understandable. Thus everything can be derived from the design decisions.

The design decisions also have clear rationales.

"Why something is better" and "why something has "won"" are of course different questions that deserve different answers.

Here is an article, where a lens maker recalls his experience designing special lenses for the film Barry Lydon. Kubrick wanted to shoot inside castles in only candle light...

No mention of knowing the lens makers daughter though...

http://www.visual-memory.co.uk/sk/ac/len/page1.htm

Why would dvcs cause problems for auditors?

For any given project, no matter how distributed the development, you will have a "blessed" repository, from which the official releases are made. The history of this "blessed" repository is made not rewritable, even if anyone can push new stuff to it. The config files and hooks can be made writable by only admins.

Or you use a maintainer model, where the "blessed" repository is not even pushable. A maintainer (or a group of them) chooses what he merges in.