{"thread":{"id":"44827","subject":"Rebasing a branch with merges","startedAt":"2017-01-06T19:12:14Z","lastAt":"2017-01-09T21:03:39Z","messageCount":4,"participants":["Robert Dailey","Philip Oakley"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"308884","messageId":"CAHd499BREpaHHyN89a1HchyJiQzPpdo3NSfoLLGVONEmX1m19g@mail.gmail.com","threadId":"44827","inReplyTo":null,"subject":"Rebasing a branch with merges","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2017-01-06T19:12:06Z","receivedAt":"2017-01-06T19:12:14Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"Here's the scenario:\n\nI create a topic branch so one other developer and myself can work on\na feature that takes 2 weeks to complete. During that 2 week period,\nchanges are occurring on master that I need in my topic branch. Since\nI have a collaborator on the branch, I opt for merges instead of\nrebase.\n\nEach day I merge from master to the topic branch, which changes code\nI'm actively working in and requires semantic changes (functions\nrenamed, moved, etc).\n\nOnce I'm ready to merge the topic branch back into master, I have two\noptions (bearing in mind the goal is to keep history as clean as\npossible. Furthermore this implies that the constant merging into\ntopic from master has made the topic branch look unwieldy and\ndifficult to audit):\n\n1. Do a squash merge, which keeps history clean but we lose context\nfor the important bits (the commits representing units of work that\ncontribute to the topic itself).\n\n2. Do a final rebase prior to merging.\n\n#2 doesn't seem to be possible due to patch ordering. For example, if\nI have real commits after merge commits that depend on those changes\nfrom master being present as a base at that point in time, the rebase\nwill cause the patch before it to no longer include those changes from\nmaster.\n\nIs there a mechanism to rebase in this situation to both achieve a\nclean, linear history for the topic branch and allow fast forward\nmerging if desired, while still not causing superfluous conflicts due\nto the merges being omitted during the rebase?\n\nThanks in advance for any advice in this scenario.\n"},{"id":"308898","messageId":"49C0981FE7D04AE2AC0BBB011FD74B90@PhilipOakley","threadId":"44827","inReplyTo":"CAHd499BREpaHHyN89a1HchyJiQzPpdo3NSfoLLGVONEmX1m19g@mail.gmail.com","subject":"Re: Rebasing a branch with merges","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2017-01-06T21:29:03Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Robert Dailey\" \n> Here's the scenario:\n>\n> I create a topic branch so one other developer and myself can work on\n> a feature that takes 2 weeks to complete. During that 2 week period,\n> changes are occurring on master that I need in my topic branch. Since\n> I have a collaborator on the branch, I opt for merges instead of\n> rebase.\n>\n> Each day I merge from master to the topic branch, which changes code\n> I'm actively working in and requires semantic changes (functions\n> renamed, moved, etc).\n>\n> Once I'm ready to merge the topic branch back into master, I have two\n> options (bearing in mind the goal is to keep history as clean as\n> possible. Furthermore this implies that the constant merging into\n> topic from master has made the topic branch look unwieldy and\n> difficult to audit):\n\na broader question zero;\n0. Is the merge always clean? Do you always do a preparatory fixup! to \nensure that the merge will be clean?\n\nEnsuring that the merge will be clean should greatly simplify your decision \nabout process.\n\n>\n> 1. Do a squash merge, which keeps history clean but we lose context\n> for the important bits (the commits representing units of work that\n> contribute to the topic itself).\n>\n> 2. Do a final rebase prior to merging.\n>\n> #2 doesn't seem to be possible due to patch ordering. For example, if\n> I have real commits after merge commits that depend on those changes\n> from master being present as a base at that point in time, the rebase\n> will cause the patch before it to no longer include those changes from\n> master.\n\nHow much of the historic fixups to cover changes on master do you want to \nkeep visible? i.e. how many fork-points are truly needed (a. by you, b. by \nthe project - personal knowledge vs corporate knowledge).?\n\n>\n> Is there a mechanism to rebase in this situation to both achieve a\n> clean, linear history for the topic branch and allow fast forward\n> merging if desired, while still not causing superfluous conflicts due\n> to the merges being omitted during the rebase?\n>\n> Thanks in advance for any advice in this scenario.\n>\n\nHave you looked at @dscho's garden-shears scripts that he uses on \nGit-for-Windows as he has to continuously rebase the Windows specific \npatches on top of the progressing Git master? Very similar issues ;-)\n\nhttps://github.com/git-for-windows/build-extra/blob/master/shears.sh \nhttps://blogs.msdn.microsoft.com/visualstudioalm/2016/09/03/whats-new-in-git-for-windows-2-10/ \n(#Fun Facts)\n\n--\nPhilip \n\n"},{"id":"309052","messageId":"CAHd499CuZBXF0AddP7AfqtzvA8rBArwqtktRmNdD-kwGUCruLg@mail.gmail.com","threadId":"44827","inReplyTo":"49C0981FE7D04AE2AC0BBB011FD74B90@PhilipOakley","subject":"Re: Rebasing a branch with merges","fromName":"Robert Dailey","fromEmail":"rcdailey.lists@gmail.com","sentAt":"2017-01-09T18:52:21Z","receivedAt":"2017-01-09T18:52:31Z","isPatch":false,"sender":{"key":"rcdailey.lists@gmail.com","avatar":null},"body":"On Fri, Jan 6, 2017 at 3:28 PM, Philip Oakley wrote:\n> From: \"Robert Dailey\" \n>>\n>> Here's the scenario:\n>>\n>> I create a topic branch so one other developer and myself can work on\n>> a feature that takes 2 weeks to complete. During that 2 week period,\n>> changes are occurring on master that I need in my topic branch. Since\n>> I have a collaborator on the branch, I opt for merges instead of\n>> rebase.\n>>\n>> Each day I merge from master to the topic branch, which changes code\n>> I'm actively working in and requires semantic changes (functions\n>> renamed, moved, etc).\n>>\n>> Once I'm ready to merge the topic branch back into master, I have two\n>> options (bearing in mind the goal is to keep history as clean as\n>> possible. Furthermore this implies that the constant merging into\n>> topic from master has made the topic branch look unwieldy and\n>> difficult to audit):\n>\n>\n> a broader question zero;\n> 0. Is the merge always clean? Do you always do a preparatory fixup! to\n> ensure that the merge will be clean?\n>\n> Ensuring that the merge will be clean should greatly simplify your decision\n> about process.\n\nI don't understand what you're asking. How would I do a fixup with\nmerges? Can you explain a bit? Normally the only time I use fixup! or\nsquash! is for local changes prior to pushing.\n\n>> 1. Do a squash merge, which keeps history clean but we lose context\n>> for the important bits (the commits representing units of work that\n>> contribute to the topic itself).\n>>\n>> 2. Do a final rebase prior to merging.\n>>\n>> #2 doesn't seem to be possible due to patch ordering. For example, if\n>> I have real commits after merge commits that depend on those changes\n>> from master being present as a base at that point in time, the rebase\n>> will cause the patch before it to no longer include those changes from\n>> master.\n>\n>\n> How much of the historic fixups to cover changes on master do you want to\n> keep visible? i.e. how many fork-points are truly needed (a. by you, b. by\n> the project - personal knowledge vs corporate knowledge).?\n\n\nAgain, I do not understand. Maybe the first question you asked needs\nto be understood before I can answer this one. Sorry for the trouble.\n"},{"id":"309068","messageId":"80DC824CA6974DF7A65A116A5CA83E01@PhilipOakley","threadId":"44827","inReplyTo":"CAHd499CuZBXF0AddP7AfqtzvA8rBArwqtktRmNdD-kwGUCruLg@mail.gmail.com","subject":"Re: Rebasing a branch with merges","fromName":"Philip Oakley","fromEmail":"philipoakley@iee.org","sentAt":null,"receivedAt":"2017-01-09T21:03:39Z","isPatch":false,"sender":{"key":"philipoakley@iee.email","avatar":"https://avatars.githubusercontent.com/u/914343?v=4"},"body":"From: \"Robert Dailey\" \n> On Fri, Jan 6, 2017 at 3:28 PM, Philip Oakley \n> wrote:\n>> From: \"Robert Dailey\" \n>>>\n>>> Here's the scenario:\n>>>\n>>> I create a topic branch so one other developer and myself can work on\n>>> a feature that takes 2 weeks to complete. During that 2 week period,\n>>> changes are occurring on master that I need in my topic branch. Since\n>>> I have a collaborator on the branch, I opt for merges instead of\n>>> rebase.\n>>>\n>>> Each day I merge from master to the topic branch, which changes code\n>>> I'm actively working in and requires semantic changes (functions\n>>> renamed, moved, etc).\n>>>\n>>> Once I'm ready to merge the topic branch back into master, I have two\n>>> options (bearing in mind the goal is to keep history as clean as\n>>> possible. Furthermore this implies that the constant merging into\n>>> topic from master has made the topic branch look unwieldy and\n>>> difficult to audit):\n>>\n>>\n>> a broader question zero;\n>> 0. Is the merge always clean? Do you always do a preparatory fixup! to\n>> ensure that the merge will be clean?\n>>\n>> Ensuring that the merge will be clean should greatly simplify your \n>> decision\n>> about process.\n>\n> I don't understand what you're asking. How would I do a fixup with\n> merges? Can you explain a bit? Normally the only time I use fixup! or\n> squash! is for local changes prior to pushing.\n>\n\nI was using 'fixup!' figuratively, rather than literally. If I understand \nthe general setup correctly, what you want is that if one does a trial \nmerge, then it must merge cleanly, compile and pass all tests, or if it \ndoesn't, you would need to add that extra commit to ensure that you get that \nclean merge.\n\nThe alternative is that there is extra work to be done after the 'merge' \n(which may be a management choice) to then get your nice code ready for \nwider release - it may even be someone elses job to do 'integration'.\n\nEither way, at least if you rationalise the clean end point it becomes \neasier to discuss the start point. If both ends are 'dirty' it is an open \nargument...\n\n>>> 1. Do a squash merge, which keeps history clean but we lose context\n>>> for the important bits (the commits representing units of work that\n>>> contribute to the topic itself).\n>>>\n>>> 2. Do a final rebase prior to merging.\n>>>\n>>> #2 doesn't seem to be possible due to patch ordering. For example, if\n>>> I have real commits after merge commits that depend on those changes\n>>> from master being present as a base at that point in time, the rebase\n>>> will cause the patch before it to no longer include those changes from\n>>> master.\n>>\n>>\n>> How much of the historic fixups to cover changes on master do you want to\n>> keep visible? i.e. how many fork-points are truly needed (a. by you, b. \n>> by\n>> the project - personal knowledge vs corporate knowledge).?\n>\n>\n> Again, I do not understand. Maybe the first question you asked needs\n> to be understood before I can answer this one. Sorry for the trouble.\n>\n\nIn some scenarios it is important to keep the record of the exact start \npoint (date and place) to formally justify the work performed (time eleapsed \netc). Now given the other part of your scenario of a moving api / function \nnaming etc, you now have two reference points - the original start point, \nand the release point of the new api/names.\n\nSo at that point you probably want to merge in those changes (one way or \nanother), which gives you a choice of a true merge (option 1), or adding a \npatch to cherry pick the bulk changes on master (option2), or just the api \nchanges (if you can isolate them) (option3). No option is inherently \nbetter - it will depend on local needs.\n\nFrom a clean code perspective, it's nicest if you can simply rebase your \ncode, but that isn't alway possible. The hard bit is to be clear about the \nlocal issues, and which ones are immutable. These will decide your choice.\n\nPhilip\n\n"}]}