Make the intent of "--bool" more obvious by returning a direct True
or False value.  Convert a couple non-bool users with obvious bool
intent.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Invoke git rev-list directly, avoiding the shell, in
P4Submit and P4Sync.  The overhead of starting extra
processes is significant in cygwin; this speeds things
up on that platform.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The extra quoting and double-% are unneeded, just to work
around the shell.  Instead, avoid the shell indirection.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

On windows, p4 marks un-edited files as read-only.  Not only are
they read-only, but also they cannot be deleted.  Remove the
read-only attribute before deleting in both the copy and rename
cases.

This also happens in the RCS cleanup code, where a file is marked
to be deleted, but must first be edited to remove adjust the
keyword lines.  Make sure it is editable before patching.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Files of type utf16 are handled with "p4 print" instead of the
normal "p4 -G print" interface due to how the latter does not
produce correct output.  See 55aa5714 (git-p4: handle utf16
filetype properly, 2011-09-17) for details.

On windows, though, "p4 print" can not be told which line
endings to use, as there is no underlying client, and always
chooses crlf, even for utf16 files.  Convert the \r\n into \n
when importing utf16 files.

The fix for this is complex, in that the problem is a property
of the NT version of p4.  There are old versions of p4 that
were compiled directly for cygwin that should not be subjected
to text replacement.  The right check here, then, is to look
at the p4 version, not the OS version.  Note also that on cygwin,
platform.system() is "CYGWIN_NT-5.1" or similar, not "Windows".

Add a function to memoize the p4 version string and use it to
check for "/NT", indicating the Windows build of p4.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Replacing \r\n with \n on windows was added in c1f9197f (Replace
\r\n with \n when importing from p4 on Windows, 2007-05-24), to
work around an oddity with "p4 print" on windows.  Text files
are printed with "\r\r\n" endings, regardless of whether they
were created on unix or windows, and regardless of the client
LineEnd setting.

As of d2c6dd30 (use p4CmdList() to get file contents in Python
dicts. This is more robust., 2007-05-23), git-p4 uses "p4 -G
print", which generates files in a raw format.  As the native
line ending format if p4 is \n, there will be no \r\n in the
raw text.

Actually, it is possible to generate a text file so that the
p4 representation includes embedded \r\n, even though this is not
normal on either windows or unix.  In that case the code would
have mistakenly stripped them out, but now they will be left
intact.

More information on how p4 deals with line endings is here:

    http://kb.perforce.com/article/63Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Depot paths must start with //.  Exit with a better explanation
when a bad depot path is supplied.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Found by "pyflakes" checker tool.
Modules shelve, getopt were unused.
Module os.path is exported by os.
Reformat one-per-line as is PEP008 suggested style.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Commit fed23693 (git-p4: Search for parent commit on branch creation,
2012-01-25) uses temporary branches to help find the parent of a
new p4 branch.  The temp branches are of the form "git-p4-tmp/%d"
for some p4 change number.  Mistakenly, this string was made
using os.path.join() instead of just string concatenation.  On
windows, this turns into a backslash (\), which is not allowed in
git branch names.
Reported-by: NCasey McGinty <casey.mcginty@gmail.com>
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It finds its upstream and applies the commit properly, but
the sync step will fail unless it is told which branch to
work on.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It is legal to sync a branch with a different name than
refs/remotes/p4/master, and to do so even when master does
not exist.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If --branch was used to build a repository with no
refs/remotes/p4/master, future syncs will not know
which branch to sync.  Notice this situation and
print a helpful error message.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This was set in a couple of places, both of which were very
far away from its use.  Move it a bit closer to importChanges(),
and add some comments.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

For a clone or sync, --branch says where the newly imported
branch should go, or which existing branch to sync up.  It
takes an argument, which is currently either something that
starts with "refs/", or if not, "refs/heads/p4" is prepended.

Putting it in heads seems like a bad default; these should
go in remotes/p4/ in most situations.  Make that the new default,
and be more liberal in the form of the branch name.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When using the --branch argument to "git p4 clone", one
might specify a destination for p4 changes different from
the default refs/remotes/p4/master.  Both cases should
create a master branch and checkout files.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

There is code to create a symbolic reference from p4/HEAD to
p4/master.  This allows saying "git show p4" as a shortcut
to "git show p4/master", for example.

But this reference was only created on the second "git p4 sync"
(or first sync after a clone).  Make it work on the initial
clone or sync.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It is four lines of code used in only one place.  Simplify by
including it where it is used.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NEric S. Raymond <esr@thyrsus.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

It confuses pylint, and is never needed.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Error messages that arise during the "p4 print" phase of
generating commits were silently ignored.  Catch them,
abort the fast-import, and exit.

Without this fix, the sync/clone appears to work, but files that
are inaccessible by the p4d server will still be imported to git,
although without the proper contents.  Instead the errant files
will contain a p4 error message, such as "Librarian checkout
//depot/path failed".
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Support for the "p4 move" command was added in 8e9497c2 (git p4:
add support for 'p4 move' in P4Submit, 2012-07-12), which checks
to make sure that the client and server support the command.

But older versions of p4d may not handle the "-k" argument, and
newer p4d allow disabling "p4 move" with a configuration setting.
Check for both these cases by testing a p4 move command on bogus
filenames and looking for strings in the error messages.
Reported-by: NVitor Antunes <vitor.hda@gmail.com>
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Group the two calls to "p4 describe" into a new helper function,
and try to validate the p4 results.  The current behavior when p4
describe fails is to die with a python backtrace.  The new behavior
will print the full response.

This does not solve any particular problem, but adds more
checking in hopes of narrowing down odd behavior seen on
at least two occasions.
Based-on-patch-by: NMatt Arsenault <arsenm2@gmail.com>
Reported-by: NArthur <a.foulon@amesys.fr>
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This bug was introduced in cb585a9c (git-p4: keyword
flattening fixes, 2011-10-16).  The newline character
is indeed special, and $File$ expansions should not try
to match across multiple lines.
Based-on-patch-by: NChris Goard <cgoard@gmail.com>
Signed-off-by: NPete Wyckoff <pw@padd.com>
Signed-off-by: NJeff King <peff@peff.net>

This allows specifying what to do when a conflict
happens when applying a commit to p4, automating the
interactive prompt.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

This option can be used to prepare the client workspace for
submission, only.  It does not invoke the final "p4 submit".
A message describes how to proceed, either submitting the
changes or reverting.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

A new option, "git p4 submit --dry-run" can be used to verify
what commits and labels would be moved into p4.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The short form "-v" is common in many git commands as an
alias for "--verbose".
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The user can decide not to continue with a submission,
by not saving the p4 submit template, then answering "no" to
the "Submit anyway?" prompt.  In this case, be sure to
return the p4 client to its initial state.

Deleted files were not reverted; fix this and test all cases.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Put all items in order as they appear, and add comments.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

Test a variety of cases where a patch failed to apply to
p4 and had to be cleaned up.

If the patch failed to apply cleanly, do not try to remove
to-be-added files, as they have not really been added yet.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When editing the submit template, if no change was made to it,
git p4 offers a prompt "Submit anyway?".  Answering "no" cancels
the submit.

Previously, a "no" answer behaves like a "[s]kip" answer to the
failed-patch prompt, in that it proceeded to try to apply the
rest of the commits.  Instead, put users back into the new
"[s]kip / [c]ontinue" loop so that they can decide.  This makes
both cases of patch failure behave identically.

The return code of git p4 after a "no" answer is now the same
as that for a "skip" due to failed patch; update a test to
understand this.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When applying a commit to the p4 workspace fails, a prompt
asks what to do next.  This belongs up in run() instead
of in applyCommit(), where run() can notice, for instance,
that the prompt is unnecessary because this is the last commit.

Offer two options about how to continue at conflict: [s]kip or
[q]uit.  Having an explicit "quit" option gives git p4 a chance
to clean up, show the applied-commit summary, and do tag export.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

When a patch failed to apply, these interactive options offered
to:

    1) apply the patch anyway, leaving reject (.rej) files around, or,
    2) write the patch to a file (patch.txt)

In both cases it suggested to invoke "git p4 submit --continue",
an unimplemented option.

While manually fixing the rejects and submitting the result might
work, there are many steps that must be done to the job properly:

    * apply patch
    * invoke p4 add and delete
    * change executable bits
    * p4 sync -f renamed/copied files
    * extract commit message into p4 change description and
      move Jobs lines out of description section
    * set changelist owner for --preserve-user

Plus the following manual sync/rebase will cause conflicts too,
which must be resolved once again.

Drop these workflows.  Instead users should do a sync/rebase in
git, fix the conflicts there, and do a clean "git p4 submit".
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

If a commit fails to apply cleanly to the p4 tree, an interactive
prompt asks what to do next.  In all cases (skip, apply, write),
the behavior after the prompt had a few problems.

Change it so that it does not claim erroneously that all commits
were applied.  Instead list the set of the patches under
consideration, and mark with an asterisk those that were
applied successfully.  Like this example:

    Applying 592f1f9 line5 in file1 will conflict
    ...
    Unfortunately applying the change failed!
    What do you want to do?
    [s]kip this patch / [a]pply the patch forcibly and with .rej files / [w]rite the patch to a file (patch.txt) s
    Skipping! Good luck with the next patches...
    //depot/file1#4 - was edit, reverted
    Applying b8db1c6 okay_commit_after_skip
    ...
    Change 6 submitted.
    Applied only the commits marked with '*':
      592f1f9 line5 in file1 will conflict
    * b8db1c6 okay_commit_after_skip

Do not try to sync and rebase unless all patches were applied.
If there was a conflict during the submit, there is sure to be one
at the rebase.  Let the user to do the sync and rebase manually.

This changes how a couple tets in t9810-git-p4-rcs.sh behave:

    - git p4 now does not leave files open and edited in the
      client

    - If a git commit contains a change to a file that was
      deleted in p4, the test used to check that the sync/rebase
      loop happened after the failure to apply the change.  Since
      now sync/rebase does not happen after failure, do not test
      this.  Normal rebase machinery, outside of git p4, will let
      rebase --skip work.
Signed-off-by: NPete Wyckoff <pw@padd.com>
Acked-by: NLuke Diamand <luke@diamand.org>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>

The bug report in http://stackoverflow.com/questions/11893688
observes that files are mapped into the wrong locations in
git when both --use-client-spec and --branch-detection are enabled.

Fix this by changing the relative path prefix to match discovered
branches when using a client spec.

The problem was likely introduced with ecb7cf98 (git-p4: rewrite view
handling, 2012-01-02).
Signed-off-by: NPete Wyckoff <pw@padd.com>
Tested-by: NMatthew Korich <matthew@korich.net>
Signed-off-by: NJunio C Hamano <gitster@pobox.com>