[U-Boot-Users] Revised custodian git writeup

[Wolfgang Denk]

In message <20080122105016.313d8f88 at dhcp-252-066.norway.atmel.com> you wrote:
>
> > Are you sure that is a good idea? Note that I (and probably others)
> > will be pulling from that branch, and not only once!
> 
> That depends on whether or not you want your commit history filled with
> "merge with upstream/master" crap or not.

...which in turn depends on whether  or  not  you  consider  a  merge
commit as crap or not. IMHO it's sometimes valuable information about
the history of a project, but YMMV.


My point is a different one, and it seems I never explicitly stated it
before:

My idea of a custodian repository is that it  is  more  than  just  a
working  tool  for  collecting  patches and preparing these for merge
into  mainline.  My  idea  is  instea  that  these  are  pretty  much
independent  incarnations  of  U-Boot source trees which users (note:
users, not only developers) with  specific  needs  or  interests  can
refer to.

For example, in my set of mind somebody interested in the latest 85xx
code would clone the 85xx custodian  repository,  expecting  that  he
finds  there  the  most  current  code for this family of processors.
Probably he will never sync himself  against  mainline,  but  instead
continue update (pull) from the 85xx custodian repository.

That means, that my idea is that it is the custodian's responsibility
to  provide  a  permanently  accessable,  consistent  view   of   his
repository  to  users.  When  he  collects  patches,  he will - after
sufficient review and testing - decide that these are good enough  to
go  into  his  repository. And at certain points we will pull all the
stuff that has been collected there into mainline.

> You should only pull when explicitly requested to do so. In that case,

Actually I fetch from all custodian repos quite frequently. But I do
only pull (merge into mainline) when I'm explicitely told.

But note that my idea  is  that  other  users  may  have  cloned  the
custodian  repository,  and  continue  to  pull  from  it.  For their
convenience (and my own) I want to have the current code collected in
the master branch, and I think we agree that the master  branch  must
not be rebased.

> If there are conflicting changes and the merge needs manual
> intervention, you abort the merge and tell the one sending the pull
> request that it didn't merge cleanly, please rebase.

Right - but this does not depend on how the custodian repos are set up
or which branch I'm pulling from.

> >        way that will cause problems for anyone who already has a copy
> >                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >        of the branch in their repository and tries to pull updates
> >        ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> >        from you. You should understand the implications of using git
> >        ^^^^^^^^^
> >        rebase on a repository that you share.
> 
> And that is, IMO, exactly why you shouldn't be pulling from the master
> branch in the first place. People who pull regularly to test stuff that
> is in progress will run into this problem, and they are most likely to
> pull the master branch because that's the default.

People pulling the master branch have (IMHO) the right  to  expect  a
consisten  history.  It is the custodians responsibility not to merge
stuff into the master branch that causes conflicts.

> There are two different kinds of users involved here: You (and other
> maintainers that are "upstream" from someone), and regular users who
> want to test stuff. Upstream maintainers should receive a clean

I don't think that we are different types of users - maybe  from  the
kind  of  work  we  do,  but  I  don't  see  why we should access the
custodian's repository differently. Actually I think  it's  a  pretty
good idea if others test the very same code I will be pulling later.

> history, i.e. from a branch that is frequently rebased. At the same

I think only "small" topic branches should be rebased - this  is  the
part of the custodian's work that is needed to clean up the stuff and
to  make it ready for mainline merge. The he prepares a branch for me
and ofr other users to pull from.

> time, we should avoid exposing testers to the problems of dealing with
> a branch that is rebased all the time.

ACK.

> So we need (at least) two different branches that are maintained in
> different ways, and I think it's easier to tell you, Wolfgang and other
> upstream maintainers, to pull from a non-master branch than to tell
> everyone else in the world.

I still fail to see why separate branches would be  needed.  I  think
using  the  same  one  makes more sense, as it allows me to pull from
tested code.

Best regards,

Wolfgang Denk

-- 
DENX Software Engineering GmbH,     MD: Wolfgang Denk & Detlev Zundel
HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany
Phone: (+49)-8142-66989-10 Fax: (+49)-8142-66989-80 Email: wd at denx.de
God may be subtle, but He isn't plain mean.         - Albert Einstein