* 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
* [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: 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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
* 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: Alex Riesen @ 2006-07-21 7:08 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Robin Luckey, git
In-Reply-To: <Pine.LNX.4.64.0607201944460.29649@g5.osdl.org>
On 7/21/06, Linus Torvalds <torvalds@osdl.org> wrote:
> > 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 --
>
That'd be not enough for kernel after it was compiled.
Maybe this:
find . -maxdepth 1 -not -name .git -not -name . -print0 | xargs -0 rm -rf --
^ permalink raw reply
* Re: Unanticipated test error
From: Alex Riesen @ 2006-07-21 7:22 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20060720194013.GC24793@bohr.gbar.dtu.dk>
On 7/20/06, Peter Eriksen <s022018@student.dtu.dk> wrote:
> 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.
>
Well, there are differences. Correct translation from memcpy
to strlcpy (aside the fact with \0 inside the string) would be
something like:
strlcpy(to, from, len + 1);
assuming your example with memcpy. strlcpy expects size of
storage, and will never write more bytes that it was allowed to.
That'll cut off last character of the source string, unless it is
\0-terminated before the size of storage.
^ permalink raw reply
* Re: Unanticipated test error
From: Peter Eriksen @ 2006-07-21 8:19 UTC (permalink / raw)
To: git
In-Reply-To: <81b0412b0607210022o562ac326wd149c73cc529f239@mail.gmail.com>
On Fri, Jul 21, 2006 at 09:22:44AM +0200, Alex Riesen wrote:
...
> Well, there are differences. Correct translation from memcpy
> to strlcpy (aside the fact with \0 inside the string) would be
> something like:
>
> strlcpy(to, from, len + 1);
>
> assuming your example with memcpy. strlcpy expects size of
> storage, and will never write more bytes that it was allowed to.
> That'll cut off last character of the source string, unless it is
> \0-terminated before the size of storage.
I see it now. What I did was wrong. Appending " + 1" to every
one of my calls makes the patch survive "make test". However,
since strlcpy() calls strlen(from), it would have to be checked,
that 'from' is always NUL terminated. The benefits of this patch
seem to shrink.
Thank you for your comment!
Peter
^ permalink raw reply
* Re: git clone / SHA1 mismatch
From: Johannes Schindelin @ 2006-07-21 8:37 UTC (permalink / raw)
To: Mika Muukkonen; +Cc: git
In-Reply-To: <007e01c6ac81$d523a700$76401f0a@almare2.tre>
Hi,
On Fri, 21 Jul 2006, Mika Muukkonen wrote:
> 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)
This sounds like you had a timeout before the complete pack was
transmitted (the Deltifying takes place on the other side).
Hth,
Dscho
^ permalink raw reply
* The ingredients in Fatblaster assist in the thermogenic processes allowing you to naturally and safely burn fat and loose unwanted weight.
From: Sumner @ 2006-07-21 10:05 UTC (permalink / raw)
To: godard
Dear valued customer.
The ingredients in Fatblaster assist in the thermogenic processes allowing you to naturally and safely burn fat and loose unwanted weight. One way to reduce energy intake and absorption is through thermogenic formulas such as the ingredients found in Fatblaster. Supplement your life today! Join thousands of satisfied customers and experience for yourself the proven benefits of Fatblaster. Check up here: http://yeltren.com/gal/fb/
The best doctors are Dr Diet, Dr Quiet and Dr Merryman Good broth may be made in an old pot Men are from earth Women are from earth Deal with it
For the commandment is a lamp; and the law is light; and reproofs of instruction are the way of life. Wisdom crieth without; she uttereth her voice in the streets. Imagination is the highest kite you can fly Age before beauty
^ permalink raw reply
* Re: [PATCH] Display "gitweb/test/file with spaces" in gitk
From: Paul Mackerras @ 2006-07-21 13:01 UTC (permalink / raw)
To: Thomas Kolejka; +Cc: git, Junio C Hamano
In-Reply-To: <20060720101223.116320@gmx.net>
Thomas Kolejka writes:
> 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 ;-).
Hmmm, certainly my code is incorrect. However with your code, tabs in
the filename will get changed to spaces. Treating the line read from
git-ls-tree or git-diff-tree was a shortcut hack that isn't really
optimal. I'll think about the best way to fix it.
Paul.
^ permalink raw reply
* Re: Git BOF notes
From: J. Bruce Fields @ 2006-07-21 13:18 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060719230155.GJ13776@pasky.or.cz>
On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:
> (i) We should somehow separate the lowlevel Git commands from the
> highlevel ones meant for user consumption. There's too many of them
> and it is confusing for the users. Similarity with BitKeeper was pointed
> out (and I refrained from mentioning GNU Arch).
The man page already attempts to make this distinction in its command
list, though arguably the order is wrong (it lists the low-level
commands first) and you could argue about some of the choices (git
init-db may be "low level", but it's something everyone probably wants
to see).
"git help" already has an abbreviated list. What else could we do?
--b.
^ permalink raw reply
* Re: Git BOF notes
From: J. Bruce Fields @ 2006-07-21 13:21 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <20060719230155.GJ13776@pasky.or.cz>
On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:
> * Support for distributing and following the mutated history.
> I'm actually not sure about the level of Git support for
> this, Cogito supports cg-updating to a mutated history
> if you have no local changes.
A fetch that doesn't fast-forward fails with a warning unless you
explicitly ask it (--force) to blow away your old history.
I don't see what more you could do.
--b.
^ permalink raw reply
* Re: Git BOF notes
From: Petr Baudis @ 2006-07-21 14:31 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060721132111.GD32585@fieldses.org>
Dear diary, on Fri, Jul 21, 2006 at 03:21:11PM CEST, I got a letter
where "J. Bruce Fields" <bfields@fieldses.org> said that...
> On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:
> > * Support for distributing and following the mutated history.
> > I'm actually not sure about the level of Git support for
> > this, Cogito supports cg-updating to a mutated history
> > if you have no local changes.
>
> A fetch that doesn't fast-forward fails with a warning unless you
> explicitly ask it (--force) to blow away your old history.
I don't know if there's a point in being so paranoid - it already makes
things more painful than necessary. In the tracking branch, you just
want to have what the other side has anyway, and if the other side
decided to jump around, why would you care otherwise?
Just make sure you print the original commit ID and perhaps a warning.
> I don't see what more you could do.
I guess a huge majority of Git users is an - almost inherently - silent
mass of those who just use Git for tracking the development of others,
and we gotta make it easy for them - and it's not easy if when the
remote side rebases it doesn't just move them to the new commit but
helpfully offers a nonsensical three-way merge.
--
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
* Re: Git BOF notes
From: Petr Baudis @ 2006-07-21 14:42 UTC (permalink / raw)
To: J. Bruce Fields; +Cc: git
In-Reply-To: <20060721131824.GC32585@fieldses.org>
Dear diary, on Fri, Jul 21, 2006 at 03:18:24PM CEST, I got a letter
where "J. Bruce Fields" <bfields@fieldses.org> said that...
> On Thu, Jul 20, 2006 at 01:01:55AM +0200, Petr Baudis wrote:
> > (i) We should somehow separate the lowlevel Git commands from the
> > highlevel ones meant for user consumption. There's too many of them
> > and it is confusing for the users. Similarity with BitKeeper was pointed
> > out (and I refrained from mentioning GNU Arch).
>
> The man page already attempts to make this distinction in its command
> list, though arguably the order is wrong (it lists the low-level
> commands first) and you could argue about some of the choices (git
> init-db may be "low level", but it's something everyone probably wants
> to see).
>
> "git help" already has an abbreviated list. What else could we do?
Perhaps (while coordinating with the porcelains, of course) we should
start moving the lowlevel tools to the libexec directory and keep only
the end-user tools around.
Yes, there is some blury stuff, but I think it's rather a sign that
something is missing in the core Git porcelain. git-init-db is lowlevel
and I think in 99% of the cases you are going to do an initial commit
right after anyway, so you might as well just get git-init which does it
for you (something akin cg-init ;). I think we still tell users to use
git-update-index to mark resolved conflicts, but all the Git people at
OLS were too afraid to even _mention_ the index to the users at all;
shouldn't we have git-resolved instead?
Oh well, except that people are gonna run git-resolve instead all the
time. Why do we still _have_ that one?
--
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
* [RFC/PATCH] Per branch properties for pull
From: Santi Béjar @ 2006-07-21 14:51 UTC (permalink / raw)
To: Git Mailing List
It extracts all the information for pull from the config file.
If you have a config file as:
[branch "master"]
remote=origin
merge=next #the remote name
octopus=octopus
twohead=recursive
When doing a "git pull" without extra parameters in the master branch
it will fetch the origin remote repository and will merge the next
branch (the remote name).
And you can also put the equivalent of the pull.{octopus,twohead}
options for each branch.
This only changes the behavour when these keys exist and when
git-pull is used without extra parameters.
Signed-off-by: Santi Béjar <sbejar@gmail.com>
---
Hi *,
Now that we have the arbitrary keys in the config file...
It does not affect the integrator that pulls from different
places. I don't know exactly what is needed but just for discuss it
could be something as:
[branch "master"]
remote=net
remote=ata
merge=for-linus from ata
merge=upstream from net
diff --git a/git-pull.sh b/git-pull.sh
index f380437..e7630b1 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -44,6 +44,14 @@ do
shift
done
+if [ $# -eq 0 ] ; then
+ default=yes
+ curr_branch=$(git-symbolic-ref HEAD)
+ curr_branch=${curr_branch##refs/heads/}
+ remote=$(git-repo-config --get "branch.$curr_branch.remote")
+ test "$remote" && set x "$remote" && shift
+fi
+
orig_head=$(git-rev-parse --verify HEAD) || die "Pulling into a black hole?"
git-fetch --update-head-ok --reflog-action=pull "$@" || exit 1
@@ -70,9 +78,19 @@ to recover.'
fi
+if [ "$default" == yes ] ; then
+ merge_head=$(git repo-config --get-all "branch.$curr_branch.merge")
+ for ref in $merge_head ; do
+ refspec=$(git-repo-config --get "remote.$remote.fetch" "^$ref:")
+ [ -z "$refspec" ] && die "Branch $ref does not exist in the repository: $remote."
+ locref="$locref ${refspec##$ref:}"
+ done
+ merge_head=$locref
+else
merge_head=$(sed -e '/ not-for-merge /d' \
-e 's/ .*//' "$GIT_DIR"/FETCH_HEAD | \
tr '\012' ' ')
+fi
case "$merge_head" in
'')
@@ -85,6 +103,11 @@ case "$merge_head" in
then
strategy_default_args="-s $var"
fi
+ var=`git-repo-config --get branch.$curr_branch.octopus`
+ if test -n "$var"
+ then
+ strategy_default_args="-s $var"
+ fi
;;
*)
var=`git-repo-config --get pull.twohead`
@@ -92,6 +115,11 @@ case "$merge_head" in
then
strategy_default_args="-s $var"
fi
+ var=`git-repo-config --get branch.$curr_branch.twohead`
+ if test -n "$var"
+ then
+ strategy_default_args="-s $var"
+ fi
;;
esac
^ permalink raw reply related
* Re: Unanticipated test error
From: Alex Riesen @ 2006-07-21 14:54 UTC (permalink / raw)
To: Peter Eriksen; +Cc: git
In-Reply-To: <20060721081954.GA29645@bohr.gbar.dtu.dk>
On 7/21/06, Peter Eriksen <s022018@student.dtu.dk> wrote:
> ...
> > Well, there are differences. Correct translation from memcpy
> > to strlcpy (aside the fact with \0 inside the string) would be
> > something like:
> >
> > strlcpy(to, from, len + 1);
> >
> > assuming your example with memcpy. strlcpy expects size of
> > storage, and will never write more bytes that it was allowed to.
> > That'll cut off last character of the source string, unless it is
> > \0-terminated before the size of storage.
>
> I see it now. What I did was wrong. Appending " + 1" to every
> one of my calls makes the patch survive "make test". However,
> since strlcpy() calls strlen(from), it would have to be checked,
> that 'from' is always NUL terminated. The benefits of this patch
> seem to shrink.
Probably, but you still have room to balance benefits.
^ permalink raw reply
* Never-seen Order it on-line and impress your girlfriend with your wonderful shooting
From: Sandy @ 2006-07-21 14:55 UTC (permalink / raw)
To: godard
How are u?
Prolong your ssex. You have smalll peniis? Add 3 inches in lenght! Check up here: http://www.ollyert.com/gal/ms/
Better an open enemy, than a false friend True love never grows old Pain is so close to pleasure Murder will out
^ permalink raw reply
* Makefile checks for DarwinPorts / Fink
From: Stefan Pfetzing @ 2006-07-21 14:58 UTC (permalink / raw)
To: Git Mailing List
Hi,
while I was updating the DarwinPorts Portfile for git, I saw some
really suspicious lines in the Makefile of Git for DarwinPorts/Fink.
--- snip ---
## fink
ifeq ($(shell test -d /sw/lib && echo y),y)
ALL_CFLAGS += -I/sw/include
ALL_LDFLAGS += -L/sw/lib
endif
## darwinports
ifeq ($(shell test -d /opt/local/lib && echo y),y)
ALL_CFLAGS += -I/opt/local/include
ALL_LDFLAGS += -L/opt/local/lib
endif
--- snap ---
IMHO, Git should definetely not include /sw/include and /sw/lib, just
if it *exists*.
Think of a situation, when somebody has Fink and DarwinPorts installed
on one machine (possible). Then if you would build Git from
DarwinPorts, the git Makefile would link against Fink libraries! IMHO
the DarwinPorts / Fink build process should set LDFLAGS and CFLAGS
accordingly.
Also, maybe you want to create a DarwinPorts / Fink independent Mac OS
X pkg which contains Git and its deps.
I know this just appends to CFLAGS/LDFLAGS, but if for example
DarwinPorts has broken build-deps, then the Fink stuff would get
sucked in, and you would not notice. (on a box with both, DP and Fink
installed)
bye
Stefan
--
http://www.dreamind.de/
Oroborus and Debian GNU/Linux Developer.
^ 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