From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Achim Gratz Newsgroups: gmane.emacs.devel Subject: Re: dealing with local patches - mercurial queues over bzr/git checkout Date: Mon, 06 Jan 2014 22:51:47 +0100 Organization: Linux Private Site Message-ID: <87vbxw93t8.fsf@Rainer.invalid> References: <1389035494635-308685.post@n5.nabble.com> <83r48ksys4.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: ger.gmane.org 1389045132 10044 80.91.229.3 (6 Jan 2014 21:52:12 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 6 Jan 2014 21:52:12 +0000 (UTC) To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Jan 06 22:52:19 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 1W0I5q-0005LH-79 for ged-emacs-devel@m.gmane.org; Mon, 06 Jan 2014 22:52:18 +0100 Original-Received: from localhost ([::1]:37742 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0I5p-0006M8-U6 for ged-emacs-devel@m.gmane.org; Mon, 06 Jan 2014 16:52:17 -0500 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49538) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0I5g-0006LN-R9 for emacs-devel@gnu.org; Mon, 06 Jan 2014 16:52:15 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1W0I5a-00063x-LU for emacs-devel@gnu.org; Mon, 06 Jan 2014 16:52:08 -0500 Original-Received: from plane.gmane.org ([80.91.229.3]:57170) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1W0I5a-00063s-EP for emacs-devel@gnu.org; Mon, 06 Jan 2014 16:52:02 -0500 Original-Received: from list by plane.gmane.org with local (Exim 4.69) (envelope-from ) id 1W0I5Z-0004hx-4b for emacs-devel@gnu.org; Mon, 06 Jan 2014 22:52:01 +0100 Original-Received: from pd9eb309c.dip0.t-ipconnect.de ([217.235.48.156]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Jan 2014 22:52:01 +0100 Original-Received: from Stromeko by pd9eb309c.dip0.t-ipconnect.de with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 06 Jan 2014 22:52:01 +0100 X-Injected-Via-Gmane: http://gmane.org/ Original-Lines: 32 Original-X-Complaints-To: usenet@ger.gmane.org X-Gmane-NNTP-Posting-Host: pd9eb309c.dip0.t-ipconnect.de User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3.50 (gnu/linux) Cancel-Lock: sha1:ng9vdye5QDFhRrifqX78WrWSS3Q= 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:167530 Archived-At: Eli Zaretskii writes: > But then you lose history of each patch, I presume: each patch appears > as a single flat changeset with no history. When I work on a > non-trivial feature in a local branch, I make lots of small commits, > each one implementing a small sub-feature or a part thereof, usually > after testing the part that was added. This history is useful later, > when the whole series is merged to mainline, because if there's a > regression, bisecting a series of small commits is easier than a > single large commit. I find that in Git simply rebasing the local branch on top of upstream (which can be configured to be done instead of a merge when you "pull") keeps that history inside the local branch intact while producing a nice linear history when you finally push it upstream (with or without rewriting it before the push), without the messiness of many superfluous merges. If you have lots of changes that create merge conflicts, you'll want to find a way to (almost) automatically deal with them, but you'd have the same problem with actual merges. It's a slightly different workflow than what you will find in most tutorials, but I feel it actually works better than patch stacks (I've also tried stgit and topgit and concluded they would perhaps be useful or even preferrable in other situations, but not for this). Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Waldorf MIDI Implementation & additional documentation: http://Synth.Stromeko.net/Downloads.html#WaldorfDocs