1. 16 Jul, 2008 1 commit
  2. 09 Jun, 2008 1 commit
    • René Scharfe's avatar
      Ignore .gitattributes in bare repositories · 2d35d556
      René Scharfe authored
      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: default avatarRene Scharfe <[email protected]>
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  3. 23 Apr, 2008 1 commit
  4. 07 Feb, 2008 1 commit
  5. 19 Oct, 2007 1 commit
  6. 19 Sep, 2007 1 commit
  7. 15 Aug, 2007 2 commits
    • Junio C Hamano's avatar
      attr.c: read .gitattributes from index as well. · 1a9d7e9b
      Junio C Hamano authored
      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: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      attr.c: refactoring · a4413118
      Junio C Hamano authored
      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: default avatarJunio C Hamano <[email protected]>
  8. 22 Apr, 2007 1 commit
  9. 18 Apr, 2007 1 commit
    • Junio C Hamano's avatar
      Fix funny types used in attribute value representation · a5e92abd
      Junio C Hamano authored
      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: default avatarJunio C Hamano <[email protected]>
  10. 17 Apr, 2007 1 commit
    • Junio C Hamano's avatar
      Allow more than true/false to attributes. · 515106fa
      Junio C Hamano authored
      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
      but you cannot use it, as nobody takes notice and acts on
      it yet.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  11. 15 Apr, 2007 3 commits
    • Junio C Hamano's avatar
      Change attribute negation marker from '!' to '-'. · e4aee10a
      Junio C Hamano authored
      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: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      Define a built-in attribute macro "binary". · fc2d07b0
      Junio C Hamano authored
      For binary files we would want to disable textual diff
      generation and automatic crlf conversion.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      attribute macro support · f48fd688
      Junio C Hamano authored
      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
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
  12. 14 Apr, 2007 3 commits
    • Junio C Hamano's avatar
      Teach 'diff' about 'diff' attribute. · 8c701249
      Junio C Hamano authored
      This makes paths that explicitly unset 'diff' attribute not to
      produce "textual" diffs from 'git-diff' family.
      Signed-off-by: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      Define 'crlf' attribute. · 35ebfd6a
      Junio C Hamano authored
      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: default avatarJunio C Hamano <[email protected]>
    • Junio C Hamano's avatar
      Add basic infrastructure to assign attributes to paths · d0bfd026
      Junio C Hamano authored
      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: default avatarJunio C Hamano <[email protected]>