From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Steinar Bang Newsgroups: gmane.emacs.devel Subject: Re: State of the repository conversion Date: Thu, 20 Mar 2014 09:07:41 +0100 Organization: Probably a good idea Message-ID: References: <20140319175124.BCCB3380835@snark.thyrsus.com> <83wqfq82ge.fsf@gnu.org> <20140319185416.GA25588@thyrsus.com> <83siqe80bj.fsf@gnu.org> <87siqdiven.fsf@uwakimon.sk.tsukuba.ac.jp> <83ior98qi4.fsf@gnu.org> <87lhw5qyx9.fsf@wanadoo.es> <87k3bp9up9.fsf@mid.deneb.enyo.de> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1395302888 3557 80.91.229.3 (20 Mar 2014 08:08:08 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 08:08:08 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 20 09:08:17 2014 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1WQY1M-0001Gq-MT for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 09:08:12 +0100 Original-Received: from localhost ([::1]:45670 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQY1M-0006ee-7Y for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 04:08:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:52093) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQY1D-0006eV-U2 for emacs-devel@gnu.org; Thu, 20 Mar 2014 04:08:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQY17-0006gK-TG for emacs-devel@gnu.org; Thu, 20 Mar 2014 04:08:03 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:54611) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQY17-0006eb-LH for emacs-devel@gnu.org; Thu, 20 Mar 2014 04:07:57 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WQY12-0000kO-Tw for emacs-devel@gnu.org; Thu, 20 Mar 2014 09:07:52 +0100 Original-Received: from cm-84.208.248.210.getinternet.no ([84.208.248.210]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Mar 2014 09:07:52 +0100 Original-Received: from sb by cm-84.208.248.210.getinternet.no with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Thu, 20 Mar 2014 09:07:52 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 68 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: cm-84.208.248.210.getinternet.no Mail-Copies-To: never User-Agent: Gnus/5.130008 (Ma Gnus v0.8) Emacs/24.3 (windows-nt) Cancel-Lock: sha1:pziuco95Bq5cHd7GznaDaVydloY= X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 80.91.229.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:170607 Archived-At: >>>>> Florian Weimer : > This complicates the history of the master branch. It is not clear if > it adds any useful information, It makes later merges more likely to only contain the relevant changes. And the merge happens at a time where I can remember what was done and what the changes should be. That is useful information the way I see it. > especially if there is no expectation of ever doing development on > release branches and merge this development back to the master branch > later. Like I said, the pattern that works well for me, and gives a nice history on the file level, and the "git blame" level, is to do the fix on the earliest release branch were it is relevant, and then merge it forward. But that requires that the master is kept in sync with cherry picks applied to the release branches. If it isn't, the merge results can be strange, and it can be challenging to see what has happened (not impossible, and as long as nothing is committed or pushed, recovery is easy). > Tool support is generally better if you make the change in the oldest > supported release branch and merge that forward, but in practice, this > doesn't work that well. Often, you don't know for sure what the > oldest release branch that needs the change is. True. So one always end up with some cherry picks. > And from a general engineering point of view, it is better to develop > the best fix possible on the master branch, test it, and then start > backporting it, taking shortcuts as necessary. Er... no. It's not possible to generalize like that. For one particular fix this may have been the right approach. For another it may not. Basically, the way important release fixes have come to me, they have been reported as bugs against the released version, and then I naturally start with the release branch for that version, and figure out the problem, and do the fix. Once that fix is complete and pushed (released as a patch, or as a new version or whatever, and sent to the customer), I look at if the fix is relevant in master and later releases. If the code has changed little enough that a merge seems to be possible, I merge the older release branches forward. In many fixes, this is the case. If the code has changed so much that a merge isn't possible I try to figure out if the bug is still present in the master branch, and if it is, how to best fix it (it may be a completely different fix to what was done in the release branch). > If you do it in the other order, you tend to end up with a suboptimal > change in the master branch. Only if you merge blindly and assume that the fix will be correct for all versions. > And the development history becomes really, really complicated, too. In what way? Could you be specific?