- 05 8月, 2011 2 次提交
-
-
由 Michael Haggerty 提交于
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: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Michael Haggerty 提交于
Setting attributes to arbitrary values ("attribute=value") is now supported, so it is no longer necessary for this comment to justify prohibiting '=' in an attribute name. Signed-off-by: NMichael Haggerty <mhagger@alum.mit.edu> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 4月, 2011 1 次提交
-
-
由 Ramsay Jones 提交于
In particular, sparse issues the "symbol 'a_symbol' was not declared. Should it be static?" warnings for the following symbols: attr.c:468:12: 'git_etc_gitattributes' attr.c:476:5: 'git_attr_system' vcs-svn/svndump.c:282:6: 'svndump_read' vcs-svn/svndump.c:417:5: 'svndump_init' vcs-svn/svndump.c:432:6: 'svndump_deinit' vcs-svn/svndump.c:445:6: 'svndump_reset' The symbols in attr.c only require file scope, so we add the static modifier to their declaration. The symbols in vcs-svn/svndump.c are external symbols, and they already have extern declarations in the "svndump.h" header file, so we simply include the header in svndump.c. Signed-off-by: NRamsay Jones <ramsay@ramsay1.demon.co.uk> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 16 3月, 2011 1 次提交
-
-
由 Jonathan Nieder 提交于
test-lib sets $HOME to protect against pollution from user settings, so setting GIT_ATTR_NOGLOBAL would be redundant. Simplify by eliminating support for that environment variable altogether. GIT_ATTR_NOGLOBAL was introduced in v1.7.4-rc0~208^2 (Add global and system-wide gitattributes, 2010-09-01) as an undocumented feature for use by the test suite. It never ended up being used (neither within git.git nor in other projects). This patch does not affect GIT_ATTR_NOSYSTEM, which should still be useful. Helped-by: NJeff King <peff@peff.net> Signed-off-by: NJonathan Nieder <jrnieder@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 9月, 2010 1 次提交
-
-
由 Petr Onderka 提交于
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: NPetr Onderka <gsvick@gmail.com> Signed-off-by: NMatthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 20 5月, 2010 1 次提交
-
-
由 Eyvind Bernhardsen 提交于
As discussed on the list, "crlf" is not an optimal name. Linus suggested "text", which is much better. Signed-off-by: NEyvind Bernhardsen <eyvind.bernhardsen@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 11 4月, 2010 3 次提交
-
-
由 Henrik Grubbström 提交于
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: NHenrik Grubbström <grubba@grubba.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Henrik Grubbström 提交于
When using macros it isn't inconceivable to have an attribute being set by a macro, and then being reset explicitly. Signed-off-by: NHenrik Grubbström <grubba@grubba.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Henrik Grubbström 提交于
When debug_set() was called during macro expansion, it received a pointer to a struct git_attr rather than a string. Signed-off-by: NHenrik Grubbström <grubba@grubba.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 1月, 2010 1 次提交
-
-
由 Junio C Hamano 提交于
The function took (name, namelen) as its arguments, but all the public callers wanted to pass a full string. Demote the counted-string interface to an internal API status, and allow public callers to just pass the string to the function. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 01 7月, 2009 1 次提交
-
-
由 René Scharfe 提交于
Free the memory allocated for struct strbuf pathbuf when we're done. Signed-off-by: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 6月, 2009 1 次提交
-
-
由 Linus Torvalds 提交于
Shifting 'unsigned char' or 'unsigned short' left can result in sign extension errors, since the C integer promotion rules means that the unsigned char/short will get implicitly promoted to a signed 'int' due to the shift (or due to other operations). This normally doesn't matter, but if you shift things up sufficiently, it will now set the sign bit in 'int', and a subsequent cast to a bigger type (eg 'long' or 'unsigned long') will now sign-extend the value despite the original expression being unsigned. One example of this would be something like unsigned long size; unsigned char c; size += c << 24; where despite all the variables being unsigned, 'c << 24' ends up being a signed entity, and will get sign-extended when then doing the addition in an 'unsigned long' type. Since git uses 'unsigned char' pointers extensively, we actually have this bug in a couple of places. I may have missed some, but this is the result of looking at git grep '[^0-9 ][ ]*<<[ ][a-z]' -- '*.c' '*.h' git grep '<<[ ]*24' which catches at least the common byte cases (shifting variables by a variable amount, and shifting by 24 bits). I also grepped for just 'unsigned char' variables in general, and converted the ones that most obviously ended up getting implicitly cast immediately anyway (eg hash_name(), encode_85()). In addition to just avoiding 'unsigned char', this patch also tries to use a common idiom for the delta header size thing. We had three different variations on it: "& 0x7fUL" in one place (getting the sign extension right), and "& ~0x80" and "& 0x7f" in two other places (not getting it right). Apart from making them all just avoid using "unsigned char" at all, I also unified them to then use a simple "& 0x7f". I considered making a sparse extension which warns about doing implicit casts from unsigned types to signed types, but it gets rather complex very quickly, so this is just a hack. Signed-off-by: NLinus Torvalds <torvalds@linux-foundation.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 02 5月, 2009 1 次提交
-
-
由 Felipe Contreras 提交于
Essentially; s/type* /type */ as per the coding guidelines. Signed-off-by: NFelipe Contreras <felipe.contreras@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 18 4月, 2009 1 次提交
-
-
由 Nguyễn Thái Ngọc Duy 提交于
This instructs attr mechanism, not to look into working .gitattributes at all. Needed by tools that does not handle working directory, such as "git archive". Signed-off-by: NNguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 14 3月, 2009 1 次提交
-
-
由 Junio C Hamano 提交于
Traditionally we used .gitattributes file from the work tree if exists, and otherwise read from the index as a fallback. When switching to a branch that has an updated .gitattributes file, and entries in it give different attributes to other paths being checked out, we should instead read from the .gitattributes in the index. This breaks a use case of fixing incorrect entries in the .gitattributes in the work tree (without adding it to the index) and checking other paths out, though. $ edit .gitattributes ;# mark foo.dat as binary $ rm foo.dat $ git checkout foo.dat Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 17 7月, 2008 1 次提交
-
-
由 Dmitry Potapov 提交于
If PATH_MAX on your system is smaller than a path stored in the git repo, it may cause the buffer overflow in prepare_attr_stack. Signed-off-by: NDmitry Potapov <dpotapov@gmail.com> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 10 6月, 2008 1 次提交
-
-
由 René Scharfe 提交于
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: NRene Scharfe <rene.scharfe@lsrfire.ath.cx> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 4月, 2008 1 次提交
-
-
由 Matthew Ogilvie 提交于
Signed-off-by: NMatthew Ogilvie <mmogilvi_git@miniinfo.net> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 07 2月, 2008 1 次提交
-
-
由 Junio C Hamano 提交于
There was an embarrassing pair of off-by-one miscounting that failed to match path "a/b/c" when "a/.gitattributes" tried to name it with relative path "b/c". This fixes it. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 19 10月, 2007 1 次提交
-
-
由 Steffen Prohaska 提交于
git may segfault if gitattributes contains an invalid entry. A test is added to t0020 that triggers the segfault. The parsing code is fixed to avoid the crash. Signed-off-by: NSteffen Prohaska <prohaska@zib.de> Signed-off-by: NShawn O. Pearce <spearce@spearce.org>
-
- 19 9月, 2007 1 次提交
-
-
由 Pierre Habouzit 提交于
Signed-off-by: NPierre Habouzit <madcoder@debian.org> Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 15 8月, 2007 2 次提交
-
-
由 Junio C Hamano 提交于
This makes .gitattributes files to be read from the index when they are not checked out to the work tree. This is in line with the way we always allowed low-level tools to operate in sparsely checked out work tree in a reasonable way. It swaps the order of new file creation and converting the blob to work tree representation; otherwise when we are in the middle of checking out .gitattributes we would notice an empty but unwritten .gitattributes file in the work tree and will ignore the copy in the index. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
由 Junio C Hamano 提交于
This splits out a common routine that parses a single line of attribute file and adds it to the attr_stack. It should not change any behaviour, other than attrs array in the attr_stack structure is now grown with alloc_nr() macro, instead of one by one, which relied on xrealloc() to give enough slack to be efficient enough. Signed-off-by: NJunio C Hamano <gitster@pobox.com>
-
- 23 4月, 2007 1 次提交
-
-
由 Alex Riesen 提交于
Reallocated wrong size. Noticed on Ubuntu 7.04 probably because it has some malloc diagnostics in libc: "git-read-tree --reset -u HEAD" aborted in the test. Valgrind sped up the debugging greatly: took me 10 minutes. Signed-off-by: NAlex Riesen <raa.lkml@gmail.com> Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 19 4月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
It was bothering me a lot that I abused small integer values casted to (void *) to represent non string values in gitattributes. This corrects it by making the type of attribute values (const char *), and using the address of a few statically allocated character buffer to denote true/false. Unset attributes are represented as having NULLs as their values. Added in-header documentation to explain how git_checkattr() routine should be called. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 17 4月, 2007 1 次提交
-
-
由 Junio C Hamano 提交于
This allows you to define three values (and possibly more) to each attribute: true, false, and unset. Typically the handlers that notice and act on attribute values treat "unset" attribute to mean "do your default thing" (e.g. crlf that is unset would trigger "guess from contents"), so being able to override a setting to an unset state is actually useful. - If you want to set the attribute value to true, have an entry in .gitattributes file that mentions the attribute name; e.g. *.o binary - If you want to set the attribute value explicitly to false, use '-'; e.g. *.a -diff - If you want to make the attribute value _unset_, perhaps to override an earlier entry, use '!'; e.g. *.a -diff c.i.a !diff This also allows string values to attributes, with the natural syntax: attrname=attrvalue but you cannot use it, as nobody takes notice and acts on it yet. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 16 4月, 2007 3 次提交
-
-
由 Junio C Hamano 提交于
At the same time, we do not want to allow arbitrary strings for attribute names, as we are likely to want to extend the syntax later. Allow only alnum, dash, underscore and dot for now. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
For binary files we would want to disable textual diff generation and automatic crlf conversion. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This adds "attribute macros" (for lack of better name). So far, we have low-level attributes such as crlf and diff, which are defined in operational terms --- setting or unsetting them on a particular path directly affects what is done to the path. For example, in order to decline diffs or crlf conversions on a binary blob, no diffs on PostScript files, and treat all other files normally, you would have something like these: * diff crlf *.ps !diff proprietary.o !diff !crlf That is fine as the operation goes, but gets unwieldy rather rapidly, when we start adding more low-level attributes that are defined in operational terms. A near-term example of such an attribute would be 'merge-3way' which would control if git should attempt the usual 3-way file-level merge internally, or leave merging to a specialized external program of user's choice. When it is added, we do _not_ want to force the users to update the above to: * diff crlf merge-3way *.ps !diff proprietary.o !diff !crlf !merge-3way The way this patch solves this issue is to realize that the attributes the user is assigning to paths are not defined in terms of operations but in terms of what they are. All of the three low-level attributes usually make sense for most of the files that sane SCM users have git operate on (these files are typically called "text'). Only a few cases, such as binary blob, need exception to decline the "usual treatment given to text files" -- and people mark them as "binary". So this allows the $GIT_DIR/info/alternates and .gitattributes at the toplevel of the project to also specify attributes that assigns other attributes. The syntax is '[attr]' followed by an attribute name followed by a list of attribute names: [attr] binary !diff !crlf !merge-3way When "binary" attribute is set to a path, if the path has not got diff/crlf/merge-3way attribute set or unset by other rules, this rule unsets the three low-level attributes. It is expected that the user level .gitattributes will be expressed mostly in terms of attributes based on what the files are, and the above sample would become like this: (built-in attribute configuration) [attr] binary !diff !crlf !merge-3way * diff crlf merge-3way (project specific .gitattributes) proprietary.o binary (user preference $GIT_DIR/info/attributes) *.ps !diff There are a few caveats. * As described above, you can define these macros only in $GIT_DIR/info/attributes and toplevel .gitattributes. * There is no attempt to detect circular definition of macro attributes, and definitions are evaluated from bottom to top as usual to fill in other attributes that have not yet got values. The following would work as expected: [attr] text diff crlf [attr] ps text !diff *.ps ps while this would most likely not (I haven't tried): [attr] ps text !diff [attr] text diff crlf *.ps ps * When a macro says "[attr] A B !C", saying that a path does not have attribute A does not let you tell anything about attributes B or C. That is, given this: [attr] text diff crlf [attr] ps text !diff *.txt !ps path hello.txt, which would match "*.txt" pattern, would have "ps" attribute set to zero, but that does not make text attribute of hello.txt set to false (nor diff attribute set to true). Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
- 14 4月, 2007 3 次提交
-
-
由 Junio C Hamano 提交于
This makes paths that explicitly unset 'diff' attribute not to produce "textual" diffs from 'git-diff' family. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This defines the semantics of 'crlf' attribute as an example. When a path has this attribute unset (i.e. '!crlf'), autocrlf line-end conversion is not applied. Eventually we would want to let users to build a pipeline of processing to munge blob data to filesystem format (and in the other direction) based on combination of attributes, and at that point the mechanism in convert_to_{git,working_tree}() that looks at 'crlf' attribute needs to be enhanced. Perhaps the existing 'crlf' would become the first step in the input chain, and the last step in the output chain. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-
由 Junio C Hamano 提交于
This adds the basic infrastructure to assign attributes to paths, in a way similar to what the exclusion mechanism does based on $GIT_DIR/info/exclude and .gitignore files. An attribute is just a simple string that does not contain any whitespace. They can be specified in $GIT_DIR/info/attributes file, and .gitattributes file in each directory. Each line in these files defines a pattern matching rule. Similar to the exclusion mechanism, a later match overrides an earlier match in the same file, and entries from .gitattributes file in the same directory takes precedence over the ones from parent directories. Lines in $GIT_DIR/info/attributes file are used as the lowest precedence default rules. A line is either a comment (an empty line, or a line that begins with a '#'), or a rule, which is a whitespace separated list of tokens. The first token on the line is a shell glob pattern. The rest are names of attributes, each of which can optionally be prefixed with '!'. Such a line means "if a path matches this glob, this attribute is set (or unset -- if the attribute name is prefixed with '!'). For glob matching, the same "if the pattern does not have a slash in it, the basename of the path is matched with fnmatch(3) against the pattern, otherwise, the path is matched with the pattern with FNM_PATHNAME" rule as the exclusion mechanism is used. This does not define what an attribute means. Tying an attribute to various effects it has on git operation for paths that have it will be specified separately. Signed-off-by: NJunio C Hamano <junkio@cox.net>
-