On 03/09/2012 15:13, Stefan Roese wrote: > Hi Stefano, > > On 09/03/2012 02:36 PM, Stefano Babic wrote: >> I was thinking about the way we are usual to manage our trees. This >> comes because I know about issues from users who set their development >> on ARM-repositories. >> >> One of them uses u-boot-imx for his development, and of course after I >> rebased my tree he got into trouble, due to using a commit that does not >> exist anymore. >> Nevertheless there are boards, where the official documentation explain >> how to set patches on bases of u-boot-arm. For example, >> >> http://www.ti.com/tool/tmdsevm3530 >> >> Detlev discovers that the official documentation refers directly to >> commit cf6ec699a6dc21a538b039a0392cd38132072090 in u-boot-arm. After a >> rebase this commit does not exist anymore. >> >> Of course, we can really say that setting a development on a ARM >> repository instead of main repository is not the best ;-). But we know >> that sometimes setting on a partial repository is the best because some >> patches that are strictly required are already merged. And I do not know >> if we can say that our trees are "private" or "development" only: they >> are published, and available for everybody. >> >> Albert has described the way we are currently using in >> http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees. I think you konow >> very well and it is the way we follow, and we usually rebase our tree >> after u-boot-arm is merged by Wolgang in mainline. I want to discuss >> here if we really need it and if this is the correct way to do. >> >> In Linux, every maintainer makes a "git pull" from Linus' tree. Nobody >> rebases, and I had never had the problem that my tree diverges when I >> update my kernel's trees from a mainatiner tree. However, this happens >> continuosly for the users of u-boot-imx. The way we are following can >> be seen in the linux-next trees, not in the main trees. >> >> The worst thing I think is that we lose the history of our tree, and the >> behavior can be different. Rebased patches can be different, and testing >> done until the rebase can be worthless and should be (theoretically) >> done again. Testers can say they have successfully test a patch, but it >> was on a pre-rebased tree. A tested-by in a rebased tree can be worthless. >> >> My big question is if we should not to come back using "git pull" to >> downstream mainline from Wolfgang's tree, instead of continuos rebase. I >> know that we switched to rebase to avoid a lot of "git merge commits", >> but maybe this is not so bad as rebasing. >> >> What is your opinion ? > > I'm quite astonished about this rebasing you mention here. I'm not an > RAM custodian, so thats probably why I was not aware of it. But I do > manage 3 U-Boot custodian repositories (non-ARM). And I can't remember > that I had to rebase my custodian repositories ever. My workflow is the > one you describe with "git pull" based on Wolfgangs mainline tree. And > this definitely should be preferred over rebasing. > > Aren't those merge problems solvable without rebasing in the ARM trees?
This is what is done in Linux - I wonder that we do differently. Cheers, Stefano -- ===================================================================== DENX Software Engineering GmbH, MD: Wolfgang Denk & Detlev Zundel HRB 165235 Munich, Office: Kirchenstr.5, D-82194 Groebenzell, Germany Phone: +49-8142-66989-53 Fax: +49-8142-66989-80 Email: sba...@denx.de ===================================================================== _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
