GNOME Bugzilla – Bug 792733
Diff's hunk callback always report first hunk in diff
Last modified: 2019-02-22 03:51:41 UTC
Using ggit_diff_blob_to_buffer(), the hunk callback always gets passed a pointer to the very first hunk in the diff, whatever the number of hunk may be for that diff. This seems to be because libgit2-glib uses libgit2's hunk object pointer address as a key for its hunks cache hash table while libgit2 always passes the same pointer and simply memcopy() new hunk data in place at each run... Most probably, libgit's hunk object pointer address should not be use as a key in that hash table. I can work on a fix, but I'd like to discuss what's best to use here as a unique key first. The key should identify a particular hunk for a particular delta (ie. file). Thus it should be build with something unique from the delta and something unique from the hunk. For the hunk, the new_start (or old_start) integer should be unique within a given delta. The content string should also be. For the delta, the only thing that I can think of right now is the new_file (or old_file) path. Would using a combination of both of these be acceptable? Any better option?
Created attachment 367228 [details] [review] Do not rely on memory locations for diff objects caching First attempt, using delta's old_file oid and hunk's header content. Comments and feedbacks welcome.
Review of attachment 367228 [details] [review]: Sorry for the late response. Could you please split the patch making first the refactoring of the init method and then the real patch?
Created attachment 368680 [details] [review] Do not rely on memory locations for diff objects caching
Created attachment 368681 [details] [review] Refactor wrapper data initialisation
Created attachment 369215 [details] [review] Do not rely on memory locations for diff objects caching
Created attachment 369216 [details] [review] Refactor wrapper data initialisation
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gitg/issues/109.