{"thread":{"id":"11646","subject":"Merging using only fast-forward","startedAt":"2008-01-16T15:54:34Z","lastAt":"2008-01-21T06:26:33Z","messageCount":15,"participants":["Sverre Hvammen Johansen","Randal L. Schwartz","Junio C Hamano"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"65552","messageId":"loom.20080116T151930-575@post.gmane.org","threadId":"11646","inReplyTo":null,"subject":"Merging using only fast-forward","fromName":"Sverre Hvammen Johansen","fromEmail":"hvammen@gmail.com","sentAt":"2008-01-16T15:54:34Z","receivedAt":"2008-01-16T15:54:34Z","isPatch":false,"sender":{"key":"hvammen@gmail.com","avatar":"https://gravatar.com/avatar/d1fc25ec327eea135af60fe7b56b2a2e21f711aa32167e7f505014ec88aa24bc?d=mp&s=160"},"body":"Hi,\n\n\nI have a work flow where A is only allowed to rebase and B is only allowed to\nfast-forward. They both fetch from each other and rebase/merge using pull. On\nA I can use the configuration branch..rebase but it does not seem to be an\noption to enforce a fast-forward on B.\n\nIf there are changes on both A and B that have not yet been integrated (by A\ndoing a pull (fetch/rebase)) I want a pull (fetch/merge) on B to fail.\n\nIt would be useful with a configuration ala branch..fast-forward or an\noption --ff-only to git-merge so I could use the configuration\nbranch..mergeoptions.\n\nIs there any other way to achieve this?\n\nThanks for a great tool. I am using git with accurev where B is the integrator\nbetween git and accurev (commits flow in both directions). I imagine this could\nbe useful in other environments as well.\n\n-- \nSverre Hvammen Johansen\n"},{"id":"65555","messageId":"863asxivlj.fsf@blue.stonehenge.com","threadId":"11646","inReplyTo":"loom.20080116T151930-575@post.gmane.org","subject":"Re: Merging using only fast-forward","fromName":"Randal L. Schwartz","fromEmail":"merlyn@stonehenge.com","sentAt":"2008-01-16T16:27:52Z","receivedAt":"2008-01-16T16:27:52Z","isPatch":false,"sender":{"key":"merlyn@stonehenge.com","avatar":"https://gravatar.com/avatar/dc528d210743ff0333e6213f9ee7b33b23f1b7bc1f3c5a8c2d819074ecd7ab19?d=mp&s=160"},"body":">>>>> \"Sverre\" == Sverre Hvammen Johansen writes:\n\nSverre> If there are changes on both A and B that have not yet been integrated\nSverre> (by A doing a pull (fetch/rebase)) I want a pull (fetch/merge) on B to\nSverre> fail.\n\nJunio implemented a 7-line patch on the IRC channel (calling parts of it\n\"for randal\" or something, I believe :) to do precisely this.\n\nPerhaps you can test it, and submit it as if it were your idea. I, for one,\nwould use it as well. I'm doing ugly things with parsing the output of\ngit-status right now to achieve the same thing.\n\n-- \nRandal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095\n \nPerl/Unix/security consulting, Technical writing, Comedy, etc. etc.\nSee PerlTraining.Stonehenge.com for onsite and open-enrollment Perl training!\n"},{"id":"65598","messageId":"7vwsq9o6ls.fsf@gitster.siamese.dyndns.org","threadId":"11646","inReplyTo":"863asxivlj.fsf@blue.stonehenge.com","subject":"Re: Merging using only fast-forward","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-16T20:31:11Z","receivedAt":"2008-01-16T20:31:11Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"merlyn@stonehenge.com (Randal L. Schwartz) writes:\n\n> Junio implemented a 7-line patch on the IRC channel (calling parts of it\n> \"for randal\" or something, I believe :) to do precisely this.\n>\n> Perhaps you can test it, and submit it as if it were your idea. I, for one,\n> would use it as well. I'm doing ugly things with parsing the output of\n> git-status right now to achieve the same thing.\n\nThe mechanism itself is simple. \n\n\thttp://git.pastebin.com/m156a1856\n\nA sane integration is a different story.\n\nWe have --ff and --no-ff options to merge. How should this new\noption --ff-only mesh with them? Perhaps we would want to have\nan option --ff that takes three values?\n\n\t--ff=never\n --ff=normal\n --ff=only\n\nand have the first one be synonym for existing --no-ff, the second\none to be a synonym for not giving anything (or giving --ff\nexplicitly), and the third one to be this new mode of operation?\n"},{"id":"65615","messageId":"402c10cd0801161438u7443ebf2xdf1d6f3040ceb1a9@mail.gmail.com","threadId":"11646","inReplyTo":"7vwsq9o6ls.fsf@gitster.siamese.dyndns.org","subject":"Re: Merging using only fast-forward","fromName":"Sverre Hvammen Johansen","fromEmail":"hvammen@gmail.com","sentAt":"2008-01-16T22:38:20Z","receivedAt":"2008-01-16T22:38:20Z","isPatch":false,"sender":{"key":"hvammen@gmail.com","avatar":"https://gravatar.com/avatar/d1fc25ec327eea135af60fe7b56b2a2e21f711aa32167e7f505014ec88aa24bc?d=mp&s=160"},"body":"On Jan 16, 2008 12:31 PM, Junio C Hamano wrote:\n> A sane integration is a different story.\n>\n> We have --ff and --no-ff options to merge. How should this new\n> option --ff-only mesh with them? Perhaps we would want to have\n> an option --ff that takes three values?\n>\n> --ff=never\n> --ff=normal\n> --ff=only\n>\n> and have the first one be synonym for existing --no-ff, the second\n> one to be a synonym for not giving anything (or giving --ff\n> explicitly), and the third one to be this new mode of operation?\n\nThanks for the patch. I can probably look into it tonight and do the\nsuggested integration and test it out, I keep you posted.\n\n-- \nSverre Hvammen Johansen\n"},{"id":"65617","messageId":"7v3asxo06n.fsf@gitster.siamese.dyndns.org","threadId":"11646","inReplyTo":"402c10cd0801161438u7443ebf2xdf1d6f3040ceb1a9@mail.gmail.com","subject":"Re: Merging using only fast-forward","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-16T22:49:52Z","receivedAt":"2008-01-16T22:49:52Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sverre Hvammen Johansen\" writes:\n\n> On Jan 16, 2008 12:31 PM, Junio C Hamano wrote:\n>> A sane integration is a different story.\n>>\n>> We have --ff and --no-ff options to merge. How should this new\n>> option --ff-only mesh with them? Perhaps we would want to have\n>> an option --ff that takes three values?\n>>\n>> --ff=never\n>> --ff=normal\n>> --ff=only\n>>\n>> and have the first one be synonym for existing --no-ff, the second\n>> one to be a synonym for not giving anything (or giving --ff\n>> explicitly), and the third one to be this new mode of operation?\n>\n> Thanks for the patch. I can probably look into it tonight and do the\n> suggested integration and test it out, I keep you posted.\n\nWell, no, I did not _suggest_ that particular integration. I do\nnot even know what the right answer is to these questions. The\nUI that pastebin patch implements, which uses totally separate\nflags, may turn out to be the right approach. If you want to\ncarry the torch forward on this topic, that's great. It is very\nmuch appreciated. But one of the things included in that work\nincludes thinking and deciding which UI is better between the\npatch in the pastebin and the one that tries to introduce a\nunified --ff= option. I simply do not know the answer,\nand prefer not having to think about it during a pre-release\nfeature freeze.\n\nComing up with a 7-liner quick-and-dirty solution is one thing.\nIt was easy (although I haven't tested it, so it may not work at\nall!). But if we want to mainline it, we need to think\ncarefully how the new feature integrates well with what we\nalready have. That's all I wanted to say.\n"},{"id":"65692","messageId":"402c10cd0801162253n6ab19f51y53d0baa16319adaa@mail.gmail.com","threadId":"11646","inReplyTo":"7vwsq9o6ls.fsf@gitster.siamese.dyndns.org","subject":"Re: Merging using only fast-forward","fromName":"Sverre Hvammen Johansen","fromEmail":"hvammen@gmail.com","sentAt":"2008-01-17T06:53:15Z","receivedAt":"2008-01-17T06:53:15Z","isPatch":false,"sender":{"key":"hvammen@gmail.com","avatar":"https://gravatar.com/avatar/d1fc25ec327eea135af60fe7b56b2a2e21f711aa32167e7f505014ec88aa24bc?d=mp&s=160"},"body":"On Jan 16, 2008 12:31 PM, Junio C Hamano wrote:\n> merlyn@stonehenge.com (Randal L. Schwartz) writes:\n>\n> > Junio implemented a 7-line patch on the IRC channel (calling parts of it\n> > \"for randal\" or something, I believe :) to do precisely this.\n>\n> The mechanism itself is simple.\n>\n> http://git.pastebin.com/m156a1856\n\nI know that the patch you wrote is not good. However, it is a good\nstarting point.\n\nWe need to consider cases where the branch we are merging with is an\nancestor or an descendant of HEAD. The patch only take descendants\ninto account. There may also be more than one branch we are merging\nwith. All these cases must be considered. In the case of an octopus, the\ncases are slightly more complicated.\n\nI have a patch that work for all cases except for some octopus cases. I\nhave written a few test case. All existing tests succeeds.\n\nI will not be able to work on this for a few days, but I expect to have a\nworking patch some time this weekend.\n\nI have not looked at the documentation but assume it should not be to\nhard to add some documentation as well.\n\n-- \nSverre Hvammen Johansen\n"},{"id":"65826","messageId":"402c10cd0801172258p9a1a97bt682fa012fcebd13c@mail.gmail.com","threadId":"11646","inReplyTo":"402c10cd0801162253n6ab19f51y53d0baa16319adaa@mail.gmail.com","subject":"Re: Merging using only fast-forward","fromName":"Sverre Hvammen Johansen","fromEmail":"hvammen@gmail.com","sentAt":"2008-01-18T06:58:50Z","receivedAt":"2008-01-18T06:58:50Z","isPatch":false,"sender":{"key":"hvammen@gmail.com","avatar":"https://gravatar.com/avatar/d1fc25ec327eea135af60fe7b56b2a2e21f711aa32167e7f505014ec88aa24bc?d=mp&s=160"},"body":"On Jan 16, 2008 10:53 PM, Sverre Hvammen Johansen wrote:\n> We need to consider cases where the branch we are merging with is an\n> ancestor or an descendant of HEAD. The patch only take descendants\n> into account. There may also be more than one branch we are merging\n> with. All these cases must be considered. In the case of an octopus, the\n> cases are slightly more complicated.\n\nI have been testing octopus merges and figured it is not very smart with\nrespect to fast forward. I would like it to do a fast forward whenever it\nmakes sense to do that. Consider the following:\n\n -- c1 -- A\n / / \\\nc0 -- c2 -- C\n \\ \\ /\n -- c3 -- B\n\nA is a merge between c1 and c2, B is a merge between c2 and c3, and C is a\nmerge between A and B.\n\nc1 merged with A does a fast forward to A, A merged with C does a fast forward\nto C, but an octopus merge of c1 with A and C does not fast forward to\nC. I would\nexpect it to fast forward to C. The commit graph above have several other cases\nwhere an octopus merge can be reduced to a fast forward or a recursive merge.\n\nI suggest a separate pass before we choose merge strategy. Remove commits\nthat can be fast forwarded to any of the other commits from the\nequation and fast\nforward the current branch if possible. The remaining commits are then taken\ninto consideration. This may reduce the number of commits and thus result in\na fast forward or another merge strategy.\n\nI intend to make the patch for the option --ff-only as simple as\npossible, where it\nwill fail where more than two commits are involved. If the above suggested pass\nis implemented it should also take affect for --ff-only.\n\nDoes this make sense?\n\n-- \nSverre Hvammen Johansen\n"},{"id":"65924","messageId":"7vodbibzch.fsf@gitster.siamese.dyndns.org","threadId":"11646","inReplyTo":"402c10cd0801172258p9a1a97bt682fa012fcebd13c@mail.gmail.com","subject":"Re: Merging using only fast-forward","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-18T21:25:34Z","receivedAt":"2008-01-18T21:25:34Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sverre Hvammen Johansen\" writes:\n\n> I have been testing octopus merges and figured it is not very smart with\n> respect to fast forward.\n\nOctopus is designed to be simple and stupid. Its sole purpose\nis to bind more than two _independent_ development tracks, and\nby definition if they are totally independent, like A and B and\nC all forked from the current tip of our HEAD, it should make a\nnew commit that is children of A and B and C. If B and C are\nnot independent (e.g. C is a descendant of B), you should not be\nusing Octopus to begin with.\n\nThe thing is, Octopus makes the bisection (not the internal\nprocessing of \"git bisect\", but the whole experience with \"git\nbisect\" which is measured by the number of commits you may have\nto test to find the one bad commit) less efficient, especially\nwhen the branches that are merged are not independent topics.\n\nSo keep it simple, and do not use Octopus if there is no\njustification other than \"it looks cool\" you can come up with.\n\nI do not mind a patch to git-merge-octopus to discurage its use\neven more by detecting the casen where some of the merged\nbranches are not independent and refusing to work, but that is\na post 1.5.4 topic.\n"},{"id":"65952","messageId":"402c10cd0801190228o68995493u9b8b40e1557092dd@mail.gmail.com","threadId":"11646","inReplyTo":"7vodbibzch.fsf@gitster.siamese.dyndns.org","subject":"Re: Merging using only fast-forward","fromName":"Sverre Hvammen Johansen","fromEmail":"hvammen@gmail.com","sentAt":"2008-01-19T10:28:55Z","receivedAt":"2008-01-19T10:28:55Z","isPatch":false,"sender":{"key":"hvammen@gmail.com","avatar":"https://gravatar.com/avatar/d1fc25ec327eea135af60fe7b56b2a2e21f711aa32167e7f505014ec88aa24bc?d=mp&s=160"},"body":"On Jan 18, 2008 1:25 PM, Junio C Hamano wrote:\n> ...\n> So keep it simple, and do not use Octopus if there is no\n> justification other than \"it looks cool\" you can come up with.\n>\n> I do not mind a patch to git-merge-octopus to discurage its use\n> even more by detecting the casen where some of the merged\n> branches are not independent and refusing to work, but that is\n> a post 1.5.4 topic.\n\nInstead of refusing to work, such merge commits can be fast forwarded,\nrecorded as a \"normal\" commit with two children, or an octopus with\nfewer children than those specified by the user.\n\nThe more I think about this is that --ff-only should really be\nspecified as a merge strategy (single) and not as an special case of\n--ff. All merge strategies can then take any number of commits, but\nwill only succeed if the commits can be reduced down to two or fewer\nfor resolve/recursive and one for single.\n\nCommit reduction is simpler for single than the other merge strategies.\n\nI suggest we keep it simple and implement this new feature as a merge\nstrategy and the commit reduction is only done for fast-forward.\n\nI will create a good number of test cases so we should be comfortable\nwith this new feature.\n\nA later patch will implement the commit reduction for the other merge\nstrategies. --no-ff will then have the meaning: No fast forward of\nany commit. All commits specified by the user will be recorded.\n\n-- \nSverre Hvammen Johansen\n"},{"id":"65953","messageId":"402c10cd0801190238l6c8975bt34185d78536583e2@mail.gmail.com","threadId":"11646","inReplyTo":"402c10cd0801190228o68995493u9b8b40e1557092dd@mail.gmail.com","subject":"Re: Merging using only fast-forward","fromName":"Sverre Hvammen Johansen","fromEmail":"hvammen@gmail.com","sentAt":"2008-01-19T10:38:57Z","receivedAt":"2008-01-19T10:38:57Z","isPatch":false,"sender":{"key":"hvammen@gmail.com","avatar":"https://gravatar.com/avatar/d1fc25ec327eea135af60fe7b56b2a2e21f711aa32167e7f505014ec88aa24bc?d=mp&s=160"},"body":"On Jan 19, 2008 2:28 AM, Sverre Hvammen Johansen wrote:\n> I suggest we keep it simple and implement this new feature as a merge\n> strategy and the commit reduction is only done for fast-forward.\n\ns/fast-forward/single/\n\n-- \nSverre Hvammen Johansen\n"},{"id":"65955","messageId":"7vzlv2858y.fsf@gitster.siamese.dyndns.org","threadId":"11646","inReplyTo":"402c10cd0801190228o68995493u9b8b40e1557092dd@mail.gmail.com","subject":"Re: Merging using only fast-forward","fromName":"Junio C Hamano","fromEmail":"gitster@pobox.com","sentAt":"2008-01-19T10:43:57Z","receivedAt":"2008-01-19T10:43:57Z","isPatch":false,"sender":{"key":"gitster@pobox.com","avatar":"https://avatars.githubusercontent.com/u/54884?v=4"},"body":"\"Sverre Hvammen Johansen\" writes:\n\n> The more I think about this is that --ff-only should really be\n> specified as a merge strategy (single) and not as an special case of\n> --ff. All merge strategies can then take any number of commits, but\n> will only succeed if the commits can be reduced down to two or fewer\n> for resolve/recursive and one for single.\n\nInteresting.\n\nAt one end of the spectrum, we have these crazy people who want\ngit to record something that is not a merge at all as a merge\nwith --no-ff. At the other end of the spectrum, we have these\nother crazy people who want git to outsmart them by allowing\nthem to throw random set of commits as potential parents,\nremove duplicates and figure out how many real parents the\nresulting merge should have (including the case that it may not\neven have any).\n\nI'll have to think about it, but it sounds like a promising\nidea.\n"},{"id":"65959","messageId":"402c10cd0801190430y7d3253c9ue36ce4e6647c6f0d@mail.gmail.com","threadId":"11646","inReplyTo":"402c10cd0801190427o62493073s408959aa5701ca86@mail.gmail.com","subject":"Re: Merging using only fast-forward","fromName":"Sverre Hvammen Johansen","fromEmail":"hvammen@gmail.com","sentAt":"2008-01-19T12:30:54Z","receivedAt":"2008-01-19T12:30:54Z","isPatch":false,"sender":{"key":"hvammen@gmail.com","avatar":"https://gravatar.com/avatar/d1fc25ec327eea135af60fe7b56b2a2e21f711aa32167e7f505014ec88aa24bc?d=mp&s=160"},"body":"On Jan 19, 2008 2:43 AM, Junio C Hamano wrote:\n> At one end of the spectrum, we have these crazy people who want\n> git to record something that is not a merge at all as a merge\n> with --no-ff. At the other end of the spectrum, we have these\n> other crazy people who want git to outsmart them by allowing\n> them to throw random set of commits as potential parents,\n> remove duplicates and figure out how many real parents the\n> resulting merge should have (including the case that it may not\n> even have any).\n\nI guess the most common use case would be where you have at least\nthree developers and they randomly fetch and merge between each other.\n They usually are not aware of where each other are and everyone\navoids octopus. They end up with more merge commits than needed\nsimply because they sometime pick the wrong order. If they instead\nhad git find the real parents they would get fewer merge commits.\n\n-- \nSverre Hvammen Johansen\n"},{"id":"65961","messageId":"402c10cd0801190439j7e5ad661me2ba4007bbe2e882@mail.gmail.com","threadId":"11646","inReplyTo":"7vzlv2858y.fsf@gitster.siamese.dyndns.org","subject":"Re: Merging using only fast-forward","fromName":"Sverre Hvammen Johansen","fromEmail":"hvammen@gmail.com","sentAt":"2008-01-19T12:39:20Z","receivedAt":"2008-01-19T12:39:20Z","isPatch":false,"sender":{"key":"hvammen@gmail.com","avatar":"https://gravatar.com/avatar/d1fc25ec327eea135af60fe7b56b2a2e21f711aa32167e7f505014ec88aa24bc?d=mp&s=160"},"body":"On Jan 19, 2008 2:43 AM, Junio C Hamano wrote:\n> At one end of the spectrum, we have these crazy people who want\n> git to record something that is not a merge at all as a merge\n> with --no-ff. At the other end of the spectrum, we have these\n> other crazy people who want git to outsmart them by allowing\n> them to throw random set of commits as potential parents,\n> remove duplicates and figure out how many real parents the\n> resulting merge should have (including the case that it may not\n> even have any).\n\nI guess the most common use case would be where you have at least\nthree developers and they randomly fetch and merge between each other.\n They usually are not aware of where each other are and everyone\navoids octopus. They end up with more merge commits than needed\nsimply because they sometime pick the wrong order. If they instead\nhad git find the real parents they would get fewer merge commits.\n\n-- \nSverre Hvammen Johansen\n"},{"id":"65962","messageId":"loom.20080119T125348-869@post.gmane.org","threadId":"11646","inReplyTo":"402c10cd0801190430y7d3253c9ue36ce4e6647c6f0d@mail.gmail.com","subject":"Please don't reply to this thread","fromName":"Sverre Hvammen Johansen","fromEmail":"hvammen@gmail.com","sentAt":"2008-01-19T12:58:18Z","receivedAt":"2008-01-19T12:58:18Z","isPatch":false,"sender":{"key":"hvammen@gmail.com","avatar":"https://gravatar.com/avatar/d1fc25ec327eea135af60fe7b56b2a2e21f711aa32167e7f505014ec88aa24bc?d=mp&s=160"},"body":"Please don't reply to this thread. Sorry for the noise.\n"},{"id":"66084","messageId":"402c10cd0801202226y5bf3e00duf8ae190c6a751ee3@mail.gmail.com","threadId":"11646","inReplyTo":"7vzlv2858y.fsf@gitster.siamese.dyndns.org","subject":"Re: Merging using only fast-forward","fromName":"Sverre Hvammen Johansen","fromEmail":"hvammen@gmail.com","sentAt":"2008-01-21T06:26:33Z","receivedAt":"2008-01-21T06:26:33Z","isPatch":false,"sender":{"key":"hvammen@gmail.com","avatar":"https://gravatar.com/avatar/d1fc25ec327eea135af60fe7b56b2a2e21f711aa32167e7f505014ec88aa24bc?d=mp&s=160"},"body":"On Jan 19, 2008 2:43 AM, Junio C Hamano wrote:\n> At one end of the spectrum, we have these crazy people who want\n> git to record something that is not a merge at all as a merge\n> with --no-ff. At the other end of the spectrum, we have these\n> other crazy people who want git to outsmart them by allowing\n> them to throw random set of commits as potential parents,\n> remove duplicates and figure out how many real parents the\n> resulting merge should have (including the case that it may not\n> even have any).\n\nI am currently working on a patch for this. I have some new tests for\nthis but more is needed and there is no documentation.\n\nThe only case that currently is not working is the case where I need\nto fast forward head and then do a merge. Do I need to update the\nfiles in the working directory twice (once after the fast forward and\nthen once by the merge) or can I somehow get lets say\ngit-merge-recursive to do this part for me?\n\nThe patch I have that handles the above failing case by not fast\nforwarding HEAD, but instead use it together with the other real_heads\nwork (all tests succeed).\n\n-- \nSverre Hvammen Johansen\n"}]}