* [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: [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
* 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: [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: 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: 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: [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: 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
* [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
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