aboutsummaryrefslogtreecommitdiff
path: root/builtin/branch.c
Commit message (Collapse)AuthorAge
* builtin-branch: Fix crash on invalid use of --forceVincent van Ravesteijn2011-11-23
| | | | | | | | | | | | | The option --force should not put us in 'create branch' mode. The fact that this option is only valid in 'create branch' mode is already caught by the the next 'if' in which we assure that we are in the correct mode. Without this patch, "git branch -f" without any other argument ends up calling create_branch without any branch name. Signed-off-by: Vincent van Ravesteijn <vfr@lyx.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* branch -m: handle no arg properlyTay Ray Chuan2011-11-02
| | | | | | | | | | | | Modify the option parsing heuristic to handle all -m (rename) cases, including the no-arg case. Previously, this "fell through" to the (argc <= 2) case and caused segfault. Reported-by: Stefan Näwe <stefan.naewe@atlas-elektronik.com> Signed-off-by: Tay Ray Chuan <rctay89@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'mg/branch-list'Junio C Hamano2011-10-05
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | * mg/branch-list: t3200: clean up checks for file existence branch: -v does not automatically imply --list branch: allow pattern arguments branch: introduce --list option git-branch: introduce missing long forms for the options git-tag: introduce long forms for the options t6040: test branch -vv Conflicts: Documentation/git-tag.txt t/t3200-branch.sh
| * branch: -v does not automatically imply --listMichael J Gruber2011-09-08
| | | | | | | | | | | | | | | | | | "branch -v" without other options or parameters still works in the list mode, but that is not because there is "-v" but because there is no parameter nor option. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * branch: allow pattern argumentsMichael J Gruber2011-08-28
| | | | | | | | | | | | | | Allow pattern arguments for the list mode just like for git tag -l. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * branch: introduce --list optionMichael J Gruber2011-08-28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, there is no way to invoke the list mode explicitly, without giving -v to force verbose output. Introduce a --list option which invokes the list mode. This will be beneficial for invoking list mode with pattern matching, which otherwise would be interpreted as branch creation. Along with --list, test also combinations of existing options. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git-branch: introduce missing long forms for the optionsMichael J Gruber2011-08-28
| | | | | | | | | | | | | | | | | | | | Long forms are better to memorize and more reliably uniform across commands. Names follow precedents, e.g. "git log --remotes". Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ci/forbid-unwanted-current-branch-update'Junio C Hamano2011-09-16
|\ \ | | | | | | | | | | | | * ci/forbid-unwanted-current-branch-update: branch --set-upstream: regression fix
| * | branch --set-upstream: regression fixJunio C Hamano2011-09-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The "git branch" command, while not in listing mode, calls create_branch() even when the target branch already exists, and it does so even when it is not interested in updating the value of the branch (i.e. the name of the commit object that sits at the tip of the existing branch). This happens when the command is run with "--set-upstream" option. The earlier safety-measure to prevent "git branch -f $branch $commit" from updating the currently checked out branch did not take it into account, and we no longer can update the tracking information of the current branch. Minimally fix this regression by telling the validation code if it is called to really update the value of a potentially existing branch, or if the caller merely is interested in updating auxiliary aspects of a branch. Reported-and-Tested-by: Jay Soffian Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'ci/forbid-unwanted-current-branch-update'Junio C Hamano2011-08-28
|\ \ \ | |/ / | | | | | | | | | | | | * ci/forbid-unwanted-current-branch-update: Show interpreted branch name in error messages Prevent force-updating of the current branch
| * | Prevent force-updating of the current branchConrad Irwin2011-08-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git branch -M <foo> <current-branch>" allows updating the current branch which HEAD points, without the necessary house-keeping that git reset normally does to make this operation sensible. It also leaves the reflog in a confusing state (you would be warned when trying to read it). "git checkout -B <current branch> <foo>" is also partly vulnerable to this bug; due to inconsistent pre-flight checks it would perform half of its task and then abort just before rewriting the branch. Again this manifested itself as the index file getting out-of-sync with HEAD. "git branch -f" already guarded against this problem, and aborts with a fatal error. Update "git branch -M", "git checkout -B" and "git branch -f" to share the same check before allowing a branch to be created. These prevent you from updating the current branch. We considered suggesting the use of "git reset" in the failure message but concluded that it was not possible to discern what the user was actually trying to do. Signed-off-by: Conrad Irwin <conrad.irwin@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jk/color-and-pager'Junio C Hamano2011-08-28
|\ \ \ | |_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * jk/color-and-pager: want_color: automatically fallback to color.ui diff: don't load color config in plumbing config: refactor get_colorbool function color: delay auto-color decision until point of use git_config_colorbool: refactor stdout_is_tty handling diff: refactor COLOR_DIFF from a flag into an int setup_pager: set GIT_PAGER_IN_USE t7006: use test_config helpers test-lib: add helper functions for config t7006: modernize calls to unset Conflicts: builtin/commit.c parse-options.c
| * | want_color: automatically fallback to color.uiJeff King2011-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | All of the "do we want color" flags default to -1 to indicate that we don't have any color configured. This value is handled in one of two ways: 1. In porcelain, we check early on whether the value is still -1 after reading the config, and set it to the value of color.ui (which defaults to 0). 2. In plumbing, it stays untouched as -1, and want_color defaults it to off. This works fine, but means that every porcelain has to check and reassign its color flag. Now that want_color gives us a place to put this check in a single spot, we can do that, simplifying the calling code. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | color: delay auto-color decision until point of useJeff King2011-08-19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we read a color value either from a config file or from the command line, we use git_config_colorbool to convert it from the tristate always/never/auto into a single yes/no boolean value. This has some timing implications with respect to starting a pager. If we start (or decide not to start) the pager before checking the colorbool, everything is fine. Either isatty(1) will give us the right information, or we will properly check for pager_in_use(). However, if we decide to start a pager after we have checked the colorbool, things are not so simple. If stdout is a tty, then we will have already decided to use color. However, the user may also have configured color.pager not to use color with the pager. In this case, we need to actually turn off color. Unfortunately, the pager code has no idea which color variables were turned on (and there are many of them throughout the code, and they may even have been manipulated after the colorbool selection by something like "--color" on the command line). This bug can be seen any time a pager is started after config and command line options are checked. This has affected "git diff" since 89d07f7 (diff: don't run pager if user asked for a diff style exit code, 2007-08-12). It has also affect the log family since 1fda91b (Fix 'git log' early pager startup error case, 2010-08-24). This patch splits the notion of parsing a colorbool and actually checking the configuration. The "use_color" variables now have an additional possible value, GIT_COLOR_AUTO. Users of the variable should use the new "want_color()" wrapper, which will lazily determine and cache the auto-color decision. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | git_config_colorbool: refactor stdout_is_tty handlingJeff King2011-08-18
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | Usually this function figures out for itself whether stdout is a tty. However, it has an extra parameter just to allow git-config to override the auto-detection for its --get-colorbool option. Instead of an extra parameter, let's just use a global variable. This makes calling easier in the common case, and will make refactoring the colorbool code much simpler. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | branch -v: honor core.abbrevNamhyung Kim2011-07-01
|/ | | | | | | | | Use the value from 'core.abbrev' configuration variable unless user specifies the length on command line when showing commit object name in "branch -v" output. Signed-off-by: Namhyung Kim <namhyung@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint-1.7.5' into maintJunio C Hamano2011-06-29
|\ | | | | | | | | | | * maint-1.7.5: test: skip clean-up when running under --immediate mode "branch -d" can remove more than one branches
| * "branch -d" can remove more than one branchesJunio C Hamano2011-06-29
| | | | | | | | | | | | | | | | | | Since 03feddd (git-check-ref-format: reject funny ref names, 2005-10-13), "git branch -d" can take more than one branch names to remove. The documentation was correct, but the usage string was not. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/format-patch-am'Junio C Hamano2011-05-31
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | | | * jk/format-patch-am: format-patch: preserve subject newlines with -k clean up calling conventions for pretty.c functions pretty: add pp_commit_easy function for simple callers mailinfo: always clean up rfc822 header folding t: test subject handling in format-patch / am pipeline Conflicts: builtin/branch.c builtin/log.c commit.h
| * pretty: add pp_commit_easy function for simple callersJeff King2011-05-26
| | | | | | | | | | | | | | | | | | | | Many callers don't actually care about the pretty print context at all; let's just give them a simple way of pretty-printing a commit without having to create a context struct. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'ab/i18n-st'Junio C Hamano2011-04-01
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * ab/i18n-st: (69 commits) i18n: git-shortlog basic messages i18n: git-revert split up "could not revert/apply" message i18n: git-revert literal "me" messages i18n: git-revert "Your local changes" message i18n: git-revert basic messages i18n: git-notes GIT_NOTES_REWRITE_MODE error message i18n: git-notes basic commands i18n: git-gc "Auto packing the repository" message i18n: git-gc basic messages i18n: git-describe basic messages i18n: git-clean clean.requireForce messages i18n: git-clean basic messages i18n: git-bundle basic messages i18n: git-archive basic messages i18n: git-status "renamed: " message i18n: git-status "Initial commit" message i18n: git-status "Changes to be committed" message i18n: git-status shortstatus messages i18n: git-status "nothing to commit" messages i18n: git-status basic messages ... Conflicts: builtin/branch.c builtin/checkout.c builtin/clone.c builtin/commit.c builtin/grep.c builtin/merge.c builtin/push.c builtin/revert.c t/t3507-cherry-pick-conflict.sh t/t7607-merge-overwrite.sh
| * | i18n: git-branch "(no branch)" messageÆvar Arnfjörð Bjarmason2011-03-09
| | | | | | | | | | | | | | | | | | | | | | | | Gettextize the "(no branch)" message that's shown by "git branch" when you're in a detached HEAD. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | i18n: git-branch "git branch -v" messagesÆvar Arnfjörð Bjarmason2011-03-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Make the "git branch -v" messages translatable, e.g.: 5054b57 [ahead 8] branch error fixup This is possibly a plumbing message. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | i18n: git-branch "Deleted branch [...]" messageÆvar Arnfjörð Bjarmason2011-03-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | Gettextize the "Deleted %sbranch %s (was %s).\n" messages. test in t3200-branch.sh explicitly checked for this message. Change it to skip under GETTEXT_POISON=YesPlease. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | i18n: git-branch "remote branch '%s' not found" messageÆvar Arnfjörð Bjarmason2011-03-09
| | | | | | | | | | | | | | | | | | | | | | | | | | | This could be done better by splitting it up, but it would change too much code, which I'm trying to avoid at this point. Instead add a TRANSLATORS comment to explain what "remote " does. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | i18n: git-branch basic messagesÆvar Arnfjörð Bjarmason2011-03-09
| |/ | | | | | | | | Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | branch: split off function that writes tracking info and commit subjectJonathan Nieder2011-03-16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Introduce a add_verbose_info function that takes care of adding - an abbreviated object name; - a summary of the form [ahead x, behind y] of the relationship to the corresponding upstream branch; - a one line commit subject for the tip commit of a branch, for use in "git branch -v" output. No functional change intended. This just unindents the code a little and makes it easier to skip on first reading. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | branch_merged: fix grammar in warningEric Hanchrow2011-02-27
|/ | | | | | Signed-off-by: Eric Hanchrow <eric.hanchrow@gmail.com> Helped-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* builtin/branch.c: Use ALLOC_GROW instead of alloc_nr and xrealloc.Thiago Farina2010-12-19
| | | | | Signed-off-by: Thiago Farina <tfransosi@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jn/git-cmd-h-bypass-setup'Junio C Hamano2010-12-12
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | * jn/git-cmd-h-bypass-setup: update-index -h: show usage even with corrupt index merge -h: show usage even with corrupt index ls-files -h: show usage even with corrupt index gc -h: show usage even with broken configuration commit/status -h: show usage even with broken configuration checkout-index -h: show usage even in an invalid repository branch -h: show usage even in an invalid repository Conflicts: builtin/merge.c
| * branch -h: show usage even in an invalid repositoryNguyễn Thái Ngọc Duy2010-10-22
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | There is no need for "git branch -h" to try to access a repository. In the spirit of v1.6.6-rc0~34^2~3 (Let 'git <command> -h' show usage without a git dir, 2009-11-09). This brings git one step closer to passing the following (automatically verifiable) test: Before any repository access (aside from git_config()), a function from the setup_git_directory_* family has been run and thus one step closer to being able to use an automatic repository access checker. [jn: simplified; new commit message, test] Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | branch: improve --verbose descriptionRené Scharfe2010-11-15
| | | | | | | | | | Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | add OPT__FORCERené Scharfe2010-11-15
| | | | | | | | | | | | | | | | Add OPT__FORCE as a helper macro in the same spirit as OPT__VERBOSE et.al. to simplify defining -f/--force options. Signed-off-by: Rene Scharfe <rene.scharfe@lstfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | add description parameter to OPT__VERBOSERené Scharfe2010-11-15
|/ | | | | | | | | Allows better help text to be defined than "be verbose". Also make use of the macro in places that already had a different description. No object code changes intended. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'sm/branch-broken-ref'Junio C Hamano2010-06-21
|\ | | | | | | | | | | * sm/branch-broken-ref: branch: don't fail listing branches if one of the commits wasn't found branch: exit status now reflects if branch listing finds an error
| * branch: don't fail listing branches if one of the commits wasn't foundSimo Melenius2010-06-07
| | | | | | | | | | | | | | | | | | | | | | When listing branches with ref lookups, if one of the known raw refs doesn't point to a commit then "git branch" would return error(), terminating the whole for_each_rawref() iteration and possibly hiding any remaining refs. Signed-off-by: Simo Melenius <simo.melenius@iki.fi> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * branch: exit status now reflects if branch listing finds an errorSimo Melenius2010-06-07
| | | | | | | | | | | | | | | | | | If some refs could not be read when listing branches, this can now be observed in the exit status of the "git branch" command. Signed-off-by: Simo Melenius <simo.melenius@iki.fi> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | enums: omit trailing comma for portabilityGary V. Vaughan2010-05-31
|/ | | | | | | | | | | | | | | | | | | Without this patch at least IBM VisualAge C 5.0 (I have 5.0.2) on AIX 5.1 fails to compile git. enum style is inconsistent already, with some enums declared on one line, some over 3 lines with the enum values all on the middle line, sometimes with 1 enum value per line... and independently of that the trailing comma is sometimes present and other times absent, often mixing with/without trailing comma styles in a single file, and sometimes in consecutive enum declarations. Clearly, omitting the comma is the more portable style, and this patch changes all enum declarations to use the portable omitted dangling comma style consistently. Signed-off-by: Gary V. Vaughan <gary@thewrittenword.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'lt/deepen-builtin-source'Junio C Hamano2010-03-10
| | | | | | | | * lt/deepen-builtin-source: Move 'builtin-*' into a 'builtin/' subdirectory Conflicts: Makefile
* Move 'builtin-*' into a 'builtin/' subdirectoryLinus Torvalds2010-02-22
This shrinks the top-level directory a bit, and makes it much more pleasant to use auto-completion on the thing. Instead of [torvalds@nehalem git]$ em buil<tab> Display all 180 possibilities? (y or n) [torvalds@nehalem git]$ em builtin-sh builtin-shortlog.c builtin-show-branch.c builtin-show-ref.c builtin-shortlog.o builtin-show-branch.o builtin-show-ref.o [torvalds@nehalem git]$ em builtin-shor<tab> builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil<tab> [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh<tab> [type] shortlog.c shortlog.o show-branch.c show-branch.o show-ref.c show-ref.o [torvalds@nehalem git]$ em builtin/sho [auto-completes to] [torvalds@nehalem git]$ em builtin/shor<tab> [type] shortlog.c shortlog.o [torvalds@nehalem git]$ em builtin/shortlog.c which doesn't seem all that different, but not having that annoying break in "Display all 180 possibilities?" is quite a relief. NOTE! If you do this in a clean tree (no object files etc), or using an editor that has auto-completion rules that ignores '*.o' files, you won't see that annoying 'Display all 180 possibilities?' message - it will just show the choices instead. I think bash has some cut-off around 100 choices or something. So the reason I see this is that I'm using an odd editory, and thus don't have the rules to cut down on auto-completion. But you can simulate that by using 'ls' instead, or something similar. Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
generated by cgit v1.2.1 (git 2.18.0) at 2024-11-19 11:06:08 +0000