Junio,
Are you saying that there may be breakages that is made at the Subversion
side, and you would want to catch it?
Exactly.
What would you do _after_ finding out that somebody screwed up and you
have a borked history on the Subversion side already?
Notify the developer(s) about the problem(s).
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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
