On Sun, 16 Sep 2007, Junio C Hamano wrote:

quoted text
> david@lang.hm writes:
>
>>> I'd rather not implement it at such a low level where a true
>>> "checkout" happens.  For one thing, I am afraid that the special
>>> casing will affect the normal codepath too much and would make
>>> it into a maintenance nightmare.
>>
>> as I understand it, at this point you already choose between three
>> options.
>>
>> 1. write to a file (and set the write bit if needed)
>> 2. write to stdout
>> 3. write to a pager program
>>
>> I am suggesting adding
>> ...
>> or am I missing something major here?
>
> I do not think we are choosing any option in the codepath at
> all.
>
> What I mean by the normal "checkout" is what checkout_entry in
> entry.c does.  There is no other option than (1) above.  I would
> want to see an extremely good justification if you need to touch
> that codepath to implement this fringe use case.
>
> I do not think there is nothing that writes file contents to
> stdout/pager other than "git cat-file" or "git show"; I do not
> think they are what you have in mind when talking about managing
> the files under /etc.  So unfortunately I do not understand the
> rest of the discussion you made in your message.

Ok, I thought that there was common code for these different uses. could 
you re-read the rest of the logic based on the change being done in 
checkout_entry?

if you are unwilling to have any changes made to the checkout_entry code 
then the only remaing question is what you think of Daniel's suggestion to 
have a hook to replace check_updates()?

if it's not acceptable either then we are down to doing a post-checkout 
trigger.

one concern I have with that approach is how to deal with partial 
checkouts. if a user checks out one file how can the post-checkout trigger 
know if it's looking at the correct permissions file as opposed to one 
left over from something else? can/should it go and read the file from the 
index instead of reading the file on the filesystem? (I don't like this 
becouse it leads to non-obvious behavior), or can/should there be a config 
option to say that whenever any file is checked out the permissions file 
needs to be checked out as well.

a post checkout trigger is useful in enough different situations that the 
answers to the above questions don't eliminate the usefulness of the 
trigger, they just map out the pitfalls of useing it.

David Lang
-
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html