At the moment it seems to me that the post-receive hook is not called

when tracking a remove Subversion repository.
I think it would be nice to call the post-receive hook at the end of:
    $ git svn rebase
Why I need this?
I'd like to check for example that if a file has been added to the

remote Subversion repository then it is properly added into a MANIFEST

file. I'd also like to check some style rules. This would help to detect

some problems when one has no way to add hooks on the Subversion repository.
I have zero experience with Perl so I do not feel like hacking this myself.
What do you think?
Is this already possible (I may have missed something)?
Thanks,

Pascal.
-- 
--|------------------------------------------------------

--| Pascal Obry                           Team-Ada Member

--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE

--|------------------------------------------------------

--|              http://www.obry.net

--| "The best way to travel is by means of imagination"

--|

--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

--

Are you saying that there may be breakages that is made at the Subversion

side, and you would want to catch it?
What would you do _after_ finding out that somebody screwed up and you

have a borked history on the Subversion side already?
I do not think this belongs to "git svn rebase" (let alone "git rebase",

no way --- you won't rewrite nor reject the upstream even if you find

problems with it).
I understand that you would at least want to notice the damange to the

history that happened at the remote end, and I agree it would make sense

to do something like:
	$ git command-that-updates-the-remote-tracking-branch git-svn

        $ check-history git-svn@{1}..git-svn
The "command-that-updates" could be "svn fetch" or just a simple "fetch".
But the "check-history" script will be very specific to your project, and

I do not think it makes sense to make it a hook to the "command-that-updates".

--

Hum... Any hook is very specific to a project. That's why it is a hook

and not a built-in command.
BTW, I do not see why this would be a problem with git-svn whereas the

post-receive hook is fine for Git. In many projects rewriting history is

not permitted but post-receive is quite handy to do some checks.
post-received receive 3 parameters:
   - sha before

   - sha after

   - refname
It is perfectly usable after a git-svn rebase.
Pascal.
-- 
--|------------------------------------------------------

--| Pascal Obry                           Team-Ada Member

--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE

--|------------------------------------------------------

--|              http://www.obry.net

--| "The best way to travel is by means of imagination"

--|

--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

--

You probably haven't read Miklos's response have you?  post-receive is

about what happens at the remote end after you "push" there, and does not

have to do with what happens when you fetch.
The article I gave you a link earlier gives a guideline to decide when we

choose to add hook for particular step of operation (and when we choose

not to).  The new call from "git svn rebase" (and presumably "git svn

fetch" which is the first step of that operation) needs to be justified.
Having said that, I would have framed your argument in a different way.  I

suspect then you would not have heard the above objections if you did so:
   After pushing to a remote side, there is a post-receive hook so that

   some processing can happen depending on which refs changed from what

   commit to what new commit.  This is primarily because "push" goes to

   the remote side and the user may not have any other means to trigger an

   operation over there (e.g. there may not be ssh login access, just

   git-shell running to accept pushes).
   After fetching from somewhere else, there is no post-fetch hook.  This

   is not a show-stopper problem because the operation is local.  You can

   remember where the refs were before running a fetch, run the fetch, and

   run necessary post-fetch operation.  IOW, instead of "git fetch" (or

   "git svn fetch") calling a custom script installed as a hook, a custom

   script can call "git fetch" (or "git svn fetch") as part of what it

   does.
   However, fetch and push are logically the same operation --- update a

   set of refs on one end to match the other end, while transferring the

   necessary objects to keep the updated refs valid.  We even suggest

   (with satellite-mothership configuration) to push into remote when

   network reachability constraints keeps you from fetching in the other

   direction or vice versa.  If you used fetch to update refs at the

   receiving end only because you somehow cannot push in the other

   direction, it is natural you wo...
[ message continues ]

That would be nice, but as far as I understand that is not possible

without ugly hacks like subversion's mod_svn or a CGI script. Or did you

refer to the later?

On Sat, Aug 02, 2008 at 06:05:16PM +0200, Pascal Obry <pascal@obry.net> wro=
Sure. From the "post-receive" hook documentation:
"This hook is invoked by 'git-receive-pack' on the remote repository,

which happens when a 'git-push' is done on a local repository."
f.
git rebase is shell. ;-)