1. 26 7月, 2006 2 次提交
    • J
      Merge branch 'jt/format-patch' · e79992ab
      Junio C Hamano 提交于
      * jt/format-patch:
        builtin-log: typefix for recent format-patch changes.
        Add option to set initial In-Reply-To/References
        Add option to enable threading headers
        git-format-patch: Make the second and subsequent mails replies to the first
      e79992ab
    • J
      Merge branch 'ew/apply' · a8861ea8
      Junio C Hamano 提交于
      * ew/apply:
        Fix t4114 on cygwin
        apply: handle type-changing patch correctly.
        apply: split out removal and creation into different phases.
        apply: check D/F conflicts more carefully.
        typechange tests for git apply (currently failing)
      a8861ea8
  2. 25 7月, 2006 4 次提交
  3. 24 7月, 2006 15 次提交
  4. 18 7月, 2006 2 次提交
  5. 17 7月, 2006 7 次提交
    • J
      Merge branch 'sp/reflog' · b9718d41
      Junio C Hamano 提交于
      * sp/reflog:
        Record rebase changes as 'rebase' in the reflog.
        Log ref changes made by resolve.
        Log ref changes made by quiltimport.
        Log ref changes made by git-merge and git-pull.
      b9718d41
    • J
      apply: handle type-changing patch correctly. · 7f95aef2
      Junio C Hamano 提交于
      A type-change diff is always split into a patch to delete old,
      immediately followed by a patch to create new.  check_patch()
      routine noticed that the path to be created already exists in
      the working tree and/or in the index when looking at the
      creation patch and mistakenly thought it to be an error.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      7f95aef2
    • J
      apply: split out removal and creation into different phases. · eed46644
      Junio C Hamano 提交于
      This reworks write_out_result() loop so we first remove the paths that
      are to go away and then create them after finishing all the removal.
      
      This is necessary when a patch creates a file "foo" and removes a file
      "foo/bar".
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      eed46644
    • J
      apply: check D/F conflicts more carefully. · c28c571c
      Junio C Hamano 提交于
      When creating a new file where a directory used to be (or the user had
      an empty directory) the code did not check the result from lstat() closely
      enough, and mistakenly thought the path already existed in the working tree.
      
      This does not fix the problem where you have a patch that creates a file
      at "foo" and removes a file at "foo/bar" (which presumably is the last file
      in "foo/" directory in the original).  For that, we would need to restructure
      write_out_results() loop.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      c28c571c
    • J
      checkout -f failed to check out a file if an existing directory interfered. · f8f0b1f0
      Junio C Hamano 提交于
      When path foo/bar existed in the working tree, checkout -f to switch to
      a branch that has a file foo silently did a wrong thing.  It failed to
      remove the directory foo, did not check out the file foo, and the worst
      of all it did not report any errors.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      f8f0b1f0
    • E
      typechange tests for git apply (currently failing) · 8641fb24
      Eric Wong 提交于
      I've found that git apply is incapable of handling patches
      involving object type changes to the same path.
      
      Of course git itself is perfectly capable of making commits that
      generate these changes, as it only tracks trees states.  It's
      just that the diffs between them are less useful if they can't
      be applied.
      
      Some of these are rare, but I've hit one of them (file becoming
      a symlink) recently in real-world usage, and was inspired to
      find more potential breakages :)
      
      I'm not sure when I'll have time to fix these myself and I'm not
      very familiar with the apply code.   So if someone could get
      some or all of these cases working, they would be my hero :)
      
      Some of these are what I would refer to as corner-cases from
      hell.  Most (if not all) other systems fail some of these.  In
      fact, they aren't even capable of representing most of these
      changes in their histories; much less being able to handle
      patches to that effect.
      Signed-off-by: NEric Wong <normalperson@yhbt.net>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      8641fb24
    • E
      git-svn: don't check for migrations/upgrades on commit-diff · 7b520e62
      Eric Wong 提交于
      Unlike other git-svn commands, commit-diff is intended to
      operate without needing any additional metadata inside .git
      Signed-off-by: NEric Wong <normalperson@yhbt.net>
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      7b520e62
  6. 16 7月, 2006 1 次提交
    • J
      show-branch: fix performance problem. · 26a8ad25
      Junio C Hamano 提交于
      The core function used in show-branch, join_revs(), was supposed
      to be exactly the same algorithm as merge_bases(), except that
      it was a version enhanced for use with more than two heads.
      However, it needed to mark and keep a list of all the commits it
      has seen, because it needed them for its semi-graphical output.
      The function to implement this list, mark_seen(), stupidly used
      insert_by_date(), when it did not need to keep the list sorted
      during its processing.  This made "show-branch --merge-base"
      more than 20x slower compared to "merge-base --all" in some
      cases (e.g. between b5032a5 and 48ce8b0 in the Linux 2.6 kernel
      archive).  The performance of "show-branch --independent"
      suffered from the same reason.
      
      This patch sorts the resulting list after the list traversal
      just once to fix these problems.
      Signed-off-by: NJunio C Hamano <junkio@cox.net>
      26a8ad25
  7. 15 7月, 2006 9 次提交