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