Have you seen git-started?
Closed this issue · 10 comments
It looks like your project as well as git-started have many similar goals?
No I did not see it. It has been started a few months after mine, so I did not see it in my research, thanks for the link.
That's too bad, we could have worked together, @fidian has had a lot of good ideas. I like the conflict markup detection hook, the directory and filenames that are very unixy.
It's possible you mixed up mine with someone else's - git-started starts Oct 2012, git_template was Jul 2013. However, I suppose that the time any project starts has no bearing on how valid it is.
It seems that we do the hooks in somewhat incompatible ways and our installation procedures take totally different philosophies. Really this just boils down to a few different shell commands, but it isn't like one can lift the work done here and drop it over there (or vice versa).
It does look like yours is stronger on the PHP-related hooks. Did you make this for a PHP shop because everyone was tired of doing the same sort of setup for each of their repositories?
@wjaspers - I'm a little confused by this issue on GitHub. What do you think would be the best outcome? For instance, we could make a combined project in an organization and hopefully foster more collaboration ... or was there something else you had in mind? Just a general sharing of code?
It's possible you mixed up mine with someone else's - git-started starts Oct 2012, git_template was Jul 2013. However, I suppose that the time any project starts has no bearing on how valid it is.
Oh yeah I somehow misread the github history of your repo… I don't remember finding it in my research, but maybe I had the wrong keywords. As per the validity point, I fully agree, I just wanted to explain why I did not contribute to your project. BTW, if you're interested, I was also told about this project (only pre-commit hooks though).
As you say we have different installation philosophies : I totally decouple git-template from the projects I used it on, while you integrate it with your projects, thus sharing the setup with your team.
It does look like yours is stronger on the PHP-related hooks. Did you make this for a PHP shop because everyone was tired of doing the same sort of setup for each of their repositories?
Yes, copying the sismo hook over and over was the kicker for me. The thing I am still not quite satisfied with at the moment is the update mechanism : with git_template, you have to update the repo first, then run the update script from each repo you want to update. I thought of using symlinks but then I think people would be unable to have additional hooks that are not in git template in their repos…
If we managed to totally decouple the installation mechanism from the hooks themselves, we might be able to share some code. I recently did this by isolating things that should be copied in each repos from other things (like the docs and the tests). That is the purpose of the template directory of the project.
@fidian Just the general sharing of code.
As I periodically stumble along github's vast landscape, it sometimes feels good to find similar projects and offer a chance for them to connect--even if nothing were to come of it.
@greg0ire I think the repo link you meant to share was here: https://github.com/pre-commit/pre-commit
@wjaspers I tried to link to their homepage but without the scheme, it becomes a relative link. I fixed it, thank you for catching that.
As you say we have different installation philosophies : I totally
decouple git-template from the projects I used it on, while you integrate
it with your projects, thus sharing the setup with your team.I think I need to learn a lot more about git templates to see how they
work. At my first initial glance it looks like the files are still
committed to the repository. I don't understand how one approach is more
decoupled than the other.
With regard to the pre-commit site, I'm somewhat terrified to let software
install things for the users automatically and would rather have a hook
that fails if a required dependency is not installed or configured
correctly. Let the user decide on what manual action to perform.
What do you think the odds are of combining projects in order to leverage
both of our strengths? We might need to have a pool of users to query in
order to decide what advantages one project has over the other, but I think
we could work things out. I would rather have one system that's flexible
enough to work for nearly any project and attract more developers instead
of further fragment the development community with several hook-related
projects. I really like how bash is the de facto environment for
development even on Windows, and I really want to keep leveraging that for
the hooks. You're template based approach seems to have both positives and
negatives but certainly seems intriguing. I'm game to talk about this.
I'm on Freenode's IRC as fidian in #tests-always-included (though I'm often
away) or you can email me at fidian@rumkin.com for further discussion.
As for this issue, I think it rightfully could be simply closed as the
issue is resolved?
At my first initial glance it looks like the files are still
committed to the repository.
No they are not, they are copied to the .git folder, but they do not go into the object database and cannot be shared with others using git (or at least I don't know how to do that).
I'm ok to discuss all this with you (when I have time, maybe this week-end). We should try to compare both projects and try to figure out if we could be able to "extract" the hooks from them in a separate project, or if we could merge them in one big project.
With regard to the pre-commit site, I'm somewhat terrified to let software
install things for the users automatically and would rather have a hook
that fails if a required dependency is not installed or configured
correctly. Let the user decide on what manual action to perform.
Oh I did not notice that, that's sketchy! I agree with you and I think that hooks should do nothing silently if the tool does not exist.