The semantics component of the Web Standards Project forever rewired my brain. Applying structure and meaning to things seeped into all my thinking. It’s not a paralyzing process internally, but ignoring it feels lazy. Thanks Zeldman. This vexes me.

On GitHub each repository needs a name, so naturally it has to meet these criteria:

1. Descriptive
2. Readable
3. Consistent
4. Contextual
5. Future-friendly
6. Extensible
7. Reusable

We all think this way. Right guys?

For many Git projects I can’t discern anything from the name. Surely there’s a standard to follow? Nope. Letter casing and punctuation are oddly devil-may-care for a development construct. So I tweeted and Bryan Veloso of GitHub answered:

@Falkowski — Depends on the type of project and the language. I usually follow their conventions.

— Bryan Veloso (@bryanveloso) March 7, 2012

@Falkowski — Yep! I'd follow the domain.

— Bryan Veloso (@avalonstar) March 7, 2012

My Git projects are usually for websites though, so many languages are in play. We concluded modeling after the domain makes sense.

http://domain.com ➔ domain.com.git
http://sub.domain.com ➔ sub.domain.com.git

For other projects, I’m inclined to keep the lowercase and dashes pattern:

the-fellowship-of-the-ring.git
the-two-towers.git
the-return-of-the-king.git

More perfect

The GitHub for Mac ‘Clone In Mac’ feature creates a new folder named for the repo — potentially breaching a meticulously crafted project folder. I’m terribly vexed.

Git’s command line swoops in to save the day and my sanity:

# Clone the repo into a new folder named after the GitHub project
git clone [email protected]:username/project-name.git

# Clone the repo into a new folder named 'zebra'
git clone [email protected]:username/project-name.git zebra

# Clone the repo into the current directory (must be empty)
git clone [email protected]:username/project-name.git .

Now go forth and name/clone Git projects like a standardista.