* [PATCH 3/3] builtin-commit: fix author date with --amend --author=<author>
From: Johannes Schindelin @ 2007-11-08 12:16 UTC (permalink / raw)
To: git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0711081213580.4362@racer.site>
When amending a commit with a new author, the author date is taken
from the original commit.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-commit.c | 17 ++++++++++++++++-
1 files changed, 16 insertions(+), 1 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index bba9b82..03f0b9d 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -278,7 +278,6 @@ static void determine_author_info(struct strbuf *sb)
die("malformed --author parameter\n");
name = xstrndup(force_author, eoname - force_author);
email = xstrndup(eoname + 2, eomail - eoname - 2);
- /* REVIEW: drops author date from amended commit on --amend --author=<author> */
strbuf_addf(sb, "author %s\n",
fmt_ident(name, email,
getenv("GIT_AUTHOR_DATE"), 1));
@@ -525,6 +524,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
} else if (amend) {
struct commit_list *c;
struct commit *commit;
+ const char *author;
reflog_msg = "commit (amend)";
commit = lookup_commit(head_sha1);
@@ -534,6 +534,21 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
for (c = commit->parents; c; c = c->next)
strbuf_addf(&sb, "parent %s\n",
sha1_to_hex(c->item->object.sha1));
+
+ /* determine author date */
+ author = strstr(commit->buffer, "\nauthor");
+ if (author && !memmem(commit->buffer,
+ author + 1 - commit->buffer,
+ "\n\n", 2)) {
+ const char *email_end = strchr(author + 1, '>');
+ const char *line_end = strchr(author + 1, '\n');
+ if (email_end && line_end && email_end < line_end) {
+ char *date = xstrndup(email_end + 1,
+ line_end - email_end - 1);
+ setenv("GIT_AUTHOR_DATE", date, 1);
+ free(date);
+ }
+ }
} else if (in_merge) {
struct strbuf m;
FILE *fp;
--
1.5.3.5.1634.g0fa78
^ permalink raw reply related
* [PATCH 2/3] launch_editor(): read the file, even when EDITOR=:
From: Johannes Schindelin @ 2007-11-08 12:15 UTC (permalink / raw)
To: git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0711081213580.4362@racer.site>
Earlier we just returned in case EDITOR=: but the message stored
in the file was not read back. Fix this.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-tag.c | 21 ++++++++++-----------
1 files changed, 10 insertions(+), 11 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index c3b76da..f5e0f8a 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -20,7 +20,6 @@ static char signingkey[1000];
void launch_editor(const char *path, struct strbuf *buffer)
{
const char *editor, *terminal;
- struct child_process child;
const char *args[3];
editor = getenv("GIT_EDITOR");
@@ -42,17 +41,17 @@ void launch_editor(const char *path, struct strbuf *buffer)
if (!editor)
editor = "vi";
- if (!strcmp(editor, ":"))
- return;
+ if (strcmp(editor, ":")) {
+ struct child_process child;
+ memset(&child, 0, sizeof(child));
+ child.argv = args;
+ args[0] = editor;
+ args[1] = path;
+ args[2] = NULL;
- memset(&child, 0, sizeof(child));
- child.argv = args;
- args[0] = editor;
- args[1] = path;
- args[2] = NULL;
-
- if (run_command(&child))
- die("There was a problem with the editor %s.", editor);
+ if (run_command(&child))
+ die("There was a problem with the editor %s.", editor);
+ }
if (strbuf_read_file(buffer, path, 0) < 0)
die("could not read message file '%s': %s",
--
1.5.3.5.1634.g0fa78
^ permalink raw reply related
* [PATCH 1/3] builtin-commit: fix reflog message generation
From: Johannes Schindelin @ 2007-11-08 12:15 UTC (permalink / raw)
To: git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0711081213580.4362@racer.site>
Instead of strdup()ing, we can just reuse the buffer in which the
commit message is stored, and which is supposed to hold the reflog
message anyway.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
builtin-commit.c | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/builtin-commit.c b/builtin-commit.c
index f108e90..bba9b82 100644
--- a/builtin-commit.c
+++ b/builtin-commit.c
@@ -488,7 +488,7 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
int header_len, parent_count = 0;
struct strbuf sb;
const char *index_file, *reflog_msg;
- char *nl, *header_line;
+ char *nl;
unsigned char commit_sha1[20];
struct ref_lock *ref_lock;
@@ -585,12 +585,13 @@ int cmd_commit(int argc, const char **argv, const char *prefix)
0);
nl = strchr(sb.buf + header_len, '\n');
- header_line = xstrndup(sb.buf + header_len,
- nl - (sb.buf + header_len));
- strbuf_release(&sb);
- strbuf_addf(&sb, "%s: %s\n", reflog_msg, header_line);
- strbuf_addch(&sb, '\0');
- free(header_line);
+ if (nl)
+ strbuf_setlen(&sb, nl + 1 - sb.buf);
+ else
+ strbuf_addch(&sb, '\n');
+ strbuf_remove(&sb, 0, header_len);
+ strbuf_insert(&sb, 0, reflog_msg, strlen(reflog_msg));
+ strbuf_insert(&sb, strlen(reflog_msg), ": ", 2);
if (!ref_lock)
die("cannot lock HEAD ref");
--
1.5.3.5.1634.g0fa78
^ permalink raw reply related
* [PATCH 0/3] builtin-commit fixes
From: Johannes Schindelin @ 2007-11-08 12:14 UTC (permalink / raw)
To: git, krh, gitster
Hi,
The following three commits are on top of kh/commit. With these 3 patches,
the test suite passes.
Ciao,
Dscho
^ permalink raw reply
* [PATCH 2/2] git-push: plumb in --mirror mode
From: Andy Whitcroft @ 2007-11-08 12:12 UTC (permalink / raw)
To: git
In-Reply-To: <20071108121136.GG9736@shadowen.org>
Plumb in the --mirror mode for git-push.
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
builtin-push.c | 14 ++++++++++++--
transport.c | 7 +++++++
transport.h | 1 +
3 files changed, 20 insertions(+), 2 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 2c56195..d49157c 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -10,7 +10,7 @@
#include "parse-options.h"
static const char * const push_usage[] = {
- "git-push [--all] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
+ "git-push [--all | --mirror] [--dry-run] [--tags] [--receive-pack=<git-receive-pack>] [--repo=all] [-f | --force] [-v] [<repository> <refspec>...]",
NULL,
};
@@ -91,6 +91,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
{
int flags = 0;
int all = 0;
+ int mirror = 0;
int dry_run = 0;
int force = 0;
int tags = 0;
@@ -100,6 +101,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT__VERBOSE(&verbose),
OPT_STRING( 0 , "repo", &repo, "repository", "repository"),
OPT_BOOLEAN( 0 , "all", &all, "push all refs"),
+ OPT_BOOLEAN( 0 , "mirror", &mirror, "mirror all refs"),
OPT_BOOLEAN( 0 , "tags", &tags, "push tags"),
OPT_BOOLEAN( 0 , "dry-run", &dry_run, "dry run"),
OPT_BOOLEAN('f', "force", &force, "force updates"),
@@ -119,13 +121,21 @@ int cmd_push(int argc, const char **argv, const char *prefix)
add_refspec("refs/tags/*");
if (all)
flags |= TRANSPORT_PUSH_ALL;
+ if (mirror)
+ flags |= (TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE);
if (argc > 0) {
repo = argv[0];
set_refspecs(argv + 1, argc - 1);
}
- if ((flags & TRANSPORT_PUSH_ALL) && refspec)
+ if ((flags & (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) && refspec)
usage_with_options(push_usage, options);
+ if ((flags & (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) ==
+ (TRANSPORT_PUSH_ALL|TRANSPORT_PUSH_MIRROR)) {
+ error("--all and --mirror are incompatible");
+ usage_with_options(push_usage, options);
+ }
+
return do_push(repo, flags);
}
diff --git a/transport.c b/transport.c
index f4577b7..08e62b1 100644
--- a/transport.c
+++ b/transport.c
@@ -284,6 +284,9 @@ static int rsync_transport_push(struct transport *transport,
struct child_process rsync;
const char *args[10];
+ if (flags & TRANSPORT_PUSH_MIRROR)
+ return error("rsync transport does not support mirror mode");
+
/* first push the objects */
strbuf_addstr(&buf, transport->url);
@@ -386,6 +389,9 @@ static int curl_transport_push(struct transport *transport, int refspec_nr, cons
int argc;
int err;
+ if (flags & TRANSPORT_PUSH_MIRROR)
+ return error("http transport does not support mirror mode");
+
argv = xmalloc((refspec_nr + 11) * sizeof(char *));
argv[0] = "http-push";
argc = 1;
@@ -653,6 +659,7 @@ static int git_transport_push(struct transport *transport, int refspec_nr, const
args.receivepack = data->receivepack;
args.send_all = !!(flags & TRANSPORT_PUSH_ALL);
+ args.send_mirror = !!(flags & TRANSPORT_PUSH_MIRROR);
args.force_update = !!(flags & TRANSPORT_PUSH_FORCE);
args.use_thin_pack = data->thin;
args.verbose = transport->verbose;
diff --git a/transport.h b/transport.h
index d27f562..7f337d2 100644
--- a/transport.h
+++ b/transport.h
@@ -30,6 +30,7 @@ struct transport {
#define TRANSPORT_PUSH_ALL 1
#define TRANSPORT_PUSH_FORCE 2
#define TRANSPORT_PUSH_DRY_RUN 4
+#define TRANSPORT_PUSH_MIRROR 8
/* Returns a transport suitable for the url */
struct transport *transport_get(struct remote *, const char *);
^ permalink raw reply related
* [PATCH 1/2] mirror pushing
From: Andy Whitcroft @ 2007-11-08 12:12 UTC (permalink / raw)
To: git
In-Reply-To: <20071108121136.GG9736@shadowen.org>
Existing "git push --all" is almost perfect for backing up to
another repository, except that "--all" only means "all
branches" in modern git, and it does not delete old branches and
tags that exist at the back-up repository that you have removed
from your local repository.
This teaches "git-send-pack" a new "--mirror" option. The
difference from the "--all" option are that (1) it sends all
refs, not just branches, and (2) it deletes old refs you no
longer have on the local side from the remote side.
[apw@shadowen.org: rebase to next post arguments update]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
---
builtin-send-pack.c | 40 ++++++++++++++++++++++++++++------------
remote.c | 15 ++++++++++-----
send-pack.h | 1 +
3 files changed, 39 insertions(+), 17 deletions(-)
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index 5a0f5c6..d5ead97 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -8,7 +8,7 @@
#include "send-pack.h"
static const char send_pack_usage[] =
-"git-send-pack [--all] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]\n"
+"git-send-pack [--all | --mirror] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]\n"
" --all and explicit <ref> specification are mutually exclusive.";
static struct send_pack_args args = {
@@ -242,7 +242,7 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
if (!remote_tail)
remote_tail = &remote_refs;
if (match_refs(local_refs, remote_refs, &remote_tail,
- nr_refspec, refspec, args.send_all))
+ nr_refspec, refspec, args.send_all | (args.send_mirror << 1)))
return -1;
if (!remote_refs) {
@@ -259,20 +259,28 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
char old_hex[60], *new_hex;
int will_delete_ref;
const char *pretty_ref;
- const char *pretty_peer;
+ const char *pretty_peer = NULL; /* only used when not deleting */
+ const unsigned char *new_sha1;
- if (!ref->peer_ref)
- continue;
+ if (!ref->peer_ref) {
+ if (!args.send_mirror)
+ continue;
+ new_sha1 = null_sha1;
+ }
+ else
+ new_sha1 = ref->peer_ref->new_sha1;
if (!shown_dest) {
fprintf(stderr, "To %s\n", dest);
shown_dest = 1;
}
+ will_delete_ref = is_null_sha1(new_sha1);
+
pretty_ref = prettify_ref(ref->name);
- pretty_peer = prettify_ref(ref->peer_ref->name);
+ if (!will_delete_ref)
+ pretty_peer = prettify_ref(ref->peer_ref->name);
- will_delete_ref = is_null_sha1(ref->peer_ref->new_sha1);
if (will_delete_ref && !allow_deleting_refs) {
fprintf(stderr, " ! %-*s %s (remote does not support deleting refs)\n",
SUMMARY_WIDTH, "[rejected]", pretty_ref);
@@ -280,7 +288,7 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
continue;
}
if (!will_delete_ref &&
- !hashcmp(ref->old_sha1, ref->peer_ref->new_sha1)) {
+ !hashcmp(ref->old_sha1, new_sha1)) {
if (args.verbose)
fprintf(stderr, " = %-*s %s -> %s\n",
SUMMARY_WIDTH, "[up to date]",
@@ -312,8 +320,7 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
!is_null_sha1(ref->old_sha1) &&
!ref->force) {
if (!has_sha1_file(ref->old_sha1) ||
- !ref_newer(ref->peer_ref->new_sha1,
- ref->old_sha1)) {
+ !ref_newer(new_sha1, ref->old_sha1)) {
/* We do not have the remote ref, or
* we know that the remote ref is not
* an ancestor of what we are trying to
@@ -328,7 +335,7 @@ static int do_send_pack(int in, int out, struct remote *remote, const char *dest
continue;
}
}
- hashcpy(ref->new_sha1, ref->peer_ref->new_sha1);
+ hashcpy(ref->new_sha1, new_sha1);
if (!will_delete_ref)
new_refs++;
strcpy(old_hex, sha1_to_hex(ref->old_sha1));
@@ -459,6 +466,10 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
args.dry_run = 1;
continue;
}
+ if (!strcmp(arg, "--mirror")) {
+ args.send_mirror = 1;
+ continue;
+ }
if (!strcmp(arg, "--force")) {
args.force_update = 1;
continue;
@@ -483,7 +494,12 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
}
if (!dest)
usage(send_pack_usage);
- if (heads && args.send_all)
+ /*
+ * --all and --mirror are incompatible; neither makes sense
+ * with any refspecs.
+ */
+ if ((heads && (args.send_all || args.send_mirror)) ||
+ (args.send_all && args.send_mirror))
usage(send_pack_usage);
if (remote_name) {
diff --git a/remote.c b/remote.c
index 59defdb..45dd59b 100644
--- a/remote.c
+++ b/remote.c
@@ -722,10 +722,12 @@ static const struct refspec *check_pattern_match(const struct refspec *rs,
* without thinking.
*/
int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
- int nr_refspec, const char **refspec, int all)
+ int nr_refspec, const char **refspec, int flags)
{
struct refspec *rs =
parse_ref_spec(nr_refspec, (const char **) refspec);
+ int send_all = flags & 01;
+ int send_mirror = flags & 02;
if (match_explicit_refs(src, dst, dst_tail, rs, nr_refspec))
return -1;
@@ -742,7 +744,7 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
if (!pat)
continue;
}
- else if (prefixcmp(src->name, "refs/heads/"))
+ else if (!send_mirror && prefixcmp(src->name, "refs/heads/"))
/*
* "matching refs"; traditionally we pushed everything
* including refs outside refs/heads/ hierarchy, but
@@ -763,10 +765,13 @@ int match_refs(struct ref *src, struct ref *dst, struct ref ***dst_tail,
if (dst_peer && dst_peer->peer_ref)
/* We're already sending something to this ref. */
goto free_name;
- if (!dst_peer && !nr_refspec && !all)
- /* Remote doesn't have it, and we have no
+
+ if (!dst_peer && !nr_refspec && !(send_all || send_mirror))
+ /*
+ * Remote doesn't have it, and we have no
* explicit pattern, and we don't have
- * --all. */
+ * --all nor --mirror.
+ */
goto free_name;
if (!dst_peer) {
/* Create a new one and link it */
diff --git a/send-pack.h b/send-pack.h
index 7a24f71..8ff1dc3 100644
--- a/send-pack.h
+++ b/send-pack.h
@@ -5,6 +5,7 @@ struct send_pack_args {
const char *receivepack;
unsigned verbose:1,
send_all:1,
+ send_mirror:1,
force_update:1,
use_thin_pack:1,
dry_run:1;
^ permalink raw reply related
* [PATCH] contrib/hooks/post-receive-email: remove cruft, $committer is not used
From: Gerrit Pape @ 2007-11-08 12:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Andy Parkins
In-Reply-To: <7vode52hag.fsf@gitster.siamese.dyndns.org>
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
contrib/hooks/post-receive-email | 4 ----
1 files changed, 0 insertions(+), 4 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 3904c18..7511ea0 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -156,10 +156,6 @@ generate_email()
fi
# Email parameters
- # The committer will be obtained from the latest existing rev; so
- # for a deletion it will be the oldrev, for the others, then newrev
- committer=$(git show --pretty=full -s $rev | sed -ne "s/^Commit: //p" |
- sed -ne 's/\(.*\) </"\1" </p')
# The email subject will contain the best description of the ref
# that we can build from the parameters
describe=$(git describe $rev 2>/dev/null)
--
1.5.3.5
^ permalink raw reply related
* git push mirror mode
From: Andy Whitcroft @ 2007-11-08 12:11 UTC (permalink / raw)
To: git
Ok, sometime back Junio sent out a proof-of-concept change to
send-pack allowing a mirror mode. That patch seemed to interact
badly dropping refs in the .git directorty and I did not have time
to fix it up.
I've just rebased it to the latest next, and updated my follow up patch
to make this available as 'git push --mirror <remote>'. I have only
tested this lightly.
-apw
^ permalink raw reply
* git-p4 pull request
From: Simon Hausmann @ 2007-11-08 11:55 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Chris Pettitt, git
[-- Attachment #1: Type: text/plain, Size: 649 bytes --]
The following changes since commit fe61935007b6803ce116e233316e4ff51de02be6:
Junio C Hamano (1):
Merge branch 'maint'
are available in the git repository at:
git://repo.or.cz/git/git-p4.git git-p4
Chris Pettitt (2):
git-p4: Add a helper function to parse the full git diff-tree output.
git-p4: Detect changes to executable bit and include them in p4 submit.
contrib/fast-import/git-p4 | 93 ++++++++++++++++++++++++++++++++++++++++++--
1 files changed, 89 insertions(+), 4 deletions(-)
Chris implemented support for representing mode changes in git in submits to
Perforce. Fits well into master IMHO.
Thanks,
Simon
[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: What's in git.git (stable)
From: Pierre Habouzit @ 2007-11-08 11:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vk5ot40w9.fsf@gitster.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1193 bytes --]
On Thu, Nov 08, 2007 at 08:06:14AM +0000, Junio C Hamano wrote:
> On 'master' front:
>
> - git-p4 in contrib/ has updates. As I cannot test it myself
> and did not hear any success/failure stories from the list,
> the only way to make sure is to push it out and see if
> anybody screams.
>
> - "git lost-found" is going to be deprecated (not removed) in
> the next feature release.
>
> - Unspecified clean.requireForce defaults to true; this would
> make "git clean" require "-f" by default.
>
> - "git send-email --suppress-from" does not CC yourself even
> when your name is on S-o-b: or Cc: lines in the body of the
> message.
>
> ----------------------------------------------------------------
>
> * The 'maint' branch has these fixes since the last announcement.
[...]
> Pierre Habouzit (1):
> Some better parse-options documentation.
Eeeer isn't there some kind of problem ? This is not in maint, I
believe you swapped 'master' and 'maint' :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] Make it easier to run individual tests
From: David D Kilzer @ 2007-11-08 11:31 UTC (permalink / raw)
To: git; +Cc: gitster, David D Kilzer
The following commands now work from the top-level source directory:
$ make t/t0001-init.sh
$ T=t0001-init.sh make test
Signed-off-by: David D Kilzer <ddkilzer@kilzer.net>
---
For the maint branch.
I'm so lazy I wanted a way to run tests from the primary Makefile.
Makefile | 3 +++
t/Makefile | 2 +-
2 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index e70e320..eb0f7da 100644
--- a/Makefile
+++ b/Makefile
@@ -961,6 +961,9 @@ export NO_SVN_TESTS
test: all
$(MAKE) -C t/ all
+t/t%.sh: all
+ T=`basename $@` $(MAKE) -C t/ all
+
test-date$X: date.o ctype.o
test-delta$X: diff-delta.o patch-delta.o
diff --git a/t/Makefile b/t/Makefile
index 72d7884..ae25561 100644
--- a/t/Makefile
+++ b/t/Makefile
@@ -11,7 +11,7 @@ RM ?= rm -f
# Shell quote;
SHELL_PATH_SQ = $(subst ','\'',$(SHELL_PATH))
-T = $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
+T ?= $(wildcard t[0-9][0-9][0-9][0-9]-*.sh)
TSVN = $(wildcard t91[0-9][0-9]-*.sh)
all: $(T) clean
--
1.5.3.4
^ permalink raw reply related
* Re: [PATCH] Add Documentation/CodingStyle
From: Mike Ralphson @ 2007-11-08 11:29 UTC (permalink / raw)
To: Johannes Schindelin, Junio C Hamano; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711062317330.4362@racer.site>
On Nov 6, 2007 11:17 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
>
> Even if our code is quite a good documentation for our coding style,
> some people seem to prefer a document describing it.
Might this file be a place to document exactly which licenses we
accept code under? I.e. is it GPLv2 only or any license compatible
with GPLv2 ?
Currently I see only GPLv2 in core git, but I have a series of patches
which give me a speed-up of two orders of magnitude for some cases of
at least git-status (on my platform, with my repos etc) and so far my
two approaches involve bringing in code which is either public domain
with restrictions (which may be too onerous for us to carry in
mainline) or 3-clause BSD.
Cheers, Mike
^ permalink raw reply
* Re: [PATCH 3/3] git-fetch: avoid local fetching from alternate (again)
From: Shawn O. Pearce @ 2007-11-08 11:22 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhcjx2gq5.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > I'm starting to suspect heap corruption again in builtin-fetch.
> > This patch alters the malloc() calls we are doing and may be shifting
> > something around just enough in memory to cause a data overwrite or
> > something and that's why this tag just drops out of the linked list?
> > But then why does that happen in the test suite but not outside.
> > Maybe because the test suite is setting environment variables that
> > I'm not and the impact of those combined with these additional
> > mallocs is what is breaking it? *sigh*
Found it. This ain't pretty. Remember, what's failing in the test
suite is we aren't getting "tag-three-file" automatically followed
during fetch. This is an annotated tag referring to a blob.
Here's the *WAY WRONG FIX THAT SHOULD NOT EVER BE APPLIED*:
diff --git a/builtin-fetch.c b/builtin-fetch.c
index 847db73..a935b5a 100644
--- a/builtin-fetch.c
+++ b/builtin-fetch.c
@@ -389,7 +389,7 @@ static struct ref *find_non_local_tags(struct transport *transport,
if (!path_list_has_path(&existing_refs, ref_name) &&
!path_list_has_path(&new_refs, ref_name) &&
- lookup_object(ref->old_sha1)) {
+ has_sha1_file(ref->old_sha1)) {
path_list_insert(ref_name, &new_refs);
rm = alloc_ref(strlen(ref_name) + 1);
(I know Junio knows why this patch shouldn't be applied.
Its exactly why quickfetch calls rev-list --objects...)
The problem here is my quickfetch patch is bypassing the internal
call to fetch-pack. Which means we never do object handshaking,
and thus never allocate struct object* for the things we had been
talking about (because we never talked about them!). Or in the
case of commits, their trees and parents too. Thus the call above
to lookup_object() for a blob fails, as we never tried to parse it
before in fetch-pack.
Now I'm really not sure why we have blob objects allocated into
memory for lookup_object() during fetch-pack, but apparently we do.
At least during this test vector. It doesn't make sense if we are
only talking about commits (and their parents). I'd expect the
root trees to have objects (when the commit buffer was parsed for
graph traversal) but not blobs.
Maybe some smart individual will come up with the right solution to
keep automatic tag following enabled (safely!) while also allowing
us to use quickfetch. There's got to be a solution that doesn't
implicitly rely upon the handshaking we just happened to do with
the remote peer...
Me, I'm off to catch a few hours of sleep.
--
Shawn.
^ permalink raw reply related
* Re: git rebase --skip
From: Björn Steinbrink @ 2007-11-08 10:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Jeff King, Mike Hommey, git
In-Reply-To: <4732E5A8.3020101@op5.se>
On 2007.11.08 11:32:08 +0100, Andreas Ericsson wrote:
> Björn Steinbrink wrote:
>> On 2007.11.07 22:23:10 -0500, Jeff King wrote:
>>> On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:
>>>
>>>> I use git-rebase quite regularly, and I haven't used git-rebase --skip
>>>> after a failed merge without first resetting the working tree. I was
>>>> wondering if it wouldn't make sense to automatically do the reset when
>>>> running git-rebase --skip.
>>> I have often been annoyed by this behavior, too, and I can't think of
>>> any situation where you _wouldn't_ want the reset to happen. But I
>>> would be more comfortable hearing confirmation from others that they
>>> can't think of such a situation.
>>
>> Let's take this history:
>>
>> C---D---E topic
>> /
>> A---B master
>>
>> You then do:
>> git rebase master topic
>>
>> Now D causes conflicts, because B did a similar change, but not quite
>> the same, maybe having a bug. So you want to keep parts of D, but it's
>> no longer the same commit semantically and the original commit message
>> would be bogus. So you resolve the conflicts and do:
>>
>> git commit
>> git rebase --skip
>>
>> Because you replaced D with a new different commit, instead of really
>> just rebasing it. With plain --continue, you'd have to go back and fix
>> the commit message once the rebase is complete. And --continue after the
>> commit is a no-go, too, because rebase will complain that there's
>> nothing left to produce the rebased D commit.
>>
>> And now imagine that you forget to commit but instead just --skip.
>> Ouch, all the work is lost, time to restart the rebase. With the current
>> behaviour, rebase won't just throw away your stuff.
>>
>
> How about if the state to skip was stashed, the patch reapplied and the
> differences compared. If they were identical, go ahead and force the
> reset --hard, otherwise abort. That way, --skip will dwim only when
> it's safe, and all the lost work can be automagically created by
> just re-applying the patch again?
I'd prefer the --force option suggested in some other mail. Maybe I'm
just not manly enough, but messing up a rebase can mean lots of
duplicated work, so I'm rather happy with no dwim at all. Maybe for the
real manly users out there, add a rebase.alwaysForce option so they can
laugh at me for not using that ;-)
Björn
^ permalink raw reply
* Re: [PATCH] contrib/hooks/post-receive-email: add a From: line to the email header
From: Andreas Ericsson @ 2007-11-08 10:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Gerrit Pape, git, Andy Parkins
In-Reply-To: <7vode52hag.fsf@gitster.siamese.dyndns.org>
Junio C Hamano wrote:
> Gerrit Pape <pape@smarden.org> writes:
>
>> $committer is already extracted from the latest existing rev, so add the
>> corresponding From: line to the email header.
>
> You may fight this out with Andy if you want to, but I think I'd
> side with the existing behaviour.
>
I'm with Andy here, for the reasons stated below.
> commit e6dc8d60fbd2c84900a26545c5d360b0e202d95b
> Author: Andy Parkins <andyparkins@gmail.com>
> Date: Fri Sep 28 15:24:26 2007 +0100
>
> post-receive-hook: Remove the From field from the generated email header so that the pusher's name is used
>
> Using the name of the committer of the revision at the tip of the
> updated ref is not sensible. That information is available in the email
> itself should it be wanted, and by supplying a "From", we were
> effectively hiding the person who performed the push - which is useful
> information in itself.
>
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git rebase --skip
From: Andreas Ericsson @ 2007-11-08 10:32 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Jeff King, Mike Hommey, git
In-Reply-To: <20071108102412.GA31187@atjola.homenet>
Björn Steinbrink wrote:
> On 2007.11.07 22:23:10 -0500, Jeff King wrote:
>> On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:
>>
>>> I use git-rebase quite regularly, and I haven't used git-rebase --skip
>>> after a failed merge without first resetting the working tree. I was
>>> wondering if it wouldn't make sense to automatically do the reset when
>>> running git-rebase --skip.
>> I have often been annoyed by this behavior, too, and I can't think of
>> any situation where you _wouldn't_ want the reset to happen. But I
>> would be more comfortable hearing confirmation from others that they
>> can't think of such a situation.
>
> Let's take this history:
>
> C---D---E topic
> /
> A---B master
>
> You then do:
> git rebase master topic
>
> Now D causes conflicts, because B did a similar change, but not quite
> the same, maybe having a bug. So you want to keep parts of D, but it's
> no longer the same commit semantically and the original commit message
> would be bogus. So you resolve the conflicts and do:
>
> git commit
> git rebase --skip
>
> Because you replaced D with a new different commit, instead of really
> just rebasing it. With plain --continue, you'd have to go back and fix
> the commit message once the rebase is complete. And --continue after the
> commit is a no-go, too, because rebase will complain that there's
> nothing left to produce the rebased D commit.
>
> And now imagine that you forget to commit but instead just --skip.
> Ouch, all the work is lost, time to restart the rebase. With the current
> behaviour, rebase won't just throw away your stuff.
>
How about if the state to skip was stashed, the patch reapplied and the
differences compared. If they were identical, go ahead and force the
reset --hard, otherwise abort. That way, --skip will dwim only when
it's safe, and all the lost work can be automagically created by
just re-applying the patch again?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git rebase --skip
From: Björn Steinbrink @ 2007-11-08 10:24 UTC (permalink / raw)
To: Jeff King; +Cc: Mike Hommey, git
In-Reply-To: <20071108032308.GA5638@sigill.intra.peff.net>
On 2007.11.07 22:23:10 -0500, Jeff King wrote:
> On Wed, Nov 07, 2007 at 11:21:05PM +0100, Mike Hommey wrote:
>
> > I use git-rebase quite regularly, and I haven't used git-rebase --skip
> > after a failed merge without first resetting the working tree. I was
> > wondering if it wouldn't make sense to automatically do the reset when
> > running git-rebase --skip.
>
> I have often been annoyed by this behavior, too, and I can't think of
> any situation where you _wouldn't_ want the reset to happen. But I
> would be more comfortable hearing confirmation from others that they
> can't think of such a situation.
Let's take this history:
C---D---E topic
/
A---B master
You then do:
git rebase master topic
Now D causes conflicts, because B did a similar change, but not quite
the same, maybe having a bug. So you want to keep parts of D, but it's
no longer the same commit semantically and the original commit message
would be bogus. So you resolve the conflicts and do:
git commit
git rebase --skip
Because you replaced D with a new different commit, instead of really
just rebasing it. With plain --continue, you'd have to go back and fix
the commit message once the rebase is complete. And --continue after the
commit is a no-go, too, because rebase will complain that there's
nothing left to produce the rebased D commit.
And now imagine that you forget to commit but instead just --skip.
Ouch, all the work is lost, time to restart the rebase. With the current
behaviour, rebase won't just throw away your stuff.
Björn
^ permalink raw reply
* Re: git add -i fails to heed user's exclude settings
From: Miles Bader @ 2007-11-08 10:17 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4732DAD8.8000702@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Which git version are you using?
1.5.3.5
Thanks,
-Miles
--
The secret to creativity is knowing how to hide your sources.
--Albert Einstein
^ permalink raw reply
* Re: [PATCH 3/3] git-fetch: avoid local fetching from alternate (again)
From: Junio C Hamano @ 2007-11-08 10:07 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <20071108100039.GM14735@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> I'm starting to suspect heap corruption again in builtin-fetch.
> This patch alters the malloc() calls we are doing and may be shifting
> something around just enough in memory to cause a data overwrite or
> something and that's why this tag just drops out of the linked list?
> But then why does that happen in the test suite but not outside.
> Maybe because the test suite is setting environment variables that
> I'm not and the impact of those combined with these additional
> mallocs is what is breaking it? *sigh*
Thanks for working hard on this one.
It is starting to look like today was "let's kill other people's
bugs" day. I'd go to bed before I completely miss sleep, which
I often end up doing when thinking too long about bugs.
^ permalink raw reply
* Re: [PATCH 3/3] git-fetch: avoid local fetching from alternate (again)
From: Shawn O. Pearce @ 2007-11-08 10:00 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20071108080058.GC16690@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> wrote:
> Back in e3c6f240fd9c5bdeb33f2d47adc859f37935e2df Junio taught
> git-fetch to avoid copying objects when we are fetching from
> a repository that is already registered as an alternate object
> database. In such a case there is no reason to copy any objects
> as we can already obtain them through the alternate.
I haven't figured it out yet but this patch seriously breaks
t5515-fetch-merge-logic. For some reason the tag tag-three-file is
not being included in .git/FETCH_HEAD as a not-for-merge ref, but all
of the test vectors are expecting it to be present. Prior to this
patch it was included and I don't think the test vectors are wrong.
If I run git-fetch from outside the test library it does the right
thing and fetches this annotated tag pointing to a blob just fine.
But during the test vector it never even mentions that tag as part
of the status output, nor does it include it into .git/FETCH_HEAD.
Its almost like the tag ain't there.
I'm starting to suspect heap corruption again in builtin-fetch.
This patch alters the malloc() calls we are doing and may be shifting
something around just enough in memory to cause a data overwrite or
something and that's why this tag just drops out of the linked list?
But then why does that happen in the test suite but not outside.
Maybe because the test suite is setting environment variables that
I'm not and the impact of those combined with these additional
mallocs is what is breaking it? *sigh*
--
Shawn.
^ permalink raw reply
* Re: Strange git-show-branch behavior.
From: Sergei Organov @ 2007-11-08 9:58 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: git
In-Reply-To: <20071103182224.GA16345@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> On 2007.11.03 20:46:39 +0300, Sergei Organov wrote:
[...]
>> $ git-show-branch --more=9 master mybranch
>> * [master] Go to sleep
>> ! [mybranch] Some work.
>> --
>> * [master] Go to sleep
>> *+ [mybranch] Some work.
>> * [master~2] Some fun.
>> *+ [master~3] Commit message
>> *+ [master~4] Initial commit
>> $
>>
>> In this output, why git doesn't show the merge commit having "Merged
>> mybranch" commit message?
>
> Because you didn't pass --sparse.
Well, therefore, provided I have the following history:
.-F-. mybranch
/ \
A---B---C---D---E master
the 'D' merge commit is reachable only from 'master', so 'D' is not
shown unless I specify --sparse, right? Rather confusing, I'd say, and
the name 'sparse' for the option suggests that the output will have less
revisions in the output, not more. I mean I even didn't care to look at
the description of --sparse when I first read the manual page in order to
find some option to increase number of revs output, while I did look at
the --more.
What is the rationale for skipping such merge commits by default?
Anyway, courtesy to your explanation, I think I will be able to come
with a patch for the 'Documentation/core-tutorial.txt' that seems to
have wrong description for one of its examples.
>>
>> Yet another confusion:
>>
>> $ git-show-branch master mybranch
>> * [master] Go to sleep
>> ! [mybranch] Some work.
>> --
>> * [master] Go to sleep
>> *+ [mybranch] Some work.
>> $
>>
>> Why does it stop at "Some work." commit? The manual page says: "Usually
>> the command stops output upon showing the commit that is the common
>> ancestor of all the branches.", so I'd expect it should go down to
>> "Commit message" commit that is the fork point.
>
> Common ancestor means, that the commit is reachable through all refs.
> Let's take a look at your history:
>
> .-F-. mybranch
> / \
> A---B---C---D---E master
>
> There you can see that mybranch can of course reach F, and that master
> can reach it, too. E -> D -> F. So the output stops at F, not at B.
You are right, this particular confusion was due to my misunderstanding
of the term "common ancestor".
However, shouldn't "*the* common ancestor" in the manual be replaced by
"*a* common ancestor"? I mean that according to git-merge-base, there
could be multiple common ancestors even for 2 commits, so saying "*the*
common ancestor" implies use of particular algorithm to select
*the* common ancestor among all the possibilities, and therefore I'd
expect some explanation of the algorithm being used to get *the* common
ancestor.
--
Sergei.
^ permalink raw reply
* Re: [PATCH] contrib/hooks/post-receive-email: add a From: line to the email header
From: Junio C Hamano @ 2007-11-08 9:55 UTC (permalink / raw)
To: Gerrit Pape; +Cc: git, Andy Parkins
In-Reply-To: <20071108094809.22151.qmail@97f06c2e73713e.315fe32.mid.smarden.org>
Gerrit Pape <pape@smarden.org> writes:
> $committer is already extracted from the latest existing rev, so add the
> corresponding From: line to the email header.
You may fight this out with Andy if you want to, but I think I'd
side with the existing behaviour.
commit e6dc8d60fbd2c84900a26545c5d360b0e202d95b
Author: Andy Parkins <andyparkins@gmail.com>
Date: Fri Sep 28 15:24:26 2007 +0100
post-receive-hook: Remove the From field from the generated email header so that the pusher's name is used
Using the name of the committer of the revision at the tip of the
updated ref is not sensible. That information is available in the email
itself should it be wanted, and by supplying a "From", we were
effectively hiding the person who performed the push - which is useful
information in itself.
Signed-off-by: Andy Parkins <andyparkins@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 1f88099..cbbd02f 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -177,7 +177,6 @@ generate_email_header()
# --- Email (all stdout will be the email)
# Generate header
cat <<-EOF
- From: $committer
To: $recipients
Subject: ${EMAILPREFIX}$projectdesc $refname_type, $short_refname, ${change_type}d. $describe
X-Git-Refname: $refname
^ permalink raw reply related
* Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"
From: Johannes Sixt @ 2007-11-08 9:53 UTC (permalink / raw)
To: Andreas Ericsson, Steffen Prohaska; +Cc: gitster, Ralf.Wildenhues, tsuna, git
In-Reply-To: <4732D7F6.7040006@op5.se>
Andreas Ericsson schrieb:
> Johannes Sixt wrote:
>> Steffen Prohaska schrieb:
>>>
>>> On Nov 8, 2007, at 8:19 AM, Johannes Sixt wrote:
>>>
>>>> Steffen Prohaska schrieb:
>>>>> +If you linearize the history by rebasing the lower branch on
>>>>> +top of the upper, instead of merging, the bug becomes much easier to
>>>>> +find and understand. Your history would instead be:
>>>>
>>>> At this point I'm missing the words
>>>>
>>>> The solution is ...
>>>>
>>>> I.e.:
>>>>
>>>> The solution is to linearize the history by rebasing the lower
>>>> branch on
>>>> top of the upper, instead of merging. Now the bug becomes much
>>>> easier to
>>>> find and understand. Your history would instead be:
>>>
>>> Hmm. It might be a solution if you did not publish history.
>>
>> This is about finding the commit that introduced a bug. Once you found
>> it, better: you know how to fix the bug, you are expected to throw
>> away the rebased branch, not to publish it! Maybe a note along these
>> lines could be appended:
>>
>> Now that you know what caused the error (and how to fix it), throw
>> away the rebased branch, and commit a fix on top of D.
>>
>
> Well, if rebasing becomes the standard for normal development, it's hardly
> right to throw it away, is it? I like Steffen's suggestion better.
There is a big misunderstanding. The text that the patch amends is about
bisecting history that reveals that a merge commit breaks, which is not
helpful, and then how to find where and what and why the breakage really was
introduce.
And the answer to "how to find" is to rebase and bisect in the rebased history.
My initial complaint was that in the flow of reading the instructions the
pointer to "the solution" was missing. Rather, at the point where the reader
is supposed to think "ah, yes, that's how to do it", there is the
conditional statement "If you linearize history". My suggestion is to put a
big emphasis on the solution by using the words "The solution is".
Now, the user can *always* rebase one of the branches on top of the other,
even if both histories are already published. *But* if both were indeed
published, then the rebased history must be thrown away, and the only thing
you learnt from it was where and what and why the breakage really was
introduced.
Of course we could include a few "ifs" and "unlesses" (about published
histories), before suggesting to throw away rebased history. But once the
task is accomplished (find the bogus commit), throwing away the rebased
history (and continuing at commit D) is always correct, but keeping it (and
continuing at D*) is not.
-- Hannes
^ permalink raw reply
* [PATCH] contrib/hooks/post-receive-email: add a From: line to the email header
From: Gerrit Pape @ 2007-11-08 9:48 UTC (permalink / raw)
To: git, Junio C Hamano
$committer is already extracted from the latest existing rev, so add the
corresponding From: line to the email header.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
contrib/hooks/post-receive-email | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/contrib/hooks/post-receive-email b/contrib/hooks/post-receive-email
index 3904c18..c73f2d5 100644
--- a/contrib/hooks/post-receive-email
+++ b/contrib/hooks/post-receive-email
@@ -189,6 +189,7 @@ generate_email_header()
# --- Email (all stdout will be the email)
# Generate header
cat <<-EOF
+ From: $committer
To: $recipients
Subject: ${emailprefix}$projectdesc $refname_type, $short_refname, ${change_type}d. $describe
X-Git-Refname: $refname
--
1.5.3.5
^ permalink raw reply related
* [PATCH] hooks--update: decline deleting tags or branches by default, add config options
From: Gerrit Pape @ 2007-11-08 9:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v640d8skt.fsf@gitster.siamese.dyndns.org>
Decline deleting tags or branches through git push <remote> :<ref> by
default, support config options hooks.allowdeletetag, hooks.allowdeletebranch
to override this per repository.
Before this patch the update hook interpreted deleting a tag, no matter if
annotated or not, through git push <remote> :<tag> as unannotated tag, and
declined it by default, but with an unappropriate error message:
$ git push origin :atag
deleting 'refs/tags/atag'
*** The un-annotated tag, atag, is not allowed in this repository
*** Use 'git tag [ -a | -s ]' for tags you want to propagate.
ng refs/tags/atag hook declined
error: hooks/update exited with error code 1
error: hook declined to update refs/tags/atag
error: failed to push to 'monolith:/git/qm/test-repo'
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
On Wed, Nov 07, 2007 at 04:54:42PM -0800, Junio C Hamano wrote:
> Since you are allowing deletion for anything, wouldn't this be
> much simpler, I wonder...
Yes, true. But to be a good axample hook, I suggest to differentiate
this in the implementation, and to deny deleting tags, branches by
default.
templates/hooks--update | 33 +++++++++++++++++++++++++++++++--
1 files changed, 31 insertions(+), 2 deletions(-)
diff --git a/templates/hooks--update b/templates/hooks--update
index 65e8c32..7d7c251 100644
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -10,6 +10,12 @@
# hooks.allowunannotated
# This boolean sets whether unannotated tags will be allowed into the
# repository. By default they won't be.
+# hooks.allowdeletetag
+# This boolean sets whether deleting tags will be allowed in the
+# repository. By default they won't be.
+# hooks.allowdeletebranch
+# This boolean sets whether deleting branches will be allowed in the
+# repository. By default they won't be.
#
# --- Command line
@@ -32,6 +38,8 @@ fi
# --- Config
allowunannotated=$(git-repo-config --bool hooks.allowunannotated)
+allowdeletebranch=$(git-repo-config --bool hooks.allowdeletebranch)
+allowdeletetag=$(git-repo-config --bool hooks.allowdeletetag)
# check for no description
projectdesc=$(sed -ne '1p' "$GIT_DIR/description")
@@ -41,9 +49,9 @@ if [ -z "$projectdesc" -o "$projectdesc" = "Unnamed repository; edit this file t
fi
# --- Check types
-# if $newrev is 0000...0000, it's a commit to delete a branch
+# if $newrev is 0000...0000, it's a commit to delete a ref.
if [ "$newrev" = "0000000000000000000000000000000000000000" ]; then
- newrev_type=commit
+ newrev_type=delete
else
newrev_type=$(git-cat-file -t $newrev)
fi
@@ -58,15 +66,36 @@ case "$refname","$newrev_type" in
exit 1
fi
;;
+ refs/tags/*,delete)
+ # delete tag
+ if [ "$allowdeletetag" != "true" ]; then
+ echo "*** Deleting a tag is not allowed in this repository" >&2
+ exit 1
+ fi
+ ;;
refs/tags/*,tag)
# annotated tag
;;
refs/heads/*,commit)
# branch
;;
+ refs/heads/*,delete)
+ # delete branch
+ if [ "$allowdeletebranch" != "true" ]; then
+ echo "*** Deleting a branch is not allowed in this repository" >&2
+ exit 1
+ fi
+ ;;
refs/remotes/*,commit)
# tracking branch
;;
+ refs/remotes/*,delete)
+ # delete tracking branch
+ if [ "$allowdeletebranch" != "true" ]; then
+ echo "*** Deleting a tracking branch is not allowed in this repository" >&2
+ exit 1
+ fi
+ ;;
*)
# Anything else (is there anything else?)
echo "*** Update hook: unknown type of update to ref $refname of type $newrev_type" >&2
--
1.5.3.5
^ permalink raw reply related
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox