git/refs.c, branch v1.6.3

shorten_unambiguous_ref(): add strict mode

2009-04-13T16:36:44Z

Add the strict mode of abbreviation to shorten_unambiguous_ref(), i.e. the resulting ref won't trigger the ambiguous ref warning. All users of shorten_unambiguous_ref() still use the loose mode. Signed-off-by: Bert Wesarg Signed-off-by: Junio C Hamano

Merge branch 'jk/show-upstream'

2009-04-12T23:46:42Z

* jk/show-upstream: branch: show upstream branch when double verbose make get_short_ref a public function for-each-ref: add "upstream" format field for-each-ref: refactor refname handling for-each-ref: refactor get_short_ref function

Merge branch 'cc/bisect-filter'

2009-04-12T23:46:40Z

* cc/bisect-filter: (21 commits) rev-list: add "int bisect_show_flags" in "struct rev_list_info" rev-list: remove last static vars used in "show_commit" list-objects: add "void *data" parameter to show functions bisect--helper: string output variables together with "&&" rev-list: pass "int flags" as last argument of "show_bisect_vars" t6030: test bisecting with paths bisect: use "bisect--helper" and remove "filter_skipped" function bisect: implement "read_bisect_paths" to read paths in "$GIT_DIR/BISECT_NAMES" bisect--helper: implement "git bisect--helper" bisect: use the new generic "sha1_pos" function to lookup sha1 rev-list: call new "filter_skip" function patch-ids: use the new generic "sha1_pos" function to lookup sha1 sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1 rev-list: pass "revs" to "show_bisect_vars" rev-list: make "show_bisect_vars" non static rev-list: move code to show bisect vars into its own function rev-list: move bisect related code into its own file rev-list: make "bisect_list" variable local to "cmd_rev_list" refs: add "for_each_ref_in" function to refactor "for_each_*_ref" functions quote: add "sq_dequote_to_argv" to put unwrapped args in an argv array ...

make get_short_ref a public function

2009-04-08T06:22:15Z

Often we want to shorten a full ref name to something "prettier" to show a user. For example, "refs/heads/master" is often shown simply as "master", or "refs/remotes/origin/master" is shown as "origin/master". Many places in the code use a very simple formula: skip common prefixes like refs/heads, refs/remotes, etc. This is codified in the prettify_ref function. for-each-ref has a more correct (but more expensive) approach: consider the ref lookup rules, and try shortening as much as possible while remaining unambiguous. This patch makes the latter strategy globally available as shorten_unambiguous_ref. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

Merge branch 'jc/name-branch'

2009-04-06T07:43:44Z

* jc/name-branch: Don't permit ref/branch names to end with ".lock" check_ref_format(): tighten refname rules strbuf_check_branch_ref(): a helper to check a refname for a branch Fix branch -m @{-1} newname check-ref-format --branch: give Porcelain a way to grok branch shorthand strbuf_branchname(): a wrapper for branch name shorthands Rename interpret/substitute nth_last_branch functions Conflicts: Documentation/git-check-ref-format.txt

Merge branch 'cc/sha1-bsearch' into HEAD

2009-04-05T06:04:50Z

* cc/sha1-bsearch: (95 commits) patch-ids: use the new generic "sha1_pos" function to lookup sha1 sha1-lookup: add new "sha1_pos" function to efficiently lookup sha1 Update draft release notes to 1.6.3 GIT 1.6.2.2 send-email: ensure quoted addresses are rfc2047 encoded send-email: correct two tests which were going interactive Documentation: git-svn: fix trunk/fetch svn-remote key typo Mailmap: Allow empty email addresses to be mapped Cleanup warning about known issues in cvsimport documentation Documentation: Remove an odd "instead" send-email: ask_default should apply to all emails, not just the first send-email: don't attempt to prompt if tty is closed fix portability problem with IS_RUN_COMMAND_ERR Documentation: use "spurious .sp" XSLT if DOCBOOK_SUPPRESS_SP is set mailmap: resurrect lower-casing of email addresses builtin-clone.c: no need to strdup for setenv builtin-clone.c: make junk_pid static git-svn: add a double quiet option to hide git commits Update draft release notes to 1.6.2.2 Documentation: push.default applies to all remotes ...

refs: add "for_each_ref_in" function to refactor "for_each_*_ref" functions

2009-03-30T08:22:53Z

The "for_each_{tag,branch,remote,replace,}_ref" functions are redefined in terms of "for_each_ref_in" so that we can lose the hardcoded length of prefix strings from the code. Signed-off-by: Christian Couder

Merge branch 'db/push-cleanup'

2009-03-26T07:28:46Z

* db/push-cleanup: Move push matching and reporting logic into transport.c Use a common function to get the pretty name of refs Conflicts: transport.c

Don't permit ref/branch names to end with ".lock"

2009-03-25T00:02:20Z

We already skip over loose refs under $GIT_DIR/refs if the name ends with ".lock", so creating a branch named "foo.lock" will not appear in the output of "git branch", "git for-each-ref", nor will its commit be considered reachable by "git rev-list --all". In the latter case this is especially evil, as it may cause repository corruption when objects reachable only through such a ref are deleted by "git prune". It should be reasonably safe to deny use of ".lock" as a ref suffix. In prior versions of Git such branches would be "phantom branches"; you can create it, but you can't see it in "git branch" output. Signed-off-by: Shawn O. Pearce Signed-off-by: Junio C Hamano

check_ref_format(): tighten refname rules

2009-03-24T07:53:03Z

This changes the rules for refnames to forbid: (1) a refname that contains "@{" in it. Some people and foreign SCM converter may have named their branches as frotz@24 and we still want to keep supporting it. However, "git branch frotz@{24}" is a disaster. It cannot even checked out because "git checkout frotz@{24}" will interpret it as "detach the HEAD at twenty-fourth reflog entry of the frotz branch". (2) a refname that ends with a dot. We already reject a path component that begins with a dot, primarily to avoid ambiguous range interpretation. If we allowed ".B" as a valid ref, it is unclear if "A...B" means "in dot-B but not in A" or "either in A or B but not in both". But for this to be complete, we need also to forbid "A." to avoid "in B but not in A-dot". This was not a problem in the original range notation, but we should have added this restriction when three-dot notation was introduced. Unlike "no dot at the beginning of any path component" rule, this rule does not have to be "no dot at the end of any path component", because you cannot abbreviate the tail end away, similar to you can say "dot-B" to mean "refs/heads/dot-B". For these reasons, it is not likely people created branches with these names on purpose, but we have allowed such names to be used for quite some time, and it is possible that people created such branches by mistake or by accident. To help people with branches with such unfortunate names to recover, we still allow "branch -d 'bad.'" to delete such branches, and also allow "branch -m bad. good" to rename them. Signed-off-by: Junio C Hamano