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 08:36:09 +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> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1395300987 16048 80.91.229.3 (20 Mar 2014 07:36:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 20 Mar 2014 07:36:27 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Thu Mar 20 08:36:36 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 1WQXWl-0006RU-MH for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 08:36:35 +0100 Original-Received: from localhost ([::1]:45602 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQXWl-0001g9-Ac for ged-emacs-devel@m.gmane.org; Thu, 20 Mar 2014 03:36:35 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:48145) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQXWd-0001V3-IG for emacs-devel@gnu.org; Thu, 20 Mar 2014 03:36:33 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WQXWX-000610-Mo for emacs-devel@gnu.org; Thu, 20 Mar 2014 03:36:27 -0400 Original-Received: from plane.gmane.org ([80.91.229.3]:60524) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WQXWX-00060n-GC for emacs-devel@gnu.org; Thu, 20 Mar 2014 03:36:21 -0400 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1WQXWV-00063D-DG for emacs-devel@gnu.org; Thu, 20 Mar 2014 08:36:19 +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 08:36:19 +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 08:36:19 +0100 X-Injected-Via-Gmane: http://gmane.org/ Mail-Followup-To: emacs-devel@gnu.org Original-Lines: 47 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:PzwCXwijQ9wWj4gS0NGDy+E15bc= 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:170603 Archived-At: >>>>> Stefan : > Not sure why this matters: we don't cherry pick from the maintenance > branch. Instead we merge the development branch. And we sometimes > cherry pick fixes from the development branch into the maintenance > branch (which makes the subsequent merge a bit more delicate, since we > want to avoid applying that change twice). What I do, after cherry picking a fix from the master HEAD back into a release branch (named "release-branch" in the below commands) is immediately do a: git checkout master git merge --no-ff --no-commit release-branch (The latter command will apply the changes from the merge, and then stop before committing) Then I look at the changes in magit, and ideally there should be no diffs, because I have done the same thing earlier in the lifetime of the release branch, and have told git to drop irrelevant changes from the release branch. The way to tell git to drop the merge results and instead pick the version from master, is to insert the master branch's version of the file before committing, eg.: git checkout origin/master version.txt (this picks the master branch's version of the, er..., version file. "origin/master" means the version of the master branch that has been pushed to the remote git repository named "origin") name of the first branch After I am satisfied that the merge results contains no unexpected changes with master, I do a: git commit to complete the merge (or just do a `c' in magit). Whenever I am doing a bugfix, I _try_ to start a local branch in the earliest branch where the fix is relevant, and do the fix there. Then, instead of cherry picking, I can just merge the fix into the newer branches that should have the same fix. And most of the time the merge will be conflict free and correct. But I always do git commit --no-ff --no-commit in these cases, and look at the diffs resulting from the merge in magit.