{"thread":{"id":"42347","subject":"Best Practices with code/build fixes post-merge?","startedAt":"2016-05-16T19:19:52Z","lastAt":"2016-05-16T19:42:24Z","messageCount":2,"participants":["Robert Dailey","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"286704","messageId":"CAHd499D7kgMtUXgBgsUzNLEMuuHRE7j_T1mikL21KJjDE8ey3A@mail.gmail.com","threadId":"42347","inReplyTo":null,"subject":"Best Practices with code/build fixes post-merge?","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2016-05-16T19:19:52Z","receivedAt":"2016-05-16T19:19:52Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"Sometimes, I merge 2 branches that have deviated quite a bit. A\nworst-case example would be some API change. The topic branch\n(long-lived) may start using the old API. However, once I merge the\ntopic back to master, that API no longer exists. As such, every place\nthat introduces a usage of the old API will fail to build (but won't\nnecessarily cause a conflict during a merge).\n\nConcerning best practices, which of the following is better?\n\n1. Make the fixes (which may be vast), smoke test, get a general feel\nthat everything is working on master again. Amend the changes to the\nprevious merge commit.\n\n2. Make the fixes as in step 1, but instead of amending to the merge\ncommit, create a new descendant commit representing the changes.\n\nConcerns I see with either choice:\n\n1. Pros: Changes are atomic. Cons: merge commits are typically very\ndifficult to view, especially from logs. For example, `git log\n--name-status` does nothing for merge commits, so it makes it\nless-intuitive to get a good overview of changes.\n\n2. Opposite of #1: Changes are not atomic (con), but it makes it very\nclear that these changes were made \"on top of\" the merge (pro)\n\nIs there a best practice here? What do each of you do as a personal\npreference or policy? Thanks in advance.\n"},{"id":"286706","messageId":"xmqqr3d123j3.fsf@gitster.mtv.corp.google.com","threadId":"42347","inReplyTo":"CAHd499D7kgMtUXgBgsUzNLEMuuHRE7j_T1mikL21KJjDE8ey3A@mail.gmail.com","subject":"Re: Best Practices with code/build fixes post-merge?","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2016-05-16T19:42:24Z","receivedAt":"2016-05-16T19:42:24Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"Robert Dailey <rcdailey.lists@gmail.com> writes:\n\n> Sometimes, I merge 2 branches that have deviated quite a bit. A\n> worst-case example would be some API change. The topic branch\n> (long-lived) may start using the old API. However, once I merge the\n> topic back to master, that API no longer exists. As such, every place\n> that introduces a usage of the old API will fail to build (but won't\n> necessarily cause a conflict during a merge).\n> ...\n> Is there a best practice here? What do each of you do as a personal\n> preference or policy? Thanks in advance.\n\nI think the best practice is to make sure your \"some API change\" is\ndone in a way competent people do.  Namely, have a thin wrapper to\nemulate the old API so that such a long-lived topic that adds new\ncaller of old API would still be syntactically and semantically\ncorrect after getting textually merged.\n\nYour developers however are not perfect (nobody is), so the next\nbest is to arrange that a build fails (which seems to be what you\nhave), so that you can notice at the merge time.\n\nIf the adjustment of an application that uses the old API to use the\nnew one is simple enough, amending the merge would be my preference,\nas a merge commit should be \"a single atomic change\" as any other\ncommit.  But at the same time, you do not have to be too worried\nabout such a \"mismerge\".  A merge commit is a change that can\nintroduce a bug as any other commit.  After all, we are dealing with\nhuman endeavours.  So \"I did this merge as a single atomic change,\nmerging the work done in the topic while adjusting the way the topic\ndid certain things using old API to use new API, to the best of my\nability, but I may have introduced a bug\" is perfectly fine.  You do\na commit to ensure it is correct to the best of your ability, and\nbecause everybody knows you are not perfect (nobody is), nobody\nexpects your commit is always correct.  If you find a bug later, you\njust fix up with a follow-up commit.  A merge commit is no special.\n\nMy personal preference, if adjustment from old API to new API is\nmore involved, is to have a new topic branch that is forked from the\ntrunk and merge the topic with new call sites of old API into it.\nI'd fix as much breakage in that merge commit, and then fix things\nup as necessary in follow up commits on that new topic branch as\nnecessary.  After that, merging the result to the trunk.\n"}]}