Design

GitX Philosophy

• GitX is used by people that don't know (or need to know) how it works
• Not all projects have a Git Guru at hand
• It should be harder to make a "mistake" than to correct it. To be clear, for most users it's a mistake to:
• Get the repository into 'unusual' states like detatched HEAD
• Drop commits into the aether (unreferenced) without an explicit 'delete' operation

Things I Should Have Known Before I Pushed An Update

• Git binaries on developers machines are
• sometimes very old
• sometimes very new (unreleased/experimental)
• sometimes in multiple locations
• sometimes badly misconfigured
• Bare repositories count
• Some repositories have 30 remotes
• Not all remotes are reachable
• Some repositories have 300 branches
• Multiply this by 30 remotes, and checking something against each ref can be quite slow
• Some repositories have 300,000 commits
• Some commits are 300 MB

General Design Guide

The Zen of Python, by Tim Peters

• Beautiful is better than ugly.
• Explicit is better than implicit.
• Simple is better than complex.
• Complex is better than complicated.
• Flat is better than nested.
• Sparse is better than dense.
• Readability counts.
• Special cases aren't special enough to break the rules.
• Although practicality beats purity.
• Errors should never pass silently.
• Unless explicitly silenced.
• In the face of ambiguity, refuse the temptation to guess.
• There should be one-- and preferably only one --obvious way to do it.
• Although that way may not be obvious at first unless you're Dutch.
• Now is better than never.
• Although never is often better than right now.
• If the implementation is hard to explain, it's a bad idea.
• If the implementation is easy to explain, it may be a good idea.
• Namespaces are one honking great idea -- let's do more of those!