summaryrefslogtreecommitdiff
path: root/builtin/branch.c
AgeCommit message (Collapse)AuthorFilesLines
2021-09-27ref-filter: stop setting FILTER_REFS_INCLUDE_BROKENLibravatar Jeff King1-1/+1
Of the ref-filter callers, for-each-ref and git-branch both set the INCLUDE_BROKEN flag (but git-tag does not, which is a weird inconsistency). But now that GIT_REF_PARANOIA is on by default, that produces almost the same outcome for all three. The one exception is that GIT_REF_PARANOIA will omit dangling symrefs. That's a better behavior for these tools, as they would never include such a symref in the main output anyway (they can't, as it doesn't point to an object). Instead they issue a warning to stderr. But that warning is somewhat useless; a dangling symref is a perfectly reasonable thing to have in your repository, and is not a sign of corruption. It's much friendlier to just quietly ignore it. And in terms of robustness, the warning gains us little. It does not impact the exit code of either tool. So while the warning _might_ clue in a user that they have an unexpected broken symref, it would not help any kind of scripted use. This patch converts for-each-ref and git-branch to stop using the INCLUDE_BROKEN flag. That gives them more reasonable behavior, and harmonizes them with git-tag. We have to change one test to adapt to the situation. t1430 tries to trigger all of the REF_ISBROKEN behaviors from the underlying ref code. It uses for-each-ref to do so (because there isn't any other mechanism). That will no longer issue a warning about the symref which points to an invalid name, as it's considered dangling (and we can instead be sure that it's _not_ mentioned on stderr). Note that we do still complain about the illegally named "broken..symref"; its problem is not that it's dangling, but the name of the symref itself is illegal. Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-27branch: allow deleting dangling branches with --forceLibravatar René Scharfe1-1/+1
git branch only allows deleting branches that point to valid commits. Skip that check if --force is given, as the caller is indicating with it that they know what they are doing and accept the consequences. This allows deleting dangling branches, which previously had to be reset to a valid start-point using --force first. Reported-by: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-04-20ref-filter: reuse output bufferLibravatar ZheNing Hu1-4/+6
When we use `git for-each-ref`, every ref will allocate its own output strbuf and error strbuf. But we can reuse the final strbuf for each step ref's output. The error buffer will also be reused, despite the fact that the git will exit when `format_ref_array_item()` return a non-zero value and output the contents of the error buffer. The performance for `git for-each-ref` on the Git repository itself with performance testing tool `hyperfine` changes from 23.7 ms ± 0.9 ms to 22.2 ms ± 1.0 ms. Optimization is relatively minor. At the same time, we apply this optimization to `git tag -l` and `git branch -l`. This approach is similar to the one used by 79ed0a5 (cat-file: use a single strbuf for all output, 2018-08-14) to speed up the cat-file builtin. Helped-by: Junio C Hamano <gitster@pobox.com> Helped-by: Jeff King <peff@peff.net> Helped-by: René Scharfe <l.s.r@web.de> Signed-off-by: ZheNing Hu <adlternative@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-02-05Merge branch 'ph/use-delete-refs'Libravatar Junio C Hamano1-19/+28
When removing many branches and tags, the code used to do so one ref at a time. There is another API it can use to delete multiple refs, and it makes quite a lot of performance difference when the refs are packed. * ph/use-delete-refs: use delete_refs when deleting tags or branches
2021-01-21use delete_refs when deleting tags or branchesLibravatar Phil Hord1-19/+28
'git tag -d' accepts one or more tag refs to delete, but each deletion is done by calling `delete_ref` on each argv. This is very slow when removing from packed refs. Use delete_refs instead so all the removals can be done inside a single transaction with a single update. Do the same for 'git branch -d'. Since delete_refs performs all the packed-refs delete operations inside a single transaction, if any of the deletes fail then all them will be skipped. In practice, none of them should fail since we verify the hash of each one before calling delete_refs, but some network error or odd permissions problem could have different results after this change. Also, since the file-backed deletions are not performed in the same transaction, those could succeed even when the packed-refs transaction fails. After deleting branches, remove the branch config only if the branch ref was removed and was not subsequently added back in. A manual test deleting 24,000 tags took about 30 minutes using delete_ref. It takes about 5 seconds using delete_refs. Acked-by: Elijah Newren <newren@gmail.com> Signed-off-by: Phil Hord <phil.hord@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-07branch: sort detached HEAD based on a flagLibravatar Ævar Arnfjörð Bjarmason1-0/+2
Change the ref-filter sorting of detached HEAD to check the FILTER_REFS_DETACHED_HEAD flag, instead of relying on the ref description filled-in by get_head_description() to start with "(", which in turn we expect to ASCII-sort before any other reference. For context, we'd like the detached line to appear first at the start of "git branch -l", e.g.: $ git branch -l * (HEAD detached at <hash>) master This doesn't change that, but improves on a fix made in 28438e84e04 (ref-filter: sort detached HEAD lines firstly, 2019-06-18) and gives the Chinese translation the ability to use its preferred punctuation marks again. In Chinese the fullwidth versions of punctuation like "()" are typically written as (U+FF08 fullwidth left parenthesis), (U+FF09 fullwidth right parenthesis) instead[1]. This form is used in both po/zh_{CN,TW}.po in most cases where "()" is translated in a string. Aside from that improvement to the Chinese translation, it also just makes for cleaner code that we mark any special cases in the ref_array we're sorting with flags and make the sort function aware of them, instead of piggy-backing on the general-case of strcmp() doing the right thing. As seen in the amended tests this made reverse sorting a bit more consistent. Before this we'd sometimes sort this message in the middle, now it's consistently at the beginning or end, depending on whether we're doing a normal or reverse sort. Having it at the end doesn't make much sense either, but at least it behaves consistently now. A follow-up commit will make this behavior under reverse sorting even better. I'm removing the "TRANSLATORS" comments that were in the old code while I'm at it. Those were added in d4919bb288e (ref-filter: move get_head_description() from branch.c, 2017-01-10). I think it's obvious from context, string and translation memory in typical translation tools that these are the same or similar string. 1. https://en.wikipedia.org/wiki/Chinese_punctuation#Marks_similar_to_European_punctuation Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-07ref-filter: move ref_sorting flags to a bitfieldLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Change the reverse/ignore_case/version sort flags in the ref_sorting struct into a bitfield. Having three of them was already a bit unwieldy, but it would be even more so if another flag needed a function like ref_sorting_icase_all() introduced in 76f9e569adb (ref-filter: apply --ignore-case to all sorting keys, 2020-05-03). A follow-up change will introduce such a flag, so let's move this over to a bitfield. Instead of using the usual '#define' pattern I'm using the "enum" pattern from builtin/rebase.c's b4c8eb024af (builtin rebase: support --quiet, 2018-09-04). Perhaps there's a more idiomatic way of doing the "for each in list amend mask" pattern than this "mask/on" variable combo. This function doesn't allow us to e.g. do any arbitrary changes to the bitfield for multiple flags, but I think in this case that's fine. The common case is that we're calling this with a list of one. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-01-06branch: change "--local" to "--list" in commentLibravatar Ævar Arnfjörð Bjarmason1-1/+1
There has never been a "git branch --local", this is just a typo for "--list". Fixes a comment added in 23e714df91c (branch: roll show_detached HEAD into regular ref_list, 2015-09-23). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-12-18Merge branch 'js/init-defaultbranch-advice'Libravatar Junio C Hamano1-1/+3
Our users are going to be trained to prepare for future change of init.defaultBranch configuration variable. * js/init-defaultbranch-advice: init: provide useful advice about init.defaultBranch get_default_branch_name(): prepare for showing some advice branch -m: allow renaming a yet-unborn branch init: document `init.defaultBranch` better
2020-12-13branch -m: allow renaming a yet-unborn branchLibravatar Johannes Schindelin1-1/+3
In one of the next commits, we would like to give users some advice regarding the initial branch name, and how to modify it. To that end, it would be good if `git branch -m <name>` worked in a freshly initialized repository without any commits. Let's make it so. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-11-25config: convert multi_replace to flagsLibravatar Derrick Stolee1-2/+2
We will extend the flexibility of the config API. Before doing so, let's take an existing 'int multi_replace' parameter and replace it with a new 'unsigned flags' parameter that can take multiple options as a bit field. Update all callers that specified multi_replace to now specify the CONFIG_FLAGS_MULTI_REPLACE flag. To add more clarity, extend the documentation of git_config_set_multivar_in_file() including a clear labeling of its arguments. Other config API methods in config.h require only a change of the final parameter from 'int' to 'unsigned'. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-09-16ref-filter: allow merged and no-merged filtersLibravatar Aaron Lipman1-3/+3
Enable ref-filter to process multiple merged and no-merged filters, and extend functionality to git branch, git tag and git for-each-ref. This provides an easy way to check for branches that are "graduation candidates:" $ git branch --no-merged master --merged next If passed more than one merged (or more than one no-merged) filter, refs must be reachable from any one of the merged commits, and reachable from none of the no-merged commits. Signed-off-by: Aaron Lipman <alipman88@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-07-06Merge branch 'es/get-worktrees-unsort'Libravatar Junio C Hamano1-1/+1
API cleanup for get_worktrees() * es/get-worktrees-unsort: worktree: drop get_worktrees() unused 'flags' argument worktree: drop get_worktrees() special-purpose sorting option
2020-06-25Merge branch 'dl/branch-cleanup'Libravatar Junio C Hamano1-1/+1
Code clean-up around "git branch" with a minor bugfix. * dl/branch-cleanup: branch: don't mix --edit-description t3200: test for specific errors t3200: rename "expected" to "expect"
2020-06-22worktree: drop get_worktrees() unused 'flags' argumentLibravatar Eric Sunshine1-1/+1
get_worktrees() accepts a 'flags' argument, however, there are no existing flags (the lone flag GWT_SORT_LINKED was recently retired) and no behavior which can be tweaked. Therefore, drop the 'flags' argument. Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-06-17branch: don't mix --edit-descriptionLibravatar Denton Liu1-1/+1
`git branch` accepts `--edit-description` in conjunction with other arguments. However, `--edit-description` is its own mode, similar to `--set-upstream-to`, which is also made mutually exclusive with other modes. Prevent `--edit-description` from being mixed with other modes. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-05-08Merge branch 'jk/for-each-ref-multi-key-sort-fix'Libravatar Junio C Hamano1-1/+1
"git branch" and other "for-each-ref" variants accepted multiple --sort=<key> options in the increasing order of precedence, but it had a few breakages around "--ignore-case" handling, and tie-breaking with the refname, which have been fixed. * jk/for-each-ref-multi-key-sort-fix: ref-filter: apply fallback refname sort only after all user sorts ref-filter: apply --ignore-case to all sorting keys
2020-05-04ref-filter: apply --ignore-case to all sorting keysLibravatar Jeff King1-1/+1
All of the ref-filter users (for-each-ref, branch, and tag) take an --ignore-case option which makes filtering and sorting case-insensitive. However, this option was applied only to the first element of the ref_sorting list. So: git for-each-ref --ignore-case --sort=refname would do what you expect, but: git for-each-ref --ignore-case --sort=refname --sort=taggername would sort the primary key (taggername) case-insensitively, but sort the refname case-sensitively. We have two options here: - teach callers to set ignore_case on the whole list - replace the ref_sorting list with a struct that contains both the list of sorting keys, as well as options that apply to _all_ keys I went with the first one here, as it gives more flexibility if we later want to let the users set the flag per-key (presumably through some special syntax when defining the key; for now it's all or nothing through --ignore-case). The new test covers this by sorting on both tagger and subject case-insensitively, which should compare "a" and "A" identically, but still sort them before "b" and "B". We'll break ties by sorting on the refname to give ourselves a stable output (this is actually supposed to be done automatically, but there's another bug which will be fixed in the next commit). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2020-04-28Use OPT_CALLBACK and OPT_CALLBACK_FLibravatar Denton Liu1-4/+2
In the codebase, there are many options which use OPTION_CALLBACK in a plain ol' struct definition. However, we have the OPT_CALLBACK and OPT_CALLBACK_F macros which are meant to abstract these plain struct definitions away. These macros are useful as they semantically signal to developers that these are just normal callback option with nothing fancy happening. Replace plain struct definitions of OPTION_CALLBACK with OPT_CALLBACK or OPT_CALLBACK_F where applicable. The heavy lifting was done using the following (disgusting) shell script: #!/bin/sh do_replacement () { tr '\n' '\r' | sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\s*0,\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK(\1,\2,\3,\4,\5,\6)/g' | sed -e 's/{\s*OPTION_CALLBACK,\s*\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\([^,]*\),\(\s*[^[:space:]}]*\)\s*}/OPT_CALLBACK_F(\1,\2,\3,\4,\5,\6,\7)/g' | tr '\r' '\n' } for f in $(git ls-files \*.c) do do_replacement <"$f" >"$f.tmp" mv "$f.tmp" "$f" done The result was manually inspected and then reformatted to match the style of the surrounding code. Finally, using `git grep OPTION_CALLBACK \*.c`, leftover results which were not handled by the script were manually transformed. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-09l10n: minor case fix in 'git branch' '--unset-upstream' descriptionLibravatar Dimitriy Ryazantcev1-1/+1
Signed-off-by: Dimitriy Ryazantcev <dimitriy.ryazantcev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-07-09Merge branch 'po/doc-branch'Libravatar Junio C Hamano1-1/+2
Doc update. * po/doc-branch: doc branch: provide examples for listing remote tracking branches
2019-07-09Merge branch 'nb/branch-show-other-worktrees-head'Libravatar Junio C Hamano1-4/+12
"git branch --list" learned to show branches that are checked out in other worktrees connected to the same repository prefixed with '+', similar to the way the currently checked out branch is shown with '*' in front. * nb/branch-show-other-worktrees-head: branch: add worktree info on verbose output branch: update output to include worktree info ref-filter: add worktreepath atom
2019-05-29doc branch: provide examples for listing remote tracking branchesLibravatar Philip Oakley1-1/+2
The availability of these pattern selections is not obvious from the man pages, as per mail thread <87lfz3vcbt.fsf@evledraar.gmail.com>. Provide examples. Re-order the `git branch` synopsis to emphasise the `--list <pattern>` pairing. Also expand and reposition the `all/remotes` options. Split the over-long description into three parts so that the <pattern> description can be seen. Clarify that the `all/remotes` options require the --list if patterns are to be used. Add examples of listing remote tracking branches that match a pattern, including `git for-each-ref` which has more options. Improve the -a/-r warning message. The message confused this author as the combined -a and -r options had not been given, though a pattern had. Specifically guide the user that maybe they needed the --list option to enable a remote branch pattern selection. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-07branch: add worktree info on verbose outputLibravatar Nickolai Belakovski1-0/+4
To display worktree path for refs checked out in a linked worktree Signed-off-by: Nickolai Belakovski <nbelakovski@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-05-07branch: update output to include worktree infoLibravatar Nickolai Belakovski1-4/+8
The output of git branch is modified to mark branches checked out in a linked worktree with a "+" and color them in cyan (in contrast to the current branch, which will still be denoted with a "*" and colored in green) This is meant to communicate to the user that the branches that are marked or colored will behave differently from other branches if the user attempts to check them out or delete them, since branches checked out in another worktree cannot be checked out or deleted. Signed-off-by: Nickolai Belakovski <nbelakovski@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-21parse_opt_ref_sorting: always use with NONEG flagLibravatar Jeff King1-2/+1
The "--sort" parameter of for-each-ref, etc, does not handle negation, and instead returns an error to the parse-options code. But neither piece of code prints anything for the user, which may leave them confused: $ git for-each-ref --no-sort $ echo $? 129 As the comment in the callback function notes, this probably should clear the list, which would make it consistent with other list-like options (i.e., anything that uses OPT_STRING_LIST currently). Unfortunately that's a bit tricky due to the way the ref-filter code works. But in the meantime, let's at least make the error a little less confusing: - switch to using PARSE_OPT_NONEG in the option definition, which will cause the options code to produce a useful message - since this was cut-and-pasted to four different spots, let's define a single OPT_REF_SORT() macro that we can use everywhere - the callback can use BUG_ON_OPT_NEG() to make sure the correct flags are used (incidentally, this also satisfies -Wunused-parameters, since we're now looking at "unset") - expand the comment into a NEEDSWORK to make it clear that the direction is right, but the details need to be worked out Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-03-07Merge branch 'du/branch-show-current'Libravatar Junio C Hamano1-2/+23
"git branch" learned a new subcommand "--show-current". * du/branch-show-current: branch: introduce --show-current display option
2018-11-12branch.c: remove the_repository referenceLibravatar Nguyễn Thái Ngọc Duy1-2/+4
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-30Merge branch 'tq/branch-style-fix'Libravatar Junio C Hamano1-2/+1
Code clean-up. * tq/branch-style-fix: branch: trivial style fix
2018-10-30Merge branch 'tq/branch-create-wo-branch-get'Libravatar Junio C Hamano1-5/+0
Code clean-up. * tq/branch-create-wo-branch-get: builtin/branch.c: remove useless branch_get
2018-10-26branch: introduce --show-current display optionLibravatar Daniels Umanovskis1-2/+23
When called with --show-current, git branch will print the current branch name and terminate. Only the actual name gets printed, without refs/heads. In detached HEAD state, nothing is output. Intended both for scripting and interactive/informative use. Unlike git branch --list, no filtering is needed to just get the branch name. Signed-off-by: Daniels Umanovskis <daniels@umanovskis.se> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-18branch: trivial style fixLibravatar Tao Qingyun1-2/+1
Signed-off-by: Tao Qingyun <taoqy@ls-a.me> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-10-18builtin/branch.c: remove useless branch_getLibravatar Tao Qingyun1-5/+0
branch_get sometimes returns current_branch, which can be NULL (e.g., if you're on a detached HEAD). Try: $ git branch HEAD fatal: no such branch 'HEAD' $ git branch '' fatal: no such branch '' However, it seems weird that we'd check those cases here (and provide such lousy messages). And indeed, dropping that and letting us eventually hit create_branch() gives a much better message: $ git branch HEAD fatal: 'HEAD' is not a valid branch name. $ git branch '' fatal: '' is not a valid branch name. Signed-off-by: Tao Qingyun <taoqy@ls-a.me> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-09-17Merge branch 'ds/reachable'Libravatar Junio C Hamano1-0/+1
The code for computing history reachability has been shuffled, obtained a bunch of new tests to cover them, and then being improved. * ds/reachable: commit-reach: correct accidental #include of C file commit-reach: use can_all_from_reach commit-reach: make can_all_from_reach... linear commit-reach: replace ref_newer logic test-reach: test commit_contains test-reach: test can_all_from_reach_with_flags test-reach: test reduce_heads test-reach: test get_merge_bases_many test-reach: test is_descendant_of test-reach: test in_merge_bases test-reach: create new test tool for ref_newer commit-reach: move can_all_from_reach_with_flags upload-pack: generalize commit date cutoff upload-pack: refactor ok_to_give_up() upload-pack: make reachable() more generic commit-reach: move commit_contains from ref-filter commit-reach: move ref_newer from remote.c commit.h: remove method declarations commit-reach: move walk methods from commit.c
2018-09-17Merge branch 'jk/branch-l-1-repurpose'Libravatar Junio C Hamano1-21/+1
Updated plan to repurpose the "-l" option to "git branch". * jk/branch-l-1-repurpose: doc/git-branch: remove obsolete "-l" references branch: make "-l" a synonym for "--list"
2018-08-16branch: support configuring --sort via .gitconfigLibravatar Samuel Maftoul1-1/+9
Add support for configuring default sort ordering for git branches. Command line option will override this configured value, using the exact same syntax. Signed-off-by: Samuel Maftoul <samuel.maftoul@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-02Merge branch 'sb/object-store-lookup'Libravatar Junio C Hamano1-3/+4
lookup_commit_reference() and friends have been updated to find in-core object for a specific in-core repository instance. * sb/object-store-lookup: (32 commits) commit.c: allow lookup_commit_reference to handle arbitrary repositories commit.c: allow lookup_commit_reference_gently to handle arbitrary repositories tag.c: allow deref_tag to handle arbitrary repositories object.c: allow parse_object to handle arbitrary repositories object.c: allow parse_object_buffer to handle arbitrary repositories commit.c: allow get_cached_commit_buffer to handle arbitrary repositories commit.c: allow set_commit_buffer to handle arbitrary repositories commit.c: migrate the commit buffer to the parsed object store commit-slabs: remove realloc counter outside of slab struct commit.c: allow parse_commit_buffer to handle arbitrary repositories tag: allow parse_tag_buffer to handle arbitrary repositories tag: allow lookup_tag to handle arbitrary repositories commit: allow lookup_commit to handle arbitrary repositories tree: allow lookup_tree to handle arbitrary repositories blob: allow lookup_blob to handle arbitrary repositories object: allow lookup_object to handle arbitrary repositories object: allow object_as_type to handle arbitrary repositories tag: add repository argument to deref_tag tag: add repository argument to parse_tag_buffer tag: add repository argument to lookup_tag ...
2018-07-20commit.h: remove method declarationsLibravatar Derrick Stolee1-0/+1
These methods are now declared in commit-reach.h. Remove them from commit.h and add new include statements in all files that require these declarations. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-18Merge branch 'jk/branch-l-0-deprecation'Libravatar Junio C Hamano1-1/+21
The "-l" option in "git branch -l" is an unfortunate short-hand for "--create-reflog", but many users, both old and new, somehow expect it to be something else, perhaps "--list". This step warns when "-l" is used as a short-hand for "--create-reflog" and warns about the future repurposing of the it when it is used. * jk/branch-l-0-deprecation: branch: deprecate "-l" option t: switch "branch -l" to "branch --create-reflog" t3200: unset core.logallrefupdates when testing reflog creation
2018-06-29commit: add repository argument to lookup_commit_referenceLibravatar Stefan Beller1-3/+4
Add a repository argument to allow callers of lookup_commit_reference to be more specific about which repository to handle. This is a small mechanical change; it doesn't change the implementation to handle repositories other than the_repository yet. As with the previous commits, use a macro to catch callers passing a repository other than the_repository at compile time. Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-25Merge branch 'nd/complete-config-vars'Libravatar Junio C Hamano1-17/+12
Continuing with the idea to programatically enumerate various pieces of data required for command line completion, teach the codebase to report the list of configuration variables subcommands care about to help complete them. * nd/complete-config-vars: completion: complete general config vars in two steps log-tree: allow to customize 'grafted' color completion: support case-insensitive config vars completion: keep other config var completion in camelCase completion: drop the hard coded list of config vars am: move advice.amWorkDir parsing back to advice.c advice: keep config name in camelCase in advice_config[] fsck: produce camelCase config key names help: add --config to list all available config fsck: factor out msg_id_info[] lazy initialization code grep: keep all colors in an array Add and use generic name->id mapping code for color slot parsing
2018-06-22branch: make "-l" a synonym for "--list"Libravatar Jeff King1-21/+1
The other "mode" options of git-branch have short-option aliases that are easy to type (e.g., "-d" and "-m"). Let's give "--list" the same treatment. This also makes it consistent with the similar "git tag -l" option. We didn't do this originally because "--create-reflog" was squatting on the "-l" option. Now that we've deprecated that use for long enough, we can make the switch. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-22branch: deprecate "-l" optionLibravatar Jeff King1-1/+21
The "-l" option is short for "--create-reflog". This has caused much confusion over the years. Most people expect it to work as "--list", because that would match the other "mode" options like -d/--delete and -m/--move, as well as the similar -l/--list option of git-tag. Adding to the confusion, using "-l" _appears_ to work as "--list" in some cases: $ git branch -l * master because the branch command defaults to listing (so even trying to specify --list in the command above is redundant). But that may bite the user later when they add a pattern, like: $ git branch -l foo which does not return an empty list, but in fact creates a new branch (with a reflog, naturally) called "foo". It's also probably quite uncommon for people to actually use "-l" to create a reflog. Since 0bee591869 (Enable reflogs by default in any repository with a working directory., 2006-12-14), this is the default in non-bare repositories. So it's rather unfortunate that the feature squats on the short-and-sweet "-l" (which was only added in 3a4b3f269c (Create/delete branch ref logs., 2006-05-19), meaning there were only 7 months where it was actually useful). Let's deprecate "-l" in hopes of eventually re-purposing it to "--list". Note that we issue the warning only when we're not in list mode. This means that people for whom it works as a happy accident, namely: $ git branch -l master won't see the warning at all. And when we eventually switch to it meaning "--list", that will just continue to work. We do the issue the warning for these important cases: - when we are actually creating a branch, in case the user really did mean it as "--create-reflog" - when we are in some _other_ mode, like deletion. There the "-l" is a noop for now, but it will eventually conflict with any other mode request, and the user should be told that this is changing. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-18Merge branch 'rd/doc-remote-tracking-with-hyphen'Libravatar Junio C Hamano1-1/+1
Doc update. * rd/doc-remote-tracking-with-hyphen: Use hyphenated "remote-tracking branch" (docs and comments)
2018-06-13Use hyphenated "remote-tracking branch" (docs and comments)Libravatar Robert P. J. Day1-1/+1
Use the obvious consensus of hyphenated "remote-tracking branch", and fix an obvious typo, all in documentation and comments. Signed-off-by: Robert P. J. Day <rpjday@crashcourse.ca> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-06-01Merge branch 'nd/use-opt-int-set-f'Libravatar Junio C Hamano1-2/+2
Code simplification. * nd/use-opt-int-set-f: Use OPT_SET_INT_F() for cmdline option specification
2018-05-30Merge branch 'js/use-bug-macro'Libravatar Junio C Hamano1-1/+1
Developer support update, by using BUG() macro instead of die() to mark codepaths that should not happen more clearly. * js/use-bug-macro: BUG_exit_code: fix sparse "symbol not declared" warning Convert remaining die*(BUG) messages Replace all die("BUG: ...") calls by BUG() ones run-command: use BUG() to report bugs, not die() test-tool: help verifying BUG() code paths
2018-05-29help: add --config to list all available configLibravatar Nguyễn Thái Ngọc Duy1-0/+3
Sometimes it helps to list all available config vars so the user can search for something they want. The config man page can also be used but it's harder to search if you want to focus on the variable name, for example. This is not the best way to collect the available config since it's not precise. Ideally we should have a centralized list of config in C code (pretty much like 'struct option'), but that's a lot more work. This will do for now. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-29Add and use generic name->id mapping code for color slot parsingLibravatar Nguyễn Thái Ngọc Duy1-18/+10
Instead of hard coding the name-to-id mapping in C code, keep it in an array and use a common function to do the parsing. This reduces code and also allows us to list all possible color slots later. This starts using C99 designated initializers more for convenience (the first designated initializers have been introduced in builtin/clean.c for some time without complaints) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-05-24Use OPT_SET_INT_F() for cmdline option specificationLibravatar Nguyễn Thái Ngọc Duy1-2/+2
The only thing these commands need is extra parseopt flag which can be passed in by OPT_SET_INT_F() and it is a bit more compact than full struct initialization. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>