`EDITOR` environment variables and then finally `vi`.
core.pager::
- The command that git will use to paginate output. Can be overridden
- with the `GIT_PAGER` environment variable.
+ The command that git will use to paginate output. Can
+ be overridden with the `GIT_PAGER` environment
+ variable. Note that git sets the `LESS` environment
+ variable to `FRSX` if it is unset when it runs the
+ pager. One can change these settings by setting the
+ `LESS` variable to some other value or by giving the
+ `core.pager` option a value such as "`less -+FRSX`".
core.whitespace::
A comma separated list of common whitespace problems to
linkgit:git-repack[1].
pager.<cmd>::
- Allows to set your own pager preferences for each command, overriding
- the default. If `\--pager` or `\--no-pager` is specified on the command
- line, it takes precedence over this option.
+ Allows turning on or off pagination of the output of a
+ particular git subcommand when writing to a tty. If
+ `\--paginate` or `\--no-pager` is specified on the command line,
+ it takes precedence over this option. To disable pagination for
+ all commands, set `core.pager` or 'GIT_PAGER' to "`cat`".
pull.octopus::
The default merge strategy to use when pulling multiple branches
'GIT_PAGER'::
This environment variable overrides `$PAGER`. If it is set
to an empty string or to the value "cat", git will not launch
- a pager.
+ a pager. See also the `core.pager` option in
+ linkgit:git-config[1].
'GIT_SSH'::
If this environment variable is set then 'git-fetch'
NO_UNSETENV = YesPlease
NO_HSTRERROR = YesPlease
NO_SYS_SELECT_H = YesPlease
+ SNPRINTF_RETURNS_BOGUS = YesPlease
endif
ifneq (,$(findstring MINGW,$(uname_S)))
NO_MMAP = YesPlease
struct dir_struct dir;
struct lock_file *lock_file = xcalloc(1, sizeof(struct lock_file));
- if (read_cache_unmerged())
- die("you need to resolve your current index first");
refresh_cache(REFRESH_QUIET);
fd = hold_locked_index(lock_file, 1);
static int merge_trivial(void)
{
unsigned char result_tree[20], result_commit[20];
- struct commit_list parent;
+ struct commit_list *parent = xmalloc(sizeof(struct commit_list *));
write_tree_trivial(result_tree);
printf("Wonderful.\n");
- parent.item = remoteheads->item;
- parent.next = NULL;
- commit_tree(merge_msg.buf, result_tree, &parent, result_commit);
+ parent->item = lookup_commit(head);
+ parent->next = xmalloc(sizeof(struct commit_list *));
+ parent->next->item = remoteheads->item;
+ parent->next->next = NULL;
+ commit_tree(merge_msg.buf, result_tree, parent, result_commit);
finish(result_commit, "In-index merge");
drop_save();
return 0;
int cnt = 0;
struct rev_info rev;
+ discard_cache();
if (read_cache() < 0)
die("failed to read the cache");
struct commit_list **remotes = &remoteheads;
setup_work_tree();
- if (unmerged_cache())
+ if (read_cache_unmerged())
die("You are in the middle of a conflicted merge.");
/*
}
/* Automerge succeeded. */
+ discard_cache();
write_tree_trivial(result_tree);
automerge_was_ok = 1;
break;
Usage
=====
-git-p4 supports two main modes: Importing from Perforce to a Git repository is
-done using "git-p4 sync" or "git-p4 rebase". Submitting changes from Git back
-to Perforce is done using "git-p4 submit".
+git-p4 can be used in two different ways:
+
+1) To import changes from Perforce to a Git repository, using "git-p4 sync".
+
+2) To submit changes from Git back to Perforce, using "git-p4 submit".
Importing
=========
-You can simply start with
+Simply start with
git-p4 clone //depot/path/project
git-p4 clone //depot/path/project myproject
-This will create an empty git repository in a subdirectory called "project" (or
-"myproject" with the second command), import the head revision from the
-specified perforce path into a git "p4" branch (remotes/p4 actually), create a
-master branch off it and check it out. If you want the entire history (not just
-the head revision) then you can simply append a "@all" to the depot path:
+This will:
+
+1) Create an empty git repository in a subdirectory called "project" (or
+"myproject" with the second command)
+
+2) Import the head revision from the given Perforce path into a git branch
+called "p4" (remotes/p4 actually)
+
+3) Create a master branch based on it and check it out.
+
+If you want the entire history (not just the head revision) then you can simply
+append a "@all" to the depot path:
git-p4 clone //depot/project/main@all myproject
This will import the current head revision of the specified depot path into a
"remotes/p4/master" branch of your git repository. You can use the
---branch=mybranch option to use a different branch.
+--branch=mybranch option to import into a different branch.
-If you want to import the entire history of a given depot path just use
+If you want to import the entire history of a given depot path simply use:
git-p4 sync //path/in/depot@all
+
+Note:
+
To achieve optimal compression you may want to run 'git repack -a -d -f' after
a big import. This may take a while.
-Support for Perforce integrations is still work in progress. Don't bother
-trying it unless you want to hack on it :)
-
Incremental Imports
===================
-After an initial import you can easily synchronize your git repository with
-newer changes from the Perforce depot by just calling
+After an initial import you can continue to synchronize your git repository
+with newer changes from the Perforce depot by just calling
git-p4 sync
in your git repository. By default the "remotes/p4/master" branch is updated.
-It is recommended to run 'git repack -a -d -f' from time to time when using
-incremental imports to optimally combine the individual git packs that each
-incremental import creates through the use of git-fast-import.
+Advanced Setup
+==============
+
+Suppose you have a periodically updated git repository somewhere, containing a
+complete import of a Perforce project. This repository can be cloned and used
+with git-p4. When updating the cloned repository with the "sync" command,
+git-p4 will try to fetch changes from the original repository first. The git
+protocol used with this is usually faster than importing from Perforce
+directly.
+
+This behaviour can be disabled by setting the "git-p4.syncFromOrigin" git
+configuration variable to "false".
Updating
========
==========
git-p4 has support for submitting changes from a git repository back to the
-Perforce depot. This requires a Perforce checkout separate to your git
+Perforce depot. This requires a Perforce checkout separate from your git
repository. To submit all changes that are in the current git branch but not in
the "p4" branch (or "origin" if "p4" doesn't exist) simply call
git-p4 submit --continue
-After submitting you should sync your perforce import branch ("p4" or "origin")
-from Perforce using git-p4's sync command.
-
-If you have changes in your working directory that you haven't committed into
-git yet but that you want to commit to Perforce directly ("quick fixes") then
-you do not have to go through the intermediate step of creating a git commit
-first but you can just call
-
- git-p4 submit --direct
-
-
Example
=======
'
+test_expect_success 'fail if the index has unresolved entries' '
+
+ rm -fr [abcd] &&
+ git checkout -f "$c1" &&
+
+ test_must_fail git merge "$c5" &&
+ test_must_fail git merge "$c5" 2> out &&
+ grep "You are in the middle of a conflicted merge" out
+
+'
+
test_expect_success 'merge-recursive remove conflict' '
rm -fr [abcd] &&
test_debug 'gitk --all'
+test_expect_success 'in-index merge' '
+ git reset --hard c0 &&
+ git merge --no-ff -s resolve c1 > out &&
+ grep "Wonderful." out &&
+ verify_parents $c0 $c1
+'
+
+test_debug 'gitk --all'
+
test_done
git diff --exit-code &&
test -f c0.c &&
test -f c1.c &&
- test -f c2.c
+ test -f c2.c &&
+ test 3 = $(git ls-tree -r HEAD | wc -l) &&
+ test 3 = $(git ls-files | wc -l)
'
test_expect_success 'merge c2 to c3 (fails)' '