So I've got a use case that is cumbersome, and I'm wondering if it's a common one, or if anyone has found a better way to manage it. I have a repo that I work in where I make a set of changes to adapt it to my environment -- some config file changes and a couple code changes that help with debugging. I want those changes always applied, regardless of which branch I'm on, but they're specific to my setup, so I don't want to commit them to the public repo's history. The changes are in specific places that aren't in active development, so the changes I apply never generate merge conflicts. When I work, I've currently been keeping these changes in a couple commits, that I call 'tailor'. When I want to work on a branch 'foo', instead of checking out foo, I manually rebase --onto foo tailor~~ tailor, so that the couple commits in my tailor branch reapply, now on top of branch foo. When I commit, I want to commit to foo, not my tailor branch. So to get that, I have to first commit on top of my tailor branch, then checkout foo, cherry pick the new commit, and then checkout tailor again, and rebase back on top of the new foo. The other way I could do that would be to commit on top of tailor, rebase --interactive to reorder the commits, and manually update the foo ref. Either way is cumbersome. It's not a use case for --assume-unchanged, because I sometimes do make changes in those same files that get tailored, and I do want those changes to be show in diff and git gui. I thought about trying to do some stuff with git hooks, but the idea of doing things like rebasing inside post-checkout seemed evil. Really, the whole 'tailor' branch I've been using itself is really just an artificiality. Really, I'd rather be thinking just about the branches I'm actually working with, not this artificial 'tailor' branch. Essentially, I want a way to work with branches normally, but to ensure that, for a defined patchset: • every time I update HEAD to a new ref, my working copy is actually checked out as HEAD+patchset • when I diff my working copy against any ref (including HEAD of course), for patchset to not contribute to the diffs that are produced • when I commit to HEAD, for patchset to remain applied in the working copy only, and not be committed to HEAD. • to be able to (very rarely) change the content of that patchset I haven't' been able to come up with a way to automate that. Is this a use case others have encountered? Has anyone found a better way to manage this? Thanks, --Jason C. Wenger
