* [PATCH] autoconf: Add config.cache to .gitignore
From: Jakub Narebski @ 2006-09-07 12:30 UTC (permalink / raw)
To: git
Add generated file config.cache (default cache file, when running
./configure with -C, --config-cache option) to the list of ignored
files.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
'make clean' does remove config.cache already.
This file is not generated by default.
.gitignore | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/.gitignore b/.gitignore
index 78cb671..0d608fe 100644
--- a/.gitignore
+++ b/.gitignore
@@ -141,6 +141,7 @@ git-core.spec
*.py[co]
config.mak
autom4te.cache
+config.cache
config.log
config.status
config.mak.autogen
--
1.4.2
^ permalink raw reply related
* [PATCH 1/2] autoconf: Set NO_ICONV if iconv is found neither in libc, nor in libiconv
From: Jakub Narebski @ 2006-09-07 11:48 UTC (permalink / raw)
To: git
In-Reply-To: <200609071347.32152.jnareb@gmail.com>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This patch only adds NO_ICONV=YesPlease, and it never unsets
NO_ICONV. This doesn't matter now because there is no setting
NO_ICONV value in Makefile (no architecture/system based detection).
configure.ac | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index 482c849..8af276c 100644
--- a/configure.ac
+++ b/configure.ac
@@ -143,9 +143,12 @@ AC_CHECK_LIB([expat], [XML_ParserCreate]
AC_SUBST(NO_EXPAT)
#
# Define NEEDS_LIBICONV if linking with libc is not enough (Darwin).
+# Define NO_ICONV if neither libc nor libiconv support iconv.
AC_CHECK_LIB([c], [iconv],
-[NEEDS_LIBICONV=],
-[NEEDS_LIBICONV=YesPlease])
+ [NEEDS_LIBICONV=],
+ AC_CHECK_LIB([iconv], [iconv],
+ [NEEDS_LIBICONV=YesPlease],
+ [GIT_CONF_APPEND_LINE([NO_ICONV=YesPlease])]))
AC_SUBST(NEEDS_LIBICONV)
test -n "$NEEDS_LIBICONV" && LIBS="$LIBS -liconv"
#
--
1.4.2
^ permalink raw reply related
* [PATCH 2/2] autoconf: Add support for setting NO_ICONV and ICONVDIR
From: Jakub Narebski @ 2006-09-07 11:48 UTC (permalink / raw)
To: git
In-Reply-To: <200609071347.32152.jnareb@gmail.com>
Add support for ./configure options --without-iconv (if neither libc
nor libiconv properly support iconv), and for --with-iconv=PATH (to
set prefix to libiconv library and headers, used only when
NEED_LIBICONV is set). While at it, make ./configure set or unset
NO_ICONV always (it is not autodetected in Makefile).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
The config.mak.in patch just adds or uncomments
NO_ICONV=@NO_ICONV@
at the end of the file. If there is conflict during applying this part
of patchset (for example "autoconf: Add some commented out variables
to config.mak.in" and "autoconf: Preliminary check for working mmap"
are not applied), just modify config.mak.in to have this line at the
end.
config.mak.in | 2 +-
configure.ac | 13 ++++++++++++-
2 files changed, 13 insertions(+), 2 deletions(-)
diff --git a/config.mak.in b/config.mak.in
index 2c8fd2c..fccde61 100644
--- a/config.mak.in
+++ b/config.mak.in
@@ -38,5 +38,5 @@ NO_STRCASESTR=@NO_STRCASESTR@
NO_STRLCPY=@NO_STRLCPY@
NO_SETENV=@NO_SETENV@
NO_MMAP=@NO_MMAP@
-#NO_ICONV=@NO_ICONV@
+NO_ICONV=@NO_ICONV@
diff --git a/configure.ac b/configure.ac
index 8af276c..6a980a5 100644
--- a/configure.ac
+++ b/configure.ac
@@ -148,8 +148,9 @@ AC_CHECK_LIB([c], [iconv],
[NEEDS_LIBICONV=],
AC_CHECK_LIB([iconv], [iconv],
[NEEDS_LIBICONV=YesPlease],
- [GIT_CONF_APPEND_LINE([NO_ICONV=YesPlease])]))
+ [NO_ICONV=YesPlease]))
AC_SUBST(NEEDS_LIBICONV)
+AC_SUBST(NO_ICONV)
test -n "$NEEDS_LIBICONV" && LIBS="$LIBS -liconv"
#
# Define NEEDS_SOCKET if linking with libc is not enough (SunOS,
@@ -350,6 +351,16 @@ # specify your own (or DarwinPort's) inc
# library directories by defining CFLAGS and LDFLAGS appropriately.
#
# Define NO_MMAP if you want to avoid mmap.
+#
+# Define NO_ICONV if your libc does not properly support iconv.
+AC_ARG_WITH(iconv,
+AS_HELP_STRING([--without-iconv],
+[if your architecture doesn't properly support iconv])
+AS_HELP_STRING([--with-iconv=PATH],
+[PATH is prefix for libiconv library and headers])
+AS_HELP_STRING([],
+[used only if you need linking with libiconv]),
+GIT_PARSE_WITH(iconv))
## --enable-FEATURE[=ARG] and --disable-FEATURE
#
--
1.4.2
^ permalink raw reply related
* [PATCH 0/2] autoconf: iconv
From: Jakub Narebski @ 2006-09-07 11:47 UTC (permalink / raw)
To: git
Those two patches add support for remaining iconv related compilation
variables, namely NO_ICONV and ICONVDIR to configure.ac. First patch
sets NO_ICONV if no iconv implementation was found (autodetection),
second adds --without-iconv/--with-iconv=PATH option to generated
./configure script (user input).
This series is based on my earlier autoconf series "[PATCH 0/5] Some
autoconf patches", but with little editing of config.mak.in patch in
the PATCH 2/2 they could be applied on top of 'next' branch.
Shortlog:
[PATCH 1/2] autoconf: Set NO_ICONV if iconv is found neither in libc, nor in libiconv
[PATCH 2/2] autoconf: Add support for setting NO_ICONV and ICONVDIR
Diffstat:
config.mak.in | 2 +-
configure.ac | 18 ++++++++++++++++--
2 files changed, 17 insertions(+), 3 deletions(-)
--
Jakub Narebski
ShadeHawk on #git
Poland
^ permalink raw reply
* Re: Cygwin playbook?
From: Martin Langhoff @ 2006-09-07 10:37 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vwt8g2j7j.fsf@assigned-by-dhcp.cox.net>
On 9/7/06, Junio C Hamano <junkio@cox.net> wrote:
> What I meant was "readily available", not "installed by default".
I imagined. Thanks to all though! What do you think of
http://git.or.cz/gitwiki/WindowsInstall as a starting point? I've
tried to summarize this thread a bit, and added some of my own notes.
Will update further with learned lessons from helping Kris out with
his Cygwin environment.
BTW, sorry about the double post -- I initially sent the 'Cygwin
playbook' email, bogofilter bounced it, and I tried again changing the
words I thought would be trigger words. Didnt work -- complained to
postmaster@ and they thawed... both of them...
cheers,
martin
^ permalink raw reply
* Re: file rename causes history to disappear
From: Alex Riesen @ 2006-09-07 10:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, git
In-Reply-To: <7vmz9c7pzm.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano, Wed, Sep 06, 2006 21:29:49 +0200:
> The only people who will get burnt by this change are the ones
> with metacharacters in their pathnames, so it is relative safe
> change.
May be make metacharacters the default behaviour, but provide a
command-line option to disable it? It'll be seldom used, but would
provide a way to disambiguate input for scripts and make possible
(even if a bit harder) to use such filenames.
^ permalink raw reply
* Re: [PATCH 3/3] git-commit.sh: convert run_status to a C builtin
From: Jeff King @ 2006-09-07 9:10 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20060907063621.GC17083@coredump.intra.peff.net>
On Thu, Sep 07, 2006 at 02:36:21AM -0400, Jeff King wrote:
> +static void
> +status_print_updated_cb(struct diff_queue_struct *q,
> + struct diff_options *options,
> + void *data)
> [...]
> + if (!shown_header) {
> + status_print_header("Updated but not checked in",
> + "will commit");
> + s->commitable = 1;
> + }
Sorry, this should set shown_header=1. That's what I get for making a
last minute change and not testing...
-Peff
^ permalink raw reply
* Re: A look at some alternative PACK file encodings
From: linux @ 2006-09-07 9:07 UTC (permalink / raw)
To: gitzilla; +Cc: git, linux
> Support for 'thin' packs would pretty much require mixing IDs and
> (relative) offsets in the same pack file.
An alternative would be to create a small "placeholder" object that
just gives an ID, then refer to it by offset.
That would avoid the need for an id/offset bit with every offset,
and possibly save more space if the same object was referenced
multiple times.
And it just seems simpler.
^ permalink raw reply
* Re: Cygwin install howto
From: Alex Riesen @ 2006-09-07 9:07 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90609062219g340a738fq3813f1c0e07916a0@mail.gmail.com>
Martin Langhoff, Thu, Sep 07, 2006 07:19:26 +0200:
> - What cygwin packages are needed?
Perl, python, rcs (for merge), diff-utils, tcl/tk for gitk (no, X
support is not needed. Tcl/Tk is not fully cygwin, if at all).
> - Makefile tweaks?
I disabled installation of repository templates. You can't use them in
Windows anyway (except under specific, rarely reached conditions).
> - How do I install for personal use?
> - How do I install in /usr/local?
Installation works as usual, just remember using cygwin path in
prefix. Cygpath (cygpath -w or cygpath -u) can be useful.
> - Anything else I should know?
Disable x-attribute in every repository. It never works.
Case insensitivity of all Windows filesystems breaks things often.
Restrict characters in filenames - no special symbols (like ?, : or *).
It is painfully slow on large repos (many files).
It is very slow on large files.
Try to avoid interrupting (Ctrl-C) - it breaks cygwin.
Ask me again if your friend has to use ActiveState Perl - it is a long
story to make perl scripts in git work with that piece of sh.t.
In general - use the OS very careful, it is not designed to be useful.
^ permalink raw reply
* Re: [PATCH 1/7] gitweb: Make pickaxe search a feature
From: Jakub Narebski @ 2006-09-07 9:07 UTC (permalink / raw)
To: git
In-Reply-To: <7vmz9c2goh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> Junio C Hamano wrote:
>>> The patch suggests that it is turned off by default right now; I
>>> have not checked it myself, but is that the case?
>>
>> No, it is not. Currently it is turned on, _but_ undocumented.
>
> Then it would be nice to make it documented and keep the default
> perhaps?
Keep the default is easy (although I thought that we can turn off expensive
pickaxe because it was undocumented and I suppose not many people used
that). Should I send corrected patch (i.e. making pickaxe search a feature,
but default on and perhaps overridable), or should I send correcting patch
(i.e. make pickaxe search turned on by default patch)?
Documenting gitweb search operators (author:, committer:, pickaxe:) is not:
where to put the documentation?
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 2/2] Teach rev-list an option to read revs from the standard input.
From: Junio C Hamano @ 2006-09-07 9:07 UTC (permalink / raw)
To: Andy Whitcroft; +Cc: git
In-Reply-To: <44FFD436.4020407@shadowen.org>
Andy Whitcroft <apw@shadowen.org> writes:
> There was white space breakage in the patch which I noticed late in the
> game, and a problem with the printing lacking newlines. Your conversion
> to direct writes on the fd fixes the bug part.
>
> What you have on 'pu' looks good to me.
>
> /me wasn't aware of the meaning of the pu branch :)
Thanks. Will merge into "next" with a plan to have it graduate
to master by next week.
^ permalink raw reply
* Re: [PATCH 1/7] gitweb: Make pickaxe search a feature
From: Junio C Hamano @ 2006-09-07 9:02 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <edoli0$oql$1@sea.gmane.org>
Jakub Narebski <jnareb@gmail.com> writes:
> Junio C Hamano wrote:
>
>> Jakub Narebski <jnareb@gmail.com> writes:
>>
>>> As pickaxe search (selected using undocumented 'pickaxe:' operator in
>>> search query) is resource consuming, allow to turn it on/off using
>>> feature meachanism.
>>
>> I do not have a problem against making it configurable.
>>
>>> + 'pickaxe' => {
>>> + 'sub' => \&feature_pickaxe,
>>> + 'override' => 0,
>>> + 'default' => [0]},
>>> );
>>
>> The patch suggests that it is turned off by default right now; I
>> have not checked it myself, but is that the case?
>
> No, it is not. Currently it is turned on, _but_ undocumented.
Then it would be nice to make it documented and keep the default
perhaps?
^ permalink raw reply
* Re: GitWiki lost ability to parse macros
From: Jakub Narebski @ 2006-09-07 8:44 UTC (permalink / raw)
To: git
In-Reply-To: <20060907014206.GN18896@pasky.or.cz>
Petr Baudis wrote:
> Dear diary, on Wed, Sep 06, 2006 at 07:18:37PM CEST, I got a letter
> where Jakub Narebski <jnareb@gmail.com> said that...
>> Could admin of GitWiki then delete cache of all files?
>
> I did that originally, but it looks like I've missed some bit. Hopefully
> now all is in order. :-)
It looks like everything is now all right. Thnaks a lot.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: A look at some alternative PACK file encodings
From: linux @ 2006-09-07 8:41 UTC (permalink / raw)
To: gitzilla; +Cc: git, linux
A few notes:
Re: base-128 encodings, it's a pet peeve of mine that meny people, even
while trying to save space, waste it by allowing redundant encodings.
The optimal way, assming msbit=1 means "more", is
0x00 -> 0 0x01 -> 1
0x7f -> 127 0x80 0x00 -> 128
0x80 0x7f -> 255 0x81 0x00 -> 256
0xfe 0x7f -> 16383 0xff 0x00 -> 16384
0xff 0x7f -> 16511 0x80 0x00 0x00 -> 16512
The decoding code can be written several ways, but try:
c = *p++;
x = c & 127;
while (c & 128) {
c = *p++;
x = ((x + 1) << 7) + (c & 127);
}
encoding is most easily done in reverse:
char buf[9];
char *p = buf+8;
*p = x & 127;
while (x >>= 7)
*--p = 0x80 | (--x & 127);
write_out(p, buf + 9 - p);
If you want to do signed offsets, the easiest way to write the code
is to convert to an unsigned with the sign bit as lsbit:
u = (s << 1) ^ -(s < 0);
And then feed the resulting unsigned number to the functions above.
Handling the sign bit specially in the encoding is messier.
And finally, regarding qsort(), stability is not guaranteed, but glibc
actually uses a stable merge sort if it can allocate the memory. See
http://sourceware.org/cgi-bin/cvsweb.cgi/libc/stdlib/msort.c?rev=1.21&cvsroot=glibc
This leads to the slightly annoying question of whether it's worth
writing a stable sort just to make git work a little bit better
on non-glibc platforms, when it doesn't affect most current users
personally and it still works correctly with an unstable qsort.
It might be simplest to simply lift the glibc mergesort implementation,
possibly inlining the compares for efficiency. If you touch the code,
please (my eyes! it hurts us!) consider fixing the brace style.
^ permalink raw reply
* Re: [PATCH 8/8] gitweb: Remove --parents from call to git-rev-list in parse_rev_list
From: Jakub Narebski @ 2006-09-07 8:39 UTC (permalink / raw)
To: git
In-Reply-To: <edng0d$jng$1@sea.gmane.org>
By the way, I didn't do benchmarking for _later_ pages. Perhaps gain from
using only one git-rev-list invocation are outweighted for the unnecessary
output and parsing of skipped revisions.
So perhaps this part of series (patches 4, 5, 6, 8) should be skipped for
now... at least until new benchmarks. Unless someone wants to use
git-rev-list for generating list of revisions, and parse_rev_list onlky for
revisions which would be on page; alternatively change the 'p' page
parameter to 'j' jump_to (= <hash>).
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/7] gitweb: Make pickaxe search a feature
From: Jakub Narebski @ 2006-09-07 8:34 UTC (permalink / raw)
To: git
In-Reply-To: <7vlkow5x77.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Jakub Narebski <jnareb@gmail.com> writes:
>
>> As pickaxe search (selected using undocumented 'pickaxe:' operator in
>> search query) is resource consuming, allow to turn it on/off using
>> feature meachanism.
>
> I do not have a problem against making it configurable.
>
>> + 'pickaxe' => {
>> + 'sub' => \&feature_pickaxe,
>> + 'override' => 0,
>> + 'default' => [0]},
>> );
>
> The patch suggests that it is turned off by default right now; I
> have not checked it myself, but is that the case?
No, it is not. Currently it is turned on, _but_ undocumented.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/2] Add git-archive
From: Junio C Hamano @ 2006-09-07 8:16 UTC (permalink / raw)
To: Franck; +Cc: git
In-Reply-To: <44FFD00E.5040305@innova-card.com>
Franck Bui-Huu <vagabon.xyz@gmail.com> writes:
> My first intention was to enable/disable specific archive format
> through daemon service. But we could in an other way: send a
> "git-upload-archive --format=tar" request then in upload-archive
> check that git-upload-tar service is enabled. This service would
> exist even if git-upload-tar is not a valid command.
>
> But Rene thinks that part should be in git-upload-archive. I dunno
> what is the best direction. I have used git-daemon service because
> the service infrastucture already allow us to achieve that.
Hmph. daemon_service was a nice idea but the current
implementation falls short by not giving finer control such as
"this service is Ok with such and such option but not this
option". Here we ideally would want to say something like
"git-archive is fine with upload-tar but not upload-zip" or "Ok
as long as upload-tar's numeric arg is less than 6". Needs some
thought _if_ we plan to add tons of services to the daemon.
> I'm sorry to not make things faster. I'm new to git internals and
> unfortunately I'm busy to do some other (crap) things. I'll send
> a new patchset this morning and I'll sum up what's done and what
> we still need to do.
Taking things slowly is just fine. Otherwise _I_ would burn out
;-).
^ permalink raw reply
* Re: [PATCH 2/2] Teach rev-list an option to read revs from the standard input.
From: Andy Whitcroft @ 2006-09-07 8:11 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vhczk5wup.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> Andy Whitcroft <apw@shadowen.org> writes:
>
>> Ok, I've tested this with an updated version of my patch to make
>> send-pack use this (which I'll send out following this message) and it
>> seems to work pretty well.
>
> Eh, I have your earlier one placed on "pu" already. I do not
> mind replacing it with the new one but (1) have you checked what
> is in "pu"? (2) how different is this new one compared to it?
There was white space breakage in the patch which I noticed late in the
game, and a problem with the printing lacking newlines. Your conversion
to direct writes on the fd fixes the bug part.
What you have on 'pu' looks good to me.
/me wasn't aware of the meaning of the pu branch :)
-apw
^ permalink raw reply
* Re: Cygwin playbook?
From: Junio C Hamano @ 2006-09-07 8:07 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <46a038f90609070018k319b748cmae7a9b30da45b3b6@mail.gmail.com>
"Martin Langhoff" <martin.langhoff@gmail.com> writes:
> Sorry to ask this... Are you sure? Vanilla base setup with no extra
> packages getting gcc and various -dev packages? Perhaps there is a
> 'developer' profile during install that gets you a reasonable kit?
What I meant was "readily available", not "installed by default".
> About 5 minutes ago I managed to get limited access (non-root, cannot
> install packages) to a cygwin env using rdesktop. It did have gcc and
> make, but make bombed out with a missing libcurl and openssl header
> files. IIRC, diff3/merge isn't in the base install either.
It is in rcs as usual ;-).
> In debian I can look at apt-cache show git-core to get a quick
> overview of dependencies but here I'm lost :(
The packaging was pretty much similar and I could guess from
apt-cache show git-core output indeed ;-).
^ permalink raw reply
* Re: [PATCH 1/2] Add git-archive
From: Franck Bui-Huu @ 2006-09-07 7:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Franck Bui-Huu, git, Rene Scharfe
In-Reply-To: <7v1wqo400b.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano wrote:
> "Franck Bui-Huu" <vagabon.xyz@gmail.com> writes:
>> These alias would be internal to git (always defined)
>
> You _could_ work things around by building special cases into
> the system, but I would rather avoid doing that unless
> necessary.
>
yes that was not a great idea...
> Is there a reason that "git-upload-archive --format=tar" is not
> desirable at this point of the code?
>
My first intention was to enable/disable specific archive format
through daemon service. But we could in an other way: send a
"git-upload-archive --format=tar" request then in upload-archive
check that git-upload-tar service is enabled. This service would
exist even if git-upload-tar is not a valid command.
But Rene thinks that part should be in git-upload-archive. I dunno
what is the best direction. I have used git-daemon service because
the service infrastucture already allow us to achieve that.
I'm sorry to not make things faster. I'm new to git internals and
unfortunately I'm busy to do some other (crap) things. I'll send
a new patchset this morning and I'll sum up what's done and what
we still need to do.
Thanks
Franck
^ permalink raw reply
* Re: Cygwin playbook?
From: Shawn Pearce @ 2006-09-07 7:27 UTC (permalink / raw)
To: Martin Langhoff; +Cc: git
In-Reply-To: <7v7j0g40xh.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> > - What cygwin packages are needed?
I'd have to check tomorrow but I run a pretty reduced set of Cygwin
packages with Git. I'm using something around:
rcs (for merge)
python (for merge-recursive, though merge-recur is a *huge* win)
wish (for gitk)
perl
ssh
openssl
curl
expat
... maybe i missed something but probably not...
make
gcc
binutils (sorta necessary to compile!)
iirc I build git on Windows with a command as simple as:
make prefix=/usr/local/git NO_MMAP=1 install
I actually have it in a small shell script as I then turn around
and tar/bz2 that directory and make a Cygwin package out of it for
other folks at my site.
> > - How do I install for personal use?
>
> make install would install under whereever you call ~/bin in
> Cygwin environment, and that is how I have mine.
I personally don't like the default prefix so I always retarget Git
to another directory. This works just fine on Cygwin just like on
any UNIX system.
> > - Anything else I should know?
>
> You would probably have great pain if on vfat. It appears to
> work Ok on NTFS. It appears to be quite slow, judging from
> the way it runs our standard test suite.
I see odd behavior when its not a locally mounted NTFS filesystem.
For example sometimes our SAMBA server (a Solaris system) doesn't
play nicely with our XP systems and we get bad error codes back
(still haven't figured that one out). We also have what I believe
is a Windows 2003 server whose drive is mapped onto many 2000/XP
desktops; that drive can't properly rename the index file so we
can't use it for working directory storage. Works fine though for
bare repositories. Local NTFS has never been an issue.
I see large slowdowns when the number of loose objects >~100. So I
repack frequently. No, defragging hasn't helped. Only repacking
has.
I just started using merge-recur (export
GIT_USE_RECUR_FOR_RECURSIVE=1 to enable) over git-merge-recursive.
Its a huge performance gain. I'm glad Alex Riesen and Johannes
Schindelin have put so much effort into it.
gitk has layout issues on Cygwin. I always whack my ~/.gitk
file and then have to resize the window every time it launches.
People have reported this bug in the past but I don't think anyone
has taken the time to work it out. It hasn't annoyed me enough
(yet) to justify me spending time on it.
Git pretty much works as you would expect; its just somewhat slower
than on a good UNIX system. Maybe its Cygwin, maybe its Windows,
maybe its the 4+ year old system its running on. :-)
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/2] Add git-archive
From: Junio C Hamano @ 2006-09-07 7:19 UTC (permalink / raw)
To: Franck Bui-Huu; +Cc: Junio C Hamano, git
In-Reply-To: <cda58cb80609062332p356bd26bw852e31211c43d1ac@mail.gmail.com>
"Franck Bui-Huu" <vagabon.xyz@gmail.com> writes:
> sorry I wasn't clear. My point was that the structure need to be
> 'mallocated'. Which funtion allocate it doesn't matter, we will need
> to free it later. That's what I tried to avoid with the alternative I
> sent you in my previous email. Do you think we could use it ?
I do not think allocation and free matter much, but if you want
to do it that way, enumerating all the possible struct in one
place is fine by me for this application. After all we are not
defining a plug-in architecture that lets others to write their
archive backends and load them without recompiling git-archive
binary.
>> >>> +static int run_remote_archiver(struct archiver_struct *ar, int argc,
>> >>> + const char **argv)
>> >>> +{
>> >>> + char *url, buf[1024];
>> >>> + pid_t pid;
>> >>> + int fd[2];
>> >>> + int len, rv;
>> >>> +
>> >>> + sprintf(buf, "git-upload-%s", ar->name);
>> >>
>> >> Are you calling git-upload-{tar,zip,rar,...} here?
>> >
>> > yes. Actually git-upload-{tar,zip,...} commands are going to be
>> > removed, but git-daemon know them as a daemon service.
>>
>> That would break "git-archive --remove=ssh://site/repo treeish"
>> wouldn't it?
>
> Yes. But couldn't we make some alias like:
>...
> These alias would be internal to git (always defined)
You _could_ work things around by building special cases into
the system, but I would rather avoid doing that unless
necessary.
Is there a reason that "git-upload-archive --format=tar" is not
desirable at this point of the code?
^ permalink raw reply
* Re: Cygwin playbook?
From: Martin Langhoff @ 2006-09-07 7:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v7j0g40xh.fsf@assigned-by-dhcp.cox.net>
On 9/7/06, Junio C Hamano <junkio@cox.net> wrote:
> "Martin Langhoff" <martin.langhoff@gmail.com> writes:
>
> > - What cygwin packages are needed?
>
> I am not in front of Windows machine so I need to check later if
> nobody beats me to this, but essentially it is the same as on
> sane Unix systems. Cygwin folks did a good job providing
> necessary libraries readily available from their Setup.exe.
Sorry to ask this... Are you sure? Vanilla base setup with no extra
packages getting gcc and various -dev packages? Perhaps there is a
'developer' profile during install that gets you a reasonable kit?
About 5 minutes ago I managed to get limited access (non-root, cannot
install packages) to a cygwin env using rdesktop. It did have gcc and
make, but make bombed out with a missing libcurl and openssl header
files. IIRC, diff3/merge isn't in the base install either.
In debian I can look at apt-cache show git-core to get a quick
overview of dependencies but here I'm lost :(
> > - Need to fudge makefile?
>
> No; not even autoconf was needed and it installed out of the box
> for me (w2k).
That's great to know.
> > - How do I install for personal use?
>
> make install would install under whereever you call ~/bin in
> Cygwin environment, and that is how I have mine.
Kewl.
> > - How do I install in /usr/local?
>
> I do not think of a reason why "make prefix=/usr/local" would
> not work but I haven't tried it myself so don't quote me on
> this.
Is cygwin still installable in 2 modes? (Used to be personal and
system-wide or something like that.)
If that's the case, then in a system-wide install you must be root to
write to /usr/local (I'm guessing here) and there's no sudo or su -c
'make prefix=/usr/local install' so you'd have to open an admin
session. Can cygwin shell be invoked under RunAs?
> > - Anything else I should know?
>
> You would probably have great pain if on vfat. It appears to
> work Ok on NTFS. It appears to be quite slow, judging from
> the way it runs our standard test suite.
Thanks! So no vfat. In terms of speed, this should be for a
small/medium project. No linux kernel development on Windows just yet
;-)
Thanks! that's a starting point, though I'm intrigued about the
packages required. Are there ways to query what packages you have
installed (a la dpkg -l) and to install a list of packages from
commandline?
Oh, what an ignorant fop I am.
cheers,
martin
^ permalink raw reply
* Re: [PATCH 3/5] autoconf: Preliminary check for working mmap
From: Shawn Pearce @ 2006-09-07 5:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vodtt8l6v.fsf@assigned-by-dhcp.cox.net>
Junio C Hamano <junkio@cox.net> wrote:
> Well, if you are talking about git.git t/ directory, I bet that
> "the full test suite" easily fits in a single window so much of
> the new code is not exercised, unless you have a runtime option
> to make use of very tiny window (32kB would be nice) for testing
> ;-).
Heh. t/ passed which meant basic rev listing and verify-pack
appeared OK. I hardcoded the window size to be 2*getpagesize() (8192
bytes on my Mac OS X system) and started beating up Git against its
own 8 MiB pack. The window code opened a ton of windows at once as
the PACK_MAX_SZ was 128 MiB. So I hardcoded that to be 16384 bytes.
And the code worked right against the 8 MiB Git pack by opening
only 4 windows at once and closing the least-recently-used one.
I can easily parameterize both values in .git/config; there's no
real reason for them to be hardcoded. That should make it easier
to craft some new test cases that push the windowing code.
> > I am going to rebase the changes to the 64 bit index in `pu`
> > and clean up my history. Its currently one massive commit with
> > lots of changes that should be broken down into slightly more
> > digestable chunks.
>
> Breaking things up would be nice. Do you have a good testcase
> out of Mozilla repository that _needs_ 64-bit index? The code
> in "pu" uses 64-bit index only 32-bit offset cannot describe the
> pack, so I only tested with an artificial case with the kernel
> archive with .idx converted with convert-idx to 64-bit.
>
Not really. We know the Mozilla pack decompressed is around 20 GiB.
I could decompress it and repack it using no deltas; that should
exceed 4 GiB. It will take quite some time to run the decompression
and delta inflates, especially with the highly-compressed 450 MiB
pack Jon Smirl sent me. I can do that kind of testing maybe later
next week after I get my new amd64 system built.
--
Shawn.
^ permalink raw reply
* Cygwin install howto
From: Martin Langhoff @ 2006-09-07 5:19 UTC (permalink / raw)
To: git
A friend wants to work with us on a git project but is Trapped In
Windows right now. He does have a cywgin install, and I was hoping to find
a cygwin install howto. Alas, I couldn't find any (is there one and
Google doesn't know about it?).
Now, I am a bit at a loss, as I don't have access to windows. So for
you cygwin knights in the woods, a few questions...
- What cygwin packages are needed?
- Makefile tweaks?
- How do I install for personal use?
- How do I install in /usr/local?
- Anything else I should know?
I'll be more than happy to shape the replies in a nice wiki page...
(Mercurial has one already
http://www.selenic.com/mercurial/wiki/index.cgi/WindowsInstall )
cheers,
martin
^ 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