git-gui: more issues with diff parsing

git-gui: more issues with diff parsing

[Michele Ballabio]

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 {

Re: git-gui: more issues with diff parsing

[Shawn O. Pearce]

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.
 
> 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.

Re: git-gui: more issues with diff parsing

[Junio C Hamano]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> 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.

Re: git-gui: more issues with diff parsing

[Jakub Narebski]

"Shawn O. Pearce" <spearce@spearce.org> writes:

> 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