Re: [PATCH] Teach git-gui to split hunks

From: Shawn O. Pearce <spearce@spearce.org>
Date: Jul 26, 2007, 07:07 UTC
Message-ID: <20070726070744.GD18114@spearce.org>
In-Reply-To: <85ir8790lj.fsf@lola.goethe.zz>

David Kastrup <dak@gnu.org> wrote:

Show 16 quoted lines

> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> 
> > When you select the context menu item "Split Hunk" in the diff area,
> > git-gui will now split the current hunk so that a new hunk starts at
> > the current position.
> >
> > For this to work, apply has to be called with --unidiff-zero, since
> > the new hunks can start or stop with a "-" or "+" line.
> 
> Unless one splits right at the beginning or end of an existing hunk,
> wouldn't there be context which one could use?  Or does it confuse
> patch when adjacent hunks have overlapping contexts?  At least if the
> first hunk patches what is to be used as context in the second hunk, I
> could imagine this.  And there is really no danger of losing synch in
> this situation, anyhow.  So it would be more of a convenience thing
> than anything else to be able to omit --unidiff-zero.

Yea, there's context there. Junio and I talked about this patch on #git a few minutes ago. I really appreciate that Dscho wrote it, especially given that he hasn't really been into Tcl hacking for Git much before. But I'd really like to save/create context, like `git add -i` does, so that we don't have to use --unidiff-zero here.

It won't matter if git-apply rejected overlapping context in this case. git-gui will only ever feed one hunk at a time to git-apply. And if things get really f'd in the diff buffer the user can easily regenerate it (right click, Refresh).

Right now git-gui's apply doesn't correctly update the other hunk headers when you apply a hunk. I've seen git-apply fail on some hunks just for this reason. Refreshing the diff (so git recomputes the headers) works around the issue. So I'm a little worried about using --unidiff-zero here.

-- 
Shawn.