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

Don't Overlook This About the User's Environment

• Git binaries on developer's machines are
• sometimes very old
• sometimes very new (unreleased/experimental)
• sometimes in multiple locations
• sometimes badly misconfigured
• Bare repositories count
• Waiting for network operations can still be slow in git, and GitX does too much of it already.
• Unfortunately, 300 MB commits aren't even rare enough to consider unusual
• Nor are 3 GB clones
• Some repositories have 30 remotes
• Not all remotes are reachable, or even valid at any given time
• Some repositories have 300 branches
• Multiply this by 30 remotes, and checking something against each ref can be quite slow
• Some repositories have 3,000 tags
• I don't know what 30,000 is an unexpected number of for git. It's not uncommon for "number of commits in a big project", but deserves a place in this list anyway.
• Some repositories have 300,000 commits

General Design Guide

TODO

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!