Re: Understanding git.git's branch policy

From: Petr Baudis <pasky@suse.cz>
Date: Jan 25, 2010, 00:17 UTC
Message-ID: <20100125001732.GD9553@machine.or.cz>
In-Reply-To: <83pr4znklo.fsf@torus.sehlabs.com>

On Sun, Jan 24, 2010 at 06:34:11PM -0500, Steven E. Harris wrote:

Show 16 quoted lines

> Radding the maintain-git.txt document¹, there are a few points that I'm
> having trouble decoding. Under "The Policy", it notes
> 
> ,----
> | The tips of 'master', 'maint' and 'next' branches will always
> | fast-forward, to allow people to build their own customization on top
> | of them.
> `----
> 
> I understand that a "fast-forward merge" means that one's current HEAD
> commit is an ancestor of the evolved branch's head, so that the HEAD
> pointer can move forward to "catch up" without needing to combine
> disparate content.
> 
> How does this relate to the prescribed use of the "master", "maint", and
> "next" branches? What operations or patterns does it constrain against?

Rebases or other jumps. New tip of 'master' will always be descendant of old tip of 'master', never a commit from a parallel commit line. This is preserved over commits and merges, but not over operations that rewrite history - rebase, filter-branch and such.

The term "fast-forward" is used commonly in this sense. E.g. git push will typically deny you to push out a branch that is not fastforwarding the currently pushed out branch, unless you force it to.

-- 
				Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth