summaryrefslogtreecommitdiff
path: root/t/t0003-attributes.sh
AgeCommit message (Collapse)AuthorFilesLines
2021-02-16attr: do not respect symlinks for in-tree .gitattributesLibravatar Jeff King1-3/+33
The attributes system may sometimes read in-tree files from the filesystem, and sometimes from the index. In the latter case, we do not resolve symbolic links (and are not likely to ever start doing so). Let's open filesystem links with O_NOFOLLOW so that the two cases behave consistently. As a bonus, this means that git will not follow such symlinks to read and parse out-of-tree paths. In some cases this could have security implications, as a malicious repository can cause Git to open and read arbitrary files. It could already feed arbitrary content to the parser, but in certain setups it might be able to exfiltrate data from those paths (e.g., if an automated service operating on the malicious repo reveals its stderr to an attacker). Note that O_NOFOLLOW only prevents following links for the path itself, not intermediate directories in the path. At first glance, it seems like ln -s /some/path in-repo might still look at "in-repo/.gitattributes", following the symlink to "/some/path/.gitattributes". However, if "in-repo" is a symbolic link, then we know that it has no git paths below it, and will never look at its .gitattributes file. We will continue to support out-of-tree symbolic links (e.g., in $GIT_DIR/info/attributes); this just affects in-tree links. When a symbolic link is encountered, the contents are ignored and a warning is printed. POSIX specifies ELOOP in this case, so the user would generally see something like: warning: unable to access '.gitattributes': Too many levels of symbolic links Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-20t0003: don't use `test_must_fail attr_check`Libravatar Denton Liu1-15/+15
In an effort to remove test_must_fail for all invocations not related to git or test-tool, replace invocations of `test_must_fail attr_check` with a plain attr_check call with the $expect argument set to the actual value output by git. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-20t0003: use test_must_be_empty()Libravatar Denton Liu1-3/+3
In several places, we used `test_line_count = 0` to check for an empty file. Although this is correct, it's overkill. Use test_must_be_empty() instead because it's more suited for this purpose. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-12-20t0003: use named parameters in attr_check()Libravatar Denton Liu1-7/+4
We had named the parameters in attr_check() but $2 was being used instead of $expect. Make all variable accesses in attr_check() use named variables instead of numbered arguments for clarity. While we're at it, add variable assignments to the &&-chain. These aren't ever expected to fail but if a future developer ever adds some code above the assignments and they could fail in some way, the intact &&-chain will ensure that the failure is caught. Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-01-22attr: do not mark queried macros as unsetLibravatar Jeff King1-0/+20
Since 60a12722ac (attr: remove maybe-real, maybe-macro from git_attr, 2017-01-27), we will always mark an attribute macro (e.g., "binary") that is specifically queried for as "unspecified", even though listing _all_ attributes would display it at set. E.g.: $ echo "* binary" >.gitattributes $ git check-attr -a file file: binary: set file: diff: unset file: merge: unset file: text: unset $ git check-attr binary file file: binary: unspecified The problem stems from an incorrect conversion of the optimization from 06a604e670 (attr: avoid heavy work when we know the specified attr is not defined, 2014-12-28). There we tried in collect_some_attrs() to avoid even looking at the attr_stack when the user has asked for "foo" and we know that "foo" did not ever appear in any .gitattributes file. It used a flag "maybe_real" in each attribute struct, where "real" meant that the attribute appeared in an actual file (we have to make this distinction because we also create an attribute struct for any names that are being queried). But as explained in that commit message, the meaning of "real" was tangled with some special cases around macros. When 60a12722ac later refactored the macro code, it dropped maybe_real entirely. This missed the fact that "maybe_real" could be unset for two reasons: because of a macro, or because it was never found during parsing. This had two results: - the optimization in collect_some_attrs() ceased doing anything meaningful, since it no longer kept track of "was it found during parsing" - worse, it actually kicked in when the caller _did_ ask about a macro by name, causing us to mark it as unspecified It should be possible to salvage this optimization, but let's start with just removing the remnants. It hasn't been doing anything (except creating bugs) since 60a12722ac, and nobody seems to have noticed the performance regression. It's more important to fix the correctness problem clearly first. I've added two tests here. The second one actually shows off the bug. The test of "check-attr -a" is not strictly necessary, but we currently do not test attribute macros much, and the builtin "binary" not at all. So this increases our general test coverage, as well as making sure we didn't mess up this related case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-08-27Merge branch 'sg/test-must-be-empty'Libravatar Junio C Hamano1-2/+1
Test fixes. * sg/test-must-be-empty: tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>' tests: use 'test_must_be_empty' instead of 'test_cmp /dev/null <out>' tests: use 'test_must_be_empty' instead of 'test ! -s' tests: use 'test_must_be_empty' instead of '! test -s'
2018-08-21tests: use 'test_must_be_empty' instead of 'test_cmp <empty> <out>'Libravatar SZEDER Gábor1-2/+1
Using 'test_must_be_empty' is shorter and more idiomatic than >empty && test_cmp empty out as it saves the creation of an empty file. Furthermore, sometimes the expected empty file doesn't have such a descriptive name like 'empty', and its creation is far away from the place where it's finally used for comparison (e.g. in 't7600-merge.sh', where two expected empty files are created in the 'setup' test, but are used only about 500 lines later). These cases were found by instrumenting 'test_cmp' to error out the test script when it's used to compare empty files, and then converted manually. Note that even after this patch there still remain a lot of cases where we use 'test_cmp' to check empty files: - Sometimes the expected output is not hard-coded in the test, but 'test_cmp' is used to ensure that two similar git commands produce the same output, and that output happens to be empty, e.g. the test 'submodule update --merge - ignores --merge for new submodules' in 't7406-submodule-update.sh'. - Repetitive common tasks, including preparing the expected results and running 'test_cmp', are often extracted into a helper function, and some of this helper's callsites expect no output. - For the same reason as above, the whole 'test_expect_success' block is within a helper function, e.g. in 't3070-wildmatch.sh'. - Or 'test_cmp' is invoked in a loop, e.g. the test 'cvs update (-p)' in 't9400-git-cvsserver-server.sh'. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2018-07-16t0000-t0999: fix broken &&-chainsLibravatar Eric Sunshine1-12/+12
Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2017-02-01attr: support quoting pathname patterns in C styleLibravatar Nguyễn Thái Ngọc Duy1-0/+26
Full pattern must be quoted. So 'pat"t"ern attr' will give exactly 'pat"t"ern', not 'pattern'. Also clarify that leading whitespaces are not part of the pattern and document comment syntax. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Stefan Beller <sbeller@google.com> Signed-off-by: Brandon Williams <bmwill@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-03-14Merge branch 'jc/check-attr-honor-working-tree'Libravatar Junio C Hamano1-22/+40
"git check-attr" when (trying to) work on a repository with a working tree did not work well when the working tree was specified via --work-tree (and obviously with --git-dir). The command also works in a bare repository but it reads from the (possibly stale, irrelevant and/or nonexistent) index, which may need to be fixed to read from HEAD, but that is a completely separate issue. As a related tangent to this separate issue, we may want to also fix "check-ignore", which refuses to work in a bare repository, to also operate in a bare one. * jc/check-attr-honor-working-tree: check-attr: move to the top of working tree when in non-bare repository t0003: do not chdir the whole test process
2014-02-06check-attr: move to the top of working tree when in non-bare repositoryLibravatar Junio C Hamano1-0/+10
Lasse Makholm noticed that running "git check-attr" from a place totally unrelated to $GIT_DIR and $GIT_WORK_TREE does not give expected results. I think it is because the command does not say it wants to call setup_work_tree(). We still need to support use cases where only a bare repository is involved, so unconditionally requiring a working tree would not work well. Instead, make a call only in a non-bare repository. We may want to see if we want to do a similar fix in the opposite direction to check-ignore. The command unconditionally requires a working tree, but it should be usable in a bare repository just like check-attr attempts to be. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-02-06t0003: do not chdir the whole test processLibravatar Junio C Hamano1-22/+30
Moving to some other directory and letting the remainder of the test pieces to expect that they start there is a bad practice. The test that contains chdir itself may fail (or by mistake skipped via the GIT_SKIP_TESTS mechanism) in which case the remainder may operate on files in unexpected places. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-09t: trivial whitespace cleanupsLibravatar Felipe Contreras1-1/+0
Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-03-01Sync with 1.8.1.5Libravatar Junio C Hamano1-1/+2
2013-03-01Make !pattern in .gitattributes non-fatalLibravatar Thomas Rast1-1/+2
Before 82dce99 (attr: more matching optimizations from .gitignore, 2012-10-15), .gitattributes did not have any special treatment of a leading '!'. The docs, however, always said The rules how the pattern matches paths are the same as in `.gitignore` files; see linkgit:gitignore[5]. By those rules, leading '!' means pattern negation. So 82dce99 correctly determined that this kind of line makes no sense and should be disallowed. However, users who actually had a rule for files starting with a '!' are in a bad position: before 82dce99 '!' matched that literal character, so it is conceivable that users have .gitattributes with such lines in them. After 82dce99 the unescaped version was disallowed in such a way that git outright refuses to run(!) most commands in the presence of such a .gitattributes. It therefore becomes very hard to fix, let alone work with, such repositories. Let's at least allow the users to fix their repos: change the fatal error into a warning. Reported-by: mathstuf@gmail.com Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-01-10Merge branch 'nd/wildmatch'Libravatar Junio C Hamano1-0/+37
Allows pathname patterns in .gitignore and .gitattributes files with double-asterisks "foo/**/bar" to match any number of directory hierarchies. * nd/wildmatch: wildmatch: replace variable 'special' with better named ones compat/fnmatch: respect NO_FNMATCH* even on glibc wildmatch: fix "**" special case t3070: Disable some failing fnmatch tests test-wildmatch: avoid Windows path mangling Support "**" wildcard in .gitignore and .gitattributes wildmatch: make /**/ match zero or more directories wildmatch: adjust "**" behavior wildmatch: fix case-insensitive matching wildmatch: remove static variable force_lower_case wildmatch: make wildmatch's return value compatible with fnmatch t3070: disable unreliable fnmatch tests Integrate wildmatch to git wildmatch: follow Git's coding convention wildmatch: remove unnecessary functions Import wildmatch from rsync ctype: support iscntrl, ispunct, isxdigit and isprint ctype: make sane_ctype[] const array Conflicts: Makefile
2012-11-09Merge branch 'nd/attr-match-optim-more'Libravatar Jeff King1-0/+10
Start laying the foundation to build the "wildmatch" after we can agree on its desired semantics. * nd/attr-match-optim-more: attr: more matching optimizations from .gitignore gitignore: make pattern parsing code a separate function exclude: split pathname matching code into a separate function exclude: fix a bug in prefix compare optimization exclude: split basename matching code into a separate function exclude: stricten a length check in EXC_FLAG_ENDSWITH case
2012-10-15Support "**" wildcard in .gitignore and .gitattributesLibravatar Nguyễn Thái Ngọc Duy1-0/+37
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-10-15attr: more matching optimizations from .gitignoreLibravatar Nguyễn Thái Ngọc Duy1-0/+10
.gitattributes and .gitignore share the same pattern syntax but has separate matching implementation. Over the years, ignore's implementation accumulates more optimizations while attr's stays the same. This patch reuses the core matching functions that are also used by excluded_from_list. excluded_from_list and path_matches can't be merged due to differences in exclude and attr, for example: * "!pattern" syntax is forbidden in .gitattributes. As an attribute can be unset (i.e. set to a special value "false") or made back to unspecified (i.e. not even set to "false"), "!pattern attr" is unclear which one it means. * we support attaching attributes to directories, but git-core internally does not currently make use of attributes on directories. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-07-27test-lib: provide case insensitivity as a prerequisiteLibravatar Michael J Gruber1-10/+0
Case insensitivity plays a role in several tests and is tested in several tests. Therefore, move the test from t003 into the test lib and use the prerequisite in t0003. Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10Merge the attributes fix in from maint-1.6.7 branchLibravatar Junio C Hamano1-0/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10Merge the attributes fix in from maint-1.6.6 branchLibravatar Junio C Hamano1-0/+10
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-01-10attr: don't confuse prefixes with leading directoriesLibravatar Jeff King1-0/+10
When we prepare the attribute stack for a lookup on a path, we start with the cached stack from the previous lookup (because it is common to do several lookups in the same directory hierarchy). So the first thing we must do in preparing the stack is to pop any entries that point to directories we are no longer interested in. For example, if our stack contains gitattributes for: foo/bar/baz foo/bar foo but we want to do a lookup in "foo/bar/bleep", then we want to pop the top element, but retain the others. To do this we walk down the stack from the top, popping elements that do not match our lookup directory. However, the test do this simply checked strncmp, meaning we would mistake "foo/bar/baz" as a leading directory of "foo/bar/baz_plus". We must also check that the character after our match is '/', meaning we matched the whole path component. There are two special cases to consider: 1. The top of our attr stack has the empty path. So we must not check for '/', but rather special-case the empty path, which always matches. 2. Typically when matching paths in this way, you would also need to check for a full string match (i.e., the character after is '\0'). We don't need to do so in this case, though, because our path string is actually just the directory component of the path to a file (i.e., we know that it terminates with "/", because the filename comes after that). Helped-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-10-17Merge branch 'bc/attr-ignore-case'Libravatar Junio C Hamano1-1/+58
* bc/attr-ignore-case: attr.c: respect core.ignorecase when matching attribute patterns attr: read core.attributesfile from git_default_core_config builtin/mv.c: plug miniscule memory leak cleanup: use internal memory allocation wrapper functions everywhere attr.c: avoid inappropriate access to strbuf "buf" member Conflicts: transport-helper.c
2011-10-11attr.c: respect core.ignorecase when matching attribute patternsLibravatar Brandon Casey1-1/+58
When core.ignorecase is true, the file globs configured in the .gitattributes file should be matched case-insensitively against the paths in the working directory. Let's do so. Plus, add some tests. The last set of tests is performed only on a case-insensitive filesystem. Those tests make sure that git handles the case where the .gitignore file resides in a subdirectory and the user supplies a path that does not match the case in the filesystem. In that case^H^H^H^Hsituation, part of the path supplied by the user is effectively interpreted case-insensitively, and part of it is dependent on the setting of core.ignorecase. git will currently only match the portion of the path below the directory holding the .gitignore file according to the setting of core.ignorecase. This is also partly future-proofing. Currently, git builds the attr stack based on the path supplied by the user, so we don't have to do anything special (like use strcmp_icase) to handle the parts of that path that don't match the filesystem with respect to case. If git instead built the attr stack by scanning the repository, then the paths in the origin field would not necessarily match the paths supplied by the user. If someone makes a change like that in the future, these tests will notice. Signed-off-by: Brandon Casey <drafnel@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-22t0003: remove extra whitespacesLibravatar Junio C Hamano1-46/+22
The test had excess whitespaces everywhere that made it harder to read than necessary. Remove them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-09-22Teach '--cached' option to check-attrLibravatar Jay Soffian1-4/+21
This option causes check-attr to consider .gitattributes only from the index, ignoring .gitattributes from the working tree. This allows the command to be used in situations where a working tree does not exist. Signed-off-by: Jay Soffian <jaysoffian@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Normalize pathsLibravatar Michael Haggerty1-2/+2
Normalize the path arguments (relative to the working tree root, if applicable) before looking up their attributes. This requires passing the prefix down the call chain. This fixes two test cases for different reasons: * "unnormalized paths" is fixed because the .gitattribute-file-seeking code is not confused into reading the top-level file twice. * "relative paths" is fixed because the canonical pathnames are passed to get_check_attr() or get_all_attrs(), allowing them to match the pathname patterns as expected. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Demonstrate problems with relative pathsLibravatar Michael Haggerty1-1/+14
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Demonstrate problems with unnormalized pathsLibravatar Michael Haggerty1-0/+9
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: test that no output is written to stderrLibravatar Michael Haggerty1-2/+3
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Fix command-line handling to match docsLibravatar Michael Haggerty1-1/+0
According to the git-check-attr synopsis, if the '--stdin' option is used then no pathnames are expected on the command line. Change the behavior to match this description; namely, if '--stdin' is used but not '--', then treat all command-line arguments as attribute names. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Drive two tests using the same raw dataLibravatar Michael Haggerty1-36/+23
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Add an --all option to show all attributesLibravatar Michael Haggerty1-0/+24
Add new usage patterns git check-attr [-a | --all] [--] pathname... git check-attr --stdin [-a | --all] < <list-of-paths> which display all attributes associated with the specified file(s). Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Error out if no pathnames are specifiedLibravatar Michael Haggerty1-0/+2
If no pathnames are passed as command-line arguments and the --stdin option is not specified, fail with the error message "No file specified". Add tests of this behavior. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Add tests of command-line parsingLibravatar Michael Haggerty1-0/+7
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04git-check-attr: Add missing "&&"Libravatar Michael Haggerty1-1/+1
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-08-04Disallow the empty string as an attribute nameLibravatar Michael Haggerty1-0/+6
Previously, it was possible to have a line like "file.txt =foo" in a .gitattribute file, after which an invocation like "git check-attr '' -- file.txt" would succeed. This patch disallows both constructs. Please note that any existing .gitattributes file that tries to set an empty attribute will now trigger the error message "error: : not a valid attribute name" whereas previously the nonsense was allowed through. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-11-24Merge branch 'en/and-cascade-tests'Libravatar Junio C Hamano1-1/+1
* en/and-cascade-tests: (25 commits) t4124 (apply --whitespace): use test_might_fail t3404: do not use 'describe' to implement test_cmp_rev t3404 (rebase -i): introduce helper to check position of HEAD t3404 (rebase -i): move comment to description t3404 (rebase -i): unroll test_commit loops t3301 (notes): use test_expect_code for clarity t1400 (update-ref): use test_must_fail t1502 (rev-parse --parseopt): test exit code from "-h" t6022 (renaming merge): chain test commands with && test-lib: introduce test_line_count to measure files tests: add missing &&, batch 2 tests: add missing && Introduce sane_unset and use it to ensure proper && chaining t7800 (difftool): add missing && t7601 (merge-pull-config): add missing && t7001 (mv): add missing && t6016 (rev-list-graph-simplify-history): add missing && t5602 (clone-remote-exec): add missing && t4026 (color): remove unneeded and unchained command t4019 (diff-wserror): add lots of missing && ... Conflicts: t/t7006-pager.sh
2010-11-09tests: add missing &&Libravatar Jonathan Nieder1-1/+1
Breaks in a test assertion's && chain can potentially hide failures from earlier commands in the chain. Commands intended to fail should be marked with !, test_must_fail, or test_might_fail. The examples in this patch do not require that. Signed-off-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-10-29t0003: properly quote $HOMELibravatar Thomas Rast1-1/+1
6df42ab (Add global and system-wide gitattributes, 2010-09-01) forgot to quote one instance of $HOME in the tests. This would be valid according to POSIX, but bash 4 helpfully declines to execute the command in question with an "ambiguous redirection" error. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-09-29Merge branch 'po/etc-gitattributes'Libravatar Junio C Hamano1-0/+13
* po/etc-gitattributes: Add global and system-wide gitattributes Conflicts: Documentation/config.txt Makefile
2010-09-01Add global and system-wide gitattributesLibravatar Petr Onderka1-0/+13
Allow gitattributes to be set globally and system wide. This way, settings for particular file types can be set in one place and apply for all user's repositories. The location of system-wide attributes file is $(prefix)/etc/gitattributes. The location of the global file can be configured by setting core.attributesfile. Some parts of the code were copied from the implementation of the same functionality in config.c. Signed-off-by: Petr Onderka <gsvick@gmail.com> Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-08-29t0003: add missing && at end of linesLibravatar Matthieu Moy1-5/+5
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-10attr: Expand macros immediately when encountered.Libravatar Henrik Grubbström1-0/+9
When using macros it is otherwise hard to know whether an attribute set by the macro should override an already set attribute. Consider the following .gitattributes file: [attr]mybinary binary -ident * ident foo.bin mybinary bar.bin mybinary ident Without this patch both foo.bin and bar.bin will have the ident attribute set, which is probably not what the user expects. With this patch foo.bin will have an unset ident attribute, while bar.bin will have it set. Signed-off-by: Henrik Grubbström <grubba@grubba.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2010-04-10attr: Allow multiple changes to an attribute on the same line.Libravatar Henrik Grubbström1-0/+6
When using macros it isn't inconceivable to have an attribute being set by a macro, and then being reset explicitly. Signed-off-by: Henrik Grubbström <grubba@grubba.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-10-12check-attr: Add --stdin optionLibravatar Dmitry Potapov1-0/+17
This allows multiple paths to be specified on stdin. Signed-off-by: Dmitry Potapov <dpotapov@gmail.com> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
2008-06-09Ignore .gitattributes in bare repositoriesLibravatar René Scharfe1-0/+35
Attributes can be specified at three different places: the internal table of default values, the file $GIT_DIR/info/attributes and files named .gitattributes in the work tree. Since bare repositories don't have a work tree, git should ignore any .gitattributes files there. This patch makes git do that, so the only way left for a user to specify attributes in a bare repository is the file info/attributes (in addition to changing the defaults and recompiling). In addition, git-check-attr is now allowed to run without a work tree. Like any user of the code in attr.c, it ignores the .gitattributes files when run in a bare repository. It can still read from info/attributes. Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2008-04-22Merge branch 'maint-1.5.4' into maintLibravatar Junio C Hamano1-0/+8
* maint-1.5.4: svn-git: Use binmode for reading/writing binary rev maps diff options documentation: refer to --diff-filter in --name-status git-svn bug with blank commits and author file archive.c: format_subst - fixed bogus argument to memchr copy.c: copy_fd - correctly report write errors gitattributes: Fix subdirectory attributes specified from root directory
2008-04-22gitattributes: Fix subdirectory attributes specified from root directoryLibravatar Matthew Ogilvie1-0/+8
Signed-off-by: Matthew Ogilvie <mmogilvi_git@miniinfo.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>