* Re: git-clone --reference problem?
From: Junio C Hamano @ 2006-04-23 17:50 UTC (permalink / raw)
To: David Woodhouse; +Cc: git
In-Reply-To: <1145810080.16166.223.camel@shinybook.infradead.org>
David Woodhouse <dwmw2@infradead.org> writes:
> Should I expect cloning with alternates using '--reference' to be
> transitive?
Not with the current code and design, but a patch that cleanly
does that can be considered for inclusion. Adjusting relative
paths obtained from other repositories correctly, and avoiding
circular alternates by mistake would be tricky, though.
^ permalink raw reply
* git-clone --reference problem?
From: David Woodhouse @ 2006-04-23 16:34 UTC (permalink / raw)
To: git
Should I expect cloning with alternates using '--reference' to be
transitive?
Using '--reference clone1 --reference linux-2.6' for the second clone
works OK, but surely it ought to work with just '--reference clone1'?
It doesn't work -- it can't find the objects which are in the original
linux-2.6 tree....
(linux-2.6 contains a current copy of linus' tree)
shinybook /shiny/git $ git-clone --reference linux-2.6 git://git.infradead.org/mtd-2.6.git clone1
Checking files out...
100% (19552/19552) done
shinybook /shiny/git $ git-clone --reference clone1 git://git.infradead.org/mtd-2.6.git clone2
error: refs/reference-tmp/refs/tags/v2.6.13-rc7 does not point to a valid commit object!
error: refs/reference-tmp/refs/tags/v2.6.13-rc2 does not point to a valid commit object!
error: refs/reference-tmp/refs/tags/v2.6.14 does not point to a valid commit object!
< ..... >
error: refs/reference-tmp/refs/tags/v2.6.14-rc1 does not point to a valid commit object!
error: refs/reference-tmp/refs/tags/v2.6.15-rc2 does not point to a valid commit object!
error: refs/reference-tmp/refs/tags/v2.6.13-rc6 does not point to a valid commit object!
error: refs/reference-tmp/refs/tags/v2.6.13-rc4 does not point to a valid commit object!
error: Could not read 7e6684741b15e98dd52bd0dbcb08a4eb69857c23
error: Could not read 7e6684741b15e98dd52bd0dbcb08a4eb69857c23
error: Could not read 7260448207915a170bb812f8639a90a30329adce
error: Could not read 7260448207915a170bb812f8639a90a30329adce
error: Could not read acf8d9bd83be879328c558400d94ee61fc229672
error: Could not read acf8d9bd83be879328c558400d94ee61fc229672
error: Could not read c7270e76718f635bed33afe6c4751a270b2d031b
error: Could not read c7270e76718f635bed33afe6c4751a270b2d031b
error: Could not read 0a8763981774041f3fee0a71e016dcaa096fa3f8
error: Could not read 0a8763981774041f3fee0a71e016dcaa096fa3f8
error: Could not read 4a47136ddde07488a5741e6be267b8f5bddc407b
error: Could not read 4a47136ddde07488a5741e6be267b8f5bddc407b
error: Could not read 6cad1d2664ec091ba5a6f3e3e552cf550ec8c2e0
error: Could not read 6cad1d2664ec091ba5a6f3e3e552cf550ec8c2e0
< ..... >
error: Could not read a0d4c65cd5642e7f7bbd2f806a69d20b2e43edc4
error: Could not read 611dd7a56906343db81c9fe340be0eb78c4ec260
error: Could not read 611dd7a56906343db81c9fe340be0eb78c4ec260
error: Could not read 227b4665ae0105348868d7a0a577209c8d16c6e3
error: Could not read 227b4665ae0105348868d7a0a577209c8d16c6e3
error: Could not read 9f19a4bfe0d0f0d203113d34d7455ceb82ff8341
error: Could not read 9f19a4bfe0d0f0d203113d34d7455ceb82ff8341
Checking files out...
error: git-checkout-index: unable to read sha1 file of .gitignore (27fd37621255799602d74e94d670ff7a1658d40a)
error: git-checkout-index: unable to read sha1 file of COPYING (ca442d313d86dc67e0a2e5d584b465bd382cbf5c)
error: git-checkout-index: unable to read sha1 file of CREDITS (787564bc248b1d6125fc42f3932966b60aa2f7f4)
error: git-checkout-index: unable to read sha1 file of Kbuild (2d4f95e4b89f7f81da6cb94b07e8449b3689ba37)
error: git-checkout-index: unable to read sha1 file of Makefile (fc8e08c419f09e81252f3aa41cb7f47524c0af60)
error: git-checkout-index: unable to read sha1 file of README (05e055530bbb687599dd732d6753c77ffa281ae5)
< .....>
--
dwmw2
^ permalink raw reply
* Re: lstat() call in rev-parse.c
From: Linus Torvalds @ 2006-04-23 16:19 UTC (permalink / raw)
To: Paul Mackerras; +Cc: git
In-Reply-To: <17483.27938.890830.375324@cargo.ozlabs.ibm.com>
On Sun, 23 Apr 2006, Paul Mackerras wrote:
>
> Why does git-rev-parse do an lstat on some of its arguments, at line
> 345 of rev-parse.c, and die if the lstat fails? It doesn't seem to do
> anything with the result.
>
> The effect is that if you do "gitk a b", it works as long as a and b
> exist (as files or directories), but fails if they don't, and some
> users have found this confusing.
Because it's even _more_ common to do
gitk v2.6.16
(in the git directory) and be very confused when that returns an empty
history.
So the rule is: if you don't give that "--", then we have to be able to
confirm that the filenames are really files. Not a misspelled revision
name, or a revision name that was correctly spelled, but for the wrong
project, because you were in the wrong subdirectory ;)
And yes, this actually happened to me. I was demonstrating git before we
did that fix, and I used the wrong tag-name, and gitk would think for a
minute and them show "No commits selected" with no error, because
"v2.6.16" didn't exist at that time, and it used the "tag-name" as a
filename, and that filename didn't actually exist, so the number of
commits that changed it was exactly zero.
So now, if you do "gitk v2.6.16" in the git directory, it will return a
nice and understandable
Error reading commits: fatal: 'v2.6.16': No such file or directory
which is _exactly_ what you want. The only problem is that gitk will
actually open the big window too, and the error window is small and can be
non-obvious if the window manager hides it in some corner. So I actually
think you should try to make the error window come up smack dab in front
of the main gitk window and make the error clearer.
So the rules are simple:
- the filenames are _always_ separated by "--"
- we have a short-hand, which allows the "--" to be dropped iff it is
unambiguous
Where "unambiguous" means that
- the revision name cannot possible be interpreted as a filename (we
don't check this part yet, but I think we should)
- all filenames are obviously not revision names, since they not
only aren't valid revisions, they actually exist as files.
Otherwise, misspellings, typos, and thinkos result in total confusion.
Linus
^ permalink raw reply
* lstat() call in rev-parse.c
From: Paul Mackerras @ 2006-04-23 12:03 UTC (permalink / raw)
To: git
Why does git-rev-parse do an lstat on some of its arguments, at line
345 of rev-parse.c, and die if the lstat fails? It doesn't seem to do
anything with the result.
The effect is that if you do "gitk a b", it works as long as a and b
exist (as files or directories), but fails if they don't, and some
users have found this confusing. Yes they should put in a --, but
it's not obvious to users why this should make it work in the case
when a or b doesn't exist.
(And yes I just took out the git-rev-parse call from gitk, but I'm
going to need to do git-rev-parse --no-refs --no-flags for some
changes I'm doing at the moment.)
Paul.
^ permalink raw reply
* Re: make update-index --chmod work with multiple files and --stdin
From: Alex Riesen @ 2006-04-23 7:08 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wvpi010.fsf@assigned-by-dhcp.cox.net>
[-- Attachment #1: Type: text/plain, Size: 950 bytes --]
Junio C Hamano, Sun, Apr 23, 2006 02:54:51 +0200:
> Alex Riesen <raa.lkml@gmail.com> writes:
>
> > I had a project where lots of files were "accidentally" marked +x, and
> > doing plain "git-update-index --chmod=-x" for each file was too slow.
> > Besides, it's somewhat inconsistent, that --chmod does work only for
> > one subsequent file.
>
> If you are doing that on the command line, people may want to
> have a way to mean "from here on do not do chmod, just do normal
> update-index and nothing else" by resetting the chmod_mode thing
> back to zero. Nothing major, and we do not do that to allow_add
> and allow_remove either, but just a thought.
I am unsure about this. I'm even attaching instead of inlining the
patches, to make it clear how unsure I am :)
I have a feeling that it's more understandable to just use two
separate commands. Besides, the reset switch makes it impossible to
use pathname disambiguation ("--"). Unsure...
[-- Attachment #2: 0002-git-update-index-no-chmod.txt --]
[-- Type: text/plain, Size: 1352 bytes --]
>From nobody Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Sun Apr 23 08:38:04 2006 +0200
Subject: git-update-index --no-chmod
Message-ID: <7v1wvpi010.fsf@assigned-by-dhcp.cox.net>
Alex Riesen <raa.lkml@gmail.com> writes:
> I had a project where lots of files were "accidentally" marked +x, and
> doing plain "git-update-index --chmod=-x" for each file was too slow.
> Besides, it's somewhat inconsistent, that --chmod does work only for
> one subsequent file.
If you are doing that on the command line, people may want to
have a way to mean "from here on do not do chmod, just do normal
update-index and nothing else" by resetting the chmod_mode thing
back to zero. Nothing major, and we do not do that to allow_add
and allow_remove either, but just a thought.
---
update-index.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
2972ef33fa4b04f07d4f4dbb9e13d5b9b2d593b4
diff --git a/update-index.c b/update-index.c
index a8582ea..1ed36fa 100644
--- a/update-index.c
+++ b/update-index.c
@@ -551,6 +551,10 @@ int main(int argc, const char **argv)
set_executable_bit = path[8];
continue;
}
+ if (!strcmp(path, "--no-chmod")) {
+ set_executable_bit = 0;
+ continue;
+ }
if (!strcmp(path, "--assume-unchanged")) {
mark_valid_only = MARK_VALID;
continue;
--
1.3.0.gc2941
[-- Attachment #3: 0003-git-update-index-add-no-add-and-no-remove.txt --]
[-- Type: text/plain, Size: 1595 bytes --]
>From nobody Mon Sep 17 00:00:00 2001
From: Junio C Hamano <junkio@cox.net>
Date: Sun Apr 23 08:43:42 2006 +0200
Subject: git-update-index: add --no-add and --no-remove
Message-ID: <7v1wvpi010.fsf@assigned-by-dhcp.cox.net>
Alex Riesen <raa.lkml@gmail.com> writes:
> I had a project where lots of files were "accidentally" marked +x, and
> doing plain "git-update-index --chmod=-x" for each file was too slow.
> Besides, it's somewhat inconsistent, that --chmod does work only for
> one subsequent file.
If you are doing that on the command line, people may want to
have a way to mean "from here on do not do chmod, just do normal
update-index and nothing else" by resetting the chmod_mode thing
back to zero. Nothing major, and we do not do that to allow_add
and allow_remove either, but just a thought.
---
update-index.c | 8 ++++++++
1 files changed, 8 insertions(+), 0 deletions(-)
89bceee48996f366a779b0c95ba230ec24fea340
diff --git a/update-index.c b/update-index.c
index 1ed36fa..cbee859 100644
--- a/update-index.c
+++ b/update-index.c
@@ -509,6 +509,10 @@ int main(int argc, const char **argv)
allow_add = 1;
continue;
}
+ if (!strcmp(path, "--no-add")) {
+ allow_add = 0;
+ continue;
+ }
if (!strcmp(path, "--replace")) {
allow_replace = 1;
continue;
@@ -517,6 +521,10 @@ int main(int argc, const char **argv)
allow_remove = 1;
continue;
}
+ if (!strcmp(path, "--no-remove")) {
+ allow_remove = 0;
+ continue;
+ }
if (!strcmp(path, "--unmerged")) {
allow_unmerged = 1;
continue;
--
1.3.0.gc2941
^ permalink raw reply related
* Re: make update-index --chmod work with multiple files and --stdin
From: Alex Riesen @ 2006-04-23 7:01 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1wvpi010.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Sun, Apr 23, 2006 02:54:51 +0200:
> > I had a project where lots of files were "accidentally" marked +x, and
> > doing plain "git-update-index --chmod=-x" for each file was too slow.
> > Besides, it's somewhat inconsistent, that --chmod does work only for
> > one subsequent file.
>
> If you are doing that on the command line, people may want to
> have a way to mean "from here on do not do chmod, just do normal
> update-index and nothing else" by resetting the chmod_mode thing
> back to zero. Nothing major, and we do not do that to allow_add
> and allow_remove either, but just a thought.
Not sure about that, but did it anyway (as separate patches).
I updated the patch with the other remarks regarding
set_executable_bit, whitespaces and die in chmod_path (thought about
this one myself, but was lazy).
---
update-index.c | 23 ++++++++++++++++-------
1 files changed, 16 insertions(+), 7 deletions(-)
92d1372fd0358811a5f2670b99a6a304dadb7864
diff --git a/update-index.c b/update-index.c
index 1efac27..a8582ea 100644
--- a/update-index.c
+++ b/update-index.c
@@ -328,7 +328,7 @@ static int add_cacheinfo(unsigned int mo
return 0;
}
-static int chmod_path(int flip, const char *path)
+static void chmod_path(int flip, const char *path)
{
int pos;
struct cache_entry *ce;
@@ -336,21 +336,24 @@ static int chmod_path(int flip, const ch
pos = cache_name_pos(path, strlen(path));
if (pos < 0)
- return -1;
+ goto _fail;
ce = active_cache[pos];
mode = ntohl(ce->ce_mode);
if (!S_ISREG(mode))
- return -1;
+ goto _fail;
switch (flip) {
case '+':
ce->ce_mode |= htonl(0111); break;
case '-':
ce->ce_mode &= htonl(~0111); break;
default:
- return -1;
+ goto _fail;
}
active_cache_changed = 1;
- return 0;
+ report("chmod %cx '%s'", flip, path);
+ return;
+_fail:
+ die("git-update-index: cannot chmod %cx '%s'", flip, path);
}
static struct cache_file cache_file;
@@ -478,6 +481,7 @@ int main(int argc, const char **argv)
int read_from_stdin = 0;
const char *prefix = setup_git_directory();
int prefix_length = prefix ? strlen(prefix) : 0;
+ char set_executable_bit = 0;
git_config(git_default_config);
@@ -544,8 +548,7 @@ int main(int argc, const char **argv)
!strcmp(path, "--chmod=+x")) {
if (argc <= i+1)
die("git-update-index: %s <path>", path);
- if (chmod_path(path[8], argv[++i]))
- die("git-update-index: %s cannot chmod %s", path, argv[i]);
+ set_executable_bit = path[8];
continue;
}
if (!strcmp(path, "--assume-unchanged")) {
@@ -594,6 +597,8 @@ int main(int argc, const char **argv)
die("unknown option %s", path);
}
update_one(path, prefix, prefix_length);
+ if (set_executable_bit)
+ chmod_path(set_executable_bit, path);
}
if (read_from_stdin) {
struct strbuf buf;
@@ -608,6 +613,10 @@ int main(int argc, const char **argv)
else
path_name = buf.buf;
update_one(path_name, prefix, prefix_length);
+ if (set_executable_bit) {
+ const char *p = prefix_path(prefix, prefix_length, path_name);
+ chmod_path(set_executable_bit, p);
+ }
if (path_name != buf.buf)
free(path_name);
}
--
1.3.0.gc2941
^ permalink raw reply related
* Re: RFC: New diff-delta.c implementation
From: Geert Bosch @ 2006-04-23 2:31 UTC (permalink / raw)
To: Davide Libenzi; +Cc: git
In-Reply-To: <Pine.LNX.4.64.0604221333470.23166@alien.or.mcafeemobile.com>
On Sat, Apr 22, 2006 at 01:36:07PM -0700, Davide Libenzi wrote:
> Geert, I saw you're using a shift of 55 bits, that gives an degree of the
> root polynomial of 63, that is not prime. Where did you get the root
> polynomial, and why you did not chose 61 as degree of the root?
> Just curious ...
The polynomial was randomly created using code by David Mazieres, that
is part of LBFS. I chose a (irreducible) polynomial of degree 63 as
that was the same as LBFS did. As for my purposes it's best to have
a constant polynomial and I wanted to have all the code for
the computations in the same compilation unit for performance,
I decided to just have a little program print out the tables
and include it directly. The chosen polynomial was 0xb15e234bd3792f63.
Later on I haven't revisited this decision, although I agree that
it'd probably be a good idea to use a polynomial of prime degree,
even though we're not looking for cryptographically strong hashes here.
Below I include new tables for degree 61. The window size of 22 was
found by plotting graphs on a number of largish test cases (30-100MB)
and seeing how the size of the compressed output changed. It is
essential to do all comparisons using gzipped output. I've been
tempted a number of times to include new optimizations, only
to find out that the uncompressed size reduced, but final compressed
size grew. More smaller copies and literal data segments is generally
worse.
-Geert
#define RABIN_POLY 0x25bd5331c0d7096dULL
#define RABIN_DEGREE 61
#define RABIN_SHIFT 53
#define RABIN_WINDOW_SIZE 22
unsigned long long T[256] =
{ 0x0000000000000000ULL, 0x25bd5331c0d7096dULL, 0x4b7aa66381ae12daULL,
0x6ec7f55241791bb7ULL, 0x96f54cc7035c25b4ULL, 0xb3481ff6c38b2cd9ULL,
0xdd8feaa482f2376eULL, 0xf832b99542253e03ULL, 0x0857cabfc66f4205ULL,
0x2dea998e06b84b68ULL, 0x432d6cdc47c150dfULL, 0x66903fed871659b2ULL,
0x9ea28678c53367b1ULL, 0xbb1fd54905e46edcULL, 0xd5d8201b449d756bULL,
0xf065732a844a7c06ULL, 0x10af957f8cde840aULL, 0x3512c64e4c098d67ULL,
0x5bd5331c0d7096d0ULL, 0x7e68602dcda79fbdULL, 0x865ad9b88f82a1beULL,
0xa3e78a894f55a8d3ULL, 0xcd207fdb0e2cb364ULL, 0xe89d2ceacefbba09ULL,
0x18f85fc04ab1c60fULL, 0x3d450cf18a66cf62ULL, 0x5382f9a3cb1fd4d5ULL,
0x763faa920bc8ddb8ULL, 0x8e0d130749ede3bbULL, 0xabb04036893aead6ULL,
0xc577b564c843f161ULL, 0xe0cae6550894f80cULL, 0x04e279ced96a0179ULL,
0x215f2aff19bd0814ULL, 0x4f98dfad58c413a3ULL, 0x6a258c9c98131aceULL,
0x92173509da3624cdULL, 0xb7aa66381ae12da0ULL, 0xd96d936a5b983617ULL,
0xfcd0c05b9b4f3f7aULL, 0x0cb5b3711f05437cULL, 0x2908e040dfd24a11ULL,
0x47cf15129eab51a6ULL, 0x627246235e7c58cbULL, 0x9a40ffb61c5966c8ULL,
0xbffdac87dc8e6fa5ULL, 0xd13a59d59df77412ULL, 0xf4870ae45d207d7fULL,
0x144decb155b48573ULL, 0x31f0bf8095638c1eULL, 0x5f374ad2d41a97a9ULL,
0x7a8a19e314cd9ec4ULL, 0x82b8a07656e8a0c7ULL, 0xa705f347963fa9aaULL,
0xc9c20615d746b21dULL, 0xec7f55241791bb70ULL, 0x1c1a260e93dbc776ULL,
0x39a7753f530cce1bULL, 0x5760806d1275d5acULL, 0x72ddd35cd2a2dcc1ULL,
0x8aef6ac99087e2c2ULL, 0xaf5239f85050ebafULL, 0xc195ccaa1129f018ULL,
0xe4289f9bd1fef975ULL, 0x09c4f39db2d402f2ULL, 0x2c79a0ac72030b9fULL,
0x42be55fe337a1028ULL, 0x670306cff3ad1945ULL, 0x9f31bf5ab1882746ULL,
0xba8cec6b715f2e2bULL, 0xd44b19393026359cULL, 0xf1f64a08f0f13cf1ULL,
0x0193392274bb40f7ULL, 0x242e6a13b46c499aULL, 0x4ae99f41f515522dULL,
0x6f54cc7035c25b40ULL, 0x976675e577e76543ULL, 0xb2db26d4b7306c2eULL,
0xdc1cd386f6497799ULL, 0xf9a180b7369e7ef4ULL, 0x196b66e23e0a86f8ULL,
0x3cd635d3fedd8f95ULL, 0x5211c081bfa49422ULL, 0x77ac93b07f739d4fULL,
0x8f9e2a253d56a34cULL, 0xaa237914fd81aa21ULL, 0xc4e48c46bcf8b196ULL,
0xe159df777c2fb8fbULL, 0x113cac5df865c4fdULL, 0x3481ff6c38b2cd90ULL,
0x5a460a3e79cbd627ULL, 0x7ffb590fb91cdf4aULL, 0x87c9e09afb39e149ULL,
0xa274b3ab3beee824ULL, 0xccb346f97a97f393ULL, 0xe90e15c8ba40fafeULL,
0x0d268a536bbe038bULL, 0x289bd962ab690ae6ULL, 0x465c2c30ea101151ULL,
0x63e17f012ac7183cULL, 0x9bd3c69468e2263fULL, 0xbe6e95a5a8352f52ULL,
0xd0a960f7e94c34e5ULL, 0xf51433c6299b3d88ULL, 0x057140ecadd1418eULL,
0x20cc13dd6d0648e3ULL, 0x4e0be68f2c7f5354ULL, 0x6bb6b5beeca85a39ULL,
0x93840c2bae8d643aULL, 0xb6395f1a6e5a6d57ULL, 0xd8feaa482f2376e0ULL,
0xfd43f979eff47f8dULL, 0x1d891f2ce7608781ULL, 0x38344c1d27b78eecULL,
0x56f3b94f66ce955bULL, 0x734eea7ea6199c36ULL, 0x8b7c53ebe43ca235ULL,
0xaec100da24ebab58ULL, 0xc006f5886592b0efULL, 0xe5bba6b9a545b982ULL,
0x15ded593210fc584ULL, 0x306386a2e1d8cce9ULL, 0x5ea473f0a0a1d75eULL,
0x7b1920c16076de33ULL, 0x832b99542253e030ULL, 0xa696ca65e284e95dULL,
0xc8513f37a3fdf2eaULL, 0xedec6c06632afb87ULL, 0x1389e73b65a805e4ULL,
0x3634b40aa57f0c89ULL, 0x58f34158e406173eULL, 0x7d4e126924d11e53ULL,
0x857cabfc66f42050ULL, 0xa0c1f8cda623293dULL, 0xce060d9fe75a328aULL,
0xebbb5eae278d3be7ULL, 0x1bde2d84a3c747e1ULL, 0x3e637eb563104e8cULL,
0x50a48be72269553bULL, 0x7519d8d6e2be5c56ULL, 0x8d2b6143a09b6255ULL,
0xa8963272604c6b38ULL, 0xc651c7202135708fULL, 0xe3ec9411e1e279e2ULL,
0x03267244e97681eeULL, 0x269b217529a18883ULL, 0x485cd42768d89334ULL,
0x6de18716a80f9a59ULL, 0x95d33e83ea2aa45aULL, 0xb06e6db22afdad37ULL,
0xdea998e06b84b680ULL, 0xfb14cbd1ab53bfedULL, 0x0b71b8fb2f19c3ebULL,
0x2eccebcaefceca86ULL, 0x400b1e98aeb7d131ULL, 0x65b64da96e60d85cULL,
0x9d84f43c2c45e65fULL, 0xb839a70dec92ef32ULL, 0xd6fe525fadebf485ULL,
0xf343016e6d3cfde8ULL, 0x176b9ef5bcc2049dULL, 0x32d6cdc47c150df0ULL,
0x5c1138963d6c1647ULL, 0x79ac6ba7fdbb1f2aULL, 0x819ed232bf9e2129ULL,
0xa42381037f492844ULL, 0xcae474513e3033f3ULL, 0xef592760fee73a9eULL,
0x1f3c544a7aad4698ULL, 0x3a81077bba7a4ff5ULL, 0x5446f229fb035442ULL,
0x71fba1183bd45d2fULL, 0x89c9188d79f1632cULL, 0xac744bbcb9266a41ULL,
0xc2b3beeef85f71f6ULL, 0xe70eeddf3888789bULL, 0x07c40b8a301c8097ULL,
0x227958bbf0cb89faULL, 0x4cbeade9b1b2924dULL, 0x6903fed871659b20ULL,
0x9131474d3340a523ULL, 0xb48c147cf397ac4eULL, 0xda4be12eb2eeb7f9ULL,
0xfff6b21f7239be94ULL, 0x0f93c135f673c292ULL, 0x2a2e920436a4cbffULL,
0x44e9675677ddd048ULL, 0x61543467b70ad925ULL, 0x99668df2f52fe726ULL,
0xbcdbdec335f8ee4bULL, 0xd21c2b917481f5fcULL, 0xf7a178a0b456fc91ULL,
0x1a4d14a6d77c0716ULL, 0x3ff0479717ab0e7bULL, 0x5137b2c556d215ccULL,
0x748ae1f496051ca1ULL, 0x8cb85861d42022a2ULL, 0xa9050b5014f72bcfULL,
0xc7c2fe02558e3078ULL, 0xe27fad3395593915ULL, 0x121ade1911134513ULL,
0x37a78d28d1c44c7eULL, 0x5960787a90bd57c9ULL, 0x7cdd2b4b506a5ea4ULL,
0x84ef92de124f60a7ULL, 0xa152c1efd29869caULL, 0xcf9534bd93e1727dULL,
0xea28678c53367b10ULL, 0x0ae281d95ba2831cULL, 0x2f5fd2e89b758a71ULL,
0x419827bada0c91c6ULL, 0x6425748b1adb98abULL, 0x9c17cd1e58fea6a8ULL,
0xb9aa9e2f9829afc5ULL, 0xd76d6b7dd950b472ULL, 0xf2d0384c1987bd1fULL,
0x02b54b669dcdc119ULL, 0x270818575d1ac874ULL, 0x49cfed051c63d3c3ULL,
0x6c72be34dcb4daaeULL, 0x944007a19e91e4adULL, 0xb1fd54905e46edc0ULL,
0xdf3aa1c21f3ff677ULL, 0xfa87f2f3dfe8ff1aULL, 0x1eaf6d680e16066fULL,
0x3b123e59cec10f02ULL, 0x55d5cb0b8fb814b5ULL, 0x7068983a4f6f1dd8ULL,
0x885a21af0d4a23dbULL, 0xade7729ecd9d2ab6ULL, 0xc32087cc8ce43101ULL,
0xe69dd4fd4c33386cULL, 0x16f8a7d7c879446aULL, 0x3345f4e608ae4d07ULL,
0x5d8201b449d756b0ULL, 0x783f528589005fddULL, 0x800deb10cb2561deULL,
0xa5b0b8210bf268b3ULL, 0xcb774d734a8b7304ULL, 0xeeca1e428a5c7a69ULL,
0x0e00f81782c88265ULL, 0x2bbdab26421f8b08ULL, 0x457a5e74036690bfULL,
0x60c70d45c3b199d2ULL, 0x98f5b4d08194a7d1ULL, 0xbd48e7e14143aebcULL,
0xd38f12b3003ab50bULL, 0xf6324182c0edbc66ULL, 0x065732a844a7c060ULL,
0x23ea61998470c90dULL, 0x4d2d94cbc509d2baULL, 0x6890c7fa05dedbd7ULL,
0x90a27e6f47fbe5d4ULL, 0xb51f2d5e872cecb9ULL, 0xdbd8d80cc655f70eULL,
0xfe658b3d0682fe63ULL
};
unsigned long long U[256] =
{ 0x0000000000000000ULL, 0x067b86c43d6a6cb0ULL, 0x0cf70d887ad4d960ULL,
0x0a8c8b4c47beb5d0ULL, 0x19ee1b10f5a9b2c0ULL, 0x1f959dd4c8c3de70ULL,
0x151916988f7d6ba0ULL, 0x1362905cb2170710ULL, 0x166165102b846cedULL,
0x101ae3d416ee005dULL, 0x1a9668985150b58dULL, 0x1cedee5c6c3ad93dULL,
0x0f8f7e00de2dde2dULL, 0x09f4f8c4e347b29dULL, 0x03787388a4f9074dULL,
0x0503f54c99936bfdULL, 0x097f991197dfd0b7ULL, 0x0f041fd5aab5bc07ULL,
0x05889499ed0b09d7ULL, 0x03f3125dd0616567ULL, 0x1091820162766277ULL,
0x16ea04c55f1c0ec7ULL, 0x1c668f8918a2bb17ULL, 0x1a1d094d25c8d7a7ULL,
0x1f1efc01bc5bbc5aULL, 0x19657ac58131d0eaULL, 0x13e9f189c68f653aULL,
0x1592774dfbe5098aULL, 0x06f0e71149f20e9aULL, 0x008b61d57498622aULL,
0x0a07ea993326d7faULL, 0x0c7c6c5d0e4cbb4aULL, 0x12ff32232fbfa16eULL,
0x1484b4e712d5cddeULL, 0x1e083fab556b780eULL, 0x1873b96f680114beULL,
0x0b112933da1613aeULL, 0x0d6aaff7e77c7f1eULL, 0x07e624bba0c2caceULL,
0x019da27f9da8a67eULL, 0x049e5733043bcd83ULL, 0x02e5d1f73951a133ULL,
0x08695abb7eef14e3ULL, 0x0e12dc7f43857853ULL, 0x1d704c23f1927f43ULL,
0x1b0bcae7ccf813f3ULL, 0x118741ab8b46a623ULL, 0x17fcc76fb62cca93ULL,
0x1b80ab32b86071d9ULL, 0x1dfb2df6850a1d69ULL, 0x1777a6bac2b4a8b9ULL,
0x110c207effdec409ULL, 0x026eb0224dc9c319ULL, 0x041536e670a3afa9ULL,
0x0e99bdaa371d1a79ULL, 0x08e23b6e0a7776c9ULL, 0x0de1ce2293e41d34ULL,
0x0b9a48e6ae8e7184ULL, 0x0116c3aae930c454ULL, 0x076d456ed45aa8e4ULL,
0x140fd532664daff4ULL, 0x127453f65b27c344ULL, 0x18f8d8ba1c997694ULL,
0x1e835e7e21f31a24ULL, 0x004337779fa84bb1ULL, 0x0638b1b3a2c22701ULL,
0x0cb43affe57c92d1ULL, 0x0acfbc3bd816fe61ULL, 0x19ad2c676a01f971ULL,
0x1fd6aaa3576b95c1ULL, 0x155a21ef10d52011ULL, 0x1321a72b2dbf4ca1ULL,
0x16225267b42c275cULL, 0x1059d4a389464becULL, 0x1ad55fefcef8fe3cULL,
0x1caed92bf392928cULL, 0x0fcc49774185959cULL, 0x09b7cfb37ceff92cULL,
0x033b44ff3b514cfcULL, 0x0540c23b063b204cULL, 0x093cae6608779b06ULL,
0x0f4728a2351df7b6ULL, 0x05cba3ee72a34266ULL, 0x03b0252a4fc92ed6ULL,
0x10d2b576fdde29c6ULL, 0x16a933b2c0b44576ULL, 0x1c25b8fe870af0a6ULL,
0x1a5e3e3aba609c16ULL, 0x1f5dcb7623f3f7ebULL, 0x19264db21e999b5bULL,
0x13aac6fe59272e8bULL, 0x15d1403a644d423bULL, 0x06b3d066d65a452bULL,
0x00c856a2eb30299bULL, 0x0a44ddeeac8e9c4bULL, 0x0c3f5b2a91e4f0fbULL,
0x12bc0554b017eadfULL, 0x14c783908d7d866fULL, 0x1e4b08dccac333bfULL,
0x18308e18f7a95f0fULL, 0x0b521e4445be581fULL, 0x0d29988078d434afULL,
0x07a513cc3f6a817fULL, 0x01de95080200edcfULL, 0x04dd60449b938632ULL,
0x02a6e680a6f9ea82ULL, 0x082a6dcce1475f52ULL, 0x0e51eb08dc2d33e2ULL,
0x1d337b546e3a34f2ULL, 0x1b48fd9053505842ULL, 0x11c476dc14eeed92ULL,
0x17bff01829848122ULL, 0x1bc39c4527c83a68ULL, 0x1db81a811aa256d8ULL,
0x173491cd5d1ce308ULL, 0x114f170960768fb8ULL, 0x022d8755d26188a8ULL,
0x04560191ef0be418ULL, 0x0eda8adda8b551c8ULL, 0x08a10c1995df3d78ULL,
0x0da2f9550c4c5685ULL, 0x0bd97f9131263a35ULL, 0x0155f4dd76988fe5ULL,
0x072e72194bf2e355ULL, 0x144ce245f9e5e445ULL, 0x12376481c48f88f5ULL,
0x18bbefcd83313d25ULL, 0x1ec06909be5b5195ULL, 0x00866eef3f509762ULL,
0x06fde82b023afbd2ULL, 0x0c71636745844e02ULL, 0x0a0ae5a378ee22b2ULL,
0x196875ffcaf925a2ULL, 0x1f13f33bf7934912ULL, 0x159f7877b02dfcc2ULL,
0x13e4feb38d479072ULL, 0x16e70bff14d4fb8fULL, 0x109c8d3b29be973fULL,
0x1a1006776e0022efULL, 0x1c6b80b3536a4e5fULL, 0x0f0910efe17d494fULL,
0x0972962bdc1725ffULL, 0x03fe1d679ba9902fULL, 0x05859ba3a6c3fc9fULL,
0x09f9f7fea88f47d5ULL, 0x0f82713a95e52b65ULL, 0x050efa76d25b9eb5ULL,
0x03757cb2ef31f205ULL, 0x1017ecee5d26f515ULL, 0x166c6a2a604c99a5ULL,
0x1ce0e16627f22c75ULL, 0x1a9b67a21a9840c5ULL, 0x1f9892ee830b2b38ULL,
0x19e3142abe614788ULL, 0x136f9f66f9dff258ULL, 0x151419a2c4b59ee8ULL,
0x067689fe76a299f8ULL, 0x000d0f3a4bc8f548ULL, 0x0a8184760c764098ULL,
0x0cfa02b2311c2c28ULL, 0x12795ccc10ef360cULL, 0x1402da082d855abcULL,
0x1e8e51446a3bef6cULL, 0x18f5d780575183dcULL, 0x0b9747dce54684ccULL,
0x0decc118d82ce87cULL, 0x07604a549f925dacULL, 0x011bcc90a2f8311cULL,
0x041839dc3b6b5ae1ULL, 0x0263bf1806013651ULL, 0x08ef345441bf8381ULL,
0x0e94b2907cd5ef31ULL, 0x1df622cccec2e821ULL, 0x1b8da408f3a88491ULL,
0x11012f44b4163141ULL, 0x177aa980897c5df1ULL, 0x1b06c5dd8730e6bbULL,
0x1d7d4319ba5a8a0bULL, 0x17f1c855fde43fdbULL, 0x118a4e91c08e536bULL,
0x02e8decd7299547bULL, 0x049358094ff338cbULL, 0x0e1fd345084d8d1bULL,
0x086455813527e1abULL, 0x0d67a0cdacb48a56ULL, 0x0b1c260991dee6e6ULL,
0x0190ad45d6605336ULL, 0x07eb2b81eb0a3f86ULL, 0x1489bbdd591d3896ULL,
0x12f23d1964775426ULL, 0x187eb65523c9e1f6ULL, 0x1e0530911ea38d46ULL,
0x00c55998a0f8dcd3ULL, 0x06bedf5c9d92b063ULL, 0x0c325410da2c05b3ULL,
0x0a49d2d4e7466903ULL, 0x192b428855516e13ULL, 0x1f50c44c683b02a3ULL,
0x15dc4f002f85b773ULL, 0x13a7c9c412efdbc3ULL, 0x16a43c888b7cb03eULL,
0x10dfba4cb616dc8eULL, 0x1a533100f1a8695eULL, 0x1c28b7c4ccc205eeULL,
0x0f4a27987ed502feULL, 0x0931a15c43bf6e4eULL, 0x03bd2a100401db9eULL,
0x05c6acd4396bb72eULL, 0x09bac08937270c64ULL, 0x0fc1464d0a4d60d4ULL,
0x054dcd014df3d504ULL, 0x03364bc57099b9b4ULL, 0x1054db99c28ebea4ULL,
0x162f5d5dffe4d214ULL, 0x1ca3d611b85a67c4ULL, 0x1ad850d585300b74ULL,
0x1fdba5991ca36089ULL, 0x19a0235d21c90c39ULL, 0x132ca8116677b9e9ULL,
0x15572ed55b1dd559ULL, 0x0635be89e90ad249ULL, 0x004e384dd460bef9ULL,
0x0ac2b30193de0b29ULL, 0x0cb935c5aeb46799ULL, 0x123a6bbb8f477dbdULL,
0x1441ed7fb22d110dULL, 0x1ecd6633f593a4ddULL, 0x18b6e0f7c8f9c86dULL,
0x0bd470ab7aeecf7dULL, 0x0daff66f4784a3cdULL, 0x07237d23003a161dULL,
0x0158fbe73d507aadULL, 0x045b0eaba4c31150ULL, 0x0220886f99a97de0ULL,
0x08ac0323de17c830ULL, 0x0ed785e7e37da480ULL, 0x1db515bb516aa390ULL,
0x1bce937f6c00cf20ULL, 0x114218332bbe7af0ULL, 0x17399ef716d41640ULL,
0x1b45f2aa1898ad0aULL, 0x1d3e746e25f2c1baULL, 0x17b2ff22624c746aULL,
0x11c979e65f2618daULL, 0x02abe9baed311fcaULL, 0x04d06f7ed05b737aULL,
0x0e5ce43297e5c6aaULL, 0x082762f6aa8faa1aULL, 0x0d2497ba331cc1e7ULL,
0x0b5f117e0e76ad57ULL, 0x01d39a3249c81887ULL, 0x07a81cf674a27437ULL,
0x14ca8caac6b57327ULL, 0x12b10a6efbdf1f97ULL, 0x183d8122bc61aa47ULL,
0x1e4607e6810bc6f7ULL
};
^ permalink raw reply
* Re: Problem with Git in Cygwin on x86-64 platform
From: Junio C Hamano @ 2006-04-23 0:57 UTC (permalink / raw)
To: Tim O'Callaghan; +Cc: git, Alex Riesen
In-Reply-To: <20060422211733.GB7676@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
>> Any ideas on how to start tracking this one down?
>
> Start by going into git/t and running "./t0000-basic.sh -d -v"
I usually do "cd t && sh -x that-test -i -v".
^ permalink raw reply
* Re: make update-index --chmod work with multiple files and --stdin
From: Junio C Hamano @ 2006-04-23 0:54 UTC (permalink / raw)
To: Alex Riesen; +Cc: git
In-Reply-To: <20060422204642.GA7676@steel.home>
Alex Riesen <raa.lkml@gmail.com> writes:
> I had a project where lots of files were "accidentally" marked +x, and
> doing plain "git-update-index --chmod=-x" for each file was too slow.
> Besides, it's somewhat inconsistent, that --chmod does work only for
> one subsequent file.
If you are doing that on the command line, people may want to
have a way to mean "from here on do not do chmod, just do normal
update-index and nothing else" by resetting the chmod_mode thing
back to zero. Nothing major, and we do not do that to allow_add
and allow_remove either, but just a thought.
> + char chmod_mode = 0;
Perhaps "set_executable_bit"?
> + if ( chmod_mode ) {
Please lose ( extra ) whitespaces around parentheses.
> + if ( chmod_mode ) {
Likewise.
> + if (chmod_path(chmod_mode, p))
> + die("git-update-index: cannot chmod %cx %s",
> + chmod_mode, p);
> + }
Might make sense to die inside chmod_path() instead of repeating
the if () { die() } sequence twice? I dunno.
^ permalink raw reply
* Re: Problem with Git in Cygwin on x86-64 platform
From: Alex Riesen @ 2006-04-22 21:17 UTC (permalink / raw)
To: Tim O'Callaghan, git
In-Reply-To: <20060422023029.GC2444@Zangband>
Tim O'Callaghan, Sat, Apr 22, 2006 04:30:30 +0200:
> When running a 'make test' under cygwin on my 64bit machine, and got
> the output below. The reason i cite the 64bit cygwin platform being a
> difference is that i have run 'make test' on the exact same codebase
> on a 32 bit machine. The only difference in compile environment is
> that the cygwin install on the 64 bit machine is as of today, and the
> 32 bit machine was about three days ago.
>
> *** t0000-basic.sh ***
...
> * FAIL 8: git-update-index with --remove should be able to remove.
...
> Any ideas on how to start tracking this one down?
Start by going into git/t and running "./t0000-basic.sh -d -v"
^ permalink raw reply
* Problem with Git in Cygwin on x86-64 platform
From: Tim O'Callaghan @ 2006-04-22 2:30 UTC (permalink / raw)
To: git
When running a 'make test' under cygwin on my 64bit machine, and got
the output below. The reason i cite the 64bit cygwin platform being a
difference is that i have run 'make test' on the exact same codebase
on a 32 bit machine. The only difference in compile environment is
that the cygwin install on the 64 bit machine is as of today, and the
32 bit machine was about three days ago.
----
*** t0000-basic.sh ***
* 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.
* FAIL 8: git-update-index with --remove should be able to remove.
git-update-index --remove should-be-empty
* ok 9: git-write-tree should be able to write an empty tree.
* FAIL 10: validate object ID of a known tree.
test "$tree" = 4b825dc642cb6eb9a060e54bf8d69288fbee4904
* FAIL 11: adding various types of objects with git-update-index --add.
find path* ! -type d -print | xargs git-update-index --add
* ok 12: showing stage with git-ls-files --stage
* FAIL 13: validate git-ls-files output for a known tree.
diff current expected
* ok 14: writing tree out with git-write-tree.
* FAIL 15: validate object ID for a known tree.
test "$tree" = 087704a96baf1c2d1c869a8b084481e121c88b5b
* ok 16: showing tree with git-ls-tree
* FAIL 17: git-ls-tree output for a known tree.
diff current expected
* ok 18: showing tree with git-ls-tree -r
* FAIL 19: git-ls-tree -r output for a known tree.
diff current expected
* FAIL 20: 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 21: validate git-diff-files output for a know cache/work tree state.
git-diff-files >current && diff >/dev/null -b current expected
* FAIL 22: git-update-index --refresh should succeed.
git-update-index --refresh
* ok 23: no diff after checkout and git-update-index --refresh.
* failed 10 among 23 test(s)
-----
Any ideas on how to start tracking this one down?
Tim.
^ permalink raw reply
* Re: RFC: New diff-delta.c implementation
From: Nicolas Pitre @ 2006-04-22 3:19 UTC (permalink / raw)
To: Geert Bosch; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <602974A9-09A3-46E9-92D6-D30728923C11@adacore.com>
On Fri, 21 Apr 2006, Geert Bosch wrote:
> I wrote a new binary differencing algorithm that is both faster
> and generates smaller deltas than the current implementation.
> The format is compatible with that used by patch-delta, so
> it should be easy to integrate.
It looks really interesting.
It ignores the max_size argument but that is trivially fixed.
Then it triggers some assertions in the code when running the test
suite.
> Originally, I wrote this for the GDIFF format, see
> http://www.w3.org/TR/NOTE-gdiff-19970901.
> The adaptation for GIT format was relatively simple, but is not thoroughly
> tested.
Some trivial tests look fine but it fail on some others.
> The code is not derived from libxdiff, but uses the rabin_slide function
> written
> by David Mazieres (dm@uun.org). Also the tables are generated using his code.
> Finally, this was developed on Darwin, and not a Linux system, so some changes
> may be needed.
It does compile out of the box on Linux.
> Please feel free to play around with this code, and give feedback.
> Keep in mind this wasn't originally written for GIT, and C is not
> my native language, so don't mind my formatting etc.
I did reformat it a bit to be more inline with the rest of GIT's coding
style (and to help me read it). I'll look at fixing the issues I can
fix and post it back.
Nicolas
^ permalink raw reply
* [RFC] Loosening path argument check a little bit in revision.c
From: Junio C Hamano @ 2006-04-22 10:15 UTC (permalink / raw)
To: git; +Cc: Linus Torvalds
The argument parser revision.c::setup_revisions() insists on
path arguments that do not follow the double-dash marker to be
paths (either files or directories) that exist in the working
tree. As the fact that diff-files and update-index have
explicit options to ignore "missing" files reminds us,
traditionally we allowed a sparsely populated working tree, so
this check is not very user friendly.
This patch allows non-existing paths to be given without the
double-dash marker as long as they exist in the index, or they
are leading paths of blobs that exist in the index.
A misspelled tag v2.6.16 is not a very likely name to have only
in the index and not in the working tree, so this should not
break the case the original code wanted to fix ;-).
---
* I noticed a breakage in out test scripts while libifying
diff-files. The two-tree fast-forward merge test stuffs an
entry DF/DF in the index while having a working tree file DF,
and run "diff-files DF/DF" to make sure two-way read-tree
left the index dirty. The libified diff-files naturally uses
revision infrastructure to get its parameters, and the path
argument check causes the test to fail without this patch.
This is just an RFC. We can easily rewrite the particular
test to use the double-dash marker, but I suspect existing
porcelains share the same problem, expecting to be able to do
something like this:
$ names=`git diff-files --name-only`
$ git diff-index HEAD $names
Of course, the kosher way is to always use double-dash, like
this:
$ git diff-files -z --name-only |
xargs -0 git diff-index HEAD --
So I am not pushing this too strongly. Comments?
revision.c | 48 ++++++++++++++++++++++++++++++++++++++++++++----
1 files changed, 44 insertions(+), 4 deletions(-)
diff --git a/revision.c b/revision.c
index 113dd5a..9f6dd24 100644
--- a/revision.c
+++ b/revision.c
@@ -504,6 +504,43 @@ void init_revisions(struct rev_info *rev
diff_setup(&revs->diffopt);
}
+static int check_path_arg(const char *path)
+{
+ struct stat st;
+ int tmp = lstat(path, &st);
+ if (!tmp)
+ return 0;
+ tmp = errno;
+ if (!active_cache)
+ read_cache();
+ if (active_cache) {
+ int namelen = strlen(path);
+ int pos = cache_name_pos(path, namelen);
+ if (pos < 0)
+ pos = -pos - 1;
+ if (pos < active_nr) {
+ struct cache_entry *ce = active_cache[pos];
+ if (ce_namelen(ce) == namelen &&
+ !memcmp(ce->name, path, namelen))
+ return 0;
+ }
+ /* Try it as a directory name - "foo/" */
+ while (++pos < active_nr) {
+ struct cache_entry *ce = active_cache[pos];
+ if (namelen < ce_namelen(ce) &&
+ !memcmp(ce->name, path, namelen)) {
+ /* prefix still matches */
+ if (ce->name[namelen] == '/')
+ return 0;
+ }
+ else
+ break; /* prefix does not match anymore */
+ }
+ }
+ errno = tmp;
+ return -1;
+}
+
/*
* Parse revision information, filling in the "rev_info" structure,
* and removing the used arguments from the argument list.
@@ -752,16 +789,19 @@ int setup_revisions(int argc, const char
arg++;
}
if (get_sha1(arg, sha1) < 0) {
- struct stat st;
int j;
if (seen_dashdash || local_flags)
die("bad revision '%s'", arg);
- /* If we didn't have a "--", all filenames must exist */
+ /* If we didn't have a "--", all filenames must
+ * exist, either in the working tree or in the
+ * cache.
+ */
for (j = i; j < argc; j++) {
- if (lstat(argv[j], &st) < 0)
- die("'%s': %s", argv[j], strerror(errno));
+ if (check_path_arg(argv[j]))
+ die("'%s': %s", argv[j],
+ strerror(errno));
}
revs->prune_data = get_pathspec(revs->prefix, argv + i);
break;
^ permalink raw reply related
* make update-index --chmod work with multiple files and --stdin
From: Alex Riesen @ 2006-04-22 20:46 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
I had a project where lots of files were "accidentally" marked +x, and
doing plain "git-update-index --chmod=-x" for each file was too slow.
Besides, it's somewhat inconsistent, that --chmod does work only for
one subsequent file.
---
Yes, windows again.
update-index.c | 16 ++++++++++++++--
1 files changed, 14 insertions(+), 2 deletions(-)
5c7b9c2d187f36ba8b5632d2125f2bd19abb3564
diff --git a/update-index.c b/update-index.c
index 1efac27..c3c2000 100644
--- a/update-index.c
+++ b/update-index.c
@@ -350,6 +350,7 @@ static int chmod_path(int flip, const ch
return -1;
}
active_cache_changed = 1;
+ report("chmod %cx '%s'", flip, path);
return 0;
}
@@ -478,6 +479,7 @@ int main(int argc, const char **argv)
int read_from_stdin = 0;
const char *prefix = setup_git_directory();
int prefix_length = prefix ? strlen(prefix) : 0;
+ char chmod_mode = 0;
git_config(git_default_config);
@@ -544,8 +546,7 @@ int main(int argc, const char **argv)
!strcmp(path, "--chmod=+x")) {
if (argc <= i+1)
die("git-update-index: %s <path>", path);
- if (chmod_path(path[8], argv[++i]))
- die("git-update-index: %s cannot chmod %s", path, argv[i]);
+ chmod_mode = path[8];
continue;
}
if (!strcmp(path, "--assume-unchanged")) {
@@ -594,6 +595,11 @@ int main(int argc, const char **argv)
die("unknown option %s", path);
}
update_one(path, prefix, prefix_length);
+ if ( chmod_mode ) {
+ if (chmod_path(chmod_mode, path))
+ die("git-update-index: cannot chmod %cx %s",
+ chmod_mode, path);
+ }
}
if (read_from_stdin) {
struct strbuf buf;
@@ -608,6 +614,12 @@ int main(int argc, const char **argv)
else
path_name = buf.buf;
update_one(path_name, prefix, prefix_length);
+ if ( chmod_mode ) {
+ const char *p = prefix_path(prefix, prefix_length, path_name);
+ if (chmod_path(chmod_mode, p))
+ die("git-update-index: cannot chmod %cx %s",
+ chmod_mode, p);
+ }
if (path_name != buf.buf)
free(path_name);
}
--
1.3.0.gc2941
^ permalink raw reply related
* Re: [PATCH] Libify diff-files.
From: Junio C Hamano @ 2006-04-22 10:52 UTC (permalink / raw)
To: git; +Cc: torvalds, pasky
In-Reply-To: <7vbqutlxwq.fsf@assigned-by-dhcp.cox.net>
I noticed that there are two flags related to missing working
tree files in diff-files and diff-index. The former takes -q
to mean "do not report lossage of working tree files", and the
latter uses -m to mean "when not using --cached, pretend that
missing working tree files are actually present and match the
index".
Being able to pretend missing working tree files are unchanged
was originally done to help merging in a separate temporary
area, and it is useful, but I wish we used the same flag. I
started wondering if we can unify them to '-q', since '-m'
means "do not ignore merges" in diff-tree context (including
log and whatchanged).
NOTE. -q is different from specifying --diff-filter=ACMRTU;
while the former does not even feed the filepair to diffcore,
the latter tells the diffcore to filter deletion out in the
output phase. The distinction makes huge difference when the
rename/copy detection, especially without --find-copies-harder,
is involved.
Now, as far as I can tell, nobody uses "diff-files -q". Cogito
uses "diff-index -m" quite a bit, but I suspect large part of it
is remnant from the days it did a merge in a separate directory,
and/or a cut-and-paste error from neighbouring "diff-tree -m -r".
A cursory look suggests some could even be bugs. For example,
cg-patch has
diff-tree -m -r "$commitparent" "$commitid"
(where -m does not have any effect) which is immediately
followed by a
diff-index -m -r HEAD
where -m may or may not be intended.
^ permalink raw reply
* Re: What's in git.git
From: Johannes Schindelin @ 2006-04-22 11:25 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, linux-kernel
In-Reply-To: <7vzmieo2j3.fsf@assigned-by-dhcp.cox.net>
Hi,
On Fri, 21 Apr 2006, Junio C Hamano wrote:
> - diff --stat: do not drop rename information.
>
> Johannes suggested "file => /dev/null" to show a deleted
> file as if a rename was done. While I think it makes some
> sense, I am afraid it diverges too much from the traditional
> diffstat output. I am undecided, somewhat negative, about
> the suggestion.
It was not so much a suggestion, but a misinterpretation of your patch. I
am also undecided and slightly negative about it.
> * The 'pu' branch, in addition, has these.
>
> - gitk: Fix geometry on rootless X (Johannes Schindelin)
I talked to Paul about this, and was not only slightly negative about it.
The suggestion was to either use native versions of Tk (which might or
might not fix it), or fix Tk.
Having spent already some time with this workaround, I am not willing to
invest more of it, though.
So, if people want to do something about this patch, go wild.
Ciao,
Dscho
^ permalink raw reply
* Re: RFC: New diff-delta.c implementation
From: Geert Bosch @ 2006-04-22 11:04 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <Pine.LNX.4.64.0604212308080.2215@localhost.localdomain>
[-- Attachment #1: Type: text/plain, Size: 854 bytes --]
On Apr 21, 2006, at 23:19, Nicolas Pitre wrote:
> It looks really interesting.
>
> It ignores the max_size argument but that is trivially fixed.
>
> Then it triggers some assertions in the code when running the test
> suite.
Yes, these were errors in the change to the GIT output format.
They were trivially fixed. More importantly, I didn't finalize
the indexing data, since the code was originally used in a stand-alone
program that would terminate after the diff.
> I did reformat it a bit to be more inline with the rest of GIT's
> coding
> style (and to help me read it). I'll look at fixing the issues I can
> fix and post it back.
Please apply the attached patch first.
-Geert
BTW. It's a shame that we don't reuse the index when comparing one
source
against multiple targets. Creating the index takes about 70% of
the time.
[-- Attachment #2: pat --]
[-- Type: application/octet-stream, Size: 3585 bytes --]
--- diff-delta.c.orig 2006-04-22 06:53:44.000000000 -0400
+++ diff-delta.c 2006-04-22 06:59:14.000000000 -0400
@@ -29,7 +29,7 @@
#define RABIN_WINDOW_SIZE 22
#define RABIN_SHIFT 55
-static unsigned long long T[256] =
+static const unsigned long long T[256] =
{ 0x0000000000000000ULL, 0xb15e234bd3792f63ULL, 0x62bc4697a6f25ec6ULL,
0xd3e265dc758b71a5ULL, 0x7426ae649e9d92efULL, 0xc5788d2f4de4bd8cULL,
0x169ae8f3386fcc29ULL, 0xa7c4cbb8eb16e34aULL, 0x59137f82ee420abdULL,
@@ -118,7 +118,7 @@
0xed7b43a0554e9f70ULL
};
-static unsigned long long U[256] =
+static const unsigned long long U[256] =
{ 0x0000000000000000ULL, 0x079343d61ab9f60eULL, 0x0f2687ac3573ec1cULL,
0x08b5c47a2fca1a12ULL, 0x1e4d0f586ae7d838ULL, 0x19de4c8e705e2e36ULL,
0x116b88f45f943424ULL, 0x16f8cb22452dc22aULL, 0x3c9a1eb0d5cfb070ULL,
@@ -261,7 +261,7 @@
static int copy_count = 0;
static unsigned max_copies = 0; /* Dynamically increased */
-static unsigned *idx;
+static unsigned *idx = 0;
static unsigned idx_size;
static unsigned char *idx_data;
static unsigned idx_data_len;
@@ -406,6 +406,19 @@
{ idx[maxfp[j] % idx_size] = maxofs[j];
} } }
+static void finalize_idx()
+{ if (max_copies > MAX_COPIES)
+ { free (copies);
+ max_copies = 0;
+ copy_count = 0;
+ }
+ if (idx) free (idx);
+ idx = 0;
+ idx_size = 0;
+ idx_data = 0;
+ idx_data_len = 0;
+}
+
static unsigned header_length (unsigned srclen, unsigned tgtlen)
{ unsigned len = 0;
assert (srclen <= MAX_SIZE && tgtlen <= MAX_SIZE);
@@ -420,10 +433,12 @@
}
static unsigned data_length (unsigned length)
-{ assert (length > 0 && length <= MAX_SIZE);
+{ unsigned len = length % 0x7f;
+ assert (length > 0 && length <= MAX_SIZE);
/* Can only include 0x7f data bytes per command */
- return (length / 0x7f) * 0x80 + length % 0x7f + 1;
+ if (len) len++;
+ return len + (length / 0x7f) * 0x80;
}
static unsigned copy_length (unsigned offset, unsigned length)
@@ -624,8 +639,7 @@
static unsigned char *
write_header (unsigned char *patch, unsigned srclen, unsigned tgtlen)
-{
- assert (srclen <= MAX_SIZE && tgtlen <= MAX_SIZE);
+{ assert (srclen <= MAX_SIZE && tgtlen <= MAX_SIZE);
while (srclen >= 0x7f)
{ *patch++= (srclen & 0x7f) | 0x80;
@@ -658,8 +672,9 @@
*patch++ = (unsigned char) size;
memcpy (patch, data, size);
+ patch += size;
- return patch + size;
+ return patch;
}
static unsigned char *
@@ -687,6 +702,7 @@
if (cmd & 0x40) *patch++ = (size >> 16) & 0xff;
size -= chunksize;
}
+
return patch;
}
@@ -699,7 +715,9 @@
unsigned copy_commands = 0;
int j;
+ assert (delta_size - (ptr - delta) >= header_length (idx_data_len, len));
ptr = write_header (ptr, idx_data_len, len);
+ assert (ptr - delta > 0);
for (j = 0; j < copy_count; j++)
{ CopyInfo *copy = copies + j;
@@ -732,11 +750,17 @@
void *diff_delta(void *from_buf, unsigned long from_size,
void *to_buf, unsigned long to_size,
unsigned long *delta_size, unsigned long max_size)
-{ unsigned dsize;
+{ unsigned char *delta = 0;
+ unsigned dsize;
assert (from_size <= MAX_SIZE && to_size <= MAX_SIZE);
init_idx (from_buf, from_size, 1); /* Use optimization level 1 */
+
dsize = calculate_delta (to_buf, to_size);
- if (!dsize) return 0;
- *delta_size = dsize;
- return create_delta (to_buf, to_size, *delta_size);
+ if (dsize && (!max_size || dsize <= max_size))
+ { delta = create_delta (to_buf, to_size, dsize);
+ *delta_size = delta ? dsize : 0;
+ }
+
+ finalize_idx ();
+ return delta;
}
^ permalink raw reply
* Re: RFC: New diff-delta.c implementation
From: Davide Libenzi @ 2006-04-22 20:36 UTC (permalink / raw)
To: Geert Bosch; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <602974A9-09A3-46E9-92D6-D30728923C11@adacore.com>
On Fri, 21 Apr 2006, Geert Bosch wrote:
> I wrote a new binary differencing algorithm that is both faster
> and generates smaller deltas than the current implementation.
> The format is compatible with that used by patch-delta, so
> it should be easy to integrate.
>
> Originally, I wrote this for the GDIFF format, see
> http://www.w3.org/TR/NOTE-gdiff-19970901.
> The adaptation for GIT format was relatively simple, but is not thoroughly
> tested.
> The code is not derived from libxdiff, but uses the rabin_slide function
> written
> by David Mazieres (dm@uun.org). Also the tables are generated using his code.
> Finally, this was developed on Darwin, and not a Linux system, so some
> changes may be needed.
>
> Initial testing seems quite positive, take for example git-1.2.5.tar vs
> git-1.2.6.tar
> on my PowerBook (both with -O2 -DNDEBUG):
>
> current: 2.281s, patch size 36563
> new : 0.109s, patch size 16199
>
> Please feel free to play around with this code, and give feedback.
> Keep in mind this wasn't originally written for GIT, and C is not
> my native language, so don't mind my formatting etc.
Geert, I saw you're using a shift of 55 bits, that gives an degree of the
root polynomial of 63, that is not prime. Where did you get the root
polynomial, and why you did not chose 61 as degree of the root?
Just curious ...
- Davide
^ permalink raw reply
* [PATCH] Libified diff-index: backward compatibility fix.
From: Junio C Hamano @ 2006-04-22 11:04 UTC (permalink / raw)
To: git; +Cc: torvalds
In-Reply-To: <7v64l1lxwj.fsf@assigned-by-dhcp.cox.net>
"diff-index -m" does not mean "do not ignore merges", but means
"pretend missing files match the index".
The previous round tried to address this, but failed because
setup_revisions() ate "-m" flag before the caller had a chance
to intervene.
Signed-off-by: Junio C Hamano <junkio@cox.net>
---
diff-index.c | 6 ++----
diff-lib.c | 10 +++++++++-
diff.h | 2 +-
3 files changed, 12 insertions(+), 6 deletions(-)
diff --git a/diff-index.c b/diff-index.c
index 4a243b3..8694012 100644
--- a/diff-index.c
+++ b/diff-index.c
@@ -23,9 +23,7 @@ int main(int argc, const char **argv)
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
- if (!strcmp(arg, "-m"))
- match_missing = 1;
- else if (!strcmp(arg, "--cached"))
+ if (!strcmp(arg, "--cached"))
cached = 1;
else
usage(diff_cache_usage);
@@ -37,5 +35,5 @@ int main(int argc, const char **argv)
if (!rev.pending_objects || rev.pending_objects->next ||
rev.max_count != -1 || rev.min_age != -1 || rev.max_age != -1)
usage(diff_cache_usage);
- return run_diff_index(&rev, cached, match_missing);
+ return run_diff_index(&rev, cached);
}
diff --git a/diff-lib.c b/diff-lib.c
index 63da3b5..2183b41 100644
--- a/diff-lib.c
+++ b/diff-lib.c
@@ -308,12 +308,20 @@ static void mark_merge_entries(void)
}
}
-int run_diff_index(struct rev_info *revs, int cached, int match_missing)
+int run_diff_index(struct rev_info *revs, int cached)
{
int ret;
struct object *ent;
struct tree *tree;
const char *tree_name;
+ int match_missing = 0;
+
+ /*
+ * Backward compatibility wart - "diff-index -m" does
+ * not mean "do not ignore merges", but totally different.
+ */
+ if (!revs->ignore_merges)
+ match_missing = 1;
if (read_cache() < 0) {
perror("read_cache");
diff --git a/diff.h b/diff.h
index 837d449..7150b90 100644
--- a/diff.h
+++ b/diff.h
@@ -171,6 +171,6 @@ extern const char *diff_unique_abbrev(co
extern int run_diff_files(struct rev_info *revs, int silent_on_removed);
-extern int run_diff_index(struct rev_info *revs, int cached, int match_missing);
+extern int run_diff_index(struct rev_info *revs, int cached);
#endif /* DIFF_H */
--
1.3.0.g0bc6
^ permalink raw reply related
* Re: RFC: New diff-delta.c implementation
From: Junio C Hamano @ 2006-04-22 11:13 UTC (permalink / raw)
To: Geert Bosch; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <A856A2C5-2BD7-4DC5-9CCC-CD53E9A2623C@adacore.com>
Geert Bosch <bosch@adacore.com> writes:
> BTW. It's a shame that we don't reuse the index when comparing one
> source
> against multiple targets. Creating the index takes about 70% of
> the time.
(Please line-wrap sensibly).
I think we tried that with Nico/Davide's delta already, and IIRC
we had mixed results.
It really depends on how big an index for a source is. Keep in
mind that we keep --window (default=10) of the source text
in-core, and you are suggesting to keep index in-core as well,
so we need to take memory pressure into account.
Having said that, the initial number you posted suggests the
algorithm is very fast, in which case reusing index may not
matter. We will see ;-).
^ permalink raw reply
* Re: RFC: New diff-delta.c implementation
From: Rene Scharfe @ 2006-04-22 12:36 UTC (permalink / raw)
To: Geert Bosch; +Cc: Git Mailing List, Junio C Hamano
In-Reply-To: <602974A9-09A3-46E9-92D6-D30728923C11@adacore.com>
Hello Geert,
Geert Bosch schrieb:
> I wrote a new binary differencing algorithm that is both faster and
> generates smaller deltas than the current implementation. The format
> is compatible with that used by patch-delta, so it should be easy to
> integrate.
[...]
> Initial testing seems quite positive, take for example git-1.2.5.tar
> vs git-1.2.6.tar on my PowerBook (both with -O2 -DNDEBUG):
>
> current: 2.281s, patch size 36563
> new : 0.109s, patch size 16199
>
> Please feel free to play around with this code, and give feedback.
> Keep in mind this wasn't originally written for GIT, and C is not my
> native language, so don't mind my formatting etc.
nice speedup! Though I cannot comment on what it actually does, I have
some comments on style. B-)
Could you please send your code inline, not as an attachment? And
possibly as a patch with a Signed-off-by: tag (see
Documentation/SubmittingPatches)?
Regarding your FIXME comment about endianess: I think you are looking
for htonl(). Use it to convert the values from host byte order to
network byte order (= big endian) and you can get rid of those ugly
branches.
You can use "indent -npro -kr -i8 -ts8 -l80 -ss -ncs" to reformat your
code into a similar style as used in the rest of git (settings taken
from Lindent which is shipped with the Linux source).
After converting to htonl() "make test" ran fine on my x86 box. Here is
what I get when I try to repack the git repo, though:
$ git repack -a -d
Generating pack...
Done counting 18985 objects.
Deltifying 18985 objects.
git-pack-objects: diff-delta.c:766: create_delta: Assertion `ptr -
delta == (int)delta_size' failed.
Please let me know if you need more details.
Thanks,
René
^ permalink raw reply
* Re: RFC: New diff-delta.c implementation
From: Geert Bosch @ 2006-04-22 12:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nicolas Pitre, Git Mailing List
In-Reply-To: <7v7j5hkglq.fsf@assigned-by-dhcp.cox.net>
On Apr 22, 2006, at 07:13, Junio C Hamano wrote:
> (Please line-wrap sensibly).
Apologies. I'm using a broken mailer, which insists
on breaking longish lines. I'll try to avoid this.
> I think we tried that with Nico/Davide's delta already, and IIRC
> we had mixed results.
>
> It really depends on how big an index for a source is. Keep
> in mind that we keep --window (default=10) of the source
> text in-core, and you are suggesting to keep index in-core
> as well, so we need to take memory pressure into account.
The point is that if we do the following comparisons:
diff A B
diff A C
diff A D
then we should keep A and its index in core for all
three comparisons. Discarding and recreating can never
be better :)
> Having said that, the initial number you posted suggests the
> algorithm is very fast, in which case reusing index may not
> matter. We will see ;-).
BTW, after applying the obvious fixes, I get the following
message:
potomac%./git-pack-objects --no-reuse-delta --stdout <lst
Generating pack...
Done counting 16984 objects.
Deltifying 16984 objects.
100% (16984/16984) done
fatal: delta size changed
Is this expected now I have a different algorithm?
-Geert
^ permalink raw reply
* Re: RFC: New diff-delta.c implementation
From: Nicolas Pitre @ 2006-04-22 19:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Geert Bosch, Git Mailing List
In-Reply-To: <7vslo5ikmk.fsf@assigned-by-dhcp.cox.net>
On Sat, 22 Apr 2006, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > Well, actually I was measuring a 10% speed improvement with a quick and
> > naive (not memory efficient) approach for pack-objects with the current
> > algorithm.
> >...
> > The idea to avoid memory pressure is to reverse the window processing
> > such that the object to delta against is constant for the entire window
> > instead of the current logic where the target object is constant. This
> > way there would be only one index in memory at all time.
>
> Your are right. The first led to the latter unexplored idea.
>
> I expect to be offline most of the day today, and have other
> things I can work on for the next few days anyway, so if you or
> somebody else have an inclination and energy to reverse the
> delta window, I would appreciate that.
I'll probably give it a try.
I'm still reviewing Geert's code right now and found minor things
pertaining to the GIT delta encoding here and there which probably
explain why it doesn't pack the Linux kernel archive yet.
Nicolas
^ permalink raw reply
* Re: RFC: New diff-delta.c implementation
From: Geert Bosch @ 2006-04-22 13:39 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0604220846040.2215@localhost.localdomain>
On Apr 22, 2006, at 08:51, Nicolas Pitre wrote:
> First, pack-objects tries to find the best object combinations
> producing the smallest delta. Then there is a second pass
> where the best delta are actually written out. When that
> message appears that means the delta size for the same object
> pair does not match between those two passes.
OK, thanks for that info. There are very few comments in the
code, or specs of either the file format used, or
for function arguments. I'll look a the code again with this
info.
What is the exact role of the max_size parameter that is
passed to diff_delta? I took it to mean return 0 if
the size of the delta would be bigger than max_size and
max_size is nonzero.
I only set *delta_size when returning a nonzero delta.
-Geert
^ permalink raw reply
* Re: RFC: New diff-delta.c implementation
From: Nicolas Pitre @ 2006-04-22 12:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Geert Bosch, Git Mailing List
In-Reply-To: <7v7j5hkglq.fsf@assigned-by-dhcp.cox.net>
On Sat, 22 Apr 2006, Junio C Hamano wrote:
> Geert Bosch <bosch@adacore.com> writes:
>
> > BTW. It's a shame that we don't reuse the index when comparing one
> > source
> > against multiple targets. Creating the index takes about 70% of
> > the time.
>
> I think we tried that with Nico/Davide's delta already, and IIRC
> we had mixed results.
Well, actually I was measuring a 10% speed improvement with a quick and
naive (not memory efficient) approach for pack-objects with the current
algorithm.
> It really depends on how big an index for a source is. Keep in
> mind that we keep --window (default=10) of the source text
> in-core, and you are suggesting to keep index in-core as well,
> so we need to take memory pressure into account.
The idea to avoid memory pressure is to reverse the window processing
such that the object to delta against is constant for the entire window
instead of the current logic where the target object is constant. This
way there would be only one index in memory at all time.
Nicolas
^ 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