Hi Stefano,
On Mon, 03 Sep 2012 14:36:31 +0200, Stefano Babic sbabic@denx.de wrote:
Hi all ARM Custodians,
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.
You mean a commit ID that does not exist any more, right?
Nevertheless there are boards, where the official documentation explain how to set patches on bases of u-boot-arm. For example,
I haven't found where in the page a reference to u-boot-arm was made. Can you clarify this?
Detlev discovers that the official documentation refers directly to commit cf6ec699a6dc21a538b039a0392cd38132072090 in u-boot-arm. After a rebase this commit does not exist anymore.
That can happen indeed. I *do* hope that the commit was also described by its (invariant) commit summary.
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.
But they are not official. The official release is u-boot/master.
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.
Indeed, but so can it be when the branch is pulled rather than rebased and fast-forwarded, I believe.
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 ?
This reference;
(see the detailed answer re merging vs rebasing, and the answer to this answer) gives us two additional pieces of info:
a) we are not the only project where the opposition between merging and branching strategies is considered; :)
b) merging requires testing just like rebasing does, which is kind of evident as for a given pair of branches, both methods yield, or should yield, the same semantic semantic union of the branches).
My preference goes to rebasing rather than merging because in a rebasing strategy, each commit in the main branch is a single, understandable, purposeful change, whereas with merging, if the commit is a merge, it can be a complete set of pervasive changes which are not readily identifiable and may serve lots of purposes.
OTOH, we all can see Wolfgang sometimes performing pulls by merging, so he might have a different view on this.
Regards, Stefano
Amicalement,