summaryrefslogtreecommitdiff
path: root/builtin/branch.c
AgeCommit message (Collapse)AuthorFilesLines
2018-02-09completion: use __gitcomp_builtin in _git_branchLibravatar Nguyễn Thái Ngọc Duy1-1/+1
The new completable options are: --all --create-reflog --format= --ignore-case --quiet Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-02-09parse-options: let OPT__FORCE take optional flags argumentLibravatar Nguyễn Thái Ngọc Duy1-1/+1
--force option is most likely hidden from command line completion for safety reasons. This is done by adding an extra flag PARSE_OPT_NOCOMPLETE. Update OPT__FORCE() to accept additional flags. Actual flag change comes later depending on individual commands. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-27Merge branch 'ks/branch-cleanup'Libravatar Junio C Hamano1-6/+13
Code clean-up. * ks/branch-cleanup: builtin/branch: strip refs/heads/ using skip_prefix branch: update warning message shown when copying a misnamed branch branch: group related arguments of create_branch() branch: improve documentation and naming of create_branch() parameters
2017-12-07builtin/branch: strip refs/heads/ using skip_prefixLibravatar Kaartic Sivaraam1-4/+11
Instead of hard-coding the offset strlen("refs/heads/") to skip the prefix "refs/heads/" use the skip_prefix() function which is more communicative and verifies that the string actually starts with that prefix. Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-07branch: update warning message shown when copying a misnamed branchLibravatar Kaartic Sivaraam1-1/+1
When a user tries to rename a branch that has a "bad name" (e.g., starts with a '-') then we warn them that the misnamed branch has been renamed "away". A similar message is shown when trying to create a copy of a misnamed branch even though it doesn't remove the misnamed branch. This is not correct and may confuse the user. So, update the warning message shown to be more precise that only a copy of the misnamed branch has been created. It's better to show the warning message than not showing it at all as it makes the user aware of the presence of a misnamed branch. Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-12-07branch: group related arguments of create_branch()Libravatar Kaartic Sivaraam1-1/+1
39bd6f726 (Allow checkout -B <current-branch> to update the current branch, 2011-11-26) added 'clobber_head' (now, 'clobber_head_ok') "before" 'track' as 'track' was closely related 'clobber_head' for the purpose the commit wanted to achieve. Looking from the perspective of how the arguments are used it turns out that 'clobber_head' is more related to 'force' than it is to 'track'. So, re-order the arguments to keep the related arguments close to each other. Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-28Merge branch 'ma/branch-list-paginate'Libravatar Junio C Hamano1-0/+3
"git branch --list" learned to show its output through the pager by default when the output is going to a terminal, which is controlled by the pager.branch configuration variable. This is similar to a recent change to "git tag --list". * ma/branch-list-paginate: branch: change default of `pager.branch` to "on" branch: respect `pager.branch` in list-mode only t7006: add tests for how git branch paginates
2017-11-28Merge branch 'jc/branch-name-sanity'Libravatar Junio C Hamano1-7/+4
"git branch" and "git checkout -b" are now forbidden from creating a branch whose name is "HEAD". * jc/branch-name-sanity: builtin/branch: remove redundant check for HEAD branch: correctly reject refs/heads/{-dash,HEAD} branch: split validate_new_branchname() into two branch: streamline "attr_only" handling in validate_new_branchname()
2017-11-20branch: change default of `pager.branch` to "on"Libravatar Martin Ågren1-1/+1
This is similar to ff1e72483 (tag: change default of `pager.tag` to "on", 2017-08-02) and is safe now that we do not consider `pager.branch` at all when we are not listing branches. This change will help with listing many branches, but will not hurt users of `git branch --edit-description` as it would have before the previous commit. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-20branch: respect `pager.branch` in list-mode onlyLibravatar Martin Ågren1-0/+3
Similar to de121ffe5 (tag: respect `pager.tag` in list-mode only, 2017-08-02), use the DELAY_PAGER_CONFIG-mechanism to only respect `pager.branch` when we are listing branches. We have two possibilities of generalizing what that earlier commit made to `git tag`. One is to interpret, e.g., --set-upstream-to as "it does not use an editor, so we should page". Another, the one taken by this commit, is to say "it does not list, so let's not page". That is in line with the approach of the series on `pager.tag` and in particular the wording in Documentation/git-tag.txt, which this commit reuses for git-branch.txt. This fixes the failing test added in the previous commit. Also adapt the test for whether `git branch --set-upstream-to` respects `pager.branch`. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-15builtin/branch: remove redundant check for HEADLibravatar Kaartic Sivaraam1-3/+0
The lower level code has been made to handle this case for the sake of consistency. This has made this check redundant. So, remove the redundant check. Signed-off-by: Kaartic Sivaraam <kaartic.sivaraam@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-11-06refs: rename constant `REF_NODEREF` to `REF_NO_DEREF`Libravatar Michael Haggerty1-1/+1
Even after working with this code for years, I still see this constant name as "ref node ref". Rename it to make it's meaning clearer. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-28Merge branch 'bc/object-id' into baseLibravatar Michael Haggerty1-4/+4
2017-10-18Merge branch 'jk/ref-filter-colors-fix'Libravatar Junio C Hamano1-1/+1
This is the "theoretically more correct" approach of simply stepping back to the state before plumbing commands started paying attention to "color.ui" configuration variable. Let's run with this one. * jk/ref-filter-colors-fix: tag: respect color.ui config Revert "color: check color.ui in git_default_config()" Revert "t6006: drop "always" color config tests" Revert "color: make "always" the same as "auto" in config"
2017-10-17Revert "color: check color.ui in git_default_config()"Libravatar Jeff King1-1/+1
This reverts commit 136c8c8b8fa39f1315713248473dececf20f8fe7. That commit was trying to address a bug caused by 4c7f1819b3 (make color.ui default to 'auto', 2013-06-10), in which plumbing like diff-tree defaulted to "auto" color, but did not respect a "color.ui" directive to disable it. But it also meant that we started respecting "color.ui" set to "always". This was a known problem, but 4c7f1819b3 argued that nobody ought to be doing that. However, that turned out to be wrong, and we got a number of bug reports related to "add -p" regressing in v2.14.2. Let's revert 136c8c8b8, fixing the regression to "add -p". This leaves the problem from 4c7f1819b3 unfixed, but: 1. It's a pretty obscure problem in the first place. I only noticed it while working on the color code, and we haven't got a single bug report or complaint about it. 2. We can make a more moderate fix on top by respecting "never" but not "always" for plumbing commands. This is just the minimal fix to go back to the working state we had before v2.14.2. Note that this isn't a pure revert. We now have a test in t3701 which shows off the "add -p" regression. This can be flipped to success. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-16refs: convert resolve_refdup and refs_resolve_refdup to struct object_idLibravatar brian m. carlson1-3/+3
All of the callers already pass the hash member of struct object_id, so update them to pass a pointer to the struct directly, This transformation was done with an update to declaration and definition and the following semantic patch: @@ expression E1, E2, E3, E4; @@ - resolve_refdup(E1, E2, E3.hash, E4) + resolve_refdup(E1, E2, &E3, E4) @@ expression E1, E2, E3, E4; @@ - resolve_refdup(E1, E2, E3->hash, E4) + resolve_refdup(E1, E2, E3, E4) Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-16refs: convert delete_ref and refs_delete_ref to struct object_idLibravatar brian m. carlson1-1/+1
Convert delete_ref and refs_delete_ref to take a pointer to struct object_id. Update the documentation accordingly, including referring to null_oid in lowercase, as it is not a #define constant. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-13branch: split validate_new_branchname() into twoLibravatar Junio C Hamano1-4/+4
Checking if a proposed name is appropriate for a branch is strictly a subset of checking if we want to allow creating or updating a branch with such a name. The mysterious sounding 'attr_only' parameter to validate_new_branchname() is used to switch the function between these two roles. Instead, split the function into two, and adjust the callers. A new helper validate_branchname() only checks the name and reports if the branch already exists. This loses one NEEDSWORK from the branch API. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-07Merge branch 'ks/branch-tweak-error-message-for-extra-args'Libravatar Junio C Hamano1-3/+3
Error message tweak. * ks/branch-tweak-error-message-for-extra-args: branch: change the error messages to be more meaningful
2017-10-07Merge branch 'sb/branch-avoid-repeated-strbuf-release'Libravatar Junio C Hamano1-2/+3
* sb/branch-avoid-repeated-strbuf-release: branch: reset instead of release a strbuf
2017-10-05Merge branch 'rs/cleanup-strbuf-users'Libravatar Junio C Hamano1-1/+1
Code clean-up. * rs/cleanup-strbuf-users: graph: use strbuf_addchars() to add spaces use strbuf_addstr() for adding strings to strbufs path: use strbuf_add_real_path()
2017-10-04branch: reset instead of release a strbufLibravatar Stefan Beller1-2/+3
Our documentation advises to not re-use a strbuf, after strbuf_release has been called on it. Use the proper reset instead. Currently 'strbuf_release' releases and re-initializes the strbuf, so it is safe, but slow. 'strbuf_reset' only resets the internal length variable, such that this could also be accounted for as a micro-optimization. Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-04branch: change the error messages to be more meaningfulLibravatar Kaartic Sivaraam1-3/+3
The error messages shown when the branch command is misused by supplying it wrong number of parameters wasn't meaningful. That's because it used the the phrase "too many branches" assuming all parameters to be "valid" branch names. It's not always the case as exemplified below, $ git branch foo * master $ git branch -m foo foo old fatal: too many branches for a rename operation Change the messages to be more general thus making no assumptions about the "parameters". Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-10-03Merge branch 'sd/branch-copy'Libravatar Junio C Hamano1-15/+47
"git branch" learned "-c/-C" to create a new branch by copying an existing one. * sd/branch-copy: branch: fix "copy" to never touch HEAD branch: add a --copy (-c) option to go with --move (-m) branch: add test for -m renaming multiple config sections config: create a function to format section headers
2017-10-02use strbuf_addstr() for adding strings to strbufsLibravatar René Scharfe1-1/+1
Use strbuf_addstr() instead of strbuf_addf() for adding strings. That's simpler and makes the intent clearer. Patch generated by Coccinelle and contrib/coccinelle/strbuf.cocci; adjusted indentation in refs/packed-backend.c manually. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-09-24branch: fix "copy" to never touch HEADLibravatar Junio C Hamano1-6/+3
When creating a new branch B by copying the branch A that happens to be the current branch, it also updates HEAD to point at the new branch. It probably was made this way because "git branch -c A B" piggybacked its implementation on "git branch -m A B", This does not match the usual expectation. If I were sitting on a blue chair, and somebody comes and repaints it to red, I would accept ending up sitting on a chair that is now red (I am also OK to stand, instead, as there no longer is my favourite blue chair). But if somebody creates a new red chair, modelling it after the blue chair I am sitting on, I do not expect to be booted off of the blue chair and ending up on sitting on the new red one. Let's fix this before it hits 'next'. Those who want to create a new branch and switch to it can do "git checkout B" after doing a "git branch -c B", and if that operation is so useful and deserves a short-hand way to do so, perhaps extend "git checkout -b B" to copy configurations while creating the new branch B. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-08-17builtin/branch: stop supporting the "--set-upstream" optionLibravatar Kaartic Sivaraam1-22/+3
The '--set-upstream' option of branch was deprecated in b347d06b ("branch: deprecate --set-upstream and show help if we detect possible mistaken use", 2012-08-30) and has been planned for removal ever since. In order to prevent "--set-upstream" on a command line from being taken as an abbreviated form of "--set-upstream-to", explicitly catch "--set-upstream" option and die, instead of just removing it from the list of options. Before this change, an attempt to use "--set-upstream" resulted in: $ git branch * master $ git branch --set-upstream origin/master The --set-upstream flag is deprecated and will be removed. Consider using --track or --set-upstream-to Branch origin/master set up to track local branch master. $ echo $? 0 $ git branch * master origin/master With this change, the behaviour becomes like this: $ git branch * master $ git branch --set-upstream origin/master fatal: the '--set-upstream' option is no longer supported. Please use '--track' or '--set-upstream-to' instead. $ echo $? 128 $ git branch * master Signed-off-by: Kaartic Sivaraam <kaarticsivaraam91196@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13ref-filter: consult want_color() before emitting colorsLibravatar Jeff King1-0/+1
When color placeholders like %(color:red) are used in a ref-filter format, we unconditionally output the colors, even if the user has asked us for no colors. This usually isn't a problem when the user is constructing a --format on the command line, but it means we may do the wrong thing when the format is fed from a script or alias. For example: $ git config alias.b 'branch --format=%(color:green)%(refname)' $ git b --no-color should probably omit the green color. Likewise, running: $ git b >branches should probably also omit the color, just as we would for all baked-in coloring (and as we recently started to do for user-specified colors in --pretty formats). This commit makes both of those cases work by teaching the ref-filter code to consult want_color() before outputting any color. The color flag in ref_format defaults to "-1", which means we'll consult color.ui, which in turn defaults to the usual isatty() check on stdout. However, callers like git-branch which support their own color config (and command-line options) can override that. The new tests independently cover all three of the callers of ref-filter (for-each-ref, tag, and branch). Even though these seem redundant, it confirms that we've correctly plumbed through all of the necessary config to make colors work by default. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13color: check color.ui in git_default_config()Libravatar Jeff King1-1/+1
Back in prehistoric times, our decision on whether or not to show color by default relied on using a config callback that either did or didn't load color config like color.diff. When we introduced color.ui, we put it in the same boat: commands had to manually respect it by using git_color_config() or its git_color_default_config() convenience wrapper. But in 4c7f1819b (make color.ui default to 'auto', 2013-06-10), that changed. Since then, we default color.ui to auto in all programs, meaning that even plumbing commands like "git diff-tree --pretty" might colorize the output. Nobody seems to have complained in the intervening years, presumably because the "is stdout a tty" check does a good job of catching the right cases. But that leaves an interesting curiosity: color.ui defaults to auto even in plumbing, but you can't actually _disable_ the color via config. So if you really hate color and set "color.ui" to false, diff-tree will still show color (but porcelain like git-diff won't). Nobody noticed that either, probably because very few people disable color. One could argue that the plumbing should _always_ disable color unless an explicit --color option is given on the command line. But in practice, this creates a lot of complications for scripts which do want plumbing to show user-visible output. They can't just pass "--color" blindly; they need to check the user's config and decide what to send. Given that nobody has complained about the current behavior, let's assume it's a good path, and follow it to its conclusion: supporting color.ui everywhere. Note that you can create havoc by setting color.ui=always in your config, but that's more or less already the case. We could disallow it entirely, but it is handy for one-offs like: git -c color.ui=always foo >not-a-tty when "foo" does not take a --color option itself. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13ref-filter: abstract ref format into its own structLibravatar Jeff King1-7/+7
The ref-filter module provides routines for formatting a ref for output. The fundamental interface for the format is a "const char *" containing the format, and any additional options need to be passed to each invocation of show_ref_array_item. Instead, let's make a ref_format struct that holds the format, along with any associated format options. That will make some enhancements easier in the future: 1. new formatting options can be added without disrupting existing callers 2. some state can be carried in the struct rather than as global variables For now this just has the text format itself along with the quote_style option, but we'll add more fields in future patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-13check return value of verify_ref_format()Libravatar Jeff King1-1/+3
Users of the ref-filter code must call verify_ref_format() before formatting any refs, but most ignore its return value. This means we may print an error on a syntactically bogus pattern, but keep going anyway. In most cases this results in a fatal error when we actually try to format a ref. But if you have no refs to show at all, then the behavior is confusing: git prints the error from verify_ref_format(), then exits with code 0 without showing any output. Let's instead abort immediately if we know we have a bogus format. We'll output the usage information if we have it handy (just like the existing call in cmd_for_each_ref() does), and otherwise just die(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-12Merge branch 'kn/ref-filter-branch-list'Libravatar Junio C Hamano1-6/+9
The rewrite of "git branch --list" using for-each-ref's internals that happened in v2.13 regressed its handling of color.branch.local; this has been fixed. * kn/ref-filter-branch-list: ref-filter.c: drop return from void function branch: set remote color in ref-filter branch immediately branch: use BRANCH_COLOR_LOCAL in ref-filter format branch: only perform HEAD check for local branches
2017-07-09branch: set remote color in ref-filter branch immediatelyLibravatar Jeff King1-5/+6
We set the current and local branch colors at the top of the build_format() function. Let's do the same for the remote color. This saves a little bit of repetition, but more importantly it puts all of the color-setting in the same place. That makes it easier to see that we are coloring all possibilities. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-09branch: use BRANCH_COLOR_LOCAL in ref-filter formatLibravatar Jeff King1-2/+3
Since 949af0684 (branch: use ref-filter printing APIs, 2017-01-10), git-branch's output is generated by passing a custom format to the ref-filter code. This format forgot to pass BRANCH_COLOR_LOCAL, meaning that local branches (besides the current one) were never colored at all. We can add it in the %(if) block where we decide whether the branch is "current" or merely "local". Note that this means the current/local coloring is either/or. You can't set: [color "branch"] local = blue current = bold and expect the current branch to be "bold blue". This matches the pre-949af0684 behavior. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-07-09branch: only perform HEAD check for local branchesLibravatar Jeff King1-1/+2
When assembling the ref-filter format to show "git branch" output, we put the "%(if)%(HEAD)" conditional at the start of the overall format. But there's no point in checking whether a remote branch matches HEAD, as it never will. The check should go inside the local conditional; we assemble that format inside the "local" strbuf. By itself, this is just a minor optimization. But in a future patch, we'll need this refactoring to fix local-branch coloring. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-24Merge branch 'bw/config-h'Libravatar Junio C Hamano1-0/+1
Fix configuration codepath to pay proper attention to commondir that is used in multi-worktree situation, and isolate config API into its own header file. * bw/config-h: config: don't implicitly use gitdir or commondir config: respect commondir setup: teach discover_git_directory to respect the commondir config: don't include config.h by default config: remove git_config_iter config: create config.h
2017-06-18branch: add a --copy (-c) option to go with --move (-m)Libravatar Sahil Dua1-16/+51
Add the ability to --copy a branch and its reflog and configuration, this uses the same underlying machinery as the --move (-m) option except the reflog and configuration is copied instead of being moved. This is useful for e.g. copying a topic branch to a new version, e.g. work to work-2 after submitting the work topic to the list, while preserving all the tracking info and other configuration that goes with the branch, and unlike --move keeping the other already-submitted branch around for reference. Like --move, when the source branch is the currently checked out branch the HEAD is moved to the destination branch. In the case of --move we don't really have a choice (other than remaining on a detached HEAD) and in order to keep the functionality consistent, we are doing it in similar way for --copy too. The most common usage of this feature is expected to be moving to a new topic branch which is a copy of the current one, in that case moving to the target branch is what the user wants, and doesn't unexpectedly behave differently than --move would. One outstanding caveat of this implementation is that: git checkout maint && git checkout master && git branch -c topic && git checkout - Will check out 'maint' instead of 'master'. This is because the @{-N} feature (or its -1 shorthand "-") relies on HEAD reflogs created by the checkout command, so in this case we'll checkout maint instead of master, as the user might expect. What to do about that is left to a future change. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Sahil Dua <sahildua2305@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-06-15config: don't include config.h by defaultLibravatar Brandon Williams1-0/+1
Stop including config.h by default in cache.h. Instead only include config.h in those files which require use of the config system. Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-05-08Convert lookup_commit* to struct object_idLibravatar brian m. carlson1-3/+3
Convert lookup_commit, lookup_commit_or_die, lookup_commit_reference, and lookup_commit_reference_gently to take struct object_id arguments. Introduce a temporary in parse_object buffer in order to convert this function. This is required since in order to convert parse_object and parse_object_buffer, lookup_commit_reference_gently and lookup_commit_or_die would need to be converted. Not introducing a temporary would therefore require that lookup_commit_or_die take a struct object_id *, but lookup_commit would take unsigned char *, leaving a confusing and hard-to-use interface. parse_object_buffer will lose this temporary in a later patch. This commit was created with manual changes to commit.c, commit.h, and object.c, plus the following semantic patch: @@ expression E1, E2; @@ - lookup_commit_reference_gently(E1.hash, E2) + lookup_commit_reference_gently(&E1, E2) @@ expression E1, E2; @@ - lookup_commit_reference_gently(E1->hash, E2) + lookup_commit_reference_gently(E1, E2) @@ expression E1; @@ - lookup_commit_reference(E1.hash) + lookup_commit_reference(&E1) @@ expression E1; @@ - lookup_commit_reference(E1->hash) + lookup_commit_reference(E1) @@ expression E1; @@ - lookup_commit(E1.hash) + lookup_commit(&E1) @@ expression E1; @@ - lookup_commit(E1->hash) + lookup_commit(E1) @@ expression E1, E2; @@ - lookup_commit_or_die(E1.hash, E2) + lookup_commit_or_die(&E1, E2) @@ expression E1, E2; @@ - lookup_commit_or_die(E1->hash, E2) + lookup_commit_or_die(E1, E2) Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-26Merge branch 'jk/war-on-git-path'Libravatar Junio C Hamano1-3/+3
While handy, "git_path()" is a dangerous function to use as a callsite that uses it safely one day can be broken by changes to other code that calls it. Reduction of its use continues. * jk/war-on-git-path: am: drop "dir" parameter from am_state_init replace strbuf_addstr(git_path()) with git_path_buf() replace xstrdup(git_path(...)) with git_pathdup(...) use git_path_* helper functions branch: add edit_description() helper bisect: add git_path_bisect_terms helper
2017-04-20branch: add edit_description() helperLibravatar Jeff King1-3/+3
Rather than have a variable with a short name that is fed to git_path(), let's add a helper function that returns the full path. This avoids the dangerous git_path() function. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-04-11Merge branch 'ab/ref-filter-no-contains'Libravatar Junio C Hamano1-1/+4
"git tag/branch/for-each-ref" family of commands long allowed to filter the refs by "--contains X" (show only the refs that are descendants of X), "--merged X" (show only the refs that are ancestors of X), "--no-merged X" (show only the refs that are not ancestors of X). One curious omission, "--no-contains X" (show only the refs that are not descendants of X) has been added to them. * ab/ref-filter-no-contains: tag: add tests for --with and --without ref-filter: reflow recently changed branch/tag/for-each-ref docs ref-filter: add --no-contains option to tag/branch/for-each-ref tag: change --point-at to default to HEAD tag: implicitly supply --list given another list-like option tag: change misleading --list <pattern> documentation parse-options: add OPT_NONEG to the "contains" option tag: add more incompatibles mode tests for-each-ref: partly change <object> to <commit> in help tag tests: fix a typo in a test description tag: remove a TODO item from the test suite ref-filter: add test for --contains on a non-commit ref-filter: make combining --merged & --no-merged an error tag doc: reword --[no-]merged to talk about commits, not tips tag doc: split up the --[no-]merged documentation tag doc: move the description of --[no-]merged earlier
2017-03-28Merge branch 'jk/interpret-branch-name' into maintLibravatar Junio C Hamano1-1/+4
"git branch @" created refs/heads/@ as a branch, and in general the code that handled @{-1} and @{upstream} was a bit too loose in disambiguating. * jk/interpret-branch-name: checkout: restrict @-expansions when finding branch strbuf_check_ref_format(): expand only local branches branch: restrict @-expansions when deleting t3204: test git-branch @-expansion corner cases interpret_branch_name: allow callers to restrict expansions strbuf_branchname: add docstring strbuf_branchname: drop return value interpret_branch_name: move docstring to header file interpret_branch_name(): handle auto-namelen for @{-1}
2017-03-24ref-filter: add --no-contains option to tag/branch/for-each-refLibravatar Ævar Arnfjörð Bjarmason1-1/+4
Change the tag, branch & for-each-ref commands to have a --no-contains option in addition to their longstanding --contains options. This allows for finding the last-good rollout tag given a known-bad <commit>. Given a hypothetically bad commit cf5c7253e0, the git version to revert to can be found with this hacky two-liner: (git tag -l 'v[0-9]*'; git tag -l --contains cf5c7253e0 'v[0-9]*') | sort | uniq -c | grep -E '^ *1 ' | awk '{print $2}' | tail -n 10 With this new --no-contains option the same can be achieved with: git tag -l --no-contains cf5c7253e0 'v[0-9]*' | sort | tail -n 10 As the filtering machinery is shared between the tag, branch & for-each-ref commands, implement this for those commands too. A practical use for this with "branch" is e.g. finding branches which were branched off between v2.8.0 and v2.10.0: git branch --contains v2.8.0 --no-contains v2.10.0 The "describe" command also has a --contains option, but its semantics are unrelated to what tag/branch/for-each-ref use --contains for. A --no-contains option for "describe" wouldn't make any sense, other than being exactly equivalent to not supplying --contains at all, which would be confusing at best. Add a --without option to "tag" as an alias for --no-contains, for consistency with --with and --contains. The --with option is undocumented, and possibly the only user of it is Junio (<xmqqefy71iej.fsf@gitster.mtv.corp.google.com>). But it's trivial to support, so let's do that. The additions to the the test suite are inverse copies of the corresponding --contains tests. With this change --no-contains for tag, branch & for-each-ref is just as well tested as the existing --contains option. In addition to those tests, add a test for "tag" which asserts that --no-contains won't find tree/blob tags, which is slightly unintuitive, but consistent with how --contains works & is documented. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-17Merge branch 'bc/object-id'Libravatar Junio C Hamano1-13/+13
"uchar [40]" to "struct object_id" conversion continues. * bc/object-id: wt-status: convert to struct object_id builtin/merge-base: convert to struct object_id Convert object iteration callbacks to struct object_id sha1_file: introduce an nth_packed_object_oid function refs: simplify parsing of reflog entries refs: convert each_reflog_ent_fn to struct object_id reflog-walk: convert struct reflog_info to struct object_id builtin/replace: convert to struct object_id Convert remaining callers of resolve_refdup to object_id builtin/merge: convert to struct object_id builtin/clone: convert to struct object_id builtin/branch: convert to struct object_id builtin/grep: convert to struct object_id builtin/fmt-merge-message: convert to struct object_id builtin/fast-export: convert to struct object_id builtin/describe: convert to struct object_id builtin/diff-tree: convert to struct object_id builtin/commit: convert to struct object_id hex: introduce parse_oid_hex
2017-03-14Merge branch 'kn/ref-filter-branch-list'Libravatar Junio C Hamano1-4/+15
"git branch --list" takes the "--abbrev" and "--no-abbrev" options to control the output of the object name in its "-v"(erbose) output, but a recent update started ignoring them; this fixes it before the breakage reaches to any released version. * kn/ref-filter-branch-list: branch: honor --abbrev/--no-abbrev in --list mode
2017-03-14Merge branch 'jk/interpret-branch-name'Libravatar Junio C Hamano1-1/+4
"git branch @" created refs/heads/@ as a branch, and in general the code that handled @{-1} and @{upstream} was a bit too loose in disambiguating. * jk/interpret-branch-name: checkout: restrict @-expansions when finding branch strbuf_check_ref_format(): expand only local branches branch: restrict @-expansions when deleting t3204: test git-branch @-expansion corner cases interpret_branch_name: allow callers to restrict expansions strbuf_branchname: add docstring strbuf_branchname: drop return value interpret_branch_name: move docstring to header file interpret_branch_name(): handle auto-namelen for @{-1}
2017-03-10branch: honor --abbrev/--no-abbrev in --list modeLibravatar Junio C Hamano1-4/+15
When the "branch --list" command was converted to use the --format facility from the ref-filter API, we forgot to honor the --abbrev setting in the default output format and instead used a hardcoded "7". Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02branch: restrict @-expansions when deletingLibravatar Jeff King1-1/+4
We use strbuf_branchname() to expand the branch name from the command line, so you can delete the branch given by @{-1}, for example. However, we allow other nonsense like "@", and we do not respect our "-r" flag (so we may end up deleting an oddly-named local ref instead of a remote one). We can fix this by passing the appropriate "allowed" flag to strbuf_branchname(). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-03-02interpret_branch_name: allow callers to restrict expansionsLibravatar Jeff King1-1/+1
The interpret_branch_name() function converts names like @{-1} and @{upstream} into branch names. The expanded ref names are not fully qualified, and may be outside of the refs/heads/ namespace (e.g., "@" expands to "HEAD", and "@{upstream}" is likely to be in "refs/remotes/"). This is OK for callers like dwim_ref() which are primarily interested in resolving the resulting name, no matter where it is. But callers like "git branch" treat the result as a branch name in refs/heads/. When we expand to a ref outside that namespace, the results are very confusing (e.g., "git branch @" tries to create refs/heads/HEAD, which is nonsense). Callers can't know from the returned string how the expansion happened (e.g., did the user really ask for a branch named "HEAD", or did we do a bogus expansion?). One fix would be to return some out-parameters describing the types of expansion that occurred. This has the benefit that the caller can generate precise error messages ("I understood @{upstream} to mean origin/master, but that is a remote tracking branch, so you cannot create it as a local name"). However, out-parameters make the function interface somewhat cumbersome. Instead, let's do the opposite: let the caller tell us which elements to expand. That's easier to pass in, and none of the callers give more precise error messages than "@{upstream} isn't a valid branch name" anyway (which should be sufficient). The strbuf_branchname() function needs a similar parameter, as most of the callers access interpret_branch_name() through it. We can break the callers down into two groups: 1. Callers that are happy with any kind of ref in the result. We pass "0" here, so they continue to work without restrictions. This includes merge_name(), the reflog handling in add_pending_object_with_path(), and substitute_branch_name(). This last is what powers dwim_ref(). 2. Callers that have funny corner cases (mostly in git-branch and git-checkout). These need to make use of the new parameter, but I've left them as "0" in this patch, and will address them individually in follow-on patches. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>