* [PATCHv2 3/4] run-command: help callers distinguish errors
From: Jeff King @ 2009-01-28 7:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <20090128073059.GD19165@coredump.intra.peff.net>
run_command returns a single integer specifying either an
error code or the exit status of the spawned program. The
only way to tell the difference is that the error codes are
outside of the allowed range of exit status values.
Rather than make each caller implement the test against a
magic limit, let's provide a macro.
Signed-off-by: Jeff King <peff@peff.net>
---
New since v1 of the series.
run-command.h | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/run-command.h b/run-command.h
index 0211e1d..a88b3cd 100644
--- a/run-command.h
+++ b/run-command.h
@@ -10,6 +10,7 @@ enum {
ERR_RUN_COMMAND_WAITPID_SIGNAL,
ERR_RUN_COMMAND_WAITPID_NOEXIT,
};
+#define IS_RUN_COMMAND_ERR(x) (x >= ERR_RUN_COMMAND_FORK)
struct child_process {
const char **argv;
--
1.6.1.1.367.g30b36
^ permalink raw reply related
* Re: git 1.6.1 on AIX 5.3
From: Junio C Hamano @ 2009-01-28 7:37 UTC (permalink / raw)
To: Jeff King; +Cc: Perry Smith, Mike Ralphson, git
In-Reply-To: <20090128070114.GB19165@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Jan 27, 2009 at 07:35:00PM -0600, Perry Smith wrote:
>
>> Just to be sure we are on the same page. My directory structure has a
>> top/src/git-1.6.1 and top/build/git.1.6.1. The src/git-1.6.1 is the
>> tar ball. The build/git-1.6.1 starts out empty. I cd into it and
>> then do: ../../src/git-1.6.1/configure <options> After this
>> completes, you can do "make".
>
> I don't see how this would work without automake support, which git does
> not have.
... nor want to have ;-).
^ permalink raw reply
* [PATCHv2 4/4] git: use run_command to execute dashed externals
From: Jeff King @ 2009-01-28 7:38 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <20090128073059.GD19165@coredump.intra.peff.net>
We used to simply try calling execvp(); if it succeeded,
then we were done and the new program was running. If it
didn't, then we knew that it wasn't a valid command.
Unfortunately, this interacted badly with the new pager
handling. Now that git remains the parent process and the
pager is spawned, git has to hang around until the pager is
finished. We install an atexit handler to do this, but that
handler never gets called if we successfully run execvp.
You could see this behavior by running any dashed external
using a pager (e.g., "git -p stash list"). The command
finishes running, but the pager is still going. In the case
of less, it then gets an error reading from the terminal and
exits, potentially leaving the terminal in a broken state
(and not showing the output).
This patch just uses run_command to try running the
dashed external. The parent git process then waits for the
external process to complete and then handles the pager
cleanup as it would for an internal command.
Signed-off-by: Jeff King <peff@peff.net>
---
Incorporates negated status fix from JSixt.
This version also differentiates in the exit code and stderr output
whether we simply failed to exec the command versus passing along its
status code.
git.c | 17 +++++++++++++----
1 files changed, 13 insertions(+), 4 deletions(-)
diff --git a/git.c b/git.c
index 45e493d..b02b05b 100644
--- a/git.c
+++ b/git.c
@@ -2,6 +2,7 @@
#include "exec_cmd.h"
#include "cache.h"
#include "quote.h"
+#include "run-command.h"
const char git_usage_string[] =
"git [--version] [--exec-path[=GIT_EXEC_PATH]] [-p|--paginate|--no-pager] [--bare] [--git-dir=GIT_DIR] [--work-tree=GIT_WORK_TREE] [--help] COMMAND [ARGS]";
@@ -392,6 +393,7 @@ static void execv_dashed_external(const char **argv)
{
struct strbuf cmd = STRBUF_INIT;
const char *tmp;
+ int status;
strbuf_addf(&cmd, "git-%s", argv[0]);
@@ -406,10 +408,17 @@ static void execv_dashed_external(const char **argv)
trace_argv_printf(argv, "trace: exec:");
- /* execvp() can only ever return if it fails */
- execvp(cmd.buf, (char **)argv);
-
- trace_printf("trace: exec failed: %s\n", strerror(errno));
+ /*
+ * if we fail because the command is not found, it is
+ * OK to return. Otherwise, we just pass along the status code.
+ */
+ status = run_command_v_opt(argv, 0);
+ if (status != -ERR_RUN_COMMAND_EXEC) {
+ if (IS_RUN_COMMAND_ERR(status))
+ die("unable to run '%s'", argv[0]);
+ exit(-status);
+ }
+ errno = ENOENT; /* as if we called execvp */
argv[0] = tmp;
--
1.6.1.1.367.g30b36
^ permalink raw reply related
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 7:41 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, PJ Hyett, Johannes Schindelin, git
In-Reply-To: <7vd4e7x5ov.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Here is my work in progress. It introduces "ignore-missing-negative"
> option to the revision traversal machinery, and squelches the places we
> currently complain loudly and die when we expect an object to be
> available, when the color we are going to paint the object with is
> UNINTERESTING.
>
> I have a mild suspicion that it may even be the right thing to ignore them
> unconditionally, and it might even match the intention of Linus's original
> code. That would make many hunks in this patch much simpler.
>
> The evidences behind this suspicion are found in a handful of places in
> revision.c. mark_blob_uninteresting() does not complain if the caller
> fails to find the blob. mark_tree_uninteresting() does not, either.
> mark_parents_uninteresting() does not, either, and it even has a comment
> that strongly suggests the original intention was not to care about
> missing UNINTERESTING objects.
Here is what I ended up with doing. It lost "ignore-missing-negative"
so missing UNINTERESTING objects are non-error events more uniformly,
but on the other hand get_reference() which is about the command line
arguments always wants the named objects to exist, even if they are
marked as UNINTERESTING.
I'll send [PATCH 1/2] which is an update to my previous fix as a follow-up
to this message.
-- >8 --
Subject: [PATCH 2/2] revision traversal: allow UNINTERESTING objects to be missing
Most of the existing codepaths were meant to treat missing uninteresting
objects to be a silently ignored non-error, but there were a few places
in handle_commit() and add_parents_to_list(), which are two key functions
in the revision traversal machinery, that cared:
- When a tag refers to an object that we do not have, we barfed. We
ignore such a tag if it is painted as UNINTERESTING with this change.
- When digging deeper into the ancestry chain of a commit that is already
painted as UNINTERESTING, in order to paint its parents UNINTERESTING,
we barfed if parse_parent() for a parent commit object failed. We can
ignore such a parent commit object.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
revision.c | 7 +++++--
t/t5519-push-alternates.sh | 37 +++++++++++++++++++++++++++++++++++++
2 files changed, 42 insertions(+), 2 deletions(-)
diff --git a/revision.c b/revision.c
index db60f06..ea8ba0f 100644
--- a/revision.c
+++ b/revision.c
@@ -183,8 +183,11 @@ static struct commit *handle_commit(struct rev_info *revs, struct object *object
if (!tag->tagged)
die("bad tag");
object = parse_object(tag->tagged->sha1);
- if (!object)
+ if (!object) {
+ if (flags & UNINTERESTING)
+ return NULL;
die("bad object %s", sha1_to_hex(tag->tagged->sha1));
+ }
}
/*
@@ -480,7 +483,7 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit,
struct commit *p = parent->item;
parent = parent->next;
if (parse_commit(p) < 0)
- return -1;
+ continue;
p->object.flags |= UNINTERESTING;
if (p->parents)
mark_parents_uninteresting(p);
diff --git a/t/t5519-push-alternates.sh b/t/t5519-push-alternates.sh
index 6dfc55a..96be523 100755
--- a/t/t5519-push-alternates.sh
+++ b/t/t5519-push-alternates.sh
@@ -103,4 +103,41 @@ test_expect_success 'bob works and pushes' '
)
'
+test_expect_success 'alice works and pushes yet again' '
+ (
+ # Alice does not care what Bob does. She does not
+ # even have to be aware of his existence. She just
+ # keeps working and pushing
+ cd alice-work &&
+ echo more and more alice >file &&
+ git commit -a -m sixth.1 &&
+ echo more and more alice >>file &&
+ git commit -a -m sixth.2 &&
+ echo more and more alice >>file &&
+ git commit -a -m sixth.3 &&
+ git push ../alice-pub
+ )
+'
+
+test_expect_success 'bob works and pushes again' '
+ (
+ cd alice-pub &&
+ git cat-file commit master >../bob-work/commit
+ )
+ (
+ # This time Bob does not pull from Alice, and
+ # the master branch at her public repository points
+ # at a commit Bob does not fully know about, but
+ # he happens to have the commit object (but not the
+ # necessary tree) in his repository from Alice.
+ # This should not prevent the push by Bob from
+ # succeeding.
+ cd bob-work &&
+ git hash-object -t commit -w commit &&
+ echo even more bob >file &&
+ git commit -a -m seventh &&
+ git push ../bob-pub
+ )
+'
+
test_done
--
1.6.1.1.273.g0e555
^ permalink raw reply related
* Re: git 1.6.1 on AIX 5.3
From: Jeff King @ 2009-01-28 7:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Perry Smith, Mike Ralphson, git
In-Reply-To: <7v4ozjx4ni.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 27, 2009 at 11:37:21PM -0800, Junio C Hamano wrote:
> >> Just to be sure we are on the same page. My directory structure has a
> >> top/src/git-1.6.1 and top/build/git.1.6.1. The src/git-1.6.1 is the
> >> tar ball. The build/git-1.6.1 starts out empty. I cd into it and
> >> then do: ../../src/git-1.6.1/configure <options> After this
> >> completes, you can do "make".
> >
> > I don't see how this would work without automake support, which git does
> > not have.
>
> ... nor want to have ;-).
Heh. Yes, in case there was any confusion: I don't want my statement in
any way to be construed as a suggestion to support automake.
I would not be opposed to it if it somehow enhanced some users'
experience without bothering people who didn't want to touch it (like
the way that autoconf support is implemented). But I don't see how that
would be possible.
-Peff
^ permalink raw reply
* Re: [PATCHv2 3/4] run-command: help callers distinguish errors
From: Jeff King @ 2009-01-28 7:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <20090128073639.GC31884@coredump.intra.peff.net>
On Wed, Jan 28, 2009 at 02:36:39AM -0500, Jeff King wrote:
> +#define IS_RUN_COMMAND_ERR(x) (x >= ERR_RUN_COMMAND_FORK)
<sigh> This should be "<= -ERR_RUN_COMMAND_FORK", since we expect the
negated status.
Maybe it is time I wrote a test for a failed external.
-Peff
^ permalink raw reply
* Re: [PATCHv2 3/4] run-command: help callers distinguish errors
From: Jeff King @ 2009-01-28 7:47 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <20090128074334.GB31951@coredump.intra.peff.net>
On Wed, Jan 28, 2009 at 02:43:34AM -0500, Jeff King wrote:
> On Wed, Jan 28, 2009 at 02:36:39AM -0500, Jeff King wrote:
>
> > +#define IS_RUN_COMMAND_ERR(x) (x >= ERR_RUN_COMMAND_FORK)
>
> <sigh> This should be "<= -ERR_RUN_COMMAND_FORK", since we expect the
> negated status.
>
> Maybe it is time I wrote a test for a failed external.
Hmm. Actually, it is hard to write a test case for this; it only
triggers if we actually have an error running a program, like fork()
failing.
-Peff
^ permalink raw reply
* [PATCH 1/2] send-pack: do not send unknown object name from ".have" to pack-objects
From: Junio C Hamano @ 2009-01-28 7:51 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Linus Torvalds, PJ Hyett, Johannes Schindelin, git
In-Reply-To: <7vvdrzvpwd.fsf@gitster.siamese.dyndns.org>
v1.6.1 introduced ".have" extension to the protocol to allow the receiving
side to advertise objects that are reachable from refs in the repositories
it borrows from. This was meant to be used by the sending side to avoid
sending such objects; they are already available through the alternates
mechanism.
The client side implementation in v1.6.1, which was introduced with
40c155f (push: prepare sender to receive extended ref information from the
receiver, 2008-09-09) aka v1.6.1-rc1~203^2~1, were faulty in that it did
not consider the possiblity that the repository receiver borrows from
might have objects it does not know about.
This fixes it by refraining from passing missing commits to underlying
pack-objects. Revision machinery may need to be tightened further to
treat missing uninteresting objects as non-error events, but this is an
obvious and safe fix for a maintenance release that is almost good enough.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This lost the "NEEDSWORK" comment, as it turns out that revision
traversal machinery mostly ignores missing uninteresting objects as
non-error events except for a few corner cases, which we can tighten
separately.
builtin-send-pack.c | 43 +++++++++---------
t/t5519-push-alternates.sh | 106 ++++++++++++++++++++++++++++++++++++++++++++
2 files changed, 127 insertions(+), 22 deletions(-)
create mode 100755 t/t5519-push-alternates.sh
diff --git a/builtin-send-pack.c b/builtin-send-pack.c
index a9fdbf9..d65d019 100644
--- a/builtin-send-pack.c
+++ b/builtin-send-pack.c
@@ -15,6 +15,20 @@ static struct send_pack_args args = {
/* .receivepack = */ "git-receive-pack",
};
+static int feed_object(const unsigned char *sha1, int fd, int negative)
+{
+ char buf[42];
+
+ if (negative && !has_sha1_file(sha1))
+ return 1;
+
+ memcpy(buf + negative, sha1_to_hex(sha1), 40);
+ if (negative)
+ buf[0] = '^';
+ buf[40 + negative] = '\n';
+ return write_or_whine(fd, buf, 41 + negative, "send-pack: send refs");
+}
+
/*
* Make a pack stream and spit it out into file descriptor fd
*/
@@ -35,7 +49,6 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
};
struct child_process po;
int i;
- char buf[42];
if (args.use_thin_pack)
argv[4] = "--thin";
@@ -51,31 +64,17 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
* We feed the pack-objects we just spawned with revision
* parameters by writing to the pipe.
*/
- for (i = 0; i < extra->nr; i++) {
- memcpy(buf + 1, sha1_to_hex(&extra->array[i][0]), 40);
- buf[0] = '^';
- buf[41] = '\n';
- if (!write_or_whine(po.in, buf, 42, "send-pack: send refs"))
+ for (i = 0; i < extra->nr; i++)
+ if (!feed_object(extra->array[i], po.in, 1))
break;
- }
while (refs) {
if (!is_null_sha1(refs->old_sha1) &&
- has_sha1_file(refs->old_sha1)) {
- memcpy(buf + 1, sha1_to_hex(refs->old_sha1), 40);
- buf[0] = '^';
- buf[41] = '\n';
- if (!write_or_whine(po.in, buf, 42,
- "send-pack: send refs"))
- break;
- }
- if (!is_null_sha1(refs->new_sha1)) {
- memcpy(buf, sha1_to_hex(refs->new_sha1), 40);
- buf[40] = '\n';
- if (!write_or_whine(po.in, buf, 41,
- "send-pack: send refs"))
- break;
- }
+ !feed_object(refs->old_sha1, po.in, 1))
+ break;
+ if (!is_null_sha1(refs->new_sha1) &&
+ !feed_object(refs->new_sha1, po.in, 0))
+ break;
refs = refs->next;
}
diff --git a/t/t5519-push-alternates.sh b/t/t5519-push-alternates.sh
new file mode 100755
index 0000000..6dfc55a
--- /dev/null
+++ b/t/t5519-push-alternates.sh
@@ -0,0 +1,106 @@
+#!/bin/sh
+
+test_description='push to a repository that borrows from elsewhere'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+ mkdir alice-pub &&
+ (
+ cd alice-pub &&
+ GIT_DIR=. git init
+ ) &&
+ mkdir alice-work &&
+ (
+ cd alice-work &&
+ git init &&
+ >file &&
+ git add . &&
+ git commit -m initial &&
+ git push ../alice-pub master
+ ) &&
+
+ # Project Bob is a fork of project Alice
+ mkdir bob-pub &&
+ (
+ cd bob-pub &&
+ GIT_DIR=. git init &&
+ mkdir -p objects/info &&
+ echo ../../alice-pub/objects >objects/info/alternates
+ ) &&
+ git clone alice-pub bob-work &&
+ (
+ cd bob-work &&
+ git push ../bob-pub master
+ )
+'
+
+test_expect_success 'alice works and pushes' '
+ (
+ cd alice-work &&
+ echo more >file &&
+ git commit -a -m second &&
+ git push ../alice-pub
+ )
+'
+
+test_expect_success 'bob fetches from alice, works and pushes' '
+ (
+ # Bob acquires what Alice did in his work tree first.
+ # Even though these objects are not directly in
+ # the public repository of Bob, this push does not
+ # need to send the commit Bob received from Alice
+ # to his public repository, as all the object Alice
+ # has at her public repository are available to it
+ # via its alternates.
+ cd bob-work &&
+ git pull ../alice-pub master &&
+ echo more bob >file &&
+ git commit -a -m third &&
+ git push ../bob-pub
+ ) &&
+
+ # Check that the second commit by Alice is not sent
+ # to ../bob-pub
+ (
+ cd bob-pub &&
+ second=$(git rev-parse HEAD^) &&
+ rm -f objects/info/alternates &&
+ test_must_fail git cat-file -t $second &&
+ echo ../../alice-pub/objects >objects/info/alternates
+ )
+'
+
+test_expect_success 'clean-up in case the previous failed' '
+ (
+ cd bob-pub &&
+ echo ../../alice-pub/objects >objects/info/alternates
+ )
+'
+
+test_expect_success 'alice works and pushes again' '
+ (
+ # Alice does not care what Bob does. She does not
+ # even have to be aware of his existence. She just
+ # keeps working and pushing
+ cd alice-work &&
+ echo more alice >file &&
+ git commit -a -m fourth &&
+ git push ../alice-pub
+ )
+'
+
+test_expect_success 'bob works and pushes' '
+ (
+ # This time Bob does not pull from Alice, and
+ # the master branch at her public repository points
+ # at a commit Bob does not know about. This should
+ # not prevent the push by Bob from succeeding.
+ cd bob-work &&
+ echo yet more bob >file &&
+ git commit -a -m fifth &&
+ git push ../bob-pub
+ )
+'
+
+test_done
--
1.6.1.1.273.g0e555
^ permalink raw reply related
* Re: [RFC/PATCH 0/3] fix "Funny: git -p submodule summary"
From: Junio C Hamano @ 2009-01-28 7:54 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Johannes Sixt, git
In-Reply-To: <20090128073059.GD19165@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Jan 27, 2009 at 05:31:02PM +0100, Johannes Schindelin wrote:
>
>> I like the patch series, well designed and concise (especially with the
>> fixes Hannes proposed).
The series looks quite sane and clean. Will queue once I finish wrapping
up the push with ".have" thing.
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Jeff King @ 2009-01-28 7:55 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, Linus Torvalds, PJ Hyett, Johannes Schindelin,
git
In-Reply-To: <7vd4e7x5ov.fsf@gitster.siamese.dyndns.org>
On Tue, Jan 27, 2009 at 11:14:56PM -0800, Junio C Hamano wrote:
> I've been toying with an idea for an alternative solution, and need
> somebody competent to bounce it around with.
Well, unfortunately for you, you are stuck with me. ;P
> Here is my work in progress. It introduces "ignore-missing-negative"
> option to the revision traversal machinery, and squelches the places we
> currently complain loudly and die when we expect an object to be
> available, when the color we are going to paint the object with is
> UNINTERESTING.
>
> I have a mild suspicion that it may even be the right thing to ignore them
> unconditionally, and it might even match the intention of Linus's original
> code. That would make many hunks in this patch much simpler.
I'm not sure it is a good idea to do so unconditionally. In the case of
negatives for transferring files, a missed negative is simply a missed
opportunity for optimizing the resulting pack.
But in other cases, it silently gives you the wrong answer. For
example, consider a history like:
C--D
/
A--B
\
E--F
now let's suppose I have everything except 'E'. If I ask for
git rev-list F..D
then it will not realize that A and B are uninteresting, and I will get
A-B-C-D. I think it is much better for git to complain loudly that it
could not compute the correct answer.
Am I understanding the issue correctly?
-Peff
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort at prompt
From: David Aguilar @ 2009-01-28 8:04 UTC (permalink / raw)
To: Caleb Cushing; +Cc: Junio C Hamano, Charles Bailey, git, Nanako Shiraishi
In-Reply-To: <81bfc67a0901272256t726bf206k351bb6c8b2778bd5@mail.gmail.com>
Hi Caleb
On Tue, Jan 27, 2009 at 10:56 PM, Caleb Cushing <xenoterracide@gmail.com> wrote:
> previously git mergetool when run with prompt only allowed the user to continue
> merging. This changes git mergetool to allow the option of skipping a file or
> aborting, and includes an addtional key to explicitly select merge.
>
> Signed-off-by: Caleb Cushing <xenoterracide@gmail.com>
> ---
> git-mergetool.sh | 20 ++++++++++++++++++--
> 1 files changed, 18 insertions(+), 2 deletions(-)
>
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index 00e1337..575fbb2 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -177,8 +177,24 @@ merge_file () {
> describe_file "$local_mode" "local" "$LOCAL"
> describe_file "$remote_mode" "remote" "$REMOTE"
> if "$prompt" = true; then
> - printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
> - read ans
> + while true; do
> + printf "Use (m)erge file or (s)kip file, or (a)bort? (%s): " \
I really like the feature you added here. I'm sorry to bikeshed on
this conversation, but after trying it I have one tiny suggestion.
Right now the prompt looks like this with your patch:
"""
Merging the files: foo bar baz
Normal merge conflict for 'foo':
{local}: created
{remote}: created
Use (m)erge file or (s)kip file, or (a)bort? (xxdiff): m
"""
do you think
"Use merge file or skip file, or abort?"
might be better expressed as:
"""
Merging: foo bar baz
Normal merge conflict for 'foo':
{local}: created
{remote}: created
(m)erge, (s)kip, or (q)uit? (xxdiff): m
"""?
I realize that your patch only touches the last line of the prompt
(and not the introductory "Merging the files:" line) so if you agree
then maybe I can throw a patch together for the introductory line.
Also, my example has quit instead of abort for two reasons (the first
one is silly)
1. skip rhymes with quit, so it reads very nicely out loud
2. consistency with git add --interactive
3. less typos (q and s are diagonal on qwerty, s and a are adjacent)
(okay, that last one is silly too)
Some might also mis-associate 'abort' with meaning "abort the merge."
slightly off-topic:
If we're looking at cleaning up mergetool a bit would you all mind a
separate patch to convert it to using hard tabs throughout, just like
git-rebase.sh?
> + "$merge_tool"
> + read ans
> + case "$ans" in
> + [mM]*|"")
> + break
> + ;;
> + [sS]*)
> + cleanup_temp_files
> + return 0
> + ;;
> + [aA]*)
> + cleanup_temp_files
> + exit 0
> + ;;
> + esac
> + done
> fi
>
> case "$merge_tool" in
> --
> 1.6.1.1
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
David
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 8:05 UTC (permalink / raw)
To: Jeff King
Cc: Shawn O. Pearce, Linus Torvalds, PJ Hyett, Johannes Schindelin,
git
In-Reply-To: <20090128075515.GA1133@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> But in other cases, it silently gives you the wrong answer. For
> example, consider a history like:
>
> C--D
> /
> A--B
> \
> E--F
>
> now let's suppose I have everything except 'E'. If I ask for
>
> git rev-list F..D
>
> then it will not realize that A and B are uninteresting, and I will get
> A-B-C-D. I think it is much better for git to complain loudly that it
> could not compute the correct answer.
Fair enough. I think we can resurrect the conditional and the traversal
option revs->ignore_missing_negative only for this hunk in my [2/2] patch
to support that use case.
@@ -480,7 +483,7 @@ static int add_parents_to_list(struct rev_info *revs, struct commit *commit,
struct commit *p = parent->item;
parent = parent->next;
if (parse_commit(p) < 0)
- return -1;
+ continue;
p->object.flags |= UNINTERESTING;
if (p->parents)
mark_parents_uninteresting(p);
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Jeff King @ 2009-01-28 8:17 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, Linus Torvalds, PJ Hyett, Johannes Schindelin,
git
In-Reply-To: <7vfxj3vos2.fsf@gitster.siamese.dyndns.org>
On Wed, Jan 28, 2009 at 12:05:33AM -0800, Junio C Hamano wrote:
> Jeff King <peff@peff.net> writes:
>
> > But in other cases, it silently gives you the wrong answer. For
> > example, consider a history like:
> >
> > C--D
> > /
> > A--B
> > \
> > E--F
> >
> > now let's suppose I have everything except 'E'. If I ask for
> >
> > git rev-list F..D
> >
> > then it will not realize that A and B are uninteresting, and I will get
> > A-B-C-D. I think it is much better for git to complain loudly that it
> > could not compute the correct answer.
>
> Fair enough. I think we can resurrect the conditional and the traversal
> option revs->ignore_missing_negative only for this hunk in my [2/2] patch
> to support that use case.
> [ hunk handling parent lookup]
Don't the other changes have similar parallel use cases? [2/2] also deals
with tag lookup. Wouldn't you also expect, if you had a tag "T" pointing
to "E" in the above scenario that "git rev-list T..D" would barf? I
really think you don't want to ignore missing negations _ever_ unless
the caller knows that such a miss is really only about optimization and
not correctness.
Side note:
As you described, we expect to reach this situation from a partial
transfer. Which means that you don't actually have a _ref_ for "T" (or
"F"). So it is unlikely to come up in normal use (you would have to
manually specify the sha1 of a broken portion of the graph).
But what is more important is that your repository _is_ corrupted, I
think we are losing an important method by which the user finds out. Git
is usually very good at informing you of a problem in the repo early,
and I think unconditionally ignoring missing objects would lose that.
-Peff
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Junio C Hamano @ 2009-01-28 8:22 UTC (permalink / raw)
To: Jeff King
Cc: Shawn O. Pearce, Linus Torvalds, PJ Hyett, Johannes Schindelin,
git
In-Reply-To: <7vfxj3vos2.fsf@gitster.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> But in other cases, it silently gives you the wrong answer. For
>> example, consider a history like:
>>
>> C--D
>> /
>> A--B
>> \
>> E--F
>>
>> now let's suppose I have everything except 'E'. If I ask for
>>
>> git rev-list F..D
>>
>> then it will not realize that A and B are uninteresting, and I will get
>> A-B-C-D. I think it is much better for git to complain loudly that it
>> could not compute the correct answer.
>
> Fair enough. I think we can resurrect the conditional and the traversal
> option revs->ignore_missing_negative only for this hunk in my [2/2] patch
> to support that use case.
> ...
Nah, I take that back.
Even the original code does not consider this case an error.
If you really want that, the revision machinery needs major surgery, as I
already noted that the design of mark_parents_uninteresting() wants to
treat a missing uninteresting commit as a non-error event.
^ permalink raw reply
* Re: feature needed imap-send pass as cli switch
From: David Aguilar @ 2009-01-28 8:22 UTC (permalink / raw)
To: Caleb Cushing; +Cc: git
In-Reply-To: <81bfc67a0901272318i707b66a0ja20f97df6fe95c73@mail.gmail.com>
On Tue, Jan 27, 2009 at 11:18 PM, Caleb Cushing <xenoterracide@gmail.com> wrote:
> I tend to have my .gitconfig shared on github with a bunch of other
> config files and this has been ok, until submitting a patch here I
> needed to use imap-send, and the only way I see in the documentation
Are you sending patches through gmail? If so, check out:
http://git.or.cz/gitwiki/GitTips#head-a015948617d9becbdc9836776f96ad244ba87cb8
You can add .msmtprc to your .gitignore and keep it chmod 600.
Sure, it's cheating -- instead of keeping the data in .gitconfig we're
now keeping it in .mstmprc, but maybe it's a suitable workaround?
> is to put my email password in .gitconfig, obviously I can't push this
> up to my remote as I usually do. I'd like to see an option to pass the
> password on the cli, either as an input prompt or as just an argument
> to an option, or both. I think storing it in the config file is a
> security risk, storing passwords in plaintext is just bad practice.
>
> if it's already possible could someone share how with me? and perhaps
> patch the documentation to include how.
> --
> Caleb Cushing
>
> http://xenoterracide.blogspot.com
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
David
^ permalink raw reply
* Re: [PATCH] Windows: Fix intermittent failures of t7701
From: Junio C Hamano @ 2009-01-28 8:26 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <498008BA.2000201@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Johannes Schindelin schrieb:
>> I use this trick in my valgrind series:
>>
>> ($PROGRAM; echo $? > exit.code) | $OTHER_PROGRAM &&
>> test 0 = "$(cat exit.code)"
>
> Ah, using a file as temporary storage? Why not simply
>
> $PROGRAM > data &&
> $OTHER_PROGRAM < data
>
> Hm? ;)
Because too much cleverness often blinds clever minds.
Care to reroll with the simpler, dumber but clearer version?
^ permalink raw reply
* git clone ssh:// auth failiure
From: Arya, Manish Kumar @ 2009-01-28 8:28 UTC (permalink / raw)
To: git
Hi,
root@dcb0:~# git clone ssh://localhost/~/testproject manish
Initialized empty Git repository in /home/marya/manish/.git/
Password:
Password:
Password:
Permission denied (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).
fatal: The remote end hung up unexpectedly
though I am providing correct ssh password but its not working.
ne help guys ?
-Manish
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort at prompt
From: Charles Bailey @ 2009-01-28 8:47 UTC (permalink / raw)
To: Caleb Cushing; +Cc: Junio C Hamano, git, Nanako Shiraishi
In-Reply-To: <81bfc67a0901272256t726bf206k351bb6c8b2778bd5@mail.gmail.com>
On Wed, Jan 28, 2009 at 01:56:47AM -0500, Caleb Cushing wrote:
> diff --git a/git-mergetool.sh b/git-mergetool.sh
> index 00e1337..575fbb2 100755
> --- a/git-mergetool.sh
> +++ b/git-mergetool.sh
> @@ -177,8 +177,24 @@ merge_file () {
> describe_file "$local_mode" "local" "$LOCAL"
> describe_file "$remote_mode" "remote" "$REMOTE"
> if "$prompt" = true; then
> - printf "Hit return to start merge resolution tool (%s): " "$merge_tool"
> - read ans
> + while true; do
> + printf "Use (m)erge file or (s)kip file, or (a)bort? (%s): " \
> + "$merge_tool"
> + read ans
> + case "$ans" in
> + [mM]*|"")
> + break
> + ;;
> + [sS]*)
> + cleanup_temp_files
> + return 0
> + ;;
> + [aA]*)
> + cleanup_temp_files
> + exit 0
> + ;;
> + esac
> + done
This patch does now apply for me, so I've given it a longer look. It
does roughly what I expect, but I can't help feeling that the change
isn't in the best place.
Currently, whatever the prompt, the merge tool will always be run so
it makes sense (or at least there is no negative) in creating the
temporary files before running the merge tool.
With this change, it would seem to be more logical to ask whether the
merge tool is to be run before creating the temporary files, removing
the need for them to be cleaned up if the answer is no. I think that
this would be cleaner overall.
At the same time, however, it might be worth refactoring the
merge_file function as the same criticism could probably levelled at
the code paths that perform symlink and deleted file merges and these
paths would probably now share much more of the logic and behaviour of
a normal file merge.
Trying out this refactoring and adding the option to choose local or
remote file versions without running the merge tool has been on my
todo list for a while, but I might actually have a go at it this
weekend if nobody beats me to it.
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* Re: git clone ssh:// auth failiure
From: Steven Noonan @ 2009-01-28 8:50 UTC (permalink / raw)
To: Arya, Manish Kumar; +Cc: git
In-Reply-To: <197294.49807.qm@web35708.mail.mud.yahoo.com>
On Wed, Jan 28, 2009 at 12:28 AM, Arya, Manish Kumar <m.arya@yahoo.com> wrote:
> Hi,
>
> root@dcb0:~# git clone ssh://localhost/~/testproject manish
> Initialized empty Git repository in /home/marya/manish/.git/
> Password:
> Password:
> Password:
> Permission denied (gssapi-keyex,gssapi-with-mic,publickey,keyboard-interactive).
> fatal: The remote end hung up unexpectedly
>
> though I am providing correct ssh password but its not working.
>
> ne help guys ?
>
> -Manish
>
This appears to be more likely a problem with your OpenSSH config than with git.
- Steven
^ permalink raw reply
* Current git-svn and svn props state
From: Edward Z. Yang @ 2009-01-28 9:19 UTC (permalink / raw)
To: git
Hello all,
I was wondering what the current support by git-svn for Subversion
properties was.
Cheers,
Edward
^ permalink raw reply
* Re: Bad objects error since upgrading GitHub servers to 1.6.1
From: Jeff King @ 2009-01-28 9:24 UTC (permalink / raw)
To: Junio C Hamano
Cc: Shawn O. Pearce, Linus Torvalds, PJ Hyett, Johannes Schindelin,
git
In-Reply-To: <7vbptrvo0m.fsf@gitster.siamese.dyndns.org>
On Wed, Jan 28, 2009 at 12:22:01AM -0800, Junio C Hamano wrote:
> Nah, I take that back.
>
> Even the original code does not consider this case an error.
>
> If you really want that, the revision machinery needs major surgery, as I
> already noted that the design of mark_parents_uninteresting() wants to
> treat a missing uninteresting commit as a non-error event.
Hrm. Never mind my concern, then. I was worried that we were losing some
existing corruption checks, but it seems they are not there in the first
place.
-Peff
^ permalink raw reply
* git {pull,push} fails without stdin
From: Gustav Hållberg @ 2009-01-28 9:27 UTC (permalink / raw)
To: git
This was seen in git 1.6.0.2...
I want to run "git push" in an automated system and, as there's no
sensible stdin to use, I close fd 0 before exec'ing.
However, it does not work:
sh$ git push <&-
fatal: read error (Bad file descriptor)
compared to:
sh$ git push
Everything up-to-date
The same thing happens with "git pull", but not the other git commands
I tried (in a far-from-exhaustive search).
It's trivial to work around (e.g., use /dev/null as stdin), but it
would be more convenient if it just worked :-)
- Gustav
^ permalink raw reply
* Re: git 1.6.1 on AIX 5.3
From: Mike Ralphson @ 2009-01-28 9:48 UTC (permalink / raw)
To: Perry Smith; +Cc: git, Jeff King
In-Reply-To: <BAD975AD-323D-4278-8405-0B57E7202797@gmail.com>
2009/1/28 Perry Smith <pedzsan@gmail.com>:
> Sorry... I thought "out of tree" was a universal term.
No, my mistake, I didn't think about what you meant.
> About 90% of the open source configure / autoconf code out there can do this
> with. The other 10% you can not. I like it because when things die, its easier to
> grep around the source tree and I blow away the build directory and start back over and
> I know that I'm starting fresh.
Even if you're only building git, unless disc space is tight, I'd
probably recommend cloning the git.git repository, then you can either
use make clean or git clean, plus it makes updating to
latest/arbitrary versions easier. Anyway, I don't think your setup is
wrong.
> Yea, part of my larger quest is to start a web site to provide AIX builds
> of open source images as installp images. I have not added iconv to the
> mix yet because I fear bad interactions with GNU's and AIX's. In theory,
> AIX's commands should use AIX's library but it would not surprise me if there are
> a few AIX applications that are not built properly.
A pity package distribution for AIX is so fragmented, but when IBM had
the ball, they dropped it. Mail me if you want links to other existing
sites who might appreciate contributed builds.
> I assume the GIT_SKIP_TESTS is done:
It's documented in test/README
> I just tried setting SHELL_PATH (and exporting it) and the make test gets
> into the second batch and then fails two tests. ... now test 10 of t0001.sh
> fails because test_cmp can not be found.
>
> Is that a GNU tool? (I didn't see it in git or coreutils.)
As Peff said, there's a wrapper around either diff -u or a user
supplied comparison tool (e.g. cmp) set in GIT_TEST_CMP. Setting it to
cmp works fine on AIX if you don't have a diff which takes -u on your
PATH.
As (at the moment) you need bash, gcc, gmake and ginstall to build,
test and (maybe) run all parts of git on AIX, I haven't set up a clean
environment to try and flush out any other quirks to get git to
build/test/run on a stock AIX with no GNU tools installed. For obvious
reasons such AIX machines being used for dev purposes are (I believe)
rare.
Mike
^ permalink raw reply
* Re: [PATCH] mergetool merge/skip/abort at prompt
From: Caleb Cushing @ 2009-01-28 9:50 UTC (permalink / raw)
To: David Aguilar; +Cc: Junio C Hamano, Charles Bailey, git, Nanako Shiraishi
In-Reply-To: <402731c90901280004l29382eaanedfdfcca75529468@mail.gmail.com>
> Also, my example has quit instead of abort for two reasons (the first
> one is silly)
> 1. skip rhymes with quit, so it reads very nicely out loud
> 2. consistency with git add --interactive
> 3. less typos (q and s are diagonal on qwerty, s and a are adjacent)
> (okay, that last one is silly too)
I chose abort because it's used in other places in mergetool (for same
purpose). I'm not opposed to cleaning up or making it more consistent
with other utilities though. but perhaps that's for another patch...
> slightly off-topic:
> If we're looking at cleaning up mergetool a bit would you all mind a
> separate patch to convert it to using hard tabs throughout, just like
> git-rebase.sh?
in an earlier thread... I complained loudly about the mixing of tabs
and spaces, it should be banned imho, causes nothing but problems.
--
Caleb Cushing
http://xenoterracide.blogspot.com
^ permalink raw reply
* [PATCH v2] Windows: Fix intermittent failures of t7701
From: Johannes Sixt @ 2009-01-28 9:52 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, Git Mailing List
In-Reply-To: <7v3af3vnti.fsf@gitster.siamese.dyndns.org>
From: Johannes Sixt <j6t@kdbg.org>
The last test case checks whether unpacked objects receive the time stamp
of the pack file. Due to different implementations of stat(2) by MSYS and
our version in compat/mingw.c, the test fails in about half of the test
runs.
Note the following facts:
- The test uses perl's -M operator to compare the time stamps. Since we
depend on MSYS perl, the result of this operator is based on MSYS's
implementation of the stat(2) call.
- NTFS on Windows records fractional seconds.
- The MSYS implementation of stat(2) *rounds* fractional seconds to full
seconds instead of truncating them. This becomes obvious by comparing the
modification times reported by 'ls --full-time $f' and 'stat $f' for
various files $f.
- Our implementation of stat(2) in compat/mingw.c *truncates* to full
seconds.
The consequence of this is that
- add_packed_git() picks up a truncated whole second modification time
from the pack file time stamp, which is then used for the loose objects,
while the pack file retains its time stamp in fractional seconds;
- but the test case compared the pack file's rounded modification times
to the loose objects' truncated modification times.
And half of the time the rounded modification time is not the same as its
truncated modification time.
The fix is that we replace perl by 'test-chmtime -v +0', which prints the
truncated whole-second mtime without modifying it.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
Junio C Hamano schrieb:
> Care to reroll with the simpler, dumber but clearer version?
OK. This time I use an intermediate file and dquotes around $t.
-- Hannes
t/t7701-repack-unpack-unreachable.sh | 14 +++++++-------
1 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/t/t7701-repack-unpack-unreachable.sh b/t/t7701-repack-unpack-unreachable.sh
index 63a8225..5babdf2 100755
--- a/t/t7701-repack-unpack-unreachable.sh
+++ b/t/t7701-repack-unpack-unreachable.sh
@@ -50,12 +50,10 @@ test_expect_success '-A with -d option leaves unreachable objects unpacked' '
compare_mtimes ()
{
- perl -e 'my $reference = shift;
- foreach my $file (@ARGV) {
- exit(1) unless(-f $file && -M $file == -M $reference);
- }
- exit(0);
- ' -- "$@"
+ read tref rest &&
+ while read t rest; do
+ test "$tref" = "$t" || break
+ done
}
test_expect_success '-A without -d option leaves unreachable objects packed' '
@@ -87,7 +85,9 @@ test_expect_success 'unpacked objects receive timestamp of pack file' '
tmppack=".git/objects/pack/tmp_pack" &&
ln "$packfile" "$tmppack" &&
git repack -A -l -d &&
- compare_mtimes "$tmppack" "$fsha1path" "$csha1path" "$tsha1path"
+ test-chmtime -v +0 "$tmppack" "$fsha1path" "$csha1path" "$tsha1path" \
+ > mtimes &&
+ compare_mtimes < mtimes
'
test_done
--
1.6.1.1.1203.g5882
^ 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