pre-receive hook ; how to detect file and append code ?

pre-receive hook ; how to detect file and append code ?

[J. Bakshi]

Dear list,

How can I detect a specific file during push, if it is modified or not ?
And how can I then append a block of code into that file; if modified
during push ? I think pre-receive hook is the best for this operation.

Thanks

Re: pre-receive hook ; how to detect file and append code ?

[Thomas Adam]

On 22 June 2012 14:07, J. Bakshi <joydeep.bakshi@infoservices.in> wrote:
> Dear list,
>
> How can I detect a specific file during push, if it is modified or not ?
> And how can I then append a block of code into that file; if modified
> during push ? I think pre-receive hook is the best for this operation.

Umm, what problem are you trying to solve?  This is a solution to an
unnamed problem, see "XY problem".

-- Thomas Adam

Re: pre-receive hook ; how to detect file and append code ?

[Junio C Hamano]

"J. Bakshi" <joydeep.bakshi@infoservices.in> writes:

> How can I detect a specific file during push, if it is modified or not ?
> And how can I then append a block of code into that file; if modified
> during push ? I think pre-receive hook is the best for this operation.

The purpose of the "pre-receive" hook is to either approve or reject
a proposed change made by the push.  When it runs, the repository
already has received all the objects necessary to inspect the
proposed change locally (from the receiving repository's point of
view).

A proposed change comes in the form of <old> <new> <refname> that
says "The pusher saw <old> at <refname> when he started this push,
and it wants to update the ref to <new>".  So any of the following
standard techniques (note: not exhaustive) to inspect the changes
between <old> and <new> can be used:

    # are log messages sane?
    git log <old>..<new>

    # are the changes sane?
    git diff <old>..<new>

    # does it leave forbidden paths intact
    git diff --name-only <old>..<new>

If your script likes the proposed change, exit with 0.  If it does
not, exit with non-zero.

That is all it can do.  It is not supposed to change <new> to some
other value, and there is no interface to do so.

If you want to rewrite the history pushed into the repository after
a push is accepted, you would want to run it from post-receive or
something.  All the usual warning about rewriting published history
will apply if you do so, however.  After all, the history is already
published immediately before post-recieve (or post-update) runs.

Re: pre-receive hook ; how to detect file and append code ?

[J. Bakshi]

On Fri, 22 Jun 2012 11:02:41 -0700
Junio C Hamano <gitster@pobox.com> wrote:

> "J. Bakshi" <joydeep.bakshi@infoservices.in> writes:
> 
> > How can I detect a specific file during push, if it is modified or not ?
> > And how can I then append a block of code into that file; if modified
> > during push ? I think pre-receive hook is the best for this operation.
> 
> The purpose of the "pre-receive" hook is to either approve or reject
> a proposed change made by the push.  When it runs, the repository
> already has received all the objects necessary to inspect the
> proposed change locally (from the receiving repository's point of
> view).
> 
> A proposed change comes in the form of <old> <new> <refname> that
> says "The pusher saw <old> at <refname> when he started this push,
> and it wants to update the ref to <new>".  So any of the following
> standard techniques (note: not exhaustive) to inspect the changes
> between <old> and <new> can be used:
> 
>     # are log messages sane?
>     git log <old>..<new>
> 
>     # are the changes sane?
>     git diff <old>..<new>
> 
>     # does it leave forbidden paths intact
>     git diff --name-only <old>..<new>
> 
> If your script likes the proposed change, exit with 0.  If it does
> not, exit with non-zero.
> 
> That is all it can do.  It is not supposed to change <new> to some
> other value, and there is no interface to do so.
> 
> If you want to rewrite the history pushed into the repository after
> a push is accepted, you would want to run it from post-receive or
> something.  All the usual warning about rewriting published history
> will apply if you do so, however.  After all, the history is already
> published immediately before post-recieve (or post-update) runs.

Thanks a lot for the clarifications....