From: david@lang.hm
To: Daniel Barkalow <barkalow@iabervon.org>
Cc: "Junio C Hamano" <gitster@pobox.com>,
"Johannes Schindelin" <Johannes.Schindelin@gmx.de>,
"martin f krafft" <madduck@madduck.net>,
git@vger.kernel.org, "Thomas Harning Jr." <harningt@gmail.com>,
"Francis Moreau" <francis.moro@gmail.com>,
"Nicolas Vilz" <niv@iaglans.de>,
"David Härdeman" <david@hardeman.nu>
Subject: Re: metastore
Date: Sun, 16 Sep 2007 14:12:23 -0700 (PDT) [thread overview]
Message-ID: <Pine.LNX.4.64.0709161346150.24221@asgard.lang.hm> (raw)
In-Reply-To: <Pine.LNX.4.64.0709161054380.5298@iabervon.org>
On Sun, 16 Sep 2007, Daniel Barkalow wrote:
>> I however think your idea to have extra "permission information
>> file" is very interesting. What would be more palatable, than
>> mucking with the core level git, would be to have an external
>> command that takes two tree object names that tells it what the
>> old and new trees our work tree is switching between, and have
>> that command to:
>>
>> - inspect the diff-tree output to find out what were checked
>> out and might need their permission information tweaked;
>>
>> - inspect the differences between the "permission information
>> file" in these trees to find out what were _not_ checked out,
>> but still need their permission information tweaked.
>>
>> - tweak whatever external information you are interested in
>> expressing in your "permission information file" in the work
>> tree for the paths it discovered in the above two steps.
>> This step may involve actions specific to projects and call
>> hook scripts with <path, info from "permission information
>> file" for that path> tuples to carry out the actual tweaking.
>
> Why not have the command also responsible for creating the files that need
> to be created (calling back into git to read their contents)? That way,
> there's no window where they've been created without their metadata, and
> there's more that the core git doesn't have to worry about.
my initial thoughts were to have git do all it's normal work and hook into
git at the point where it's writing the file out (where today it chooses
between writing the data to a file on disk, pipeing to stdout, or pipeing
to a pager) by adding the option to pipe into a different program that
would deal with the permission stuff. this program would only have to
write the file and set the permissions, it wouldn't have to know anything
about git other then where to find the permissions it needs to know.
it sounds like you are suggesting that the hook be much earlier in the
process, and instead of one copy of git running and calling many copies of
the writing program, you would have one copy of the writing program that
would call many copies of git.
I'll admit that my initial reaction is that it's probably a lot more
expensive to do all the calls into git. git just has a lot more complex
things to do.
> I could see the program getting the index, the target tree, and the
> directory to put files in, and being told to do the whole 2-way merge
> (except, perhaps, updating the index to match the tree, which git could do
> afterwards). As far as git would be concerned, it would mostly be like a
> bare repository.
if this functionality does shift to earlier in the process, how much of
the git logic needs to be duplicated in this program?
if this program needs to do the merge, won't it have to duplicate the
merge logic, including the .gitattributes checking for custom merge calls?
I have been thinking primarily in terms of doing a complete checkout,
overwriting all files, and secondarily how do do a checkout of just a few
files, but again where all files selected overwrite the existing files.
I wasn't thinking of the fact that git optimizes the checkout and avoids
writing a file that didn't change.
this changes things slightly
prior to this I was thinking that the permission file needed to be handled
differently becouse writing it out needed to avoid doing any circular
refrences where you would need to check the contents of it to write it
out.
it now appears as if what really needs to happen is that if the permission
file changes a different program needs to be called when it's written out
then when the other files are written out. by itself this isn't hard as
.gitattributes can have a special entry for this filename and that entry
can specify a different program, and that program fixes all the
permissions (and/or detects that they can't be fixed due to
user/filesystem limits, records the error, checks if the repository is set
appropriately, and screams to the user if it isn't)
it would be a nice optimization to this permission checkout for it to
compare the old and the new permissions so that it only tries to change
the permissions where it needs to, but is that really nessasary? the
program can look at the permissions of the existing files to see what they
are and decide if it needs to change them (this would tromp on local
changes that aren't checked in. how big of a problem is this?) my initial
reaction is that having to know the two commits and do the comparison
between them is adding a lot of logic and git interaction that I'd rather
avoid if I could.
David Lang
next prev parent reply other threads:[~2007-09-16 21:13 UTC|newest]
Thread overview: 72+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <38b2ab8a0709130511q7a506c5cvb0f8785a1d7ed7ad@mail.gmail.com>
[not found] ` <20070913123137.GA31735@piper.oerlikon.madduck.net>
[not found] ` <38b2ab8a0709140108v2a9c3569i93b39f351f1d4ec3@mail.gmail.com>
[not found] ` <20070914091545.GA26432@piper.oerlikon.madduck.net>
2007-09-14 17:31 ` Track /etc directory using Git Thomas Harning Jr.
2007-09-14 21:26 ` Nicolas Vilz
2007-09-15 14:29 ` Pierre Habouzit
2007-09-15 15:24 ` martin f krafft
2007-09-15 15:27 ` Pierre Habouzit
2007-09-15 15:42 ` martin f krafft
2007-09-15 13:26 ` metastore (was: Track /etc directory using Git) martin f krafft
2007-09-15 14:10 ` Johannes Schindelin
2007-09-15 14:16 ` metastore David Kastrup
2007-09-15 14:54 ` metastore (was: Track /etc directory using Git) martin f krafft
2007-09-15 16:22 ` Grzegorz Kulewski
2007-09-15 17:43 ` Johannes Schindelin
2007-09-15 23:33 ` metastore Randal L. Schwartz
2007-09-16 0:37 ` metastore david
2007-09-16 1:10 ` metastore Randal L. Schwartz
2007-09-16 1:49 ` metastore david
2007-09-17 13:04 ` metastore Francis Moreau
2007-09-17 15:32 ` metastore Randal L. Schwartz
2007-09-15 19:56 ` metastore (was: Track /etc directory using Git) Daniel Barkalow
2007-09-15 22:14 ` Johannes Schindelin
2007-09-16 1:30 ` david
2007-09-16 2:48 ` Johannes Schindelin
2007-09-16 3:00 ` david
2007-09-16 8:06 ` metastore Junio C Hamano
2007-09-16 8:30 ` metastore David Kastrup
2007-09-16 20:19 ` metastore david
2007-09-16 15:51 ` metastore Daniel Barkalow
2007-09-16 21:12 ` david [this message]
2007-09-16 21:28 ` metastore Junio C Hamano
2007-09-16 21:45 ` metastore Daniel Barkalow
2007-09-16 21:53 ` metastore david
2007-09-16 22:02 ` metastore Daniel Barkalow
2007-09-16 22:37 ` metastore david
2007-09-17 13:30 ` metastore martin f krafft
2007-09-17 17:17 ` metastore david
2007-09-17 19:46 ` metastore Josh England
2007-09-16 21:45 ` metastore david
2007-09-16 22:11 ` metastore Junio C Hamano
2007-09-16 22:52 ` metastore david
2007-09-17 0:58 ` metastore Junio C Hamano
2007-09-17 2:31 ` metastore david
2007-09-17 4:23 ` metastore Junio C Hamano
2007-09-17 4:35 ` metastore david
2007-09-17 6:06 ` metastore Junio C Hamano
2007-09-17 17:42 ` metastore Daniel Barkalow
2007-09-17 19:19 ` metastore Junio C Hamano
2007-09-16 15:59 ` metastore (was: Track /etc directory using Git) Jan Hudec
2007-09-16 20:36 ` david
2007-09-16 6:14 ` martin f krafft
2007-09-16 15:51 ` Jan Hudec
2007-09-16 19:43 ` david
2007-09-17 13:31 ` martin f krafft
2007-09-16 1:35 ` david
2007-09-16 6:08 ` martin f krafft
2007-09-19 19:16 ` David Härdeman
2007-10-02 19:53 ` martin f krafft
2007-10-02 19:58 ` David Härdeman
2007-10-02 20:04 ` metastore David Kastrup
2007-10-02 20:18 ` metastore david
2007-10-02 20:23 ` metastore martin f krafft
2007-10-02 20:29 ` metastore david
2007-10-02 20:39 ` metastore martin f krafft
2007-10-02 20:54 ` metastore david
2007-10-02 21:42 ` metastore martin f krafft
2007-10-02 21:15 ` metastore David Härdeman
2007-10-02 21:44 ` metastore martin f krafft
2007-10-02 23:32 ` metastore Julian Phillips
2007-10-03 0:52 ` metastore david
2007-10-03 0:52 ` metastore Johannes Schindelin
2007-10-02 21:02 ` metastore (was: Track /etc directory using Git) Daniel Barkalow
[not found] ` <20070913122002.GO671@genesis.frugalware.org>
[not found] ` <38b2ab8a0709140120k50f5b474oc8a841ea0a5fda50@mail.gmail.com>
2007-09-15 16:32 ` Track /etc directory using Git martin f krafft
2007-09-15 16:57 ` David Kastrup
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
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=Pine.LNX.4.64.0709161346150.24221@asgard.lang.hm \
--to=david@lang.hm \
--cc=Johannes.Schindelin@gmx.de \
--cc=barkalow@iabervon.org \
--cc=david@hardeman.nu \
--cc=francis.moro@gmail.com \
--cc=git@vger.kernel.org \
--cc=gitster@pobox.com \
--cc=harningt@gmail.com \
--cc=madduck@madduck.net \
--cc=niv@iaglans.de \
/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.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
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 read-only IMAP folder(s) and NNTP newsgroup(s).