Trying to make local changes in HEAD repo and have brew pick them up

[wrobelda]

I am trying to apply a patch over a HEAD upstream source. If I commit the change to a cached repository in /Users/me/Library/Caches/Homebrew/, brew will hard reset it back to the upstream ref state upon starting:

Your branch is ahead of 'origin/codebranch by 1 commit.
  (use "git push" to publish your local commits)
HEAD is now at XYZ123 (...)

, where XYZ123 is the origin head.

The documentation mentions that there is a --git option that is fit for this purpose ("Create a Git repository, useful for creating patches to the software"), and it does seem to have an effect, per the Reinitialized existing Git repository in /private/tmp/... log line, but that location is nuked as soon as the build fails.

So how do I make local changes to a git repo and have brew pick them up?

[Rylan12]

There are a few things you can do, I think. The preferable way to handle something like this as a more long-term solution is probably to add a patch block in the head block. Might look something like this:

head do
  url "..." # HEAD url

  patch do
    url "..." # url of the patch file (this can be a filename using `file:///Users/...`)
    sha256 "..." # of the file specified above
  end
end

A good way to generate the patch file is to run brew install --interactive --git. You can then make the changes and use git diff > /some/patch/file to create the patch file to be used in the patch block.

That's really what the --git option is for. We don't really have a built-in way to make on-the-fly changes like you're indicating. One thing that may be useful is the --keep-tmp option to brew install which will keep that /private/tmp/... directory that you mentioned around after brew install finishes (and I believe it prints the temporary path to the screen for easy access).

Now, I believe another way is to manually edit the head URL to point to a file instead of a URL. I haven't been able to quite figure out how to get this to work with a git repo without archiving/zipping the repo before trying to install, but it might be possible.

Hope that's what you're looking for.

[wrobelda]

Hope that's what you're looking for.

Yes, that mostly answers my question, although neither solution is ideal. I wish there was a switch that would leave the /tmp location and reuse it upon the next build attempt. This way I could incrementally work on fixing the codebase until brew actually compiled it successfully.

[wrobelda]

An easier alternative might be to fork the repo

The point is that for some changes you don't really know they're ready until you have obtained a successful brew build. So pushing half-baked untested and most likely incomplete changes to your fork just to test if brew can build it is very inelegant. That's why it would make sense to be able to continue working with a "dirty" local branch until the code changes are complete.

[carlocab]

It would, but there's currently no way of doing that. It's a feature I've wished brew had, but haven't had the time to work out implementation.

If you'd really rather work with a dirty local branch, then you'll probably have to work with Rylan's suggestion above. You do risk your patches breaking on you without notice (unless HEAD is actually a repo you already manage), though.

I have to say that I don't understand the aversion to a fork. It's your own fork; you can rewrite history as you please. Not to mention that it saves you the work of producing a new patch for every build change you'd like to test.

[wrobelda]

I have to say that I don't understand the aversion to a fork. It's your own fork; you can rewrite history as you please. Not to mention that it saves you the work of producing a new patch for every build change you'd like to test.

I do have a fork, but I used it to create a pull-request to have my (clean and tested) change merged to upstream. In your approach, I'd be pushing several untested commits to a public fork and, once ready, I'd have to rewrite the history to come up with a tidy pull-request. Rewriting the history is not elegant and that's what I was referring to. I just don't work like this, it's a bad practice. I only push changes to my public repos once I had tested them.

Thanks for the input, though.

[carlocab]

You don't need to use your existing fork for this, but ok.