threads / discuss / 22376

Understanding git.git's branch policy

Subject: Understanding git.git's branch policy

## tl;dr

2 messages between Jan 24, 2010 and Jan 25, 2010.

replies: 1people: 2as markdown or json

Steven E. Harris· Jan 24, 2010, 23:34 UTC · lore

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?

Footnotes: 
¹ http://kernel.org/pub/software/scm/git/docs/howto/maintain-git.txt
-- 
Steven E. Harris
Petr Baudis· Jan 25, 2010, 00:17 UTC · re: Steven E. Harris · lore

Re: Understanding git.git's branch policy

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

← back to recent threads