From mboxrd@z Thu Jan 1 00:00:00 1970 From: Albert ARIBAUD Date: Mon, 3 Sep 2012 21:47:29 +0200 Subject: [U-Boot] ARM Workflow: rebase on ARM repositories In-Reply-To: <20120903191328.71FC4203EDC@gemini.denx.de> References: <5044A44F.2050204@denx.de> <20120903200244.2ddad7d4@lilith> <20120903191328.71FC4203EDC@gemini.denx.de> Message-ID: <20120903214729.4f3949e7@lilith> List-Id: MIME-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit To: u-boot@lists.denx.de Hi Wolfgang, On Mon, 03 Sep 2012 21:13:28 +0200, Wolfgang Denk 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.