This project is mirrored from Pull mirroring updated .
  1. 30 Sep, 2022 9 commits
  2. 29 Sep, 2022 1 commit
  3. 26 Sep, 2022 1 commit
  4. 25 Sep, 2022 4 commits
  5. 24 Sep, 2022 1 commit
  6. 19 Sep, 2022 4 commits
  7. 17 Sep, 2022 1 commit
  8. 08 Sep, 2022 1 commit
  9. 07 Sep, 2022 1 commit
  10. 05 Sep, 2022 1 commit
  11. 02 Sep, 2022 1 commit
  12. 30 Aug, 2022 4 commits
  13. 29 Aug, 2022 1 commit
  14. 25 Aug, 2022 1 commit
  15. 14 Aug, 2022 1 commit
  16. 08 Aug, 2022 3 commits
    • mkettl's avatar
      Merge branch configurable-code-block-analysis-fixed-merges · ee44926d
      mkettl authored
      git-svn-id: 4712c6d2-40bb-43ae-aa4b-fec3f1bdfe4c
    • mkettl's avatar
      Revert merge of branch configurable-code-block-analysis-fixed-merges · 3efb9b47
      mkettl authored
      git-svn-id: 4712c6d2-40bb-43ae-aa4b-fec3f1bdfe4c
    • pwendler's avatar
      Fake merge of remainder of previous branch · 0587f138
      pwendler authored
      The branch configurable-code-block-analysis-fixed-merges is based on
      configurable-code-block-analysis, and all relevant commits from the latter
      were cherry-picked into the former.
      Only broken merge commits (without appropriate merge metadata)
      are left over (not cherry-picked) in configurable-code-block-analysis.
      This would usually be no problem and the metadata etc. is completely correct.
      However, because git is less powerful than svn with respect to cherry picking,
      this situation causes problems for git-svn.
      When we merge configurable-code-block-analysis-fixed-merges into trunk
      as we did in r41348 / 7a46e878,
      git-svn refused to create a merge commit
      and thus all the changes developed in both branches
      look as if committed in that single commit.
      This makes for example "git blame" much less useful.
      Now if we fake a complete merge of configurable-code-block-analysis
      into configurable-code-block-analysis-fixed-merges it seems that git-svn
      will create a proper merge commit when merging the latter into trunk
      (at least in my tests). So lets do this.
      This fake merge is safe to do and does not create any further trouble
      because as mentioned above configurable-code-block-analysis-fixed-merges
      already contains most commits from configurable-code-block-analysis,
      and those few commits that were not cherry-picked into
      configurable-code-block-analysis-fixed-merges where actually
      replicated manually on the latter branch.
      So configurable-code-block-analysis-fixed-merges does have exactly
      the same content as if configurable-code-block-analysis would have been
      merged into it, just the metadata is different.
      A non-fake merge of configurable-code-block-analysis would have an empty diff,
      but only after resolving tons of merge conflicts.
      So we do the fake merge with
      svn merge ^/branches/configurable-code-block-analysis@39567 --record-only
      git-svn-id: 4712c6d2-40bb-43ae-aa4b-fec3f1bdfe4c
  17. 05 Aug, 2022 1 commit
  18. 04 Aug, 2022 4 commits