From: Junio C Hamano <hidden> Date: 2016-06-15 22:43:30
Dmitry Kakurin [off-list ref] writes:
1. It may be better to combine all these files into one (.gitmeta) with different sections
Merging what has traditionally been known as .gitignore's
capability to attributes has been discussed, and I think it
would make sense in longer term, as 'this path pattern is to be
ignored' is just a special case of a more general attribute.
And "precious" handling would naturally fit there. However, as
the .gitignore and .git/info/exclude has been as old as git
itself (I think it was introduced around early May 2005), I do
not see us even start talking about deprecating .gitignore.
I do not think .gitmodules fits the model of what .gitattributes
solves. .gitattributes is about the attribute of paths, while
.gitmodules is about attribute of subprojects, and one attribute
of a subproject is where in the superproject directory hierarchy
it sits at.
I do not know what you are talking about with .gitacls.
Personally I am not interested in turning git into a back-up
program at all, so if you are talking beyond what has already
been suggested as "owner", "group" and "perms" attributes that
could be stored in .gitattributes, I do not think it belongs to
git.
2. Storing metadata in regular source-controlled files feels wrong to
me.
You are free to _feel_ whatever you want without thinking, but
please keep that _feeling_ to yourself, and speak it out after
making it into an _opinion_, which would take a bit of thinking
about it first. For example, think about what you could do
without confusing a total newbie after the initial clone. You
cannot avoid chicken-and-egg problem. I think reading from
index as a fallback measure when work tree file is missing is a
very good compromise we came up recently. The wish of the user
(i.e. the owner of the work tree) overrides what is in the
index, and the index is how the repository contents are
initially propagated back to the work tree.
From: Johannes Schindelin <hidden> Date: 2016-06-15 22:43:31
Hi,
On Sat, 25 Aug 2007, Dmitry Kakurin wrote:
----- Original Message ----- From: "Junio C Hamano" [off-list ref]
quoted
quoted
2. Storing metadata in regular source-controlled files feels wrong to
me.
You are free to _feel_ whatever you want without thinking, but
I did quite a bit of thinking before posting it. Not sure what made you
think otherwise.
Well, it certainly appears to me that your proposal to move metadata from
the working tree (where it is visible, and easily editable with the editor
of _your_ choice) to the index (where it is hidden, and could only be
edited with _yet another_ git command) is not well thought through.
It certainly would make some common operation much more complicated, for
no gain at all.
Should you still not be convinced, please find some convincing mails by
Linus (which are much longer than I would have the patience to write)
where he goes into detail _why_ it is _wrong_ to _hide_ things away from
the working tree.
(Just a small hint: git is much more powerful _because_ it keeps metadata
visibly in the filesystem.)
As for your proposal to munge the different metadata files into sections
of _one_ file: I doubt that this is "cleaner" or "more elegant" than what
we have now. For one, if a script fscks up one file, it does not fsck up
the others.
For another, scripts do not have to jump through hoops to edit the
metadata files, as long as they do not have sections (containing
completely independent informations).
Ciao,
Dscho
From: martin f krafft <hidden> Date: 2016-06-15 22:43:31
also sprach Junio C Hamano [off-list ref] [2007.08.26.0637 +0200]:
quoted
1. It may be better to combine all these files into one
(.gitmeta) with different sections
Merging what has traditionally been known as .gitignore's
capability to attributes has been discussed, and I think it would
make sense in longer term, as 'this path pattern is to be ignored'
is just a special case of a more general attribute.
I tried to find related threads in the archives but failed. If
someone has a pointer handy, I'd appreciate it. Alternatively,
please feel free to just bounce related messages from your own
archives to me.
I am interested in this mainly because of a somewhat related idea of
honouring .gitignore/* in case it's a directory [0].
0. http://marc.info/?l=git&m=118725982332041&w=2
--
martin; (greetings from the heart of the sun.)
\____ echo mailto: !#^."<*>"|tr "<*> mailto:" net@madduck
"the question of whether computers can think
is like the question of whether submarines can swim."
-- edsgar w. dijkstra
spamtraps: madduck.bogus@madduck.net
1. It may be better to combine all these files into one (.gitmeta) with
different sections
Sorry about entering this discussion so late.
I am just wondering about one thing.
Couldn't all this directory/ownership/permission tracing be easily done by
using hooks?
E.g. Having a pre-status and pre-commit hook one could fire up a program/script
to collect all the extra info he wants to trace and store it somewhere
(typically in some traced file).
The other way round one could have a post-checkout hook and he could arrange
it to fire up some program to look into the extra-info file to set up
all the meta-data he wants.
This would be very flexible and would permit to manage absolutely /any/ kind
of the metadata leaving absolute freedom about how to do so.
Am I missing something here?
Sergio
From: David Kastrup <hidden> Date: 2016-06-15 22:43:31
Sergio Callegari [off-list ref] writes:
Couldn't all this directory/ownership/permission tracing be easily
done by using hooks? E.g. Having a pre-status and pre-commit hook
one could fire up a program/script to collect all the extra info he
wants to trace and store it somewhere (typically in some traced
file). The other way round one could have a post-checkout hook and
he could arrange it to fire up some program to look into the
extra-info file to set up all the meta-data he wants.
This would be very flexible and would permit to manage absolutely
/any/ kind of the metadata leaving absolute freedom about how to do
so.
Am I missing something here?
From: Petr Baudis <hidden> Date: 2016-06-15 22:43:31
On Mon, Aug 27, 2007 at 05:48:34PM CEST, David Kastrup wrote:
Sergio Callegari [off-list ref] writes:
quoted
Couldn't all this directory/ownership/permission tracing be easily
done by using hooks? E.g. Having a pre-status and pre-commit hook
one could fire up a program/script to collect all the extra info he
wants to trace and store it somewhere (typically in some traced
file). The other way round one could have a post-checkout hook and
he could arrange it to fire up some program to look into the
extra-info file to set up all the meta-data he wants.
This would be very flexible and would permit to manage absolutely
/any/ kind of the metadata leaving absolute freedom about how to do
so.
Am I missing something here?
Merging.
Fetching.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
Couldn't all this directory/ownership/permission tracing be easily
done by using hooks? E.g. Having a pre-status and pre-commit hook
one could fire up a program/script to collect all the extra info he
wants to trace and store it somewhere (typically in some traced
file). The other way round one could have a post-checkout hook and
he could arrange it to fire up some program to look into the
extra-info file to set up all the meta-data he wants.
This would be very flexible and would permit to manage absolutely
/any/ kind of the metadata leaving absolute freedom about how to do
so.
Am I missing something here?
Merging.
Sorry, maybe I am really missing something, since merging does not look to me
as an issue.
Why cannot git simply do the merging in the working tree as it normally
does, including merging of the traced metadata file generated by the metadata
helpers invoked via the hooks?
Only, again more hooks are needed and likely a post-merge hook, so that at
the end of the merge, the metadata can be applied.
Only, to have things going on smoothly, one should be so wise to assure that
the metadata helpers save metadata as nice, sorted text files in order to
minimize the burden of manual intervention if there are conflicts in
metadata merging.
BTW. Having a post-checkout hook could also help getting rid of unwanted
empty directories, couldn't it?
Sergio
Couldn't all this directory/ownership/permission tracing be easily
done by using hooks? E.g. Having a pre-status and pre-commit hook
one could fire up a program/script to collect all the extra info he
wants to trace and store it somewhere (typically in some traced
file). The other way round one could have a post-checkout hook and
he could arrange it to fire up some program to look into the
extra-info file to set up all the meta-data he wants.
This would be very flexible and would permit to manage absolutely
/any/ kind of the metadata leaving absolute freedom about how to do
so.
Am I missing something here?
Merging.
Fetching.
Even here, I must be missing something, as I cannot see the issue.
If I need to fetch from someone who is tracing metadata, then there are 2
alternatives:
1) I am fetching only for myself and I am not interested in metadata at all.
All I need to do is to fetch. With this I will fetch a repository with
one/some extra file/files (e.g. .helper-metadata).
2) I am interested in the metadata tracing (e.g. to interact with
my origin). Then it is sufficient to first install the same set of
metadata tracing helpers as my origin and after that to do the fetch.
With this I will fetch a repository including the traced metadata files
just as above, yet these would be immediately be used by the helpers
through the hooks. For instance, as soon as anything gets checked out the
proper metadata can be applied.
Obviously, before installing any hooks, I should trust their origin. But I
believe that if hooks get this kind of usage, rapidly we will see
the growth of trustable "standard" hooks-bundles for many tasks.
Couldn't all this directory/ownership/permission tracing be easily
done by using hooks? E.g. Having a pre-status and pre-commit hook
one could fire up a program/script to collect all the extra info he
wants to trace and store it somewhere (typically in some traced
file). The other way round one could have a post-checkout hook and
he could arrange it to fire up some program to look into the
extra-info file to set up all the meta-data he wants.
This would be very flexible and would permit to manage absolutely
/any/ kind of the metadata leaving absolute freedom about how to do
so.
Am I missing something here?
Merging.
Sorry, maybe I am really missing something, since merging does not look to me
as an issue.
Why cannot git simply do the merging in the working tree as it normally
does, including merging of the traced metadata file generated by the metadata
helpers invoked via the hooks?
Only, again more hooks are needed and likely a post-merge hook, so that at
the end of the merge, the metadata can be applied.
Only, to have things going on smoothly, one should be so wise to assure that
the metadata helpers save metadata as nice, sorted text files in order to
minimize the burden of manual intervention if there are conflicts in
metadata merging.
The post-checkout (no need for post-merge -- after in-index merge is done,
the files are checked out to worktree, so post-checkout would run anyway)
could actually apply any custom merge strategy required to avoid/clean up
spurious conflicts in the metadata file (eg. adding two files that go after
each other would be a textual conflict). The relevant versions are stored in
index stages at that point.
BTW. Having a post-checkout hook could also help getting rid of unwanted
empty directories, couldn't it?
Probably not. I would imagine it would actually only run for the files being
checked out -- and there is nothing checked out in empty directories. (Well,
it would run once or once per directory with list of checked out files on
standard input).
--
Jan 'Bulb' Hudec [off-list ref]