[kwlug-disc] git: merging some but not all commits

[Chris Irwin]

On Thu, Mar 21, 2019, at 03:00, Paul Nijjar via kwlug-disc wrote:
> Now it is time to merge the changes I made from devel to master. If I
> naively git merge then I will get commit abcdef, which merges in
> config options for development, which screws everything up for
> production. Oh no!
> 
> I can cherry-pick commits from devel and merge them to master, but
> that seems gross and error-prone. Is there a better way for me to
> merge the changes from devel into master, EXCLUDING a set of commits
> hat I never want merged?

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.

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.

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.

1. Cherry pick the commits you want

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).

Pros: you can push 'master', and not push 'devel', ensuring your local config doesn't leak to external repositories.

Cons: The cherry-picked commits have no actual relation to the original commits.

2. Merge devel, and revert commits you don't want

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).

Pros: Preserves original git history, with commit times and messages unmodified from your development.

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.

3. Rebase your commits.

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.

You can rebase your commits to remove the offending commits. This will preserve a sanitized 'devel' branch, which you can then merge into 'master'.

Pros: Your excluded commits are not pushed.

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.

-- 
*Chris Irwin*

email: chris at chrisirwin.ca
 xmpp: chris at chrisirwin.ca
 web: https://chrisirwin.ca
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://kwlug.org/pipermail/kwlug-disc_kwlug.org/attachments/20190321/5ca15f70/attachment.htm>