[U-Boot-Users] Revised custodian git writeup

[Jerry Van Baren <gerald.vanbaren@ge.com>]

Wolfgang Denk wrote:
> In message <87myqyx7fp.fsf@denx.de> you wrote:
>> Not doing this makes it hard to use git-request-pull to generate these
>> cute summaries in case you repeatedly update->merge-a-patch.
> 
> You're suppoed to merge it only when you're done with it - see my
> previous message: consider merging into your master branch as the
> first step of my pulling from your tree.
> 
> Best regards,
> Wolfgang Denk

...but this is a contradiction again.  Quoting from different WD emails:

> As explained before, my idea is that the custodians will merge  their
> code  into the master branch (a) for others to test it and (b) for me
> to pull from. 

> You're suppoed to merge it only when you're done with it - see my
> previous message: consider merging into your master branch as the
> first step of my pulling from your tree.

> To me, your master branch is your "stable" code. Code that needs more
> testing should use a different branch name. Especially  if  you  have
> different pots on the fire at the same time.

1) Master branch is for others to actively base from
2) Master branch is updated just before a pull request
3) No merge conflicts with the u-boot.git repo when Wolfgang pulls it

These appear to be contradictory goals.  #1 and #2 could be argued to 
not be contradictory, but I'm not buying into that theory.  The point of 
people pulling and testing is to find problem, which should be fixed 
*before* a pull request.  If the master branch has broken code in it, 
the broken patch will have to be replaced with a fixed patch (rewriting 
history - oh-oh) or the fix will have to be added as another patch (ugly 
and potentially breaking git-bisect).

I'm not sure what happens (how git handles it) if patches are applied in 
different orders.  What I'm thinking about is if custodians #1 and #2 
both issue a pull request.  Wolfgang pulls #1 and then #2.  What happens 
to #2 when he does a merge with the master u-boot.git?  Does git insert 
custodian #1 patches ahead of his existing (#2) patches, or do the 
patches end up in a different order in the repos?

Then there is the merge conflict, which will be a result of the order 
that Wolfgang pulls from the custodian repos.  How does a custodian 
resolve a merge conflict without changing his branch's history?

In my mind, custodian repos should be (must be?) faithful slaves of the 
master u-boot.git repo - always the current u-boot.git + "value added" 
(to the best of the custodian's ability to keep up with Wolfgang ;-). 
The custodian always keeps the "value added" patches at the tip of the 
tree so that they are clearly identified.

Third party developers can clone u-boot.git, create a branch and pull 
the custodian's "value added" branch (master or otherwise), and merge or 
cherry-pick the "value added" patches.  While we have not poked into the 
dark corners of this technique, Kim, Kumar, myself, and Wolfgang 
(unwittingly for Wolfgang) have done this and it has Just Worked[tm].

-------

FWIIW, my repo seems to have worked fine in this merge window.  I 
actually have two u-boot-fdt repos: a "mirror" copy I synchronize 
against git://www.denx.de/git/u-boot-fdt.git nightly and a working repo 
(with local branches).  This allows me to watch what is officially 
advertised, allows me to recover if I shit my working repo.

1) I rebased my working repo against u-boot.git, pushed my "master" 
branch to denx.de, then issued a pull request.
  * My "to pull" patches were at the tip of the tree

2) Wolfgang pulled my changes into u-boot.git

3) I did the rebase of my working repo using a "uboot" branch to pull 
the lastest u-boot.git changes and then rebasing my working repo's 
"mster" branch.  I did that just now, so it has all of everybody's changes.

4) I pushed my working repo's master branch back to denx.de - my 
custodian repo now matches the master u-boot.git repo (not verified 
bit-for-bit, but it appears to be done right).

5) I pulled git://www.denx.de/git/u-boot-fdt.git into my "mirror" copy.

All of this Just Worked[tm] with no errors.  While it could be argued 
that I rewrote history with my rebasing, I believe this is a good thing 
- all of our repos should match (at least on the master branches) and 
IMHO all of our histories should match at the point that the merge 
window closes.  Emperically, git handled this "history rewriting" with 
no (apparent) errors.

-------

I've added a link "Intro to Distributed Version Control (Illustrated)" 
to the Custodian page:
<http://betterexplained.com/articles/intro-to-distributed-version-control-illustrated/>

This is somewhat helpful, but doesn't talk about what happens to the 
custodian repositories after the patches are pulled into the master 
repository.

Best regards,
gvb
(going home to soak my brain in ethanol)