On Mar 2, 2007, at 7:00 AM, Andy Parkins wrote:
On Thursday 2007, March 01, Brian Gernhardt wrote:
[attribute "image/png"]
path = *.png
show = "open %path%"
[attribute "text/plain"]
path = *.c
checkout = eol_to_local
The problem is that this flips the relationship. What you want to
do is
assign attributes to paths. This is assigning paths to attributes.
What about this:
doc/*.txt = text/plain AND documentation
In your system that would make
I'm sorry, I was assuming that information on what to do with each
attribute would be in the config file while a majority of the
attribute information was in an in-tree file. I was actually assuming:
.gitattributes:
*.png: image/png
logo.png: logo
*.c: text/plain source
.git/config:
[attribute "image"]
show = ...
merge = ...
With the ability to have additional "path =" entries for *local*
overrides/additions. Storing the handler information in
the .gitattributes is one of the worst things you could do, IMHO. It
assumes that people will have a homogenous environment to develop in,
and that every developer want to use the same tools. In some cases,
this may be true (eol_lf on checking for everybody), but not in
others. On my Mac, I'd like to use "open" for random file types, and
might want to use VERY different graphical merge than Linux users.
And OS X is a fairly Unix-like environment. Let's not even ponder
those poor fools using MinGW. ;-)
Actually, shouldn't the files also be run through the infilter to
check for changes caused by that, too?
I don't think so. The effect of the infilter will never be seen in
the
working tree, because it's applied on git-add. The previous
content with the
old attributes are already in the repository. However, it could be
that we
would have to force those files to be marked dirty in the index
(this is
already sounding bad), to force the application of the infilter on
next
checkin. Perhaps that's what you meant, and I'm being slow.
That's something like what I meant. And it sounds bad. Content
changes caused by attribute changes should likely be handled by the
user and made easy to detect instead of trying to handle it
automatically. So ignore my original statement on the matter.
~~ Brian
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html