git.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Michael Haggerty <mhagger@alum.mit.edu>
To: Junio C Hamano <gitster@pobox.com>
Cc: "Jeff King" <peff@peff.net>,
	git@vger.kernel.org, "Henrik Grubbström" <grubba@grubba.org>,
	git-dev@github.com
Subject: Re: [BUG] gitattribute macro expansion oddity
Date: Wed, 11 Jan 2012 05:37:59 +0100	[thread overview]
Message-ID: <4F0D1227.5020509@alum.mit.edu> (raw)
In-Reply-To: <7v1ur7bhhe.fsf@alter.siamese.dyndns.org>

On 01/10/2012 06:22 PM, Junio C Hamano wrote:
> Regardless of this unrelated regression, after looking at what ec775c4
> wanted to do again, I am very much tempted to just revert it.
> 
> It aimed to take these three
> 
>         *       ident
>         foo     mybin
>         bar     mybin ident
> 
> and wanted to omit 'ident' from "foo" when there is this macro definition
> elsewhere:
> 
> 	[attr] mybin binary -ident
> 
> But the real point of the macro was that the users do not have to know
> their internals, iow, if you explicitly specify a pattern that overrides
> the contents of the macro, that explicit pattern should win. When deciding
> the value of "ident" attribute for path "foo", "* ident" is stronger than
> "foo mybin" (the latter of which does not say anything about 'ident'
> explicitly).

I like the simplicity of the rule "apply attributes in the order found
in the .gitattributes files" better than the rule you are proposing,
which seems like it will become more complicated to explain.

For example, it would seem under your rule for the above example that
the "mybin" macro should bestow on file foo the "binary" attribute and
also the "mybin" attribute (given that macros are themselves
attributes), but not "-ident".

You would also have to decide and explain whether a macro that invokes a
macro that sets or clears attribute "foo" is "weaker" than a simple
macro that clears or sets attribute "foo".

I have one real-life use case that would become more difficult with your
rule:

# Marker for textlike files whose EOL characters haven't been
# normalized yet:
[attr]eol-fixme -text !eol

*.cc text eol=lf


# Then later, perhaps in some subdirectory's .gitattributes:
SomeParticularScrewedUpFile.cc eol-fixme


The point of the eol-fixme macro is (1) to prevent git from throwing a
tantrum and (2) to mark the file as needing cleanup sometime in the future.

Michael

-- 
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/

      reply	other threads:[~2012-01-11  4:38 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-01-10  7:03 [BUG] gitattribute macro expansion oddity Jeff King
2012-01-10  9:01 ` Michael Haggerty
2012-01-10 17:11   ` Jeff King
2012-01-10 18:08     ` [PATCH] attr: don't confuse prefixes with leading directories Jeff King
2012-01-10 18:21       ` Jeff King
2012-01-10 19:23         ` Junio C Hamano
2012-01-10 19:28           ` Jeff King
2012-01-10 19:32             ` Jeff King
2012-01-10 20:25             ` Junio C Hamano
2012-01-10 22:31               ` Jeff King
2012-01-10 19:25       ` Junio C Hamano
2012-01-10 17:22 ` [BUG] gitattribute macro expansion oddity Junio C Hamano
2012-01-11  4:37   ` Michael Haggerty [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F0D1227.5020509@alum.mit.edu \
    --to=mhagger@alum.mit.edu \
    --cc=git-dev@github.com \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=grubba@grubba.org \
    --cc=peff@peff.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).