Re: RFC: Patch editing

From: Johannes Schindelin <johannes.schindelin@gmx.de>
Date: Feb 27, 2007, 11:54 UTC
Message-ID: <Pine.LNX.4.63.0702271247000.22628@wbgn013.biozentrum.uni-wuerzburg.de>
In-Reply-To: <Pine.LNX.4.64.0702270205540.6485@iabervon.org>

Hi,

On Tue, 27 Feb 2007, Daniel Barkalow wrote:

> For much the same reason, I wrote a script that entirely ignores the 
> intermediate commits in a throw-away head, and lets you trim down the 
> diff between the mainline and your head, and arrange it into a new patch 
> series.

It looks to me like you just start a new branch, get the state of an existing commit *1*, and then "git add -i" your way through that diff.

This is slightly different from my work flow:

- I can have overlapping changes (i.e. one commit fixes something which 
  gets refactored in the next), and

- I try not to touch the code when editing the patch series. Only in the 
  conflicting case, I _have_ to edit it.

The latter means, of course, that the commits in the throwaway branch _must_ be a superset of the commits I want to have in the cleaned up branch. (Meaning that I never commit two unrelated things with the same commit.)

To achieve that, I use my own version of "git add -i" quite often while composing the throwaway branch. For example, when I found a bug with an easy fix, in the middle of something different, and the fix touches a file that is already changed, I only commit the appropriate hunks of that file.

Ciao, Dscho

*1* It is not really as easy as "git diff ..other-branch | git apply", since you would lose valuable information about added files, so you have to be very careful there.