[ List Earliest Comments Only For Pages | Games | Rated Pages | Rated Games | Subjects of Discussion ]
Check out Janggi (Korean Chess), our featured variant for December, 2024.
Check out Janggi (Korean Chess), our featured variant for December, 2024.
Well, for most of the history the source was very much corrupted, because you apparently do something wrong when resolving merge conflicts. When such a conflict occurs, git writes <<<<<<, ===== and >>>>> markers in the conflicting file(s), to offer you an opportunity to select the competing outcomes of the merge on which git could not decide automatically which was the right one. The idea is that you then solve those conflicts by editing, in any case removing all markers, and leaving in only the content that should be there (which sometimes is neither or both the alternatives). Then you can continue the merge to finish the conflicting and the remaining commits. It seems you never do that, though, and just continue the merge with all the cruft in it. Which would of course make the project unbuildable. It is furthermore extremely confusing for someone trying to merge the branch later that he finds lots of conflict markers which are not a result of his own merge, but were already contained in the files. When he removes those as he normally should, git will keep nagging him with new conflicts, because it now thinks the conflict markers actually belong in the file, while you had removed them.
Anyway, in the past few hours I managed to do a new rebase of (a copy of) the trial branch, (without re-ordering anything yet) for each conflict consulting the commitdiff of the original commit. And this eventually produced a result that was pretty close to the head of trial; just 4 missing pieces in fairy-set-view.js, a corrupted terror.js and some whitespace differences in index.js. I added three commits to fix those, and now only some whitespace differences in index.js remain. (I don't know how to remove carriage returns that are apparently originating from editing on Windows...)
The good news is that when I now repeat the rebase (still without reordering) on this repaired branch, it succeeds fully automatically in a few seconds. And I don't think any of the intermediate states of this new branch contain conflict markers (which could cause problems after re-ordering).