Re: [U-Boot-Users] Revised custodian git writeup

In message 20080122105016.313d8f88@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