{"thread":{"id":"22376","subject":"Understanding git.git's branch policy","startedAt":"2010-01-24T23:34:11Z","lastAt":"2010-01-25T00:17:32Z","messageCount":2,"participants":["Steven E. Harris","Petr Baudis"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"132566","messageId":"83pr4znklo.fsf@torus.sehlabs.com","threadId":"22376","inReplyTo":null,"subject":"Understanding git.git's branch policy","fromName":"Steven E. Harris","fromEmail":"seh@panix.com","sentAt":"2010-01-24T23:34:11Z","receivedAt":"2010-01-24T23:34:11Z","isPatch":false,"sender":{"key":"seh@panix.com","avatar":"https://gravatar.com/avatar/d59ec0f7c010ee73cd67db381a5b865206fed17fd4278f12cdb6277db30033fc?d=mp&s=160"},"body":"Radding the maintain-git.txt document¹, there are a few points that I'm\nhaving trouble decoding. Under \"The Policy\", it notes\n\n,----\n| The tips of 'master', 'maint' and 'next' branches will always\n| fast-forward, to allow people to build their own customization on top\n| of them.\n`----\n\nI understand that a \"fast-forward merge\" means that one's current HEAD\ncommit is an ancestor of the evolved branch's head, so that the HEAD\npointer can move forward to \"catch up\" without needing to combine\ndisparate content.\n\nHow does this relate to the prescribed use of the \"master\", \"maint\", and\n\"next\" branches? What operations or patterns does it constrain against?\n\n\nFootnotes: \n¹ http://kernel.org/pub/software/scm/git/docs/howto/maintain-git.txt\n\n-- \nSteven E. Harris\n"},{"id":"132570","messageId":"20100125001732.GD9553@machine.or.cz","threadId":"22376","inReplyTo":"83pr4znklo.fsf@torus.sehlabs.com","subject":"Re: Understanding git.git's branch policy","fromName":"Petr Baudis","fromEmail":"pasky@suse.cz","sentAt":"2010-01-25T00:17:32Z","receivedAt":"2010-01-25T00:17:32Z","isPatch":false,"sender":{"key":"pasky@ucw.cz","avatar":"https://avatars.githubusercontent.com/u/18439?v=4"},"body":"On Sun, Jan 24, 2010 at 06:34:11PM -0500, Steven E. Harris wrote:\n> Radding the maintain-git.txt document¹, there are a few points that I'm\n> having trouble decoding. Under \"The Policy\", it notes\n> \n> ,----\n> | The tips of 'master', 'maint' and 'next' branches will always\n> | fast-forward, to allow people to build their own customization on top\n> | of them.\n> `----\n> \n> I understand that a \"fast-forward merge\" means that one's current HEAD\n> commit is an ancestor of the evolved branch's head, so that the HEAD\n> pointer can move forward to \"catch up\" without needing to combine\n> disparate content.\n> \n> How does this relate to the prescribed use of the \"master\", \"maint\", and\n> \"next\" branches? What operations or patterns does it constrain against?\n\nRebases or other jumps. New tip of 'master' will always be descendant of\nold tip of 'master', never a commit from a parallel commit line. This is\npreserved over commits and merges, but not over operations that rewrite\nhistory - rebase, filter-branch and such.\n\nThe term \"fast-forward\" is used commonly in this sense. E.g. git push\nwill typically deny you to push out a branch that is not fastforwarding\nthe currently pushed out branch, unless you force it to.\n\n-- \n\t\t\t\tPetr \"Pasky\" Baudis\nA lot of people have my books on their bookshelves.\nThat's the problem, they need to read them. -- Don Knuth\n"}]}