git/t, branch v2.7.0

Merge branch 'sh/p4-multi-depot'

2015-12-28T21:58:58Z

"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

Merge branch 'jk/pending-keep-tag-name'

2015-12-28T21:58:04Z

History traversal with "git log --source" that starts with an annotated tag failed to report the tag as "source", due to an old regression in the command line parser back in v2.2 days. * jk/pending-keep-tag-name: revision.c: propagate tag names from pending array

Merge branch 'jk/symbolic-ref-maint'

2015-12-28T21:57:24Z

"git symbolic-ref" forgot to report a failure with its exit status. * jk/symbolic-ref-maint: t1401: test reflog creation for git-symbolic-ref symbolic-ref: propagate error code from create_symref()

t1401: test reflog creation for git-symbolic-ref

2015-12-21T20:06:31Z

The current code writes a reflog entry whenever we update a symbolic ref, but we never test that this is so. Let's add a test to make sure upcoming refactoring doesn't cause a regression. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

symbolic-ref: propagate error code from create_symref()

2015-12-21T20:03:03Z

If create_symref() fails, git-symbolic-ref will still exit with code 0, and our caller has no idea that the command did nothing. This appears to have been broken since the beginning of time (e.g., it is not a regression where create_symref() stopped calling die() or something similar). Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

git-p4: reduce number of server queries for fetches

2015-12-21T19:26:55Z

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 Signed-off-by: Luke Diamand Signed-off-by: Junio C Hamano

Merge branch 'bc/format-patch-null-from-line'

2015-12-21T18:59:08Z

"format-patch" has learned a new option to zero-out the commit object name on the mbox "From " line. * bc/format-patch-null-from-line: format-patch: check that header line has expected format format-patch: add an option to suppress commit hash sha1_file.c: introduce a null_oid constant

Merge branch 'mc/push-recurse-submodules-config'

2015-12-21T18:59:05Z

Add new config to avoid typing "--recurse-submodules" on each push. * mc/push-recurse-submodules-config: push: follow the "last one wins" convention for --recurse-submodules push: test that --recurse-submodules on command line overrides config push: add recurseSubmodules config option

revision.c: propagate tag names from pending array

2015-12-17T18:47:56Z

When we unwrap a tag to find its commit for a traversal, we do not propagate the "name" field of the tag in the pending array (i.e., the ref name the user gave us in the first place) to the commit (instead, we use an empty string). This means that "git log --source" will never show the tag-name for commits we reach through it. This was broken in 2073949 (traverse_commit_list: support pending blobs/trees with paths, 2014-10-15). That commit tried to be careful and avoid propagating the path information for a tag (which would be nonsensical) to trees and blobs. But it should not have cut off the "name" field, which should carry forward to children. Note that this does mean that the "name" field will carry forward to blobs and trees, too. Whereas prior to 2073949, we always gave them an empty string. This is the right thing to do, but in practice no callers probably use it (since now we have an explicit separate "path" field, which was the point of 2073949). We add tests here not only for the broken case, but also a basic sanity test of "log --source" in general, which did not have any coverage in the test suite. Reported-by: Raymundo Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'fr/rebase-i-continue-preserve-options'

2015-12-16T22:42:52Z

"git rebase -i" started with merge strategy options did not propagate them upon "git rebase --continue". * fr/rebase-i-continue-preserve-options: rebase -i: remember merge options beyond continue actions