1. 21 Dec, 2015 1 commit
  2. 24 Nov, 2015 3 commits
  3. 20 Oct, 2015 1 commit
  4. 03 Oct, 2015 7 commits
  5. 22 Sep, 2015 1 commit
  6. 21 Sep, 2015 1 commit
  7. 16 Sep, 2015 1 commit
  8. 03 Sep, 2015 1 commit
  9. 28 Aug, 2015 3 commits
    • Luke Diamand's avatar
      git-p4: fix P4 label import for unprocessed commits · b43702ac
      Luke Diamand authored
      With --detect-labels enabled, git-p4 will try to create tags
      using git fast-import by writing a "tag" clause to the
      fast-import stream.
      
      If the commit that the tag references has not yet actually
      been processed by fast-import, then the tag can't be created
      and git-p4 fails to import the P4 label.
      
      Teach git-p4 to use fast-import "marks" when creating tags
      which reference commits created during the current run of the
      program.
      
      Commits created before the current run are still referenced
      in the old way using a normal git commit.
      Signed-off-by: Luke Diamand's avatarLuke Diamand <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      b43702ac
    • Luke Diamand's avatar
      git-p4: do not terminate creating tag for unknown commit · 9ab1cfe5
      Luke Diamand authored
      If p4 reports a tag for a commit that git-p4 does not know
      about (e.g. because it references a P4 changelist that was
      imported prior to the point at which the repo was cloned into
      git), make sure that the error is correctly caught and handled.
      rather than just crashing.
      Signed-off-by: Luke Diamand's avatarLuke Diamand <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9ab1cfe5
    • Lars Schneider's avatar
      git-p4: honor core.ignorecase when using P4 client specs · a0a50d87
      Lars Schneider authored
      Perforce depot may record paths in mixed cases, e.g. "p4 files" may
      show that there are these two paths:
      
         //depot/Path/to/file1
         //depot/pATH/to/file2
      
      and with "p4" or "p4v", these end up in the same directory, e.g.
      
         //depot/Path/to/file1
         //depot/Path/to/file2
      
      which is the desired outcome on case insensitive systems.
      
      If git-p4 is used with client spec "//depot/Path/...", however, then
      all files not matching the case in the client spec are ignored (in
      the example above "//depot/pATH/to/file2").
      
      Fix this by using the path case that appears first in lexicographical
      order when core.ignorecase is set to true. This behavior is consistent
      with "p4" and "p4v".
      Signed-off-by: default avatarLars Schneider <[email protected]>
      Acked-by: Luke Diamand's avatarLuke Diamand <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      a0a50d87
  10. 10 Jun, 2015 1 commit
    • Luke Diamand's avatar
      git-p4: fixing --changes-block-size handling · 1051ef00
      Luke Diamand authored
      The --changes-block-size handling was intended to help when
      a user has a limited "maxscanrows" (see "p4 group"). It used
      "p4 changes -m $maxchanges" to limit the number of results.
      
      Unfortunately, it turns out that the "maxscanrows" and "maxresults"
      limits are actually applied *before* the "-m maxchanges" parameter
      is considered (experimentally).
      
      Fix the block-size handling so that it gets blocks of changes
      limited by revision number ($Start..$Start+$N, etc). This limits
      the number of results early enough that both sets of tests pass.
      
      Note that many other Perforce operations can fail for the same
      reason (p4 print, p4 files, etc) and it's probably not possible
      to workaround this. In the real world, this is probably not
      usually a problem.
      Signed-off-by: Luke Diamand's avatarLuke Diamand <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      1051ef00
  11. 27 May, 2015 1 commit
  12. 24 May, 2015 1 commit
  13. 23 Apr, 2015 1 commit
    • Vitor Antunes's avatar
      git-p4: improve client path detection when branches are used · cd884106
      Vitor Antunes authored
      Perforce allows client side file/directory remapping through
      the use of the client view definition that is part of the
      user's client spec.
      
      To support this functionality while branch detection is
      enabled it is important to determine the branch location in
      the workspace such that the correct files are patched before
      Perforce submission. Perforce provides a command that
      facilitates this process: p4 where.
      
      This patch does two things to fix improve file location
      detection when git-p4 has branch detection and use of client
      spec enabled:
      
       1. Enable usage of "p4 where" when Perforce branches exist
          in the git repository, even when client specification is
          used. This makes use of the already existing function
          p4Where.
      
       2. Allow identifying partial matches of the branch's depot
          path while processing the output of "p4 where". For
          robustness, paths will only match if ending in "/...".
      Signed-off-by: Vitor Antunes's avatarVitor Antunes <[email protected]>
      Acked-by: Luke Diamand's avatarLuke Diamand <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      cd884106
  14. 20 Apr, 2015 1 commit
  15. 04 Apr, 2015 1 commit
  16. 11 Feb, 2015 1 commit
  17. 23 Jan, 2015 1 commit
  18. 13 Jun, 2014 1 commit
  19. 27 May, 2014 1 commit
  20. 07 May, 2014 1 commit
  21. 07 Apr, 2014 1 commit
  22. 22 Jan, 2014 4 commits
    • Pete Wyckoff's avatar
      git p4: fix an error message when "p4 where" fails · 20005443
      Pete Wyckoff authored
      When "p4 where" fails, for whatever reason, the error message tries to
      show an undefined variable.  This minor bug applies only when using a
      client spec, and was introduced recently in 9d57c4a6 (git p4: implement
      view spec wildcards with "p4 where", 2013-08-30).
      Signed-off-by: default avatarPete Wyckoff <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      20005443
    • Pete Wyckoff's avatar
      git p4: handle files with wildcards when doing RCS scrubbing · 79467e61
      Pete Wyckoff authored
      Commit 9d7d446a (git p4: submit files with wildcards, 2012-04-29)
      fixed problems with handling files that had p4 wildcard
      characters, like "@" and "*".  But it missed one case, that of
      RCS keyword scrubbing, which uses "p4 fstat" to extract type
      information.  Fix it by calling wildcard_encode() on the raw
      filename.
      Signed-off-by: default avatarPete Wyckoff <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      79467e61
    • Pete Wyckoff's avatar
      git p4 test: do not pollute /tmp · 0cf1b72a
      Pete Wyckoff authored
      Generating the submit template for p4 uses tempfile.mkstemp(),
      which by default puts files in /tmp.  For a test that fails,
      possibly on purpose, this is not cleaned up.  Run with TMPDIR
      pointing into the trash directory so the temp files go away
      with the test results.
      
      To do this required some other minor changes.  First, the editor
      is launched using system(editor + " " + template_file), using
      shell expansion to build the command string.  This doesn't work
      if editor has a space in it.  And is generally unwise as it's
      easy to fool the shell into doing extra work.  Exec the args
      directly, without shell expansion.
      
      Second, without shell expansion, the trick of "P4EDITOR=:" used
      in the tests doesn't work.  Use a real command, true, as the
      non-interactive editor for testing.
      Signed-off-by: default avatarPete Wyckoff <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      0cf1b72a
    • 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
  23. 22 Nov, 2013 1 commit
  24. 03 Sep, 2013 1 commit
    • Kazuki Saitoh's avatar
      git p4: implement view spec wildcards with "p4 where" · 9d57c4a6
      Kazuki Saitoh authored
      "git p4" does not support many of the view wildcards, such as * and
      %%n.  It only knows the common ... mapping, and exclusions.
      
      Redo the entire wildcard code around the idea of directly querying
      the p4 server for the mapping.  For each commit, invoke "p4 where"
      with committed file paths as args and use the client mapping to
      decide where the file goes in git.
      
      This simplifies a lot of code, and adds support for all wildcards
      supported by p4.  Downside is that there is probably a 20%-ish
      slowdown with this approach.
      
      [pw: redo code and tests]
      Signed-off-by: default avatarKazuki Saitoh <[email protected]>
      Signed-off-by: default avatarPete Wyckoff <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
      9d57c4a6
  25. 12 Aug, 2013 1 commit
  26. 29 Jul, 2013 1 commit
  27. 19 Jun, 2013 1 commit