This project is mirrored from https://github.com/git/git. Updated .
  1. 22 Jan, 2014 1 commit
    • Pete Wyckoff's avatar
      git p4: work around p4 bug that causes empty symlinks · 40f846c3
      Pete Wyckoff authored
      Damien Gérard highlights an interesting problem.  Some p4
      repositories end up with symlinks that have an empty target.  It
      is not possible to create this with current p4, but they do
      indeed exist.
      
      The effect in git p4 is that "p4 print" on the symlink returns an
      empty string, confusing the curret symlink-handling code.
      
      Such broken repositories cause problems in p4 as well, even with
      no git involved.  In p4, syncing to a change that includes a
      bogus symlink causes errors:
      
          //depot/empty-symlink - updating /home/me/p4/empty-symlink
          rename: /home/me/p4/empty-symlink: No such file or directory
      
      and leaves no symlink.
      
      In git, replicate the p4 behavior by ignoring these bad symlinks.
      If, in a later p4 revision, the symlink happens to point to
      something non-null, the symlink will be replaced properly.
      
      Add a big test for all this too.
      
      This happens to be a regression introduced by 1292df11 (git-p4:
      Fix occasional truncation of symlink contents., 2013-08-08) and
      appeared first in 1.8.5.  But it shows up only in p4 repositories
      of dubious character, so can wait for a proper release.
      Tested-by: Damien Gerard's avatarDamien Gérard <[email protected]>
      Signed-off-by: default avatarPete Wyckoff <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      40f846c3
  2. 21 Jan, 2014 1 commit
  3. 29 Jul, 2013 1 commit
  4. 18 Jun, 2013 1 commit
    • Brandon Casey's avatar
      t/t9802: explicitly name the upstream branch to use as a base · 9d58c4a3
      Brandon Casey authored
      Prior to commit fa83a33b, the 'git checkout' DWIMery would create a
      new local branch if the specified branch name did not exist and it
      matched exactly one ref in the "remotes" namespace.  It searched
      the "remotes" namespace for matching refs using a simple comparison
      of the trailing portion of the remote ref names.  This approach
      could sometimes produce false positives or negatives.
      
      Since fa83a33b, the DWIMery more strictly excludes the remote name
      from the ref comparison by iterating through the remotes that are
      configured in the .gitconfig file.  This has the side-effect that
      any refs that exist in the "remotes" namespace, but do not match
      the destination side of any remote refspec, will not be used by
      the DWIMery.
      
      This change in behavior breaks the tests in t9802 which relied on
      the old behavior of searching all refs in the remotes namespace,
      since the git-p4 script does not configure any remotes in the
      .gitconfig.  Let's work around this in these tests by explicitly
      naming the upstream branch to base the new local branch on when
      calling 'git checkout'.
      Signed-off-by: default avatarBrandon Casey <[email protected]>
      Acked-by: default avatarPete Wyckoff <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9d58c4a3
  5. 27 Jan, 2013 2 commits
  6. 09 Apr, 2012 1 commit
  7. 06 Nov, 2011 1 commit
  8. 18 Oct, 2011 1 commit
    • Pete Wyckoff's avatar
      git-p4: handle utf16 filetype properly · 55aa5714
      Pete Wyckoff authored
      One of the filetypes that p4 supports is utf16.  Its behavior is
      odd in this case.  The data delivered through "p4 -G print" is
      not encoded in utf16, although "p4 print -o" will produce the
      proper utf16-encoded file.
      
      When dealing with this filetype, discard the data from -G, and
      instead read the contents directly.
      
      An alternate approach would be to try to encode the data in
      python.  That worked for true utf16 files, but for other files
      marked as utf16, p4 delivers mangled text in no recognizable encoding.
      
      Add a test case to check utf16 handling, and +k and +ko handling.
      Reported-by: default avatarChris Li <[email protected]>
      Acked-by: Luke Diamand's avatarLuke Diamand <[email protected]>
      Signed-off-by: default avatarPete Wyckoff <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      55aa5714