viewing the following commit will cause the browser to hang for several minutes then finally load the dead spider page
is unclear what is special about this commit - the diff is not particular large - other commits on the same repo load ok
i have this project mirrored all over - gogs seems to be the only one with this trouble - this is the diff for that commit if it helps:
Confirm this. I also have the same problem.
For some reason it seems that the 'git' command that gogs spawns takes way longer than normal to view those particular commits. I'll try to figure out why that is.
this one is curious - there does not seem to be anything peculiar about the diff - one thing to notice is that the commit message has (issue #30) in it - which makes a link but leads to a 404 - but if that is a bug i would think that would have been noticed sooner
That is a good catch though! I'll try to reproduce that in that manner.
ok it's not the commit message - i rebased and changed the message and the new commit has the same issue
ok i split it up into one file per commit and isolated the problem to one file
yes definitely that one 'mk-clean' file is the troublemaker
i rebased again just to re-order the commits and the commit with that same file is having the same issue
simply renaming the file fixed the problem
mk-clean → mkclean
all these commit are on this branch
a simple test case does not exhibit this https://notabug.org/bill-auger/gogs-filename-bug
O_o OK, I'll try to trace that problem. I wonder if it has anything to do with Gogs' attempts to do syntax highlighting and mimetype detection. I guess Gogs just stops functioning in the goroutine for that request and the git command is just waiting with a full pipe
this is quite bizzarre indeed - it seems not to be the filename either - simply adding an empty commit on top of the troubled one has no problem - this must be some crazy hashing bug where it just does not like being in that precise state
on this branch
also this is the identical diff as the troublesome commit (literally the same file copied from the other project) but alone in it's own project so that kinda rule out syntax highlighting yea?
Well, it was a good hypothesis while it lasted :) Thanks for digging, if you find anything more please keep updating this ticket. I'm at work now so I can't look into it immediately.
ok i have isolated the bug to this tiny test case
again this test-case repo has no problems on github or pagure
uch... That's... really, really bad 0_0. I hope there's an easy fix for this. I'll have a look when I can.
Also the reverse is true
btw I think git only tracks the executable bit of the owner. All other bits should be irrelevant.
this is what it shows me:
$ git diff HEAD^
diff --git a/mk-clean b/mk-clean
old mode 100644
new mode 100755
So, the hypothesis is that any commit that changes the file mode breaks? Or any commit that only changes file mode fails?
In the latter case it could just be an issue in the diff renderer.
@bill-auger I only used 0644 and 0744, I guess git automatically sets the same bit everywhere...
im trying to look this up - the format seems to be not documented - maybe @hp knows if that is that a standard notation but it is probably recording the setuid, setgid, and sticky bits as well as the standard user/group/world
is the filename at all important? can this be repeated with any filename?
I tried to reproduce this both on try.gogs and try.gitea. They seem to work OK.
Relevant note: I've only pushed commits with a single chmod change.
ok i was gonna suggest lets just toss this one over the fence but now it looks like it notabug only?
@hp it seems to happen in both cases
1. push empty file **OK**
2. chmod and push **BREAK**
1. push empty file **OK**
2. add new file with some text in it
3. chmod (empty file)
4. push in a single commit the new file and the chmod change **BREAK**
I've also tried chmod-ing with both empty and non-empty files to see if it would made any difference. Same issue instead.
yea it does not seem to matter what is in the file - but the name is important - have you tried with a different filename?
@bill-auger filename doesn't seem to make any difference for me... Do you have any particular name or combination that I could try?
ok i just tried a different filename - same deal - the filename is not important and the file contents are not important
@bill-auger This seems to work, could you try to reproduce?
It looks to me that Gogs crashes when reading the diff, if the diff contains at least one file with only permission changes (some parsing error?). But since it works on try.gogs, they probably fixed it already (just my wild guess).
sry forgot to answer directly your question - it seems to be any commit that changes the executable bit of any file but only if it changes only the executable bit - adding bytes to the file in the same commit as making it executable does not cause the problem for some reason
this branch demonstrates that:
yes i think we both verified the same thing - the commit can change any number of files but the probelm is if any one files changes only it's executable bit
The only significant change in the diff seems to be the index line, like for example index 0000000..e69de29; so I'd put my money on the fact that Gogs is looking for it even when there is no such line.
Well, that should at least be easy enough to find in the code.
I hope I've pinned down the problem.
The diff stuff is in a sub-module at vendor/github.com/gogits/git-module/repo_diff.go. On line 137 there is a function called ParsePatch that tries to understand what a diff is about. In particular where there is CHECK_TYPE:, there is a switch checking the prefix of each line to determine the type of that particular diff. When only the file mode has changed, the diff looks like this
diff --git a/myfile b/myfile
old mode 100644
new mode 100755
apparently Gogs is looking for one of new file, deleted, index, or similarity index 100%; neither old mode nor new mode match any case, so it's probably returning NULL or something like that. They seem to have added an additional check for old mode a couple of months ago.
similarity index 100%
I hope this fixes the issue.
Team work :)
Let's hope this simple fix can solve the problem.
This issue has been fixed and can be closed. Gogs still doesn't show mode change in the UI (eg 0644 -> 0755) but this is only a minor nuisance; it doesn't crash anymore.
0644 -> 0755