{"thread":{"id":"50492","subject":"Tailoring branch use case question","startedAt":"2019-02-13T14:21:56Z","lastAt":"2019-02-13T14:21:56Z","messageCount":1,"participants":["Jason Wenger"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"369233","messageId":"CAM6z=49Ku-JMJRvjqYT8cqN7PaUdBESQCdx_6tCB4e5zhA2Cog@mail.gmail.com","threadId":"50492","inReplyTo":null,"subject":"Tailoring branch use case question","fromName":"Jason Wenger","fromEmail":"jcwenger@gmail.com","sentAt":"2019-02-13T14:21:41Z","receivedAt":"2019-02-13T14:21:56Z","isPatch":false,"sender":{"key":"jcwenger@gmail.com","avatar":null},"body":"So I've got a use case that is cumbersome, and I'm wondering if it's a\ncommon one, or if anyone has found a better way to manage it.\n\nI have a repo that I work in where I make a set of changes to adapt it\nto my environment -- some config file changes and a couple code\nchanges that help with debugging.  I want those changes always\napplied, regardless of which branch I'm on, but they're specific to my\nsetup, so I don't want to commit them to the public repo's history.\nThe changes are in specific places that aren't in active development,\nso the changes I apply never generate merge conflicts.\n\nWhen I work, I've currently been keeping these changes in a couple\ncommits, that I call 'tailor'.\n\nWhen I want to work on a branch 'foo', instead of checking out foo, I\nmanually rebase --onto foo tailor~~ tailor, so that the couple commits\nin my tailor branch reapply, now on top of branch foo.\n\nWhen I commit, I want to commit to foo, not my tailor branch.  So to\nget that, I have to first commit on top of my tailor branch, then\ncheckout foo, cherry pick the new commit, and then checkout tailor\nagain, and rebase back on top of the new foo.  The other way I could\ndo that would be to commit on top of tailor, rebase --interactive to\nreorder the commits, and manually update the foo ref.  Either way is\ncumbersome.\n\nIt's not a use case for --assume-unchanged, because I sometimes do\nmake changes in those same files that get tailored, and I do want\nthose changes to be show in diff and git gui.\n\nI thought about trying to do some stuff with git hooks, but the idea\nof doing things like rebasing inside post-checkout seemed evil.\n\nReally, the whole 'tailor' branch I've been using itself is really\njust an artificiality.  Really, I'd rather be thinking just about the\nbranches I'm actually working with, not this artificial 'tailor'\nbranch.\n\nEssentially, I want a way to work with branches normally, but to\nensure that, for a defined patchset:\n• every time I update HEAD to a new ref, my working copy is actually\nchecked out as HEAD+patchset\n• when I diff my working copy against any ref (including HEAD of\ncourse), for patchset to not contribute to the diffs that are produced\n• when I commit to HEAD, for patchset to remain applied in the working\ncopy only, and not be committed to HEAD.\n• to be able to (very rarely) change the content of that patchset\n\nI haven't' been able to come up with a way to automate that.  Is this\na use case others have encountered?  Has anyone found a better way to\nmanage this?\n\nThanks,\n--Jason C. Wenger\n"}]}