Sometimes, I merge 2 branches that have deviated quite a bit. A worst-case example would be some API change. The topic branch (long-lived) may start using the old API. However, once I merge the topic back to master, that API no longer exists. As such, every place that introduces a usage of the old API will fail to build (but won't necessarily cause a conflict during a merge).
Concerning best practices, which of the following is better? 1. Make the fixes (which may be vast), smoke test, get a general feel that everything is working on master again. Amend the changes to the previous merge commit. 2. Make the fixes as in step 1, but instead of amending to the merge commit, create a new descendant commit representing the changes. Concerns I see with either choice: 1. Pros: Changes are atomic. Cons: merge commits are typically very difficult to view, especially from logs. For example, `git log --name-status` does nothing for merge commits, so it makes it less-intuitive to get a good overview of changes. 2. Opposite of #1: Changes are not atomic (con), but it makes it very clear that these changes were made "on top of" the merge (pro) Is there a best practice here? What do each of you do as a personal preference or policy? Thanks in advance. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected] More majordomo info at http://vger.kernel.org/majordomo-info.html
