[U-Boot-Users] Revised custodian git writeup

[Jerry Van Baren]

Haavard Skinnemoen wrote:
> On Tue, 22 Jan 2008 09:55:33 +0100
> Wolfgang Denk <wd at denx.de> wrote:
> 
>> Rebasing the master branch, i. e. the one I'll be pullung from?
>>
>> 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.
> 
> You should only pull when explicitly requested to do so. In that case,
> if the branch was newly rebased, there will be a clean, linear history
> from the tip of your master branch to the tip of the one being pulled.
> 
> 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.
> 
>>        When you rebase a branch, you are changing its history in a
>>        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.
> 
> 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
> history, i.e. from a branch that is frequently rebased. At the same
> time, we should avoid exposing testers to the problems of dealing with
> a branch that is rebased all the time.

I don't see this as a big deal because my methodology (and the proper 
one, IMHO) is to create a branch in my local repo, pull the current 
state of the target repo into the branch, and then either merge or 
cherrypick the "foreign" subrepo changes into my working branch in my 
repo.  At that point, I discard the foreign repo branch because it has 
served its purpose.  Because I discard the foreign repo branch, I don't 
care of the foreign repo gets rebased and its history is rewritten, I've 
already discarded that history.

If more things change in the foreign repo, I do the same thing over, 
starting with creating a new branch.

I'm sure that is how Wolfgang pulls subrepos to - not directly, but into 
a testing branch and then, if it is OK, into the main u-boot.git repo.

Here are my Cliff Notes(R) for a real example of this interaction with 
u-boot.git and between myself and Kumar, pulling his libfdt updates into 
my u-boot-fdt.git repo:
<http://www.denx.de/wiki/view/UBoot/UBootFdtInfo#All_Your_Base_are_Belong_to_Us>

This ultimately was merged by Wolfgang into u-boot.git with no problems 
(yet ;-).

> 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.
> 
> Just my two cents.
> 
> Haavard

+ my 2c,
gvb