Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Provide separate initialization paths for global and in-repo initialiazation #61

Merged
merged 7 commits into from
Jun 4, 2014

Conversation

rubyist
Copy link
Contributor

@rubyist rubyist commented Jun 3, 2014

This provides separate initialization paths:

If you're not in a repo, git media init will only run the global initialization, which is adding the filter setup to ~/.gitconfig.

If you're in a repo, git media init will run the global init, and also run a repo init - which currently only calls the (empty) hook initialization.

If you run git media init hooks, it will run only the hook initialization.

We can easily add subcommands to this, or maybe wad the local stuff back together a bit more, in the event that I'm over-thinking this.

@technoweenie
Copy link
Contributor

👍 Though the hooks sub command should bail early if it's not inside a repository.

Having repoInit() call hookInit() does make this seem a tad excessive.

Another approach is to move more of this to the core gitmedia package. Then git media init could always install the global configs, and the repo stuff when inside a repository.

Once the hook stuff in the core gitmedia package means it can easily be called for git media clean and git media smudge too. That would satisfy the last item on #56.

@rubyist
Copy link
Contributor Author

rubyist commented Jun 3, 2014

How about this direction? Should we move the filter installation under gitmedia as well?

switch sub {
case "hooks":
if err := c.hookInit(); err != nil {
fmt.Println(err)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Check out logging.go in the gitmedia package. It has helpers for printing messages and errors. This way we can capture all output for the logs that get written after a panic.

@technoweenie
Copy link
Contributor

Should we move the filter installation under gitmedia as well?

Yes, for consistency.

I like to think of the commands as simple glue code. Actual logic should be written and tested in packages like gitmedia.

On a similar note, I'm thinking of moving the integration tests to the commands package, and organizing them per command. Considering the importance of the commands, this looks bad:

?       _/Users/rick/github/git-media/commands  [no test files]

return SimpleExec("git", "config", "-l", "-f", ".gitconfig")
}

func SimpleExec(name string, arg ...string) (string, error) {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just stuck this in here for now, since it's the only thing that uses it. It could be its own package.

It was under gitmedia, but then there was a circular dependency as gitmedia needs to use gitconfig and gitconfig needed gitmedia for SimpleExec.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Wow, the only thing? I think I'd even keep from exporting it. This doesn't seem like something a package named gitconfig should export.

rubyist pushed a commit that referenced this pull request Jun 4, 2014
Provide separate initialization paths for global and in-repo initialiazation
@rubyist rubyist merged commit f5a0158 into master Jun 4, 2014
@rubyist rubyist deleted the keep-em-separated branch June 4, 2014 13:27
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants