Just like the working tree is cleaned up when the user cancelled
submission in P4Submit.applyCommit(), clean up the mess if "p4
submit" fails.

* eg/p4-submit-catch-failure:
  git-p4: clean up after p4 submit failure

Make git-p4 work on a detached head.

* ld/p4-detached-head:
  git-p4: work with a detached head
  git-p4: add option to system() to return subshell status
  git-p4: add failing test for submit from detached head

When "p4 submit" command fails in P4Submit.applyCommit, the
workspace is left with the changes.  We already have code to revert
the changes to the workspace when the user decides to cancel
submission by aborting the editor that edits the change description,
and we should treat the "p4 submit" failure the same way.

Clean the workspace if p4_write_pipe raised SystemExit, so that the
user don't have to do it themselves.

Signed-off-by: GIRARD Etienne <egirard@murex.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Jeff King <peff@peff.net>

When submitting, git-p4 finds the current branch in
order to know if it is allowed to submit (configuration
"git-p4.allowSubmit").

On a detached head, detecting the branch would fail, and
git-p4 would report a cryptic error.

This change teaches git-p4 to recognise a detached head and
submit successfully.

Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Jeff King <peff@peff.net>

Add an optional parameter ignore_error to the git-p4 system()
function. If used, it will return the subshell exit status
rather than throwing an exception.

Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Jeff King <peff@peff.net>

Work around "git p4" failing when the P4 depot records the contents
in UTF-16 without UTF-16 BOM.

* ls/p4-translation-failure:
  git-p4: handle "Translation of file content failed"
  git-p4: add test case for "Translation of file content failed" error

Correct "git p4 --detect-labels" so that it does not fail to create
a tag that points at a commit that is also being imported.

* ld/p4-import-labels:
  git-p4: fix P4 label import for unprocessed commits
  git-p4: do not terminate creating tag for unknown commit
  git-p4: failing test for ignoring invalid p4 labels

A P4 repository can get into a state where it contains a file with
type UTF-16 that does not contain a valid UTF-16 BOM. If git-p4
attempts to retrieve the file then the process crashes with a
"Translation of file content failed" error.

More info here: http://answers.perforce.com/articles/KB/3117

Fix this by detecting this error and retrieving the file as binary
instead. The result in Git is the same.

Known issue: This works only if git-p4 is executed in verbose mode.
In normal mode no exceptions are thrown and git-p4 just exits.

Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

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 <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

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 <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>