Re: Understanding git.git's branch policy

[Petr Baudis <pasky@suse.cz>]

On Sun, Jan 24, 2010 at 06:34:11PM -0500, Steven E. Harris wrote:
> 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