* Re: error: char103: premature end of data
From: Johan Herland @ 2007-06-07 23:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706072348110.4046@racer.site>
On Friday 08 June 2007, Johannes Schindelin wrote:
> Hi,
>
> I just tried to fetch from one of my repos which was perfectly usable (and
> fetchable) before, and got this error message:
>
> error: char103: premature end of data
Sorry about that. Do you have an idea of which tag object caused the
failure? If so, could you send the output of "git-cat-file tag <name>" on
it?
git-fsck on the repo should report the same error. If you run with -v
(verbose) you should also get some hints as to which tag object causes
this.
...Johan
--
Johan Herland, <johan@herland.net>
www.herland.net
^ permalink raw reply
* Re: git-send-pack: broken handling of ref specs with wildcards
From: Johannes Schindelin @ 2007-06-07 22:56 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20070607225302.GA10633@steel.home>
Hi,
On Fri, 8 Jun 2007, Alex Riesen wrote:
> Try something like this:
>
> git-send-pack --remote=origin --thin /some/other/repo \
> 'refs/heads/*:refs/remotes/child/*'
>
> The result looks broken: the sent reference are created not in
> refs/remotes/child/ but just in refs/heads/ of /some/other/repo.
I had the impression that it was git-push, a porcelain, which handles
refspec wildcards, not send-pack, which is plumbing.
Ciao,
Dscho
^ permalink raw reply
* Re: git-stash
From: Johannes Schindelin @ 2007-06-07 22:55 UTC (permalink / raw)
To: Lars Hjemli; +Cc: git
In-Reply-To: <8c5c35580706071552v3a099fdci1baec9101a40242b@mail.gmail.com>
Hi,
On Fri, 8 Jun 2007, Lars Hjemli wrote:
> On 6/8/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > git-commit-tree $tree
>
> I added -p HEAD here, and it's even nicer ;-)
Yep, you're right. I forgot that in my "final" version.
Thanks,
Dscho
^ permalink raw reply
* git-send-pack: broken handling of ref specs with wildcards
From: Alex Riesen @ 2007-06-07 22:53 UTC (permalink / raw)
To: git
Try something like this:
git-send-pack --remote=origin --thin /some/other/repo \
'refs/heads/*:refs/remotes/child/*'
The result looks broken: the sent reference are created not in
refs/remotes/child/ but just in refs/heads/ of /some/other/repo.
^ permalink raw reply
* error: char103: premature end of data
From: Johannes Schindelin @ 2007-06-07 22:50 UTC (permalink / raw)
To: git
Hi,
I just tried to fetch from one of my repos which was perfectly usable (and
fetchable) before, and got this error message:
error: char103: premature end of data
WTF? Since when did we stop using non-cryptic error messages?
Needless to say, I am very unhappy with such a message, especially in a
repo which worked perfectly, thank you.
I somehow suspect that this has something to do with the recent work on
the tag objects. If so, NACK on that patch series from me.
Ciao,
Dscho
^ permalink raw reply
* Re: git-stash
From: Lars Hjemli @ 2007-06-07 22:52 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706072328000.4046@racer.site>
On 6/8/07, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> git-commit-tree $tree
I added -p HEAD here, and it's even nicer ;-)
Thanks!
--
larsh
^ permalink raw reply
* Re: [PATCH] [RFC] Generational repacking
From: Martin Langhoff @ 2007-06-07 22:51 UTC (permalink / raw)
To: Sam Vilain; +Cc: Nicolas Pitre, Dana How, Junio C Hamano, git
In-Reply-To: <46687A73.6080100@vilain.net>
On 6/8/07, Sam Vilain <sam@vilain.net> wrote:
> Ok. But if repack is generational you probably don't mind waiting for
> it on commit so don't need to background it.
Agreed. The patch I posted back then was on fetch as a signle fetch is
more likely to bring a lot of new objects in. (Moreso than a commit)
Repack-on-commit if there's more than 1k unpacked objects makes sense.
Are fetches nowaways always using the "keep pack" and "fatten thin
pack" semantics? If yes, then
cheers,
martin
^ permalink raw reply
* Re: git does the wrong thing with ambiguous names
From: Brandon Casey @ 2007-06-07 22:51 UTC (permalink / raw)
To: Git Mailing List
Didn't hit reply-all...
Brandon Casey wrote:
> Alex Riesen wrote:
>> Alex Riesen, Thu, Jun 07, 2007 01:33:27 +0200:
>>> Alex Riesen, Thu, Jun 07, 2007 00:58:26 +0200:
>>>> Brandon Casey, Thu, Jun 07, 2007 00:13:48 +0200:
> [snip]
>> This one is much shorter and less friendly. Suggested by Junio on irc.
>> It makes checkout always prefer a branch.
>>
>> diff --git a/git-checkout.sh b/git-checkout.sh
>> index 6b6facf..282c84f 100755
>> --- a/git-checkout.sh
>> +++ b/git-checkout.sh
>> @@ -67,6 +67,8 @@ while [ "$#" != "0" ]; do
>> new_name="$arg"
>> if git-show-ref --verify --quiet -- "refs/heads/$arg"
>> then
>> + rev=$(git-rev-parse --verify "refs/heads/$arg^0"
>> 2>/dev/null)
>> + new="$rev"
>> branch="$arg"
>> fi
>> elif rev=$(git-rev-parse --verify "$arg^{tree}" 2>/dev/null)
>>
>
> This doesn't work.
sorry, scratch that. It does work.
Thunderbird turned $arg _hat_ 0 into $arg _superscript_ 0, which became
$arg0 when I copy/pasted. And I didn't catch it. Again, apologies.
I think this is the intuitive behavior, prefer branch over tag. though I
think a warning or refusal to switch would be better (but more
complicated, and I don't know how to do it).
A quick run through of some other porcelain commands shows they prefer tag:
git log
git show
git diff
-brandon
^ permalink raw reply
* [PATCH] fsck: do not crash on tag objects which do not contain an empty line
From: Johannes Schindelin @ 2007-06-07 22:40 UTC (permalink / raw)
To: git, gitster
The first empty line in a tag object separates the header from the
message. If the tag object has no empty line, do not crash, but
complain loudly instead.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
---
I have no idea how this tag crept into one of my repos, but it is
no good to crash for git-fsck.
builtin-fsck.c | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/builtin-fsck.c b/builtin-fsck.c
index 7a92e47..607136a 100644
--- a/builtin-fsck.c
+++ b/builtin-fsck.c
@@ -545,9 +545,14 @@ static void fsck_verify_ref_to_tag_object(const char *refname, struct object *ob
{
/* Verify that refname matches the name stored in obj's "tag" header */
struct tag *tagobj = (struct tag *) parse_object(obj->sha1);
- size_t tagname_len = strlen(tagobj->tag);
+ size_t tagname_len;
size_t refname_len = strlen(refname);
+ if (!tagobj->tag) {
+ error("tag %s does not contain any tag?", refname);
+ return;
+ }
+ tagname_len = strlen(tagobj->tag);
if (!tagname_len) return; /* No tag name stored in tagobj. Nothing to do. */
if (tagname_len < refname_len &&
--
1.5.2.1.2683.gab86-dirty
^ permalink raw reply related
* Re: Problems with git-svnimport
From: Johannes Schindelin @ 2007-06-07 22:29 UTC (permalink / raw)
To: plexq; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0706071639190.12111@www.mintpixels.com>
Hi,
On Thu, 7 Jun 2007, Alex R.M. Turner wrote:
> I am trying to import my svn project into git with git-svnimport, but I am
> getting a bunch of error messages using the following command:
>
> git-svnimport -C eastcoastmarine -v \
> svn://svn.mintpixels.com/eastcoastmarine-website
>
> I get messages like:
> 4: Unrecognized path: /trend-scripts/trunk/run_purge.sh
Let's deprecate git-svnimport, once for all.
git-svn should work much better.
Ciao,
Dscho
^ permalink raw reply
* git-stash
From: Johannes Schindelin @ 2007-06-07 22:28 UTC (permalink / raw)
To: git
Hi,
I just was in the need for git-stash (for the 1e6th time this year), but
instead of writing a script, I though I'd try the "!" convention for
aliases. Works quite well for me:
git config alias.stash '!git diff-files --name-only -z | git update-index
-z --stdin && tree=$(git-write-tree) && commit=$(echo stash $(date) |
git-commit-tree $tree) && git-update-ref refs/heads/stash $commit &&
git-reset --hard'
(This is one long line.)
With this, I can now say "git stash" with a dirty working directory, and
it will have the same effect as "git reset --hard", i.e. reset to the
clean state in HEAD.
Except that all my changes are stashed away in the branch "stash". It is
not really a branch, as I expect it to jump from loose end to loose end,
like this:
A - B - C - D - E - F - G - H - ... (master branch)
\ \ \
A' .. E' .. G' (stash branch)
The ".." denote reflog connections: "git log stash" will show G' and as
its parent G with its history, while "git reflog stash" will show G', and
then E', and then A'.
Maybe it is not only useful for me...
Ciao,
Dscho
^ permalink raw reply
* Problems with git-svnimport
From: Alex R.M. Turner @ 2007-06-07 21:42 UTC (permalink / raw)
To: git
I am trying to import my svn project into git with git-svnimport, but I am
getting a bunch of error messages using the following command:
git-svnimport -C eastcoastmarine -v \
svn://svn.mintpixels.com/eastcoastmarine-website
I get messages like:
4: Unrecognized path: /trend-scripts/trunk/run_purge.sh
Is this expected, or should I be worried?
Alex
^ permalink raw reply
* [PATCH] Fix bug in tag parsing when thorough verification was in effect
From: Johan Herland @ 2007-06-07 22:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <200706040251.52613.johan@herland.net>
The code that was enabled by passing a non-zero 'thorough_verify' argument
to parse_and_verify_tag_buffer() moved the 'tag_line' and 'keywords_line'
pointer variables forward in memory while checking for illegal chars.
These pointers were later used when setting the respective members on
the parsed tag object.
The fix refactors the verification loop so as to use offsets to the
'tag_line' and 'keywords_line' pointers, instead of moving the pointers
directly.
The patch also includes cleanup of the code associated with moving the
various '*_line' pointers past their initial header field identifier.
These operations are now done along with the calculation of their
corresponding '*_len' variables.
The patch also includes minor changes to expected output in associated
testcases.
The bug was discovered by inspection. Currently none of the callers of
parse_and_verify_tag_buffer() that use thorough_verify != 0, also use
the 'tag' and 'keywords' members of the parsed tag object.
Signed-off-by: Johan Herland <johan@herland.net>
---
This goes on top of the existing "Refactor the tag object" patch series.
Have fun!
...Johan
t/t3800-mktag.sh | 8 ++++----
tag.c | 49 ++++++++++++++++++++++++++-----------------------
2 files changed, 30 insertions(+), 27 deletions(-)
diff --git a/t/t3800-mktag.sh b/t/t3800-mktag.sh
index f6e3d10..ac9008a 100755
--- a/t/t3800-mktag.sh
+++ b/t/t3800-mktag.sh
@@ -186,7 +186,7 @@ tagger bar@baz.com
EOF
cat >expect.pat <<EOF
-^error: char67: could not verify tag name$
+^error: char66: could not verify tag name$
EOF
check_verify_failure 'verify tag-name check'
@@ -240,7 +240,7 @@ tagger bar@baz.com
EOF
cat >expect.pat <<EOF
-^error: char83: .*$
+^error: char82: .*$
EOF
check_verify_failure '"keywords" line check #1'
@@ -258,7 +258,7 @@ tagger bar@baz.com
EOF
cat >expect.pat <<EOF
-^error: char87: .*$
+^error: char86: .*$
EOF
check_verify_failure '"keywords" line check #2'
@@ -276,7 +276,7 @@ tagger bar@baz.com
EOF
cat >expect.pat <<EOF
-^error: char83: .*$
+^error: char82: .*$
EOF
check_verify_failure '"keywords" line check #3'
diff --git a/tag.c b/tag.c
index 9c95e0b..e371179 100644
--- a/tag.c
+++ b/tag.c
@@ -153,52 +153,55 @@ int parse_and_verify_tag_buffer(struct tag *item, const char *data, const unsign
if (*header_end != '\n') /* header must end with "\n\n" */
return error("char" PD_FMT ": could not find blank line after header section", header_end - data);
- /* Calculate lengths of header fields */
- type_len = tag_line == type_line ? 0 : /* 0 if not given, > 0 if given */
- (tag_line - type_line) - strlen("type \n");
- tag_len = keywords_line == tag_line ? 0 : /* 0 if not given, > 0 if given */
- (keywords_line - tag_line) - strlen("tag \n");
- keywords_len = tagger_line == keywords_line ? 0 : /* 0 if not given, > 0 if given */
- (tagger_line - keywords_line) - strlen("keywords \n");
- tagger_len = header_end == tagger_line ? 0 : /* 0 if not given, > 0 if given */
- (header_end - tagger_line) - strlen("tagger \n");
+ /*
+ * Advance header field pointers past their initial identifier.
+ * Calculate lengths of header fields (0 for fields that are not given).
+ */
+ type_line += strlen("type ");
+ type_len = tag_line > type_line ? ( tag_line - type_line) - 1 : 0;
+ tag_line += strlen("tag ");
+ tag_len = keywords_line > tag_line ? (keywords_line - tag_line) - 1 : 0;
+ keywords_line += strlen("keywords ");
+ keywords_len = tagger_line > keywords_line ? ( tagger_line - keywords_line) - 1 : 0;
+ tagger_line += strlen("tagger ");
+ tagger_len = header_end > tagger_line ? ( header_end - tagger_line) - 1 : 0;
/* Get the actual type */
if (type_len >= sizeof(type))
- return error("char" PD_FMT ": type too long", (type_line + 5) - data);
- memcpy(type, type_line + 5, type_len);
+ return error("char" PD_FMT ": type too long", (type_line) - data);
+ memcpy(type, type_line, type_len);
type[type_len] = '\0';
if (thorough_verify) {
+ unsigned long i;
+
/* Verify that the object matches */
if (verify_object(sha1, type))
return error("char%d: could not verify object %s", 7, sha1_to_hex(sha1));
/* Verify the tag name: we don't allow control characters or spaces in it */
if (tag_len > 0) { /* tag name was given */
- tag_line += 4; /* skip past "tag " */
- for (;;) {
- unsigned char c = *tag_line++;
+ for (i = 0; i < tag_len; ++i) {
+ unsigned char c = tag_line[i];
if (c == '\n')
break;
if (c > ' ' && c != 0x7f)
continue;
- return error("char" PD_FMT ": could not verify tag name", tag_line - data);
+ return error("char" PD_FMT ": could not verify tag name", tag_line + i - data);
}
}
/* Verify the keywords line: we don't allow control characters or spaces in it, or two subsequent commas */
if (keywords_len > 0) { /* keywords line was given */
- keywords_line += 9; /* skip past "keywords " */
- for (;;) {
- unsigned char c = *keywords_line++;
+ for (i = 0; i < keywords_len; ++i) {
+ unsigned char c = keywords_line[i];
if (c == '\n')
break;
- if (c == ',' && *keywords_line == ',')
- return error("char" PD_FMT ": found empty keyword", keywords_line - data);
+ if (c == ',' && keywords_line[i + 1] == ',') /* consecutive commas */
+ return error("char" PD_FMT ": found empty keyword", keywords_line + i - data);
if (c > ' ' && c != 0x7f)
continue;
- return error("char" PD_FMT ": could not verify keywords", keywords_line - data);
+ return error("char" PD_FMT ": could not verify keywords", keywords_line + i - data);
}
}
@@ -211,7 +214,7 @@ int parse_and_verify_tag_buffer(struct tag *item, const char *data, const unsign
if (item) { /* Store parsed information into item */
if (tag_len > 0) { /* optional tag name was given */
item->tag = xmalloc(tag_len + 1);
- memcpy(item->tag, tag_line + 4, tag_len);
+ memcpy(item->tag, tag_line, tag_len);
item->tag[tag_len] = '\0';
}
else { /* optional tag name not given */
@@ -221,7 +224,7 @@ int parse_and_verify_tag_buffer(struct tag *item, const char *data, const unsign
if (keywords_len > 0) { /* optional keywords string was given */
item->keywords = xmalloc(keywords_len + 1);
- memcpy(item->keywords, keywords_line + 9, keywords_len);
+ memcpy(item->keywords, keywords_line, keywords_len);
item->keywords[keywords_len] = '\0';
}
else { /* optional keywords string not given. Set default keywords */
--
1.5.2
^ permalink raw reply related
* Re: StGIT: stgitformatversion vs. stgit.formatversion
From: Catalin Marinas @ 2007-06-07 21:55 UTC (permalink / raw)
To: Karl Hasselström; +Cc: Yann Dirson, GIT list
In-Reply-To: <20070603121718.GA6507@diana.vm.bytemark.co.uk>
On 03/06/07, Karl Hasselström <kha@treskal.com> wrote:
> It happens a bit too often that we find problems with patches only
> after Catalin has published them on "master". (At least that seems to
> be the case with patches coming from me!) Maybe a "pu" branch
> (maintained either by Catalin or someone else) would be a good way to
> smoke them out before they're written in stone and distributed to lots
> of people.
BTW, if any of you is willing to maintain such a branch, I'll happily
pull from it when it gets stable.
--
Catalin
^ permalink raw reply
* Re: [StGIT PATCH 0/2] Fix issues with series deletion
From: Catalin Marinas @ 2007-06-07 21:50 UTC (permalink / raw)
To: Yann Dirson; +Cc: git
In-Reply-To: <20070606205852.7657.69286.stgit@gandelf.nowhere.earth>
On 06/06/07, Yann Dirson <ydirson@altern.org> wrote:
> I am however not happy at all with the way we delete patches and
> series, starting with an existence check and then deleting. If any
> error occurs midway, then we are left with an inconsistent state that
> the user has to cleanup by hand. IMHO, we should have those methods
> be as robust as possible, maybe starting by removing the formatversion
> item, and printing a "cleaning up zombie stack" if does not find it.
> So at least after fixing a "delete" bug, we could rerun the same
> command and get to a sane state again.
This sounds OK for a quick fix. Longer term, I think we should support
some kind of transactions. One idea is to put the StGIT metadata in a
single file (or maybe two if we include the config) that gets checked
in after every operation.
--
Catalin
^ permalink raw reply
* Re: [PATCH] [RFC] Generational repacking
From: Sam Vilain @ 2007-06-07 21:36 UTC (permalink / raw)
To: Martin Langhoff; +Cc: Nicolas Pitre, Dana How, Junio C Hamano, git
In-Reply-To: <46a038f90706071246y7dd14f55t199b8ed4e7617b68@mail.gmail.com>
Martin Langhoff wrote:
> On 6/7/07, Nicolas Pitre <nico@cam.org> wrote:
>> Run git-repack without -a from some hook. You can even launch it in the
>> background.
>
> I posted an RFC patch a while ago doing exactly that, and Linus shot
> it down, indicating we should instead print a message suggesting
> repack to the user.
>
> Relevant thread around
> http://www.gelato.unsw.edu.au/archives/git/0606/22977.html
>
>> Or what am I missing?
>
> I don't think people were comfortable at the time with concurrent
> repacks -- though the semantics are safe if we don't hit any bug. My
> guess is that noone wants to risk the .001% chances of data corruption
> for this nice-to-have.
Ok. But if repack is generational you probably don't mind waiting for
it on commit so don't need to background it.
Sam.
^ permalink raw reply
* Re: [PATCH] [RFC] Generational repacking
From: Sam Vilain @ 2007-06-07 21:29 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git Mailing List
In-Reply-To: <alpine.LFD.0.99.0706070932000.12885@xanadu.home>
Nicolas Pitre wrote:
> >> Well that depends how many loose objects there are :) I heard about on
>> Windows a case where packing 30k loose objects took over an hour.
> > And your patch cannot change anything to that, right?
> You shouldn't wait until 30k loose objects accumulate before repacking.
Absolutely. But the generational approach would make it practical to
repack very often, in fact automatically, and keep the time of that
repack reasonably bounded. As I said in the original patch, the
intention is that this style of repacking works best when applied
automatically, perhaps on commit.
>> If you repack every 100 objects without -a, sure it will be fast, but
>> you'll end up with too many packs.
> You just need to adjust this treshold of 100 objects.
> And latest GIT behaves _much_ better with lots of packs, almost like if
> there was only one pack. See the test results I posted to the list.
The test run with 66 packs? What about a repository with 300000 objects
that was repacked every 100 new objects, would it work well with with
3000 packs? Surely there is some value in conglomerating older packs,
even though your LRU patch might make it very small (which I do find
impressive). Do you really need me to prove this with a benchmark?
"Adjust the threshold" you have already said. But the problem with that
is what to? I want the automatic repack to be *fast*. So making it
larger will make it slower. But making it too small will make the packs
excessive.
Sam.
^ permalink raw reply
* Re: pull/merge --no-commit
From: Keith Duthie @ 2007-06-07 20:51 UTC (permalink / raw)
To: kurt_p_lloyd; +Cc: git, Junio C Hamano, Kevin Green
In-Reply-To: <46686B63.6080808@alcatel-lucent.com>
On Thu, 7 Jun 2007, kurt_p_lloyd wrote:
> Just an idea. Of course, if something like this already exists ....
> (I'd rather not shut down sshd, nor have to create a separate "public"
> repository (for certain types of "projects" anyway).)
Actually, a separate public repository is probably exactly what you want
here. If you clone the repository with the local and shared flags you'll
only need to have one copy of the objects on disk (if I understand things
correctly), and you can just push your development branch to the public
repository whenever you're happy with the state of your code.
And if you're going to give other people access to your development
repository then you're probably best off having a branch (or branches)
that are there specifically for other people to pull from, and make sure
you don't merge anything into those branches without it being ready for
release. And then tell people it's their own fault if they grab one of
your work-in-progress branches instead ;-)
--
The universe hates you, but don't worry - it's nothing personal.
^ permalink raw reply
* [PATCH] Missing statics.
From: Pierre Habouzit @ 2007-06-07 20:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pierre Habouzit
In-Reply-To: <118124910076-git-send-email-madcoder@debian.org>
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
builtin-branch.c | 4 ++--
builtin-revert.c | 2 +-
daemon.c | 2 +-
wt-status.c | 2 +-
xdiff/xemit.c | 4 ++--
5 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/builtin-branch.c b/builtin-branch.c
index 67f46c1..da48051 100644
--- a/builtin-branch.c
+++ b/builtin-branch.c
@@ -55,7 +55,7 @@ static int parse_branch_color_slot(const char *var, int ofs)
die("bad config variable '%s'", var);
}
-int git_branch_config(const char *var, const char *value)
+static int git_branch_config(const char *var, const char *value)
{
if (!strcmp(var, "color.branch")) {
branch_use_color = git_config_colorbool(var, value);
@@ -72,7 +72,7 @@ int git_branch_config(const char *var, const char *value)
return git_default_config(var, value);
}
-const char *branch_get_color(enum color_branch ix)
+static const char *branch_get_color(enum color_branch ix)
{
if (branch_use_color)
return branch_colors[ix];
diff --git a/builtin-revert.c b/builtin-revert.c
index 80c348c..8f02ed7 100644
--- a/builtin-revert.c
+++ b/builtin-revert.c
@@ -107,7 +107,7 @@ static char *get_oneline(const char *message)
return result;
}
-char *get_encoding(const char *message)
+static char *get_encoding(const char *message)
{
const char *p = message, *eol;
diff --git a/daemon.c b/daemon.c
index 674e30d..4c8c322 100644
--- a/daemon.c
+++ b/daemon.c
@@ -439,7 +439,7 @@ static void parse_extra_args(struct interp *table, char *extra_args, int buflen)
}
}
-void fill_in_extra_table_entries(struct interp *itable)
+static void fill_in_extra_table_entries(struct interp *itable)
{
char *hp;
diff --git a/wt-status.c b/wt-status.c
index 4bfe8f1..5205420 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -198,7 +198,7 @@ static void wt_read_cache(struct wt_status *s)
read_cache();
}
-void wt_status_print_initial(struct wt_status *s)
+static void wt_status_print_initial(struct wt_status *s)
{
int i;
char buf[PATH_MAX];
diff --git a/xdiff/xemit.c b/xdiff/xemit.c
index e291dc7..86315b7 100644
--- a/xdiff/xemit.c
+++ b/xdiff/xemit.c
@@ -99,8 +99,8 @@ static void xdl_find_func(xdfile_t *xf, long i, char *buf, long sz, long *ll) {
}
-int xdl_emit_common(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
- xdemitconf_t const *xecfg) {
+static int xdl_emit_common(xdfenv_t *xe, xdchange_t *xscr, xdemitcb_t *ecb,
+ xdemitconf_t const *xecfg) {
xdfile_t *xdf = &xe->xdf1;
const char *rchg = xdf->rchg;
long ix;
--
1.5.2.1
^ permalink raw reply related
* [PATCH] Active_nr is unsigned, hence can't be < 0
From: Pierre Habouzit @ 2007-06-07 20:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, Pierre Habouzit
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
---
sha1_name.c | 2 --
1 files changed, 0 insertions(+), 2 deletions(-)
diff --git a/sha1_name.c b/sha1_name.c
index 7df01af..858f08c 100644
--- a/sha1_name.c
+++ b/sha1_name.c
@@ -682,8 +682,6 @@ int get_sha1_with_mode(const char *name, unsigned char *sha1, unsigned *mode)
namelen = namelen - (cp - name);
if (!active_cache)
read_cache();
- if (active_nr < 0)
- return -1;
pos = cache_name_pos(cp, namelen);
if (pos < 0)
pos = -pos - 1;
--
1.5.2.1
^ permalink raw reply related
* Re: pull/merge --no-commit
From: J. Bruce Fields @ 2007-06-07 20:43 UTC (permalink / raw)
To: kurt_p_lloyd; +Cc: git, Keith Duthie, Junio C Hamano, Kevin Green
In-Reply-To: <46686B63.6080808@alcatel-lucent.com>
On Thu, Jun 07, 2007 at 04:32:35PM -0400, kurt_p_lloyd wrote:
> One thing I was thinking might be useful would be a command to make
> (just) my repository unavailable for 'fetch' or 'pull' from others,
> temporarily. And then a command to make it available again,
> after I finish things that could end up needing "database" surgery,
> like maybe something that could result in having to do a git reset.
> I was thinking maybe something like:
>
> $ git config maintenance true
> .... do something that may end up needing "database" surgery
> $ git config maintenance false
You could probably do that with file permissions, but...
> Just an idea. Of course, if something like this already exists ....
> (I'd rather not shut down sshd, nor have to create a separate "public"
> repository (for certain types of "projects" anyway).)
... why not? Having a separate public repository also allows you to do
this and much more. And it should be cheap and easy--if you're worried
about the space, clone with --shared or something.
--b.
^ permalink raw reply
* Re: pull/merge --no-commit
From: kurt_p_lloyd @ 2007-06-07 20:32 UTC (permalink / raw)
To: git; +Cc: Keith Duthie, Junio C Hamano, Kevin Green
In-Reply-To: <alpine.DEB.0.99.0706080658070.6319@sleipnir.no.net.nz>
Many thanks to Junio, Kevin, and Keith for the helpful comments.
I'll give some play time to all of these suggestions :)
One thing I was thinking might be useful would be a command to make
(just) my repository unavailable for 'fetch' or 'pull' from others,
temporarily. And then a command to make it available again,
after I finish things that could end up needing "database" surgery,
like maybe something that could result in having to do a git reset.
I was thinking maybe something like:
$ git config maintenance true
.... do something that may end up needing "database" surgery
$ git config maintenance false
Just an idea. Of course, if something like this already exists ....
(I'd rather not shut down sshd, nor have to create a separate "public"
repository (for certain types of "projects" anyway).)
-Kurt
Keith Duthie wrote:
> On Thu, 7 Jun 2007, kurt_p_lloyd wrote:
>
>> Except here's the model that I am trying to follow....
>> It seems that 'pull' can be partitioned into 3 separate responsibilities:
>>
>> 1. Retrieve changes from the remote user's replica (without modifying
>> any /local/ branches).
>> 2. Bring changes from "remote" into a local branch (without commit).
>> 3. Commit.
>
> I believe you can accomplish step one with a remote tracking branch
> ("git-remote add localname git://whereever/project.git" to add the branch
> to the repository, then "git-remote update localname" to update it to the
> current remote state).
^ permalink raw reply
* Re: git-log fatal error in empty repo
From: Junio C Hamano @ 2007-06-07 20:29 UTC (permalink / raw)
To: Steve Hoelzer; +Cc: git
In-Reply-To: <588192970706070634s4c25ae45g68be32c06a30d043@mail.gmail.com>
"Steve Hoelzer" <shoelzer@gmail.com> writes:
> git-log will return a fatal error for an empty repo, like so:
>
> $ git --version
> git version 1.5.2.73.g18bece
> $ mkdir mytest
> $ cd mytest
> $ git-init
> Initialized empty Git repository in .git/
> $ git-log
> fatal: bad default revision 'HEAD'
>
> It would be nice if git-log was quiet or returned a "no log" message
> instead of the fatal error.
Maybe, but I highly doubt if it is worth to bother about it.
revision.c | 5 ++++-
1 files changed, 4 insertions(+), 1 deletions(-)
diff --git a/revision.c b/revision.c
index 0a29b53..0573b86 100644
--- a/revision.c
+++ b/revision.c
@@ -1218,8 +1218,11 @@ int setup_revisions(int argc, const char **argv, struct rev_info *revs, const ch
unsigned char sha1[20];
struct object *object;
unsigned mode;
- if (get_sha1_with_mode(def, sha1, &mode))
+ if (get_sha1_with_mode(def, sha1, &mode)) {
+ if (!strcmp("HEAD", def))
+ die("You have no history yet on your HEAD");
die("bad default revision '%s'", def);
+ }
object = get_reference(revs, def, sha1, 0);
add_pending_object_with_mode(revs, object, def, mode);
}
^ permalink raw reply related
* Re: [PATCH] [RFC] Generational repacking
From: Martin Langhoff @ 2007-06-07 19:46 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Sam Vilain, Dana How, Junio C Hamano, git
In-Reply-To: <alpine.LFD.0.99.0706062314410.12885@xanadu.home>
On 6/7/07, Nicolas Pitre <nico@cam.org> wrote:
> Run git-repack without -a from some hook. You can even launch it in the
> background.
I posted an RFC patch a while ago doing exactly that, and Linus shot
it down, indicating we should instead print a message suggesting
repack to the user.
Relevant thread around
http://www.gelato.unsw.edu.au/archives/git/0606/22977.html
> Or what am I missing?
I don't think people were comfortable at the time with concurrent
repacks -- though the semantics are safe if we don't hit any bug. My
guess is that noone wants to risk the .001% chances of data corruption
for this nice-to-have.
It was also probably a bad idea in my patch that it said -a -- it should just be
git repack -l -q &
[And I generally agree with the concerns about possibly broken
semantics, unexpected user actions and racing repacks. One of the main
reasons I've never advocated SVN is that the early stories of data
corruption using BDB backends made me very very very wary of it.
Perhaps because I lot months of work in the past to disk corruption in
a cvs repo, and have a good mental picture of the nervous breakdown
that followed.]
cheers,
m
^ permalink raw reply
* Re: pull/merge --no-commit
From: Keith Duthie @ 2007-06-07 19:12 UTC (permalink / raw)
To: kurt_p_lloyd; +Cc: Junio C Hamano, git
In-Reply-To: <46684EFD.1080804@alcatel-lucent.com>
On Thu, 7 Jun 2007, kurt_p_lloyd wrote:
> Except here's the model that I am trying to follow....
> It seems that 'pull' can be partitioned into 3 separate responsibilities:
>
> 1. Retrieve changes from the remote user's replica (without modifying
> any /local/ branches).
> 2. Bring changes from "remote" into a local branch (without commit).
> 3. Commit.
I believe you can accomplish step one with a remote tracking branch
("git-remote add localname git://whereever/project.git" to add the branch
to the repository, then "git-remote update localname" to update it to the
current remote state).
--
The universe hates you, but don't worry - it's nothing personal.
^ 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