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

["Shawn O. Pearce" <spearce@spearce.org>]

David Kastrup <dak@gnu.org> wrote:
> 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.