* [PATCH][resend 2] git-svn: Use GIT_SSH setting if SVN_SSH is not set
From: Karthik R @ 2009-08-18 20:31 UTC (permalink / raw)
To: git
If SVN_SSH is defined, it will be used; else value in
GIT_SSH is copied to SVN_SSH & then, only on Windows,
the \s are escaped.
On Windows, the shell-variables must be set as follows
GIT_SSH="C:\Program Files\PuTTY\plink.exe"
SVN_SSH="C:\\Program Files\\PuTTY\\plink.exe"
See http://code.google.com/p/msysgit/issues/detail?id=305
---
Trying again following Dscho's comment (removed MSWin32) & using
logic from Junio (don't muck with user's SVN_SSH; else use GIT_SSH
to seed SVN_SSH & adjust the \s on Windows)
Previous life of patch:
[PATCH] GIT_SSH does not override ssh in git-svn
[PATCH][resend] git-svn: Respect GIT_SSH setting
git-svn.perl | 9 +++++++++
1 files changed, 9 insertions(+), 0 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index b0bfb74..ef86d10 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -21,6 +21,15 @@ $Git::SVN::default_ref_id = $ENV{GIT_SVN_ID} ||
'git-svn';
$Git::SVN::Ra::_log_window_size = 100;
$Git::SVN::_minimize_url = 'unset';
+if (! exists $ENV{SVN_SSH}) {
+ if (exists $ENV{GIT_SSH}) {
+ $ENV{SVN_SSH} = $ENV{GIT_SSH};
+ if ($^O eq 'msys') {
+ $ENV{SVN_SSH} =~ s/\\/\\\\/g;
+ }
+ }
+}
+
$Git::SVN::Log::TZ = $ENV{TZ};
$ENV{TZ} = 'UTC';
$| = 1; # unbuffer STDOUT
--
1.5.4.3
^ permalink raw reply related
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Junio C Hamano @ 2009-08-18 20:30 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Sebastian Schuberth, Artur Skawina, Johannes Sixt,
msysGit, Linus Torvalds, Git Mailing List
In-Reply-To: <7vprasc1vu.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Nicolas Pitre <nico@cam.org> writes:
>
>> On Tue, 18 Aug 2009, Junio C Hamano wrote:
>>
>>> To reduce confusion, you may want to rename compat/bswap.h to something
>>> like compat/ntohl-htonl-fix.h ;-)
>>
>> Bah. If you wish, you can edit the patch directly for this, unless you
>> really prefer me to repost. Maybe we might want to add a 8-byte
>> versions of those as well eventually, which is why I chose a more
>> generic name.
>
> Ok, here is what I came up with after many squashing...
Meh, our mails crossed. I'll chuck this one and use your
[PATCH] make sure byte swapping is optimal for git
patch. Do you want default_swab32 be mmoved inside the
#if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))
block?
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Brandon Casey @ 2009-08-18 20:29 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Sebastian Schuberth, Artur Skawina, Johannes Sixt,
msysGit, Linus Torvalds, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908181607240.6044@xanadu.home>
Nicolas Pitre wrote:
> On Tue, 18 Aug 2009, Brandon Casey wrote:
>
>> The SUNWspro compiler doesn't set __i386__. Instead it sets __i386, and
>> I think __x86_64 and __amd64 where appropriate. So, compilation with
>> the SUNWspro compiler on x86 is currently unaffected by these changes and
>> falls back to the generic routines.
>>
>> It seems that v5.10 of the compiler can grok both the __asm__ statements
>> and the ({...}) naked block notation and passes all of the tests when the
>> block_sha1 code is modified to add defined(__i386) to each of the macro
>> statements.
>
> Does it really implement the gcc inline assembly syntax?
Yes, I think it does. I actually extracted the assembly from sha1.c and tested
in a separate test program. The v5.10 sunwspro compiler compiles and executes
it correctly.
-brandon
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Linus Torvalds @ 2009-08-18 20:25 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Brandon Casey, Junio C Hamano, Sebastian Schuberth, Artur Skawina,
Johannes Sixt, msysGit, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908181607240.6044@xanadu.home>
On Tue, 18 Aug 2009, Nicolas Pitre wrote:
>
> Does it really implement the gcc inline assembly syntax?
A fair number of compilers do. The Intel compiler does too.
The reason? The gcc inline asm is as close to a standard there is, and is
fairly expressive without being the mess that is MSC. So if you do inline
asm at all (and considering the target market for a C compiler, most do),
gcc asm is a good thing to aim for.
Linus
^ permalink raw reply
* Re: [RFC PATCH] stash: accept options also when subcommand 'save' is omitted
From: Junio C Hamano @ 2009-08-18 20:20 UTC (permalink / raw)
To: Jeff King; +Cc: Matthieu Moy, git, Johannes Schindelin
In-Reply-To: <20090818174509.GA27518@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Tue, Aug 18, 2009 at 03:01:52PM +0200, Matthieu Moy wrote:
> ...
> I think yours is nicer, especially as we have just added the
> '-p|--patch' option, as well. With what is there now, you can do "git
> stash -p", but not "git stash -p -k".
>
>> But I may have missed its drawbacks ;-)
>
> The only I can think of is that bogus input will provoke 'save'. So
> something like:
>
> git stash --apply
>
> will invoke "git stash save --apply", which doesn't even complain. It
> just tries to make a stash with message --apply. Now of course this
> input is obviously bogus, but probably the right thing to do is
> complain.
>
> OTOH, I think it is the fault of "git stash save --apply" for not doing
> the complaining, so your patch really isn't making it worse. Probably it
> should barf on anything unrecognized starting with a '-', and allow '--'
> to separate the message from the rest of the options (in the rare case
> that you want a message starting with '-').
Sounds like a sane approach.
I am Ok with the idea of queuing a patch to update js/stash-dwim ea41cfc
(Make 'git stash -k' a short form for 'git stash save --keep-index',
2009-07-27) with an implementation along this line; the "stash -p" one
f300fab (DWIM 'git stash save -p' for 'git stash -p', 2009-08-13) also
may need to adjusted (it could become no-op, I suspect).
^ permalink raw reply
* Re: [PATCH] git-log: allow --decorate[=short|full]
From: Junio C Hamano @ 2009-08-18 20:18 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jeff King, Junio C Hamano, Git Mailing List
In-Reply-To: <8c5c35580908150723h6e4c8fcay43b708969a86ae27@mail.gmail.com>
Lars Hjemli <hjemli@gmail.com> writes:
> diff --git a/builtin-log.c b/builtin-log.c
> index 3817bf1..1ed4c76 100644
> --- a/builtin-log.c
> +++ b/builtin-log.c
> @@ -61,8 +61,15 @@ static void cmd_log_init(int argc, const char
> **argv, const char *prefix,
> for (i = 1; i < argc; i++) {
> const char *arg = argv[i];
> if (!strcmp(arg, "--decorate")) {
> - load_ref_decorations();
> - rev->show_decorations = 1;
> + rev->show_decorations = DECORATE_SHORT_REFS;
> + } else if (!prefixcmp(arg, "--decorate=")) {
> + const char *v = skip_prefix(arg, "--decorate=");
> + if (!strcmp(v, "full"))
> + rev->show_decorations = DECORATE_FULL_REFS;
> + else if (!strcmp(v, "short"))
> + rev->show_decorations = DECORATE_SHORT_REFS;
> + else
> + die("invalid --decorate option: %s", arg);
> } else if (!strcmp(arg, "--source")) {
> rev->show_source = 1;
> } else if (!strcmp(arg, "-h")) {
> @@ -70,6 +77,8 @@ static void cmd_log_init(int argc, const char
> **argv, const char *prefix,
> } else
> die("unrecognized argument: %s", arg);
> }
> + if (rev->show_decorations)
> + load_ref_decorations(rev->show_decorations);
> }
If you are deciding whether full refs are given or short ones when you
call load_ref_decorations(), I do not think there is any reason for you to
change the type of rev->short_decorations from bool to enum. Shouldn't
you maintain a local variable in this function and pass it down to this
call instead?
That is, something like this on top (I had to fix the breakage your MUA
has done to your patch, so there might be some fuzz around whitespace).
builtin-log.c | 13 ++++++++-----
log-tree.c | 2 +-
revision.h | 2 +-
3 files changed, 10 insertions(+), 7 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 2a0f5f7..25e21ed 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -35,6 +35,7 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
struct rev_info *rev)
{
int i;
+ int decoration_style = 0;
rev->abbrev = DEFAULT_ABBREV;
rev->commit_format = CMIT_FMT_DEFAULT;
@@ -61,13 +62,13 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
for (i = 1; i < argc; i++) {
const char *arg = argv[i];
if (!strcmp(arg, "--decorate")) {
- rev->show_decorations = DECORATE_SHORT_REFS;
+ decoration_style = DECORATE_SHORT_REFS;
} else if (!prefixcmp(arg, "--decorate=")) {
const char *v = skip_prefix(arg, "--decorate=");
if (!strcmp(v, "full"))
- rev->show_decorations = DECORATE_FULL_REFS;
+ decoration_style = DECORATE_FULL_REFS;
else if (!strcmp(v, "short"))
- rev->show_decorations = DECORATE_SHORT_REFS;
+ decoration_style = DECORATE_SHORT_REFS;
else
die("invalid --decorate option: %s", arg);
} else if (!strcmp(arg, "--source")) {
@@ -77,8 +78,10 @@ static void cmd_log_init(int argc, const char **argv, const char *prefix,
} else
die("unrecognized argument: %s", arg);
}
- if (rev->show_decorations)
- load_ref_decorations(rev->show_decorations);
+ if (decoration_style) {
+ rev->show_decorations = 1;
+ load_ref_decorations(decoration_style);
+ }
}
/*
diff --git a/log-tree.c b/log-tree.c
index 1c767c9..1c9eefe 100644
--- a/log-tree.c
+++ b/log-tree.c
@@ -25,7 +25,7 @@ static int add_ref_decoration(const char *refname, const unsigned char *sha1, in
struct object *obj = parse_object(sha1);
if (!obj)
return 0;
- if (!cb_data || *(int *)cb_data & DECORATE_SHORT_REFS)
+ if (!cb_data || *(int *)cb_data == DECORATE_SHORT_REFS)
refname = prettify_refname(refname);
add_name_decoration("", refname, obj);
while (obj->type == OBJ_TAG) {
diff --git a/revision.h b/revision.h
index 9a644ee..b10984b 100644
--- a/revision.h
+++ b/revision.h
@@ -59,6 +59,7 @@ struct rev_info {
rewrite_parents:1,
print_parents:1,
show_source:1,
+ show_decorations:1,
reverse:1,
reverse_output_stage:1,
cherry_pick:1,
@@ -98,7 +99,6 @@ struct rev_info {
const char *subject_prefix;
int no_inline;
int show_log_size;
- int show_decorations;
/* Filter by commit log message */
struct grep_opt grep_filter;
^ permalink raw reply related
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Junio C Hamano @ 2009-08-18 20:17 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Junio C Hamano, Sebastian Schuberth, Artur Skawina, Johannes Sixt,
msysGit, Linus Torvalds, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908181411320.6044@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 18 Aug 2009, Junio C Hamano wrote:
>
>> To reduce confusion, you may want to rename compat/bswap.h to something
>> like compat/ntohl-htonl-fix.h ;-)
>
> Bah. If you wish, you can edit the patch directly for this, unless you
> really prefer me to repost. Maybe we might want to add a 8-byte
> versions of those as well eventually, which is why I chose a more
> generic name.
Ok, here is what I came up with after many squashing...
-- >8 --
From: Nicolas Pitre <nico@cam.org>
Date: Tue, 18 Aug 2009 12:43:08 -0400
Subject: [PATCH] bswap: avoid potentially inefficient ntohl/htonl on i386/x86-64
Johannes Sixt reports that on Windows ntohl()/htonl() are not found in
<arpa/inet.h>, and as a minimal fix we need to include <winsock2.h>
instead. Sebastian Schuberth points out that they are implemented as
out-of-line functions on Windows, which defeats these byteorder "macros"
used for performance.
Use bswap instruction through gcc inline asm instead on i386/x86-64
as a generic solution to this.
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
block-sha1/sha1.c | 4 +---
compat/bswap.h | 19 +++++++++++++++++++
git-compat-util.h | 2 ++
3 files changed, 22 insertions(+), 3 deletions(-)
create mode 100644 compat/bswap.h
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index 464cb25..51a27c1 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -4,9 +4,7 @@
* and to avoid unnecessary copies into the context array.
*/
-#include <string.h>
-#include <arpa/inet.h>
-
+#include "../git-compat-util.h"
#include "sha1.h"
#if defined(__i386__) || defined(__x86_64__)
diff --git a/compat/bswap.h b/compat/bswap.h
new file mode 100644
index 0000000..78fd2df
--- /dev/null
+++ b/compat/bswap.h
@@ -0,0 +1,19 @@
+/*
+ * Let's make sure we always have a sane definition for ntohl()/htonl().
+ * Some libraries define those as a function call, just to perform byte
+ * swapping, bringing significant overhead to what should be a simple
+ * operation.
+ */
+
+#if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))
+
+#define bswap32(x) ({ \
+ unsigned int __res; \
+ __asm__("bswap %0" : "=r" (__res) : "0" (x)); \
+ __res; })
+#undef ntohl
+#undef htonl
+#define ntohl(x) bswap32(x)
+#define htonl(x) bswap32(x)
+
+#endif
diff --git a/git-compat-util.h b/git-compat-util.h
index 9f941e4..000859e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -176,6 +176,8 @@ extern char *gitbasename(char *);
#endif
#endif
+#include "compat/bswap.h"
+
/* General helper functions */
extern void usage(const char *err) NORETURN;
extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
--
1.6.4.245.g50659
^ permalink raw reply related
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Nicolas Pitre @ 2009-08-18 20:10 UTC (permalink / raw)
To: Brandon Casey
Cc: Junio C Hamano, Sebastian Schuberth, Artur Skawina, Johannes Sixt,
msysGit, Linus Torvalds, Git Mailing List
In-Reply-To: <XJM0H8pTiCJpryS-arPltHCHwsm0djqVixaH1NwBqT2pci2MA9karw@cipher.nrlssc.navy.mil>
On Tue, 18 Aug 2009, Brandon Casey wrote:
> The SUNWspro compiler doesn't set __i386__. Instead it sets __i386, and
> I think __x86_64 and __amd64 where appropriate. So, compilation with
> the SUNWspro compiler on x86 is currently unaffected by these changes and
> falls back to the generic routines.
>
> It seems that v5.10 of the compiler can grok both the __asm__ statements
> and the ({...}) naked block notation and passes all of the tests when the
> block_sha1 code is modified to add defined(__i386) to each of the macro
> statements.
Does it really implement the gcc inline assembly syntax?
Nicolas
^ permalink raw reply
* Re: Continue git clone after interruption
From: Nicolas Pitre @ 2009-08-18 20:01 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Tomasz Kontusz, git
In-Reply-To: <m3fxbpneqe.fsf@localhost.localdomain>
On Tue, 18 Aug 2009, Jakub Narebski wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Tue, 18 Aug 2009, Tomasz Kontusz wrote:
> >
> > > Ok, so it looks like it's not implementable without some kind of cache
> > > server-side, so the server would know what the pack it was sending
> > > looked like.
> > > But here's my idea: make server send objects in different order (the
> > > newest commit + whatever it points to first, then next one,then
> > > another...). Then it would be possible to look at what we got, tell
> > > server we have nothing, and want [the newest commit that was not
> > > complete]. I know the reason why it is sorted the way it is, but I think
> > > that the way data is stored after clone is clients problem, so the
> > > client should reorganize packs the way it wants.
> >
> > That won't buy you much. You should realize that a pack is made of:
> >
> > 1) Commit objects. Yes they're all put together at the front of the pack,
> > but they roughly are the equivalent of:
> >
> > git log --pretty=raw | gzip | wc -c
> >
> > For the Linux repo as of now that is around 32 MB.
>
> For my clone of Git repository this gives 3.8 MB
>
> > 2) Tree and blob objects. Those are the bulk of the content for the top
> > commit. The top commit is usually not delta compressed because we
> > want fast access to the top commit, and that is used as the base for
> > further delta compression for older commits. So the very first
> > commit is whole at the front of the pack right after the commit
> > objects. you can estimate the size of this data with:
> >
> > git archive --format=tar HEAD | gzip | wc -c
> >
> > On the same Linux repo this is currently 75 MB.
>
> On the same Git repository this gives 2.5 MB
Interesting to see that the commit history is larger than the latest
source tree. Probably that would be the same with the Linux kernel as
well if all versions since the beginning with adequate commit logs were
included in the repo.
> > 3) Delta objects. Those are making the rest of the pack, plus a couple
> > tree/blob objects that were not found in the top commit and are
> > different enough from any object in that top commit not to be
> > represented as deltas. Still, the majority of objects for all the
> > remaining commits are delta objects.
>
> You forgot that delta chains are bound by pack.depth limit, which
> defaults to 50. You would have then additional full objects.
Sure, but that's probably not significant. the delta chain depth is
limited, but not the width. A given base object can have unlimited
delta "children", and so on at each depth level.
> The single packfile for this (just gc'ed) Git repository is 37 MB.
> Much more than 3.8 MB + 2.5 MB = 6.3 MB.
What I'm saying is that most of that 37 MB - 6.3 MB = 31 MB is likely to
be occupied by deltas.
> [cut]
>
> There is another way which we can go to implement resumable clone.
> Let's git first try to clone whole repository (single pack; BTW what
> happens if this pack is larger than file size limit for given
> filesystem?).
We currently fail. Seems that no one ever had a problem with that so
far. We'd have to split the pack stream into multiple packs on the
receiving end. But frankly, if you have a repository large enough to
bust your filesystem's file size limit then maybe you should seriously
reconsider your choice of development environment.
> If it fails, client ask first for first half of of
> repository (half as in bisect, but it is server that has to calculate
> it). If it downloads, it will ask server for the rest of repository.
> If it fails, it would reduce size in half again, and ask about 1/4 of
> repository in packfile first.
Problem people with slow links have won't be helped at all with this.
What if the network connection gets broken only after 49% of the
transfer and that took 3 hours to download? You'll attempt a 25% size
transfer which would take 1.5 hour despite the fact that you already
spent that much time downloading that first 1/4 of the repository
already. And yet what if you're unlucky and now the network craps on
you after 23% of that second attempt?
I think it is better to "prime" the repository with the content of the
top commit in the most straight forward manner using git-archive which
has the potential to be fully restartable at any point with little
complexity on the server side.
Nicolas
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Brandon Casey @ 2009-08-18 19:56 UTC (permalink / raw)
To: Junio C Hamano
Cc: Nicolas Pitre, Sebastian Schuberth, Artur Skawina, Johannes Sixt,
msysGit, Linus Torvalds, Git Mailing List
In-Reply-To: <7vk511dk11.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Another issue, especially with your "openssl sha1 removal" patch, is if we
> can assume gcc everywhere. As far as I can tell, block-sha1/sha1.c will
> be the first unconditional use of inline asm or statement expression on
> i386/amd64. Are folks on Solaris and other platforms Ok with this?
The SUNWspro compiler doesn't set __i386__. Instead it sets __i386, and
I think __x86_64 and __amd64 where appropriate. So, compilation with
the SUNWspro compiler on x86 is currently unaffected by these changes and
falls back to the generic routines.
It seems that v5.10 of the compiler can grok both the __asm__ statements
and the ({...}) naked block notation and passes all of the tests when the
block_sha1 code is modified to add defined(__i386) to each of the macro
statements.
The 5.8 version cannot grok the naked block, and requires spelling __asm__
as __asm for inline assembly. Even then it appears that there is a bug in
the assembly that is produced (a google search told me so), so the assembly
code does not successfully compile.
I haven't had much time to think about how or whether to address this.
Adding something like the following would get ugly real quick:
(defined(__i386) && defined(__SUNPRO_C) && (__SUNPRO_C >= 0x5100))
For now, the code compiles fine using the SUNWspro compiler on x86 even if
it is suboptimal compared to gcc. It is still an improvement over the
mozilla code.
-brandon
^ permalink raw reply
* learning curve (aka Git User's Survey 2009 partial summary, part 2 - from first 10)
From: Nicolas Sebrecht @ 2009-08-18 19:55 UTC (permalink / raw)
To: Jakub Narebski; +Cc: Nicolas Sebrecht, git
In-Reply-To: <200908181900.03356.jnareb@gmail.com>
The 18/08/09, Jakub Narebski wrote:
> > I believe it would be interesting to know who (from the question 6.)
> > think what later. We may expect that people of the grade 4 and 5 ("can
> > offer advice" and "know it very well") underestimate the difficulty to
> > learn Git.
>
> Well, you can do some analysis yourself, using just created filters at
> http://www.survs.com/shareResults?survey=2PIMZGU0&rndm=678J66QRA2
Thank you very much.
> For example:
>
> ================================================|
> | proficiency with Git |
> To learn |-----------------------------|
> | any*[%] | 1-3 [%] | 4-5 [%] |
> ------------------------------------------------|
> Very easy | 4% | 3% | 5% |
> Easy | 20% | 19% | 22% |
> Reasonably easy | 55% | 55% | 56% |
> Hard | 19% | 20% | 16% |
> Very hard | 2% | 3% | 1% |
> ------------------------------------------------|
> Total respondents | 3005 | 1786 | 1212 |
> ================================================|
This looks consistent. Here are some more grained summaries based on
your filters:
=========================================================
| TO LEARN (%) |
===============================================================================
Proficiency | very easy | easy | reasonably easy | hard | very hard |
===============================================================================
no filter (any) | 4 | 20 | 55 | 19 | 2 |
――――――――――――――――――――――|―――――――――――|――――――|―――――――――――――――――|――――――|―――――――――――|
1. novice | 3 | 12 | 49 | 25 | 11 |
2. casual | 2 | 17 | 54 | 25 | 3 |
3. everyday use | 4 | 21 | 56 | 18 | 2 |
4. can offer advice | 4 | 23 | 56 | 17 | 1 |
5. know it very well | 11 | 20 | 54 | 14 | 1 |
===============================================================================
=========================================================
| TO USE (%) |
===============================================================================
Proficiency | very easy | easy | reasonably easy | hard | very hard |
===============================================================================
no filter (any) | 9 | 37 | 45 | 8 | 1 |
――――――――――――――――――――――|―――――――――――|――――――|―――――――――――――――――|――――――|―――――――――――|
1. novice | 5 | 17 | 47 | 25 | 7 |
2. casual | 5 | 27 | 51 | 15 | 2 |
3. everyday use | 8 | 36 | 47 | 8 | 1 |
4. can offer advice | 11 | 44 | 40 | 4 | 0 |
5. know it very well | 22 | 37 | 36 | 5 | 1 |
===============================================================================
What appears here first is that the averages of the third category
("everyday day use") are _very_ near from the averages of the whole users.
This gives a good confidence in the results.
Simplified summary:
===============================================
| TO LEARN (%) |
=====================================================================
Proficiency | (very) easy | reasonably easy | (very) hard |
=====================================================================
no filter (any) | 24 | 55 | 21 |
――――――――――――――――――――――|―――――――――――――|―――――――――――――――――|―――――――――――――|
1. novice | 15 | 49 | 36 |
2. casual | 19 | 54 | 28 |
----------------------|-------------|-----------------|-------------|
3. everyday use | 25 | 56 | 20 |
----------------------|-------------|-----------------|-------------|
4. can offer advice | 27 | 56 | 18 |
5. know it very well | 31 | 54 | 15 |
=====================================================================
===============================================
| TO USE (%) |
=====================================================================
Proficiency | (very) easy | reasonably easy | (very) hard |
=====================================================================
no filter (any) | 36 | 45 | 9 |
――――――――――――――――――――――|―――――――――――――|―――――――――――――――――|―――――――――――――|
1. novice | 22 | 47 | 32 |
2. casual | 32 | 51 | 17 |
----------------------|-------------|-----------------|-------------|
3. everyday use | 44 | 47 | 9 |
----------------------|-------------|-----------------|-------------|
4. can offer advice | 55 | 40 | 4 |
5. know it very well | 59 | 36 | 6 |
=====================================================================
--
Nicolas Sebrecht
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Junio C Hamano @ 2009-08-18 19:40 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <7vk511dk11.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Another issue, especially with your "openssl sha1 removal" patch, is if we
> can assume gcc everywhere. As far as I can tell, block-sha1/sha1.c will
> be the first unconditional use of inline asm or statement expression on
> i386/amd64. Are folks on Solaris and other platforms Ok with this?
Ahhh, your bswap.h is a no-op unless you use gcc, so my worry was
unfounded.
^ permalink raw reply
* [PATCH] block-sha1: guard gcc extensions with __GNUC__
From: Nicolas Pitre @ 2009-08-18 19:37 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908181516510.6044@xanadu.home>
With this, the code should now be portable to any C compiler.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Tue, 18 Aug 2009, Nicolas Pitre wrote:
> On Tue, 18 Aug 2009, Junio C Hamano wrote:
>
> > Another issue, especially with your "openssl sha1 removal" patch, is if we
> > can assume gcc everywhere. As far as I can tell, block-sha1/sha1.c will
> > be the first unconditional use of inline asm or statement expression on
> > i386/amd64. Are folks on Solaris and other platforms Ok with this?
>
> I guess we can guard the first with ifdef(__GNUC__) which should help
> people with MSVC. That should take care of x86 at least.
Here it is.
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index d31f2e3..92d9121 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -9,7 +9,7 @@
#include "sha1.h"
-#if defined(__i386__) || defined(__x86_64__)
+#if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))
/*
* Force usage of rol or ror by selecting the one with the smaller constant.
@@ -54,7 +54,7 @@
#if defined(__i386__) || defined(__x86_64__)
#define setW(x, val) (*(volatile unsigned int *)&W(x) = (val))
-#elif defined(__arm__)
+#elif defined(__GNUC__) && defined(__arm__)
#define setW(x, val) do { W(x) = (val); __asm__("":::"memory"); } while (0)
#else
#define setW(x, val) (W(x) = (val))
^ permalink raw reply related
* [PATCH] make sure byte swapping is optimal for git
From: Nicolas Pitre @ 2009-08-18 19:26 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908181516510.6044@xanadu.home>
We rely on ntohl() and htonl() to perform byte swapping in many places.
However, some platforms have libraries providing really poor
implementations of those which might cause significant performance
issues, especially with the block-sha1 code.
Signed-off-by: Nicolas Pitre <nico@cam.org>
---
On Tue, 18 Aug 2009, Nicolas Pitre wrote:
> Well, I gave in and added a comment to the patch anyway, with more
> improvements in the case of constant values. Patch follows.
diff --git a/block-sha1/sha1.c b/block-sha1/sha1.c
index 464cb25..d31f2e3 100644
--- a/block-sha1/sha1.c
+++ b/block-sha1/sha1.c
@@ -4,8 +4,8 @@
* and to avoid unnecessary copies into the context array.
*/
-#include <string.h>
-#include <arpa/inet.h>
+/* this is only to get definitions for memcpy(), ntohl() and htonl() */
+#include "../git-compat-util.h"
#include "sha1.h"
diff --git a/compat/bswap.h b/compat/bswap.h
new file mode 100644
index 0000000..7246a12
--- /dev/null
+++ b/compat/bswap.h
@@ -0,0 +1,36 @@
+/*
+ * Let's make sure we always have a sane definition for ntohl()/htonl().
+ * Some libraries define those as a function call, just to perform byte
+ * shifting, bringing significant overhead to what should be a simple
+ * operation.
+ */
+
+/*
+ * Default version that the compiler ought to optimize properly with
+ * constant values.
+ */
+static inline unsigned int default_swab32(unsigned int val)
+{
+ return (((val & 0xff000000) >> 24) |
+ ((val & 0x00ff0000) >> 8) |
+ ((val & 0x0000ff00) << 8) |
+ ((val & 0x000000ff) << 24));
+}
+
+#if defined(__GNUC__) && (defined(__i386__) || defined(__x86_64__))
+
+#define bswap32(x) ({ \
+ unsigned int __res; \
+ if (__builtin_constant_p(x)) { \
+ __res = default_swab32(x); \
+ } else { \
+ __asm__("bswap %0" : "=r" (__res) : "0" (x)); \
+ } \
+ __res; })
+
+#undef ntohl
+#undef htonl
+#define ntohl(x) bswap32(x)
+#define htonl(x) bswap32(x)
+
+#endif
diff --git a/git-compat-util.h b/git-compat-util.h
index 9f941e4..000859e 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -176,6 +176,8 @@ extern char *gitbasename(char *);
#endif
#endif
+#include "compat/bswap.h"
+
/* General helper functions */
extern void usage(const char *err) NORETURN;
extern void die(const char *err, ...) NORETURN __attribute__((format (printf, 1, 2)));
^ permalink raw reply related
* Re: [PATCH][resend] git-svn: Respect GIT_SSH setting
From: Junio C Hamano @ 2009-08-18 19:25 UTC (permalink / raw)
To: Karthik R; +Cc: git
In-Reply-To: <4A89EC07.2010402@fastmail.fm>
Karthik R <karthikr@fastmail.fm> writes:
>> Two questions.
>>
>> - What if a user has SVN_SSH exported _and_ wants to use a different one
>> from the one s/he uses for git? Naturally such a user would set both
>> environment variables and differently, but this seems to override the
>> value in SVN_SSH;
>>
> Do you mean user wants to use a different one with "git svn
> ... svn+ssh://" (than the one with "git clone ssh://") ?
Yes.
> In this case
> - defining SVN_SSH, but not GIT_SSH will still work (with this patch,
> GIT_SSH overrides)
Which means if you need to use GIT_SSH to specify one and SVN_SSH to
specify another, you have trouble. IOW, you cannot use anything but
whatever the default is for native git access over ssh:// protocol.
> - but SVN_SSH needs to have \\s.
>
> So unless the user already knew of this quirk, we'll only see
> unescaped \s - so it *does* make sense to escape the \s (if the user
> knew, then too many escaped \s still work).
>
>> - Can a user have SVN_SSH exported, on MSWin32 or msys, and use svn
>> outside git? If so, what does the value of SVN_SSH look like? Does it
>> typically have necessary doubling of backslashes already?
>>
> With subversion for Windows, these \\s are not needed (but doesn't
> cause any break). The doubling is something to do with the bash (in
> msys) I think.
>
Ok, so does that mean the logic should look more like the one you quoted
below without saying yes/no/anything? The points are:
(1) do not muck with SVN_SSH if already given by the user.
(2) when and only when we reuse value from GIT_SSH for SVN_SSH, double
the backslashes.
>> What I am getting at is, if the patch should look something like this
>> instead:
>>
>> if (! exists $ENV{SVN_SSH}) {
>> if (exists $ENV{GIT_SSH}) {
>> $ENV{SVN_SSH} = $ENV{GIT_SSH};
>> if ($^O eq 'MSWin32' || $^O eq 'msys') {
>> $ENV{SVN_SSH} =~ s/\\/\\\\/g;
>> }
>> }
>> }
>>
>>
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Nicolas Pitre @ 2009-08-18 19:22 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <7vk511dk11.fsf@alter.siamese.dyndns.org>
On Tue, 18 Aug 2009, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Tue, 18 Aug 2009, Junio C Hamano wrote:
> >
> >> For git's own use, I would be much happier with this change.
> >>
> >> But given that there are some people wanting to snarf block-sha1/*.[ch]
> >> out to use them standalone, I have a slight hesitation against introducing
> >> the dependency to git-compat-util.h, making it unclear to them that all
> >> this file wants from outside are ntohl, htonl and memcpy.
> >
> > Should we really care to keep our code suboptimal just to make it
> > readily reusable by other projects? That seems a bit backward to me.
>
> You are right; and I should give a bit more credit to their intelligence.
> The source (block-sha1/sha1.c) is short enough that they can figure this
> out for themselves even without any additional comments.
Well, I gave in and added a comment to the patch anyway, with more
improvements in the case of constant values. Patch follows.
> Another issue, especially with your "openssl sha1 removal" patch, is if we
> can assume gcc everywhere. As far as I can tell, block-sha1/sha1.c will
> be the first unconditional use of inline asm or statement expression on
> i386/amd64. Are folks on Solaris and other platforms Ok with this?
I guess we can guard the first with
ifdef(__GNUC__) which should help
people with MSVC. That should take care of x86 at least.
Nicolas
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Junio C Hamano @ 2009-08-18 19:00 UTC (permalink / raw)
To: Nicolas Pitre
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <alpine.LFD.2.00.0908181357330.6044@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 18 Aug 2009, Junio C Hamano wrote:
>
>> For git's own use, I would be much happier with this change.
>>
>> But given that there are some people wanting to snarf block-sha1/*.[ch]
>> out to use them standalone, I have a slight hesitation against introducing
>> the dependency to git-compat-util.h, making it unclear to them that all
>> this file wants from outside are ntohl, htonl and memcpy.
>
> Should we really care to keep our code suboptimal just to make it
> readily reusable by other projects? That seems a bit backward to me.
You are right; and I should give a bit more credit to their intelligence.
The source (block-sha1/sha1.c) is short enough that they can figure this
out for themselves even without any additional comments.
Another issue, especially with your "openssl sha1 removal" patch, is if we
can assume gcc everywhere. As far as I can tell, block-sha1/sha1.c will
be the first unconditional use of inline asm or statement expression on
i386/amd64. Are folks on Solaris and other platforms Ok with this?
^ permalink raw reply
* Re: Continue git clone after interruption
From: Jakub Narebski @ 2009-08-18 18:45 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Tomasz Kontusz, git
In-Reply-To: <alpine.LFD.2.00.0908181246470.6044@xanadu.home>
Nicolas Pitre <nico@cam.org> writes:
> On Tue, 18 Aug 2009, Tomasz Kontusz wrote:
>
> > Ok, so it looks like it's not implementable without some kind of cache
> > server-side, so the server would know what the pack it was sending
> > looked like.
> > But here's my idea: make server send objects in different order (the
> > newest commit + whatever it points to first, then next one,then
> > another...). Then it would be possible to look at what we got, tell
> > server we have nothing, and want [the newest commit that was not
> > complete]. I know the reason why it is sorted the way it is, but I think
> > that the way data is stored after clone is clients problem, so the
> > client should reorganize packs the way it wants.
>
> That won't buy you much. You should realize that a pack is made of:
>
> 1) Commit objects. Yes they're all put together at the front of the pack,
> but they roughly are the equivalent of:
>
> git log --pretty=raw | gzip | wc -c
>
> For the Linux repo as of now that is around 32 MB.
For my clone of Git repository this gives 3.8 MB
> 2) Tree and blob objects. Those are the bulk of the content for the top
> commit. The top commit is usually not delta compressed because we
> want fast access to the top commit, and that is used as the base for
> further delta compression for older commits. So the very first
> commit is whole at the front of the pack right after the commit
> objects. you can estimate the size of this data with:
>
> git archive --format=tar HEAD | gzip | wc -c
>
> On the same Linux repo this is currently 75 MB.
On the same Git repository this gives 2.5 MB
>
> 3) Delta objects. Those are making the rest of the pack, plus a couple
> tree/blob objects that were not found in the top commit and are
> different enough from any object in that top commit not to be
> represented as deltas. Still, the majority of objects for all the
> remaining commits are delta objects.
You forgot that delta chains are bound by pack.depth limit, which
defaults to 50. You would have then additional full objects.
The single packfile for this (just gc'ed) Git repository is 37 MB.
Much more than 3.8 MB + 2.5 MB = 6.3 MB.
[cut]
There is another way which we can go to implement resumable clone.
Let's git first try to clone whole repository (single pack; BTW what
happens if this pack is larger than file size limit for given
filesystem?). If it fails, client ask first for first half of of
repository (half as in bisect, but it is server that has to calculate
it). If it downloads, it will ask server for the rest of repository.
If it fails, it would reduce size in half again, and ask about 1/4 of
repository in packfile first.
The only extension required is for server to support additional
capability, which enable for client to ask for appropriate 1/2^n part
of repository (approximately), or 1/2^n between have and want.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Daniel Barkalow @ 2009-08-18 18:42 UTC (permalink / raw)
To: Marius Storm-Olsen
Cc: Johannes Schindelin, msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <4A8AEAF5.6070205@gmail.com>
On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
> Johannes Schindelin said the following on 18.08.2009 16:11:
> > On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
> > > So, instead of rely on these vcproj files which *will* go stale, we
> > > can simply use the same Makefile system which everyone else is
> > > using. :) After all, we're just compiling with a different
> > > compiler. The end result will still rely on the *msysGit
> > > environment* to function, so we already require it. Thus, GNU Make
> > > is present, and we can use it.
> >
> > We can also use sed or perl to generate/modify the .vcproj files, or
> > run CMake (once Pau got it to build), and package the stuff using zip
> > (once I got that to build).
>
> Really? That would be some script being able to parse the Makefile, and create
> something reasonable as a vcproj script :) Keeping all the options in sync,
> conditional files/libs, all the various end executables (a separate .vcproj
> for each of them, and a solution file (.sln)to tie them all together into a ..
> "solution", a complete product blah blah blah) etc.
I think it wouldn't be impossible to split the Makefile into an
easy-to-parse part and an irrelevant-to-vcproj part. Certainly you don't
need GNU Make to read a file:
SCRIPT_SH += git-am.sh
SCRIPT_SH += git-bisect.sh
SCRIPT_PERL += git-add--interactive.perl
PROGRAM_NAMES += git-fast-import
BUILTINS_IN_OBJS += add
(etc)
That is, we can probably describe the project sufficiently with a lot of
VAR += value
lines, using only constant values and variables we specify, and then the
Makefile declares them empty and does an
include UserServicableParts
and puts together the variables it needs. And things that aren't GNU Make
could also process this file without enormous difficulty, since it's
essentially a .ini file or java resource file with a stray + on each line.
Of course, people interested in the vcproj thing would have to update
whatever makes VC do the right thing when new *rules* are introduced, but
that's a lot less common than new *files* being introduced, and also more
obvious (in the sense that the included file is setting variables that the
builder doesn't know what to do with).
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Nicolas Pitre @ 2009-08-18 18:16 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <7vpratdpc8.fsf@alter.siamese.dyndns.org>
On Tue, 18 Aug 2009, Junio C Hamano wrote:
> To reduce confusion, you may want to rename compat/bswap.h to something
> like compat/ntohl-htonl-fix.h ;-)
Bah. If you wish, you can edit the patch directly for this, unless you
really prefer me to repost. Maybe we might want to add a 8-byte
versions of those as well eventually, which is why I chose a more
generic name.
Nicolas
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Nicolas Pitre @ 2009-08-18 18:10 UTC (permalink / raw)
To: Sebastian Schuberth
Cc: Junio C Hamano, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <bdca99240908180959h69f37671k4d526fbf4814e8d1@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1542 bytes --]
On Tue, 18 Aug 2009, Sebastian Schuberth wrote:
> On Tue, Aug 18, 2009 at 18:43, Nicolas Pitre<nico@cam.org> wrote:
>
> >> Well... Given that git already uses ntohl/htonl quite extensively in
> >> its core already, I'd suggest making this more globally available
> >> instead.
> >
> > What about something like this?
>
> I like the idea of making bswap available more globally, but I'm not
> sure if it's worth to introduce a new file for only that purpose.
> Isn't there already a central header for such things?
That central header is already quite crowded. A bit of isolation might
not hurt.
Furthermore, other platforms might wish to add their own (re)definitions
for those byte swap operations, so it has the potential to grow. I for
example have a better implementation for ARM than what is provided by
glibc. (Yeah yeah, maybe glibc should be fixed instead, but that
reasoning goes for all those other libraries too).
> Moreover, including compat/bswap.h would only give you ntohl()/htonl()
> on one platform. For consistency, I'd expect to get those for any
> platform if I include compat/bswap.h, but maybe I'm not aware of some
> Git source code rules.
You get it by default for all platforms already by including
git-compat-util.h. The compat/bswap.h is not meant to be included by
random c files. If compat/bswap.h happens to contain a better version
for your architecture then it'll override the default one.
> Finally, there's a typo in your comment saying "sinple" instead of "simple".
Thanks
Nicolas
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Marius Storm-Olsen @ 2009-08-18 18:06 UTC (permalink / raw)
To: Johan 't Hart
Cc: Junio C Hamano, Johannes.Schindelin, msysgit, git, lznuaa,
bonzini, kusmabite
In-Reply-To: <4A8AE7C5.7050600@gmail.com>
Johan 't Hart said the following on 18.08.2009 19:41:
> Junio C Hamano schreef:
>> Since use of make implies use of shell, this makes me wonder if it
>> would make sense to go one step further by giving msvc users a thin
>> shell wrapper mcvc-cc that turns bog-standard cc command line into
>> whatever cl uses.
>
> Just using the msvc toolchain for building git misses the whole
> purpose of what VC is used for. MSVC would be used because of the
> IDE, not for the compiler IMO.
Bull. MSVC produces superior code on Windows compared to MinGW, I'm
afraid. Add the /LTGC (Link Time Code Generation), and MSVC generates
very good cross compile-unit optimized code. (I know gcc has the option,
but it's not as good, by far)
Coupled now with built-in static code analysis, these are only two
reasons why *I* would want to build it directly from the command line
without worrying that my .vcproj is out-of-sync with the main development.
You can still debug with the MSVC debugger if you'd like, and the MSVC
IDE allows you to wrap Makefile project too, so you can *still* use the
IDE..
--
.marius
^ permalink raw reply
* Re: [PATCH] block-sha1: Windows declares ntohl() in winsock2.h
From: Nicolas Pitre @ 2009-08-18 18:01 UTC (permalink / raw)
To: Junio C Hamano
Cc: Sebastian Schuberth, Artur Skawina, Johannes Sixt, msysGit,
Linus Torvalds, Git Mailing List
In-Reply-To: <7v1vn9f4mz.fsf@alter.siamese.dyndns.org>
On Tue, 18 Aug 2009, Junio C Hamano wrote:
> Nicolas Pitre <nico@cam.org> writes:
>
> > On Tue, 18 Aug 2009, Nicolas Pitre wrote:
> >
> >> Well... Given that git already uses ntohl/htonl quite extensively in
> >> its core already, I'd suggest making this more globally available
> >> instead.
> >
> > What about something like this?
>
> For git's own use, I would be much happier with this change.
>
> But given that there are some people wanting to snarf block-sha1/*.[ch]
> out to use them standalone, I have a slight hesitation against introducing
> the dependency to git-compat-util.h, making it unclear to them that all
> this file wants from outside are ntohl, htonl and memcpy.
Should we really care to keep our code suboptimal just to make it
readily reusable by other projects? That seems a bit backward to me.
We might simply add a comment telling people what git-compat-util.h is
actually for, namely memcpy(), ntohl() and htonl(). That should be
trivial for them to use the appropriate substitute.
Nicolas
^ permalink raw reply
* Re: Continue git clone after interruption
From: Nicolas Pitre @ 2009-08-18 17:56 UTC (permalink / raw)
To: Tomasz Kontusz; +Cc: git
In-Reply-To: <1250578735.2885.40.camel@cf-48>
On Tue, 18 Aug 2009, Tomasz Kontusz wrote:
> Ok, so it looks like it's not implementable without some kind of cache
> server-side, so the server would know what the pack it was sending
> looked like.
> But here's my idea: make server send objects in different order (the
> newest commit + whatever it points to first, then next one,then
> another...). Then it would be possible to look at what we got, tell
> server we have nothing, and want [the newest commit that was not
> complete]. I know the reason why it is sorted the way it is, but I think
> that the way data is stored after clone is clients problem, so the
> client should reorganize packs the way it wants.
That won't buy you much. You should realize that a pack is made of:
1) Commit objects. Yes they're all put together at the front of the pack,
but they roughly are the equivalent of:
git log --pretty=raw | gzip | wc -c
For the Linux repo as of now that is around 32 MB.
2) Tree andblob objects. Those are the bulk of the content for the top
commit. The top commit is usually not delta compressed because we
want fast access to the top commit, and that is used as the base for
further delta compression for older commits. So the very first
commit is whole at the front of the pack right after the commit
objects. you can estimate the size of this data with:
git archive --format=tar HEAD | gzip | wc -c
On the same Linux repo this is currently 75 MB.
3) Delta objects. Those are making the rest of the pack, plus a couple
tree/blob objects that were not found in the top commit and are
different enough from any object in that top commit not to be
represented as deltas. Still, the majority of objects for all the
remaining commits are delta objects.
So... if we reorder objects, all that we can do is to spread commit
objects around so that the objects referenced by one commit are all seen
before another commit object is included. That would cut on that
initial 32 MB.
However you still have to get that 75 MB in order to at least be able to
look at _one_ commit. So you've only reduced your critical download
size from 107 MB to 75 MB. This is some improvement, of course, but not
worth the bother IMHO. If we're to have restartable clone, it has to
work for any size.
And that's where the real problem is. I don't think having servers to
cache pack results for every fetch requests is sensible as that would be
an immediate DoS attack vector.
And because the object order in a pack is not defined by the protocol,
we cannot expect the server to necessarily always provide the same
object order either. For example, it is already undefined in which
order you'll receive objects as threaded delta search is non
deterministic and two identical fetch requests may end up with slightly
different packing. Or load balancing may redirect your fetch requests
to different git servers which might have different versions of zlib, or
even git itself, affecting the object packing order and/or size.
Now... What _could_ be done, though, is some extension to the
git-archive command. One thing that is well and strictly defined in git
is the file path sort order. So given a commit SHA1, you should always
get the same files in the same order from git-archive. For an initial
clone, git could attempt fetching the top commit using the remote
git-archive service and locally reconstruct that top commit that way.
if the transfer is interrupted in the middle, then the remote
git-archive could be told how to resume the transfer by telling it how
many files and how many bytes in the current file to skip. This way the
server doesn't need to perform any sort of caching and remains
stateless.
You then end up with a pretty shallow repository. The clone process
could then fall back to the traditional native git transfer protocol to
deepen the history of that shallow repository. And then that special
packing sort order to distribute commit objects would make sense since
each commit would then have a fairly small set of new objects, and most
of them would be deltas anyway, making the data size per commit really
small and any interrupted transfer much less of an issue.
Nicolas
^ permalink raw reply
* Re: [RFC] Enable compilation by Makefile for the MSVC toolchain
From: Marius Storm-Olsen @ 2009-08-18 17:55 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: msysgit, git, lznuaa, bonzini, kusmabite
In-Reply-To: <alpine.DEB.1.00.0908181605370.4680@intel-tinevez-2-302>
Johannes Schindelin said the following on 18.08.2009 16:11:
> On Tue, 18 Aug 2009, Marius Storm-Olsen wrote:
>> So, instead of rely on these vcproj files which *will* go stale, we
>> can simply use the same Makefile system which everyone else is
>> using. :) After all, we're just compiling with a different
>> compiler. The end result will still rely on the *msysGit
>> environment* to function, so we already require it. Thus, GNU Make
>> is present, and we can use it.
>
> We can also use sed or perl to generate/modify the .vcproj files, or
> run CMake (once Pau got it to build), and package the stuff using zip
> (once I got that to build).
Really? That would be some script being able to parse the Makefile, and
create something reasonable as a vcproj script :) Keeping all the
options in sync, conditional files/libs, all the various end executables
(a separate .vcproj for each of them, and a solution file (.sln)to tie
them all together into a .. "solution", a complete product blah blah
blah) etc.
Just using the (GNU) Makefile as the 'default' way of compiling with
MSVC seems to be the most reasonable to me. Then we could just have a
contrib/vc/msvc2008.vcproj which someone can update when they feel like
it. The default way should be hard to get out-of-sync, IMO.
>> diff --git a/Makefile b/Makefile
>> +ifneq (,$(findstring Microsoft Visual Studio, $(INCLUDE)))
...
>> +else
>> ifneq (,$(findstring MINGW,$(uname_S)))
>> pathsep = ;
>> NO_PREAD = YesPlease
>
> This means that gcc is never used when Visual C++ is available? Hmm.
Yes it does :)
First, "This implementation is a quick hack to make it compile", so it
was all about just making it compile, not being 100% correct. There are
still some warnings and options which shouldn't be passed on to cl, so
it's by no means complete. Second, having MSVC include paths in INCLUDE
when you're compiling with MinGW would be plain wrong. I could use LIB
instead, which would be even wronger ;)
I was actually going to replace it with a USE_MSVC variable check
instead though, so you'd rather do 'make USE_MSVC=1'
>> diff --git a/compat/msvc.h b/compat/msvc.h
>> index 6071565..a9d5f7f 100644
>> --- a/compat/msvc.h
>> +++ b/compat/msvc.h
>> @@ -10,50 +10,120 @@
>>
>> /*Configuration*/
>>
>> +#ifndef NO_PREAD
>> #define NO_PREAD
>> +#endif
>
> Why? You now have the stuff in two places. If you want to keep them in
> compat/msvc.h to be able to generate .vcproj files, I'd rather not have
> them duplicated in the Makefile.
The changes to the msvc.h where added just keep Frank's vcproj project
working. I would have just nuked all that stuff in the msvc.h since the
Makefile would just provide it for me anyways..
--
.marius
^ 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