1

Scenario:

I cloned a fork of an open-source project. I installed SonarQube software for fun on my local computer. To be able to analyze the project with SonarQube I added respective plugin and configuration to build.gradle.kts file. I thought "Neat! I want to be able to run SonarQube in the future".

Now, I want to do normal changes - create branches and PRs, merge changes from upstream to refresh a fork - basically standard workflow BUT here is the twist: I also want to keep my changes to the build.gradle.kts file just to occasionally run an analysis, but I don't EVER want to push them.

So the goals I want to achieve are:

  • have a "workspace-patch" that is at all times applied to my files
  • detect changes to build.gradle.kts OTHER than what patch introduces
  • make git ignore changes introduced by the patch, BUT DO NOT ignore the affected file - right now it always shows that build.gradle.kts has been modified, which I don't want, but I obviously can't ignore this file
  • keep git history clean i.e. I don't want commits that apply patch in my feature branches
  • keep scripting and using external tools to minimum and preferably use built-in git mechanisms
  • make it so that patch is never included in PRs - I don't want to introduce my local mess to ohter project
  • be able to work in repo the same way I usually work and don't be bothered by this patch - normally create branches, checkout others, do merges from upstream etc.
  • be independent of build system
  • optionally keep the patch code in local version control (adding file to .gitignore is bothersome)

In short - I want this workspace-patch to be transparent.

For now I came up with some band-aid solutions, but all of them have certain flaws:

  • create a patch file, store it locally, ignore it, write a local pre- and post-commit hooks to rollback and apply the patch. This solution requires me to create hooks and shows changes introduced by patch in git status. It would also require me to ignore the patch file, so I can't store it in local source control
  • write a local only shell script that applies the patch when needed, run the required build configuration with patch now applied and cleans after itself. This method is not purely from git and without some clever mechanism to optimize patch applying/rollback would force project to often reload.

I am almost certainly sure that I'm missing something and there must be a way to achieve something similar in one way or another. How do/would you do that? This method seems like it's flawed, but I can't think of any other idea and need some help.

Tooster
  • 322
  • 3
  • 14
  • 1
    I often do things like the two band-aids you have described. You might also look at `assume-unchanged` (link: https://dev.to/nishina555/how-to-ignore-files-already-managed-with-git-locally-19oo ), but I ended up "surprised" at various times with how that would interact with `stash` activity. – pestophagous Apr 13 '21 at 18:48
  • 2
    Not sure if you knew this: you can just leave your "dirty" edits always present, and when you wish to commit code, stage things using `git add -p`. After I learned of `git add -p` it became the only way I ever add things. Combine it with a "poison comment" (like "DNC" for Do Not Commit) and pre-commit hook so you never accidentally commit the dirty lines: https://github.com/219-design/git_templatedir/blob/master/hooks/pre-commit – pestophagous Apr 13 '21 at 18:51
  • 2
    Instead of hooks you can use filters: https://stackoverflow.com/a/2155355/7976758 – phd Apr 13 '21 at 18:52
  • @phd This is brilliant. Filters do most of the things I wanted (including transparency when running `status` and the like), but I have yet to figure out how to exactly setup them - applying patches using bash `patch` or `git apply` didn't seem to work very well and was bothersome. One minor flaw is the need to edit `.gitattributes` which is detected by git, but maybe in tandem with @pestophagous `assume-unchaged` it can be somehow (not-so-safely) sidestepped. – Tooster Apr 25 '21 at 19:52

0 Answers0