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,