1. 23 Mar, 2016 1 commit
  2. 28 Feb, 2016 1 commit
  3. 04 Feb, 2016 1 commit
  4. 02 Feb, 2016 1 commit
  5. 15 Jan, 2016 1 commit
  6. 04 Jan, 2016 1 commit
  7. 03 Dec, 2015 1 commit
  8. 30 Nov, 2015 1 commit
  9. 24 Nov, 2015 2 commits
  10. 23 Nov, 2015 1 commit
  11. 20 Nov, 2015 1 commit
  12. 05 Nov, 2015 1 commit
  13. 30 Oct, 2015 1 commit
  14. 07 Oct, 2015 2 commits
  15. 01 Oct, 2015 3 commits
  16. 01 Sep, 2015 2 commits
  17. 31 Aug, 2015 1 commit
  18. 01 Jul, 2015 1 commit
  19. 19 Jun, 2015 2 commits
  20. 18 Jun, 2015 1 commit
  21. 23 May, 2015 1 commit
  22. 18 May, 2015 1 commit
  23. 04 May, 2015 1 commit
  24. 27 Apr, 2015 1 commit
  25. 16 Apr, 2015 1 commit
  26. 15 Apr, 2015 1 commit
  27. 09 Apr, 2015 1 commit
  28. 07 Apr, 2015 2 commits
  29. 01 Apr, 2015 1 commit
  30. 14 Mar, 2015 2 commits
  31. 06 Mar, 2015 1 commit
    • machenbach's avatar
      Make automated branch creation gnumbd-save. · 934dd88d
      machenbach authored
      This makes now the same simplification as the chromium
      release scripts do. For creating branch B from a gnumbd'ed
      (aka real) commit X do:
      1. Branch Y off the real X
      2. Set refs/pending/heads/B to Y
      3. Set refs/pending-tags/B to X
      4. Set refs/heads/B to X
      
      The old algorithm tried to branch off the pending
      correspondent of X. That commit was determined by comparing
      tree objects of the real X and commits on pending.
      Unfortunately, multiple commits on one branch can refer to
      the same tree object, e.g., for commits P, Q, R with R being
      the revert of Q, P and R refer to the same tree object.
      
      TBR=tandrii@chromium.org
      NOTRY=true
      TEST=./script_test.py
      TEST=tools/release/create_release.py -a me -r you --dry-run
      
      Review URL: https://codereview.chromium.org/979243004
      
      Cr-Commit-Position: refs/heads/master@{#27042}
      934dd88d
  32. 05 Mar, 2015 1 commit
    • machenbach's avatar
      Fix progress check in auto-roller. · f96e2260
      machenbach authored
      Using a git range check for checking progress is wrong when
      the last rolled revision and the revision candidate are on
      different branches. The range A..B will always show the
      commits from the merge-base of A and B until B.
      
      Better compare the tags of the last rolled revision and the
      candidate. The candidate's version must be strictly greater
      than what's in chromium.
      
      TBR=tandrii@chromium.org
      NOTRY=true
      TEST=./script_test.py
      
      Review URL: https://codereview.chromium.org/979133002
      
      Cr-Commit-Position: refs/heads/master@{#27021}
      f96e2260