* Re: Possibility of a MinGW version?
From: Sven Verdoolaege @ 2005-12-24 10:18 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Rob McDonald, git
In-Reply-To: <43AD1E63.4040103@op5.se>
On Sat, Dec 24, 2005 at 11:09:39AM +0100, Andreas Ericsson wrote:
> The worst trouble you're likely to run into is all the hardcoded paths.
> They are everywhere and ofcourse use the / for path entity separation.
AFAIR, '/' is a valid path separator on Windows.
It's just command.com (does that still exist?) that insisted on '\\'
separators.
> The fact that there are 39 bash'ish shell-scripts does little to help a
> native port, and although they can be fairly easily replaced by "real"
> programs it still means quite a bit of work with little real value for
> the unix-version, so I'm guessing you'll have to write those up for
> yourself.
Or just use MinGW's bash.
skimo
^ permalink raw reply
* Re: [ANNOUNCE] GIT 1.0.0b quickfix
From: Andreas Ericsson @ 2005-12-24 10:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Ingo Oeser, linux-kernel, Linus Torvalds, Benjamin Herrenschmidt,
H. Peter Anvin, git
In-Reply-To: <7vu0cyu8vj.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
>
> *1* Which one is the heaviest, 5h, 3kg, or 20cm?
>
5h, without a doubt. Because time can be broken down into infinitely
small pieces and encompasses all the matter in the universe it will
always be heavier and larger than any measurement relating to 3
dimensions or less.
Beware of rhetorical questions around people with hangovers in a
philosohopical mood. ;)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Possibility of a MinGW version?
From: Andreas Ericsson @ 2005-12-24 10:09 UTC (permalink / raw)
To: Rob McDonald; +Cc: git
In-Reply-To: <006c01c60832$86f92620$6900a8c0@sps>
Rob McDonald wrote:
> 1.0 is out the door, with support (to some degree or another) for Cygwin,
> BSD, MacOS X, Solaris, and who knows what else, good job all.
>
> What possibility is there of getting git (& assorted tools) to run natively
> on Windows (sacrilege I know) using MinGW? What truly Unixy-only things
> does the code do? Unfortunately, Windows is a reality for many of us.
>
> I'd like to begin experimenting using git to track all of my data files
> acting as a synchronization mechanism. Have all your files up-to-date
> everywhere, revision tracking, & redundancy too... Dedicated Linux
> repository at home, dual boot laptop on the road, Windows machine at work,
> etc...
>
> Thoughts? Suggestions?
>
The worst trouble you're likely to run into is all the hardcoded paths.
They are everywhere and ofcourse use the / for path entity separation.
The fact that there are 39 bash'ish shell-scripts does little to help a
native port, and although they can be fairly easily replaced by "real"
programs it still means quite a bit of work with little real value for
the unix-version, so I'm guessing you'll have to write those up for
yourself.
Is there some reason you can't install Cygwin, which effectively
overcomes both those problems?
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Require packfiles to follow the naming convention.
From: Junio C Hamano @ 2005-12-24 10:03 UTC (permalink / raw)
To: git
In-Reply-To: <7vd5jmvnkc.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> * require packfiles to follow the naming convention more strictly.
>
> This rejects a packfile whose name does not begin with
> "pack-" followed by 40-byte hexadecimal digits. The core
> never had such limitation (the only thing it required was
> that the pack and the idx are named with the same basename
> with .pack and .idx extention), but the way http-fetch
> handles packs requires this.
> ...
> This is probably controversial because it would eventually
> require users to rename their packs created using pre v0.99.9
> tools. There is a small utility program that helps the
> conversion process, so it may not be that painful.
And this is the patch in question. When your packs are the ones
produced by pre v0.99.9 tools, you can ask git-convert-packs to
suggest you the "right name" to use.
$ git-convert-packs
warning: index name '.git/objects/pack/pack-a3b60db8bb6dad970f6dcdc03b0addf3988e8556.idx' does not match contents of the pack '83b60db8bb6dad970f6dcdc03b0addf3988e8556'
# Packname does not match contents.
mv '.git/objects/pack/pack-a3b60db8bb6dad970f6dcdc03b0addf3988e8556.pack' '.git/objects/pack/pack-83b60db8bb6dad970f6dcdc03b0addf3988e8556.pack'
mv '.git/objects/pack/pack-a3b60db8bb6dad970f6dcdc03b0addf3988e8556.idx' '.git/objects/pack/pack-83b60db8bb6dad970f6dcdc03b0addf3988e8556.idx'
$ git-convert-packs | sh
warning: index name '.git/objects/pack/pack-a3b60db8bb6dad970f6dcdc03b0addf3988e8556.idx' does not match contents of the pack '83b60db8bb6dad970f6dcdc03b0addf3988e8556'
$ git-convert-packs
$ exit
Comments?
-- >8 --
Pack files names are required to be "pack-[0-9a-f]{40}.pack",
with corresponding .idx file. This is not strictly needed at
the core level, but the packed file transfer over HTTP relies on
this format. With this commit, the core would ignore otherwise
a valid packfile in .git/objects/packs that "git-unpack-objects"
would expand properly, if it does not follow the naming
convention.
The hexadecimal part should be what git-pack-objects computed
when the pack was created originally, and it is the SHA1 sum
over sorted object names (i.e. 20-byte binary SHA1 checksum
each). However, this condition is checked but not enforced
currently, because git-pack-objects before v0.99.9 computed a
checksum over object names without sorting (i.e. the order
git-rev-list fed the object names), just to make pack names
unlikely to collide. This made less than ideal use of SHA1 sum
to name packs, which we would want to rectify in the future.
Many packfiles in the wild were created with git before v0.99.9,
so the check would trigger and will give a warning message like
this:
warning: index name '.git/objects/pack/pack-3b60db8....idx' does
not match contents of the pack '83b60db...'
You can rename the existing pack that has this old name
(3b60db8...) to new name (83b60db...) to squelch this warning
message. For that, a new command git-convert-packs is provided
to produce suitable "mv" command you can paste into your shell.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
.gitignore | 1 +
Makefile | 2 +
convert-packs.c | 49 ++++++++++++++++++++++++++++++
sha1_file.c | 41 ++++++++++++++++++++++++-
t/t5300-pack-object.sh | 79 ++++++++++++++++++++++++++----------------------
5 files changed, 133 insertions(+), 39 deletions(-)
create mode 100644 convert-packs.c
9c9f23b012e4030f433c7d4260a3fae93c302a0e
diff --git a/.gitignore b/.gitignore
index 6bd508e..d713f62 100644
--- a/.gitignore
+++ b/.gitignore
@@ -18,6 +18,7 @@ git-clone-pack
git-commit
git-commit-tree
git-convert-objects
+git-convert-packs
git-count-objects
git-cvsexportcommit
git-cvsimport
diff --git a/Makefile b/Makefile
index 3395a9e..2209f97 100644
--- a/Makefile
+++ b/Makefile
@@ -121,7 +121,7 @@ SIMPLE_PROGRAMS = \
PROGRAMS = \
git-apply$X git-cat-file$X \
git-checkout-index$X git-clone-pack$X git-commit-tree$X \
- git-convert-objects$X git-diff-files$X \
+ git-convert-objects$X git-convert-packs$X git-diff-files$X \
git-diff-index$X git-diff-stages$X \
git-diff-tree$X git-fetch-pack$X git-fsck-objects$X \
git-hash-object$X git-index-pack$X git-init-db$X \
diff --git a/convert-packs.c b/convert-packs.c
new file mode 100644
index 0000000..13f5502
--- /dev/null
+++ b/convert-packs.c
@@ -0,0 +1,49 @@
+#include "cache.h"
+
+void verify_pack_name(struct packed_git *p)
+{
+ SHA_CTX ctx;
+ unsigned char sha1[20];
+ int i, nr, len;
+ const char *hex;
+
+ nr = num_packed_objects(p);
+
+ SHA1_Init(&ctx);
+ for (i = 0; i < nr; i++) {
+ unsigned char *ent = (((unsigned char *)p->index_base) +
+ 4*256 + i * 24 + 4);
+ SHA1_Update(&ctx, ent, 20);
+ }
+ SHA1_Final(sha1, &ctx);
+
+ len = strlen(p->pack_name);
+ hex = sha1_to_hex(sha1);
+ /* "pack-X{40}.pack" */
+ if (len < 50 ||
+ memcmp(p->pack_name + len - 5 - 40, hex, 40)) {
+ char *d = strrchr(p->pack_name, '/');
+ int dlen;
+
+ if (d)
+ dlen = (d - p->pack_name) + 1;
+ else
+ dlen = 0;
+ printf("# Packname does not match contents.\n");
+ printf("mv '%s' '%.*spack-%s.pack'\n",
+ p->pack_name, dlen, p->pack_name, hex);
+ printf("mv '%.*sidx' '%.*spack-%s.idx'\n",
+ len-4, p->pack_name, dlen, p->pack_name, hex);
+ }
+}
+
+int main(int ac, char **av)
+{
+ struct packed_git *p;
+
+ setup_git_directory();
+ prepare_packed_git();
+ for (p = packed_git; p; p = p->next)
+ verify_pack_name(p);
+ return 0;
+}
diff --git a/sha1_file.c b/sha1_file.c
index 6b7577d..fc24d0e 100644
--- a/sha1_file.c
+++ b/sha1_file.c
@@ -323,6 +323,7 @@ static int check_packed_git_idx(const ch
{
SHA_CTX ctx;
unsigned char sha1[20];
+ unsigned char packname[20];
void *idx_map;
unsigned int *index;
unsigned long idx_size;
@@ -337,6 +338,16 @@ static int check_packed_git_idx(const ch
close(fd);
return -1;
}
+
+ /* We require "...../pack-XXXX{40}XXXX.idx" now.
+ * 5-byte "pack-", 40-byte hex and 4-byte .idx.
+ */
+ i = strlen(path);
+ if (i < 49 || strcmp(path + i - 4, ".idx") ||
+ strncmp(path + i - 49, "pack-", 5) ||
+ get_sha1_hex(path + i - 44, packname))
+ return error("non index file %s ignored", path);
+
idx_size = st.st_size;
idx_map = mmap(NULL, idx_size, PROT_READ, MAP_PRIVATE, fd, 0);
close(fd);
@@ -369,7 +380,7 @@ static int check_packed_git_idx(const ch
return error("wrong index file size");
/*
- * File checksum.
+ * File checksum and index name.
*/
SHA1_Init(&ctx);
SHA1_Update(&ctx, idx_map, idx_size-20);
@@ -378,6 +389,34 @@ static int check_packed_git_idx(const ch
if (memcmp(sha1, idx_map + idx_size - 20, 20))
return error("index checksum mismatch");
+/*
+ * 0: do not check, do not do anything.
+ * 1: check and warn, but do not reject.
+ * 2: check and reject if pack name is obsolete.
+ */
+#define PACK_NAME_ENFORCEMENT_PHASE 1
+
+#if PACK_NAME_ENFORCEMENT_PHASE != 0
+ SHA1_Init(&ctx);
+ for (i = 0; i < nr; i++) {
+ unsigned char *ent = (idx_map + 4*256) + i * 24 + 4;
+ SHA1_Update(&ctx, ent, 20);
+ }
+ SHA1_Final(sha1, &ctx);
+
+ if (memcmp(sha1, packname, 20)) {
+#if PACK_NAME_ENFORCEMENT_PHASE == 1
+ fprintf(stderr, "warning: index name '%s' does not match "
+ "contents of the pack '%s'\n",
+ path, sha1_to_hex(sha1));
+#else
+ return error("index name '%s' does not match "
+ "contents of the pack '%s'\n",
+ path, sha1_to_hex(sha1));
+#endif
+ }
+#endif
+
return 0;
}
diff --git a/t/t5300-pack-object.sh b/t/t5300-pack-object.sh
index 7dfb1ab..dba8227 100755
--- a/t/t5300-pack-object.sh
+++ b/t/t5300-pack-object.sh
@@ -10,6 +10,8 @@ test_description='git-pack-object
TRASH=`pwd`
+mkdir test-1 test-2
+
test_expect_success \
'setup' \
'rm -f .git/index*
@@ -35,7 +37,7 @@ test_expect_success \
test_expect_success \
'pack without delta' \
- 'packname_1=$(git-pack-objects --window=0 test-1 <obj-list)'
+ 'packname_1=$(git-pack-objects --window=0 test-1/pack <obj-list)'
rm -fr .git2
mkdir .git2
@@ -45,8 +47,8 @@ test_expect_success \
"GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git-init-db &&
- git-unpack-objects -n <test-1-${packname_1}.pack &&
- git-unpack-objects <test-1-${packname_1}.pack"
+ git-unpack-objects -n <test-1/pack-${packname_1}.pack &&
+ git-unpack-objects <test-1/pack-${packname_1}.pack"
unset GIT_OBJECT_DIRECTORY
cd "$TRASH/.git2"
@@ -66,7 +68,8 @@ cd "$TRASH"
test_expect_success \
'pack with delta' \
'pwd &&
- packname_2=$(git-pack-objects test-2 <obj-list)'
+ packname_2=$(git-pack-objects test-2/pack <obj-list) &&
+ test "$packname_2" = "$packname_1"'
rm -fr .git2
mkdir .git2
@@ -76,8 +79,8 @@ test_expect_success \
'GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git-init-db &&
- git-unpack-objects -n <test-2-${packname_2}.pack &&
- git-unpack-objects <test-2-${packname_2}.pack'
+ git-unpack-objects -n <test-2/pack-${packname_2}.pack &&
+ git-unpack-objects <test-2/pack-${packname_2}.pack'
unset GIT_OBJECT_DIRECTORY
cd "$TRASH/.git2"
@@ -101,7 +104,8 @@ test_expect_success \
'GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
git-init-db &&
- cp test-1-${packname_1}.pack test-1-${packname_1}.idx .git2/objects/pack && {
+ cp test-1/pack-${packname_1}.pack test-1/pack-${packname_1}.idx \
+ .git2/objects/pack && {
git-diff-tree --root -p $commit &&
while read object
do
@@ -116,8 +120,9 @@ test_expect_success \
'use packed deltified objects' \
'GIT_OBJECT_DIRECTORY=.git2/objects &&
export GIT_OBJECT_DIRECTORY &&
- rm -f .git2/objects/pack/test-?.idx &&
- cp test-2-${packname_2}.pack test-2-${packname_2}.idx .git2/objects/pack && {
+ rm -f .git2/objects/pack/pack-* &&
+ cp test-2/pack-${packname_2}.pack test-2/pack-${packname_2}.idx \
+ .git2/objects/pack && {
git-diff-tree --root -p $commit &&
while read object
do
@@ -131,41 +136,41 @@ unset GIT_OBJECT_DIRECTORY
test_expect_success \
'verify pack' \
- 'git-verify-pack test-1-${packname_1}.idx test-2-${packname_2}.idx'
+ 'git-verify-pack test-?/pack-${packname_1}.idx'
test_expect_success \
'corrupt a pack and see if verify catches' \
- 'cp test-1-${packname_1}.idx test-3.idx &&
- cp test-2-${packname_2}.pack test-3.pack &&
- if git-verify-pack test-3.idx
+ 'cp test-1/pack-${packname_1}.idx . &&
+ cp test-2/pack-${packname_2}.pack . &&
+ if git-verify-pack pack-${packname_1}.idx
then false
else :;
fi &&
- cp test-1-${packname_1}.pack test-3.pack &&
- dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=2 &&
- if git-verify-pack test-3.idx
+ cp test-1/pack-${packname_1}.pack . &&
+ dd if=/dev/zero of=pack-${packname_1}.pack count=1 bs=1 conv=notrunc seek=2 &&
+ if git-verify-pack pack-${packname_1}.idx
then false
else :;
fi &&
- cp test-1-${packname_1}.pack test-3.pack &&
- dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=7 &&
- if git-verify-pack test-3.idx
+ cp test-1/pack-${packname_1}.pack . &&
+ dd if=/dev/zero of=pack-${packname_1}.pack count=1 bs=1 conv=notrunc seek=7 &&
+ if git-verify-pack pack-${packname_1}.idx
then false
else :;
fi &&
- cp test-1-${packname_1}.pack test-3.pack &&
- dd if=/dev/zero of=test-3.pack count=1 bs=1 conv=notrunc seek=12 &&
- if git-verify-pack test-3.idx
+ cp test-1/pack-${packname_1}.pack . &&
+ dd if=/dev/zero of=pack-${packname_1}.pack count=1 bs=1 conv=notrunc seek=12 &&
+ if git-verify-pack pack-${packname_1}.idx
then false
else :;
fi &&
- cp test-1-${packname_1}.pack test-3.pack &&
- dd if=/dev/zero of=test-3.idx count=1 bs=1 conv=notrunc seek=1200 &&
- if git-verify-pack test-3.pack
+ cp test-1/pack-${packname_1}.pack . &&
+ dd if=/dev/zero of=pack-${packname_1}.idx count=1 bs=1 conv=notrunc seek=1200 &&
+ if git-verify-pack pack-${packname_1}.idx
then false
else :;
fi &&
@@ -174,19 +179,19 @@ test_expect_success \
test_expect_success \
'build pack index for an existing pack' \
- 'cp test-1-${packname_1}.pack test-3.pack &&
- git-index-pack -o tmp.idx test-3.pack &&
- cmp tmp.idx test-1-${packname_1}.idx &&
-
- git-index-pack test-3.pack &&
- cmp test-3.idx test-1-${packname_1}.idx &&
-
- cp test-2-${packname_2}.pack test-3.pack &&
- git-index-pack -o tmp.idx test-2-${packname_2}.pack &&
- cmp tmp.idx test-2-${packname_2}.idx &&
+ 'cp test-1/pack-${packname_1}.pack unknown.pack &&
+ git-index-pack -o tmp.idx unknown.pack &&
+ cmp tmp.idx test-1/pack-${packname_1}.idx &&
+
+ git-index-pack unknown.pack &&
+ cmp unknown.idx test-1/pack-${packname_1}.idx &&
+
+ cp test-2/pack-${packname_2}.pack unknown.pack &&
+ git-index-pack -o tmp.idx unknown.pack &&
+ cmp tmp.idx test-2/pack-${packname_2}.idx &&
- git-index-pack test-3.pack &&
- cmp test-3.idx test-2-${packname_2}.idx &&
+ git-index-pack unknown.pack &&
+ cmp unknown.idx test-2/pack-${packname_2}.idx &&
:'
--
1.0.GIT
^ permalink raw reply related
* [PATCH] ls-tree: chomp leading directories when run from a subdirectory
From: Junio C Hamano @ 2005-12-24 9:44 UTC (permalink / raw)
To: git
When run from a subdirectory, even though we filtered the output
based on where we were using pathspec, we wrote out the
repository relative paths, not subtree relative paths. This
changes things so that it shows only the current subdirectory
relative paths.
For example, in Documentation subdirectory of git itself, this
used to be the case:
$ git-ls-tree --name-only HEAD | grep how
Documentation/git-show-branch.txt
Documentation/git-show-index.txt
Documentation/howto-index.sh
Documentation/howto
But now it does this instead:
$ git-ls-tree --name-only HEAD | grep how
git-show-branch.txt
git-show-index.txt
howto-index.sh
howto
There are two things to keep in mind.
1. This shows nothing.
$ git-ls-tree --name-only HEAD ../ppc/
This is to make things consistent with ls-files, which
refuses relative path that goes uplevel.
2. These show things in full repository relative paths. In this
case, paths outside the current subdirectory are also shown.
$ git-ls-tree --name-only --full-name HEAD | grep how
Documentation/git-show-branch.txt
Documentation/git-show-index.txt
Documentation/howto-index.sh
Documentation/howto
$ git-ls-tree --name-only --full-name HEAD ../ppc/
ppc/sha1.c
ppc/sha1.h
ppc/sha1ppc.S
The flag --full-name gives the same behaviour as 1.0, so it
ought to be the default if we really care about the backward
compatibility, but in practice no Porcelain runs ls-tree from a
subdirectory yet, and without --full-name is more human
friendly, so hopefully the default being not --full-name would
be acceptable.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
* This should be the same as what Linus did earlier, only that
I lost the patch X-<. My vague recollection says that that
one did not have --full-name to match what ls-files does,
though.
Obviously the "'checkout [--|tree] path' from subdirectory"
patch needs to pass --full-name to ls-tree if we are going to
do this.
ls-tree.c | 22 ++++++++++++++++++----
1 files changed, 18 insertions(+), 4 deletions(-)
a69dd585fca9ab7fc4a07f7563f6cdb106e3ffed
diff --git a/ls-tree.c b/ls-tree.c
index dae377d..d585b6f 100644
--- a/ls-tree.c
+++ b/ls-tree.c
@@ -15,9 +15,11 @@ static int line_termination = '\n';
#define LS_NAME_ONLY 8
static int ls_options = 0;
const char **pathspec;
+static int chomp_prefix = 0;
+static const char *prefix;
static const char ls_tree_usage[] =
- "git-ls-tree [-d] [-r] [-t] [-z] [--name-only] [--name-status] <tree-ish> [path...]";
+ "git-ls-tree [-d] [-r] [-t] [-z] [--name-only] [--name-status] [--full-name] <tree-ish> [path...]";
static int show_recursive(const char *base, int baselen, const char *pathname)
{
@@ -49,7 +51,8 @@ static int show_recursive(const char *ba
}
}
-static int show_tree(unsigned char *sha1, const char *base, int baselen, const char *pathname, unsigned mode, int stage)
+static int show_tree(unsigned char *sha1, const char *base, int baselen,
+ const char *pathname, unsigned mode, int stage)
{
int retval = 0;
const char *type = "blob";
@@ -65,21 +68,28 @@ static int show_tree(unsigned char *sha1
else if (ls_options & LS_TREE_ONLY)
return 0;
+ if (chomp_prefix &&
+ (baselen < chomp_prefix || memcmp(prefix, base, chomp_prefix)))
+ return 0;
+
if (!(ls_options & LS_NAME_ONLY))
printf("%06o %s %s\t", mode, type, sha1_to_hex(sha1));
- write_name_quoted(base, baselen, pathname, line_termination, stdout);
+ write_name_quoted(base + chomp_prefix, baselen - chomp_prefix,
+ pathname,
+ line_termination, stdout);
putchar(line_termination);
return retval;
}
int main(int argc, const char **argv)
{
- const char *prefix;
unsigned char sha1[20];
char *buf;
unsigned long size;
prefix = setup_git_directory();
+ if (prefix && *prefix)
+ chomp_prefix = strlen(prefix);
while (1 < argc && argv[1][0] == '-') {
switch (argv[1][1]) {
case 'z':
@@ -100,6 +110,10 @@ int main(int argc, const char **argv)
ls_options |= LS_NAME_ONLY;
break;
}
+ if (!strcmp(argv[1]+2, "full-name")) {
+ chomp_prefix = 0;
+ break;
+ }
/* otherwise fallthru */
default:
usage(ls_tree_usage);
--
1.0.GIT
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.0.0b quickfix
From: Junio C Hamano @ 2005-12-24 9:44 UTC (permalink / raw)
To: Ingo Oeser
Cc: linux-kernel, Linus Torvalds, Benjamin Herrenschmidt,
H. Peter Anvin, git
In-Reply-To: <200512231712.40621.ioe-lkml@rameria.de>
Ingo Oeser <ioe-lkml@rameria.de> writes:
> Also sucks because letters after numbers a read as "units".
>
> Just compare 5h, 3kg, 20cm, 9in, 1.3h
If your first reaction after seeing 0.99.7a 0.99.7b 0.99.7c was
that they were numbers in unrelated units a b c and cannot be
compared with each other, you need to get your head examined ;-).
I concede that it is a cute point you tried to make [*1*], but I
do not think your presentation was convincing enough.
[Footnote]
*1* Which one is the heaviest, 5h, 3kg, or 20cm?
^ permalink raw reply
* Re: [PATCH] whatchanged: customize diff-tree output
From: Junio C Hamano @ 2005-12-24 9:44 UTC (permalink / raw)
To: Alex Riesen; +Cc: Johannes Schindelin, Linus Torvalds, git
In-Reply-To: <20051223182047.GB3165@steel.home>
> But you cannot know which ones you have to give, unless you parsed
> output of git-repo-config!
Why?
I was suggesting that you would literally write something like
this in your script:
git-whatchanged --name-status "$1".."$2"
Then whatchanged uses the '--name-status', and ignores whatever
is in the repository configuration, so you do not need to care
what repo-config says. Neither used are its built-in defaults.
^ permalink raw reply
* GIT 1.0.4 and what is in master and proposed updates.
From: Junio C Hamano @ 2005-12-24 9:42 UTC (permalink / raw)
To: git, linux-kernel
GIT 1.0.4 contains the following updates since GIT 1.0.3:
* check_packed_git_idx(): check integrity of the idx file itself.
Earlier we did not use SHA1 checksum at the end of the index
file that records the checksum of the index file itself.
* show-branch: usability updates.
Fixes the bug that made 'git show-branch --heads' show the
same heads twice, among other things.
* merge --no-commit: tweak message.
Instead of saying "failed/prevented", say which one.
* ls-files --full-name: usage string and documentation.
The option was not documented.
* mailinfo: iconv does not like "latin-1" -- should spell it "latin1"
Noted by Marco; when a message does not identify its own
charset, we tried to assume latin1 but misspelled it as
latin-1, and iconv barfed.
The master branch has all of the above, and in addition contains
the following:
* git-clone: do not special case dumb http.
This is to remove the remnant from the days http-fetch did
not handle packed repositories natively.
* rev-parse: --show-cdup
This is a low-impact shorthand for:
git rev-parse --show-prefix | sed -e 's|[^/][^/]*|..|g'
and will be used by "git checkout works from a subdirectory"
patch.
The proposed updates branch has the following updates.
* git-daemon --base-path
Lack of the command line verification bugs me somewhat with
this patch. Also we might want to apply the base-path to the
whitelist as well, which the patch currently does not do.
Almost there, but not quite ready.
* help with group permission in a shared repository.
This series consists of these commits:
Introduce core.sharedrepository
git-init-db: initialize shared repositories with --shared
Tutorial: mention shared repository management.
I think this one is ready. I just am taking things slowly.
* make git-checkout work from a subdirectory.
This series consists of these commits:
checkout: sometimes work from a subdirectory.
ls-tree: chomp leading directories when run from a subdirectory
Adjust to ls-tree --full-name when run from a subdirectory.
This seems to work pretty well. I just am taking things
slowly.
* require packfiles to follow the naming convention more strictly.
This rejects a packfile whose name does not begin with
"pack-" followed by 40-byte hexadecimal digits. The core
never had such limitation (the only thing it required was
that the pack and the idx are named with the same basename
with .pack and .idx extention), but the way http-fetch
handles packs requires this.
An alternative strategy to handle the current mess would be
to fix http-fetch so that it does not assume that pack names
are always in the format "pack-[0-9a-f]{40}.pack", getting
rid of sha1[] column from struct packed_git. This is
probably more work, but would be cleaner. On the other hand,
the cleanliness probably would not buy us much. We do not
need to insist on "pack-" prefix, but there is no strong
reason to hate it, and we need to ensure packnames do not
collide with each other anyway, so having SHA1 hash in the
name makes sense. However, we currently allow arbitrary 40
hexadecimal digits there and the user is free to say 0{40}.
Continuing to allow this defeats the initial purpose of why
40 hexadecimal digits are there: collision avoidance.
This series starts warning if the 40-byte hex that follows
"pack-" is not the correct hash for contained object names
that was given by pack-objects when the pack was created, and
has a provision to later start rejecting such packs.
This is probably controversial because it would eventually
require users to rename their packs created using pre v0.99.9
tools. There is a small utility program that helps the
conversion process, so it may not be that painful.
* Disable USE_SYMLINK_HEAD by default.
This uses symref for .git/HEAD everywhere. Some Porcelain
may not be ready to deal with it, so it is kept in the
proposed updates branch for now.
If your Porcelain "cat .git/HEAD", or "readlink .git/HEAD",
it is already broken in repositories that use symref for
HEAD, but it will be broken everywhere by this. Use
git-symbolic-ref if you want to find out the name of the
branch HEAD points at, or git-rev-parse if you want to find
out the commit object name HEAD points at.
Most notably, git_read_hash(".../HEAD") in gitweb is probably
affected (meaning, it is already broken).
^ permalink raw reply
* Re: [PATCH] qgit: allow overriding CCFLAGS
From: Junio C Hamano @ 2005-12-24 8:14 UTC (permalink / raw)
To: Marco Costalba; +Cc: Pavel Roskin, git
In-Reply-To: <43ACE80A.4070600@yahoo.it>
Marco Costalba <mcostalba@yahoo.it> writes:
> Thanks for the patch.
>
> I had a git error while applying:
> $ git-am -k -u --3way /home/marco/tmp/ccflags.txt
> tried to convert from latin-1 to ISO-8859-15, but your iconv does not work with it.
>
> It's more of a warning then en erorr because the process goes on an the patch
> applies.
Yes, and that warning is coming from a stupid typo. mailinfo.c
should say "latin1", not "latin-1". The fix will be in 1.0.4,
which I am preparing right now.
^ permalink raw reply
* Re: [PATCH] qgit: allow overriding CCFLAGS
From: Marco Costalba @ 2005-12-24 6:17 UTC (permalink / raw)
To: Pavel Roskin; +Cc: git, junkio
In-Reply-To: <1135380226.18431.21.camel@dv>
Pavel Roskin wrote:
> This patch allows overriding CCFLAGS by setting an environment variable
> or an argument to make.
>
> Signed-off-by: Pavel Roskin <proski@gnu.org>
>
> ---
> If anyone knows Python and scons well, it would be great to have a more
> generic solution that would use both environment and scons (not make)
> command line to override several variables that users may want to
> override, in particular CXX and installDir. I cannot believe I'll need
> any non-trivial coding to do something as common as this.
>
> diff --git a/SConstruct b/SConstruct
> index b0b5d0f..8ed151b 100644
> --- a/SConstruct
> +++ b/SConstruct
> @@ -27,7 +27,7 @@ env['ENV']['HOME'] = os.environ['HOME']
>
> installDir = env['HOME']+'/bin'
>
> -env.Append( CCFLAGS = ['-O2', '-Wall' ,'-Wno-non-virtual-dtor'] )
> +env.Append( CCFLAGS = os.environ.get('CCFLAGS', ['-O2', '-Wall', '-Wno-non-virtual-dtor']) )
>
> ## Uncomment the following if you need threading support threading
> env.Append( CPPFLAGS = ['-DQT_THREAD_SUPPORT', '-D_REENTRANT', '-I/usr/include/qt3'] )
>
>
Thanks for the patch.
I had a git error while applying:
$ git-am -k -u --3way /home/marco/tmp/ccflags.txt
tried to convert from latin-1 to ISO-8859-15, but your iconv does not work with it.
It's more of a warning then en erorr because the process goes on an the patch
applies.
Some info:
# iconv -V
iconv (GNU libc) 2.3.5
Copyright (C) 2005 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Questo è software libero; si veda il sorgente per le condizioni di copiatura.
NON c'è alcuna garanzia; neppure di COMMERCIABILITÀ o IDONEITÀ AD UN
PARTICOLARE SCOPO.
Written by Ulrich Drepper.
# iconv -l
The following list contain all the coded character sets known. This does
not necessarily mean that all combinations of these names can be used for
the FROM and TO command line parameters. One coded character set can be
listed with several different names (aliases).
437, 500, 500V1, 850, 851, 852, 855, 856, 857, 860, 861, 862, 863, 864, 865,
866, 866NAV, 869, 874, 904, 1026, 1046, 1047, 8859_1, 8859_2, 8859_3, 8859_4,
8859_5, 8859_6, 8859_7, 8859_8, 8859_9, 10646-1:1993, 10646-1:1993/UCS4,
ANSI_X3.4-1968, ANSI_X3.4-1986, ANSI_X3.4, ANSI_X3.110-1983, ANSI_X3.110,
ARABIC, ARABIC7, ARMSCII-8, ASCII, ASMO-708, ASMO_449, BALTIC, BIG-5,
BIG-FIVE, BIG5-HKSCS, BIG5, BIG5HKSCS, BIGFIVE, BS_4730, CA, CN-BIG5, CN-GB,
CN, CP-AR, CP-GR, CP-HU, CP037, CP038, CP154, CP273, CP274, CP275, CP278,
CP280, CP281, CP282, CP284, CP285, CP290, CP297, CP367, CP420, CP423, CP424,
CP437, CP500, CP737, CP775, CP813, CP819, CP850, CP851, CP852, CP855, CP856,
CP857, CP860, CP861, CP862, CP863, CP864, CP865, CP866, CP866NAV, CP868,
CP869, CP870, CP871, CP874, CP875, CP880, CP891, CP903, CP904, CP905, CP912,
CP915, CP916, CP918, CP920, CP922, CP930, CP932, CP933, CP935, CP936, CP937,
CP939, CP949, CP950, CP1004, CP1026, CP1046, CP1047, CP1070, CP1079, CP1081,
CP1084, CP1089, CP1124, CP1125, CP1129, CP1132, CP1133, CP1160, CP1161,
CP1162, CP1163, CP1164, CP1250, CP1251, CP1251_TT, CP1252, CP1253, CP1254,
CP1255, CP1256, CP1257, CP1258, CP1361, CP10007, CPIBM861, CSA7-1, CSA7-2,
CSASCII, CSA_T500-1983, CSA_T500, CSA_Z243.4-1985-1, CSA_Z243.4-1985-2,
CSA_Z243.419851, CSA_Z243.419852, CSDECMCS, CSEBCDICATDE, CSEBCDICATDEA,
CSEBCDICCAFR, CSEBCDICDKNO, CSEBCDICDKNOA, CSEBCDICES, CSEBCDICESA,
CSEBCDICESS, CSEBCDICFISE, CSEBCDICFISEA, CSEBCDICFR, CSEBCDICIT, CSEBCDICPT,
CSEBCDICUK, CSEBCDICUS, CSEUCKR, CSEUCPKDFMTJAPANESE, CSGB2312, CSHPROMAN8,
CSIBM037, CSIBM038, CSIBM273, CSIBM274, CSIBM275, CSIBM277, CSIBM278,
CSIBM280, CSIBM281, CSIBM284, CSIBM285, CSIBM290, CSIBM297, CSIBM420,
CSIBM423, CSIBM424, CSIBM500, CSIBM851, CSIBM855, CSIBM856, CSIBM857,
CSIBM860, CSIBM863, CSIBM864, CSIBM865, CSIBM866, CSIBM868, CSIBM869,
CSIBM870, CSIBM871, CSIBM880, CSIBM891, CSIBM903, CSIBM904, CSIBM905,
CSIBM918, CSIBM922, CSIBM930, CSIBM932, CSIBM933, CSIBM935, CSIBM937,
CSIBM939, CSIBM943, CSIBM1026, CSIBM1124, CSIBM1129, CSIBM1132, CSIBM1133,
CSIBM1160, CSIBM1161, CSIBM1163, CSIBM1164, CSIBM11621162,
CSISO4UNITEDKINGDOM, CSISO10SWEDISH, CSISO11SWEDISHFORNAMES,
CSISO14JISC6220RO, CSISO15ITALIAN, CSISO16PORTUGESE, CSISO17SPANISH,
CSISO18GREEK7OLD, CSISO19LATINGREEK, CSISO21GERMAN, CSISO25FRENCH,
CSISO27LATINGREEK1, CSISO49INIS, CSISO50INIS8, CSISO51INISCYRILLIC,
CSISO58GB1988, CSISO60DANISHNORWEGIAN, CSISO60NORWEGIAN1, CSISO61NORWEGIAN2,
CSISO69FRENCH, CSISO84PORTUGUESE2, CSISO85SPANISH2, CSISO86HUNGARIAN,
CSISO88GREEK7, CSISO89ASMO449, CSISO90, CSISO92JISC62991984B, CSISO99NAPLPS,
CSISO103T618BIT, CSISO111ECMACYRILLIC, CSISO121CANADIAN1, CSISO122CANADIAN2,
CSISO139CSN369103, CSISO141JUSIB1002, CSISO143IECP271, CSISO150,
CSISO150GREEKCCITT, CSISO151CUBA, CSISO153GOST1976874, CSISO646DANISH,
CSISO2022CN, CSISO2022JP, CSISO2022JP2, CSISO2022KR, CSISO2033,
CSISO5427CYRILLIC, CSISO5427CYRILLIC1981, CSISO5428GREEK, CSISO10367BOX,
CSISOLATIN1, CSISOLATIN2, CSISOLATIN3, CSISOLATIN4, CSISOLATIN5, CSISOLATIN6,
CSISOLATINARABIC, CSISOLATINCYRILLIC, CSISOLATINGREEK, CSISOLATINHEBREW,
CSKOI8R, CSKSC5636, CSMACINTOSH, CSNATSDANO, CSNATSSEFI, CSN_369103,
CSPC8CODEPAGE437, CSPC775BALTIC, CSPC850MULTILINGUAL, CSPC862LATINHEBREW,
CSPCP852, CSSHIFTJIS, CSUCS4, CSUNICODE, CSWINDOWS31J, CUBA, CWI-2, CWI,
CYRILLIC-ASIAN, CYRILLIC, DE, DEC-MCS, DEC, DECMCS, DIN_66003, DK, DS2089,
DS_2089, E13B, EBCDIC-AT-DE-A, EBCDIC-AT-DE, EBCDIC-BE, EBCDIC-BR,
EBCDIC-CA-FR, EBCDIC-CP-AR1, EBCDIC-CP-AR2, EBCDIC-CP-BE, EBCDIC-CP-CA,
EBCDIC-CP-CH, EBCDIC-CP-DK, EBCDIC-CP-ES, EBCDIC-CP-FI, EBCDIC-CP-FR,
EBCDIC-CP-GB, EBCDIC-CP-GR, EBCDIC-CP-HE, EBCDIC-CP-IS, EBCDIC-CP-IT,
EBCDIC-CP-NL, EBCDIC-CP-NO, EBCDIC-CP-ROECE, EBCDIC-CP-SE, EBCDIC-CP-TR,
EBCDIC-CP-US, EBCDIC-CP-WT, EBCDIC-CP-YU, EBCDIC-CYRILLIC, EBCDIC-DK-NO-A,
EBCDIC-DK-NO, EBCDIC-ES-A, EBCDIC-ES-S, EBCDIC-ES, EBCDIC-FI-SE-A,
EBCDIC-FI-SE, EBCDIC-FR, EBCDIC-GREEK, EBCDIC-INT, EBCDIC-INT1,
EBCDIC-IS-FRISS, EBCDIC-IT, EBCDIC-JP-E, EBCDIC-JP-KANA, EBCDIC-PT,
EBCDIC-UK, EBCDIC-US, EBCDICATDE, EBCDICATDEA, EBCDICCAFR, EBCDICDKNO,
EBCDICDKNOA, EBCDICES, EBCDICESA, EBCDICESS, EBCDICFISE, EBCDICFISEA,
EBCDICFR, EBCDICISFRISS, EBCDICIT, EBCDICPT, EBCDICUK, EBCDICUS, ECMA-114,
ECMA-118, ECMA-128, ECMA-CYRILLIC, ECMACYRILLIC, ELOT_928, ES, ES2, EUC-CN,
EUC-JISX0213, EUC-JP-MS, EUC-JP, EUC-KR, EUC-TW, EUCCN, EUCJP-MS, EUCJP-OPEN,
EUCJP-WIN, EUCJP, EUCKR, EUCTW, FI, FR, GB, GB2312, GB13000, GB18030, GBK,
GB_1988-80, GB_198880, GEO8-BPG, GEO8-PS, GEORGIAN-ACADEMY, GEORGIAN-PS,
GEORGIAN-RS, GOST_19768-74, GOST_19768, GOST_1976874, GREEK-CCITT, GREEK,
GREEK7-OLD, GREEK7, GREEK7OLD, GREEK8, GREEKCCITT, HEBREW, HP-ROMAN8,
HPROMAN8, HU, IBM-856, IBM-922, IBM-930, IBM-932, IBM-933, IBM-935, IBM-937,
IBM-939, IBM-943, IBM-1046, IBM-1047, IBM-1124, IBM-1129, IBM-1132, IBM-1133,
IBM-1160, IBM-1161, IBM-1162, IBM-1163, IBM-1164, IBM037, IBM038, IBM256,
IBM273, IBM274, IBM275, IBM277, IBM278, IBM280, IBM281, IBM284, IBM285,
IBM290, IBM297, IBM367, IBM420, IBM423, IBM424, IBM437, IBM500, IBM775,
IBM813, IBM819, IBM848, IBM850, IBM851, IBM852, IBM855, IBM856, IBM857,
IBM860, IBM861, IBM862, IBM863, IBM864, IBM865, IBM866, IBM866NAV, IBM868,
IBM869, IBM870, IBM871, IBM874, IBM875, IBM880, IBM891, IBM903, IBM904,
IBM905, IBM912, IBM915, IBM916, IBM918, IBM920, IBM922, IBM930, IBM932,
IBM933, IBM935, IBM937, IBM939, IBM943, IBM1004, IBM1026, IBM1046, IBM1047,
IBM1089, IBM1124, IBM1129, IBM1132, IBM1133, IBM1160, IBM1161, IBM1162,
IBM1163, IBM1164, IEC_P27-1, IEC_P271, INIS-8, INIS-CYRILLIC, INIS, INIS8,
INISCYRILLIC, IS13194-DEV, IS13194-DEVANAGARI, IS13194:1991, ISCII-91,
ISCII-DEV, ISIRI-3342, ISIRI3342, ISO-2022-CN-EXT, ISO-2022-CN,
ISO-2022-JP-2, ISO-2022-JP-3, ISO-2022-JP, ISO-2022-KR, ISO-8859-1,
ISO-8859-2, ISO-8859-3, ISO-8859-4, ISO-8859-5, ISO-8859-6, ISO-8859-7,
ISO-8859-8, ISO-8859-9, ISO-8859-9E, ISO-8859-10, ISO-8859-11, ISO-8859-13,
ISO-8859-14, ISO-8859-15, ISO-8859-16, ISO-10646, ISO-10646/UCS2,
ISO-10646/UCS4, ISO-10646/UTF-8, ISO-10646/UTF8, ISO-CELTIC, ISO-IR-4,
ISO-IR-6, ISO-IR-8-1, ISO-IR-9-1, ISO-IR-10, ISO-IR-11, ISO-IR-14, ISO-IR-15,
ISO-IR-16, ISO-IR-17, ISO-IR-18, ISO-IR-19, ISO-IR-21, ISO-IR-25, ISO-IR-27,
ISO-IR-37, ISO-IR-49, ISO-IR-50, ISO-IR-51, ISO-IR-54, ISO-IR-55, ISO-IR-57,
ISO-IR-60, ISO-IR-61, ISO-IR-69, ISO-IR-84, ISO-IR-85, ISO-IR-86, ISO-IR-88,
ISO-IR-89, ISO-IR-90, ISO-IR-92, ISO-IR-98, ISO-IR-99, ISO-IR-100,
ISO-IR-101, ISO-IR-103, ISO-IR-109, ISO-IR-110, ISO-IR-111, ISO-IR-121,
ISO-IR-122, ISO-IR-126, ISO-IR-127, ISO-IR-138, ISO-IR-139, ISO-IR-141,
ISO-IR-143, ISO-IR-144, ISO-IR-148, ISO-IR-150, ISO-IR-151, ISO-IR-153,
ISO-IR-155, ISO-IR-156, ISO-IR-157, ISO-IR-166, ISO-IR-179, ISO-IR-193,
ISO-IR-197, ISO-IR-199, ISO-IR-203, ISO-IR-209, ISO-IR-226, ISO646-CA,
ISO646-CA2, ISO646-CN, ISO646-CU, ISO646-DE, ISO646-DK, ISO646-ES,
ISO646-ES2, ISO646-FI, ISO646-FR, ISO646-FR1, ISO646-GB, ISO646-HU,
ISO646-IT, ISO646-JP-OCR-B, ISO646-JP, ISO646-KR, ISO646-NO, ISO646-NO2,
ISO646-PT, ISO646-PT2, ISO646-SE, ISO646-SE2, ISO646-US, ISO646-YU,
ISO2022CN, ISO2022CNEXT, ISO2022JP, ISO2022JP2, ISO2022KR, ISO6937,
ISO8859-1, ISO8859-2, ISO8859-3, ISO8859-4, ISO8859-5, ISO8859-6, ISO8859-7,
ISO8859-8, ISO8859-9, ISO8859-10, ISO8859-11, ISO8859-13, ISO8859-14,
ISO8859-15, ISO8859-16, ISO88591, ISO88592, ISO88593, ISO88594, ISO88595,
ISO88596, ISO88597, ISO88598, ISO88599, ISO885910, ISO885911, ISO885913,
ISO885914, ISO885915, ISO885916, ISO_646.IRV:1991, ISO_2033-1983, ISO_2033,
ISO_5427-EXT, ISO_5427, ISO_5427:1981, ISO_5427EXT, ISO_5428, ISO_5428:1980,
ISO_6937-2, ISO_6937-2:1983, ISO_6937, ISO_6937:1992, ISO_8859-1,
ISO_8859-1:1987, ISO_8859-2, ISO_8859-2:1987, ISO_8859-3, ISO_8859-3:1988,
ISO_8859-4, ISO_8859-4:1988, ISO_8859-5, ISO_8859-5:1988, ISO_8859-6,
ISO_8859-6:1987, ISO_8859-7, ISO_8859-7:1987, ISO_8859-7:2003, ISO_8859-8,
ISO_8859-8:1988, ISO_8859-9, ISO_8859-9:1989, ISO_8859-10, ISO_8859-10:1992,
ISO_8859-14, ISO_8859-14:1998, ISO_8859-15, ISO_8859-15:1998, ISO_8859-16,
ISO_8859-16:2001, ISO_9036, ISO_10367-BOX, ISO_10367BOX, ISO_69372, IT,
JIS_C6220-1969-RO, JIS_C6229-1984-B, JIS_C62201969RO, JIS_C62291984B, JOHAB,
JP-OCR-B, JP, JS, JUS_I.B1.002, KHMER-NS, KOI-7, KOI-8, KOI8-K, KOI8-R,
KOI8-T, KOI8-U, KOI8, KOI8R, KOI8U, KSC5636, L1, L2, L3, L4, L5, L6, L7, L8,
L10, LATIN-9, LATIN-GREEK-1, LATIN-GREEK, LATIN1, LATIN2, LATIN3, LATIN4,
LATIN5, LATIN6, LATIN7, LATIN8, LATIN10, LATINGREEK, LATINGREEK1,
MAC-CYRILLIC, MAC-IS, MAC-SAMI, MAC-UK, MAC, MACCYRILLIC, MACINTOSH, MACIS,
MACUK, MACUKRAINIAN, MS-ANSI, MS-ARAB, MS-CYRL, MS-EE, MS-GREEK, MS-HEBR,
MS-MAC-CYRILLIC, MS-TURK, MS932, MS936, MSCP949, MSCP1361, MSMACCYRILLIC,
MSZ_7795.3, MS_KANJI, MULELAO-1, NAPLPS, NATS-DANO, NATS-SEFI, NATSDANO,
NATSSEFI, NC_NC0010, NC_NC00-10, NC_NC00-10:81, NF_Z_62-010,
NF_Z_62-010_(1973), NF_Z_62-010_1973, NF_Z_62010, NF_Z_62010_1973, NO, NO2,
NS_4551-1, NS_4551-2, NS_45511, NS_45512, OS2LATIN1, OSF00010001,
OSF00010002, OSF00010003, OSF00010004, OSF00010005, OSF00010006, OSF00010007,
OSF00010008, OSF00010009, OSF0001000A, OSF00010020, OSF00010100, OSF00010101,
OSF00010102, OSF00010104, OSF00010105, OSF00010106, OSF00030010, OSF0004000A,
OSF0005000A, OSF05010001, OSF100201A4, OSF100201A8, OSF100201B5, OSF100201F4,
OSF100203B5, OSF1002011C, OSF1002011D, OSF1002035D, OSF1002035E, OSF1002035F,
OSF1002036B, OSF1002037B, OSF10010001, OSF10020025, OSF10020111, OSF10020115,
OSF10020116, OSF10020118, OSF10020122, OSF10020129, OSF10020352, OSF10020354,
OSF10020357, OSF10020359, OSF10020360, OSF10020364, OSF10020365, OSF10020366,
OSF10020367, OSF10020370, OSF10020387, OSF10020388, OSF10020396, OSF10020402,
OSF10020417, PT-CP154, PT, PT2, PT154, R8, RK1048, ROMAN8, RUSCII, SE, SE2,
SEN_850200_B, SEN_850200_C, SHIFT-JIS, SHIFT_JIS, SHIFT_JISX0213, SJIS-OPEN,
SJIS-WIN, SJIS, SS636127, STRK1048-2002, ST_SEV_358-88, T.61-8BIT, T.61,
T.618BIT, TATAR-CYR, TCVN-5712, TCVN, TCVN5712-1, TCVN5712-1:1993, TIS-620,
TIS620-0, TIS620.2529-1, TIS620.2533-0, TIS620, TS-5881, TSCII-0, TSCII,
UCS-2, UCS-2BE, UCS-2LE, UCS-4, UCS-4BE, UCS-4LE, UCS2, UCS4, UHC, UJIS, UK,
UNICODE, UNICODEBIG, UNICODELITTLE, US-ASCII, US, UTF-7, UTF-8, UTF-16,
UTF-16BE, UTF-16LE, UTF-32, UTF-32BE, UTF-32LE, UTF7, UTF8, UTF16, UTF16BE,
UTF16LE, UTF32, UTF32BE, UTF32LE, VISCII-1, VISCII, VISCII1.1-1, WCHAR_T,
WIN-SAMI-2, WINBALTRIM, WINDOWS-31J, WINDOWS-874, WINDOWS-936, WINDOWS-1250,
WINDOWS-1251, WINDOWS-1252, WINDOWS-1253, WINDOWS-1254, WINDOWS-1255,
WINDOWS-1256, WINDOWS-1257, WINDOWS-1258, WINSAMI2, WS2, YU
___________________________________
Yahoo! Mail: gratis 1GB per i messaggi e allegati da 10MB
http://mail.yahoo.it
^ permalink raw reply
* Re: git repack throws -> error: unrecognized: ??
From: Junio C Hamano @ 2005-12-24 3:16 UTC (permalink / raw)
To: duncan; +Cc: git
In-Reply-To: <43ACAE49.4000902@excelsior-online.org>
Duncan Mac Leod <duncan@excelsior-online.org> writes:
> The last one throws 'error: unrecognized:' - what does this mean?
>
> Under which circumstances is this error message fired?
>
> Did my git repository get corrupted?
No. But you are running GIT before 1.0.0b.
Namely, this commit is needed to squelch the error message:
commit 8ac4838af428a2a32498b3e8d13295eb714654b4
Author: Junio C Hamano <junkio@cox.net>
Date: Wed Dec 21 13:48:47 2005 -0800
server-info: skip empty lines.
Now we allow an empty line in objects/info/packs file, recognize
that and stop complaining.
Signed-off-by: Junio C Hamano <junkio@cox.net>
^ permalink raw reply
* Possibility of a MinGW version?
From: Rob McDonald @ 2005-12-24 2:34 UTC (permalink / raw)
To: git
1.0 is out the door, with support (to some degree or another) for Cygwin,
BSD, MacOS X, Solaris, and who knows what else, good job all.
What possibility is there of getting git (& assorted tools) to run natively
on Windows (sacrilege I know) using MinGW? What truly Unixy-only things
does the code do? Unfortunately, Windows is a reality for many of us.
I'd like to begin experimenting using git to track all of my data files
acting as a synchronization mechanism. Have all your files up-to-date
everywhere, revision tracking, & redundancy too... Dedicated Linux
repository at home, dual boot laptop on the road, Windows machine at work,
etc...
Thoughts? Suggestions?
Rob
Please CC me, I track the archive closely, but am not subscribed.
^ permalink raw reply
* git repack throws -> error: unrecognized: ??
From: Duncan Mac Leod @ 2005-12-24 2:11 UTC (permalink / raw)
To: git
Hi!
I have done the following operations on my git repository...
duncan@firebird /var/git $ GIT_DIR=/var/git/myproject.git git fsck-objects
duncan@firebird /var/git $ GIT_DIR=/var/git/myproject.git git prune
duncan@firebird /var/git $ GIT_DIR=/var/git/myproject.git git count-objects
42 objects, 616 kilobytes
duncan@firebird /var/git $ GIT_DIR=/var/git/myproject.git git repack
Packing 42 objects
Pack pack-d715ebdf63391b054d9f058d59d3d3a4f6f2a12c created.
error: unrecognized:
The last one throws 'error: unrecognized:' - what does this mean?
Under which circumstances is this error message fired?
Did my git repository get corrupted?
...and 'HAPPY HOLIDAYS' to all of you!
Duncan
^ permalink raw reply
* Re: "p4 revert -a" equivalent in git?
From: Luben Tuikov @ 2005-12-24 0:36 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd5jn4a36.fsf@assigned-by-dhcp.cox.net>
--- Junio C Hamano <junkio@cox.net> wrote:
> That's what "git-update-index --refresh" does, unless I am
> misreading what you say you want.
>
> $ git checkout master
> $ touch *.c
> $ git diff-index HEAD ;# tons of changes
> $ git update-index --refresh
> $ git diff-index HEAD ;# no changes
Ok, thanks. I wasn't sure if I had to specify the file
names on the command line of "git-update-index --refresh".
It looks like I don't have to, so this is a perfect
equivalent.
Thanks,
Luben
^ permalink raw reply
* Re: "p4 revert -a" equivalent in git?
From: Junio C Hamano @ 2005-12-24 0:23 UTC (permalink / raw)
To: ltuikov; +Cc: git
In-Reply-To: <20051224001308.7078.qmail@web31805.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> That is I want to git-update-index --refresh for all
> files whose inode may have changed but the actual file
> data has not.
That's what "git-update-index --refresh" does, unless I am
misreading what you say you want.
$ git checkout master
$ touch *.c
$ git diff-index HEAD ;# tons of changes
$ git update-index --refresh
$ git diff-index HEAD ;# no changes
^ permalink raw reply
* "p4 revert -a" equivalent in git?
From: Luben Tuikov @ 2005-12-24 0:13 UTC (permalink / raw)
To: git
Hi,
Is there a "p4 revert -a" equivalent in git or should I
whip up a script using git-diff-index and git-update-index?
That is I want to git-update-index --refresh for all
files whose inode may have changed but the actual file
data has not (i.e. git-diff-index is empty).
Thanks,
Luben
^ permalink raw reply
* minor lib issue
From: Bennett Todd @ 2005-12-23 23:55 UTC (permalink / raw)
To: git
[-- Attachment #1.1: Type: text/plain, Size: 637 bytes --]
Not sure whether it's practical to fix this without autoconfiscating
the thing, but the logic for picking what libs to link against isn't
as robust as it might be, and the lib ordering (libcurl after
libcrypto) depends on dynamic linking to work.
I was able to build on Bent Linux (uClibc based, static linking
only) with the attached patch, which obviously is a one-off kludge
and not a reasonable fix for the problem.
-Bennett
P.S. In case anyone cares, I call Bent Linux my mid-life crisis
project. Unix as I grew to love her about 25 years ago, when she and
I were both a lot slimmer and healthier.
<URL:http://bent.latency.net/>
[-- Attachment #1.2: git-1.0.3-liborder.patch --]
[-- Type: text/plain, Size: 584 bytes --]
diff -ru git-1.0.3.orig/Makefile git-1.0.3/Makefile
--- git-1.0.3.orig/Makefile 2005-12-23 23:07:42.000000000 +0000
+++ git-1.0.3/Makefile 2005-12-23 23:09:36.000000000 +0000
@@ -422,8 +422,8 @@
git-ssh-pull$X: rsh.o fetch.o
git-ssh-push$X: rsh.o
-git-http-fetch$X: LIBS += $(CURL_LIBCURL)
-git-http-push$X: LIBS += $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
+git-http-fetch$X: LIBS += $(CURL_LIBCURL) $(LIB_4_CRYPTO) -lssl -lcrypto
+git-http-push$X: LIBS += $(CURL_LIBCURL) $(EXPAT_LIBEXPAT) -lssl -lcrypto
git-rev-list$X: LIBS += $(OPENSSL_LIBSSL)
init-db.o: init-db.c
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] qgit: allow overriding CCFLAGS
From: Fernando J. Pereda @ 2005-12-23 23:29 UTC (permalink / raw)
To: git
In-Reply-To: <1135380226.18431.21.camel@dv>
[-- Attachment #1: Type: text/plain, Size: 637 bytes --]
On Fri, Dec 23, 2005 at 06:23:46PM -0500, Pavel Roskin wrote:
| This patch allows overriding CCFLAGS by setting an environment variable
| or an argument to make.
That'd be nice... I have an ugly sed in the Gentoo ebuild to workaround
that. However...
| -env.Append( CCFLAGS = ['-O2', '-Wall' ,'-Wno-non-virtual-dtor'] )
| +env.Append( CCFLAGS = os.environ.get('CCFLAGS', ['-O2', '-Wall', '-Wno-non-virtual-dtor']) )
... shouldn't the enviroment variable be CXXFLAGS ?
Cheers,
Ferdy
--
Fernando J. Pereda Garcimartín
Gentoo Developer (Alpha,net-mail,mutt,git)
20BB BDC3 761A 4781 E6ED ED0B 0A48 5B0C 60BD 28D4
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* [PATCH] qgit: allow overriding CCFLAGS
From: Pavel Roskin @ 2005-12-23 23:23 UTC (permalink / raw)
To: Marco Costalba; +Cc: git
This patch allows overriding CCFLAGS by setting an environment variable
or an argument to make.
Signed-off-by: Pavel Roskin <proski@gnu.org>
---
If anyone knows Python and scons well, it would be great to have a more
generic solution that would use both environment and scons (not make)
command line to override several variables that users may want to
override, in particular CXX and installDir. I cannot believe I'll need
any non-trivial coding to do something as common as this.
diff --git a/SConstruct b/SConstruct
index b0b5d0f..8ed151b 100644
--- a/SConstruct
+++ b/SConstruct
@@ -27,7 +27,7 @@ env['ENV']['HOME'] = os.environ['HOME']
installDir = env['HOME']+'/bin'
-env.Append( CCFLAGS = ['-O2', '-Wall' ,'-Wno-non-virtual-dtor'] )
+env.Append( CCFLAGS = os.environ.get('CCFLAGS', ['-O2', '-Wall', '-Wno-non-virtual-dtor']) )
## Uncomment the following if you need threading support threading
env.Append( CPPFLAGS = ['-DQT_THREAD_SUPPORT', '-D_REENTRANT', '-I/usr/include/qt3'] )
--
Regards,
Pavel Roskin
^ permalink raw reply related
* Re: [PATCH] whatchanged: customize diff-tree output
From: Alex Riesen @ 2005-12-23 18:12 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git
In-Reply-To: <Pine.LNX.4.63.0512222323110.12241@wbgn013.biozentrum.uni-wuerzburg.de>
Johannes Schindelin, Thu, Dec 22, 2005 23:24:48 +0100:
> > A script from ~user1/bin, which calls git-whatchanged suddenly stops
> > working in ~user2/repo.
> > [...]
> >
> > Maybe such configuration better left to environment variables?
>
> And that makes the script not stop how?
>
It is another user, who does not have the variable set, or just unsets
the variable in his scripts (now he _can_ rely upon git-whatchanged
always doing the same)
^ permalink raw reply
* Re: git-checkout and SUBDIRECTORY_OK='Yes'
From: Junio C Hamano @ 2005-12-23 17:56 UTC (permalink / raw)
To: git; +Cc: Jon Nelson
In-Reply-To: <7virtge7fb.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> writes:
> Jon Nelson <jnelson-git@jamponi.net> writes:
>
>> Is it safe to set SUBDIRECTORY_OK='Yes' in git-checkout.sh?
> This patch *might* work, or it may not...
I've done some tests and it seems to work (it is in the
proposed updates branch).
In git.git working tree, here is what happens:
$ git checkout pu ;# start from pu
$ cd Documentation
$ echo >>git-daemon.txt ;# smudge
$ git checkout -- git-daemon.txt ;# restore
$ git diff -r --name-status ;# no change
$ git checkout master git-daemon.txt ;# pick from tree
$ git diff master -r --name-status ;# (1)
$ git diff -r --name-status ;# (2)
$ git diff pu -r --name-status ;# (3)
M Documentation/git-daemon.txt
(1) does not show any because it did take the file out of master
branch, and git-daemon.txt is the only file different under
Documentation/ between master and pu.
(2) does not show any because "checkout master git-daemon.txt"
updated the path both in index and working tree.
(3) shows the path indeed is different between master and pu.
The change relies on ls-tree showing full paths regardless of
where it gets started (because the output is fed to --index-info
form of git-update-index). If we are going to take the "ls-tree
prefix truncation" patch from Linus, either we also need to
update "git-update-index --index-info" to match this.
^ permalink raw reply
* [PATCH] git-show-branch: show the right things when "--heads" or "--tags" is specified
From: M_ @ 2005-12-23 16:35 UTC (permalink / raw)
To: git
---
show-branch.c | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
26c0f04b8a370ac9943bb409b8cd5e7370263f41
diff --git a/show-branch.c b/show-branch.c
index c742246..2aeabd9 100644
--- a/show-branch.c
+++ b/show-branch.c
@@ -515,7 +515,7 @@ int main(int ac, char **av)
if (all_heads + all_tags)
snarf_refs(all_heads, all_tags);
- if (ac) {
+ if (ac + all_heads + all_tags) {
while (0 < ac) {
append_one_rev(*av);
ac--; av++;
--
1.0.0b
^ permalink raw reply related
* Re: [ANNOUNCE] GIT 1.0.0b quickfix
From: Ingo Oeser @ 2005-12-23 16:12 UTC (permalink / raw)
To: linux-kernel
Cc: Linus Torvalds, Benjamin Herrenschmidt, H. Peter Anvin,
Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0512220945450.4827@g5.osdl.org>
On Thursday 22 December 2005 18:46, Linus Torvalds wrote:
> On Thu, 22 Dec 2005, Benjamin Herrenschmidt wrote:
> > > Wouldn't it make more sense for the maintenance release to be 1.0.1?
> > Seconded. letters in versions are bad. With my MacOS background, for me,
> > "b" means "beta" :)
> FWIW, thirded. The kernel used to use letters too, and it's cute, but just
> using multiple levels of release numbers is much more common.
Also sucks because letters after numbers a read as "units".
Just compare 5h, 3kg, 20cm, 9in, 1.3h
Also putting letters after version numbers usally gives me
a feeling that the author is not sure about what he does.
But this is just me, I guess
I hope util-linux is going to learn all that one day :-)
Regards
Ingo Oeser
^ permalink raw reply
* [ANNOUNCE] Stacked GIT 0.8
From: Catalin Marinas @ 2005-12-23 15:19 UTC (permalink / raw)
To: GIT
Stacked GIT 0.8 release is available from http://www.procode.org/stgit/
StGIT is a Python application providing similar functionality to Quilt
(i.e. pushing/popping patches to/from a stack) on top of GIT. These
operations are performed using GIT commands and the patches are stored
as GIT commit objects, allowing easy merging of the StGIT patches into
other repositories using standard GIT functionality.
What's new in this release:
* 'branch' command for the GIT branches manipulation: creation,
deletion, switching, renaming, cloning (including the StGIT
patches)
* 'patches' command to show the StGIT patches modifying a file
* Better visualisation of the StGIT patches and branches (a short
description can be displayed)
* '--fold' option for the 'pick' command to allow folding a given
commit onto an existing patch
* Automatic invocation of the editor for the cover message when
sending a series by e-mail
* StGIT informs when a patch was modified during a push or pick
operation (i.e. a three-way merge was needed)
* StGIT now complies with the recommended format for the author
information in the patch description (both for sending and
receiving)
* Further optimisations
* Bug fixes
Acknowledgements (generated with 'git shortlog'):
Catalin Marinas:
Optimise 'push' to use git-apply instead of git-read-tree
Escape the unusual characters in the name <email> strings
Cache the HEAD value
Make __commits global in git.py
Add an uninstallable script for profiling
Add the --reset option to status
'status --reset' should remove the conflicts as well
TODO updated with the need for a 'prune' command
Add a --fold option to pick
Allow git.apply_patch() to take a base revision
Add a --reset option to resolved
Fix the caching of the HEAD value
Use git_id in import and fold instead of git.rev_parse
Allow the short version of --base (i.e. -b) in import
Flush the HEAD cache in set_head_file()
Fix the branch protect/unprotect message
Allow the editing of the cover message before sending it by e-mail
Notify when a patch was modified during a push operation
Notify when a cherry-picked commit was modified by 'pick'
Capture the KeyboardInterrupt exception
Fix the 'files' initialisation in git.checkout()
Add a patches command
Optimise the export command
Add a space after ',' when building the e-mail recipients headers
Different fixes for the branch command
Optimise pick --fold to use git-apply first
Fix the --name option for the pick command
Fix the unapplied variable missing in export.py
Allow 'stg status --reset' to work on individual files
Make StGIT comply with the author information retrieving
Update the tutorial
Update the TODO information
Fix the import command when the body is empty
"status --reset" does not restore the deleted files
Release 0.8
Chuck Lever:
Use a more clear message when pop or push can't apply a patch
Use "git-rev-parse" to get the HEAD commit
Add a stack method to delete a patch series
Create a new utility function in git.py for setting the HEAD link
Add git method for creating a fresh branch
Add git method for switching to a different branch
Add the ability to delete a branch to git.py
Add the ability to rename a git branch
Allow print_crt_patch to work on other branches
Rudimentary support for multiple development branches
Allow user to protect some branches against "stg pull"
Add support for branch description files
Fix a couple of bugs in "stg branch --create"
Fix a bug in "stg branch --rename"
Give the global "crt_series" variable a default value
Remove unused import in stgit/git.py
Make sure switch_branch uses the right __head
Get rid of an unused variable
Fix exception error message in git.merge()
Make switching to the current branch a no-op
Make listing branches more efficient
"stg mail" doesn't distinguish between unapplied and non-existent patches
Print the git version when running the "stg version" command
Need to do "git-update-index --refresh" in more places
Prevent stderr from appearing on stdout when running commands
Use __run instead of os.system() in git.merge()
Using a mutable default function argument is bad
remove extra refresh_index() call in apply_patches()
"stg export" error message could be more specific
Fix up help string for "stg clone"
Replace a variable that uses the same name as a built-in
Add a stack method for determining whether a branch is initialised
Generalize branch renaming
Better error message when renaming patches to same name
use "crt_series.get_branch()" instead of "git.get_head_file()"
Fix a typo in "stg pick"
Fix a typo in the "add" command's documentation
Cleanup: remove unused variable
Clean up StGIT's "branch --delete" command
Seamlessly allow diffs "from" the current working directory
Using delete_patch while deleting a branch is broken
Align branch descriptions in output of "stg branch -l"
Use git-rev-parse to find the local GIT repository
"stg series" option to show patch summary descriptions
Add facility to print short list of patches around 'top'
Make "stg export" save the base commit in the output directory
Fast-forwarding does a git.switch() even when it forwarded no patches
Add a "--clone" option to "stg branch"
Add a brief sentence to the documentation of the "stg branch" command.
Remove "-r" option on invocations of git-diff-index
Paolo 'Blaisorblade' Giarrusso:
Parse /top.old with id and when requesting diffs
Ask vim to avoid backup copies of .stgit.msg
Add an option to delete a patch from a certain branch
Trond Myklebust:
remove formatting of git log entry on an imported patch
--
Catalin
^ permalink raw reply
* Re: [PATCH] send-pack: reword non-fast-forward error message.
From: Andreas Ericsson @ 2005-12-23 12:13 UTC (permalink / raw)
To: git
In-Reply-To: <7vu0d0j24z.fsf_-_@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Junio C Hamano <junkio@cox.net> writes:
>
>
>>Andreas Ericsson <ae@op5.se> writes:
>>
>>
>>>Junio C Hamano wrote:
>>>
>>>>In a sense, both are "pull first?" situation, and it probably is
>>>>more confusing to give different messages to the user in these
>>>>two cases. From the end-user point of view they are the same
>>>>"remote is not strict subset.".
>>>
>>>In non-git'ish, does this mean "you're not up to date, so pull before
>>>pushing" ? If so, why not say so? I'm sure it could prevent a fair few
>>>problems for users (not least those new to scm's).
>
>
> That is reasonable. How about this?
>
Me likes.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ 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