summaryrefslogtreecommitdiff
path: root/builtin/branch.c
Commit message (Collapse)AuthorAgeFilesLines
...
| * | branch -d: simplify by using RESOLVE_REF_READINGRonnie Sahlberg2014-10-151-3/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When "git branch -d" reads the branch it is about to delete, it used to avoid passing the RESOLVE_REF_READING ('treat missing ref as error') flag because a symref pointing to a nonexistent ref would show up as missing instead of as something that could be deleted. To check if a ref is actually missing, we then check - is it a symref? - if not, did it resolve to null_sha1? Now we pass RESOLVE_REF_NO_RECURSE and the correct information is returned for a symref even when it points to a missing ref. Simplify by relying on RESOLVE_REF_READING. No functional change intended. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | branch -d: avoid repeated symref resolutionJonathan Nieder2014-10-151-1/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | If a repository gets in a broken state with too much symref nesting, it cannot be repaired with "git branch -d": $ git symbolic-ref refs/heads/nonsense refs/heads/nonsense $ git branch -d nonsense error: branch 'nonsense' not found. Worse, "git update-ref --no-deref -d" doesn't work for such repairs either: $ git update-ref -d refs/heads/nonsense error: unable to resolve reference refs/heads/nonsense: Too many levels of symbolic links Fix both by teaching resolve_ref_unsafe a new RESOLVE_REF_NO_RECURSE flag and passing it when appropriate. Callers can still read the value of a symref (for example to print a message about it) with that flag set --- resolve_ref_unsafe will resolve one level of symrefs and stop there. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | refs.c: change resolve_ref_unsafe reading argument to be a flags fieldRonnie Sahlberg2014-10-151-4/+5
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | resolve_ref_unsafe takes a boolean argument for reading (a nonexistent ref resolves successfully for writing but not for reading). Change this to be a flags field instead, and pass the new constant RESOLVE_REF_READING when we want this behaviour. While at it, swap two of the arguments in the function to put output arguments at the end. As a nice side effect, this ensures that we can catch callers that were unaware of the new API so they can be audited. Give the wrapper functions resolve_refdup and read_ref_full the same treatment for consistency. Signed-off-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jn/parse-config-slot'Junio C Hamano2014-10-201-10/+9
|\ \ \ | |/ / |/| | | | | | | | | | | | | | | | | Code cleanup. * jn/parse-config-slot: color_parse: do not mention variable name in error message pass config slots as pointers instead of offsets
| * | color_parse: do not mention variable name in error messagejn/parse-config-slotJeff King2014-10-141-2/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Originally the color-parsing function was used only for config variables. It made sense to pass the variable name so that the die() message could be something like: $ git -c color.branch.plain=bogus branch fatal: bad color value 'bogus' for variable 'color.branch.plain' These days we call it in other contexts, and the resulting error messages are a little confusing: $ git log --pretty='%C(bogus)' fatal: bad color value 'bogus' for variable '--pretty format' $ git config --get-color foo.bar bogus fatal: bad color value 'bogus' for variable 'command line' This patch teaches color_parse to complain only about the value, and then return an error code. Config callers can then propagate that up to the config parser, which mentions the variable name. Other callers can provide a custom message. After this patch these three cases now look like: $ git -c color.branch.plain=bogus branch error: invalid color value: bogus fatal: unable to parse 'color.branch.plain' from command-line config $ git log --pretty='%C(bogus)' error: invalid color value: bogus fatal: unable to parse --pretty format $ git config --get-color foo.bar bogus error: invalid color value: bogus fatal: unable to parse default color value Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | pass config slots as pointers instead of offsetsJonathan Nieder2014-10-141-8/+8
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Many config-parsing helpers, like parse_branch_color_slot, take the name of a config variable and an offset to the "slot" name (e.g., "color.branch.plain" is passed along with "13" to effectively pass "plain"). This is leftover from the time that these functions would die() on error, and would want the full variable name for error reporting. These days they do not use the full variable name at all. Passing a single pointer to the slot name is more natural, and lets us more easily adjust the callers to use skip_prefix to avoid manually writing offset numbers. This is effectively a continuation of 9e1a5eb, which did the same for parse_diff_color_slot. This patch covers all of the remaining similar constructs. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | use skip_prefix() to avoid more magic numbersrs/more-uses-of-skip-prefixRené Scharfe2014-10-071-16/+13
| | | | | | | | | | | | | | | | | | Continue where ae021d87 (use skip_prefix to avoid magic numbers) left off and use skip_prefix() in more places for determining the lengths of prefix strings to avoid using dependent constants and other indirect methods. Signed-off-by: Rene Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | branch: clean up commit flags after merge-filter walkjk/branch-verbose-mergedJeff King2014-09-181-14/+19
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When we run `branch --merged`, we use prepare_revision_walk with the merge-filter marked as UNINTERESTING. Any branch tips that are marked UNINTERESTING after it returns must be ancestors of that commit. As we iterate through the list of refs to show, we check item->commit->object.flags to see whether it was marked. This interacts badly with --verbose, which will do a separate walk to find the ahead/behind information for each branch. There are two bad things that can happen: 1. The ahead/behind walk may get the wrong results, because it can see a bogus UNINTERESTING flag leftover from the merge-filter walk. 2. We may omit some branches if their tips are involved in the ahead/behind traversal of a branch shown earlier. The ahead/behind walk carefully cleans up its commit flags, meaning it may also erase the UNINTERESTING flag that we expect to check later. We can solve this by moving the merge-filter state for each ref into its "struct ref_item" as soon as we finish the merge-filter walk. That fixes (2). Then we are free to clear the commit flags we used in the walk, fixing (1). Note that we actually do away with the matches_merge_filter helper entirely here, and inline it between the revision walk and the flag-clearing. This ensures that nobody accidentally calls it at the wrong time (it is only safe to check in that instant between the setting and clearing of the global flag). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'sb/prepare-revision-walk-error-check'Junio C Hamano2014-09-091-1/+3
|\ \ | |/ |/| | | | | * sb/prepare-revision-walk-error-check: prepare_revision_walk(): check for return value in all places
| * prepare_revision_walk(): check for return value in all placessb/prepare-revision-walk-error-checkStefan Beller2014-08-121-1/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | Even the documentation tells us: You should check if it returns any error (non-zero return code) and if it does not, you can start using get_revision() to do the iteration. In preparation for this commit, I grepped all occurrences of prepare_revision_walk and added error messages, when there were none. Signed-off-by: Stefan Beller <stefanbeller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | refactor skip_prefix to return a booleanJeff King2014-06-201-3/+3
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The skip_prefix() function returns a pointer to the content past the prefix, or NULL if the prefix was not found. While this is nice and simple, in practice it makes it hard to use for two reasons: 1. When you want to conditionally skip or keep the string as-is, you have to introduce a temporary variable. For example: tmp = skip_prefix(buf, "foo"); if (tmp) buf = tmp; 2. It is verbose to check the outcome in a conditional, as you need extra parentheses to silence compiler warnings. For example: if ((cp = skip_prefix(buf, "foo")) /* do something with cp */ Both of these make it harder to use for long if-chains, and we tend to use starts_with() instead. However, the first line of "do something" is often to then skip forward in buf past the prefix, either using a magic constant or with an extra strlen(3) (which is generally computed at compile time, but means we are repeating ourselves). This patch refactors skip_prefix() to return a simple boolean, and to provide the pointer value as an out-parameter. If the prefix is not found, the out-parameter is untouched. This lets you write: if (skip_prefix(arg, "foo ", &arg)) do_foo(arg); else if (skip_prefix(arg, "bar ", &arg)) do_bar(arg); Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* use wildmatch() directly without fnmatch() wrapperNguyễn Thái Ngọc Duy2014-02-201-1/+1
| | | | | | | Make it clear that we don't use fnmatch() anymore. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'cc/starts-n-ends-with'Junio C Hamano2013-12-171-3/+3
|\ | | | | | | | | | | | | | | | | | | | | Remove a few duplicate implementations of prefix/suffix comparison functions, and rename them to starts_with and ends_with. * cc/starts-n-ends-with: replace {pre,suf}fixcmp() with {starts,ends}_with() strbuf: introduce starts_with() and ends_with() builtin/remote: remove postfixcmp() and use suffixcmp() instead environment: normalize use of prefixcmp() by removing " != 0"
| * replace {pre,suf}fixcmp() with {starts,ends}_with()cc/starts-n-ends-withChristian Couder2013-12-051-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Leaving only the function definitions and declarations so that any new topic in flight can still make use of the old functions, replace existing uses of the prefixcmp() and suffixcmp() with new API functions. The change can be recreated by mechanically applying this: $ git grep -l -e prefixcmp -e suffixcmp -- \*.c | grep -v strbuf\\.c | xargs perl -pi -e ' s|!prefixcmp\(|starts_with\(|g; s|prefixcmp\(|!starts_with\(|g; s|!suffixcmp\(|ends_with\(|g; s|suffixcmp\(|!ends_with\(|g; ' on the result of preparatory changes in this series. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jk/robustify-parse-commit'Junio C Hamano2013-12-051-1/+1
|\ \ | |/ |/| | | | | | | | | | | | | | | * jk/robustify-parse-commit: checkout: do not die when leaving broken detached HEAD use parse_commit_or_die instead of custom message use parse_commit_or_die instead of segfaulting assume parse_commit checks for NULL commit assume parse_commit checks commit->object.parsed log_tree_diff: die when we fail to parse a commit
| * assume parse_commit checks for NULL commitJeff King2013-10-241-1/+1
| | | | | | | | | | | | | | | | | | The parse_commit function will check whether it was passed a NULL commit pointer, and if so, return an error. There is no need for callers to check this separately. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'jx/branch-vv-always-compare-with-upstream'Junio C Hamano2013-11-181-1/+7
|\ \ | | | | | | | | | | | | | | | | | | Hot-fix for a regression. * jx/branch-vv-always-compare-with-upstream: branch: fix --verbose output column alignment
| * | branch: fix --verbose output column alignmentjx/branch-vv-always-compare-with-upstreamTorstein Hegge2013-11-181-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Commit f2e0873 (branch: report invalid tracking branch as gone) removed an early return from fill_tracking_info() in the path taken when 'git branch -v' lists a branch in sync with its upstream. This resulted in an unconditionally added space in front of the subject line: $ git branch -v * master f5eb3da commit pushed to upstream topic f935eb6 unpublished topic Instead, only add the trailing space if a decoration have been added. To catch this kind of whitespace breakage in the tests, be a bit less smart when filtering the output through sed. Signed-off-by: Torstein Hegge <hegge@resisty.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | branch: trivial style fixFelipe Contreras2013-10-311-2/+1
| | | | | | | | | | | | | | | Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'jx/branch-vv-always-compare-with-upstream'Junio C Hamano2013-09-201-15/+21
|\ \ \ | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | "git branch -v -v" (and "git status") did not distinguish among a branch that does not build on any other branch, a branch that is in sync with the branch it builds on, and a branch that is configured to build on some other branch that no longer exists. * jx/branch-vv-always-compare-with-upstream: status: always show tracking branch even no change branch: report invalid tracking branch as gone
| * | branch: report invalid tracking branch as goneJiang Xin2013-08-261-15/+21
| |/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Command "git branch -vv" will report tracking branches, but invalid tracking branches are also reported. This is because the function stat_tracking_info() can not distinguish invalid tracking branch from other cases which it would not like to report, such as there is no upstream settings at all, or nothing is changed between one branch and its upstream. Junio suggested missing upstream should be reported [1] like: $ git branch -v -v master e67ac84 initial * topic 3fc0f2a [topicbase: gone] topic $ git status # On branch topic # Your branch is based on 'topicbase', but the upstream is gone. # (use "git branch --unset-upstream" to fixup) ... $ git status -b -s ## topic...topicbase [gone] ... In order to do like that, we need to distinguish these three cases (i.e. no tracking, with configured but no longer valid tracking, and with tracking) in function stat_tracking_info(). So the refactored function stat_tracking_info() has three return values: -1 (with "gone" base), 0 (no base), and 1 (with base). If the caller does not like to report tracking info when nothing changed between the branch and its upstream, simply checks if num_theirs and num_ours are both 0. [1]: http://thread.gmane.org/gmane.comp.version-control.git/231830/focus=232288 Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Jiang Xin <worldhello.net@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | branch, commit, name-rev: ease up boolean conditionsStefan Beller2013-08-071-1/+2
| | | | | | | | | | | | | | | | | | | | Now that the variables are set by OPT_BOOL, which makes sure to have the values being 0 or 1 after parsing, we do not need the double negation to map any other value to 1 for integer variables. Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Replace deprecated OPT_BOOLEAN by OPT_BOOLStefan Beller2013-08-051-5/+5
|/ | | | | | | | | | | | This task emerged from b04ba2bb (parse-options: deprecate OPT_BOOLEAN, 2011-09-27). All occurrences of the respective variables have been reviewed and none of them relied on the counting up mechanism, but all of them were using the variable as a true boolean. This patch does not change semantics of any command intentionally. Signed-off-by: Stefan Beller <stefanbeller@googlemail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* branch: colour upstream branchesFelipe Contreras2013-04-151-8/+28
| | | | | | | | Otherwise when using 'git branch -vv' it's hard to see them among so much output. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jm/branch-rename-nothing-error'Junio C Hamano2013-04-031-1/+3
|\ | | | | | | | | | | | | | | "git branch -m" without any argument noticed an error, but with an incorrect error message. * jm/branch-rename-nothing-error: branch: give better message when no names specified for rename
| * branch: give better message when no names specified for renameJonathon Mah2013-03-311-1/+3
| | | | | | | | | | Signed-off-by: Jonathon Mah <me@JonathonMah.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'nd/branch-show-rebase-bisect-state'Junio C Hamano2013-04-011-1/+25
|\ \ | |/ |/| | | | | | | | | | | | | | | | | | | | | Add a bit more information to "git status" during a rebase/bisect session. * nd/branch-show-rebase-bisect-state: status, branch: fix the misleading "bisecting" message branch: show more information when HEAD is detached status: show more info than "currently not on any branch" wt-status: move wt_status_get_state() out to wt_status_print() wt-status: split wt_status_state parsing function out wt-status: move strbuf into read_and_strip_branch()
| * status, branch: fix the misleading "bisecting" messageNguyễn Thái Ngọc Duy2013-03-231-1/+1
| | | | | | | | | | | | | | | | | | The current message is "bisecting %s" (or "bisecting branch %s"). "%s" is the current branch when we started bisecting. Clarify that to avoid confusion with good and bad refs passed to "bisect" command. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * branch: show more information when HEAD is detachedNguyễn Thái Ngọc Duy2013-03-161-1/+25
| | | | | | | | | | | | | | | | | | | | This prints more helpful info when HEAD is detached: is it detached because of bisect or rebase? What is the original branch name in those cases? Is it detached because the user checks out a remote ref or a tag (and which one)? Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'nd/branch-error-cases'Junio C Hamano2013-03-211-0/+27
|\ \ | | | | | | | | | | | | | | | | | | | | | "git branch" had more cases where it did not bother to check nonsense command line parameters. * nd/branch-error-cases: branch: segfault fixes and validation
| * | branch: segfault fixes and validationNguyễn Thái Ngọc Duy2013-02-231-0/+27
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | branch_get() can return NULL (so far on detached HEAD only) but some code paths in builtin/branch.c cannot deal with that and cause segfaults. While at there, make sure to bail out when the user gives 2 or more branches with --set-upstream-to or --unset-upstream, where only the first branch is processed and the rest silently dropped. Reported-by: Per Cederqvist <cederp@opera.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'nd/branch-error-cases'Junio C Hamano2013-02-071-9/+15
|\ \ \ | |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Fix various error messages and conditions in "git branch", e.g. we advertised "branch -d/-D" to remove one or more branches but actually implemented removal of zero or more branches---request to remove no branches was not rejected. * nd/branch-error-cases: branch: let branch filters imply --list docs: clarify git-branch --list behavior branch: mark more strings for translation branch: give a more helpful message on redundant arguments branch: reject -D/-d without branch name
| * | branch: let branch filters imply --listJeff King2013-01-311-0/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Currently, a branch filter like `--contains`, `--merged`, or `--no-merged` is ignored when we are not in listing mode. For example: git branch --contains=foo bar will create the branch "bar" from the current HEAD, ignoring the `--contains` argument entirely. This is not very helpful. There are two reasonable behaviors for git here: 1. Flag an error; the arguments do not make sense. 2. Implicitly go into `--list` mode This patch chooses the latter, as it is more convenient, and there should not be any ambiguity with attempting to create a branch; using `--contains` and not wanting to list is nonsensical. That leaves the case where an explicit modification option like `-d` is given. We already catch the case where `--list` is given alongside `-d` and flag an error. With this patch, we will also catch the use of `--contains` and other filter options alongside `-d`. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | branch: mark more strings for translationNguyễn Thái Ngọc Duy2013-01-301-5/+6
| | | | | | | | | | | | | | | | | | Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | Merge branch 'nd/edit-branch-desc-while-detached' into HEADJunio C Hamano2013-01-301-4/+4
| |\ \ | | | | | | | | | | | | | | | | * nd/edit-branch-desc-while-detached: branch: no detached HEAD check when editing another branch's description
| * | | branch: give a more helpful message on redundant argumentsNguyễn Thái Ngọc Duy2013-01-301-2/+2
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | branch: reject -D/-d without branch nameNguyễn Thái Ngọc Duy2013-01-301-2/+4
| | | | | | | | | | | | | | | | | | | | Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | Merge branch 'jc/custom-comment-char'Junio C Hamano2013-02-041-5/+5
|\ \ \ \ | |_|_|/ |/| | | | | | | | | | | | | | | | | | | | | | | | | | | Allow a configuration variable core.commentchar to customize the character used to comment out the hint lines in the edited text from the default '#'. * jc/custom-comment-char: Allow custom "comment char"
| * | | Allow custom "comment char"Junio C Hamano2013-01-161-5/+5
| |/ / | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Some users do want to write a line that begin with a pound sign, #, in their commit log message. Many tracking system recognise a token of #<bugid> form, for example. The support we offer these use cases is not very friendly to the end users. They have a choice between - Don't do it. Avoid such a line by rewrapping or indenting; and - Use --cleanup=whitespace but remove all the hint lines we add. Give them a way to set a custom comment char, e.g. $ git -c core.commentchar="%" commit so that they do not have to do either of the two workarounds. [jc: although I started the topic, all the tests and documentation updates, many of the call sites of the new strbuf_add_commented_*() functions, and the change to git-submodule.sh scripted Porcelain are from Ralf.] Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | Merge branch 'nd/edit-branch-desc-while-detached'Junio C Hamano2013-02-011-4/+4
|\ \ \ | |/ / |/| / | |/ | | | | | | | | Attempt to "branch --edit-description" an existing branch, while being on a detached HEAD, errored out. * nd/edit-branch-desc-while-detached: branch: no detached HEAD check when editing another branch's description
| * branch: no detached HEAD check when editing another branch's descriptionNguyễn Thái Ngọc Duy2013-01-301-4/+4
| | | | | | | | | | Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'nd/maint-branch-desc-doc'Junio C Hamano2013-01-091-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Teach various forms of "format-patch" command line to identify what branch the patches are taken from, so that the branch description is picked up in more cases. * nd/maint-branch-desc-doc: format-patch: pick up branch description when no ref is specified format-patch: pick up correct branch name from symbolic ref t4014: a few more tests on cover letter using branch description branch: delete branch description if it's empty config.txt: a few lines about branch.<name>.description
| * | branch: delete branch description if it's emptyNguyễn Thái Ngọc Duy2013-01-031-1/+1
| |/ | | | | | | | | Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | branch: show targets of deleted symrefs, not sha1sRené Scharfe2012-10-181-8/+11
| | | | | | | | | | | | | | | | | | | | git branch reports the abbreviated hash of the head commit of a deleted branch to make it easier for a user to undo the operation. For symref branches this doesn't help. Print the symref target instead for them. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | branch: skip commit checks when deleting symref branchesRené Scharfe2012-10-181-2/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Before a branch is deleted, we check that it points to a valid commit. With -d we also check that the commit is a merged; this check is not done with -D. The reason for that is that commits pointed to by branches should never go missing; if they do then something broke and it's better to stop instead of adding to the mess. And a non-merged commit may contain changes that are worth preserving, so we require the stronger option -D instead of -d to get rid of them. If a branch consists of a symref, these concerns don't apply. Deleting such a branch can't make a commit become unreferenced, so we don't need to check if it is merged, or even if it is actually a valid commit. Skip them in that case. This allows us to delete dangling symref branches. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | branch: delete symref branch, not its targetRené Scharfe2012-10-181-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | If a branch that is to be deleted happens to be a symref to another branch, the current code removes the targeted branch instead of the one it was called for. Change this surprising behaviour and delete the symref branch instead. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | branch: factor out delete_branch_config()René Scharfe2012-10-181-5/+10
| | | | | | | | | | | | | | Provide a small helper function for deleting branch config sections. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | branch: factor out check_branch_commit()René Scharfe2012-10-181-12/+21
| | | | | | | | | | | | | | | | Move the code to perform checks on the tip commit of a branch to its own function. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'rj/path-cleanup'Junio C Hamano2012-09-141-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | * rj/path-cleanup: Call mkpathdup() rather than xstrdup(mkpath(...)) Call git_pathdup() rather than xstrdup(git_path("...")) path.c: Use vsnpath() in the implementation of git_path() path.c: Don't discard the return value of vsnpath() path.c: Remove the 'git_' prefix from a file scope function
| * | Call mkpathdup() rather than xstrdup(mkpath(...))Ramsay Jones2012-09-041-1/+1
| |/ | | | | | | | | | | | | | | | | In addition to updating the xstrdup(mkpath(...)) call sites with mkpathdup(), we also fix a memory leak (in merge_3way()) caused by neglecting to free the memory allocated to the 'base_name' variable. Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
View Lorry Controller Status