Sublime Forum

Wrong blocks staged with large .sql file

#1

Hi,

I’m developing a system that has MySQL database with respectable amount of tables and data. I am tracking changes in the database by exporting the table to SQL using phpMyAdmin, which should produce nicely diffable .sql dump file. On the development environment side there is also “a set number” of rows, basically some set of data, which also gets updated in the process. The size of the last dump was 1.77MB which for a text file is somewhat large.

The problem comes when I replace the .sql dump file with the new one, that contains one new table in one place in the file, indexes in another, constraints in third and auto increment in fourh location across the file - four spots here and there, basically. It shows the diff just fine, I think, but when I try to merge one block or selected rows - it does not matter - it stages some very different piece of the file. Currently I am unable to merge the updates. My next workaround is to export the table without data, so it’s a lot smaller file, and hopefully easier for diff/git to handle…

Unfortunately I can’t provide the sample file I’m having the issue with, but I guess you could just export some 2MB SQL file using phpMyAdmin, add it, create a new table with indexes and constraints, export it again, and try to merge one block from the middle…

I’m using Windows 7 Professional 64-bit Finnish, and the SQL dump is from phpMyAdmin running on top of XAMPP at the same computer.

Here’s the debug info, with personal and identifyable strings removed:

=== App Version Information ===
Build: 1107

=== Git Version Information ===
Using Git: C:\Program Files\Sublime Merge\Git\cmd\git.exe (bundled)
git version 2.19.1.windows.1
PATH: C:\Program Files (x86)\Common Files\Oracle\Java\javapath;C:\ProgramData\Oracle\Java\javapath;C:\Windows\SYSTEM32;C:\Windows;C:\Windows\SYSTEM32\WBEM;C:\Windows\SYSTEM32\WINDOWSPOWERSHELL\V1.0\;C:\Program Files\Git\cmd;C:\Program Files (x86)\Nmap

=== Browse Page Information ===
HEAD: (hidden)
Is in merge: 0
Is in cherry_pick: 0
Is in rebase: 0
Is in revert: 0

=== Git Status Information ===
 M dump.sql

=== Our Status Information ===
 M dump.sql

=== Git Config Information ===
color.branch=auto
color.diff=auto
color.interactive=true
color.status=auto
core.autocrlf=true
core.bare=false
core.filemode=false
core.fscache=true
core.ignorecase=true
core.logallrefupdates=true
core.repositoryformatversion=0
core.symlinks=false
credential.helper=manager
diff.astextplain.textconv=astextplain
filter.lfs.clean=git-lfs clean -- %f
filter.lfs.process=git-lfs filter-process
filter.lfs.required=true
filter.lfs.smudge=git-lfs smudge -- %f
    help.format=html
http.sslcainfo=/ssl/certs/ca-bundle.crt
pack.packsizelimit=2g
rebase.autosquash=true
user.email=(hidden)
user.name=(hidden)

=== Our Config Information ===
Git Config Path Information
Using config path: /C/ProgramData/Git/config
Using config path: /C/Program Files/Sublime Merge/Git/mingw64/etc/gitconfig
Using config path: /C/Users/(hidden)/.config/git/config
Using config path: /C/Users/(hidden)/.gitconfig
Using config path: /C/xampp/htdocs/.git/config

Our config output is identical to the Git config output

=== Git Attributes Information ===
git check_attr --all output
dump.sql

=== Our Modified Files Newline Normalisation and EOL Information ===
dump.sql: autocrlf - crlf
0 Likes

#2

I tested it around a bit more, and noticed that staging the changes in the beginning of the file work just fine, but when trying to stage ones near the the end, the whole thing breaks. The diff is first shown OK, but as I stage a block near the end, the diff goes haywire. It detects a massive removal, which is not there, if I unstage the block. Here’s a screenshot to illustrate what I mean:


The deletion that is wrongly detected goes all the way to the end of the file.

0 Likes

#3

However, at the end of that big red blob the rest of the file can still be seen on the right, intact:


I think this is the culprit here. Perhaps the file size is the key here…?

0 Likes

#4

Did you turn on ignore-whitespace? Staging hunks with whitespace hidden has always caused problems for me in every visual git tool.

I might have an idea as to the cause (if whitespace related) based on the issues I’ve found related to whitespace, and need a few stats to ponder:

  1. how many total lines are there?
  2. how many blank lines are there? i.e. match count to the regex ^[ \t]*$
  3. how many groups of blank line are there? i.e. match count to the regex (\n[ \t]*$){2,}
  4. how many git diff hunks are there? i.e. result of git diff <filename> | grep "@@" | wc -l
0 Likes

#5

Here are my answers:

  1. Total line count is 6770
  2. There are 215 blank lines
  3. There are 0 blank line groups
  4. There are 13 git diff hunks

At least when I ran git diff dump.sql all I got was the correct hunks…

0 Likes