<!DOCTYPE html><html><head><title></title><style type="text/css">p.MsoNormal,p.MsoNoSpacing{margin:0}</style></head><body><div>On Thu, Mar 21, 2019, at 03:00, Paul Nijjar via kwlug-disc wrote:<br></div><blockquote type="cite" id="fastmail-quoted"><div>Now it is time to merge the changes I made from devel to master. If I<br></div><div>naively git merge then I will get commit abcdef, which merges in<br></div><div>config options for development, which screws everything up for<br></div><div>production. Oh no!<br></div><div><br></div><div>I can cherry-pick commits from devel and merge them to master, but<br></div><div>that seems gross and error-prone. Is there a better way for me to<br></div><div>merge the changes from devel into master, EXCLUDING a set of commits<br></div><div>hat I never want merged?<br></div></blockquote><div><br></div><div>I second (third?) the other comments about keeping configuration outside of source control. Should you need to make local config changes, just don't include those changes in a commit, and you'd have a clean history to merge. That said, you're in a predicament now, and wish to resolve it.<br></div><div><br></div><div>The "correct" answer depends on what sort of history you wish to preserve. If your overall desire is to preserve the original commits, then merge & revert will be correct. If your overall desire is to preserve only the relevant changes, cherry-pick or rebase will be correct.<br></div><div><br></div><div><div>tldr: Personally, unless you have a rather large 'devel'
history, and/or were planning on merging commits during a rebase, I'd
probably just cherry-pick this one time, and remember not to commit
devel-specific config changes to git in the future. rebase can be used like automated cherry-picking if desired, with the ability to shoot your foot off as well.<br></div><div><br></div></div><div>1. Cherry pick the commits you want<br></div><div><br></div><div>This is labour intensive and error-prone, as you need to ensure you're cherry-picking all the correct commits. Additionally, as this is basically replaying patches, you need to ensure you apply them in the same order (which is probably assumed).<br></div><div><br></div><div>Pros: you can push 'master', and not push 'devel', ensuring your local config doesn't leak to external repositories.<br></div><div><br></div><div>Cons: The cherry-picked commits have no actual relation to the original commits.<br></div><div><br></div><div>2. Merge devel, and revert commits you don't want<br></div><div><br></div><div>Merge devel into master, then revert the specific commits that you don't want in master. This is also potentially error-prone (as you need to identify the commits to revert).<br></div><div><br></div><div>Pros: Preserves original git history, with commit times and messages unmodified from your development.<br></div><div><br></div><div>Cons: It's really just the inverse of #1, you need to manually identify commits. Additionally, those patches (and all of devel) will be in 'master' history, and will be pushed externally.<br></div><div><br></div><div>3. Rebase your commits.<br></div><div><br></div><div>Rebase allows you to rewrite history. There's a lot of options here (and a lot of potential to ruin things). You can remove commits, combine commits, move your branch, etc.<br></div><div><br></div><div>You can rebase your commits to remove the offending commits. This will preserve a sanitized 'devel' branch, which you can then merge into 'master'.<br></div><div><br></div><div>Pros: Your excluded commits are not pushed.<br></div><div><br></div><div>Cons: Like #1, there is no relation to the original commits (but the original commits no longer exist (maybe), so these are now new original commits). Rebase can be dangerous.<br></div><div><br></div><div id="sig91988184"><div class="signature">-- <br></div><div class="signature"><b>Chris Irwin</b><br></div><div class="signature"><br></div><div class="signature"><span style="font-family:menlo, consolas, monospace, sans-serif" class="font">email: </span><a href="mailto:chris@chrisirwin.ca"><span style="font-family:menlo, consolas, monospace, sans-serif" class="font">chris@chrisirwin.ca</span></a><span style="font-family:menlo, consolas, monospace, sans-serif" class="font"></span><br></div><div class="signature"><span style="font-family:menlo, consolas, monospace, sans-serif" class="font"> xmpp: </span><a href="mailto:chris@chrisirwin.ca"><span style="font-family:menlo, consolas, monospace, sans-serif" class="font">chris@chrisirwin.ca</span></a><span style="font-family:menlo, consolas, monospace, sans-serif" class="font"></span><br></div><div class="signature"><span style="font-family:menlo, consolas, monospace, sans-serif" class="font"> web: </span><a href="https://chrisirwin.ca"><span style="font-family:menlo, consolas, monospace, sans-serif" class="font">https://chrisirwin.ca</span></a><br></div></div><div><br></div></body></html>