also sprach Johannes Schindelin <Johannes.Schindelin@gmx.de> [2007.09.15.16=
10 +0200]:
quoted text
> No.  Git is a source code management system.  Everything else that
> you can do with it is a bonus, a second class citizen.  Should we
> really try to support your use case, we will invariably affect the
> primary use case.

I thought git was primarily a content tracker... so it all comes
down to how to define content, doesn't it? But either way, we need
not discuss that because that definition depends a lot on context
and purpose and thus cannot be answered once and for all.

I understand that for the primary use case, tracking nothing more
than +x makes sense and should not be interfered with. This is why
I was proposing a policy-based approach. The primary use case is
unaffected, it's the default policy. Someone may choose to track
other mode bits or file/inode attributes, according to one of
several policies available with git, or even a custom policy. In
that case, the repository needs to be appropriately configured.

The reason why I say this should be done inside git rather than with
hooks and an external tool, such as metastore is quite simple: git
knows about every content entity in any tree of a repo and already
has a data node for each object. Rather than introducing a parallel
object database (shadow hierarchy or single file), it would make
a lot more sense and be way more robust to attach additional
information to these object nodes, wouldn't it?

So with "appropriately configured" above, I meant that one should be
able to say

  git-config core.track all

or

  git-config core.track mode+attr

or the default:

  git-config core.track 7666
  (read that as a umask, which masks out everything but the three
  x bits. I made it 7666 instead of 7677 because core.umask and
  core.sharedrepository then override the group and world bits if
  needed)

and have git do the right thing, rather than expecting those who
want to track more than the executable bit to assemble a brittle set
of hooks and metadata collectors+applicators and hope it all works.

I understand also that this is not top priority for git, which is
why I said earlier in the thread that the real difficulty might be
to get Junio to accept a patch. But I think that the patch would be
rather contained and small, having it all configurable would make it
unintrusive, and if we all test it real well, it should pass as
a bonus. After all, git can e.g upload patches to IMAP boxes, which
in my world clearly is bonus material as well.

Cheers,

--=20
martin;              (greetings from the heart of the sun.)
  \____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
=20
"the well-bred contradict other people.
 the wise contradict themselves."
                                                        -- oscar wilde
=20
spamtraps: madduck.bogus@madduck.net