BigW Consortium Gitlab

  1. 12 Sep, 2017 1 commit
  2. 31 Aug, 2017 1 commit
  3. 08 Aug, 2017 1 commit
  4. 07 Jul, 2017 1 commit
  5. 05 Jul, 2017 1 commit
  6. 21 Jun, 2017 1 commit
  7. 12 May, 2017 1 commit
    • Fix conflict resolution from corrupted upstream · ad2bfeb8
      Sean McGivern authored
      I don't know why this happens exactly, but given an upstream and fork repository
      from a customer, both of which required GC, resolving conflicts would corrupt
      the fork so badly that it couldn't be cloned.
      
      This isn't a perfect fix for that case, because the MR may still need to be
      merged manually, but it does ensure that the repository is at least usable.
      
      My best guess is that when we generate the index for the conflict
      resolution (which we previously did in the target project), we obtain a
      reference to an OID that doesn't exist in the source, even though we already
      fetch the refs from the target into the source.
      
      Explicitly setting the source project as the place to get the merge index from
      seems to prevent repository corruption in this way.
  8. 15 Mar, 2017 1 commit
    • Allow resolving conflicts with non-ASCII chars · 96c77bf7
      Sean McGivern authored
      We wanted to check that the text could be encoded as JSON, because
      conflict resolutions are passed back and forth in that format, so the
      file itself must be UTF-8. However, all strings from the repository come
      back without an encoding from Rugged, making them ASCII_8BIT.
      
      We force to UTF-8, and reject if it's invalid. This still leaves the
      problem of a file that 'looks like' UTF-8 (contains valid UTF-8 byte
      sequences), but isn't. However:
      
      1. If the conflicts contain the problem bytes, the user will see that
         the file isn't displayed correctly.
      2. If the problem bytes are outside of the conflict area, then we will
         write back the same bytes when we resolve the conflicts, even though
         we though the encoding was UTF-8.
  9. 01 Mar, 2017 1 commit
  10. 23 Feb, 2017 2 commits
  11. 13 Oct, 2016 3 commits
    • Simplify conflict file JSON creation · 4743d194
      Sean McGivern authored
    • Allow setting content for resolutions · 3f71c43e
      Sean McGivern authored
      When reading conflicts:
      
      1. Add a `type` field. `text` works as before, and has `sections`;
         `text-editor` is a file with ambiguous conflict markers that can only
         be resolved in an editor.
      2. Add a `content_path` field pointing to a JSON representation of the
         file's content for a single file.
      3. Hitting `content_path` returns a similar datastructure to the `file`,
         but without the `content_path` and `sections` fields, and with a
         `content` field containing the full contents of the file (with
         conflict markers).
      
      When writing conflicts:
      
      1. Instead of `sections` being at the top level, they are now in a
         `files` array. This matches the read format better.
      2. The `files` array contains file hashes, each of which must contain:
         a. `new_path`
         b. `old_path`
         c. EITHER `sections` (which works as before) or `content` (with the
            full content of the resolved file).
  12. 07 Sep, 2016 1 commit
  13. 25 Aug, 2016 2 commits
  14. 12 Aug, 2016 23 commits