[U-Boot] U-Boot git usage model

[Tom Rini]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On 10/11/12 10:16, Scott Wood wrote:
> On 10/11/2012 11:38:00 AM, Tom Rini wrote:
>> On Tue, Oct 09, 2012 at 02:32:08PM -0700, Tom Rini wrote:
>>> On Tue, Oct 09, 2012 at 03:03:28PM -0600, Stephen Warren 
>>> wrote:
>> [snip]
>>>> The problem with rebasing when pulling is that git commit
>>>> IDs change, so it's much more difficult to determine when a 
>>>> commit is merged into a parent tree; one has to search by 
>>>> commit subject rather than just executing e.g. git branch -a 
>>>> --contains XXX. I thought Albert just agreed to use merges 
>>>> rather than rebases for u-boot-arm for this and perhaps
>>>> other reasons.
>>> 
>>> The short answer is that right now, u-boot/next follows the 
>>> linux-next model and we rebase as needed.
>> 
>> I'm going to reply to myself, in hopes of clearing things up.
>> We don't follow the linux-next model, really, I miss-spoke.
>> 
>> History is important.  But so is getting the amount of process 
>> for the size of the project.  The other thing is that we're
>> doing simultaneous development for both the current release and
>> the next release.
>> 
>> So for the master branch of the master repo, it must never 
>> rebase.  And as Wolfgang encourages users to use the custodian 
>> repository of mainline isn't quite up to what they need, 
>> custodian repositories must also keep their master branch 
>> un-rebased as much as humanly possible (my rule of thumb would
>> be once it's been in the wild for a few days, it's too late).
>> 
>> The next branch however can be rebased, as needed.
> 
> Why is the next branch any different?  Users and custodians will 
> both be affected by any rebase, just as if a master branch gets 
> rebased.  This hybrid of the Linux approach and what was described 
> in this thread as the U-Boot approach is worse than consistently 
> doing one or the other IMHO.

The number of people working on next should be small and manageable.
But, yes, it bears more thinking if we want the next branch open for
longer than it has historically been, if we want that.  And we have at
least historically been saying that next can and will be rebased.

>> In the case of post-v2012.10, it will be rebased as we want the 
>> commit to change how ARM and unaligned accesses are handled to
>> be the first thing.
> 
> Any particular reason, short of telling people whose patches have 
> already been accepted that they need to respin them?

That is the primary reason, yes.  U-Boot doesn't, I feel, have the
clout that the kernel does to tell people to keep re-basing their work
until the window in master is open.

>> I don't think "perfect" "changes A-G were done in repository X 
>> against tree Y" is the most useful bit of information.  When we 
>> rebase we may lose that boards 1/2/3 worked at point Y but we 
>> gain change D is when board 2 broke as part of being merged with 
>> other changes.
> 
> I don't follow.

It's a little bit me ranting.  I'm trying to bisect a problem in the
kernel right now and I swear I must be doing something wrong, or the
merge commits just aren't helping me.

- -- 
Tom
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://www.enigmail.net/

iQIcBAEBAgAGBQJQdwGdAAoJENk4IS6UOR1Wlr0P/2EYAeeEgGxW50Nltgx2XLC3
EcHEg+IguY1PAuvjvN8FZnV4GsUGhYhGXW3TzQdVwXjyYXxYJJbDYsP2G+8dyMzs
IU4KzP3AcyNv6VuU5abJpuIagDoUtkcHKvFh+7UMRQIdQXfaDrztvf3PsGITH0pQ
QNeKFfwGkz7Gn7sUrnms6zXOA9JNPbyInG5R4C6nAY2SlKiNjd49TpvAfgPMhKzi
BJMPjStK4lMxgURJtbqYGDzZQehYY0xvW+36dw36POYINbGLV1hLxVaCyK9tffKq
YLw532a+utnygkHnsUAhH02QIzz1nQholjWoWwG2gpNlIPiAQuYHfMjwUmGpujvK
Rnql4Vm9ecgcrWV5aR5+L8QpIhF7TrqTPKK05chDGDwbTOhTPfdVwDWqnzyMfnoQ
CHjs5pmSgDviEH5uT+azdBlve/iuJlc4dcFzonNsLi7Q19ELS2i6lTbZdkuW7v9r
jNOv+qnObVfb8hGEhQWOZmLMesMio7YL5SySp+W7VFXbzZt2PSmiC3Tjjz1xdTKe
p06BhachZlZ+tEG3L+cULuYeKdOMFCjelB4xsGfZa/afPYOBQsf6nj/vyPTTsO+w
DAjUoE99df9/Uo++xWx8ZmBFbx0QTd7UMITE9IcTXpTbF4flEb+dKQ6JtCkLcngO
GjqJsPeqBjguozwGUIyH
=siLe
-----END PGP SIGNATURE-----