* git clone / SHA1 mismatch
From: Mika Muukkonen @ 2006-07-21 4:55 UTC (permalink / raw)
To: git
Greetings,
when attempting to clone repositories (Linus's kernel, stable 2.6.16, OMAP kernel) I seem to come across the following more or less constantly:
mmu@spud1:/var/git$ git clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git linux-2.6.16
Generating pack...
Done counting 195441 objects.
Deltifying 195441 objects.
100% (195441/195441) done
fatal: unexpected EOF)
fatal: packfile '/var/git/linux-2.6.16/.git/objects/pack/tmp-QeO4uB' SHA1 mismatch
error: git-fetch-pack: unable to read from git-index-pack
error: git-index-pack died with error code 128
fetch-pack from 'git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git' failed.
and
mmu@spud1:/var/git$ cg-clone git://git.kernel.org/pub/scm/linux/kernel/git/stable/linux-2.6.16.y.git linux-2.6.16
defaulting to local storage area
Fetching pack (head and objects)...
Generating pack...
Done counting 190732 objects.
Deltifying 190732 objects.
100% (190732/190732) done
fatal: unexpected EOF)
fatal: packfile '.git/objects/pack/tmp-4BiKAb' SHA1 mismatch
error: git-fetch-pack: unable to read from git-index-pack
error: git-index-pack died with error code 128
cg-fetch: fetching pack failed
and... and...
I compiled a rather recent version of git:
mmu@spud1:/var/git$ git --version
git version 1.4.2.rc1.ge7a0
and the all other libs required are up-to-date as well.
So; am I missing something or should cloning of current trees at kernel.org go down smoothly. Any advice apprecieated.
Mika Muukkonen
^ permalink raw reply
* Re: Easy way to empty working tree?
From: Linus Torvalds @ 2006-07-21 2:48 UTC (permalink / raw)
To: Robin Luckey; +Cc: git
In-Reply-To: <761519800607201828m19684b2jc267411ef3b8b9e2@mail.gmail.com>
On Thu, 20 Jul 2006, Robin Luckey wrote:
>
> I have some very large git repositories that serve mainly as archives,
> and it would be nice to clear out the working directories for the
> repositories I am not currently working with. I'm not trying to delete
> the files from the repository, I just want free up space in idle
> repositories.
Well, that actually sounds like you might want to just make them totally
"bare" repositories, ie you can just do something like
mv repo/.git repo.git
rm -rf repo
and then "repo.git" is a valid bare repository.
However, if you actually want to just clear the checked-out files:
> After mothballing the repository with git-repack -a -d and git clean
> -d -x, is there a convenient one-liner to empty the files out the
> working directory?
Well, you can do
git ls-files -z | xargs -0 rm -f --
or something, or indeed just do a "rm -rf *", since the only thing you
actually would want to save is the ".git" directory.
Linus
^ permalink raw reply
* Easy way to empty working tree?
From: Robin Luckey @ 2006-07-21 1:28 UTC (permalink / raw)
To: git
I have some very large git repositories that serve mainly as archives,
and it would be nice to clear out the working directories for the
repositories I am not currently working with. I'm not trying to delete
the files from the repository, I just want free up space in idle
repositories.
After mothballing the repository with git-repack -a -d and git clean
-d -x, is there a convenient one-liner to empty the files out the
working directory?
Thanks,
Robin
^ permalink raw reply
* Your cash, organ building
From: Marcelino Sheldon @ 2006-07-20 23:14 UTC (permalink / raw)
To: git-commits-head-owner
Even if you have no erectin problems SOFT CIA2LIS
would help you to make BETTER SE6X MORE OFTEN!
and to bring unimagnable plesure to her.
Just disolve half a pil under your tongue
and get ready for action in 15 minutes.
The tests showed that the majority of men
after taking this medic ation were able to have
PERFECT ER4ECTION during 36 hours!
VISIT US, AND GET OUR SPECIAL 70% DISCAOUNT OFER!
http://885W662t4buc1uquzp66zto6hb6o6.coactivejj.com/
==========
straight down, wings full out and stable from the moment he passed fifty
fifteenth floor sympathetic faces watched us off. All we lacked were waving
affords a new perspective on the nature of ours and ourselves; it even has
two copper disks the size of a saucer, -about a quarter inch thick, with a
he had blurred through ninety miles per hour. Jonathan had set a world
of my business. Now nothing concerned me any more.
inverted spin, and recovered at last, panting, a hundred feet below his
And he stood there with his last empty on the scales, looking like he
^ permalink raw reply
* Re: initializing remote clone but files already there
From: Petr Baudis @ 2006-07-20 21:32 UTC (permalink / raw)
To: Yakov Lerner; +Cc: Git Mailing List
In-Reply-To: <f36b08ee0607201241t6160b1eqb4f0b255b02499a7@mail.gmail.com>
Dear diary, on Thu, Jul 20, 2006 at 09:41:48PM CEST, I got a letter
where Yakov Lerner <iler.ml@gmail.com> said that...
> There are two machines with slow ssh access. The
> both have copy of same filetree that was synchronized
> previously vi rsync. How do I put both trees under git control
> as if they were clone on one other *but* (1) without creating
> branches and (2) without copying files over (files are already
> there) ?
Put one tree under the git control and examine the initial commit in
detail (cg-log -v or git show --pretty=fuller or whatever). Now you want
to perform the initial commit in the other tree with exactly the same
metadata; log message should be easy, to carry over all the times and
stuff, you need to set GIT_AUTHOR_{NAME,EMAIL,DATE} and
GIT_COMMITTER_<dtto> based on the other initial commit details. That
should result in a same commit id. Then you need to just set up remote
branch origin just like you would set up any other remote branch.
Good luck,
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* git-svn + publishing repos question
From: Seth Falcon @ 2006-07-20 19:41 UTC (permalink / raw)
To: git
Hi all,
I want to publish a read-only git mirror of a project that uses svn.
So far, I have a git repository served by git-daemon and git-svn has
been used to create remotes/git-svn. I'm thinking the git-svn fetch
can be put in chron.
I know that I could pull remotes/git-svn into master (and also chron
that), but is there a shortcut (to trick the repos into thinking that
master and remotes/git-svn are the same)?
Other suggestions?
Thanks,
+ seth
^ permalink raw reply
* initializing remote clone but files already there
From: Yakov Lerner @ 2006-07-20 19:41 UTC (permalink / raw)
To: Git Mailing List
There are two machines with slow ssh access. The
both have copy of same filetree that was synchronized
previously vi rsync. How do I put both trees under git control
as if they were clone on one other *but* (1) without creating
branches and (2) without copying files over (files are already
there) ?
Thanks
Yakov
^ permalink raw reply
* Unanticipated test error
From: Peter Eriksen @ 2006-07-20 19:40 UTC (permalink / raw)
To: git
Greetings,
I get a bit strange "make test" error using the patch bellow on the
current Git master branch. Applied with git-apply. I suspect it is
an error in my umask or something. It compiles fine. The error
output is:
[peter@localhost git]$ make test
make -C templates
make[1]: Entering directory `/home/peter/Git/git/templates'
: no custom templates yet
make[1]: Leaving directory `/home/peter/Git/git/templates'
make -C t/ all
make[1]: Entering directory `/home/peter/Git/git/t'
*** t0000-basic.sh ***
mv: cannot stat `.git/hooks': No such file or directory
* ok 1: .git/objects should be empty after git-init-db in an empty repo.
* ok 2: .git/objects should have 3 subdirectories.
* ok 3: git-update-index without --add should fail adding.
* ok 4: git-update-index with --add should succeed.
* ok 5: writing tree out with git-write-tree
* ok 6: validate object ID of a known tree.
* ok 7: git-update-index without --remove should fail removing.
* ok 8: git-update-index with --remove should be able to remove.
* ok 9: git-write-tree should be able to write an empty tree.
* ok 10: validate object ID of a known tree.
* ok 11: adding various types of objects with git-update-index --add.
* ok 12: showing stage with git-ls-files --stage
* ok 13: validate git-ls-files output for a known tree.
* FAIL 14: writing tree out with git-write-tree.
tree=$(git-write-tree)
* FAIL 15: validate object ID for a known tree.
test "$tree" = 087704a96baf1c2d1c869a8b084481e121c88b5b
* FAIL 16: showing tree with git-ls-tree
git-ls-tree $tree >current
* FAIL 17: git-ls-tree output for a known tree.
diff current expected
* FAIL 18: showing tree with git-ls-tree -r
git-ls-tree -r $tree >current
* FAIL 19: git-ls-tree -r output for a known tree.
diff current expected
* FAIL 20: showing tree with git-ls-tree -r -t
git-ls-tree -r -t $tree >current
* FAIL 21: git-ls-tree -r output for a known tree.
diff current expected
* FAIL 22: writing partial tree out with git-write-tree --prefix.
ptree=$(git-write-tree --prefix=path3)
* FAIL 23: validate object ID for a known tree.
test "$ptree" = 21ae8269cacbe57ae09138dcc3a2887f904d02b3
* FAIL 24: writing partial tree out with git-write-tree --prefix.
ptree=$(git-write-tree --prefix=path3/subp3)
* FAIL 25: validate object ID for a known tree.
test "$ptree" = 3c5e5399f3a333eddecce7a9b9465b63f65f51e2
* FAIL 26: git-read-tree followed by write-tree should be idempotent.
git-read-tree $tree &&
test -f .git/index &&
newtree=$(git-write-tree) &&
test "$newtree" = "$tree"
* FAIL 27: validate git-diff-files output for a know cache/work tree state.
git-diff-files >current && diff >/dev/null -b current expected
* ok 28: git-update-index --refresh should succeed.
* ok 29: no diff after checkout and git-update-index --refresh.
* FAIL 30: git-commit-tree records the correct tree in a commit.
commit0=$(echo NO | git-commit-tree $P) &&
tree=$(git show --pretty=raw $commit0 |
sed -n -e "s/^tree //p" -e "/^author /q") &&
test "z$tree" = "z$P"
* FAIL 31: git-commit-tree records the correct parent in a commit.
commit1=$(echo NO | git-commit-tree $P -p $commit0) &&
parent=$(git show --pretty=raw $commit1 |
sed -n -e "s/^parent //p" -e "/^author /q") &&
test "z$commit0" = "z$parent"
* FAIL 32: git-commit-tree omits duplicated parent in a commit.
commit2=$(echo NO | git-commit-tree $P -p $commit0 -p $commit0) &&
parent=$(git show --pretty=raw $commit2 |
sed -n -e "s/^parent //p" -e "/^author /q" |
sort -u) &&
test "z$commit0" = "z$parent" &&
numparent=$(git show --pretty=raw $commit2 |
sed -n -e "s/^parent //p" -e "/^author /q" |
wc -l) &&
test $numparent = 1
* failed 17 among 32 test(s)
make[1]: *** [t0000-basic.sh] Error 1
make[1]: Leaving directory `/home/peter/Git/git/t'
make: *** [test] Error 2
[peter@localhost git]$
The patch really should not change any semantics at all, since
it converts instances of
memcpy(to, from, len);
to[len] = 0;
into
strlcpy(to, from, len);
I need a bit of help troubleshooting this one. I have tried
running t0000-basic.sh using "bash -x", but that did not help
me this time.
Regards,
Peter
======== strlcpy.diff ===============
diff --git a/builtin-apply.c b/builtin-apply.c
index c903146..79537c5 100644
--- a/builtin-apply.c
+++ b/builtin-apply.c
@@ -266,8 +266,7 @@ static char * find_name(const char *line
}
name = xmalloc(len + 1);
- memcpy(name, start, len);
- name[len] = 0;
+ strlcpy(name, start, len);
free(def);
return name;
}
@@ -439,8 +438,7 @@ static int gitdiff_index(const char *lin
if (!ptr || ptr[1] != '.' || 40 < ptr - line)
return 0;
len = ptr - line;
- memcpy(patch->old_sha1_prefix, line, len);
- patch->old_sha1_prefix[len] = 0;
+ strlcpy(patch->old_sha1_prefix, line, len);
line = ptr + 2;
ptr = strchr(line, ' ');
@@ -452,8 +450,7 @@ static int gitdiff_index(const char *lin
if (40 < len)
return 0;
- memcpy(patch->new_sha1_prefix, line, len);
- patch->new_sha1_prefix[len] = 0;
+ strlcpy(patch->new_sha1_prefix, line, len);
if (*ptr == ' ')
patch->new_mode = patch->old_mode = strtoul(ptr+1, NULL, 8);
return 0;
@@ -609,8 +606,7 @@ static char *git_header_name(char *line,
}
if (second[len] == '\n' && !memcmp(name, second, len)) {
char *ret = xmalloc(len + 1);
- memcpy(ret, name, len);
- ret[len] = 0;
+ strlcpy(ret, name, len);
return ret;
}
}
diff --git a/builtin-init-db.c b/builtin-init-db.c
index 7fdd2fa..206cad1 100644
--- a/builtin-init-db.c
+++ b/builtin-init-db.c
@@ -156,8 +156,7 @@ static void copy_templates(const char *g
return;
}
- memcpy(path, git_dir, len);
- path[len] = 0;
+ strlcpy(path, git_dir, len);
copy_templates_1(path, len,
template_path, template_len,
dir);
diff --git a/builtin-ls-files.c b/builtin-ls-files.c
index 8dae9f7..a2bd674 100644
--- a/builtin-ls-files.c
+++ b/builtin-ls-files.c
@@ -310,8 +310,7 @@ static void verify_pathspec(void)
prefix_len = max;
if (max) {
real_prefix = xmalloc(max + 1);
- memcpy(real_prefix, prev, max);
- real_prefix[max] = 0;
+ strlcpy(real_prefix, prev, max);
}
prefix = real_prefix;
}
diff --git a/cache-tree.c b/cache-tree.c
index d9f7e1e..5c8009d 100644
--- a/cache-tree.c
+++ b/cache-tree.c
@@ -80,8 +80,7 @@ static struct cache_tree_sub *find_subtr
down = xmalloc(sizeof(*down) + pathlen + 1);
down->cache_tree = NULL;
down->namelen = pathlen;
- memcpy(down->name, path, pathlen);
- down->name[pathlen] = 0;
+ strlcpy(down->name, path, pathlen);
if (pos < it->subtree_nr)
memmove(it->down + pos + 1,
diff --git a/combine-diff.c b/combine-diff.c
index 1bc1484..34c166d 100644
--- a/combine-diff.c
+++ b/combine-diff.c
@@ -31,8 +31,7 @@ static struct combine_diff_path *interse
len = strlen(path);
p = xmalloc(combine_diff_path_size(num_parent, len));
p->path = (char*) &(p->parent[num_parent]);
- memcpy(p->path, path, len);
- p->path[len] = 0;
+ strlcpy(p->path, path, len);
p->len = len;
p->next = NULL;
memset(p->parent, 0,
@@ -143,8 +142,7 @@ static void append_lost(struct sline *sl
lline->len = len;
lline->next = NULL;
lline->parent_map = this_mask;
- memcpy(lline->line, line, len);
- lline->line[len] = 0;
+ strlcpy(lline->line, line, len);
*sline->lost_tail = lline;
sline->lost_tail = &lline->next;
}
diff --git a/diff-lib.c b/diff-lib.c
index 116b5a9..3e1f0b2 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -45,8 +45,7 @@ int run_diff_files(struct rev_info *revs
dpath->next = NULL;
dpath->len = path_len;
- memcpy(dpath->path, ce->name, path_len);
- dpath->path[path_len] = '\0';
+ strlcpy(dpath->path, ce->name, path_len);
dpath->mode = 0;
memset(dpath->sha1, 0, 20);
memset(&(dpath->parent[0]), 0,
diff --git a/diffcore-order.c b/diffcore-order.c
index aef6da6..cae64b9 100644
--- a/diffcore-order.c
+++ b/diffcore-order.c
@@ -50,8 +50,7 @@ static void prepare_order(const char *or
}
else {
order[cnt] = xmalloc(ep-cp+1);
- memcpy(order[cnt], cp, ep-cp);
- order[cnt][ep-cp] = 0;
+ strlcpy(order[cnt], cp, ep-cp);
}
cnt++;
}
diff --git a/dir.c b/dir.c
index 092d077..cf0b171 100644
--- a/dir.c
+++ b/dir.c
@@ -260,8 +260,7 @@ static void add_name(struct dir_struct *
}
ent = xmalloc(sizeof(*ent) + len + 1);
ent->len = len;
- memcpy(ent->name, pathname, len);
- ent->name[len] = 0;
+ strlcpy(ent->name, pathname, len);
dir->entries[dir->nr++] = ent;
}
diff --git a/entry.c b/entry.c
index 793724f..0860ded 100644
--- a/entry.c
+++ b/entry.c
@@ -11,8 +11,7 @@ static void create_directories(const cha
while ((slash = strchr(slash+1, '/')) != NULL) {
len = slash - path;
- memcpy(buf, path, len);
- buf[len] = 0;
+ strlcpy(buf, path, len);
if (mkdir(buf, 0777)) {
if (errno == EEXIST) {
struct stat st;
diff --git a/imap-send.c b/imap-send.c
index 65c71c6..a4c40e8 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -656,8 +656,7 @@ parse_imap_list_l( imap_t *imap, char **
cur->len = s - p;
s++;
cur->val = xmalloc( cur->len + 1 );
- memcpy( cur->val, p, cur->len );
- cur->val[cur->len] = 0;
+ strlcpy( cur->val, p, cur->len );
} else {
/* atom */
p = s;
diff --git a/mktag.c b/mktag.c
index 27f4c4f..7047bec 100644
--- a/mktag.c
+++ b/mktag.c
@@ -76,8 +76,7 @@ static int verify_tag(char *buffer, unsi
if (typelen >= sizeof(type))
return error("char%td: type too long\n", type_line+5 - buffer);
- memcpy(type, type_line+5, typelen);
- type[typelen] = 0;
+ strlcpy(type, type_line+5, typelen);
/* Verify that the object matches */
if (get_sha1_hex(object + 7, sha1))
^ permalink raw reply related
* Re: [PATCH] git-am: Don't accept an mbox on stdin of we already have a .dotest directory
From: Lukas Sandström @ 2006-07-20 19:35 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <20060720143353.GK13776@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Wed, Jul 19, 2006 at 10:28:00PM CEST, I got a letter
> where Lukas Sandström <lukass@etek.chalmers.se> said that...
>> Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
>> ---
>
> Please don't be afraid of putting stuff to commit message. It can only
> improve things. :-)
>
>> # git format-patch -k -3 master..conflict | git am -k -3
>> => git-am fails with a conflict message
>> # git reset --hard
>>
>> # git format-patch -k -3 master..ok | git am -k -3
>> => git am fails with the same conflict message as above,
>> => since it's trying to apply the old .dotest directory
>>
>> With the patch it complains about an old .dotest
>> directory instead.
>
> I think this rather means that git reset --hard should clear the .dotest
> directory, or something (perhaps just warn)...
But the .dotest directory is user-selectable in git-am.
>
>> - test ",$#," = ",0," ||
>> + if test ",$#," != ",0," || ! tty -s
>
> ...but this looks like a horrible idea. Does this mean that git-am can't
> be now ran without a terminal? (E.g. in a cron/at job, inside a procmail
> rule etc.) That's bad.
>
This would only stop it from running without a terminal if you have an old
.dotest directory lying around, ie. you already have a failed am-session.
git-am wouldn't work in this case before either, all the patch does is to
give a better error-message.
/Lukas
^ permalink raw reply
* [ANNOUNCE] Cogito-0.18rc1
From: Petr Baudis @ 2006-07-20 16:26 UTC (permalink / raw)
To: git
Hello,
I've just released cogito-0.18rc1, it should appear at kernel.org in a
few minutes.
The highlights are pickaxe and patches showing support in cg-log,
(still somewhat broken but sometimes it works) support for renames
following in cg-log, cg-switch -l for stashing local changes when
switching, much enhanced tagging interface, cg-commit --amend,
cg-patch -m for applying mailboxes and other cool stuff; see the log for
details.
Incompatible change is renaming $COGITO_COLORS to $CG_COLORS.
P.S.: See us at #git @ FreeNode, or this afternoon at OLS! ;-)
Happy hacking,
--
Petr "Pasky the lousy poet" Baudis
Stuff: http://pasky.or.cz/
Of the 3 great composers Mozart tells us what it's like to be human,
Beethoven tells us what it's like to be Beethoven and Bach tells us
what it's like to be the universe. -- Douglas Adams
^ permalink raw reply
* Re: [PATCH] git-am: Don't accept an mbox on stdin of we already have a .dotest directory
From: Petr Baudis @ 2006-07-20 14:33 UTC (permalink / raw)
To: Lukas Sandström; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <44BE95D0.9090708@etek.chalmers.se>
Dear diary, on Wed, Jul 19, 2006 at 10:28:00PM CEST, I got a letter
where Lukas Sandström <lukass@etek.chalmers.se> said that...
> Signed-off-by: Lukas Sandström <lukass@etek.chalmers.se>
> ---
Please don't be afraid of putting stuff to commit message. It can only
improve things. :-)
> # git format-patch -k -3 master..conflict | git am -k -3
> => git-am fails with a conflict message
> # git reset --hard
>
> # git format-patch -k -3 master..ok | git am -k -3
> => git am fails with the same conflict message as above,
> => since it's trying to apply the old .dotest directory
>
> With the patch it complains about an old .dotest
> directory instead.
I think this rather means that git reset --hard should clear the .dotest
directory, or something (perhaps just warn)...
> - test ",$#," = ",0," ||
> + if test ",$#," != ",0," || ! tty -s
...but this looks like a horrible idea. Does this mean that git-am can't
be now ran without a terminal? (E.g. in a cron/at job, inside a procmail
rule etc.) That's bad.
--
Petr "Pasky" Baudis
Stuff: http://pasky.or.cz/
Snow falling on Perl. White noise covering line noise.
Hides all the bugs too. -- J. Putnam
^ permalink raw reply
* git-rerere during git-rebase
From: Ilpo Järvinen @ 2006-07-20 14:14 UTC (permalink / raw)
To: git
Hi,
I discovered that "git-am --resolved --3way" (in 1.3.1) and "git-rebase
--continue" (in 1.4.2.rc1.ge7a0) do not correctly capture hand resolved
files into .git/rr-cache. In worst case I got (with 1.3.1), afaict, the
postimage was incorrect including also all patches successfully applied
after the git-am --resolved --3way up to until the point where next
conflict occurred. To circumvent this, I can use git-rerere directly but I
remember that its manpage states that one should never have to do so. I'm
I missing something or is this a problem in git-rebase (or possibly in
git-am)?
--
i.
ps. I'm not subscribed, so please cc me.
^ permalink raw reply
* Re: remote diff
From: Andreas Ericsson @ 2006-07-20 12:06 UTC (permalink / raw)
To: Yakov Lerner; +Cc: Git Mailing List
In-Reply-To: <f36b08ee0607200454k7aa98454rd2a8a566b0ea4582@mail.gmail.com>
Yakov Lerner wrote:
> I have local repo, and remote repo ssh://x/y/.git.
>
> I tried to diff local repo against remote, with naive
> 'git-diff ssh://x/y/.git.' But this did not work. How do I
> diff with remote repo ?
>
Pull it to a new branch and diff the two branches. This should be a
pretty cheap operation unless either of the two repos has seen a lot of
development since you forked the code.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* remote diff
From: Yakov Lerner @ 2006-07-20 11:54 UTC (permalink / raw)
To: Git Mailing List
I have local repo, and remote repo ssh://x/y/.git.
I tried to diff local repo against remote, with naive
'git-diff ssh://x/y/.git.' But this did not work. How do I
diff with remote repo ?
Yakov
^ permalink raw reply
* [PATCH] Display "gitweb/test/file with spaces" in gitk
From: Thomas Kolejka @ 2006-07-20 10:12 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git, Junio C Hamano
Hello,
with this patch files with spaces in their names are displayed
in the treeview of gitk.
I use git to make a "backup"/"dump" of a DOS-FS .. and there are
those filenames ;-).
Take care .. it's my first tcl hack!
Thomas
--
diff --git a/gitk b/gitk
index ba4644f..93af19c 100755
--- a/gitk
+++ b/gitk
@@ -3938,7 +3938,7 @@ proc gettreeline {gtf id} {
while {[gets $gtf line] >= 0} {
if {[lindex $line 1] ne "blob"} continue
set sha1 [lindex $line 2]
- set fname [lindex $line 3]
+ set fname [join [lrange $line 3 end]]
lappend treefilelist($id) $fname
lappend treeidlist($id) $sha1
}
@@ -4147,7 +4147,7 @@ proc gettreediffline {gdtf ids} {
}
return
}
- set file [lindex $line 5]
+ set file [join [lrange $line 5 end]]
lappend treediff $file
}
--
Der GMX SmartSurfer hilft bis zu 70% Ihrer Onlinekosten zu sparen!
Ideal für Modem und ISDN: http://www.gmx.net/de/go/smartsurfer
^ permalink raw reply related
* Re: [PATCH] tar-tree: add the "tar.applyUmask" config option
From: Willy Tarreau @ 2006-07-20 9:55 UTC (permalink / raw)
To: Rogan Dawes; +Cc: git
In-Reply-To: <44BF507A.4080801@dawes.za.net>
On Thu, Jul 20, 2006 at 11:44:26AM +0200, Rogan Dawes wrote:
> Willy Tarreau wrote:
> >+int git_tar_config(const char *var, const char *value)
> >+{
> >+ if (!strcmp(var, "tar.umask")) {
> >+ if (!strcmp(value, "user")) {
> >+ tar_umask = umask(0);
> >+ umask(tar_umask);
> >+ } else {
> >+ tar_umask = git_config_int(var, value);
>
> Looks like you forgot:
> umask(tar_umask);
not at all : we don't want to change the process's umask, but set the
mask that will be used to position file modes in the output archive.
The reason for umask(tar_umask) above is because you cannot read the
process umask without changing it, so you have to do it twice with a
dummy value first.
> >+ }
> >+ return 0;
> >+ }
> >+ return git_default_config(var, value);
> >+}
>
> Or else move it to just before the "return 0;" line.
>
> Rogan
Regards,
Willy
^ permalink raw reply
* Re: [PATCH] tar-tree: add the "tar.applyUmask" config option
From: Rogan Dawes @ 2006-07-20 9:44 UTC (permalink / raw)
To: Willy Tarreau; +Cc: git
In-Reply-To: <20060720093044.GA10824@1wt.eu>
Willy Tarreau wrote:
> +int git_tar_config(const char *var, const char *value)
> +{
> + if (!strcmp(var, "tar.umask")) {
> + if (!strcmp(value, "user")) {
> + tar_umask = umask(0);
> + umask(tar_umask);
> + } else {
> + tar_umask = git_config_int(var, value);
Looks like you forgot:
umask(tar_umask);
> + }
> + return 0;
> + }
> + return git_default_config(var, value);
> +}
Or else move it to just before the "return 0;" line.
Rogan
^ permalink raw reply
* Re: [PATCH] tar-tree: add the "tar.applyUmask" config option
From: Willy Tarreau @ 2006-07-20 9:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5c1jkc3.fsf@assigned-by-dhcp.cox.net>
Hi Junio,
On Wed, Jul 19, 2006 at 03:33:48PM -0700, Junio C Hamano wrote:
> Willy Tarreau <w@1wt.eu> writes:
>
> > While I agreed with Linus that the very permissive file modes set in tar
> > archives were not particularly a problem for kernel users, I'm finding
> > that for some other projects it sometimes becomes really annoying, to
> > the point that I finally considered using a plain tar instead. This is a
> > shame because tar-tree is really fast an powerful, and I like its ability
> > to enforce permissions when those of the local dir might be wrong for
> > various reasons.
>
> I do not have problem with an option to allow a non-default
> behaviour in this area. Maybe we might want to be able to set
> the mask in the configuration file as well, perhaps like...
>
> tar.umask = user ;# use from the current process'
> tar.umask = 0 ;# same as default
> tar.umask = 002 ;# group friendly
Here's the new version following your suggestion above. I really liked it.
I've also added a configuration example in the doc. Once again, please
ensure that the doc generates correctly.
Thanks,
Willy
>From d8a0d2bbd2365b719a7f68edd78c77a0fd903cab Mon Sep 17 00:00:00 2001
From: Willy Tarreau <w@1wt.eu>
Date: Thu, 20 Jul 2006 11:23:40 +0200
Subject: tar-tree: add the "tar.umask" config option
By default, git-tar-tree(1) sets file and directories modes to 0666
or 0777. While this is both useful and acceptable for projects such
as the Linux Kernel, it might be excessive for other projects. With
this variable, it becomes possible to tell git-tar-tree(1) to apply
a specific umask to the modes above. The special value "user"
indicates that the user's current umask will be used. This should be
enough for most projects, as it will lead to the same permissions as
git-checkout(1) would use. The default value remains 0, which means
world read-write.
Signed-off-by: Willy Tarreau <w@1wt.eu>
---
Documentation/config.txt | 11 +++++++++++
Documentation/git-tar-tree.txt | 15 ++++++++++++++-
builtin-tar-tree.c | 21 ++++++++++++++++++---
3 files changed, 43 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 0b434c1..f4985d4 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -208,6 +208,17 @@ showbranch.default::
The default set of branches for gitlink:git-show-branch[1].
See gitlink:git-show-branch[1].
+tar.umask::
+ By default, git-link:git-tar-tree[1] sets file and directories modes
+ to 0666 or 0777. While this is both useful and acceptable for projects
+ such as the Linux Kernel, it might be excessive for other projects.
+ With this variable, it becomes possible to tell
+ git-link:git-tar-tree[1] to apply a specific umask to the modes above.
+ The special value "user" indicates that the user's current umask will
+ be used. This should be enough for most projects, as it will lead to
+ the same permissions as git-link:git-checkout[1] would use. The default
+ value remains 0, which means world read-write.
+
user.email::
Your email address to be recorded in any newly created commits.
Can be overridden by the 'GIT_AUTHOR_EMAIL' and 'GIT_COMMITTER_EMAIL'
diff --git a/Documentation/git-tar-tree.txt b/Documentation/git-tar-tree.txt
index f2675c4..7a99acf 100644
--- a/Documentation/git-tar-tree.txt
+++ b/Documentation/git-tar-tree.txt
@@ -37,7 +37,20 @@ OPTIONS
Instead of making a tar archive from local repository,
retrieve a tar archive from a remote repository.
-Examples
+CONFIGURATION
+-------------
+By default, file and directories modes are set to 0666 or 0777. It is
+possible to change this by setting the "umask" variable in the
+repository configuration as follows :
+
+[tar]
+ umask = 002 ;# group friendly
+
+The special umask value "user" indicates that the user's current umask
+will be used instead. The default value remains 0, which means world
+readable/writable files and directories.
+
+EXAMPLES
--------
git tar-tree HEAD junk | (cd /var/tmp/ && tar xf -)::
diff --git a/builtin-tar-tree.c b/builtin-tar-tree.c
index f2e48aa..e5aaded 100644
--- a/builtin-tar-tree.c
+++ b/builtin-tar-tree.c
@@ -20,6 +20,7 @@ static char block[BLOCKSIZE];
static unsigned long offset;
static time_t archive_time;
+static int tar_umask;
/* tries hard to write, either succeeds or dies in the attempt */
static void reliable_write(const void *data, unsigned long size)
@@ -188,13 +189,13 @@ static void write_entry(const unsigned c
} else {
if (S_ISDIR(mode)) {
*header.typeflag = TYPEFLAG_DIR;
- mode |= 0777;
+ mode = (mode | 0777) & ~tar_umask;
} else if (S_ISLNK(mode)) {
*header.typeflag = TYPEFLAG_LNK;
mode |= 0777;
} else if (S_ISREG(mode)) {
*header.typeflag = TYPEFLAG_REG;
- mode |= (mode & 0100) ? 0777 : 0666;
+ mode = (mode | ((mode & 0100) ? 0777 : 0666)) & ~tar_umask;
} else {
error("unsupported file mode: 0%o (SHA1: %s)",
mode, sha1_to_hex(sha1));
@@ -293,6 +294,20 @@ static void traverse_tree(struct tree_de
}
}
+int git_tar_config(const char *var, const char *value)
+{
+ if (!strcmp(var, "tar.umask")) {
+ if (!strcmp(value, "user")) {
+ tar_umask = umask(0);
+ umask(tar_umask);
+ } else {
+ tar_umask = git_config_int(var, value);
+ }
+ return 0;
+ }
+ return git_default_config(var, value);
+}
+
static int generate_tar(int argc, const char **argv, char** envp)
{
unsigned char sha1[20], tree_sha1[20];
@@ -305,7 +320,7 @@ static int generate_tar(int argc, const
current_path.len = current_path.eof = 0;
setup_git_directory();
- git_config(git_default_config);
+ git_config(git_tar_config);
switch (argc) {
case 3:
--
1.4.1
^ permalink raw reply related
* [PATCH] git-svn: fix fetching new directories copies when using SVN:: libs
From: Eric Wong @ 2006-07-20 8:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Ben Williamson, git
In-Reply-To: <20060720034841.GA28298@localdomain>
Log output from SVN doesn't list all the new files that were
added if a new directory was copied from an existing place in
the repository. This means we'll have to do some extra work and
traverse new directories ourselves.
This has been updated from the original patch to defer traversed
adds until all removals have been done. Please disregard the
original.
Thanks to Ben Williamson for the excellent bug report and
testing.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 23 ++++++++++++++++-------
1 files changed, 16 insertions(+), 7 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 89ad840..6453771 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2709,6 +2709,12 @@ sub libsvn_fetch {
} else {
die "Unrecognized action: $m, ($f r$rev)\n";
}
+ } elsif ($t == $SVN::Node::dir && $m =~ /^[AR]$/) {
+ my @traversed = ();
+ libsvn_traverse($gui, '', $f, $rev, \@traversed);
+ foreach (@traversed) {
+ push @amr, [ $m, $_ ]
+ }
}
$pool->clear;
}
@@ -2778,7 +2784,7 @@ sub libsvn_parse_revision {
}
sub libsvn_traverse {
- my ($gui, $pfx, $path, $rev) = @_;
+ my ($gui, $pfx, $path, $rev, $files) = @_;
my $cwd = "$pfx/$path";
my $pool = SVN::Pool->new;
$cwd =~ s#^/+##g;
@@ -2786,10 +2792,15 @@ sub libsvn_traverse {
foreach my $d (keys %$dirent) {
my $t = $dirent->{$d}->kind;
if ($t == $SVN::Node::dir) {
- libsvn_traverse($gui, $cwd, $d, $rev);
+ libsvn_traverse($gui, $cwd, $d, $rev, $files);
} elsif ($t == $SVN::Node::file) {
- print "\tA\t$cwd/$d\n" unless $_q;
- libsvn_get_file($gui, "$cwd/$d", $rev);
+ my $file = "$cwd/$d";
+ if (defined $files) {
+ push @$files, $file;
+ } else {
+ print "\tA\t$file\n" unless $_q;
+ libsvn_get_file($gui, $file, $rev);
+ }
}
}
$pool->clear;
@@ -2913,9 +2924,7 @@ sub libsvn_new_tree {
}
my ($paths, $rev, $author, $date, $msg) = @_;
open my $gui, '| git-update-index -z --index-info' or croak $!;
- my $pool = SVN::Pool->new;
- libsvn_traverse($gui, '', $SVN_PATH, $rev, $pool);
- $pool->clear;
+ libsvn_traverse($gui, '', $SVN_PATH, $rev);
close $gui or croak $?;
return libsvn_log_entry($rev, $author, $date, $msg);
}
--
1.4.1.g9d8f
^ permalink raw reply related
* Re: [PATCH] tar-tree: add the "tar.applyUmask" config option
From: Rene Scharfe @ 2006-07-20 8:14 UTC (permalink / raw)
To: Willy Tarreau; +Cc: Junio C Hamano, git, torvalds
In-Reply-To: <20060719214025.GA10997@1wt.eu>
Hi Willy,
I kind of like the change, because it gives the user more control.
Theoretically this would not be needed, because tar can apply the
umask at extract time just fine. In practice I can't see why we
should forbid users from creating the archives just the way they
like them, no matter what their reasoning might be.
Willy Tarreau schrieb:
> +tar.applyUmask::
> + By default, git-link:git-tar-tree[1] sets file and directories modes
> + to 0666 or 0777. While this is both useful and acceptable for projects
> + such as the Linux Kernel, it might be excessive for other projects.
> + Setting this variable to true makes git-link:git-tar-tree[1] apply the
> + umask to the modes above. This should be enough for most projects, as
> + it will lead to the same permissions as git-link:git-checkout[1] would
> + use. The default is false.
Comments about why this change is needed and that it is sufficient
should go into the commit message. For the rest of the patch:
Acked-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
^ permalink raw reply
* Re[3]: hi from Mary B.
From: Marinka B. @ 2006-07-20 7:59 UTC (permalink / raw)
To: Jens
Hello, Jens
I think we had correspondence a long time ago if it was not you I am sorry.
If it was I could not answer you because my Mozilla mail manager was down for a
long time and I could not fix it only with my friend's help I got the emails
address out for me ..:)
I hope it was whom we were corresponded with you are still interested, as I am,
though I realize much time has passed since then...
I really don't know where to start ....
Maybe you could tell me a little about yourself since I lost our early letters,
your appearance,age , hobbies, and are you still in the search?
If it was you I wrote to and you are interested to get to know me better, I have
a profile at :
http://iamsearching-forlove.com/
Don't really know what else to say for now I hope this is the right address
Let me know if you are interested, And I hope
you won't run when you see my picture :-)
ta-ta!!
Marinka B.
If you think that you were subscribed by mistake for this mail
delivery or if your email has been added without your permission,
please, visit http://iamsearching-forlove.com/ and unsubscribe from our mails.
^ permalink raw reply
* Re: [PATCH] Re: git-svn: Missing files
From: Ben Williamson @ 2006-07-20 5:51 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060720034841.GA28298@localdomain>
On 7/20/06, Eric Wong <normalperson@yhbt.net> wrote:
> Ben, can you please try this patch against the git-svn.perl file in
> master? You can also find the full patched file here:
>
> http://git-svn.bogomips.org/git-svn.perl
Just finished, and the results were heaps better, but it seems
package/dhcp/Config.in was still missed. (The others below are empty
directories.)
$ diff -ur --exclude=.git --exclude=.svn svn-export/buildroot
git-svn-fetch-fixed/buildroot
Only in svn-export/buildroot/package/dhcp: Config.in
Only in svn-export/buildroot/package: linux
Only in svn-export/buildroot/target/generic: access_point
Only in svn-export/buildroot/target/generic: firewall
Hey, good enough for me, but then I'm not using dhcp... ;)
- Ben.
^ permalink raw reply
* Re: git-svn: Missing files
From: Ben Williamson @ 2006-07-20 4:31 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20060720024815.GC31763@localdomain>
Wow, I just got back from lunch to three replies and a patch! I'll try
to keep up here...
On 7/20/06, Eric Wong <normalperson@yhbt.net> wrote:
> May I ask if you have the Perl SVN:: library bindings installed? If so
> 1.1.1-broken (and all versions afterwards) will automatically. use them
> (if the SVN library version is >= 1.1).
Yes I have Perl SVN:: installed, because I started off trying
git-svnimport. (Most of my attempts there resulted in lots of commits
of the same empty tree, until someone else on this list mentioned that
"trunk/projectname" should be removed from the url. Then it started
working, but it seems to be a large repo and was taking forever, so I
tried git-svn.) I didn't realise git-svn didn't need the Perl stuff.
$ rpm -qa | grep subversion
subversion-1.2.1-0.1.1.fc3.rf
subversion-perl-1.2.1-0.1.1.fc3.rf
> Nevertheless, I'm running an import right now (with the SVN:: libraries enabled)
> and will make another run with them disabled (which is kind of slow).
> I'll keep you posted...
Me too, with your latest script - will let you know. Thanks!
- Ben.
^ permalink raw reply
* [PATCH] Re: git-svn: Missing files
From: Eric Wong @ 2006-07-20 3:48 UTC (permalink / raw)
To: Ben Williamson; +Cc: git, Junio C Hamano
In-Reply-To: <b6327a230607191902n47b81993x8caea2df3955d8c0@mail.gmail.com>
Ben, can you please try this patch against the git-svn.perl file in
master? You can also find the full patched file here:
http://git-svn.bogomips.org/git-svn.perl
From: Eric Wong <normalperson@yhbt.net>
Date: Wed, 19 Jul 2006 20:42:35 -0700
Subject: [PATCH] git-svn: fix fetching new directories copies when using SVN:: libs
Log output from SVN doesn't list all the new files that were
added if a new directory was copied from an existing place in
the repository. This means we'll have to do some extra work and
traverse new directories ourselves.
Thanks to Ben Williamson for the excellent bug report.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
---
git-svn.perl | 18 +++++++++++-------
1 files changed, 11 insertions(+), 7 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 89ad840..577a284 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -2692,6 +2692,7 @@ sub libsvn_fetch {
my ($last_commit, $paths, $rev, $author, $date, $msg) = @_;
open my $gui, '| git-update-index -z --index-info' or croak $!;
my @amr;
+ my %fetched = ();
foreach my $f (keys %$paths) {
my $m = $paths->{$f}->action();
$f =~ s#^/+##;
@@ -2709,10 +2710,13 @@ sub libsvn_fetch {
} else {
die "Unrecognized action: $m, ($f r$rev)\n";
}
+ } elsif ($t == $SVN::Node::dir && $m =~ /^[AR]$/) {
+ libsvn_traverse($gui, '', $f, $rev, \%fetched);
}
$pool->clear;
}
foreach (@amr) {
+ next if $fetched{$_->[1]};
print "\t$_->[0]\t$_->[1]\n" unless $_q;
libsvn_get_file($gui, $_->[1], $rev)
}
@@ -2778,7 +2782,7 @@ sub libsvn_parse_revision {
}
sub libsvn_traverse {
- my ($gui, $pfx, $path, $rev) = @_;
+ my ($gui, $pfx, $path, $rev, $files) = @_;
my $cwd = "$pfx/$path";
my $pool = SVN::Pool->new;
$cwd =~ s#^/+##g;
@@ -2786,10 +2790,12 @@ sub libsvn_traverse {
foreach my $d (keys %$dirent) {
my $t = $dirent->{$d}->kind;
if ($t == $SVN::Node::dir) {
- libsvn_traverse($gui, $cwd, $d, $rev);
+ libsvn_traverse($gui, $cwd, $d, $rev, $files);
} elsif ($t == $SVN::Node::file) {
- print "\tA\t$cwd/$d\n" unless $_q;
- libsvn_get_file($gui, "$cwd/$d", $rev);
+ my $file = "$cwd/$d";
+ print "\tA\t$file\n" unless $_q;
+ libsvn_get_file($gui, $file, $rev);
+ $files->{$file} = 1 if defined $files;
}
}
$pool->clear;
@@ -2913,9 +2919,7 @@ sub libsvn_new_tree {
}
my ($paths, $rev, $author, $date, $msg) = @_;
open my $gui, '| git-update-index -z --index-info' or croak $!;
- my $pool = SVN::Pool->new;
- libsvn_traverse($gui, '', $SVN_PATH, $rev, $pool);
- $pool->clear;
+ libsvn_traverse($gui, '', $SVN_PATH, $rev);
close $gui or croak $?;
return libsvn_log_entry($rev, $author, $date, $msg);
}
--
1.4.1.g9d8f
^ permalink raw reply related
* Re: git-svn: Missing files
From: Eric Wong @ 2006-07-20 3:06 UTC (permalink / raw)
To: Ben Williamson; +Cc: git
In-Reply-To: <20060720024815.GC31763@localdomain>
Eric Wong <normalperson@yhbt.net> wrote:
> Ben Williamson <benw@pobox.com> wrote:
> > Oh. I just looked in git-svn and found this:
> >
> > $VERSION = '1.1.1-broken';
>
> Nevertheless, I'm running an import right now (with the SVN:: libraries enabled)
> and will make another run with them disabled (which is kind of slow).
> I'll keep you posted...
Ok, I think I've found the problem. This problem only happens if you're
using the SVN:: libraries, right?
--
Eric Wong
^ 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