-
Notifications
You must be signed in to change notification settings - Fork 2k
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
Conversation
👍 Though the Having Another approach is to move more of this to the core Once the hook stuff in the core |
How about this direction? Should we move the filter installation under |
switch sub { | ||
case "hooks": | ||
if err := c.hookInit(); err != nil { | ||
fmt.Println(err) |
There was a problem hiding this comment.
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.
Yes, for consistency. I like to think of the commands as simple glue code. Actual logic should be written and tested in packages like 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:
|
return SimpleExec("git", "config", "-l", "-f", ".gitconfig") | ||
} | ||
|
||
func SimpleExec(name string, arg ...string) (string, error) { |
There was a problem hiding this comment.
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
.
There was a problem hiding this comment.
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.
Provide separate initialization paths for global and in-repo initialiazation
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.