[U-Boot] ARM Workflow: rebase on ARM repositories
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. 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 ?
Regards, Stefano
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?
Thanks, Stefan
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
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,
Dear Albert,
In message 20120903200244.2ddad7d4@lilith you wrote:
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?
Yes, and this is the same.
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.
I seriously dislike this for the master branch.
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.
Define "official". Wepublicly announce the existence of ht ecustodian repositories, and in many cases when you need current code the way to the custodian repo is the most direct one.
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).
But merging keeps all the history in place, i. e. you can always refer to any specific "old" commit ID, and be sure that it is what you really refer to because it is secured by cryptographically strong checksums.
By rebasing, you lose all this history. Even if you manage to find a commit that "looks" the same judging from the commit message etc., you have no guarantee that it's really the same code.
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.
Please feel free to do this in working branches. But I would really appreciate it if we could stop rebasing any "master" branches.
OTOH, we all can see Wolfgang sometimes performing pulls by merging, so he might have a different view on this.
Not sometimes. I _always_ use "git pull".
Best regards,
Wolfgang Denk
Hi Wolfgang,
On Mon, 03 Sep 2012 21:13:28 +0200, Wolfgang Denk wd@denx.de wrote:
Dear Albert,
In message 20120903200244.2ddad7d4@lilith you wrote:
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?
Yes, and this is the same.
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.
I seriously dislike this for the master branch.
Stefano's reference was about u-boot-arm specifically, and so was my comment to it. I do agree with you re: the U-Boot master branch (see below for additional notes)
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.
Define "official". Wepublicly announce the existence of ht ecustodian repositories, and in many cases when you need current code the way to the custodian repo is the most direct one.
I consider the official U-Boot to be the one which is used for releases, and bears labels denoting these. I do not consider official the architecture trees because -- as per the current rules -- their custodian may rebase them before a pull request, thus cause the very trouble Stefano is talking about.
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).
But merging keeps all the history in place, i. e. you can always refer to any specific "old" commit ID, and be sure that it is what you really refer to because it is secured by cryptographically strong checksums.
By rebasing, you lose all this history. Even if you manage to find a commit that "looks" the same judging from the commit message etc., you have no guarantee that it's really the same code.
Correct.
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.
Please feel free to do this in working branches. But I would really appreciate it if we could stop rebasing any "master" branches.
I'll be fine either way. Just note that this policy is at odds with the documentation at http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees which suggests rebasing, not merging, masters; the doc should be changed to match the policy.
OTOH, we all can see Wolfgang sometimes performing pulls by merging, so he might have a different view on this.
Not sometimes. I _always_ use "git pull".
I guess the occasions where I did not see a merge was when it was trivialized into a fast-forward, then.
Best regards,
Wolfgang Denk
Amicalement,
Dear Albert,
In message 20120903214729.4f3949e7@lilith you wrote:
I seriously dislike this for the master branch.
Stefano's reference was about u-boot-arm specifically, and so was my comment to it. I do agree with you re: the U-Boot master branch (see below for additional notes)
You misunderstand me. I was referring to the "master" branch of the "u-boot-arm" repository. This, like all "master" brnaches in all custodian repositories, should _never_ get rebased.
I consider the official U-Boot to be the one which is used for releases, and bears labels denoting these. I do not consider official the architecture trees because -- as per the current rules -- their custodian may rebase them before a pull request, thus cause the very trouble Stefano is talking about.
We're discussing to change the current rules, as they make no sense to me, and to a few others. And a number of users have been bitten by these.
I repeat: rebasing is of for any working branches. But the master branches in any of the custodian repos should not get rebased.
I'll be fine either way. Just note that this policy is at odds with the documentation at http://www.denx.de/wiki/view/U-Boot/CustodianGitTrees which suggests rebasing, not merging, masters; the doc should be changed to match the policy.
Definitely.
Not sometimes. I _always_ use "git pull".
I guess the occasions where I did not see a merge was when it was trivialized into a fast-forward, then.
Correct.
Best regards,
Wolfgang Denk
Am 03/09/2012 20:02, schrieb Albert ARIBAUD:
Hi Stefano,
Hi Albert,
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?
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?
I have not found this issue myself - Detlev discovers that in the documentation for the bootloader (I think inside the SDK that can be download following the link in that page) there is an a reference to a commit-id in u-boot-arm.
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.
This is a point - I have also considered that the architecture trees are unofficial, and users should clone their tree from Wolfgang's tree.
Nevertheless, all these tree are published, and nobody says that they cannot be used. And they look like as the architecture trees for linux (linux-omap, linux-imx,...). They also are not rebased and it is not unusual to get the last status for an architecture from one of these trees.
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; :)
Right, this is true.
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).
To extend this with the behavior in Linux, this is the link of Jonathan Corbet's article on lvm:
http://lwn.net/Articles/328436/
So there are in both cases advantages and drawbacks - the issue is which is the more suitable for our project. I tend to avoid rebasing due to the fact that I should not consider u-boot-imx my private and hidden branch, but a public repository.
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.
Of course ;-)
Regards, Stefano
Hi Stefano,
On Tue, 04 Sep 2012 11:37:52 +0200, Stefano Babic sbabic@denx.de wrote:
OTOH, we all can see Wolfgang sometimes performing pulls by merging, so he might have a different view on this.
Of course ;-)
And so he has expressed, before your reply actually, and clearly expressed a preference for merging rather than rebasing.
Next step - considering I've been the only one apparently to express adissenting opinion - is thus to change the Denx Wiki documentation about custodian trees so that it matches our policy.
Regards, Stefano
Amicalement,
On 09/04/2012 03:37 AM, Stefano Babic wrote:
Am 03/09/2012 20:02, schrieb Albert ARIBAUD:
Hi Stefano,
Hi Albert,
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?
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?
I have not found this issue myself - Detlev discovers that in the documentation for the bootloader (I think inside the SDK that can be download following the link in that page) there is an a reference to a commit-id in u-boot-arm.
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.
This is a point - I have also considered that the architecture trees are unofficial, and users should clone their tree from Wolfgang's tree.
Nevertheless, all these tree are published, and nobody says that they cannot be used. And they look like as the architecture trees for linux (linux-omap, linux-imx,...). They also are not rebased and it is not unusual to get the last status for an architecture from one of these trees.
We have this issue on Tegra a lot too; Tegra is pretty new, and so anyone running U-Boot on Tegra typically uses the Tegra repo, not even the ARM repo.
If we're voting, I personally fully support a move to a pure merge-based workflow (although note that I'm not a maintainer of any part of U-Boot, just a contributor to many Tegra boards).
Dear Stefano,
In message 5044A44F.2050204@denx.de you wrote:
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.
Thanks for bringing up this topic.
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.
I think it is wrong to rebase any tree for which it is not very clearly and lodly announced that this tree gets rebased on a more or less regular base. linux-next is such an example - we allknow it gets rebased frequently, so we can arrange with it (though I have to admit that I dn't like it, and that I've been bitten myself more than once by this).
For u-boot-*, most users I know are not aware of any rebasing policy.
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.
I would prefer to have at least rebase-free "master" branches in all custodian repositories. It is perfectly OK to have working branches, and to rebase these as work progresses. But for the master branches, a rebase should be more or less tabu.
Best regards,
Wolfgang Denk
participants (5)
-
Albert ARIBAUD -
Stefan Roese -
Stefano Babic -
Stephen Warren -
Wolfgang Denk