* [PATCH v5 2/6] fast-import: put marks reading in it's own function
From: Sverre Rabbelier @ 2009-08-27 18:12 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List,
Ian Clatworthy <ian.cla
Cc: Sverre Rabbelier
In-Reply-To: <1251396736-928-1-git-send-email-srabbelier@gmail.com>
All options do nothing but set settings, with the exception of the
--input-marks option. Delay the reading of the marks file till after
all options have been parsed.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Unchanged from v4.
fast-import.c | 73 ++++++++++++++++++++++++++++++++-------------------------
1 files changed, 41 insertions(+), 32 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index b904f20..812fcf0 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -315,6 +315,7 @@ static struct object_entry_pool *blocks;
static struct object_entry *object_table[1 << 16];
static struct mark_set *marks;
static const char *mark_file;
+static const char *input_file;
/* Our last blob */
static struct last_object last_blob = { STRBUF_INIT, 0, 0, 0 };
@@ -1643,6 +1644,42 @@ static void dump_marks(void)
}
}
+static void read_marks(void)
+{
+ char line[512];
+ FILE *f = fopen(input_file, "r");
+ if (!f)
+ die_errno("cannot read '%s'", input_file);
+ while (fgets(line, sizeof(line), f)) {
+ uintmax_t mark;
+ char *end;
+ unsigned char sha1[20];
+ struct object_entry *e;
+
+ end = strchr(line, '\n');
+ if (line[0] != ':' || !end)
+ die("corrupt mark line: %s", line);
+ *end = 0;
+ mark = strtoumax(line + 1, &end, 10);
+ if (!mark || end == line + 1
+ || *end != ' ' || get_sha1(end + 1, sha1))
+ die("corrupt mark line: %s", line);
+ e = find_object(sha1);
+ if (!e) {
+ enum object_type type = sha1_object_info(sha1, NULL);
+ if (type < 0)
+ die("object not found: %s", sha1_to_hex(sha1));
+ e = insert_object(sha1);
+ e->type = type;
+ e->pack_id = MAX_PACK_ID;
+ e->offset = 1; /* just not zero! */
+ }
+ insert_mark(mark, e);
+ }
+ fclose(f);
+}
+
+
static int read_next_command(void)
{
static int stdin_eof = 0;
@@ -2338,39 +2375,9 @@ static void parse_progress(void)
skip_optional_lf();
}
-static void option_import_marks(const char *input_file)
+static void option_import_marks(const char *marks)
{
- char line[512];
- FILE *f = fopen(input_file, "r");
- if (!f)
- die_errno("cannot read '%s'", input_file);
- while (fgets(line, sizeof(line), f)) {
- uintmax_t mark;
- char *end;
- unsigned char sha1[20];
- struct object_entry *e;
-
- end = strchr(line, '\n');
- if (line[0] != ':' || !end)
- die("corrupt mark line: %s", line);
- *end = 0;
- mark = strtoumax(line + 1, &end, 10);
- if (!mark || end == line + 1
- || *end != ' ' || get_sha1(end + 1, sha1))
- die("corrupt mark line: %s", line);
- e = find_object(sha1);
- if (!e) {
- enum object_type type = sha1_object_info(sha1, NULL);
- if (type < 0)
- die("object not found: %s", sha1_to_hex(sha1));
- e = insert_object(sha1);
- e->type = type;
- e->pack_id = MAX_PACK_ID;
- e->offset = 1; /* just not zero! */
- }
- insert_mark(mark, e);
- }
- fclose(f);
+ input_file = xstrdup(marks);
}
static void option_date_format(const char *fmt)
@@ -2495,6 +2502,8 @@ int main(int argc, const char **argv)
}
if (i != argc)
usage(fast_import_usage);
+ if (input_file)
+ read_marks();
rc_free = pool_alloc(cmd_save * sizeof(*rc_free));
for (i = 0; i < (cmd_save - 1); i++)
--
1.6.4.122.g6ffd7
^ permalink raw reply related
* [PATCH v5 1/6] fast-import: put option parsing code in seperate functions
From: Sverre Rabbelier @ 2009-08-27 18:12 UTC (permalink / raw)
To: Junio C Hamano, Shawn O. Pearce, Johannes Schindelin, Git List,
Ian Clatworthy <ian.cla
Cc: Sverre Rabbelier
Putting the options in their own functions increases readability of
the option parsing block and makes it easier to reuse the option
parsing code later on.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Unchanged from v4.
fast-import.c | 115 +++++++++++++++++++++++++++++++++++++--------------------
1 files changed, 75 insertions(+), 40 deletions(-)
diff --git a/fast-import.c b/fast-import.c
index 7ef9865..b904f20 100644
--- a/fast-import.c
+++ b/fast-import.c
@@ -291,6 +291,7 @@ static unsigned long branch_count;
static unsigned long branch_load_count;
static int failure;
static FILE *pack_edges;
+static unsigned int show_stats = 1;
/* Memory pools */
static size_t mem_pool_alloc = 2*1024*1024 - sizeof(struct mem_pool);
@@ -2337,7 +2338,7 @@ static void parse_progress(void)
skip_optional_lf();
}
-static void import_marks(const char *input_file)
+static void option_import_marks(const char *input_file)
{
char line[512];
FILE *f = fopen(input_file, "r");
@@ -2372,6 +2373,76 @@ static void import_marks(const char *input_file)
fclose(f);
}
+static void option_date_format(const char *fmt)
+{
+ if (!strcmp(fmt, "raw"))
+ whenspec = WHENSPEC_RAW;
+ else if (!strcmp(fmt, "rfc2822"))
+ whenspec = WHENSPEC_RFC2822;
+ else if (!strcmp(fmt, "now"))
+ whenspec = WHENSPEC_NOW;
+ else
+ die("unknown --date-format argument %s", fmt);
+}
+
+static void option_max_pack_size(const char *packsize)
+{
+ max_packsize = strtoumax(packsize, NULL, 0) * 1024 * 1024;
+}
+
+static void option_depth(const char *depth)
+{
+ max_depth = strtoul(depth, NULL, 0);
+ if (max_depth > MAX_DEPTH)
+ die("--depth cannot exceed %u", MAX_DEPTH);
+}
+
+static void option_active_branches(const char *branches)
+{
+ max_active_branches = strtoul(branches, NULL, 0);
+}
+
+static void option_export_marks(const char *marks)
+{
+ mark_file = xstrdup(marks);
+}
+
+static void option_export_pack_edges(const char *edges)
+{
+ if (pack_edges)
+ fclose(pack_edges);
+ pack_edges = fopen(edges, "a");
+ if (!pack_edges)
+ die_errno("Cannot open '%s'", edges);
+}
+
+static void parse_one_option(const char *option)
+{
+ if (!prefixcmp(option, "date-format=")) {
+ option_date_format(option + 12);
+ } else if (!prefixcmp(option, "max-pack-size=")) {
+ option_max_pack_size(option + 14);
+ } else if (!prefixcmp(option, "depth=")) {
+ option_depth(option + 6);
+ } else if (!prefixcmp(option, "active-branches=")) {
+ option_active_branches(option + 16);
+ } else if (!prefixcmp(option, "import-marks=")) {
+ option_import_marks(option + 13);
+ } else if (!prefixcmp(option, "export-marks=")) {
+ option_export_marks(option + 13);
+ } else if (!prefixcmp(option, "export-pack-edges=")) {
+ option_export_pack_edges(option + 18);
+ } else if (!prefixcmp(option, "force")) {
+ force_update = 1;
+ } else if (!prefixcmp(option, "quiet")) {
+ show_stats = 0;
+ } else if (!prefixcmp(option, "stats")) {
+ show_stats = 1;
+ } else {
+ die("Unsupported option: %s", option);
+ }
+}
+
static int git_pack_config(const char *k, const char *v, void *cb)
{
if (!strcmp(k, "pack.depth")) {
@@ -2398,7 +2469,7 @@ static const char fast_import_usage[] =
int main(int argc, const char **argv)
{
- unsigned int i, show_stats = 1;
+ unsigned int i;
git_extract_argv0_path(argv[0]);
@@ -2419,44 +2490,8 @@ int main(int argc, const char **argv)
if (*a != '-' || !strcmp(a, "--"))
break;
- else if (!prefixcmp(a, "--date-format=")) {
- const char *fmt = a + 14;
- if (!strcmp(fmt, "raw"))
- whenspec = WHENSPEC_RAW;
- else if (!strcmp(fmt, "rfc2822"))
- whenspec = WHENSPEC_RFC2822;
- else if (!strcmp(fmt, "now"))
- whenspec = WHENSPEC_NOW;
- else
- die("unknown --date-format argument %s", fmt);
- }
- else if (!prefixcmp(a, "--max-pack-size="))
- max_packsize = strtoumax(a + 16, NULL, 0) * 1024 * 1024;
- else if (!prefixcmp(a, "--depth=")) {
- max_depth = strtoul(a + 8, NULL, 0);
- if (max_depth > MAX_DEPTH)
- die("--depth cannot exceed %u", MAX_DEPTH);
- }
- else if (!prefixcmp(a, "--active-branches="))
- max_active_branches = strtoul(a + 18, NULL, 0);
- else if (!prefixcmp(a, "--import-marks="))
- import_marks(a + 15);
- else if (!prefixcmp(a, "--export-marks="))
- mark_file = a + 15;
- else if (!prefixcmp(a, "--export-pack-edges=")) {
- if (pack_edges)
- fclose(pack_edges);
- pack_edges = fopen(a + 20, "a");
- if (!pack_edges)
- die_errno("Cannot open '%s'", a + 20);
- } else if (!strcmp(a, "--force"))
- force_update = 1;
- else if (!strcmp(a, "--quiet"))
- show_stats = 0;
- else if (!strcmp(a, "--stats"))
- show_stats = 1;
- else
- die("unknown option %s", a);
+
+ parse_one_option(a + 2);
}
if (i != argc)
usage(fast_import_usage);
--
1.6.4.122.g6ffd7
^ permalink raw reply related
* Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)
From: Brandon Casey @ 2009-08-27 18:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vr5uxrwld.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
>
>>> This seems to break t9001. Near the tip of 'pu' I have a iffy
>>> workaround.
>> Can you squash this into your 'iffy' workaround to help platforms
>> (Solaris 7, IRIX 6.5) without the 'yes' utility?
>
> Not in this form, for two reasons ;-)
>
> (1) t7610-mergetool.sh,also seems to use "yes". Perhaps define something
> in test-lib.sh?
>
> (2) The implementation is iffy.
Looks good, I'll rework it sometime if you don't beat me to it.
-brandon
>> +yes () {
>> + test -n "$*" && y="$*" || y='y'
>
> Shouldn't it be
>
> if test $# = 0
> then
> y=y
> else
> y="$*"
> fi
>
> so that
>
> yes ""
>
> would give runs of empty lines?
^ permalink raw reply
* Re: vc in emacs problem with git
From: Tassilo Horn @ 2009-08-27 17:45 UTC (permalink / raw)
To: help-gnu-emacs; +Cc: git
In-Reply-To: <f46c52560908270914o7027dc0bo873544dc0687cc48@mail.gmail.com>
Rustom Mody <rustompmody@gmail.com> writes:
Hi Rustom,
> Just updating my own question:
> when I do a C-x v v (vc-next-action)
> which is supposed to be the most basic operation for checking in a file I get
>
> Wrong type argument: stringp, nil
>
> So vc can be assumed to be a broken I guess?
Hm, please do `M-x toggle-debug-on-error', reproduce the error and poste
the backtrace.
Bye,
Tassilo
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)
From: Junio C Hamano @ 2009-08-27 17:32 UTC (permalink / raw)
To: Brandon Casey; +Cc: Git Mailing List
In-Reply-To: <SW-k_fUnLrE0kFNXSIYgMIc-pexuL5ykWs1ZdvHAo9_LMxe9ggJtCA@cipher.nrlssc.navy.mil>
Brandon Casey <brandon.casey.ctr@nrlssc.navy.mil> writes:
>> This seems to break t9001. Near the tip of 'pu' I have a iffy
>> workaround.
>
> Can you squash this into your 'iffy' workaround to help platforms
> (Solaris 7, IRIX 6.5) without the 'yes' utility?
Not in this form, for two reasons ;-)
(1) t7610-mergetool.sh,also seems to use "yes". Perhaps define something
in test-lib.sh?
(2) The implementation is iffy.
> +yes () {
> + test -n "$*" && y="$*" || y='y'
Shouldn't it be
if test $# = 0
then
y=y
else
y="$*"
fi
so that
yes ""
would give runs of empty lines?
^ permalink raw reply
* Re: Question regarding git fetch
From: Avery Pennarun @ 2009-08-27 17:22 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Tom Lambda, git
In-Reply-To: <20090827164657.GA17090@atjola.homenet>
2009/8/27 Björn Steinbrink <B.Steinbrink@gmx.de>:
> It would also be pretty hard to implement that. Given the default fetch
> refspec, it would "simply" be a matter of mapping the given ref to the
> refspec, so e.g. "foo" becomes "refs/heads/foo:refs/remotes/origin/foo".
> But even just using "git remote add -t master foo git://..." breaks
> that, as the fetch refspec in the config will no longer be a glob, and
> thus no such mapping is possible.
Hmm, I don't really see why that introduces a problem. If you use -t
to override explicitly which refs you want to save, then it's not a
problem if git doesn't save other refs, right?
I'd be more concerned about the inconsistency between
git fetch git://whatever master
and
git fetch origin master
There's no really good way for the first one to know it needs to
update any branches, even though 'origin' might be an alias for
git://whatever. So users will still be confused.
Thinking of that also reminds me of another surprise. If you do:
git fetch git://whatever
...it seems to do nothing at all, as far as I can see. Which makes
sense, I guess, since I wouldn't really expect it to be meaningful.
But it seems to connect up to the remote server anyway just in case.
I suppose I have no useful suggestions here, other than an
interpretation of why users find the current behaviour confusing.
Have fun,
Avery
^ permalink raw reply
* Re: [PATCH jh/cvs-helper 0/2] Fix building when python is not available
From: Johan Herland @ 2009-08-27 16:57 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, gitster
In-Reply-To: <Rxz2NOwzg1UZ0TgAtOhrA7e8wE02XwcSzNC9cc1EL_W_oN1BjtZn8ClmG5zKB_DKmTgVP0PlMYI@cipher.nrlssc.navy.mil>
On Thursday 27 August 2009, Brandon Casey wrote:
> These two are built on top of pu. I'm pretty sure jh/cvs-helper is
> the relevant branch.
>
> Brandon Casey (2):
> Makefile: write NO_PYTHON setting to GIT-BUILD-OPTIONS file
> t/test-lib.sh: don't perform python preparations when NO_PYTHON is
> set
Thanks. Both are
Acked-by: Johan Herland <johan@herland.net>
I'll fold these into the next iteration of jh/cvs-helper.
Have fun! :)
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: Question regarding git fetch
From: Björn Steinbrink @ 2009-08-27 16:46 UTC (permalink / raw)
To: Avery Pennarun; +Cc: Tom Lambda, git
In-Reply-To: <32541b130908270836m50553ccatddf4c870eec54ddb@mail.gmail.com>
On 2009.08.27 15:36:53 +0000, Avery Pennarun wrote:
> On Thu, Aug 27, 2009 at 3:30 PM, Tom Lambda<tom.lambda@gmail.com> wrote:
> > What was a little bit surprising to me is that running "git fetch central
> > master" does not update refs/remotes/central/master but simply updates
> > FETCH_HEAD.
>
> I've often wanted this myself, especially when doing things like "git
> pull origin master". However, I know the current behaviour is also
> useful sometimes, and changing it would introduce an unexpected side
> effect. Git currently promises that your refs/remotes/* branches will
> never be updated unless you explicitly request it, even if you're
> fetching, merging, and pulling other stuff. This means you can write
> scripts to do complicated things without triggering unexpected
> user-visible side effects.
>
> So basically, I agree that it would often be much more user-friendly
> to do what you're asking. But it would be less scripting-friendly. I
> don't think anyone has thought of an answer that better balances the
> two.
It would also be pretty hard to implement that. Given the default fetch
refspec, it would "simply" be a matter of mapping the given ref to the
refspec, so e.g. "foo" becomes "refs/heads/foo:refs/remotes/origin/foo".
But even just using "git remote add -t master foo git://..." breaks
that, as the fetch refspec in the config will no longer be a glob, and
thus no such mapping is possible.
Björn
^ permalink raw reply
* Re: What's cooking in git.git (Aug 2009, #05; Wed, 26)
From: Brandon Casey @ 2009-08-27 16:41 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vfxbeb0mt.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> [Stalled]
>
> * je/send-email-no-subject (2009-08-05) 1 commit
> - send-email: confirm on empty mail subjects
>
> This seems to break t9001. Near the tip of 'pu' I have a iffy
> workaround.
Can you squash this into your 'iffy' workaround to help platforms
(Solaris 7, IRIX 6.5) without the 'yes' utility?
---
t/t9001-send-email.sh | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
diff --git a/t/t9001-send-email.sh b/t/t9001-send-email.sh
index 960d7d8..641d0c3 100755
--- a/t/t9001-send-email.sh
+++ b/t/t9001-send-email.sh
@@ -505,6 +505,14 @@ test_expect_success '--suppress-cc=cc' '
test_suppression cc
'
+yes () {
+ test -n "$*" && y="$*" || y='y'
+ while echo "$y"
+ do
+ :
+ done
+}
+
test_confirm () {
yes | \
GIT_SEND_EMAIL_NOTTY=1 \
--
1.6.4
^ permalink raw reply related
* Re: Question regarding git fetch
From: Avery Pennarun @ 2009-08-27 16:28 UTC (permalink / raw)
To: Eric Raible; +Cc: git
In-Reply-To: <loom.20090827T180201-590@post.gmane.org>
On Thu, Aug 27, 2009 at 4:21 PM, Eric Raible<raible@gmail.com> wrote:
> Avery Pennarun <apenwarr <at> gmail.com> writes:
>
>> Git currently promises that your refs/remotes/* branches will
>> never be updated unless you explicitly request it, even if you're
>> fetching, merging, and pulling other stuff.
>
> So your claim is that "git fetch central" is somehow more
> explicit than "git fetch central master"?
It is, because there's nothing else you could possibly do with it. It
fetches too many things, so you don't know their names (other than the
ones it puts into refs/remotes/*).
So it's not exactly that it's more explicit - in fact it's rather
confusing and non-explicit that the three-parameter version does
something almost entirely different from the four-parameter one - but
the three-parameter version is at least completely unambiguous.
> Either way, AFAICT it seems purely historical that
> "git fetch central master" doesn't update remotes/central.
This seems true to me.
Have fun,
Avery
^ permalink raw reply
* [PATCH jh/cvs-helper 1/2] Makefile: write NO_PYTHON setting to GIT-BUILD-OPTIONS file
From: Brandon Casey @ 2009-08-27 16:24 UTC (permalink / raw)
To: git; +Cc: gitster, johan, Brandon Casey
In-Reply-To: <Rxz2NOwzg1UZ0TgAtOhrA7e8wE02XwcSzNC9cc1EL_W_oN1BjtZn8ClmG5zKB_DKmTgVP0PlMYI@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
The GIT-BUILD-OPTIONS file is sourced by the t/test-lib.sh script which
prepares the environment for the test suite. It is used to communicate
the user's settings for things like SHELL_PATH, TAR, NO_CURL, and NO_PERL.
Add NO_PYTHON so this setting will be available to the test suite.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Makefile | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/Makefile b/Makefile
index 128c308..5c1ae7b 100644
--- a/Makefile
+++ b/Makefile
@@ -1615,6 +1615,7 @@ GIT-BUILD-OPTIONS: .FORCE-GIT-BUILD-OPTIONS
@echo TAR=\''$(subst ','\'',$(subst ','\'',$(TAR)))'\' >>$@
@echo NO_CURL=\''$(subst ','\'',$(subst ','\'',$(NO_CURL)))'\' >>$@
@echo NO_PERL=\''$(subst ','\'',$(subst ','\'',$(NO_PERL)))'\' >>$@
+ @echo NO_PYTHON=\''$(subst ','\'',$(subst ','\'',$(NO_PYTHON)))'\' >>$@
### Detect Tck/Tk interpreter path changes
ifndef NO_TCLTK
--
1.6.4
^ permalink raw reply related
* [PATCH jh/cvs-helper 0/2] Fix building when python is not available
From: Brandon Casey @ 2009-08-27 16:24 UTC (permalink / raw)
To: git; +Cc: gitster, johan
These two are built on top of pu. I'm pretty sure jh/cvs-helper is
the relevant branch.
Brandon Casey (2):
Makefile: write NO_PYTHON setting to GIT-BUILD-OPTIONS file
t/test-lib.sh: don't perform python preparations when NO_PYTHON is
set
Makefile | 1 +
t/test-lib.sh | 18 +++++++++---------
2 files changed, 10 insertions(+), 9 deletions(-)
^ permalink raw reply
* [PATCH jh/cvs-helper 2/2] t/test-lib.sh: don't perform python preparations when NO_PYTHON is set
From: Brandon Casey @ 2009-08-27 16:24 UTC (permalink / raw)
To: git; +Cc: gitster, johan, Brandon Casey
In-Reply-To: <Rxz2NOwzg1UZ0TgAtOhrA7dGx1obNszSQLoUJ4IoUGJk5ekFKeKU4vpg535nyOx20P_IWNiudJo@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
When setting GITPYTHONLIB, a check is performed to test whether the path
that GITPYTHONLIB is set to is a valid directory. This test always fails
when NO_PYTHON is set since git_remote_cvs is not built. So add a test
on NO_PYTHON to the conditional that protects this section.
Additionally, move this section down so it is done _after_
GIT-BUILD-OPTIONS is sourced, so that the NO_PYTHON setting is available.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/test-lib.sh | 18 +++++++++---------
1 files changed, 9 insertions(+), 9 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index a7fbfef..d95c66b 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -638,15 +638,6 @@ test -d ../templates/blt || {
error "You haven't built things yet, have you?"
}
-if test -z "$GIT_TEST_INSTALLED"
-then
- GITPYTHONLIB="$(pwd)/../git_remote_cvs/build/lib"
- export GITPYTHONLIB
- test -d ../git_remote_cvs/build || {
- error "You haven't built git_remote_cvs yet, have you?"
- }
-fi
-
if ! test -x ../test-chmtime; then
echo >&2 'You need to build test-chmtime:'
echo >&2 'Run "make test-chmtime" in the source (toplevel) directory'
@@ -655,6 +646,15 @@ fi
. ../GIT-BUILD-OPTIONS
+if test -z "$NO_PYTHON" -a -z "$GIT_TEST_INSTALLED"
+then
+ GITPYTHONLIB="$(pwd)/../git_remote_cvs/build/lib"
+ export GITPYTHONLIB
+ test -d ../git_remote_cvs/build || {
+ error "You haven't built git_remote_cvs yet, have you?"
+ }
+fi
+
# Test repository
test="trash directory.$(basename "$0" .sh)"
test -n "$root" && test="$root/$test"
--
1.6.4
^ permalink raw reply related
* Re: Question regarding git fetch
From: Eric Raible @ 2009-08-27 16:21 UTC (permalink / raw)
To: git
In-Reply-To: <32541b130908270836m50553ccatddf4c870eec54ddb@mail.gmail.com>
Avery Pennarun <apenwarr <at> gmail.com> writes:
> Git currently promises that your refs/remotes/* branches will
> never be updated unless you explicitly request it, even if you're
> fetching, merging, and pulling other stuff.
So your claim is that "git fetch central" is somehow more
explicit than "git fetch central master"?
I understand that "git fetch central" will use
remote.central.fetch (which _is_ explicit), but
the command itself is certainly _less_ explicit about
specifying the remote branch.
Either way, AFAICT it seems purely historical that
"git fetch central master" doesn't update remotes/central.
- Eric
^ permalink raw reply
* [PATCH 1/2] abspath.c: move declaration of 'len' into inner block and use appropriate type
From: Brandon Casey @ 2009-08-27 16:16 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
In-Reply-To: <vODpKBYr5sNtCfB7C_mUMqGkpPTwc8quzfdAUjySMC_tekZRVbEOpzkstotoeMXAS6wJ4OaF2NA@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
The 'len' variable was declared at the beginning of the make_absolute_path
function and also in an inner 'if' block which masked the outer declaration.
It is only used in two 'if' blocks, so remove the outer declaration and
make a new declaration inside the other 'if' block that uses 'len'.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
abspath.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/abspath.c b/abspath.c
index 4bee0ba..b88122c 100644
--- a/abspath.c
+++ b/abspath.c
@@ -18,7 +18,7 @@ const char *make_absolute_path(const char *path)
{
static char bufs[2][PATH_MAX + 1], *buf = bufs[0], *next_buf = bufs[1];
char cwd[1024] = "";
- int buf_index = 1, len;
+ int buf_index = 1;
int depth = MAXDEPTH;
char *last_elem = NULL;
@@ -50,7 +50,7 @@ const char *make_absolute_path(const char *path)
die_errno ("Could not get current working directory");
if (last_elem) {
- int len = strlen(buf);
+ size_t len = strlen(buf);
if (len + strlen(last_elem) + 2 > PATH_MAX)
die ("Too long path name: '%s/%s'",
buf, last_elem);
@@ -61,7 +61,7 @@ const char *make_absolute_path(const char *path)
}
if (!lstat(buf, &st) && S_ISLNK(st.st_mode)) {
- len = readlink(buf, next_buf, PATH_MAX);
+ ssize_t len = readlink(buf, next_buf, PATH_MAX);
if (len < 0)
die_errno ("Invalid symlink '%s'", buf);
if (PATH_MAX <= len)
--
1.6.4
^ permalink raw reply related
* [PATCH 2/2] commit.c: rename variable named 'n' which masks previous declaration
From: Brandon Casey @ 2009-08-27 16:16 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
In-Reply-To: <vODpKBYr5sNtCfB7C_mUMmQyYO9vzbX98QMYSBId5GcwHT7q6zvrKlJpRNwoJvTTF7qKScin5PA@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
The variable named 'n' was initially declared to be of type int. The name
'n' was reused inside inner blocks as a different type. Rename the uses
within inner blocks to avoid confusion and give them a slightly more
descriptive name.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
commit.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/commit.c b/commit.c
index e2bcbe8..a6c6f70 100644
--- a/commit.c
+++ b/commit.c
@@ -564,13 +564,13 @@ static struct commit_list *merge_bases_many(struct commit *one, int n, struct co
while (interesting(list)) {
struct commit *commit;
struct commit_list *parents;
- struct commit_list *n;
+ struct commit_list *next;
int flags;
commit = list->item;
- n = list->next;
+ next = list->next;
free(list);
- list = n;
+ list = next;
flags = commit->object.flags & (PARENT1 | PARENT2 | STALE);
if (flags == (PARENT1 | PARENT2)) {
@@ -598,11 +598,11 @@ static struct commit_list *merge_bases_many(struct commit *one, int n, struct co
free_commit_list(list);
list = result; result = NULL;
while (list) {
- struct commit_list *n = list->next;
+ struct commit_list *next = list->next;
if (!(list->item->object.flags & STALE))
insert_by_date(list->item, &result);
free(list);
- list = n;
+ list = next;
}
return result;
}
--
1.6.4
^ permalink raw reply related
* [PATCH 0/2] Two janitorial patches
From: Brandon Casey @ 2009-08-27 16:16 UTC (permalink / raw)
To: gitster; +Cc: git
Brandon Casey (2):
abspath.c: move declaration of 'len' into inner block and use
appropriate type
commit.c: rename variable named 'n' which masks previous declaration
abspath.c | 6 +++---
commit.c | 10 +++++-----
2 files changed, 8 insertions(+), 8 deletions(-)
^ permalink raw reply
* Re: vc in emacs problem with git
From: Rustom Mody @ 2009-08-27 16:14 UTC (permalink / raw)
To: help-gnu-emacs, Git Mailing List
In-Reply-To: <f46c52560908270828o574c0de6s17189a7326a1376d@mail.gmail.com>
Just updating my own question:
when I do a C-x v v (vc-next-action)
which is supposed to be the most basic operation for checking in a file I get
Wrong type argument: stringp, nil
So vc can be assumed to be a broken I guess?
On Thu, Aug 27, 2009 at 8:58 PM, Rustom Mody<rustompmody@gmail.com> wrote:
> This is emacs 23 using the new 'updated-for-modern-dvcs' vc
> I see a mode line saying (note the colon)
> Git:master
>
> In the info on vc (Version control and the mode line) the emacs manual says:
>
> The character between the back-end name and the revision ID
> indicates the version control status of the file. `-' means that the
> work file is not locked (if locking is in use), or not modified (if
> locking is not in use). `:' indicates that the file is locked, or that
> it is modified.
>
> However at the shell a git status says
> # On branch master
> nothing to commit (working directory clean)
>
> If I close and reopen the file the colon becomes a -
> But I get a message:
>
> `working-revision' not found: using the old `workfile-version' instead.
>
^ permalink raw reply
* Re: [SCuMD]
From: Robin Rosenberg @ 2009-08-27 14:41 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Christian Senkowski, git
In-Reply-To: <4A965A1D.3060104@op5.se>
torsdag 27 augusti 2009 12:04:13 skrev Andreas Ericsson <ae@op5.se>:
> Christian Senkowski wrote:
> > Hi,
> >
> > I cloned SCuMD directly via git and started it but got following error:
> >
> > ~/scumd$ ./run.sh
> > Exception in thread "main" java.lang.NoClassDefFoundError:
> > com.asolutions.scmsshd.SCuMD
> > at gnu.java.lang.MainThread.run(libgcj.so.90)
> > Caused by: java.lang.ClassNotFoundException:
> > com.asolutions.scmsshd.SCuMD not found in
> > gnu.gcj.runtime.SystemClassLoader{urls=[file:depend/lib/jgit.jar,file:depend/lib/minasshd.jar,file:lib/aopalliance-1.0.jar,file:lib/bcprov-jdk15-140.jar,file:lib/commons-io-1.4.jar,file:lib/commons-logging-1.0.4.jar,file:./,file:lib/jline-0.9.1.jar,file:lib/jline-0.9.94.jar,file:lib/jpam-1.1.jar,file:lib/jsch-0.1.40.jar,file:lib/jzlib-1.0.7.jar,file:lib/log4j-1.2.13.jar,file:lib/slf4j-api-1.5.2.jar,file:lib/slf4j-log4j12-1.4.3.jar,file:lib/spring-beans-2.5.5.jar,file:lib/spring-context-2.5.5.jar,file:lib/spring-core-2.5.5.jar],
> > parent=gnu.gcj.runtime.ExtensionClassLoader{urls=[], parent=null}}
> > at java.net.URLClassLoader.findClass(libgcj.so.90)
> > at gnu.gcj.runtime.SystemClassLoader.findClass(libgcj.so.90)
> > at java.lang.ClassLoader.loadClass(libgcj.so.90)
> > at java.lang.ClassLoader.loadClass(libgcj.so.90)
> > at gnu.java.lang.MainThread.run(libgcj.so.90)
> >
> >
> > Please help me out :)
> >
Short answer: Don't run things with GCJ unless you make sure it works
with SUN's java or OPENJDK first. If it still doesn't work ask the GCJ
people for help.
> Please refer to the SCuMD mailing list for this SCuMD related question.
Their README file refers to the Git mailing list. Hence the tag, Kind'o like
JGit, which they depend upon.
-- robin
^ permalink raw reply
* Re: Question regarding git fetch
From: Avery Pennarun @ 2009-08-27 15:36 UTC (permalink / raw)
To: Tom Lambda; +Cc: git
In-Reply-To: <1251387045053-3527289.post@n2.nabble.com>
On Thu, Aug 27, 2009 at 3:30 PM, Tom Lambda<tom.lambda@gmail.com> wrote:
> What was a little bit surprising to me is that running "git fetch central
> master" does not update refs/remotes/central/master but simply updates
> FETCH_HEAD.
I've often wanted this myself, especially when doing things like "git
pull origin master". However, I know the current behaviour is also
useful sometimes, and changing it would introduce an unexpected side
effect. Git currently promises that your refs/remotes/* branches will
never be updated unless you explicitly request it, even if you're
fetching, merging, and pulling other stuff. This means you can write
scripts to do complicated things without triggering unexpected
user-visible side effects.
So basically, I agree that it would often be much more user-friendly
to do what you're asking. But it would be less scripting-friendly. I
don't think anyone has thought of an answer that better balances the
two.
Have fun,
Avery
^ permalink raw reply
* [PATCH] Makefile: remove pointless conditional assignment in SunOS section
From: Brandon Casey @ 2009-08-27 15:35 UTC (permalink / raw)
To: gitster; +Cc: git, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
It is true that NEEDS_RESOLV is needed on SunOS if NO_IPV6 is set since
hstrerror() resides in libresolv, but performing this test at its current
location is not very useful. It will only have any effect if the user
modifies the make variables from the make command line, and will have no
effect if a config.mak file is used. A better location for this
conditional would have been further down in the Makefile after the
config.mak and config.mak.autogen had been parsed. Rather than adding
clutter to the Makefile for a conditional that will likely never be
triggered, just remove it, and any user on SunOS that manually sets NO_IPV6
can also set NEEDS_RESOLV.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Makefile | 3 ---
1 files changed, 0 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 66eedef..a9a4d89 100644
--- a/Makefile
+++ b/Makefile
@@ -757,9 +757,6 @@ ifeq ($(uname_S),SunOS)
NO_C99_FORMAT = YesPlease
NO_STRTOUMAX = YesPlease
endif
- ifdef NO_IPV6
- NEEDS_RESOLV = YesPlease
- endif
INSTALL = /usr/ucb/install
TAR = gtar
BASIC_CFLAGS += -D__EXTENSIONS__ -D__sun__ -DHAVE_ALLOCA_H
--
1.6.4
^ permalink raw reply related
* Question regarding git fetch
From: Tom Lambda @ 2009-08-27 15:30 UTC (permalink / raw)
To: git
I noticed that git-fetch seems smarter when it is run without a <refspec>
argument than when one specifies a branch name. I use a simple setup where a
remote central repository is defined when it is cloned the first time (clone
-o central ...). This leads to these default parameters:
remote.central.fetch=+refs/heads/*:refs/remotes/central/*
branch.master.remote=central
branch.master.merge=refs/heads/master
When I use "git fetch central" each branch in central's refs/heads/ is
automatically fetched to my refs/remotes/central/ as expected.
What was a little bit surprising to me is that running "git fetch central
master" does not update refs/remotes/central/master but simply updates
FETCH_HEAD.
I read the manual and I know that updating FETCH_HEAD is the expected
default behavior for git-fetch. However, I really like the fact that git
fetch (without <refspec>) knows that ANY branch in refs/heads/ corresponds
to refs/remotes/central/. Is there a way to change the configuration to have
"git fetch central branch" always updating refs/remotes/central/branch
whatever the specified branch.
I would prefer not to have to specify the <dst> each time:
git fetch central branch:remotes/central/branch
Thank you,
Tom
--
View this message in context: http://n2.nabble.com/Question-regarding-git-fetch-tp3527289p3527289.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* vc in emacs problem with git
From: Rustom Mody @ 2009-08-27 15:28 UTC (permalink / raw)
To: help-gnu-emacs, Git Mailing List
This is emacs 23 using the new 'updated-for-modern-dvcs' vc
I see a mode line saying (note the colon)
Git:master
In the info on vc (Version control and the mode line) the emacs manual says:
The character between the back-end name and the revision ID
indicates the version control status of the file. `-' means that the
work file is not locked (if locking is in use), or not modified (if
locking is not in use). `:' indicates that the file is locked, or that
it is modified.
However at the shell a git status says
# On branch master
nothing to commit (working directory clean)
If I close and reopen the file the colon becomes a -
But I get a message:
`working-revision' not found: using the old `workfile-version' instead.
^ permalink raw reply
* git-svn intermittent issues with absent_file
From: Matthias Andree @ 2009-08-27 14:56 UTC (permalink / raw)
To: git; +Cc: Eric Wong
Greetings,
we seem to have issues with checking out files from an SVN server via
https://. The problem is hard to reproduce, and shows as "absent_file"
warnings, i. e. files that are in the SVN checkout don't make it to the
Git checkin.
Perhaps this rings a bell with someone or there are similar reports that
relate to our issues...
## ISSUE ## Once in a while, a git-svn clone or rebase fails with files
missing from commits, as mentioned above. We haven't been able to figure
out under what circumstances this happens. If we try to reproduce this (i.
e. kill the directory completely and re-run the git svn clone), another
revision (for instance 170) might show this, or the clone may succeed.
This was observed with Git 1.6.0.4 under Ubuntu Linux Jaunty Jackalope
(9.04) and on a different computer with Git 1.6.4.1.196.g31f0b (from the
master branch) under a fully updated Cygwin 1.5.
Example log of failed data (sorry, we are not allowed to let you access
the repository, so we must debug by proxy).
I'm replacing substrings in the log below to maintain corporate
confidentiality levels:
$ git svn clone --no-checkout https://svnserver.example.edu/project/
Initialized empty Git repository in /tmp/compnet/.git/
W: +empty_dir: branches
W: +empty_dir: tags
W: +empty_dir: trunk
r1 = a1b0e99e3986da4d8d461944b623b6abb2460de4 (refs/remotes/git-svn)
...
r135 = 294077e62ee5f463b8ab97d961d9742ef89ae662 (refs/remotes/git-svn)
A ... (~100 PDF files)
...
A d1/u1/2009_06/f1.pdf
W: +empty_dir: d1/u2/slides/2009_06
W: absent_file: d1/u1/2009_06/d1/u1/2009_06/f2.pdf Insufficient
permissions?
W: absent_file: d1/u3/06_2009/f1/u3/2009_06/f3.pdf Insufficient
permissions?
W: absent_file: d1/u2/slides/2009_06/d1/u2/slides/2009_06/f4.pdf
Insufficient permissions?
r136 = 58523cf1fa867d33a74080dabdcbc85ae0ba99ec (refs/remotes/git-svn)
...
r139 = 2fb1647bc40d3815a5eefb32d43a375e03d2e871 (refs/remotes/git-svn)
Incomplete data: Delta source ended unexpectedly at
/usr/local/libexec/git-core/git-svn line 4605
Just re-running "git svn fetch" reproduces the "Incomplete data:" error
and aborts, but re-fetching an older version succeeds. No fiddling with
permissions needed.
## WORKAROUND ##
If this happens, I can force a checkout with, say, "git checkout -t -b
master remotes/git-svn", revert to the last good revision with "git svn
reset -r135" (this doesn't work without prior checkout) and then re-run
git svn fetch, which will usually succeed then.
The three absent_file lines are also recorded in
.git/svn/refs/remotes/git-svn/unhandled.log for r136.
Questions:
1. What causes these absent_file issues? How can we assist with debugging
this?
2. What does "Delta source ended unexpectedly" mean? (the line number is
bogus, it's just the finish_report call)
3. Is this or a similar issue known? Is this an issue with the SVN server,
the SVN bindings, or the git svn adaptor?
4. How can we avoid or fix this?
We're happy to test patches.
Thanks a lot in advance.
Cheers,
--
Matthias Andree
^ permalink raw reply
* Re: [PATCH 14/14] Add README and gitignore file for MSVC build
From: Thiago Farina @ 2009-08-27 14:26 UTC (permalink / raw)
To: Frank Li
Cc: Marius Storm-Olsen, Reece Dunn, Johannes.Schindelin, msysgit, git
In-Reply-To: <1976ea660908270616v543776fdv6ec167cc105337fc@mail.gmail.com>
Hi
On Thu, Aug 27, 2009 at 10:16 AM, Frank Li<lznuaa@gmail.com> wrote:
> I fixed this problem
> It should be ext/zlib
>
Thanks!
Now when I run 'git submodule update' I recieve this error:
'fatal: Needed a single revision
Unable to find the current revision in submodule path 'ext/OpenSSL''
If the output of 'git submodule status' help, this is:
fdd0f73b9a3e7c1fdf15c2e2a52582c637ec96f1 ext/OpenSSL
+3136d3b72e199ad1484629e8ff4563a918cad953 ext/git (remotes/origin/vcpatch)
-c891963b1c9d2ffbf194b2c2283639d784fa3690 ext/libcurl
-62cb93cb25e2fbdbc89f90249cd8a024afad8a94 ext/zlib
^ 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