3 ms·

I do this and like it: https://github.com/staticshock/dotfiles/blob/main/Makefile https://github.com/staticshock/dotfiles/blob/main/Makefile I also tend to put

I do this and like it: https://github.com/staticshock/dotfiles/blob/main/Makefile https://github.com/staticshock/dotfiles/blob/main/Makefile I also tend to put a Makefile into the root of any repo I work in (ignored via .git/info/exclude), so that shell commands relevant to my workflow can accumulate under that Makefile. I've been doing this for at least 10 years and love it. Most repos have some sort of a cli interface, but that doesn't mean that they're any good. Make is nice way to wrap all of them, and to standardize on at least the build/test/run commands across many disparate repos. Here's an example of one of those from a long-abandoned project: https://gist.github.com/staticshock/0e88a3232038d14a2817e105f9eaf85f https://gist.github.com/staticshock/0e88a3232038d14a2817e105...

cortesoft 1y ago
Is there a reason to not include your makefile in the git repo? Is it not useful to anyone else?
- belden 1y ago
  Speaking for myself, reasons why I don’t immediately share my own tooling: Perhaps I want to hold it to my own standard for tooling, not the team’s. Perhaps I want to write it in a language that the team doesn’t really embrace. I might not think it’s worth anyone’s time to code review changes I make to my own tools. I might want to do something dumb like bake an API key into the tool. Maybe the project already has a similar tool, and I don’t want to explain why I am wrapping/ignoring it. In short: sometimes the cost to collaborate on idiosyncratic tools is just higher than I’m willing to pay.
  - munksbeer 1y ago
    Sadly, I do the same at times. I just want to hack together something that works for my use case. If I can share that with the wider team, that is superb. But I really don't enjoy my hacky utils being subject to tedious code review scrutiny they don't deserve. To be clear, I _do_ add utils that I think will be useful to the common repo, subject to review, and mostly they will be merged. But if it gets painful, I just retract the PR and keep it locally.
- staticshock 1y ago
  Have you ever tried to submit a PR of your Makefile to the maintainers of, say, an open source npm package? If you have, what compelling story were you able to tell about that Makefile that got the maintainers to merge your PR? And after they successfully merged it, did you continue putting up PR after PR for each successive round of tweaks to that Makefile? What an extraordinary amount of unnecessary effort that would be. My workflow does not belong to the repo, it belongs to me. The only thing that belongs in the repo is all the shared workflows (or the elements they comprise.)

cortesoft 1y ago

Is there a reason to not include your makefile in the git repo? Is it not useful to anyone else?

belden 1y ago
Speaking for myself, reasons why I don’t immediately share my own tooling: Perhaps I want to hold it to my own standard for tooling, not the team’s. Perhaps I want to write it in a language that the team doesn’t really embrace. I might not think it’s worth anyone’s time to code review changes I make to my own tools. I might want to do something dumb like bake an API key into the tool. Maybe the project already has a similar tool, and I don’t want to explain why I am wrapping/ignoring it. In short: sometimes the cost to collaborate on idiosyncratic tools is just higher than I’m willing to pay.
- munksbeer 1y ago
  Sadly, I do the same at times. I just want to hack together something that works for my use case. If I can share that with the wider team, that is superb. But I really don't enjoy my hacky utils being subject to tedious code review scrutiny they don't deserve. To be clear, I _do_ add utils that I think will be useful to the common repo, subject to review, and mostly they will be merged. But if it gets painful, I just retract the PR and keep it locally.
staticshock 1y ago
Have you ever tried to submit a PR of your Makefile to the maintainers of, say, an open source npm package? If you have, what compelling story were you able to tell about that Makefile that got the maintainers to merge your PR? And after they successfully merged it, did you continue putting up PR after PR for each successive round of tweaks to that Makefile? What an extraordinary amount of unnecessary effort that would be. My workflow does not belong to the repo, it belongs to me. The only thing that belongs in the repo is all the shared workflows (or the elements they comprise.)