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
threads / discuss / 30867
Subject: pre-receive hook ; how to detect file and append code ?
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 ?
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 ?
"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 ?
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....