In message 4796726E.9030501@ge.com you wrote:
- Master branch is for others to actively base from
others = mostly users aka non-developers
- Master branch is updated just before a pull request
not necessarily only then, but updates should contain code that is considered to be "good" from the custodian's point of view
- No merge conflicts with the u-boot.git repo when Wolfgang pulls it
Ideally, yes.
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,
Agreed. Please see previous messages. My idea is that the maste rbranch can be consider as kind of a "stable" branch - it is ahead compared to the main repo in regards to the the custodian's special topic, but considered stable. For testing, other branches should be used (probably with an explicit "-testing" in their name).
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
git has no notation of order or sequence. It is storing content only. If you apply N independent, non-overlapping patches in arbitray order, the result will be the same. The individual commits will have different ID's, but who cares?
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?
It doesn't matter as long as there are no conflicts.
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?
That's a good point. I have to think about that one...
(going home to soak my brain in ethanol)
The brain or the liver?
Best regards,
Wolfgang Denk