From mboxrd@z Thu Jan  1 00:00:00 1970
From: Scott Wood <scottwood@freescale.com>
Date: Thu, 11 Oct 2012 11:54:46 -0500
Subject: [U-Boot] U-Boot git usage model
In-Reply-To: <20121010204054.6bca1ffc@lilith> (from
	albert.u.boot@aribaud.net on Wed Oct 10 13:40:54 2012)
Message-ID: <1349974486.6903.5@snotra>
List-Id: <u-boot.lists.denx.de>
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
To: u-boot@lists.denx.de

On 10/10/2012 01:40:54 PM, Albert ARIBAUD wrote:
> > > Re committer identity, I don't see the relationship with "by"  
> tags, and
> > > especially with Singed-off-by, since the sign-off is not and must  
> not
> > > be related to the committer of the patch, but to its author(s).
> >
> > At least the way the Linux kernel uses the tag, both the original  
> author
> > of the patch /and/ anyone who applies the patch, cherry-picks the  
> patch,
> > ... must add their S-o-b line. I think U-Boot isn't using that part  
> of
> > the model.
> 
> No, it isn't. IIUC, U-Boot's "Signed-off-by" is supposed to mean "I
> am (one of) the autor(s) of this patch".

Is this documented anywhere?

http://www.denx.de/wiki/U-Boot/DevelopmentProcess says, "U-Boot has  
adopted the Linux kernel signoff policy".

Actual behavior is probably inconsistent between custodians.

> > > But that's not making the point (IMO) that we should have a  
> flurry of
> > > branch names.
> >
> > True, that's an entirely orthogonal issue. I mainly raised that  
> point as
> > an example from the kernel. What I really started this conversation
> > about was not using rebases in either master or next, and the
> > conversation has started to concentrate more on other things.
> 
> However, there are times when rebasing, and reordering even, might be
> required -- think, for instance, of an important patch that should be
> placed as early as possible in the next release, or inversely, a patch
> that was put in next release and now sits in the middle of other
> commits, but reveals faulty. There would be cause to pick this commit
> out of the next tree before it becomes master.

It's a tradeoff between preserving history and preserving  
bisectability.  I wouldn't say it's ever really required except when  
there's a legal issue with carrying certain code in the history.

-Scott