david@lang.hm writes:
On Sun, 16 Sep 2007, Junio C Hamano wrote:
quoted
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.
Post-checkout trigger is something I can say I can live with
without looking at the actual patch, but that does not mean it
would be a better approach at all.
I would not be able to answer the first question right now; that
needs a patch to prove that it can be done with a well contained
set of changes that results in a maintainable code.
I haven't tried to assess the potential extent of damage needed
to checkout_entry(), and I have never been interested in this
"keeping track of /etc in place" topic myself. It is unlikely
I'll try to come up with such a patch on my own to support it at
such a low level near the core. Somebody who cares about that
feature needs to take the initiative of doing that work before
we can discuss and decide, although older-times including myself
can help spot potential issues.
So while I admit I am skeptical, consider me neither willing nor
unwilling at this point.
On Sun, 16 Sep 2007, Junio C Hamano wrote:
david@lang.hm writes:
quoted
On Sun, 16 Sep 2007, Junio C Hamano wrote:
quoted
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.
Post-checkout trigger is something I can say I can live with
without looking at the actual patch, but that does not mean it
would be a better approach at all.
we agree on this much at least :-)
I would not be able to answer the first question right now; that
needs a patch to prove that it can be done with a well contained
set of changes that results in a maintainable code.
you cannot answer the question in the affirmitive, but you could say that
any changes in that area would be completely unacceptable to you (and for
a while it sounded like you were saying exactly that). in which case any
effort put into preparing patches would be a waste of time
I haven't tried to assess the potential extent of damage needed
to checkout_entry(), and I have never been interested in this
"keeping track of /etc in place" topic myself. It is unlikely
I'll try to come up with such a patch on my own to support it at
such a low level near the core. Somebody who cares about that
feature needs to take the initiative of doing that work before
we can discuss and decide, although older-times including myself
can help spot potential issues.
So while I admit I am skeptical, consider me neither willing nor
unwilling at this point.
this is reasonable. thanks for pointing me so clearly at the routine that
needs to be modified.
David Lang