From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (majordomo@vger.kernel.org) by vger.kernel.org via listexpand id S932232AbWAJPcB (ORCPT ); Tue, 10 Jan 2006 10:32:01 -0500 Received: (majordomo@vger.kernel.org) by vger.kernel.org id S932229AbWAJPcB (ORCPT ); Tue, 10 Jan 2006 10:32:01 -0500 Received: from cam-admin0.cambridge.arm.com ([193.131.176.58]:44699 "EHLO cam-admin0.cambridge.arm.com") by vger.kernel.org with ESMTP id S932187AbWAJPb7 (ORCPT ); Tue, 10 Jan 2006 10:31:59 -0500 To: len.brown@intel.com Cc: torvalds@osdl.org, linux-acpi@vger.kernel.org, linux-kernel@vger.kernel.org, akpm@osdl.org, git@vger.kernel.org Date: Sun, 08 Jan 2006 00:16:51 -0800 (PST) Subject: Re: git pull on Linux/ACPI release tree References: From: Catalin Marinas In-Reply-To: (Len Brown's message of "Sun, 8 Jan 2006 02:47:30 -0500") Message-ID: User-Agent: Gnus/5.1007 (Gnus v5.10.7) Emacs/21.4 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-OriginalArrivalTime: 10 Jan 2006 15:31:31.0996 (UTC) FILETIME=[EEDAC5C0:01C615FA] Sender: linux-kernel-owner@vger.kernel.org X-Mailing-List: linux-kernel@vger.kernel.org "Brown, Len" wrote: >>I _really_ wish you wouldn't have those automatic merges. >> >>Why do you do them? They add nothing but ugly and unnecessary >>history, and in this pull, I think almost exactly half of the >>commits were just these empty merges. > > Is it possible for it git, like bk, to simply ignore merge commits > in its summary output? As Junio suggested, you can have a look at StGIT (http://www.procode.org/stgit/) for a different workflow. There is a tutorial both on the web and in the doc/ directory but, anyway, it is pretty similar to Quilt only that the patches are GIT commits. In principle, you keep all the patches in a stack whose base is the HEAD of Linus' kernel. You can indefinitely modify/push/pop the patches and, once you are happy with the state of the stack, ask Linus to pull using standard GIT commands (or mail them with 'stg mail'). You can afterwards pull the latest changes from Linus using 'stg pull'. This operation pops the patches you have, advances the base of the stack (so no "merge" message) and pushes your patches back. Since pushing is done with a three-way merge, it detects whether there are any upstream modifications to your patches (if not, all the patches should become empty and safely removed from the stack). You can also have a branch for upstream merges only and you can easily cherry-pick patches or commits from other branches. This is quite useful if you want to continue the work on your development branch until Linus merges your patches. -- Catalin