[U-Boot-Users] Please pull u-boot-mpc83xx.git mpc83xx branch

[Jerry Van Baren]

Jerry Van Baren wrote:
> Wolfgang Denk wrote:
>> In message <20070817093906.05cca34d.kim.phillips at freescale.com> you wrote:
>>> Wolfgang, please do a (and you can cut-n-paste this):
>>>
>>> git-pull git://www.denx.de/git/u-boot-mpc83xx.git mpc83xx
>> Done.
>>
>>
>>> [note the mpc83xx branch]
>> May I please ask that you use branches for other stuff, and allow me
>> to merge from the "trunk"? Thanks.
> 
> Hi Wolfgang and The List,
> 
> In the u-boot-fdt repo, I've been using the "fdt" branch for "ready to 
> merge" patches and have advocated standardizing on a "merge" branch for 
> "ready to merge" patches in the TWiki (as well as a "testing" branch for 
> "merge candidate" patches).
> <http://www.denx.de/wiki/view/UBoot/CustodianGitTrees#Tips_for_maintaining_custodian_t>
> 
> Based on your request above, it would appear that we have not convinced 
> you that pulling from a branch is a Good Thing[tm].  If that is the 
> case, the alternate technique I would advocate would be...
> 
> * Maintain the "ready to merge" patches in the master branch (per your 
> request).
> 
> * Track the main u-boot repository via a branch "u-boot" (picking a name 
> arbitrarily)
> 
> This would still allow the rebasing by doing a periodic pull of the 
> master repo into the "u-boot" branch and then rebasing the "master" on 
> the "u-boot" branch.  I have not tried this, but I don't see any reason 
> why it would not work.
> 
> The "u-boot" branch would not need to be pushed back to the denx.de 
> repository, so it would cut down the number of published branches by one 
> (generally a 100% reduction ;-).  I would still advocate using 
> work-in-progress (e.g. "testing") branch(es) that are pushed back to 
> denx.de as the need arises.  I have not felt a need myself, but I can 
> see a place for it for patches that introduce major changes that may 
> take time to mature.
> 
> Trivia:
> -------
> One of the reasons I've advocated using a branch to pull from is because 
> linux does it this way, although their methodology and organization of 
> their repositories is somewhat different.  They generally create a 
> special branch for Linus to pull from (a quick search on gmane.org shows 
> "for-linus", "release", "merge", "upstream-linus", "upstream",... so 
> there isn't much consistency there to model our methodology after).
> 
> An argument for using the "master" branch is that outstanding patches 
> are easier to find and view via gitweb.  Figuring out where to click to 
> view a branch is not obvious, it requires scrolling down to the bottom 
> of the page.  We've had that issue on the email list and I have to 
> sympathize because it threw me for a minute myself the first time I 
> tried to see changes that were in a branch.
> 
> What is the wisdom of the crowd[1]?
> 
> Best regards,
> gvb

Sorry for talking to myself, but the Koha project just announced they 
switched to git and have a very nice writeup on their methodology.  A 
quick read makes me think their methodology and writeup is very close to 
what we either already are or should be doing.  Koha's "QA Repo" and 
"Release Managers Repo" don't exist in our methodology and the 
"Liblime", "Paul", etc. repos are our custodian repos.

They do the master repo tracking in the "origin" branch, which is 
something I should have considered before penning my diatribe (above).

<http://wiki.koha.org/doku.php?id=en:development:git_usage>

Best regards,
gvb