On Thu, Jan 28, 2010 at 12:25:22PM -0800, Junio C Hamano wrote:
> "Yann Dirson" <ydirson@xxxxxxxxxx> writes:
>
> > Unless I missed something, I suggest the following plan:
> >
> > - document in maint that --check only takes worktree into account when
> > looking for .gitattributes, and more globally add a note to the
> > gitattributes manpage to explicitely say that too.
>
> It is not limited to "diff --check". The current implementation reads
> attributes only from the checked out work tree and/or from the index,
> depending on the direction of operation (e.g. checking out files to work
> tree reads from the index, I think). The same issue would affect "git
> archive" when generating a tarball from an older revision.
>
> The exception is $GIT_DIR/info/gitattributes, and for your particular
> purpose, I think it is the right one to use, because the entries in that
> file will apply regardless of which version you are examining patches
> from.
Well, it would have serious disavantages:
- if used alone, info/attributes is not obtained as part of the fetch (so
needs additional logic to deploy into dev's workspaces)
- if used together with .gitattribute files, would need to be synchronized
on pull, but then:
- would also need a policy to tell from which head to update
- mapping from a set of .gitattributes distributed in the tree is possibly
not trivial (I have not succeeded to affect files in a specific subdir
from the toplevel .gitattributes, and the manpage does not seem to mention
that info/gitattributes allows more flexibility in this respect)
> > - add a global flag to allow something like
> > "git --attributes-tree=<treeish> <command>"
>
> I am not sure if this is what we really want. It seems to me that it
> would make more sense to read from a relevant tree that the <command>
> is operating on, if we are to enhance the attributes implementation. If
> that <treeish> is a fixed one, it is not much better than having necessary
> entries in your $GIT_DIR/info/gitattributes file.
The idea with this flag is not to have <treeish> fixed, but more for use by
other commands/porcelain, who would make themselves the decision of which
treeish to take attributes from.
> > - adjust defaults to agreed-upon values
> > - add any config entries that would be meaningful
>
> Sorry, I have no idea what you mean by these two points.
That was partly intentionally vague, partly to blame on me being tired :)
- once the --attributes-tree feature would be in place, various commands like
diff-tree and show will be able to decide what makes more sense as a default
for the requested operation. Depending on the command and the particular
invocation, the default to use may not always be obvious, so I expect the
general default will be kept to the working tree.
- as ususal, people may want to use different settings than the default for
some commands, so support for overriding them via the config mechanism should
be put in place.
Anyway, how we specify the rule of which treeish to use for this will not be
possible with simply a treeish. That will probably have to use keywords
that would be meaningful in the context of the operation.
I would expect that all operations would be able to be told "worktree", "index",
and to be given any treeish - this in itself is a problem, I don't think we
already have a "treeish" syntax for worktree and index.
Additionally, "show" applied to a treeish would allow to tell to use the treeish
it is showing (or one of its parents); similarly when applied to "<committish>:<path>"
syntax; "diff-tree" would allow either the positive or negative reference; etc.
All that would also require a special syntax, so it can be specified as a
generally-useful value in the config file.
--
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