Hi Wolfgang, On Mon, 03 Sep 2012 21:13:28 +0200, Wolfgang Denk <w...@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, -- Albert. _______________________________________________ U-Boot mailing list U-Boot@lists.denx.de http://lists.denx.de/mailman/listinfo/u-boot
