kernel/git - git - PowerEL Git System

Commit Graph

Author	SHA1	Message	Date
Jeff King	cc1b8d8bc6	docs: don't talk about $GIT_DIR/refs/ everywhere It is misleading to say that we pull refs from $GIT_DIR/refs/, because we may also consult the packed refs mechanism. These days we tend to treat the "refs hierarchy" as more of an abstract namespace that happens to be represented as $GIT_DIR/refs. At best, this is a minor inaccuracy, but at worst it can confuse users who then look in $GIT_DIR/refs and find that it is missing some of the refs they expected to see. This patch drops most uses of "$GIT_DIR/refs/", changing them into just "refs/*", under the assumption that users can handle the concept of an abstract refs namespace. There are a few things to note: - most cases just dropped the $GIT_DIR/ portion. But for cases where that left _just_ the word "refs", I changed it to "refs/" to help indicate that it was a hierarchy. I didn't do the same for longer paths (e.g., "refs/heads" remained, instead of becoming "refs/heads/"). - in some cases, no change was made, as the text was explicitly about unpacked refs (e.g., the discussion in git-pack-refs). - In some cases it made sense instead to note the existence of packed refs (e.g., in check-ref-format and rev-parse). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Junio C Hamano	8222153d84	Re-fix check-ref-format documentation mark-up It is not double-backslash we forbid; backslashes are forbidden since `a4c2e699` (Disallow '\' in ref names, 2009-05-08) Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Junio C Hamano	8ff883029a	check-ref-format documentation: fix enumeration mark-up The last item in the enumerated refname rule was mistakenly made into a sub-item of the 7th one. It should be the 8th one in the list on its own. Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Thomas Rast	0b444cdb19	Documentation: spell 'git cmd' without dash throughout The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in `647ac70` (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.	15 years ago
Junio C Hamano	38eedc634b	git check-ref-format --print Tolerating empty path components in ref names means each ref does not have a unique name. This creates difficulty for porcelains that want to see if two branches are equal. Add a helper associating to each ref a canonical name. If a user asks a porcelain to create a ref "refs/heads//master", the porcelain can run "git check-ref-format --print refs/heads//master" and only deal with "refs/heads/master" from then on. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Jonathan Nieder	604e0cb5cb	Documentation: describe check-ref-format --branch Unless one already knew, it was not obvious what sort of shorthand "git check-ref-format --branch" expands. Explain it. The --branch argument is not optional. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	15 years ago
Michael J Gruber	1a28725954	Documentation: clarify / requirement in 'git check-ref-format' 'git check-ref-format' checks for the presence of at least one '/', the idea being that there should be no refs directly below 'refs/', so there should be a category like 'heads/' or 'tags/' in a refname. Try and make this clearer in the man page. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Robin Rosenberg	a4c2e69936	Disallow '\' in ref names This is asking for trouble since '\' is a directory separator in Windows and thus may produce unpredictable results. Signed-off-by: Robin Rosenberg <robin.rosenberg@dewire.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Shawn O. Pearce	3e262b95c5	Don't permit ref/branch names to end with ".lock" 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 <spearce@spearce.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Junio C Hamano	cbdffe4093	check_ref_format(): tighten refname rules 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 <gitster@pobox.com>	16 years ago
Junio C Hamano	a31dca0393	check-ref-format --branch: give Porcelain a way to grok branch shorthand The command may not be the best place to add this new feature, but $ git check-ref-format --branch "@{-1}" allows Porcelains to figure out what branch you were on before the last branch switching. Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
David J. Mellor	cd747dc6dc	Documentation: minor grammatical fix in git-check-ref-format.txt Signed-off-by: David J. Mellor <dmellor@whistlingcat.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	16 years ago
Jonathan Nieder	ba020ef5eb	manpages: italicize git command names (which were in teletype font) The names of git commands are not meant to be entered at the commandline; they are just names. So we render them in italics, as is usual for command names in manpages. Using doit () { perl -e 'for (<>) { s/\`(git-[^\`.])\`/'\''\1'\''/g; print }' } for i in git.txt config.txt diff.txt blame.txt fetch.txt i18n.txt \ merge.txt pretty.txt pull.txt rev.txt urls.txt do doit <"$i" >"$i+" && mv "$i+" "$i" done git diff . Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Jonathan Nieder	483bc4f045	Documentation formatting and cleanup Following what appears to be the predominant style, format names of commands and commandlines both as `teletype text`. While we're at it, add articles ("a" and "the") in some places, italicize the name of the command in the manual page synopsis line, and add a comma or two where it seems appropriate. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Jonathan Nieder	b1889c36d8	Documentation: be consistent about "git-" versus "git " Since the git-* commands are not installed in $(bindir), using "git-command <parameters>" in examples in the documentation is not a good idea. On the other hand, it is nice to be able to refer to each command using one hyphenated word. (There is no escaping it, anyway: man page names cannot have spaces in them.) This patch retains the dash in naming an operation, command, program, process, or action. Complete command lines that can be entered at a shell (i.e., without options omitted) are made to use the dashless form. The changes consist only of replacing some spaces with hyphens and vice versa. After a "s/ /-/g", the unpatched and patched versions are identical. Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Christian Couder	9e1f0a85c6	documentation: move git(7) to git(1) As the "git" man page describes the "git" command at the end-user level, it seems better to move it to man section 1. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Dan McGee	5162e69732	Documentation: rename gitlink macro to linkgit Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock Asciidoc configuration: @@ -149,7 +153,10 @@ # Inline macros. # Backslash prefix required for escape processing. # (?s) re flag for line spanning. -(?su)[\\]?(?P<name>\w(\w\|-)?):(?P<target>\S?)(\[(?P<attrlist>.?)\])= + +# Explicit so they can be nested. +(?su)[\\]?(?P<name>(http\|https\|ftp\|file\|mailto\|callto\|image\|link)):(?P<target>\S?)(\[(?P<attrlist>.?)\])= + # Anchor: [[[id]]]. Bibliographic anchor. (?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]?)\]\]\]=anchor3 # Anchor: [[id,xreflabel]] This default regex now matches explicit values, and unfortunately in this case gitlink was being matched by just 'link', causing the wrong inline macro template to be applied. By renaming the macro, we can avoid being matched by the wrong regex. Signed-off-by: Dan McGee <dpmcgee@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>	17 years ago
Francis Daly	3742506578	Some doc typo fixes All should be clear enough, except perhaps committish / commitish. I just kept the more-used one within the current docs. [jc: with rephrasing of check-ref-format description later discussed on the list] Signed-off-by: Francis Daly <francis@daoine.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Shawn Pearce	87a56cd3b1	Elaborate on why ':' is a bad idea in a ref name. With the new cat-file syntax of 'v1.3.3:refs.c' we should mention it as part of the reason why ':' is not permitted in a ref name. Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Fredrik Kuivinen	7bd7f2804d	Remove trailing dot after short description Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se> Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	68283999f8	Forbid pattern maching characters in refnames. by marking '?', '*', and '[' as bad_ref_char(). Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago
Junio C Hamano	622ef9df19	ref-format documentation. Signed-off-by: Junio C Hamano <junkio@cox.net>	19 years ago

28 Commits (111fb858654b95355da05772b4dcdf91decc4721)