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 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 unsubscribe
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 yields?
Ah,
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
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.
Documentation update
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
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
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
-
To
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
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
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 keep
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,
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 code
13 matches
Mail list logo
