git/builtin/check-ref-format.c, branch v2.6.2

standardize usage info string format

2015-01-14T17:32:04Z

This patch puts the usage info strings that were not already in docopt- like format into docopt-like format, which will be a litle easier for end users and a lot easier for translators. Changes include: - Placing angle brackets around fill-in-the-blank parameters - Putting dashes in multiword parameter names - Adding spaces to [-f|--foobar] to make [-f | --foobar] - Replacing * with [...] Signed-off-by: Alex Henrie Reviewed-by: Matthieu Moy Signed-off-by: Junio C Hamano

Change check_refname_format() to reject unnormalized refnames

2011-10-05T20:45:30Z

Since much of the infrastructure does not work correctly with unnormalized refnames, change check_refname_format() to reject them. Similarly, change "git check-ref-format" to reject unnormalized refnames by default. But add an option --normalize, which causes "git check-ref-format" to normalize the refname before checking its format, and print the normalized refname. This is exactly the behavior of the old --print option, which is retained but deprecated. Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

Inline function refname_format_print()

2011-10-05T20:45:30Z

Soon we will make printing independent of collapsing. Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

Make collapse_slashes() allocate memory for its result

2011-10-05T20:45:30Z

This will make upcoming changes a tiny bit easier. Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

Change check_ref_format() to take a flags argument

2011-10-05T20:45:29Z

Change check_ref_format() to take a flags argument that indicates what is acceptable in the reference name (analogous to "git check-ref-format"'s "--allow-onelevel" and "--refspec-pattern"). This is more convenient for callers and also fixes a failure in the test suite (and likely elsewhere in the code) by enabling "onelevel" and "refspec-pattern" to be allowed independently of each other. Also rename check_ref_format() to check_refname_format() to make it obvious that it deals with refnames rather than references themselves. Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

git check-ref-format: add options --allow-onelevel and --refspec-pattern

2011-10-05T20:45:29Z

Also add tests of the new options. (Actually, one big reason to add the new options is to make it easy to test check_ref_format(), though the options should also be useful to other scripts.) Interpret the result of check_ref_format() based on which types of refnames are allowed. However, because check_ref_format() can only return a single value, one test case is still broken. Specifically, the case "git check-ref-format --onelevel '*'" incorrectly succeeds because check_ref_format() returns CHECK_REF_FORMAT_ONELEVEL for this refname even though the refname is also CHECK_REF_FORMAT_WILDCARD. The type of check that leads to this failure is used elsewhere in "real" code and could lead to bugs; it will be fixed over the next few commits. Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

check-ref-format --print: Normalize refnames that start with slashes

2011-08-25T20:39:38Z

When asked if "refs///heads/master" is valid, check-ref-format says "Yes, it is well formed", and when asked to print canonical form, it shows "refs/heads/master". This is so that it can be tucked after "$GIT_DIR/" to form a valid pathname for a loose ref, and we normalize a pathname like "$GIT_DIR/refs///heads/master" to de-dup the slashes in it. Similarly, when asked if "/refs/heads/master" is valid, check-ref-format says "Yes, it is Ok", but the leading slash is not removed when printing, leading to "$GIT_DIR//refs/heads/master". Fix it to make sure such leading slashes are removed. Add tests that such refnames are accepted and normalized correctly. Signed-off-by: Michael Haggerty Signed-off-by: Junio C Hamano

Allow "check-ref-format --branch" from subdirectory

2010-08-06T17:01:45Z

check-ref-format --branch requires access to the repository to resolve refs like @{-1}. Noticed by Nguyễn Thái Ngọc Duy. Cc: Nguyễn Thái Ngọc Duy Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

check-ref-format: handle subcommands in separate functions

2010-08-06T17:00:39Z

The code for each subcommand should be easier to read and manipulate this way. Signed-off-by: Jonathan Nieder Signed-off-by: Junio C Hamano

Move 'builtin-*' into a 'builtin/' subdirectory

2010-02-22T22:29:41Z

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 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 builtin-shortlog.c builtin-shortlog.o [torvalds@nehalem git]$ em builtin-shortlog.c you get [torvalds@nehalem git]$ em buil [type] builtin/ builtin.h [torvalds@nehalem git]$ em builtin [auto-completes to] [torvalds@nehalem git]$ em builtin/sh [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 [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 Signed-off-by: Junio C Hamano