Refactoring

[stuartpb]

Ideally, all this plugin would handle would be the creating of repos on pushing a nonexistent repo. A main git plugin would handle the hooks and git-shell handoff, and another plugin/command like apps:create would be able to create hooked Git repos as well.

(The plugin should then be renamed to something like git-receive-init, and would not be included in Plusku.)

What this needs:

• commands needs to be replaced with ordered sourcing, so git-receive-init can perform the init before git-shell handles it.
• git-init needs to be a hook, so it can be called by receive-init and apps:create.
  • Actually, I don't know about that coupling. I think apps:create should be VCS-agnostic. This needs a little thought.

[stuartpb]

So, let's do it this way:

• apps's create-app hook creates the app directory.
• git's create-repo hook creates the repo.
• git-receive-init plushooks create-repo.
• apps:create plushooks create-app and create-repo.
• git-receive-app, when the app dir does not exist, plushooks create-app.

That way, apps:create is still VCS-agnostic, but it still believes in the idea of a VCS.

The kind of odd side-effect this can have is that receiving a Git pack will initialize a repo for every type of version-control Plushu plugin installed. I don't think that's necessarily a bad thing (it just means you'll get weird asymmetric behavior if you don't have a similar initializing plugin installed for other version-control systems' reception methods).

[stuartpb]

This hook layout, where create-repo can hit multiple plugins for different types of repo, begs for #6 to be implemented first.

[stuartpb]

blocked on #6, plushu/plushu#20

[stuartpb]

Also, this is kind of blocked by plushu/plushu-apps#2, since it's designed for a world with apps:create. Granted, it doesn't depend on it since you'd still be able to create apps by installing git-receive-init, but it's meant to be integrated into plushu/plushu-plusku, where that wouldn't be installed by default. So apps:create should be worked out first.

[stuartpb]

Although apps:create depends on create-repo being factored out. So there's a two-step dance in this refactor set here.

[stuartpb]

Let's go:

• create-repo self-calling
• .git suffixing in commands and create-repo hook (Ending Git repos in .git #6)
• apps:create (part of Implement Heroku-equivalent commands plushu-apps#2)
• plusourcing (commands, commands, and sourcing plushu#20)
• separated plugins

[stuartpb]

Also, a quick description of why this plugin should be renamed plushu-git: I originally wanted this plugin to be distinguished from a plushu-git plugin that doesn't create new repos with the hooks already in them when pushing a missing repo.

However, now that that functionality has been factored out into the reasonable create-repo hook, with repo creation being a deferred concept (and all creation naturally requiring some degree of integration), I'm okay with this being just the core plushu-git implementation.

[stuartpb]

You know, I mentioned when writing up the guidelines for pre-commands that using them as a shim for a specific plugin's command is a sign that that plugin is missing a hook point, and I think that applies here, too. Maybe this plugin could expose a self-plushook for git-command or git-shell (I'm thinking the former to sort-of match command, although the use is more like commands), and plugins that want to do something before that command executes can figure it out with a pre-git-command hook.

A little part of me feels easy at stepping into the same namespace used by the existing Git hooks, but I think it's unlikely that Git would implement a hook called command based on the conventions of existing hoos. If that were to happen, or of it continues to bother me, I can rename the existing hooks to eg. git-update-hook. (It's not exactly redundant since it's a "hook" from another context for the word "hook".)

[stuartpb]

Plus, I have to admit, it just feels distinctly more clear.

[stuartpb]

So, the further steps:

• Taking git-command into plushook
• Split out git-receive-init
• Renaming to plushu-git and plushu-git-apps
  • This makes the commit message issue references in the next step neater.
• Rename git hooks with -hook suffixes (Add -hook suffix to "githooks" hooks #8)

[stuartpb]

Bam.

[stuartpb]

This is being revisited by #9: the apps:create calling create-app and create-repo is being inverted so that create-repo calls create-app (since repos can stand alone, but all apps need some kind of repository for their source code).

I'm actually a little confused. How are apps being created now, in the git-receive-init case? I think they're not actually being explicitly created, just implicitly created when the git-update-hook in git-apps gets called.

And now I'm considering if apps should be naturally tied to repos, or if creating apps should just be separated altogether unless something like a plushu-create-apps-with-repos plugin is installed.