Hi, On Thu, 26 Jul 2007, Shawn O. Pearce wrote: > [talk about the --unidiff-zero stuff] > > 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. Heh. I did my share of Tcl hacking. In one (closed source) project, I was in constant awe why the devs chose Tcl as a scripting language, but Qt as windowing library (back when it was pretty expensive for a startup to use Qt). > 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. See below. > 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). But you're right, the other hunk headers should be updated. I'll have a look at it this weekend. > 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. Okay, but just using more context means that you also have to _update_ the context of another hunk. Imagine this: --- a/x +++ a/x one line -a removed one +an added one another line Now you split between the "-" and "+" line. If you stage the first hunk, not only do you have to update the hunk header of the second hunk (now the only one shown), which you already hinted should be done; you _also_ have to update the context in the second hunk, since it changed. This is just tricky enough that I am tempted to have a go at it. Not today, though, since I have other work to do, and the issues are easier to work around for the moment than to work around the lack of "Split Hunk" for me. BTW did you think about any kind of integrity checking, i.e. see if the files involved still have the same hashes as when the diff was generated? It _is_ possible to use git-gui _and_ the command line... Ciao, Dscho - 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
