threads / discuss / 15443

git-gui: more issues with diff parsing

Subject: git-gui: more issues with diff parsing

## tl;dr

4 messages between Sep 9, 2008 and Sep 12, 2008.

replies: 3people: 4as markdown or json

Michele Ballabio· Sep 9, 2008, 08:30 UTC · lore
The patch
	git-gui: Fix diff parsing for lines starting with "--" or "++"
seems to have introduced some glitches. With this sequence:

git init touch g git add g git commit -m"g is a file" rm g echo "vvvv" > file ln -s file g git add g file git gui

Now clicking on "g" in the staged changes, git-gui gives this line:
	error: Unhandled 2 way diff marker: {d}

The following patch seems to fix this particular issue, but I don't think it's the right fix...

diff --git a/lib/diff.tcl b/lib/diff.tcl
index a30c80a..0dac732 100644
--- a/lib/diff.tcl
+++ b/lib/diff.tcl
@@ -345,6 +345,8 @@ proc read_diff {fd scroll_pos} {
 				set tags {}
 			}
 			}
+		} elseif [string match {diff --git *} $line] {
+			continue
 		} else {
 			set op [string index $line 0]
 			switch -- $op {
Shawn O. Pearce· Sep 12, 2008, 15:23 UTC · re: Michele Ballabio · lore

Re: git-gui: more issues with diff parsing

Michele Ballabio <barra_cuda@katamail.com> wrote:
> The patch
> 	git-gui: Fix diff parsing for lines starting with "--" or "++"
> seems to have introduced some glitches. With this sequence:
Oy.
 
Show 12 quoted lines
> git init
> touch g
> git add g
> git commit -m"g is a file"
> rm g
> echo "vvvv" > file
> ln -s file g
> git add g file
> git gui
> 
> Now clicking on "g" in the staged changes, git-gui gives this line:
> 	error: Unhandled 2 way diff marker: {d}
The diff is weird:
  $ git-diff-index --cached -p --no-color -U5 d6e02aa06c91c711d98ae06e6e69c5de5841a5e5 -- g
  diff --git a/g b/g
  deleted file mode 100644
  index e69de29..1a010b1
  diff --git a/g b/g
  new file mode 120000
  index e69de29..1a010b1
  --- /dev/null
  +++ b/g
  @@ -0,0 +1 @@
  +file
  \ No newline at end of file

Notice how we get two diffs for the same file? That's why git-gui is choking on this particular change. It expected only one diff for the path it gave to Git. It got two back. In cases like this we may not be able to support line or hunk application as the patch is really two different patches against that path. :-|

> The following patch seems to fix this particular issue, but I don't think
> it's the right fix...

I don't think that is the right fix, but the one that I just tried to write to do clear_diff when we see the second diff --git line didn't work either. Plus we probably need to disable the hunk apply code.

I'll look at it again when I can get more time.
-- 
Shawn.
Junio C Hamano· Sep 12, 2008, 17:06 UTC · re: Shawn O. Pearce · lore

Re: git-gui: more issues with diff parsing

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 12 quoted lines
> Notice how we get two diffs for the same file?  That's why git-gui
> is choking on this particular change.  It expected only one diff
> for the path it gave to Git.  It got two back.  In cases like this
> we may not be able to support line or hunk application as the patch
> is really two different patches against that path.  :-|
>
>> The following patch seems to fix this particular issue, but I don't think
>> it's the right fix...
>
> I don't think that is the right fix, but the one that I just tried to
> write to do clear_diff when we see the second diff --git line didn't
> work either.  Plus we probably need to disable the hunk apply code.

You will have the same issue not for submodules, too. A typechange has always been expressed as delete followed by create.

Probably you already have learned the nature of change (i.e. create? modify? delete? typechange?) when you populate the list of files with changes that could be staged, which means by the time the user picks from the liast you already know if it is a typechange.

Jakub Narebski· Sep 12, 2008, 18:01 UTC · re: Shawn O. Pearce · lore

Re: git-gui: more issues with diff parsing

"Shawn O. Pearce" <spearce@spearce.org> writes:
Show 21 quoted lines
> The diff is weird:
> 
>   $ git-diff-index --cached -p --no-color -U5 \
>       d6e02aa06c91c711d98ae06e6e69c5de5841a5e5 -- g
>   diff --git a/g b/g
>   deleted file mode 100644
>   index e69de29..1a010b1
>   diff --git a/g b/g
>   new file mode 120000
>   index e69de29..1a010b1
>   --- /dev/null
>   +++ b/g
>   @@ -0,0 +1 @@
>   +file
>   \ No newline at end of file
> 
> Notice how we get two diffs for the same file?  That's why git-gui
> is choking on this particular change.  It expected only one diff
> for the path it gave to Git.  It got two back.  In cases like this
> we may not be able to support line or hunk application as the patch
> is really two different patches against that path.  :-|

Hmmm... it looks _exactly_ like a problem I had with writing "syntax highlighting" (and linkage) for the patchset part of 'commitdiff' and 'blobdiff' views, namely that typechange (file to symlink and vice versa) generates two patches for single difftree (raw diff format output) line.

See git_patchset_body in gitweb/gitweb.perl, and is_patch_split function, and commit message of 0cec6db (gitweb: Fix and simplify "split patch" detection), which tells about alternate solution.

-- 
Jakub Narebski
Poland
ShadeHawk on #git

← back to recent threads