David Kastrup <dak@xxxxxxx> wrote: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> 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. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
