* 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
* 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
* [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
* [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 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 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 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 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 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
* Re: git push mirror mode
From: Johannes Schindelin @ 2007-11-08 12:19 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <20071108121136.GG9736@shadowen.org>
Hi,
On Thu, 8 Nov 2007, Andy Whitcroft wrote:
> Ok, sometime back Junio sent out a proof-of-concept change to
> send-pack allowing a mirror mode.
You added/left his sign-off, but did not attribute the patches to him.
Why?
Ciao,
Dscho
P.S.: Without tests I am opposed to inclusion. This _definitely_ needs
some tests.
^ permalink raw reply
* Re: [PATCH 2/3] launch_editor(): read the file, even when EDITOR=:
From: Johannes Sixt @ 2007-11-08 12:33 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, krh, gitster
In-Reply-To: <Pine.LNX.4.64.0711081215360.4362@racer.site>
Johannes Schindelin schrieb:
> + struct child_process child;
> + memset(&child, 0, sizeof(child));
> + child.argv = args;
> + args[0] = editor;
> + args[1] = path;
> + args[2] = NULL;
>
> + if (run_command(&child))
You can shorten this to
const char *args[] = { editor, path, NULL };
if (run_command_v_opt(args, 0))
(and possibly remove 'args' that is in the surrounding block).
-- Hannes
^ permalink raw reply
* Re: git push mirror mode
From: Andy Whitcroft @ 2007-11-08 12:44 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0711081218090.4362@racer.site>
On Thu, Nov 08, 2007 at 12:19:18PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Thu, 8 Nov 2007, Andy Whitcroft wrote:
>
> > Ok, sometime back Junio sent out a proof-of-concept change to
> > send-pack allowing a mirror mode.
>
> You added/left his sign-off, but did not attribute the patches to him.
> Why?
I believe I left his signed off by from the original (first) patch, and
added mine to indicate that what I had modified was also unecombered.
The second patch is only signed off by me as I am the author. In my
world (admittedly a kernel hacker) the first Signed-off-by: indicates the
primary authorship of that patch and the [apw@...] part tries to clarify
the changes I made therein.
No intentional stripping of credit was intended, and I believe that the
attribution as written states Junio is the originator of this patch.
However that is the way I would read the meanings of these lines, if git
has different rules or you think there is a clearer way of stating this
I am happy to change it, and resend it so attributed.
-apw
^ permalink raw reply
* Re: git push mirror mode
From: Andy Whitcroft @ 2007-11-08 12:49 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0711081218090.4362@racer.site>
On Thu, Nov 08, 2007 at 12:19:18PM +0000, Johannes Schindelin wrote:
> P.S.: Without tests I am opposed to inclusion. This _definitely_ needs
> some tests.
This is very much 'pu' material right now. I've used it for a day
keeping some kernel repos in sync on a couple of test boxes. Hardly
extensive testing.
Yes some tests would be advisable. However I am no expert in the git
test system, so I am not going to be able to do that in short order.
What little time I had to work on this this morning was wasted by some
SarBox madness here (but that is another story). In the spirit of
making progress on what is a useful feature I pulled Junio's original
change forward, fixed up my patch to expose it the the user and gave it
some testing.
Whats there does seem to work and has a prima-facie use case. Hopefully
someone can provide the nessary tests before I can.
-apw
^ permalink raw reply
* Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"
From: Steffen Prohaska @ 2007-11-08 12:54 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Andreas Ericsson, gitster, Ralf.Wildenhues, tsuna, git
In-Reply-To: <4732DC98.70304@viscovery.net>
On Nov 8, 2007, at 10:53 AM, Johannes Sixt wrote:
> 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.
Do you use rebase like this in real life?
I thought of the text as background information that might
be helpful for users who want do decide wether to merge or
to rebase. The problem described may be valuable information
supporting a decision about a recommended workflow for a group
of users.
My personal conclusion was: I'll accept the danger of complex
merges that might be hard to bisect. I now understand this
risk, but I nonetheless prefer the simplicity of a merge
based workflow. This avoids the danger that published history
gets rewritten.
But now I'm wondering if your suggestions of rebasing only for
locating the evil commit is feasible in reality. You may need
to solve a lot of merge conflicts if you rebase a larger part
of the history. If you do not have them in your rerere cache
this might be time consuming. ...
> 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.
... So, again, the question for me is if someone does use
rebase in reality in the way that you suggests. Do you? Does
someone else?
Steffen
^ permalink raw reply
* Re: [PATCH] git-checkout: Handle relative paths containing "..".
From: David Symonds @ 2007-11-08 13:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin
In-Reply-To: <7v4pfx3zs3.fsf@gitster.siamese.dyndns.org>
On Nov 8, 2007 7:30 PM, Junio C Hamano <junio@pobox.com> wrote:
>
> Have you tested this patch from the toplevel of any tree, where
> "git-rev-parse --show-cdup" would yield an empty string?
No, I didn't. Arguably, "git-rev-parse --show-cdup" should always
return a path to the top-level, which would make this kind of
construction much simpler. Is there anything that relies upon it
returning the empty string when you're in the top-level directory?
> I also wonder how this patch (with an obvious fix to address the
> above point) would interact with GIT_DIR and/or GIT_WORK_TREE in
> the environment.
No idea. I'm still learning my way around the git codebase, so I was
hoping for some review and feedback from more experienced Gits.
Dave.
^ permalink raw reply
* Re: [REPLACEMENT PATCH] git-checkout: Add a test case for relative paths use.
From: David Symonds @ 2007-11-08 13:12 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, git, Johannes Schindelin
In-Reply-To: <4732D5A9.5040504@op5.se>
On Nov 8, 2007 8:23 PM, Andreas Ericsson <ae@op5.se> wrote:
>
> Single-dashes on all of these?
Damn. I wonder how it passed? I'll resend shortly.
Dave.
^ permalink raw reply
* [NEW REPLACEMENT PATCH] git-checkout: Add a test case for relative paths use.
From: David Symonds @ 2007-11-08 13:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Johannes Schindelin, Andreas Ericsson, David Symonds
Signed-off-by: David Symonds <dsymonds@gmail.com>
---
t/t2008-checkout-subdir.sh | 47 ++++++++++++++++++++++++++++++++++++++++++++
1 files changed, 47 insertions(+), 0 deletions(-)
create mode 100755 t/t2008-checkout-subdir.sh
diff --git a/t/t2008-checkout-subdir.sh b/t/t2008-checkout-subdir.sh
new file mode 100755
index 0000000..45b9e13
--- /dev/null
+++ b/t/t2008-checkout-subdir.sh
@@ -0,0 +1,47 @@
+#!/bin/sh
+#
+# Copyright (c) 2007 David Symonds
+
+test_description='git checkout from subdirectories'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+
+ echo base > file0 &&
+ git add file0 &&
+ mkdir dir1 &&
+ echo hello > dir1/file1 &&
+ git add dir1/file1 &&
+ test_tick &&
+ mkdir dir2 &&
+ echo bonjour > dir2/file2 &&
+ git add dir2/file2 &&
+ git commit -m "populate tree"
+
+'
+
+test_expect_success 'remove and restore with relative path' '
+
+ cd dir1 &&
+ rm ../file0 &&
+ git checkout HEAD -- ../file0 && test -f ../file0 &&
+ rm ../dir2/file2 &&
+ git checkout HEAD -- ../dir2/file2 && test -f ../dir2/file2 &&
+ rm ../file0 ./file1 &&
+ git checkout HEAD -- .. && test -f ../file0 && test -f ./file1 &&
+ rm file1 &&
+ git checkout HEAD -- ../dir1/../dir1/file1 && test -f ./file1
+
+'
+
+test_expect_failure 'checkout with relative path outside tree should fail (1)' \
+ 'git checkout HEAD -- ../file0'
+
+test_expect_failure 'checkout with relative path outside tree should fail (2)' \
+ 'cd dir1 && git checkout HEAD -- ./file0'
+
+test_expect_failure 'checkout with relative path outside tree should fail (2)' \
+ 'cd dir1 && git checkout HEAD -- ../../file0'
+
+test_done
--
1.5.3.1
^ permalink raw reply related
* Re: git push mirror mode
From: Andreas Ericsson @ 2007-11-08 13:14 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <20071108124435.GH9736@shadowen.org>
Andy Whitcroft wrote:
> On Thu, Nov 08, 2007 at 12:19:18PM +0000, Johannes Schindelin wrote:
>> Hi,
>>
>> On Thu, 8 Nov 2007, Andy Whitcroft wrote:
>>
>>> Ok, sometime back Junio sent out a proof-of-concept change to
>>> send-pack allowing a mirror mode.
>> You added/left his sign-off, but did not attribute the patches to him.
>> Why?
>
> I believe I left his signed off by from the original (first) patch, and
> added mine to indicate that what I had modified was also unecombered.
> The second patch is only signed off by me as I am the author. In my
> world (admittedly a kernel hacker) the first Signed-off-by: indicates the
> primary authorship of that patch and the [apw@...] part tries to clarify
> the changes I made therein.
>
> No intentional stripping of credit was intended, and I believe that the
> attribution as written states Junio is the originator of this patch.
> However that is the way I would read the meanings of these lines, if git
> has different rules or you think there is a clearer way of stating this
> I am happy to change it, and resend it so attributed.
>
Barring any errors in my understanding of the matter, here's how it
works for git.
git separates author from committer, so code attribution is done with
author, and "I verified this is sane" is done by committer. Those two
usually only ever differ when the user tells git commit that the author
was someone else than him/her self, or when rewriting history with git
rebase or similar. git am also maintains authorship (using the From:
line in emails), but sets $committer to the person running it, so when
you apply patches sent by email from someone else you get the code
attribution right by default.
The Signed-off-by line is, in git, used as "I touched the code here and
agree that it may be included in the mothership repo and all future
releases" (the spirit of that sentence is also in
Documentation/SubmittingPatches).
We also have Acked-by (as does the kernel, no? I think we inherited it
from there) to mean something along the lines of "I vote we include this",
but not always based on technical merit (ie, patches can have many acks
without having ever been tested).
Suggested-by, Tested-by and Reported-by are used less often, not always
written in dash-form, but hopefully always self-explanatory ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Inconsistencies with git log
From: David Symonds @ 2007-11-08 13:16 UTC (permalink / raw)
To: Andreas Ericsson
Cc: Brian Gernhardt, Jon Smirl, Johannes Schindelin, Git Mailing List
In-Reply-To: <47325415.1070205@op5.se>
On Nov 8, 2007 11:11 AM, Andreas Ericsson <ae@op5.se> wrote:
>
> David Symonds wrote:
> > On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
> >> However, Dave's suggestion of altering git-status output to be
> >> relative to (but not limited by) CWD has merit. Too bad I don't have
> >> time to work on it right now.
> >
> > I am happy to hack on this if there's not widespread revolt against the concept.
> >
>
> I'd definitely like that feature, but I wonder how many people will run
> "git commit -a" in a subdir after seeing only what they want to see in the
> output, and then accidentally committing junk somewhere else in the repo.
I never suggested path *limited*, only path *relative*. git-status
would still show all the same files, but their paths would be relative
to your current directory, so there'd be no confusion like you
mentioned. This is how Johannes' patch works.
Dave.
^ permalink raw reply
* Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"
From: Johannes Sixt @ 2007-11-08 13:22 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Andreas Ericsson, gitster, Ralf.Wildenhues, tsuna, git
In-Reply-To: <97F64156-A457-4BC1-84BE-108369FFD18C@zib.de>
Steffen Prohaska schrieb:
>
> On Nov 8, 2007, at 10:53 AM, Johannes Sixt wrote:
>> 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.
>
> Do you use rebase like this in real life?
Why is this relevant?
You've written a superb addendum to the user manual, but IT TALKS ABOUT
BISECTION, and is not a guideline when to use merges and when to rebase.
It better not be meant as such. Consider an integrator who has just merged
two histories, both of which are available publically. Pushing out a rebased
history IS NOT AN OPTION. If the poor fellow for the heck of it has no
choice but to find the bogus commit, then your instructions are worth a
thousand bucks - even if the rebased history is otherwise useless -, but any
guidelines how to construct histories are IRRELEVANT for his case.
> But now I'm wondering if your suggestions of rebasing only for
> locating the evil commit is feasible in reality. You may need
> to solve a lot of merge conflicts if you rebase a larger part
> of the history. If you do not have them in your rerere cache
> this might be time consuming. ...
During the rebase you will see the same conflicts that you also had during
the merge, even simpler ones (because they are - hopefully - broken down
into smaller pieces). If your merge was clean (as was suggested in the
patch), then you won't see a lot of conflicts during the rebase, either.
-- Hannes
^ permalink raw reply
* Re: [PATCH v2] user-manual: add advanced topic "bisecting merges"
From: Andreas Ericsson @ 2007-11-08 13:38 UTC (permalink / raw)
To: Steffen Prohaska; +Cc: Johannes Sixt, gitster, Ralf.Wildenhues, tsuna, git
In-Reply-To: <97F64156-A457-4BC1-84BE-108369FFD18C@zib.de>
Steffen Prohaska wrote:
>
> On Nov 8, 2007, at 10:53 AM, Johannes Sixt wrote:
>
>> 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.
>
> Do you use rebase like this in real life?
>
> I thought of the text as background information that might
> be helpful for users who want do decide wether to merge or
> to rebase. The problem described may be valuable information
> supporting a decision about a recommended workflow for a group
> of users.
>
> My personal conclusion was: I'll accept the danger of complex
> merges that might be hard to bisect. I now understand this
> risk, but I nonetheless prefer the simplicity of a merge
> based workflow. This avoids the danger that published history
> gets rewritten.
>
> But now I'm wondering if your suggestions of rebasing only for
> locating the evil commit is feasible in reality. You may need
> to solve a lot of merge conflicts if you rebase a larger part
> of the history. If you do not have them in your rerere cache
> this might be time consuming. ...
>
It is no great chore to put one merge-parent on top of another
and then re-run bisect on the result. git-bisect could even be
taught to do that by itself.
>
>> 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.
>
> ... So, again, the question for me is if someone does use
> rebase in reality in the way that you suggests. Do you?
I don't, but if I'd thought a bit further I would have on at least one
occasion in the past. Instead I spent two days manually auditing every
commit of several branches.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Inconsistencies with git log
From: Andreas Ericsson @ 2007-11-08 13:40 UTC (permalink / raw)
To: David Symonds
Cc: Brian Gernhardt, Jon Smirl, Johannes Schindelin, Git Mailing List
In-Reply-To: <ee77f5c20711080516n4f207ba3pccc8efffa2a6ad4c@mail.gmail.com>
David Symonds wrote:
> On Nov 8, 2007 11:11 AM, Andreas Ericsson <ae@op5.se> wrote:
>> David Symonds wrote:
>>> On Nov 8, 2007 10:19 AM, Brian Gernhardt <benji@silverinsanity.com> wrote:
>>>> However, Dave's suggestion of altering git-status output to be
>>>> relative to (but not limited by) CWD has merit. Too bad I don't have
>>>> time to work on it right now.
>>> I am happy to hack on this if there's not widespread revolt against the concept.
>>>
>> I'd definitely like that feature, but I wonder how many people will run
>> "git commit -a" in a subdir after seeing only what they want to see in the
>> output, and then accidentally committing junk somewhere else in the repo.
>
> I never suggested path *limited*, only path *relative*. git-status
> would still show all the same files, but their paths would be relative
> to your current directory, so there'd be no confusion like you
> mentioned. This is how Johannes' patch works.
>
Ah, that'd be a different matter entirely then. Thanks for clarifying. I
have no further objections then.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git push mirror mode
From: Andy Whitcroft @ 2007-11-08 13:44 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <47330BA4.6030101@op5.se>
On Thu, Nov 08, 2007 at 02:14:12PM +0100, Andreas Ericsson wrote:
> Barring any errors in my understanding of the matter, here's how it
> works for git.
>
> git separates author from committer, so code attribution is done with
> author, and "I verified this is sane" is done by committer. Those two
> usually only ever differ when the user tells git commit that the author
> was someone else than him/her self, or when rewriting history with git
> rebase or similar. git am also maintains authorship (using the From:
> line in emails), but sets $committer to the person running it, so when
> you apply patches sent by email from someone else you get the code
> attribution right by default.
>
> The Signed-off-by line is, in git, used as "I touched the code here and
> agree that it may be included in the mothership repo and all future
> releases" (the spirit of that sentence is also in
> Documentation/SubmittingPatches).
>
> We also have Acked-by (as does the kernel, no? I think we inherited it
> from there) to mean something along the lines of "I vote we include this",
> but not always based on technical merit (ie, patches can have many acks
> without having ever been tested).
>
> Suggested-by, Tested-by and Reported-by are used less often, not always
> written in dash-form, but hopefully always self-explanatory ;-)
What that doesn't tell me is how when sending an email carrying a patch
one ensures the attribution is correct when loaded into git.
Having messed about with it a bit it does seem that if one wants git to
attribute the patch to junio I have to add a From: line to the top of
the email payload.
I'll resend so attributed.
-apw
^ permalink raw reply
* Re: git push mirror mode
From: Andreas Ericsson @ 2007-11-08 13:48 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: Johannes Schindelin, git, Junio C Hamano
In-Reply-To: <20071108134432.GK9736@shadowen.org>
Andy Whitcroft wrote:
> On Thu, Nov 08, 2007 at 02:14:12PM +0100, Andreas Ericsson wrote:
>
>> Barring any errors in my understanding of the matter, here's how it
>> works for git.
>>
>> git separates author from committer, so code attribution is done with
>> author, and "I verified this is sane" is done by committer. Those two
>> usually only ever differ when the user tells git commit that the author
>> was someone else than him/her self, or when rewriting history with git
>> rebase or similar. git am also maintains authorship (using the From:
>> line in emails), but sets $committer to the person running it, so when
>> you apply patches sent by email from someone else you get the code
>> attribution right by default.
>>
>> The Signed-off-by line is, in git, used as "I touched the code here and
>> agree that it may be included in the mothership repo and all future
>> releases" (the spirit of that sentence is also in
>> Documentation/SubmittingPatches).
>>
>> We also have Acked-by (as does the kernel, no? I think we inherited it
>> from there) to mean something along the lines of "I vote we include this",
>> but not always based on technical merit (ie, patches can have many acks
>> without having ever been tested).
>>
>> Suggested-by, Tested-by and Reported-by are used less often, not always
>> written in dash-form, but hopefully always self-explanatory ;-)
>
> What that doesn't tell me is how when sending an email carrying a patch
> one ensures the attribution is correct when loaded into git.
>
Ach damn. I had a sentence there reading "From: can also be specified in
the email body to attribute code to someone else than the sender." It's
in my clipboard, but I forgot to paste it :-/
> Having messed about with it a bit it does seem that if one wants git to
> attribute the patch to junio I have to add a From: line to the top of
> the email payload.
>
> I'll resend so attributed.
>
Thanks.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] hooks--update: fix test for properly set up project description file
From: Gerrit Pape @ 2007-11-08 14:02 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git, Junio C Hamano
In-Reply-To: <4730726B.1000407@op5.se>
The update hook template intends to abort if the project description file
hasn't been adjusted or is empty. This patch fixes the check for 'being
adjusted'.
Signed-off-by: Gerrit Pape <pape@smarden.org>
---
On Tue, Nov 06, 2007 at 02:55:55PM +0100, Andreas Ericsson wrote:
> Gerrit Pape wrote:
> > # check for no description
> >-projectdesc=$(sed -e '1p' "$GIT_DIR/description")
> >-if [ -z "$projectdesc" -o "$projectdesc" = "Unnamed repository; edit
> >this
> >file to name it for gitweb" ]; then
> >+projectdesc=$(sed -ne '1p' "$GIT_DIR/description")
>
> Write this as
> projectdesc=$(sed -e 1q "$GIT_DIR/description")
> instead. It's a little shorter, a little faster and slightly more
> portable.
I made it $(head -n 1 ...).
templates/hooks--update | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
diff --git a/templates/hooks--update b/templates/hooks--update
index d8c7626..fbf664f 100644
--- a/templates/hooks--update
+++ b/templates/hooks--update
@@ -34,8 +34,8 @@ fi
allowunannotated=$(git-repo-config --bool hooks.allowunannotated)
# check for no description
-projectdesc=$(sed -e '1p' "$GIT_DIR/description")
-if [ -z "$projectdesc" -o "$projectdesc" = "Unnamed repository; edit this file to name it for gitweb" ]; then
+projectdesc=$(head -n 1 "$GIT_DIR/description")
+if [ -z "$projectdesc" -o "$projectdesc" = "Unnamed repository; edit this file to name it for gitweb." ]; then
echo "*** Project description file hasn't been set" >&2
exit 1
fi
--
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