1. 07 Oct, 2011 5 commits
  2. 30 Sep, 2011 1 commit
  3. 27 Sep, 2011 1 commit
  4. 26 Sep, 2011 2 commits
  5. 23 Sep, 2011 11 commits
  6. 20 Sep, 2011 2 commits
  7. 19 Sep, 2011 2 commits
    • Junio C Hamano's avatar
      Merge branch 'ph/format-patch-no-color' · 9b502a37
      Junio C Hamano authored
      * ph/format-patch-no-color:
        t4014: clean up format.thread config after each test
    • Jeff King's avatar
      t4014: clean up format.thread config after each test · e8107155
      Jeff King authored
      The threading tests turn on format.thread, but never clean
      up after themselves, meaning that later tests will also have
      format.thread set.
      This is more annoying than most leftover config, too,
      because not only does it impact the results of other tests,
      but it does so non-deterministically. Threading requires the
      generation of message-ids, which incorporate the current
      time, meaning a slow-running test script may generate
      different results from run to run.
      Signed-off-by: default avatarJeff King <peff@peff.net>
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  8. 18 Sep, 2011 1 commit
  9. 17 Sep, 2011 2 commits
    • Junio C Hamano's avatar
      Merge branch 'ci/forbid-unwanted-current-branch-update' · c103e952
      Junio C Hamano authored
      * ci/forbid-unwanted-current-branch-update:
        branch --set-upstream: regression fix
    • Junio C Hamano's avatar
      branch --set-upstream: regression fix · fa799376
      Junio C Hamano authored
      The "git branch" command, while not in listing mode, calls create_branch()
      even when the target branch already exists, and it does so even when it is
      not interested in updating the value of the branch (i.e. the name of the
      commit object that sits at the tip of the existing branch). This happens
      when the command is run with "--set-upstream" option.
      The earlier safety-measure to prevent "git branch -f $branch $commit" from
      updating the currently checked out branch did not take it into account,
      and we no longer can update the tracking information of the current branch.
      Minimally fix this regression by telling the validation code if it is
      called to really update the value of a potentially existing branch, or if
      the caller merely is interested in updating auxiliary aspects of a branch.
      Reported-and-Tested-by: Jay Soffian
      Signed-off-by: default avatarJunio C Hamano <gitster@pobox.com>
  10. 16 Sep, 2011 2 commits
  11. 15 Sep, 2011 1 commit
  12. 13 Sep, 2011 1 commit
    • Bryan Jacobs's avatar
      git-svn: teach git-svn to populate svn:mergeinfo · 1e5814f3
      Bryan Jacobs authored
      Allow git-svn to populate the svn:mergeinfo property automatically in
      a narrow range of circumstances. Specifically, when dcommitting a
      revision with multiple parents, all but (potentially) the first of
      which have been committed to SVN in the same repository as the target
      of the dcommit.
      In this case, the merge info is the union of that given by each of the
      parents, plus all changes introduced to the first parent by the other
      In all other cases where a revision to be committed has multiple
      parents, cause "git svn dcommit" to raise an error rather than
      completing the commit and potentially losing history information in
      the upstream SVN repository.
      This behavior is disabled by default, and can be enabled by setting
      the svn.pushmergeinfo config option.
      [ew: minor style changes and manpage merge fix]
      Acked-by: default avatarEric Wong <normalperson@yhbt.net>
      Signed-off-by: default avatarBryan Jacobs <bjacobs@woti.com>
  13. 12 Sep, 2011 9 commits