summaryrefslogtreecommitdiff
path: root/t
AgeCommit message (Collapse)AuthorFilesLines
2016-05-05read_raw_ref(): don't get confused by an empty directoryLibravatar Michael Haggerty1-1/+1
Even if there is an empty directory where we look for the loose version of a reference, check for a packed reference before giving up. This fixes the failing test that was introduced two commits ago. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2016-05-05t1404: demonstrate a bug resolving referencesLibravatar Michael Haggerty1-1/+75
Add some tests checking that it is possible to work with a reference even if there is an empty directory where the loose ref would be stored. One of the new tests demonstrates a bug that has been with us since at least 2.5.0--single reference lookup gives up when it sees the directory, even if the reference exists as a packed ref. This probably hasn't been reported before because Git usually cleans up empty directories when packing references. This bug will be fixed shortly. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
2016-04-25Merge branch 'sb/submodule-path-misc-bugs'Libravatar Junio C Hamano2-5/+126
"git submodule" reports the paths of submodules the command recurses into, but this was incorrect when the command was not run from the root level of the superproject. * sb/submodule-path-misc-bugs: t7407: make expectation as clear as possible submodule update: test recursive path reporting from subdirectory submodule update: align reporting path for custom command execution submodule status: correct path handling in recursive submodules submodule update --init: correct path handling in recursive submodules submodule foreach: correct path display in recursive submodules
2016-04-25Merge branch 'en/merge-trivial-fix'Libravatar Junio C Hamano1-1/+5
When "git merge" notices that the merge can be resolved purely at the tree level (without having to merge blobs) and the resulting tree happens to already exist in the object store, it forgot to update the index, which lead to an inconsistent state for later operations. * en/merge-trivial-fix: builtin/merge.c: fix a bug with trivial merges t7605: add a testcase demonstrating a bug with trivial merges
2016-04-25Merge branch 'en/merge-octopus-fix'Libravatar Junio C Hamano1-0/+153
"merge-octopus" strategy did not ensure that the index is clean when merge begins. * en/merge-octopus-fix: merge-octopus: abort if index does not match HEAD t6044: new merge testcases for when index doesn't match HEAD
2016-04-25Merge branch 'dt/pre-refs-backend'Libravatar Junio C Hamano2-11/+131
Code restructuring around the "refs" area to prepare for pluggable refs backends. * dt/pre-refs-backend: (24 commits) refs: on symref reflog expire, lock symref not referrent refs: move resolve_ref_unsafe into common code show_head_ref(): check the result of resolve_ref_namespace() check_aliased_update(): check that dst_name is non-NULL checkout_paths(): remove unneeded flag variable cmd_merge(): remove unneeded flag variable fsck_head_link(): remove unneeded flag variable read_raw_ref(): change flags parameter to unsigned int files-backend: inline resolve_ref_1() into resolve_ref_unsafe() read_raw_ref(): manage own scratch space files-backend: break out ref reading resolve_ref_1(): eliminate local variable "bad_name" resolve_ref_1(): reorder code resolve_ref_1(): eliminate local variable resolve_ref_unsafe(): ensure flags is always set resolve_ref_unsafe(): use for loop to count up to MAXDEPTH resolve_missing_loose_ref(): simplify semantics t1430: improve test coverage of deletion of badly-named refs t1430: test for-each-ref in the presence of badly-named refs t1430: don't rely on symbolic-ref for creating broken symrefs ...
2016-04-25Merge branch 'jc/rerere-multi'Libravatar Junio C Hamano1-1/+169
"git rerere" can encounter two or more files with the same conflict signature that have to be resolved in different ways, but there was no way to record these separate resolutions. * jc/rerere-multi: rerere: adjust 'forget' to multi-variant world order rerere: split code to call ll_merge() further rerere: move code related to "forget" together rerere: gc and clear rerere: do use multiple variants t4200: rerere a merge with two identical conflicts rerere: allow multiple variants to exist rerere: delay the recording of preimage rerere: handle leftover rr-cache/$ID directory and postimage files rerere: scan $GIT_DIR/rr-cache/$ID when instantiating a rerere_id rerere: split conflict ID further
2016-04-22Merge branch 'jk/use-write-script-more'Libravatar Junio C Hamano3-18/+20
Code clean-up. * jk/use-write-script-more: t3404: use write_script t1020: do not overuse printf and use write_script t5532: use write_script
2016-04-22Merge branch 'ad/commit-have-m-option'Libravatar Junio C Hamano1-0/+20
"git commit" misbehaved in a few minor ways when an empty message is given via -m '', all of which has been corrected. * ad/commit-have-m-option: commit: do not ignore an empty message given by -m '' commit: --amend -m '' silently fails to wipe message
2016-04-22Merge branch 'sb/submodule-helper-clone-regression-fix'Libravatar Junio C Hamano1-0/+41
A partial rewrite of "git submodule" in the 2.7 timeframe changed the way the gitdir: pointer in the submodules point at the real repository location to use absolute paths by accident. This has been corrected. * sb/submodule-helper-clone-regression-fix: submodule--helper, module_clone: catch fprintf failure submodule--helper: do not borrow absolute_path() result for too long submodule--helper, module_clone: always operate on absolute paths submodule--helper clone: create the submodule path just once submodule--helper: fix potential NULL-dereference recursive submodules: test for relative paths
2016-04-18Merge branch 'jk/branch-shortening-funny-symrefs'Libravatar Junio C Hamano1-0/+12
A change back in version 2.7 to "git branch" broke display of a symbolic ref in a non-standard place in the refs/ hierarchy (we expect symbolic refs to appear in refs/remotes/*/HEAD to point at the primary branch the remote has, and as .git/HEAD to point at the branch we locally checked out). * jk/branch-shortening-funny-symrefs: branch: fix shortening of non-remote symrefs
2016-04-18Merge branch 'ky/branch-m-worktree'Libravatar Junio C Hamano1-1/+22
When "git worktree" feature is in use, "git branch -m" renamed a branch that is checked out in another worktree without adjusting the HEAD symbolic ref for the worktree. * ky/branch-m-worktree: set_worktree_head_symref(): fix error message branch -m: update all per-worktree HEADs refs: add a new function set_worktree_head_symref
2016-04-13Merge branch 'tb/blame-force-read-cache-to-workaround-safe-crlf'Libravatar Junio C Hamano1-0/+14
When running "git blame $path" with unnormalized data in the index for the path, the data in the working tree was blamed, even though "git add" would not have changed what is already in the index, due to "safe crlf" that disables the line-end conversion. It has been corrected. * tb/blame-force-read-cache-to-workaround-safe-crlf: correct blame for files commited with CRLF
2016-04-13Merge branch 'lt/pretty-expand-tabs'Libravatar Junio C Hamano2-1/+106
When "git log" shows the log message indented by 4-spaces, the remainder of a line after a HT does not align in the way the author originally intended. The command now expands tabs by default in such a case, and allows the users to override it with a new option, '--no-expand-tabs'. * lt/pretty-expand-tabs: pretty: test --expand-tabs pretty: allow tweaking tabwidth in --expand-tabs pretty: enable --expand-tabs by default for selected pretty formats pretty: expand tabs in indented logs to make things line up properly
2016-04-13Merge branch 'mj/pull-rebase-autostash'Libravatar Junio C Hamano1-7/+67
"git pull --rebase" learned "--[no-]autostash" option, so that the rebase.autostash configuration variable set to true can be overridden from the command line. * mj/pull-rebase-autostash: t5520: test --[no-]autostash with pull.rebase=true t5520: reduce commom lines of code t5520: factor out common "failing autostash" code t5520: factor out common "successful autostash" code t5520: use better test to check stderr output t5520: ensure consistent test conditions t5520: use consistent capitalization in test titles pull --rebase: add --[no-]autostash flag git-pull.c: introduce git_pull_config()
2016-04-13Merge branch 'sk/send-pack-all-fix'Libravatar Junio C Hamano1-0/+12
"git send-pack --all <there>" was broken when its command line option parsing was written in the 2.6 timeframe. * sk/send-pack-all-fix: git-send-pack: fix --all option when used with directory
2016-04-13Merge branch 'sg/diff-multiple-identical-renames'Libravatar Junio C Hamano1-0/+11
"git diff -M" used to work better when two originally identical files A and B got renamed to X/A and X/B by pairing A to X/A and B to X/B, but this was broken in the 2.0 timeframe. * sg/diff-multiple-identical-renames: diffcore: fix iteration order of identical files during rename detection
2016-04-13Merge branch 'ky/branch-d-worktree'Libravatar Junio C Hamano1-0/+6
When "git worktree" feature is in use, "git branch -d" allowed deletion of a branch that is checked out in another worktree * ky/branch-d-worktree: branch -d: refuse deleting a branch which is currently checked out
2016-04-13Merge branch 'rz/worktree-no-checkout'Libravatar Junio C Hamano1-0/+12
"git worktree add" can be given "--no-checkout" option to only create an empty worktree without checking out the files. * rz/worktree-no-checkout: worktree: add: introduce --checkout option
2016-04-12merge-octopus: abort if index does not match HEADLibravatar Elijah Newren1-3/+3
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-12t6044: new merge testcases for when index doesn't match HEADLibravatar Elijah Newren1-0/+153
With one exception, we require the index to exactly match the current HEAD commit at the time git merge is invoked. This expectation was even documented in git-merge.txt until commit ebef7e5 (Documentation: simplify How Merge Works, 2010-01-23). Most merge strategies enforced this requirement, but it turns out not all did. The current exceptions were the following two: * ff updates * octopus merges ff updates actually will error out if the staged change is to a path modified between HEAD and the commit being merged. If the path(s) that are staged are files unrelated to the changes between these two commits, though, then an ff update will just keep these staged changes around after the merge. This is the one exception we expected to the abort-merge-if- index-doesn't-match-HEAD rule. For octopus merges, the rule should be enforced. Unfortunately, the current behavior of the code is to ignore the difference and use the staged changes in place of whatever is in HEAD as it proceeds to perform the merge. So if the staged changes can be cleanly merged with all the other heads, then the staged changes will just be incorported into the resulting commit. If the staged changes cannot be cleanly merged with all the other heads, the merge is not aborted -- merge conflicts are simply reported as if HEAD had originally contained whatever the index did. Add testcases that check our expectations. A subsequent commit will correct the erroneous octopus merge behavior. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-12builtin/merge.c: fix a bug with trivial mergesLibravatar Elijah Newren1-1/+1
If read_tree_trivial() succeeds and produces a tree that is already in the object store, then the index is not written to disk, leaving it out-of-sync with both HEAD and the working tree. In order to write the index back out to disk after a merge, write_index_locked() needs to be called. For most merge strategies, this is done from try_merge_strategy(). For fast forward updates, this is done from checkout_fast_forward(). When trivial merges work, the call to write_index_locked() is buried a little deeper: merge_trivial() -> write_tree_trivial() -> write_cache_as_tree() -> write_index_as_tree() -> write_locked_index() However, it is only called when !cache_tree_fully_valid(), which is how this bug is triggered. But that also shows why this bug doesn't affect any other merge strategies or cases. Add a direct call to write_index_locked() from merge_trivial() to fix this issue. Since the indirect call to write_locked_index() was conditional on cache_tree_fully_valid(), it won't be written twice. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-12t7605: add a testcase demonstrating a bug with trivial mergesLibravatar Elijah Newren1-1/+5
Repeating a trivial merge more than once will leave the index out of sync, despite being clean before the merge and operating on the exact same heads as the first run. The recorded merge has the correct tree and the working tree is brought up to date, it is just the index that is left as it was before the merge. Every attempt to repeat the merge beyond the first will leave the index in the same weird out-of-sync state. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-12t3404: use write_scriptLibravatar Junio C Hamano1-4/+3
The test uses hardcoded #!/bin/sh to create a pre-commit hook script. Because the generated script uses $(command substitution), which is not supported by /bin/sh on some platforms (e.g. Solaris), the resulting pre-commit always fails. Which is not noticeable as the test that uses the hook is about checking the behaviour of the command when the hook fails ;-), but nevertheless it is not testing what we wanted to test. Use write_script so that the resulting script is run under the same shell our scripted Porcelain commands are run, which must support the necessary $(construct). Helped-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-11t1020: do not overuse printf and use write_scriptLibravatar Junio C Hamano1-5/+5
The test prepares a sample file "dir/two" with a single incomplete line in it with "printf", and also prepares a small helper script "diff" to create a file with a single incomplete line in it, again with "printf". The output from the latter is compared with an expected output, again prepared with "printf" hence lacking the final LF. There is no reason for this test to be using files with an incomplete line at the end, and these look more like a mistake of not using printf "%s\n" "string to be written" and using printf "string to be written" Depending on what would be in $GIT_PREFIX, using the latter form could be a bug waiting to happen. Correct them. Also, the test uses hardcoded #!/bin/sh to create a small helper script. For a small task like what the generated script does, it does not matter too much in that what appears as /bin/sh would not be _so_ broken, but while we are at it, use write_script instead, which happens to make the result easier to read by reducing need of one level of quoting. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10t5532: use write_scriptLibravatar Jeff King1-9/+12
The recent cleanup in b7cbbff switched t5532's use of backticks to $(). This matches our normal shell style, which is good. But it also breaks the test on Solaris, where /bin/sh does not understand $(). Our normal shell style assumes a modern-ish shell which knows about $(). However, some tests create small helper scripts and just write "#!/bin/sh" into them. These scripts either need to go back to using backticks, or they need to respect $SHELL_PATH. The easiest way to do the latter is to use write_script. While we're at it, let's also stick the script creation inside a test_expect block (our usual style), and split the perl snippet into its own script (to prevent quoting madness). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10refs: on symref reflog expire, lock symref not referrentLibravatar David Turner1-0/+10
When locking a symbolic ref to expire a reflog, lock the symbolic ref (using REF_NODEREF) instead of its referent. Add a test for this. Signed-off-by: David Turner <dturner@twopensource.com> Reviewed-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10t1430: improve test coverage of deletion of badly-named refsLibravatar Michael Haggerty1-8/+96
Check "branch -d broken...ref" Check various combinations of * Deleting using "update-ref -d" * Deleting using "update-ref --no-deref -d" * Deleting using "branch -d" in the following combinations of symref -> ref: * badname -> broken...ref * badname -> broken...ref (dangling) * broken...symref -> master * broken...symref -> idonotexist (dangling) Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10t1430: test for-each-ref in the presence of badly-named refsLibravatar Michael Haggerty1-0/+16
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10t1430: don't rely on symbolic-ref for creating broken symrefsLibravatar Michael Haggerty1-2/+2
It's questionable whether it should even work. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10t1430: clean up broken refs/tags/shadowLibravatar Michael Haggerty1-1/+1
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-10t1430: test the output and error of some commands more carefullyLibravatar Michael Haggerty1-6/+12
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: David Turner <dturner@twopensource.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-08Merge branch 'jc/merge-refuse-new-root'Libravatar Junio C Hamano10-11/+35
"git merge" used to allow merging two branches that have no common base by default, which led to a brand new history of an existing project created and then get pulled by an unsuspecting maintainer, which allowed an unnecessary parallel history merged into the existing project. The command has been taught not to allow this by default, with an escape hatch "--allow-unrelated-histories" option to be used in a rare event that merges histories of two projects that started their lives independently. * jc/merge-refuse-new-root: merge: refuse to create too cool a merge by default
2016-04-07commit: do not ignore an empty message given by -m ''Libravatar Jeff King1-3/+3
When f9568530 (builtin-commit: resurrect behavior for multiple -m options, 2007-11-11) converted a "char *message" to "struct strbuf message" to hold the messages given with the "-m" option, it incorrectly changed the checks "did we get a message with the -m option?" to "is message.len 0?". Later, we noticed one breakage from this change and corrected it with 25206778 (commit: don't start editor if empty message is given with -m, 2013-05-25). However, "we got a message with -m, even though an empty one, so we shouldn't be launching an editor" was not the only breakage. * "git commit --amend -m '' --allow-empty", even though it looks strange, is a valid request to amend the commit to have no message at all. Due to the misdetection of the presence of -m on the command line, we ended up keeping the log messsage from the original commit. * "git commit -m "$msg" -F file" should be rejected whether $msg is an empty string or not, but due to the same bug, was not rejected when $msg is empty. * "git -c template=file -m "$msg"" should ignore the template even when $msg is empty, but it didn't and instead used the contents from the template file. Correct these by checking have_option_m, which the earlier 25206778 introduced to fix the same bug. Reported-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-07commit: --amend -m '' silently fails to wipe messageLibravatar Adam Dinwoodie1-0/+20
`git commit --amend -m ''` seems to be an unambiguous request to blank a commit message, but it actually leaves the commit message as-is. That's the case regardless of whether `--allow-empty-message` is specified, and doesn't so much as drop a non-zero return code. Add failing tests to show this behaviour. Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-06rerere: adjust 'forget' to multi-variant world orderLibravatar Junio C Hamano1-0/+10
Because conflicts with the same contents inside conflict blocks enclosed by "<<<<<<<" and ">>>>>>>" can now have multiple variants to help three-way merge to adjust to the differences outside the conflict blocks, "rerere forget $path" needs to be taught that there may be multiple recorded resolutions that share the same conflict hash (which groups the conflicts with "the same contents inside conflict blocks"), among which there are some that would not be relevant to the conflict we are looking at. These "other variants" that happen to share the same conflict hash should not be cleared, and the variant that would apply to the current conflict may not be the zero-th one (which is the only one that is cleared by the current code). After finding the conflict hash, iterate over the existing variants and try to resolve the conflict using each of them to find the one that "cleanly" resolves the current conflict. That is the one we want to forget and record the preimage for, so that the user can record the corrected resolution. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-06rerere: gc and clearLibravatar Junio C Hamano1-6/+75
Adjust "git rerere gc" and "git rerere clear" to the new world order with rerere database with multiple variants for the same shape of conflicts. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-06Merge branch 'la/tag-force-signing-annotated-tags'Libravatar Junio C Hamano1-0/+41
"git tag" can create an annotated tag without explicitly given an "-a" (or "-s") option (i.e. when a tag message is given). A new configuration variable, tag.forceSignAnnotated, can be used to tell the command to create signed tag in such a situation. * la/tag-force-signing-annotated-tags: tag: add the option to force signing of annotated tags
2016-04-06Merge branch 'jk/submodule-c-credential'Libravatar Junio C Hamano3-0/+57
"git -c credential.<var>=<value> submodule" can now be used to propagate configuration variables related to credential helper down to the submodules. * jk/submodule-c-credential: git_config_push_parameter: handle empty GIT_CONFIG_PARAMETERS git: submodule honor -c credential.* from command line quote: implement sq_quotef() submodule: fix segmentation fault in submodule--helper clone submodule: fix submodule--helper clone usage submodule: check argc count for git submodule--helper clone submodule: don't pass empty string arguments to submodule--helper clone
2016-04-06Merge branch 'jv/merge-nothing-into-void'Libravatar Junio C Hamano1-0/+10
"git merge FETCH_HEAD" dereferenced NULL pointer when merging nothing into an unborn history (which is arguably unusual usage, which perhaps was the reason why nobody noticed it). * jv/merge-nothing-into-void: merge: fix NULL pointer dereference when merging nothing into void
2016-04-06Merge branch 'ss/commit-squash-msg'Libravatar Junio C Hamano1-0/+28
When "git merge --squash" stopped due to conflict, the concluding "git commit" failed to read in the SQUASH_MSG that shows the log messages from all the squashed commits. * ss/commit-squash-msg: commit: do not lose SQUASH_MSG contents
2016-04-06Merge branch 'sb/rebase-x'Libravatar Junio C Hamano1-13/+6
"git rebase -x" can be used without passing "-i" option. * sb/rebase-x: t3404: cleanup double empty lines between tests rebase: decouple --exec from --interactive
2016-04-06Merge branch 'jk/test-httpd-config-nosystem'Libravatar Junio C Hamano1-0/+1
The tests that involve running httpd leaked the system-wide configuration in /etc/gitconfig to the tested environment. * jk/test-httpd-config-nosystem: t/lib-httpd: pass through GIT_CONFIG_NOSYSTEM env
2016-04-06Merge branch 'sb/clone-t57-t56'Libravatar Junio C Hamano10-0/+0
Rename bunch of tests on "git clone" for better organization. * sb/clone-t57-t56: clone tests: rename t57* => t56*
2016-04-06Merge branch 'ls/p4-map-user'Libravatar Junio C Hamano1-0/+61
"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
2016-04-06Merge branch 'pb/t7502-drop-dup'Libravatar Junio C Hamano1-5/+0
Code clean-up. * pb/t7502-drop-dup: t/t7502 : drop duplicate test
2016-04-06Merge branch 'da/mergetool-delete-delete-conflict'Libravatar Junio C Hamano1-0/+64
"git mergetool" did not work well with conflicts that both sides deleted. * da/mergetool-delete-delete-conflict: mergetool: honor tempfile configuration when resolving delete conflicts mergetool: support delete/delete conflicts
2016-04-06Merge branch 'sb/submodule-parallel-update'Libravatar Junio C Hamano3-2/+43
A major part of "git submodule update" has been ported to C to take advantage of the recently added framework to run download tasks in parallel. * sb/submodule-parallel-update: clone: allow an explicit argument for parallel submodule clones submodule update: expose parallelism to the user submodule helper: remove double 'fatal: ' prefix git submodule update: have a dedicated helper for cloning run_processes_parallel: rename parameters for the callbacks run_processes_parallel: treat output of children as byte array submodule update: direct error message to stderr fetching submodules: respect `submodule.fetchJobs` config option submodule-config: drop check against NULL submodule-config: keep update strategy around
2016-04-05correct blame for files commited with CRLFLibravatar Torsten Bögershausen1-0/+14
git blame reports lines as not "Not Committed Yet" when they have CRLF in the index, CRLF in the worktree and core.autocrlf is true. Since commit c4805393 (autocrlf: Make it work also for un-normalized repositories, 2010-05-12), files that have CRLF in the index are not normalized at commit when core.autocrl is set. Add a call to read_cache() early in fake_working_tree_commit(), before calling convert_to_git(). Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-04-04branch: fix shortening of non-remote symrefsLibravatar Jeff King1-0/+12
Commit aedcb7d (branch.c: use 'ref-filter' APIs, 2015-09-23) adjusted the symref-printing code to look like this: if (item->symref) { skip_prefix(item->symref, "refs/remotes/", &desc); strbuf_addf(&out, " -> %s", desc); } This has three bugs in it: 1. It always skips past "refs/remotes/", instead of skipping past the prefix associated with the branch we are showing (so commonly we see "refs/remotes/" for the refs/remotes/origin/HEAD symref, but the previous code would skip "refs/heads/" when showing a symref it found in refs/heads/. 2. If skip_prefix() does not match, it leaves "desc" untouched, and we show whatever happened to be in it (which is the refname from a call to skip_prefix() earlier in the function). 3. If we do match with skip_prefix(), we stomp on the "desc" variable, which is later passed to add_verbose_info(). We probably want to retain the original refname there (though it likely doesn't matter in practice, since after all, one points to the other). The fix to match the original code is fairly easy: record the prefix to strip based on item->kind, and use it here. However, since we already have a local variable named "prefix", let's give the two prefixes verbose names so we don't confuse them. Signed-off-by: Jeff King <peff@peff.net> Acked-by: Karthik Nayak <karthik.188@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>