On Saturday 13 August 2005 21:27, Junio C Hamano wrote:
> Josef Weidendorfer <[EMAIL PROTECTED]> writes:
> > Or is there already an easy way to detect the fast-forward situation in
> > the script?
>
> Since you are given old and new, presumably you can do
> merge-base in the hook to see what it yie
Josef Weidendorfer <[EMAIL PROTECTED]> writes:
> Or is there already an easy way to detect the fast-forward situation in the
> script?
Since you are given old and new, presumably you can do
merge-base in the hook to see what it yields?
-
To unsubscribe from this list: send the line "unsubscrib
On Sunday 31 July 2005 21:17, Josef Weidendorfer wrote:
> Added hook in git-receive-pack
Regarding the update hook:
In this script, it would be nice to be able to distinguish rebasing/forced
setting of a head from a regular fast forwarding. In the first case, I do not
want to potentially send a
Josef, I've committed a version that has slightly different
semantics from what you originally posted.
The differences are:
- Instead of being post-change hook, the script is run just
before each ref is updated. The script can exit with
non-zero status to tell receive-pack not to update t
On Sun, 31 Jul 2005, Junio C Hamano wrote:
>
> You are absolutely right. It should grab some sort of lock
> while it does its thing (would fcntl(F_GETLK) be acceptable to
> networked filesystem folks?).
There is no lock that works reliably except for the "create a directory
and rename it onto
Linus Torvalds <[EMAIL PROTECTED]> writes:
> In the "central repo model" you have another issue - you have potentially
> parallell pushes to different branches with no locking what-so-ever (and
> that's definitely _supposed_ to work), and I have this suspicion that the
> "update for dumb servers"
Hi,
On Sun, 31 Jul 2005, Junio C Hamano wrote:
> Let's yank out the update_server_info() call when Josef's patch
> can handle a single hook call at the end of the run, in addition
> to one call per each ref getting updated.
How about executing update_server_info() if no hook was found? That way,
On Sun, 31 Jul 2005, Junio C Hamano wrote:
> Linus Torvalds <[EMAIL PROTECTED]> writes:
>
> > No I'm not. Try all the machines behind my firewall.
>
> Ah, that's true. Do you push into them?
Yup, I do. I have this thing that I don't do backups, but I end up having
redundancy instead, so I ke
Linus Torvalds <[EMAIL PROTECTED]> writes:
> No I'm not. Try all the machines behind my firewall.
Ah, that's true. Do you push into them?
Let's yank out the update_server_info() call when Josef's patch
can handle a single hook call at the end of the run, in addition
to one call per each ref get
On Sunday 31 July 2005 22:15, Junio C Hamano wrote:
> Josef Weidendorfer <[EMAIL PROTECTED]> writes:
> > +It is assured that sha1-old is an ancestor of sha1-new (otherwise,
> > +the update would have not been allowed). refname is relative to
> > +$GIT_DIR; e.g. for the master head this is "refs/hea
On Sun, 31 Jul 2005, Junio C Hamano wrote:
>
> But you are. I can run this just fine:
No I'm not. Try all the machines behind my firewall.
kernel.org is just the place I put things to when I publish them. It
doesn't have any of my working directories on it.
Linus
-
T
Linus Torvalds <[EMAIL PROTECTED]> writes:
> This looks sane. However, I also get the strong feeling that
> git-update-server-info should be run as part of a hook and not be built
> into receive-pack..
> Personally, I simply don't want to update any dumb server info stuff for
> my own local rep
Josef Weidendorfer <[EMAIL PROTECTED]> writes:
> +It is assured that sha1-old is an ancestor of sha1-new (otherwise,
> +the update would have not been allowed). refname is relative to
> +$GIT_DIR; e.g. for the master head this is "refs/heads/master".
I think this description is inaccurate; the se
On Sun, 31 Jul 2005, Josef Weidendorfer wrote:
>
> Added hook in git-receive-pack
>
> After successful update of a ref,
>
> $GIT_DIR/hooks/update refname old-sha1 new-sha2
>
> is called if present. This allows e.g sending of a mail
> with pushed commits on the remote repository.
> Documentati
Added hook in git-receive-pack
After successful update of a ref,
$GIT_DIR/hooks/update refname old-sha1 new-sha2
is called if present. This allows e.g sending of a mail
with pushed commits on the remote repository.
Documentation update with example hook included.
Signed-off-by: Josef Weidendor
15 matches
Mail list logo
