* Re: Linus' sha1 is much faster!
From: Linus Torvalds @ 2009-08-16 20:10 UTC (permalink / raw)
To: Giuseppe Scrivano; +Cc: Bug-coreutils, Pádraig Brady, Git Mailing List
In-Reply-To: <87eirbef3c.fsf@master.homenet>
On Sun, 16 Aug 2009, Giuseppe Scrivano wrote:
>
> My GCC version is "gcc (Debian 4.3.3-14) 4.3.3" and the CPU is: Intel(R)
> Pentium(R) D CPU 3.20GHz.
Netburst is very sensitive to random spill effects, and you can basically
tune things by just code shuffling that just has random effects on the
generated asm code.
> I also spent some time trying to improve the gnulib SHA1 implementation
> and it seems a lookup table can improve things a bit.
I pretty much can guarantee you that it improves things only because it
makes gcc generate crap code, which then hides some of the P4 issues.
I'd also suggest you try gcc-4.4, since that apparently fixes some of the
oddest spill issues.
Linus
^ permalink raw reply
* Re: [RFCv3 2/4] Add Python support library for CVS remote helper
From: Junio C Hamano @ 2009-08-16 19:48 UTC (permalink / raw)
To: Johan Herland
Cc: git, barkalow, Johannes.Schindelin, David Aguilar,
Michael Haggerty
In-Reply-To: <1250036031-32272-3-git-send-email-johan@herland.net>
It appears that the "make install" step with this patch is broken, trying
to write into /usr/lib/python2.6/ without honoring DESTDIR.
It needs to be resolved before the series nears 'master', preferrably
before it hits 'next', as "make rpm" step is one of the things that is
broken by this.
I am sure people who are more savvy on Python can offer help.
Thanks.
^ permalink raw reply
* Re: git http-push and MKCOL error (22/409)
From: Junio C Hamano @ 2009-08-16 19:34 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Thomas Schlichter, willievu, Sean Davis, git
In-Reply-To: <be6fef0d0908160727r7dfa9b46l4d493e3954c21de3@mail.gmail.com>
Tay Ray Chuan <rctay89@gmail.com> writes:
> On Sun, Aug 16, 2009 at 9:57 PM, Thomas
> Schlichter<thomas.schlichter@web.de> wrote:
>> Current "master" and "next" trees also have this problem. But as git version
>> 1.6.4 does not have this problem, I was able to bisect it down to commit:
>>
>> 5424bc557fc6414660830b470dd45774b8f5f281
>> http*: add helper methods for fetching objects (loose)
>
> Interesting. Please do provide:
>
> -steps to reproduce,
> -your server's access log.
The report said:
MKCOL 98fd7fb8f32843c1bb40bd195a2f1cd6cab0751d failed, aborting (22/409)
As far as I can see you are trying (in http-push.c::start_mkcol()) to
create the two-hexdigit fan-out directory (i.e. "98" for this example); it
is strange to see a request to create the full 40-hexdigit collection in
the first place.
In another thread you responded to earlier:
http://thread.gmane.org/gmane.comp.version-control.git/125933/focus=125972
the original report did not give the exact error message, but in that one,
instead of failing to create 40-hexdigit collection like this, I am
guessing that it fails with something like "MKCOL 'refs' failed".
So are these unrelated "breakages"[1]?
[Foornote]
*1* Not necessarily in the sense the client is broken but in the sense
that the server-client combination does not work for the reporter.
^ permalink raw reply
* Re: Linus' sha1 is much faster!
From: Giuseppe Scrivano @ 2009-08-16 19:25 UTC (permalink / raw)
To: Pádraig Brady; +Cc: Linus Torvalds, Bug-coreutils, Git Mailing List
In-Reply-To: <4A85F270.20703@draigBrady.com>
[-- Attachment #1: Type: text/plain, Size: 575 bytes --]
Hi Pádraig,
I tried to reproduce your results but I wasn't able to do it. The
biggest difference on a 300MB file I noticed was approximately 15% using
on both implementations -O2, and 5% using -O3.
My GCC version is "gcc (Debian 4.3.3-14) 4.3.3" and the CPU is: Intel(R)
Pentium(R) D CPU 3.20GHz.
I also spent some time trying to improve the gnulib SHA1 implementation
and it seems a lookup table can improve things a bit.
Can you please try the patch that I have attached and tell me which
performance difference (if any) you get?
Thanks,
Giuseppe
[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-SHA1-use-a-lookup-table-for-faster-hashing.patch --]
[-- Type: text/x-diff, Size: 8582 bytes --]
>From b975a5e0849eaa46e5cf410c5bf6e2308f044d61 Mon Sep 17 00:00:00 2001
From: Giuseppe Scrivano <gscrivano@gnu.org>
Date: Sun, 16 Aug 2009 20:53:54 +0200
Subject: [PATCH] SHA1: use a lookup table for faster hashing
* lib/sha1.c (struct sha1_pre): New member.
* lib/sha1.c (sha1_process_block): Use the lookup table to quickly find
indices to use in the current round.
---
lib/sha1.c | 160 ++++++++++++++++++++++++++++++++++-------------------------
1 files changed, 92 insertions(+), 68 deletions(-)
diff --git a/lib/sha1.c b/lib/sha1.c
index 9c6c7ae..ec18ba7 100644
--- a/lib/sha1.c
+++ b/lib/sha1.c
@@ -283,6 +283,32 @@ sha1_process_bytes (const void *buffer, size_t len, struct sha1_ctx *ctx)
#define F3(B,C,D) ( ( B & C ) | ( D & ( B | C ) ) )
#define F4(B,C,D) (B ^ C ^ D)
+struct lookup_t
+{
+ unsigned char l1 : 4;
+ unsigned char l2 : 4;
+ unsigned char l3 : 4;
+ unsigned char l4 : 4;
+};
+
+const static struct lookup_t
+sha1_pre[16] = {{(0 - 3) & 0x0f, (0 - 8) & 0x0f, (0 - 14) & 0x0f},
+ {(1 - 3) & 0x0f, (1 - 8) & 0x0f, (1 - 14) & 0x0f},
+ {(2 - 3) & 0x0f, (2 - 8) & 0x0f, (2 - 14) & 0x0f},
+ {(3 - 3) & 0x0f, (3 - 8) & 0x0f, (3 - 14) & 0x0f},
+ {(4 - 3) & 0x0f, (4 - 8) & 0x0f, (4 - 14) & 0x0f},
+ {(5 - 3) & 0x0f, (5 - 8) & 0x0f, (5 - 14) & 0x0f},
+ {(6 - 3) & 0x0f, (6 - 8) & 0x0f, (6 - 14) & 0x0f},
+ {(7 - 3) & 0x0f, (7 - 8) & 0x0f, (7 - 14) & 0x0f},
+ {(8 - 3) & 0x0f, (8 - 8) & 0x0f, (8 - 14) & 0x0f},
+ {(9 - 3) & 0x0f, (9 - 8) & 0x0f, (9 - 14) & 0x0f},
+ {(10 - 3) & 0x0f, (10 - 8) & 0x0f, (10 - 14) & 0x0f},
+ {(11 - 3) & 0x0f, (11 - 8) & 0x0f, (11 - 14) & 0x0f},
+ {(12 - 3) & 0x0f, (12 - 8) & 0x0f, (12 - 14) & 0x0f},
+ {(13 - 3) & 0x0f, (13 - 8) & 0x0f, (13 - 14) & 0x0f},
+ {(14 - 3) & 0x0f, (14 - 8) & 0x0f, (14 - 14) & 0x0f},
+ {(15 - 3) & 0x0f, (15 - 8) & 0x0f, (15 - 14) & 0x0f}};
+
/* Process LEN bytes of BUFFER, accumulating context into CTX.
It is assumed that LEN % 64 == 0.
Most of this code comes from GnuPG's cipher/sha1.c. */
@@ -309,9 +335,8 @@ sha1_process_block (const void *buffer, size_t len, struct sha1_ctx *ctx)
#define rol(x, n) (((x) << (n)) | ((uint32_t) (x) >> (32 - (n))))
-#define M(I) ( tm = x[I&0x0f] ^ x[(I-14)&0x0f] \
- ^ x[(I-8)&0x0f] ^ x[(I-3)&0x0f] \
- , (x[I&0x0f] = rol(tm, 1)) )
+#define M(I) (x[I] = rol (x[sha1_pre[I].l1] ^ x[sha1_pre[I].l2] \
+ ^ x[sha1_pre[I].l3] ^ x[I], 1))
#define R(A,B,C,D,E,F,K,M) do { E += rol( A, 5 ) \
+ F( B, C, D ) \
@@ -322,7 +347,6 @@ sha1_process_block (const void *buffer, size_t len, struct sha1_ctx *ctx)
while (words < endp)
{
- uint32_t tm;
int t;
for (t = 0; t < 16; t++)
{
@@ -346,70 +370,70 @@ sha1_process_block (const void *buffer, size_t len, struct sha1_ctx *ctx)
R( c, d, e, a, b, F1, K1, x[13] );
R( b, c, d, e, a, F1, K1, x[14] );
R( a, b, c, d, e, F1, K1, x[15] );
- R( e, a, b, c, d, F1, K1, M(16) );
- R( d, e, a, b, c, F1, K1, M(17) );
- R( c, d, e, a, b, F1, K1, M(18) );
- R( b, c, d, e, a, F1, K1, M(19) );
- R( a, b, c, d, e, F2, K2, M(20) );
- R( e, a, b, c, d, F2, K2, M(21) );
- R( d, e, a, b, c, F2, K2, M(22) );
- R( c, d, e, a, b, F2, K2, M(23) );
- R( b, c, d, e, a, F2, K2, M(24) );
- R( a, b, c, d, e, F2, K2, M(25) );
- R( e, a, b, c, d, F2, K2, M(26) );
- R( d, e, a, b, c, F2, K2, M(27) );
- R( c, d, e, a, b, F2, K2, M(28) );
- R( b, c, d, e, a, F2, K2, M(29) );
- R( a, b, c, d, e, F2, K2, M(30) );
- R( e, a, b, c, d, F2, K2, M(31) );
- R( d, e, a, b, c, F2, K2, M(32) );
- R( c, d, e, a, b, F2, K2, M(33) );
- R( b, c, d, e, a, F2, K2, M(34) );
- R( a, b, c, d, e, F2, K2, M(35) );
- R( e, a, b, c, d, F2, K2, M(36) );
- R( d, e, a, b, c, F2, K2, M(37) );
- R( c, d, e, a, b, F2, K2, M(38) );
- R( b, c, d, e, a, F2, K2, M(39) );
- R( a, b, c, d, e, F3, K3, M(40) );
- R( e, a, b, c, d, F3, K3, M(41) );
- R( d, e, a, b, c, F3, K3, M(42) );
- R( c, d, e, a, b, F3, K3, M(43) );
- R( b, c, d, e, a, F3, K3, M(44) );
- R( a, b, c, d, e, F3, K3, M(45) );
- R( e, a, b, c, d, F3, K3, M(46) );
- R( d, e, a, b, c, F3, K3, M(47) );
- R( c, d, e, a, b, F3, K3, M(48) );
- R( b, c, d, e, a, F3, K3, M(49) );
- R( a, b, c, d, e, F3, K3, M(50) );
- R( e, a, b, c, d, F3, K3, M(51) );
- R( d, e, a, b, c, F3, K3, M(52) );
- R( c, d, e, a, b, F3, K3, M(53) );
- R( b, c, d, e, a, F3, K3, M(54) );
- R( a, b, c, d, e, F3, K3, M(55) );
- R( e, a, b, c, d, F3, K3, M(56) );
- R( d, e, a, b, c, F3, K3, M(57) );
- R( c, d, e, a, b, F3, K3, M(58) );
- R( b, c, d, e, a, F3, K3, M(59) );
- R( a, b, c, d, e, F4, K4, M(60) );
- R( e, a, b, c, d, F4, K4, M(61) );
- R( d, e, a, b, c, F4, K4, M(62) );
- R( c, d, e, a, b, F4, K4, M(63) );
- R( b, c, d, e, a, F4, K4, M(64) );
- R( a, b, c, d, e, F4, K4, M(65) );
- R( e, a, b, c, d, F4, K4, M(66) );
- R( d, e, a, b, c, F4, K4, M(67) );
- R( c, d, e, a, b, F4, K4, M(68) );
- R( b, c, d, e, a, F4, K4, M(69) );
- R( a, b, c, d, e, F4, K4, M(70) );
- R( e, a, b, c, d, F4, K4, M(71) );
- R( d, e, a, b, c, F4, K4, M(72) );
- R( c, d, e, a, b, F4, K4, M(73) );
- R( b, c, d, e, a, F4, K4, M(74) );
- R( a, b, c, d, e, F4, K4, M(75) );
- R( e, a, b, c, d, F4, K4, M(76) );
- R( d, e, a, b, c, F4, K4, M(77) );
- R( c, d, e, a, b, F4, K4, M(78) );
- R( b, c, d, e, a, F4, K4, M(79) );
+ R( e, a, b, c, d, F1, K1, M( 0) );
+ R( d, e, a, b, c, F1, K1, M( 1) );
+ R( c, d, e, a, b, F1, K1, M( 2) );
+ R( b, c, d, e, a, F1, K1, M( 3) );
+ R( a, b, c, d, e, F2, K2, M( 4) );
+ R( e, a, b, c, d, F2, K2, M( 5) );
+ R( d, e, a, b, c, F2, K2, M( 6) );
+ R( c, d, e, a, b, F2, K2, M( 7) );
+ R( b, c, d, e, a, F2, K2, M( 8) );
+ R( a, b, c, d, e, F2, K2, M( 9) );
+ R( e, a, b, c, d, F2, K2, M(10) );
+ R( d, e, a, b, c, F2, K2, M(11) );
+ R( c, d, e, a, b, F2, K2, M(12) );
+ R( b, c, d, e, a, F2, K2, M(13) );
+ R( a, b, c, d, e, F2, K2, M(14) );
+ R( e, a, b, c, d, F2, K2, M(15) );
+ R( d, e, a, b, c, F2, K2, M( 0) );
+ R( c, d, e, a, b, F2, K2, M( 1) );
+ R( b, c, d, e, a, F2, K2, M( 2) );
+ R( a, b, c, d, e, F2, K2, M( 3) );
+ R( e, a, b, c, d, F2, K2, M( 4) );
+ R( d, e, a, b, c, F2, K2, M( 5) );
+ R( c, d, e, a, b, F2, K2, M( 6) );
+ R( b, c, d, e, a, F2, K2, M( 7) );
+ R( a, b, c, d, e, F3, K3, M( 8) );
+ R( e, a, b, c, d, F3, K3, M( 9) );
+ R( d, e, a, b, c, F3, K3, M(10) );
+ R( c, d, e, a, b, F3, K3, M(11) );
+ R( b, c, d, e, a, F3, K3, M(12) );
+ R( a, b, c, d, e, F3, K3, M(13) );
+ R( e, a, b, c, d, F3, K3, M(14) );
+ R( d, e, a, b, c, F3, K3, M(15) );
+ R( c, d, e, a, b, F3, K3, M( 0) );
+ R( b, c, d, e, a, F3, K3, M( 1) );
+ R( a, b, c, d, e, F3, K3, M( 2) );
+ R( e, a, b, c, d, F3, K3, M( 3) );
+ R( d, e, a, b, c, F3, K3, M( 4) );
+ R( c, d, e, a, b, F3, K3, M( 5) );
+ R( b, c, d, e, a, F3, K3, M( 6) );
+ R( a, b, c, d, e, F3, K3, M( 7) );
+ R( e, a, b, c, d, F3, K3, M( 8) );
+ R( d, e, a, b, c, F3, K3, M( 9) );
+ R( c, d, e, a, b, F3, K3, M(10) );
+ R( b, c, d, e, a, F3, K3, M(11) );
+ R( a, b, c, d, e, F4, K4, M(12) );
+ R( e, a, b, c, d, F4, K4, M(13) );
+ R( d, e, a, b, c, F4, K4, M(14) );
+ R( c, d, e, a, b, F4, K4, M(15) );
+ R( b, c, d, e, a, F4, K4, M( 0) );
+ R( a, b, c, d, e, F4, K4, M( 1) );
+ R( e, a, b, c, d, F4, K4, M( 2) );
+ R( d, e, a, b, c, F4, K4, M( 3) );
+ R( c, d, e, a, b, F4, K4, M( 4) );
+ R( b, c, d, e, a, F4, K4, M( 5) );
+ R( a, b, c, d, e, F4, K4, M( 6) );
+ R( e, a, b, c, d, F4, K4, M( 7) );
+ R( d, e, a, b, c, F4, K4, M( 8) );
+ R( c, d, e, a, b, F4, K4, M( 9) );
+ R( b, c, d, e, a, F4, K4, M(10) );
+ R( a, b, c, d, e, F4, K4, M(11) );
+ R( e, a, b, c, d, F4, K4, M(12) );
+ R( d, e, a, b, c, F4, K4, M(13) );
+ R( c, d, e, a, b, F4, K4, M(14) );
+ R( b, c, d, e, a, F4, K4, M(15) );
a = ctx->A += a;
b = ctx->B += b;
--
1.6.3.3
^ permalink raw reply related
* Re: How to stop sharing objects between repositories
From: Junio C Hamano @ 2009-08-16 19:16 UTC (permalink / raw)
To: Jeff King; +Cc: Johannes Schindelin, Jon Jensen, git
In-Reply-To: <20090816135703.GA31638@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> Subject: [PATCH] docs: mention how to break alternates dependency
>
> A user who has created a repository dependency by using "git
> clone -s" does not necessarily know where to look to find
> out how to break that dependency. Let's mention it right
> under "-s", where they are most likely to find it.
>
> Signed-off-by: Jeff King <peff@peff.net>
> ---
> Documentation/git-clone.txt | 5 +++++
> 1 files changed, 5 insertions(+), 0 deletions(-)
>
> diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
> index b14de6c..87fa687 100644
> --- a/Documentation/git-clone.txt
> +++ b/Documentation/git-clone.txt
> @@ -72,6 +72,11 @@ These objects may be removed by normal git operations (such as 'git-commit')
> which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
> If these objects are removed and were referenced by the cloned repository,
> then the cloned repository will become corrupt.
> ++
> +To break the dependency of the cloned repository to the source
> +repository, run `git repack -a` in the cloned repository, which will
> +create a new pack in that repository with all referenced objects,
> +including those in the source repository.
After reading this, two points come to my mind. They may or may not be
issues.
(1) Such a user does not necessarily know a casual "git repack -a" breaks
the dependency, defeating the -s option s/he deliberately used in
order to save disk space in the first place. Perhaps we can reword
this further to kill two penguins with a single stone?
Note that the pack resulting from running `git repack -a` in the
repository cloned with the `-s` option will include objects that
are borrowed from the source repository. It essentially breaks
the dependency created by cloning with the `-s` option by copying
the objects from the source repository. To keep borrowing from
the source repository to save disk space, do not use `repack -a`.
We should suggest an alternative immediately after this sentence,
e.g. "Instead, use `repack -l`" or something, but somebody should
check if it is a valid/viable alternative.
(2) IIRC, "git gc --auto" runs "repack -A". What is its effect with
respect to this dependency between object stores? I suspect it would
also break the dependency, but if so, is it a good thing? Perhaps
should we change it to use a version that keeps the dependency
instead?
^ permalink raw reply
* Re: git-svn bug report: %20 in http:// should translate to a space ' ' automatically
From: Daniel Stenberg @ 2009-08-16 18:13 UTC (permalink / raw)
To: Tony Finch; +Cc: Björn Steinbrink, Mike Smullin, Eric Wong, git
In-Reply-To: <alpine.LSU.2.00.0908152336240.449@hermes-2.csi.cam.ac.uk>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 419 bytes --]
On Sat, 15 Aug 2009, Tony Finch wrote:
> On Sat, 15 Aug 2009, Björn Steinbrink wrote:
>>
>> 3) git svn clone -Tgoo "http://host/repo/path with spaces/foo/bar"
>>
>> Works.
>
> Spaces are not permitted in URLs so this should be treated as a syntax
> error.
libcurl OTOH doesn't verify the passed in data to be strict URLs but will
instead do its best to work with whatever is passed to it...
--
/ daniel.haxx.se
^ permalink raw reply
* GitHub linking, was Re: bbchop & Wikipedia's Bayesian search theory page
From: Johannes Schindelin @ 2009-08-16 17:18 UTC (permalink / raw)
To: git, Scott Chacon, Ealdwulf Wuffinga
In-Reply-To: <alpine.DEB.1.00.0908161907580.8306@pacific.mpi-cbg.de>
Hi,
On Sun, 16 Aug 2009, Johannes Schindelin wrote:
> I tried to find some documentation for Bayesian search theory, but it
> seems those ridiculous Wikipedia admins struck once again, in their
> mission to reduce the world's intellect to their own.
Ah, never mind, it seems that they did not delete _this_ page (it would
have been the third I looked for this week which got deleted and made
extra hard to find a copy of).
The problem, really, is that the link on the bbchop GitHub site is wrong:
http://github.com/Ealdwulf/bbchop/tree/master
The issue is that the link incorrectly includes the closing parenthesis.
It should link to
http://en.wikipedia.org/wiki/Bayesian_search_theory
not
http://en.wikipedia.org/wiki/Bayesian_search_theory)
Scott, is it possible to fix that? Or is the README not magically made
from the README in the repository (which does not contain HTML markup)?
Ciao,
Dscho
^ permalink raw reply
* bbchop & Wikipedia's Bayesian search theory page
From: Johannes Schindelin @ 2009-08-16 17:13 UTC (permalink / raw)
To: git, Ealdwulf Wuffinga
Hi,
I tried to find some documentation for Bayesian search theory, but it
seems those ridiculous Wikipedia admins struck once again, in their
mission to reduce the world's intellect to their own.
Anybody know where I can find information about Bayesian search theory
that is not deleted by people envious of other people's brains?
Thanks,
Dscho
P.S.: yes, I am disappointed. "Wisdom of the crowds"? Not with this type
of human beings in control of articles other people wrote.
^ permalink raw reply
* Re: git http-push and MKCOL error (22/409)
From: Thomas Schlichter @ 2009-08-16 14:52 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: Junio C Hamano, Sean Davis, git
In-Reply-To: <be6fef0d0908160727r7dfa9b46l4d493e3954c21de3@mail.gmail.com>
Hi,
Am Sonntag 16 August 2009 16:27:40 schrieb Tay Ray Chuan:
> Interesting. Please do provide:
>
> -steps to reproduce,
> -your server's access log.
Unfortunately I cannot provide the server's access log. It is a server
provided by the German E-Mail provider web.de. It allows to save files via a
web-interface and via WebDAV.
Steps to reproduce:
1. locally set up a git archive:
mkdir dummy.git
cd dummy.git
git init --bare
2. Upload this directory to the server.
I did do this using KDE's dolphin via WebDAV.
3. Clone this remote repository:
git clone https://webdav.smartdrive.web.de/dummy.git my_dummy
4. Create a local commit:
cd my_dummy
touch dummy.c
git commit -a
5. Push this commit up to the remote repository:
git push origin master
The last step fails es explained. During bisecting git I was able to commit
several changes with versions before commit
5424bc557fc6414660830b470dd45774b8f5f281.
Kind regards,
Thomas Schlichter
P.S.: Maybe it is important that the server uses the secure https protocol,
therefore I set my username and password combination in my local ~/.netrc
file.
^ permalink raw reply
* Re: git http-push and MKCOL error (22/409)
From: Tay Ray Chuan @ 2009-08-16 14:27 UTC (permalink / raw)
To: Thomas Schlichter; +Cc: Junio C Hamano, Sean Davis, git
In-Reply-To: <200908161557.26962.thomas.schlichter@web.de>
Hi,
On Sun, Aug 16, 2009 at 9:57 PM, Thomas
Schlichter<thomas.schlichter@web.de> wrote:
> Current "master" and "next" trees also have this problem. But as git version
> 1.6.4 does not have this problem, I was able to bisect it down to commit:
>
> 5424bc557fc6414660830b470dd45774b8f5f281
> http*: add helper methods for fetching objects (loose)
Interesting. Please do provide:
-steps to reproduce,
-your server's access log.
--
Cheers,
Ray Chuan
^ permalink raw reply
* git http-push and MKCOL error (22/409)
From: Thomas Schlichter @ 2009-08-16 13:57 UTC (permalink / raw)
To: Tay Ray Chuan, Junio C Hamano; +Cc: Sean Davis, git
Hello,
I was using git version 1.6.4 and a remote WebDAV repository. But
unfortunately, git-http-push always returns following error:
schlicht@netbook:~/dummy$ git push
Fetching remote heads...
refs
refs/heads
refs/tags
refs/heads
refs/tags
updating 'refs/heads/master'
from 980385b1032efc0db665dff3ad54068f762af9aa
to 98fd7fb8f32843c1bb40bd195a2f1cd6cab0751d
sending 1 objects
MKCOL 98fd7fb8f32843c1bb40bd195a2f1cd6cab0751d failed, aborting (22/409)
Updating remote server info
error: failed to push some refs to
'https://webdav.smartdrive.web.de/dummy.git'
Current "master" and "next" trees also have this problem. But as git version
1.6.4 does not have this problem, I was able to bisect it down to commit:
5424bc557fc6414660830b470dd45774b8f5f281
http*: add helper methods for fetching objects (loose)
I can always reproduce this problem, so I am willing to test patches to fix
this regression.
Kind regards,
Thomas Schlichter
^ permalink raw reply
* Re: How to stop sharing objects between repositories
From: Jeff King @ 2009-08-16 13:57 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, Jon Jensen, git
In-Reply-To: <alpine.DEB.1.00.0908161429590.8306@pacific.mpi-cbg.de>
On Sun, Aug 16, 2009 at 02:30:15PM +0200, Johannes Schindelin wrote:
> > I think it is the opposite; packing _without_ "-l" will create a pack
> > with objects from the alternate; using "-l" suppresses them. Running
> > "git repack -a" should do the trick, I believe (and you need the "-a" to
> > ensure that objects already packed in the repo are re-packed).
>
> Hmm. I really would like a documentation patch, then.
To what? From git-repack(1):
-l
Pass the --local option to git-pack-objects. See git-pack-objects(1).
>From git-pack-objects(1):
--local
This flag is similar to --incremental; instead of ignoring all
packed objects, it only ignores objects that are packed and/or not
in the local object store (i.e. borrowed from an alternate).
So I think the documentation is correct, but for the original poster, it
suffers from two problems:
1. The impact of "-l" in this case is a bit subtle and confusing.
I.e., it is not an obvious "use this flag to break the dependency
on an alternate", but rather "don't use this flag so that you won't
ignore non-local objects when packing". In fact, you don't need to
know about it at all
2. He has to know that "git repack" is the right place to look in the
first place (_and_ he has to figure out that "-l" is what he cares
about and follow the docs to git-pack-objects to find out what it
does).
So I think the best thing is a "by the way, here is how you break this
dependency" closer to where the concept of alternates is defined. I
guess the best part would be under the "-s" flag of git-clone, since
that is presumably how such a situation was created (unless the user is
savvy enough to edit .git/objects/info/alternates themselves, in which
case I think we have to assume they know what they are doing).
So maybe something like this would be enough:
-- >8 --
Subject: [PATCH] docs: mention how to break alternates dependency
A user who has created a repository dependency by using "git
clone -s" does not necessarily know where to look to find
out how to break that dependency. Let's mention it right
under "-s", where they are most likely to find it.
Signed-off-by: Jeff King <peff@peff.net>
---
Documentation/git-clone.txt | 5 +++++
1 files changed, 5 insertions(+), 0 deletions(-)
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index b14de6c..87fa687 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -72,6 +72,11 @@ These objects may be removed by normal git operations (such as 'git-commit')
which automatically call `git gc --auto`. (See linkgit:git-gc[1].)
If these objects are removed and were referenced by the cloned repository,
then the cloned repository will become corrupt.
++
+To break the dependency of the cloned repository to the source
+repository, run `git repack -a` in the cloned repository, which will
+create a new pack in that repository with all referenced objects,
+including those in the source repository.
--
1.6.4.257.gb8ef
^ permalink raw reply related
* Re: How to stop sharing objects between repositories
From: Johannes Schindelin @ 2009-08-16 13:57 UTC (permalink / raw)
To: Daniel Villeneuve; +Cc: Jeff King, Jon Jensen, git
In-Reply-To: <4A880F89.3060702@videotron.ca>
Hi,
On Sun, 16 Aug 2009, Daniel Villeneuve wrote:
> Johannes Schindelin wrote:
>
> > Hmm. I really would like a documentation patch, then.
>
> As another way to do it, I've used something along the lines from
> http://article.gmane.org/gmane.comp.version-control.git/62062
What does this have to do with my comment?
Besides, you are teaching general Git users how to use plumbing. That is
asking for pain, and the pain will come back to the Git developers, not to
you.
Ciao,
Dscho
^ permalink raw reply
* Re: How to stop sharing objects between repositories
From: Daniel Villeneuve @ 2009-08-16 13:54 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Jon Jensen, git
In-Reply-To: <alpine.DEB.1.00.0908161429590.8306@pacific.mpi-cbg.de>
Johannes Schindelin wrote:
> Hmm. I really would like a documentation patch, then.
>
>
As another way to do it, I've used something along the lines from
http://article.gmane.org/gmane.comp.version-control.git/62062
namely:
<script>
gitdir=$(git rev-parse --git-dir)
[ -n "$gitdir" ] || die "cannot find Git directory"
cd "$gitdir"
a=objects/info/alternates
if [ -f $a ]; then
git rev-parse --all HEAD | git pack-objects --revs objects/pack/pack
rm $a
fi
</script>
I was not sure HEAD would be included via --all (e.g. HEAD pointing to a
dangling commit), so I added it explicitly.
The reverse operation (enabling sharing for a standalone repository) is
described here
http://git.or.cz/gitwiki/GitFaq#Howtoshareobjectsbetweenexistingrepositories.3F
--
Daniel
^ permalink raw reply
* Re: How to stop sharing objects between repositories
From: Johannes Schindelin @ 2009-08-16 12:30 UTC (permalink / raw)
To: Jeff King; +Cc: Jon Jensen, git
In-Reply-To: <20090816122842.GA942@sigill.intra.peff.net>
Hi,
On Sun, 16 Aug 2009, Jeff King wrote:
> On Sun, Aug 16, 2009 at 10:43:11AM +0200, Johannes Schindelin wrote:
>
> > > If there's a better or built-in way to do this with Git tools, I'd like
> > > to learn it, and I'd be happy to update the wiki accordingly.
> >
> > I think what you need is done by
> >
> > git repack -l
> >
> > (I agree it is not well documented, and I'd welcome a documentation
> > patch.)
>
> I think it is the opposite; packing _without_ "-l" will create a pack
> with objects from the alternate; using "-l" suppresses them. Running
> "git repack -a" should do the trick, I believe (and you need the "-a" to
> ensure that objects already packed in the repo are re-packed).
Hmm. I really would like a documentation patch, then.
Ciao,
Dscho
^ permalink raw reply
* Re: How to stop sharing objects between repositories
From: Jeff King @ 2009-08-16 12:28 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jon Jensen, git
In-Reply-To: <alpine.DEB.1.00.0908161042210.8306@pacific.mpi-cbg.de>
On Sun, Aug 16, 2009 at 10:43:11AM +0200, Johannes Schindelin wrote:
> > If there's a better or built-in way to do this with Git tools, I'd like
> > to learn it, and I'd be happy to update the wiki accordingly.
>
> I think what you need is done by
>
> git repack -l
>
> (I agree it is not well documented, and I'd welcome a documentation
> patch.)
I think it is the opposite; packing _without_ "-l" will create a pack
with objects from the alternate; using "-l" suppresses them. Running
"git repack -a" should do the trick, I believe (and you need the "-a" to
ensure that objects already packed in the repo are re-packed).
-Peff
^ permalink raw reply
* Re: [PATCH] Enable Visual Studio 2008 Build Git
From: Dmitry Potapov @ 2009-08-16 10:49 UTC (permalink / raw)
To: Frank Li; +Cc: Johannes Schindelin, git
Hi,
In addition to what Johannes wrote above, I have a few more remarks:
On Tue, Aug 04, 2009 at 11:53:38PM +0800, Frank Li wrote:
> diff --git a/compat/mingw.c b/compat/mingw.c
[...]
> @@ -1011,7 +1021,9 @@ static sig_handler_t timer_fn = SIG_DFL;
> * But ticktack() interrupts the wait state after the timer's interval
> * length to call the signal handler.
> */
> -
> +#if defined(_MSC_VER)
> +#define __stdcall
> +#endif
It is a very dirty hack to change __stdcall in this way, and more
importantly, it is not clear why you did this.
> static __stdcall unsigned ticktack(void *dummy)
Accordingly to MSDN:
http://msdn.microsoft.com/en-us/library/kdzttdcb(VS.80).aspx
The routine given to _beginthreadex as the start address should be
either __stdcall or __clrcall.
> --- /dev/null
> +++ b/compat/vcbuild/libgit/libgit.vcproj
[...]
> + <Filter
> + Name="compat"
> + >
> + <File
> + RelativePath="..\..\..\compat\basename.c"
> + >
> + </File>
> + <File
> + RelativePath="..\..\..\compat\cygwin.h"
> + >
> + </File>
I am not sure what cygwin.h is doing here.
> diff --git a/git-compat-util.h b/git-compat-util.h
> index 9f941e4..3b683e6 100644
> --- a/git-compat-util.h
> +++ b/git-compat-util.h
> @@ -87,7 +87,7 @@
> #include <assert.h>
> #include <regex.h>
> #include <utime.h>
> -#ifndef __MINGW32__
> +#if !defined(__MINGW32__) && !defined(_MSC_VER)
IMHO, it should be:
#ifndef _WIN32
because it has nothing to do with a particular compiler but with the
target platform. (Note: Cygwin GCC does not have _WIN32 defined, but
MinGW GCC does, so it should not break anything.)
Dmitry
^ permalink raw reply
* Re: [RFC PATCH 1/2] add a --delete option to git push
From: Jakub Narebski @ 2009-08-16 9:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sverre Rabbelier, Git List
In-Reply-To: <7vprax4yzd.fsf@alter.siamese.dyndns.org>
On Sat, 15 Aug 2009, Junio C Hamano wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
> > One more thing. I suspect that adding --delete and nothing else probably
> > makes things worse than not doing anything.
I don't necessarily agree with that. Having '--delete=<dst>' being long
version equivalent of ':<dst>' doesn't in my opinion change parading
used by git-push to the "<scm> push <operation> <refs>..." paradigm used
by Mercurial.
It's just a convenience syntax sugar: have more readable but longer
version. Just like equivalent short and long options.
BTW. there are few other places where git is TMTOWDI...
> > In a mental model where "push there --delete $branch" is natural, there
> > are branches on the other side, and when you run 'push' command, you name
> > the special operation, 'delete', that you would want to inflict on them.
> >
> > In such a world, there probably are other (perhaps not so special)
> > operations you can inflict on the branches on the other side as well.
> > They are probably called something like:
> >
> > push there --create $branch $commit
> > push there --update $branch $commit
> >
> > If you give them only --delete without completing the vocabulary by giving
> > these operations as well, you would force people to mix "git native" world
> > model (i.e. there is no "mode" nor "opration"; there is only "list of
> > instructions, each of which encodes the equivalent of 'mode'") with this
> > Hg-inspired world model.
>
> One final note on this topic. A more problematic is --rename.
>
> In the "there are branches on the other side, and a push command can be
> told to operate on them in different ways" world model, you naturally
> would want to:
>
> push there --delete $branch
> push there --rename $old $new
> push there --copy $old $new
>
> The first one you can implement as a syntax sugar by turning it into the
> native way of pushing ":$branch". You however cannot shoehorn rename and
> copy, because the way in which git push works does not have direct access
> to their "original" values of remote branches. If we do not have the
> current object $old points at, you cannot emulate "rename $old $new" nor
> "copy $old $new" only with simple syntax sugarcoating. We would likely
> need a protocol extension to fit them in, and that is of dubious value.
True. I'm against introducing "<scm> push <remote> <operation> <refs>"
paradigm.
If you think that '--delete=<dst>' for ':<dst>' would cause too much
confusion...
>
> Among the ones Jakub listed in another message:
http://nubyonrails.com/articles/five-features-from-mercurial-that-would-make-git-suck-less
> 1. "<scm> init <directory>" (done)
> 2. "hg commit --close-branch" vs slightly cryptic
> "git push origin :refs/heads/feature-tweak", which can be written
> simply as "git push origin :feature-tweak" I think.
> (that is what this patch series is about)
> 3. Numeric local references, e.g. 18:a432bc and "hg checkout 18"...
> but more realistic example would be "hg checkout 6324" :-P
> 4. sensible defaults: meaning of revert, staging area (i.e. commit -a)
> 5. "hg serve" (gitweb and a kind of git-daemon equivalent)
Note that I didn't said that I have agree with those points (as you can
see with comment to #3 for example), and I did say to read original
blog post instead of relying on this bare-bones summary.
>
> I think only #1 and #5 make sense (and I wonder if it would be enough to
> mention "instaweb" and "daemon" to cover #5).
I think #5 is also about native transport over HTTP, i.e. the "smart"
HTTP protocol idea (which didn't pass protocol design stage, AFAIK
no code).
>
> As we discussed in this thread at length, #2 is on the borderline. It
> makes sense if you take only --delete out of possible vocabulary, but when
> you think about it as a part of a coherent whole, it becomes somewhat
> iffy---it does not fit particularly well with other parts of the system.
I can agree that #2 is borderline and a bit problematic (when one is in
the mood for bikeshedding at least ;-))).
>
> I think #3 and #4 comes from fundamental difference of the world views.
>
> Regarding #3, giving monotonically increasing numbers to local commits
> would not be very hard without breaking the underlying data model. You
> would automatically tag the original commit whenever a new branch is
> created, and count commits relative to that origin-point tag for the
> current branch, perhaps following only the first parent chain, or
> something like that.
>
> For such a incrementing number be any useful, the user's history should
> rarely rewind, and this also introduces a notion/illusion that a branch
> somehow has its own identity, which we deliberately have rejected. I doubt
> this is worth it. Most of the time you are interested in the recent past,
> and HEAD~14 would be far easier to use than r19354 anyway ;-)
Also there is a matter of fast-forward merges that git use, which
I think is against 'branch have identity' idea.
On the other side there was considered adding 'generation' header
generation(this) = max(generation(this.parents)) + 1
which was intended to help speed up traversal, but it was decided it
was not worth the hassle to add such commit object header to existing
repository which do not use it. There was idea to put it in cache,
as it is recalculable, but that idea was never put into code.
>
> About #4, in general, I do not think it is worth discussing a topic that
> begins with the word "sensible" when the person who uses that word does
> not realize that what is sensible is in the eyes of beholder. Different
> SCMs use "revert" to mean different things, because there are a lot of
> combinations of _things_ you would want to revert, _states_ you would want
> to revert to, and _ways_ you would want the revert to be expressed. You
> may be familiar with the way BK used the word revert, or you may be
> familiar with the way SVN used the word revert. There is no single
> "right" use of the word.
>
> It also is not worth repeating the discussion on fear of index, either.
IHMO the very minor disadvantage of having to specify "git commit -a"
with '-a' option in usual case is well worth it when you need more
complicated staging / index manipulation, e.g. during more involved
merging.
>
> This is a good example of why you should _think_ before blindly parrotting
> whatever random people say on the net. They have not necessarily thought
> things through before saying "git can learn from X". You need to do the
> thinking for them to decide if they are making any sense when you read
> these things.
I was just listing what he said ;-)
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: How to stop sharing objects between repositories
From: Johannes Schindelin @ 2009-08-16 8:43 UTC (permalink / raw)
To: Jon Jensen; +Cc: git
In-Reply-To: <alpine.DEB.2.00.0908151756150.29215@nhtr.ovalna.fjrygre.arg>
Hi,
On Sat, 15 Aug 2009, Jon Jensen wrote:
> If there's a better or built-in way to do this with Git tools, I'd like
> to learn it, and I'd be happy to update the wiki accordingly.
I think what you need is done by
git repack -l
(I agree it is not well documented, and I'd welcome a documentation
patch.)
Ciao,
Dscho
^ permalink raw reply
* Re: Using VC build git (new patch)
From: Johannes Schindelin @ 2009-08-16 8:38 UTC (permalink / raw)
To: Frank Li; +Cc: git, msysGit
In-Reply-To: <1976ea660908152107s8b8f3e5l3c2f043fb3e4d62@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 4438 bytes --]
Hi,
[please quote only those parts that you actually reply to.]
On Sun, 16 Aug 2009, Frank Li wrote:
> 2009/8/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
>
> > - the addition of O_BINARY in the file modes
>
> Yes, default is text mode if no O_BINARY, _read _write will do union
> code and cr\cf convert.
As Git _never_ wants to open files in text mode, this is a change that can
come _separately_ from your VC patches. It could even be considered a bug
fix (MinGW's current GCC implies O_BINARY, but previous ones may not, and
it is wrong of us to rely on this magic).
> > - disabling link() (why?)
>
> VC report stack error. I also don't know why. I have not deep debug this
> problem.
You should. What with Visual Studio's superior debugging capabilities, it
should not be a problem. Right?
> > - double-#define'ing stat (which puzzles me greatly)
>
> old define is
> #define stat stati64
> #define stati64 msys_stati64.
Not exactly.
#define stat _stati64
[...]
#define _stati64(x,y) mingw_lstat(x,y)
And even VC should handle that just fine.
> stat is used for both struct and function name.
> In C code:
> struct stat a;
> stat -> stati64 -> msys_stati64, so compiler report struct
> msys_stati64 have not defined.
It is a real pity that you did not inline your patch, and that I could not
quote it as a consequence, because now we could discuss code properly:
The original code was done on purpose as it is, to use the _stati64 struct
(which allows long pointers, as Microsoft decided off_t was not good
enough to represent 64 bit offsets). I could imagine that your patch
breaks that for Visual C++.
> > - adding _huge_ .vcproj files (can they not be smaller?)
>
> It is created by VS2008. I think it is difficult to make smaller.
Is there not some magic to make a compact export version?
But maybe it is not that bad? I have 72 (out of 1730) files in my
repository that are larger, gitk being the king.
FWIW I would have loved it if _you_ defended the size of the file, instead
of having to do it myself.
> > Further, I would like to suggest adding a header file compat/msvc.h
> > which contains all the #undef's and #define's necessary only for
> > Visual C++, and which can be #include'd from git-compat-util.h, to
> > better separate your work from the other platforms (who do not want
> > those changes). That should avoid those unwanted changes to mingw.c
> > and mingw.h. You just have to make sure that msvc.h is #include'd
> > before mingw.h.
>
> VC build will reuse msysgit work.
That is no question. We made it easy for you.
> I will reduce change to mingw.c and mingw.h
> But there are some problem at mingw.c and mingw.h
>
> 1. stat defination. Because both struct and function use the same name stat.
That needs to be resolved somehow, and you would get _much_ more help if
you had split your patch series properly and this was _one_ patch.
> 2. open need binary mode.
As I said, this can be a separate change. In my original reply I
_implied_ that it is okay, and in this reply I elaborated on that (namely
that it might be considered a bug fix).
> 3. mingw.c use C99 style to break build at VC.
The same applies here as to O_BINARY.
> 4. mingw.c use special DIR structure, So I need add open_dir in mingw.c.
No, you do not need to add that to mingw.c. MinGW does not need it. So
it has no place in mingw.c.
> If I don't change mingw.c, I need copy it to new file totally.
NOOOO!!!
You #include it after making sure that you have #undef'ed and #define'd
whatever needs to, and in a separate file -- which is only referenced in
the .vcproj -- you can implement whatever Visual C++ misses.
> > With these comments, I look forward to your next iteration.
> >
> > Ciao,
> > Dscho
Please, please, PLEASE, do not quote things that you are not addressing.
And please, please, PLEASE adher to Documentation/SubmittingPatches.
Actually, the only thing SubmittingPatches does is spell out how to make
things easier for reviewers, should you not know how to do so.
Remember: the more time it takes me to cull the quoted parts of your mail,
the more time it takes me to have a look at your patches, the more time it
takes me to refer to your patch and make suggestions, the more am I
inclined to spend my time elsewhere, doing something that is much more
enjoyable.
Ciao,
Dscho
^ permalink raw reply
* Re: [RFC PATCH v3 8/8] --sparse for porcelains
From: Johannes Schindelin @ 2009-08-16 8:14 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <200908160137.30384.jnareb@gmail.com>
Hi,
On Sun, 16 Aug 2009, Jakub Narebski wrote:
> On Sat, 15 Aug 2009, Junio C Hamano wrote:
> > Jakub Narebski <jnareb@gmail.com> writes:
> >
> >>>> Hmmm... this looks like either argument for introducing --full
> >>>> option to git-checkout (ignore CE_VALID bit, checkout everything,
> >>>> and clean CE_VALID (?))...
> >>>>
> >>>> ...or for going with _separate_ bit for partial checkout, like in
> >>>> the very first version of this series, which otherwise functions
> >>>> like CE_VALID, or is just used to mark that CE_VALID was set using
> >>>> sparse.
> >
> > How would a separate bit help? Just like you need to clear CE_VALID
> > bit to revert the index into a normal (or "non sparse") state somehow,
> > you would need to have a way to clear that separate bit anyway.
> >
> > A separate bit would help only if you want to handle assume-unchanged
> > and sparse checkout independently. But my impression was that the
> > recent lstat reduction effort addressed the issue assume-unchanged
> > were invented to work around in the first place.
>
> Well, if we assume that we don't need (don't want) to handle
> assume-unchanged and sparse checkout independently, then of course the
> idea of having separate or additional bit for sparse doesn't make sense.
For the shallow/graft issue, we had a similar discussion. Back then, I
was convinced that shallow commits and grafted commits were something
fundamentally different, and my recent patch to pack-objects shows that:
shallow commits do not have the real parents in the current repository,
and that makes them different from other grafted commits.
Now, if you want to say that assume-unchanged and sparse are two
fundamentally different things, I would be interested in some equally
convincing argument as for the shallow/graft issue.
There is a fundamental difference, I grant you that: the working directory
does not contain the "sparse'd away" files while the same is not true for
assume-unchanged files.
But does that matter? The corresponding files are still in the index and
the repository.
IOW under what circumstances would you want to be able to discern between
assume-unchanged and "sparse'd away" files in the working directory?
I could _imagine_ that you'd want a tool that allows you to change the
focus of the sparse checkout together with the working directory.
Example: you have a sparse checkout of Documentation/ and now you want to
have t/, too. Just changing .git/info/sparse will not be enough.
The question is if the tool to change the "sparseness" [*1*] should not
change .git/info/sparse itself; if it does not, it would be good to be
able to discern between the "assume-unchanged" and "sparse'd away" files.
Although it might be enough to traverse the index and check the presence
of the assume-unchanged files in the working directory to determine which
files are sparse, and which ones are merely assume-unchanged.
Ciao,
Dscho
Footnote [*1*]: I think we need some nice and clear nomenclature here.
Any English wizards with a good taste of naming things?
^ permalink raw reply
* [PATCH] unpack-trees.c: simplify check_updates() code path when o->update is false
From: Nguyễn Thái Ngọc Duy @ 2009-08-16 5:05 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Nguyễn Thái Ngọc Duy
check_updates() is heavily branched by o->update, which makes it quite
difficult to follow. This patch rips "o->update == 0" code path out and
put it on top.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
unpack-trees.c | 23 +++++++++++++----------
1 files changed, 13 insertions(+), 10 deletions(-)
diff --git a/unpack-trees.c b/unpack-trees.c
index 720f7a1..3ee9919 100644
--- a/unpack-trees.c
+++ b/unpack-trees.c
@@ -75,7 +75,15 @@ static int check_updates(struct unpack_trees_options *o)
int i;
int errs = 0;
- if (o->update && o->verbose_update) {
+ if (!o->update) {
+ remove_marked_cache_entries(&o->result);
+ remove_scheduled_dirs();
+ for (i = 0; i < index->cache_nr; i++)
+ index->cache[i]->ce_flags &= ~CE_UPDATE;
+ return 0;
+ }
+
+ if (o->verbose_update) {
for (total = cnt = 0; cnt < index->cache_nr; cnt++) {
struct cache_entry *ce = index->cache[cnt];
if (ce->ce_flags & (CE_UPDATE | CE_REMOVE))
@@ -87,15 +95,13 @@ static int check_updates(struct unpack_trees_options *o)
cnt = 0;
}
- if (o->update)
- git_attr_set_direction(GIT_ATTR_CHECKOUT, &o->result);
+ git_attr_set_direction(GIT_ATTR_CHECKOUT, &o->result);
for (i = 0; i < index->cache_nr; i++) {
struct cache_entry *ce = index->cache[i];
if (ce->ce_flags & CE_REMOVE) {
display_progress(progress, ++cnt);
- if (o->update)
- unlink_entry(ce);
+ unlink_entry(ce);
}
}
remove_marked_cache_entries(&o->result);
@@ -107,14 +113,11 @@ static int check_updates(struct unpack_trees_options *o)
if (ce->ce_flags & CE_UPDATE) {
display_progress(progress, ++cnt);
ce->ce_flags &= ~CE_UPDATE;
- if (o->update) {
- errs |= checkout_entry(ce, &state, NULL);
- }
+ errs |= checkout_entry(ce, &state, NULL);
}
}
stop_progress(&progress);
- if (o->update)
- git_attr_set_direction(GIT_ATTR_CHECKIN, NULL);
+ git_attr_set_direction(GIT_ATTR_CHECKIN, NULL);
return errs != 0;
}
--
1.6.3.GIT
^ permalink raw reply related
* Re: Using VC build git (new patch)
From: Frank Li @ 2009-08-16 4:07 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: git, msysGit
In-Reply-To: <alpine.DEB.1.00.0908151908300.8306@pacific.mpi-cbg.de>
2009/8/16 Johannes Schindelin <Johannes.Schindelin@gmx.de>:
> Hi,
>
> On Sat, 15 Aug 2009, Johannes Schindelin wrote:
>
>> A single monster patch?
>>
>> Hmm.
>>
>> Please understand that I will not review that unless it is split up into
>> nice little and reviewable chunks.
>
> Well, I try to improve.
>
> So I had a look at your patch. The changes fall naturally into one of the
> following categories:
>
> - decl-after-statement fixes
>
> - missing #include "git-compat-util.h"
>
> - converting a K&R style function definition to modern C
>
> - #undef's only needed for Microsoft Visual C++
#undef ERROR is necessary.
#undef in mingw.h is only for clean some warning.
>
> - the addition of O_BINARY in the file modes
Yes, default is text mode if no O_BINARY, _read _write will
do union code and cr\cf convert.
>
> - disabling link() (why?)
VC report stack error. I also don't know why.
I have not deep debug this problem.
>
> - double-#define'ing stat (which puzzles me greatly)
old define is
#define stat stati64
#define stati64 msys_stati64.
stat is used for both struct and function name.
In C code:
struct stat a;
stat -> stati64 -> msys_stati64, so compiler report struct
msys_stati64 have not defined.
>
> - dummy #define'ing of a few compiler attributes
>
> - adding _MSVC to a conditional to avoid #define'ing
> SNPRINTF_SIZE_CORR yourself
>
> - #define'ing several symbols without leading underscore to the
> MS-specific version with a leading underscore
>
> - implementing strcasecmp() in a misnamed file
>
> - "fixing" the return value of winansi_vfprintf for Microsoft
> Visual C++ (I think this fix is wrong)
>
> - correctly adding a Visual C++-specific conditional to
> git-compat-util.h, pager.c, run-command.c, run-command.h,
> setup.c and help.c, although the latter five could use some
> refactoring into git-compat-util.h
Do you means add
#ifdef _MSC_VER
#include git-compat-util.h
#endif
>
> Maybe there is also room to change the MinGW-conditional into a
> NO_TRUSTABLE_FILEMODE one
>
> - adding several headers missing from Visual C++'s installation
>
> - adding _huge_ .vcproj files (can they not be smaller?)
It is created by VS2008. I think it is difficult to make smaller.
>
> As you can see, there is a pretty natural way to split that huge patch
> into chunks that most people on these lists can review easily, and that
> would actually be a pleasure to look at.
>
> Even better, there are a few fixes (the first three, if you ask me), which
> are not even Windows-specific.
>
> Further, I would like to suggest adding a header file compat/msvc.h which
> contains all the #undef's and #define's necessary only for Visual C++, and
> which can be #include'd from git-compat-util.h, to better separate your
> work from the other platforms (who do not want those changes). That
> should avoid those unwanted changes to mingw.c and mingw.h. You just have
> to make sure that msvc.h is #include'd before mingw.h.
VC build will reuse msysgit work.
I will reduce change to mingw.c and mingw.h
But there are some problem at mingw.c and mingw.h
1. stat defination. Because both struct and function use the same name stat.
2. open need binary mode.
3. mingw.c use C99 style to break build at VC.
4. mingw.c use special DIR structure, So I need add open_dir in mingw.c.
If I don't change mingw.c, I need copy it to new file totally.
>
> With these comments, I look forward to your next iteration.
>
> Ciao,
> Dscho
>
>
>
>
^ permalink raw reply
* Re: [RFC PATCH 1/2] add a --delete option to git push
From: Sverre Rabbelier @ 2009-08-16 2:30 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jakub Narebski, Git List
In-Reply-To: <7vprax4yzd.fsf@alter.siamese.dyndns.org>
Heya,
On Fri, Aug 14, 2009 at 19:01, Junio C Hamano<gitster@pobox.com> wrote:
> As we discussed in this thread at length, #2 is on the borderline. It
> makes sense if you take only --delete out of possible vocabulary, but when
> you think about it as a part of a coherent whole, it becomes somewhat
> iffy---it does not fit particularly well with other parts of the system.
I do not particularly care either way, I'm willing to implement
whatever we decide on, and if that's nothing at all" that's fine with
me too :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] git submodule foreach: Provide access to submodule name, as '$name'
From: Johan Herland @ 2009-08-16 1:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List, Mark Levedahl, Lars Hjemli
The argument to 'git submodule foreach' already has access to the variables
'$path' (the path to the submodule, relative to the superproject) and '$sha1'
(the submodule commit recorded by the superproject).
This patch adds another variable -- '$name' -- which contains the name of the
submodule, as recorded in the superproject's .gitmodules file.
Signed-off-by: Johan Herland <johan@herland.net>
---
Documentation/git-submodule.txt | 3 ++-
git-submodule.sh | 1 +
2 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 7dd73ae..97c32fe 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -131,7 +131,8 @@ summary::
foreach::
Evaluates an arbitrary shell command in each checked out submodule.
- The command has access to the variables $path and $sha1:
+ The command has access to the variables $name, $path and $sha1:
+ $name is the name of the relevant submodule section in .gitmodules,
$path is the name of the submodule directory relative to the
superproject, and $sha1 is the commit as recorded in the superproject.
Any submodules defined in the superproject but not checked out are
diff --git a/git-submodule.sh b/git-submodule.sh
index ebed711..d8ecdb9 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -243,6 +243,7 @@ cmd_foreach()
if test -e "$path"/.git
then
say "Entering '$path'"
+ name=$(module_name "$path")
(cd "$path" && eval "$@") ||
die "Stopping at '$path'; script returned non-zero status."
fi
--
1.6.4.rc3.138.ga6b98.dirty
^ permalink raw reply related
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