Recent update to Git LFS broke "git p4" by changing the output from
its "lfs pointer" subcommand.

* ls/p4-lfs:
  git-p4: fix Git LFS pointer parsing
  travis-ci: express Linux/OS X dependency versions more clearly
  travis-ci: update Git-LFS and P4 to the latest version

Git LFS 1.2.0 removed a preamble from the output of the 'git lfs pointer'
command [1] which broke the parsing of this output. Adjust the parser
to support the old and the new format.

Please note that this patch slightly changes the second return parameter
from a list of LF terminated strings to a single string that contains
a number of LF characters.

[1] https://github.com/github/git-lfs/commit/da2935d9a739592bc775c98d8ef4df9c72ea3b43

Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Helped-by: Sebastian Schuberth <sschuberth@gmail.com>
Helped-by: Ben Woosley <ben.woosley@gmail.com>
Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

When migrating from Perforce to git the information about P4 jobs
associated with P4 changelists is lost.

Having these jobs listed on messages of related git commits enables smooth
migration for projects that take advantage of e.g. JIRA integration
(which uses jobs on Perforce side and parses commit messages on git side).

The jobs are added to the message in the same format as is expected when
migrating in the reverse direction.

Signed-off-by: Jan Durovec <jan.durovec@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

"git p4" now allows P4 author names to be mapped to Git author
names.

* ls/p4-map-user:
  git-p4: map a P4 user to Git author name and email address

Map a P4 user to a specific name and email address in Git with the
"git-p4.mapUser" config. The config value must be a string adhering
to the format "p4user = First Lastname <email@address.com>".

Signed-off-by: Lars Schneider <larsxschneider@gmail.com>
Reviewed-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

After changing the type of a file in the git repository, it is not possible to
"git p4 publish" the commit to perforce. This is due to the fact that the git
"T" status is not handled in git-p4.py. This can typically occur when replacing
an existing file with a symbolic link.

The "T" modifier is now supported in git-p4.py. When a file type has changed,
inform perforce with the "p4 edit -f auto" command.

Signed-off-by: Romain Picard <romain.picard@oakbits.com>
Acked-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

"git p4" when interacting with multiple depots at the same time
used to incorrectly drop changes.

* sh/p4-multi-depot:
  git-p4: reduce number of server queries for fetches
  git-p4: support multiple depot paths in p4 submit
  git-p4: failing test case for skipping changes with multiple depots

When fetching changes from a depot using a full client spec, there
is no need to perform as many queries as there are top-level paths
in the client spec.  Instead we query all changes in chronological
order, also getting rid of the need to sort the results and remove
duplicates.

Signed-off-by: Sam Hocevar <sam@hocevar.net>
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

When submitting from a repository that was cloned using a client spec,
use the full list of paths when ruling out files that are outside the
view.  This fixes a bug where only files pertaining to the first path
would be included in the p4 submit.

Signed-off-by: Sam Hocevar <sam@hocevar.net>
Signed-off-by: Luke Diamand <luke@diamand.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>

"git p4" used to import Perforce CLs that touch only paths outside
the client spec as empty commits.  It has been corrected to ignore
them instead, with a new configuration git-p4.keepEmptyCommits as a
backward compatibility knob.

* ls/p4-keep-empty-commits:
  git-p4: add option to keep empty commits