* Re: [PATCH] quote_path: convert empty path to "./"
From: Thomas Harning @ 2007-12-07 19:05 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Jeff King, Junio C Hamano, git
In-Reply-To: <Pine.LNX.4.64.0712071853500.27959@racer.site>
Johannes Schindelin wrote:
> Hi,
>
> On Fri, 7 Dec 2007, Jeff King wrote:
>
>> ...
>>
>
> Sounds reasonable.
>
> Ciao,
> Dscho
I concur. There is one case that this seems to dodge. What about the
case where you are in:
/test/test_2 where /test is not tracked...
This should probably show "./../" not just "./" , right?
^ permalink raw reply
* Re: git guidance
From: Al Boldi @ 2007-12-07 19:04 UTC (permalink / raw)
To: Jakub Narebski
Cc: Andreas Ericsson, Johannes Schindelin, Phillip Susi,
Linus Torvalds, Jing Xue, linux-kernel, git
In-Reply-To: <m3prxiu3oo.fsf@roke.D-201>
Jakub Narebski wrote:
> Al Boldi <a1426z@gawab.com> writes:
> > For example:
> >
> > echo "// last comment on this file" >> /gitfs.mounted/file
> >
> > should do an implied checkpoint, and make these checkpoints immediately
> > visible under some checkpoint branch of the gitfs mounted dir.
> >
> > Note, this way the developer gets version control without even noticing,
> > and works completely transparent to any kind of application.
>
> Why not use versioning filesystem for that, for example ext3cow
> (which looks suprisingly git-like, when you take into account that
> for ext3cow history is linear and centralized, so one can use date
> or sequential number to name commits).
>
> See GitLinks page on Git Wiki, "Other links" section:
> http://www.ext3cow.com/
Sure, Linus mentioned the cow idea before in this thread, but you would still
need a few hacks to get some basic Version Control features.
> Version control system is all about WORKFLOW B, where programmer
> controls when it is time to commit (and in private repository he/she
> can then rewrite history to arrive at "Perfect patch series"[*1*]);
> something that for example CVS failed at, requiring programmer to do
> a merge if upstream has any changes when trying to commit.
Because WORKFLOW C is transparent, it won't affect other workflows. So you
could still use your normal WORKFLOW B in addition to WORKFLOW C, gaining an
additional level of version control detail at no extra cost other than the
git-engine scratch repository overhead.
BTW, is git efficient enough to handle WORKFLOW C?
Thanks!
--
Al
^ permalink raw reply
* Re: [PATCH] quote_path: convert empty path to "./"
From: Johannes Schindelin @ 2007-12-07 18:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, git
In-Reply-To: <20071207165703.GA8889@sigill.intra.peff.net>
Hi,
On Fri, 7 Dec 2007, Jeff King wrote:
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> # subdir/
>
> So far, so good.
>
> $ cd subdir
> $ git status
> ....
> # Untracked files:
> # (use "git add <file>..." to include in what will be committed)
> #
> #
>
> Oops, that's a bit confusing.
>
> This patch prints './' to show that there is some output.
Sounds reasonable.
Ciao,
Dscho
^ permalink raw reply
* Re: Some git performance measurements..
From: Johannes Schindelin @ 2007-12-07 18:37 UTC (permalink / raw)
To: Mike Ralphson
Cc: Steffen Prohaska, Junio C Hamano, Nicolas Pitre, Linus Torvalds,
Jakub Narebski, Git Mailing List
In-Reply-To: <e2b179460712070809r4127dc0br8dc20f55b1076501@mail.gmail.com>
Hi,
On Fri, 7 Dec 2007, Mike Ralphson wrote:
> On Dec 7, 2007 1:49 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> > On Fri, 7 Dec 2007, Mike Ralphson wrote:
> >
> > > I benchmarked 3 alternative qsorts, qsortG [2] was the fastest on my
> > > system but has funky licensing, the NetBSD qsort was middle-range
> > > and the glibc one the slowest of the three (but that could be due to
> > > it being tuned for a "Sun 4/260"). All of them show over 100x speed
> > > improvements on a git-status of my main repo (104s -> ~0.7s)
> >
> > How is "You may use it in anything you like;" funky licensing? It is
> > effectively public domain.
>
> I did ask what the git licensing policy was (GPL2 or GPL2-compatible)
> but got no response. The author's wishes state:
>
> * This code may be reproduced freely provided
> [long list]
Okay, sorry, I did not bother reading further when I read "You may use it
in anything you like;".
But if the author did not respond, it might be a better idea to just
reimplement it.
Ciao,
Dscho
^ permalink raw reply
* Re: Not a valid object name refs/heads/t20050127-arm during git-cvsimport
From: Michael Haggerty @ 2007-12-07 17:48 UTC (permalink / raw)
To: git; +Cc: Baurzhan Ismagulov
In-Reply-To: <m38x4auyga.fsf@roke.D-201>
Jakub Narebski wrote:
> Baurzhan Ismagulov <ibr@radix50.net> writes:
>
>> I want to import a CVS repo myrepo into git. I copied CVSHEAD and myrepo
>> dirs from the cvs server to /home/ibr/tmp and issued the following
>> command:
>>
>> git-cvsimport -p x -k -o cvshead -d/home/ibr/tmp -C zzz myrepo/drv
>>
>> It fails [...]
>
> You can try to use other CVS importers, for example parsecvs [...]
Or cvs2svn, which can now also output to git. See these threads for
more info:
http://marc.info/?l=git&m=118592701426175&w=4
http://cvs2svn.tigris.org/servlets/BrowseList?list=users&by=thread&from=624393
Michael
^ permalink raw reply
* Re: Git and GCC
From: Linus Torvalds @ 2007-12-07 17:23 UTC (permalink / raw)
To: David Miller
Cc: jonsmirl, peff, nico, dberlin, harvey.harrison, ismail, gcc, git
In-Reply-To: <20071207.045329.204650714.davem@davemloft.net>
On Fri, 7 Dec 2007, David Miller wrote:
>
> Also I could end up being performance limited by SHA, it's not very
> well tuned on Sparc. It's been on my TODO list to code up the crypto
> unit support for Niagara-2 in the kernel, then work with Herbert Xu on
> the userland interfaces to take advantage of that in things like
> libssl. Even a better C/asm version would probably improve GIT
> performance a bit.
I doubt yu can use the hardware support. Kernel-only hw support is
inherently broken for any sane user-space usage, the setup costs are just
way way too high. To be useful, crypto engines need to support direct user
space access (ie a regular instruction, with all state being held in
normal registers that get saved/restored by the kernel).
> Is SHA a significant portion of the compute during these repacks?
> I should run oprofile...
SHA1 is almost totally insignificant on x86. It hardly shows up. But we
have a good optimized version there.
zlib tends to be a lot more noticeable (especially the uncompression: it
may be faster than compression, but it's done _so_ much more that it
totally dominates).
Linus
^ permalink raw reply
* [PATCH] quote_path: convert empty path to "./"
From: Jeff King @ 2007-12-07 16:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
Now that we are correctly removing leading prefixes from files in git
status, there is a degenerate case: the directory matching the prefix.
Because we show only the directory name for a directory that contains
only untracked files, it gets collapsed to an empty string.
Example:
$ git init
$ mkdir subdir
$ touch subdir/file
$ git status
...
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# subdir/
So far, so good.
$ cd subdir
$ git status
....
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
#
Oops, that's a bit confusing.
This patch prints './' to show that there is some output.
---
I think it looks a bit ugly because it is so small (though just '.' was
even worse). But I don't see what else would make sense.
wt-status.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/wt-status.c b/wt-status.c
index 02dbb75..31d83bf 100644
--- a/wt-status.c
+++ b/wt-status.c
@@ -121,6 +121,9 @@ static char *quote_path(const char *in, int len,
}
}
+ if (!out->len)
+ strbuf_addstr(out, "./");
+
return out->buf;
}
--
1.5.3.7.2156.g3d791-dirty
^ permalink raw reply related
* Re: [PATCH] Let git-help prefer man-pages installed with this version of git
From: David Brown @ 2007-12-07 16:22 UTC (permalink / raw)
To: Junio C Hamano, Sergei Organov, Johannes Schindelin, git
In-Reply-To: <20071207161919.GA25490@old.davidb.org>
On Fri, Dec 07, 2007 at 08:19:19AM -0800, David Brown wrote:
> Or, git gets installed out of path in its own tree, and then the 'git'
> executable itself is symlinked somewhere into the path. I know this
> happens, because this is what IT ended up doing.
This is what IT ended up doing, where I work.
I haven't run into the problem this patch fixes because the strange
out-of-path git is the only version of git available on the systems.
Dave
^ permalink raw reply
* Re: [PATCH] Let git-help prefer man-pages installed with this version of git
From: David Brown @ 2007-12-07 16:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Sergei Organov, Johannes Schindelin, git
In-Reply-To: <7vodd23i1v.fsf@gitster.siamese.dyndns.org>
On Fri, Dec 07, 2007 at 02:39:24AM -0800, Junio C Hamano wrote:
> Usually, if a user has his own version of git and regularly uses it
> by having the non-system executable directory (e.g. $HOME/bin/git)
> early in his $PATH, its corresponding documentation would also be in
> a non-system documentation directory (e.g. $HOME/man) early in his
> $MANPATH, and this change is a no-op. The only case this change
> matters is where the user installs his own git outside of his $PATH
> and $MANPATH, and explicitly runs his git executable
> (e.g. "$HOME/junk/git-1.5.4/bin/git diff").
>
>When you clarify it this way, the change does not look as useful
>anymore, does it? How typical would that use be, to run your git
>executable by always naming it by path without relying on $PATH
>environment variable?
Or, git gets installed out of path in its own tree, and then the 'git'
executable itself is symlinked somewhere into the path. I know this
happens, because this is what IT ended up doing.
It's also fairly easy to add a new executable path, and forget to add a new
manpath directory.
Dave
^ permalink raw reply
* Re: In future, to replace autotools by cmake like KDE4 did?
From: Marco Costalba @ 2007-12-07 16:10 UTC (permalink / raw)
To: J.C. Pizarro
Cc: Jakub Narebski, Andreas Ericsson, gcc, git, David Miller,
Daniel Berlin, Ismail Donmez, Marcel Holtmann
In-Reply-To: <998d0e4a0712070642u6ae75232t9cb5bfd0920b2439@mail.gmail.com>
On Dec 7, 2007 3:42 PM, J.C. Pizarro <jcpiza@gmail.com> wrote:
>
> A powerful tool can do better things that old generators-based tools
> (as autotools).
>
--- cut ---
>
> * Later: (with the powerful tool that had cached many predefined variables in
Insisting on highlighting your proposal as "powerful tool" vs what is
in git now (on which people spent long hours to tune it out) will give
you hard times on this list ;-)
Just my guess...
Marco
^ permalink raw reply
* Re: Some git performance measurements..
From: Mike Ralphson @ 2007-12-07 16:09 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Steffen Prohaska, Junio C Hamano, Nicolas Pitre, Linus Torvalds,
Jakub Narebski, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712071348100.27959@racer.site>
On Dec 7, 2007 1:49 PM, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> On Fri, 7 Dec 2007, Mike Ralphson wrote:
>
> > I benchmarked 3 alternative qsorts, qsortG [2] was the fastest on my
> > system but has funky licensing, the NetBSD qsort was middle-range and
> > the glibc one the slowest of the three (but that could be due to it
> > being tuned for a "Sun 4/260"). All of them show over 100x speed
> > improvements on a git-status of my main repo (104s -> ~0.7s)
>
> How is "You may use it in anything you like;" funky licensing? It is
> effectively public domain.
I did ask what the git licensing policy was (GPL2 or GPL2-compatible)
but got no response. The author's wishes state:
* This code may be reproduced freely provided
* - this file is retained unaltered apart from minor
* changes for portability and efficiency
* - no changes are made to this comment
* - any changes that *are* made are clearly flagged
* - the _ID string below is altered by inserting, after
* the date, the string " altered" followed at your option
* by other material. (Exceptions: you may change the name
* of the exported routine without changing the ID string.
* You may change the values of the macros TRUNC_* and
* PIVOT_THRESHOLD without changing the ID string, provided
* they remain constants with TRUNC_nonaligned, TRUNC_aligned
* and TRUNC_words/WORD_BYTES between 8 and 24, and
* PIVOT_THRESHOLD between 32 and 200.)
and they should be respected. "retained unaltered apart from" sounds a
little bit more restrictive than we might like. I haven't pinged him
about relicensing though. [Edit, I see Linus has just made those
points].
> BTW if you need a starting point (easing on your time constraints):
> http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=bba554dd0114dc436cfdd3f17edc836bbaf3d95f
Many thanks, the gmane links I bookmarked are just complaining about
wefts producing no weaves or somesuch, so that's helpful. I'll try the
mergesort and report back.
Cheers, Mike
^ permalink raw reply
* Re: Some git performance measurements..
From: Linus Torvalds @ 2007-12-07 16:07 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Mike Ralphson, Steffen Prohaska, Junio C Hamano, Nicolas Pitre,
Jakub Narebski, Git Mailing List
In-Reply-To: <Pine.LNX.4.64.0712071348100.27959@racer.site>
On Fri, 7 Dec 2007, Johannes Schindelin wrote:
>
> How is "You may use it in anything you like;" funky licensing? It is
> effectively public domain.
No, it has a long list of requirements that my not be onerous, but they
aren't compatible with GPL (ie they require that you make changes in
certain ways).
That said, if somebody wants to use that qsort, the thing to do is to ask
Gareth for permission, maybe he just says "sure". For example, for git,
you might as well remove the whole unaligned case, and quite frankly, that
#ifdef DEBUG_QSORT is some of the ugliest I've ever seen and should be
cleaned up (why didn't he just use a "dbg_printf()" macro like everybody
else? Even if it requires double parenthesis for ols-style C portability,
it's cleaner than what is there now).
Linus
^ permalink raw reply
* [RFC] Configurable name(s) for .gitmodules
From: Ping Yin @ 2007-12-07 16:00 UTC (permalink / raw)
To: Git Mailing List
I have a super project with many submodules. Each kind of role may
check out different set of submodules. There are some common modules
which are almost checked out by every role.
Here comes my question: how to implement this elegantly? If all
submodules are put in the same .gitmodules, every role has to in the
command line manually designate all submodules to be checked out.
However, it's hard to remember which submodules is required by which
role, not to mention the so huge .gitmodules. Maybe a script for each
role can help, but it's a little ugly.
If the name for '.gitmodules' is configurable, we can check in
modules.roleA and modules.roleB, etc. Then role A can designate the
corresponding modules.roleA as .gitmodules. Furtherly, if mutiple
names are allowed, for common modules, we can have modules.common and
then submodule.defaultnames="modules.common, modules.roleA" to avoid
duplicated module name entires in both modules.roleA and
modules.roleB.
I have gone deeply into git-submodule.sh and see
"GIT_CONFIG=.gitmodules" is used. However, configuable multiple names
can't be implemented in this way.
Recap:
1. configurable name for '.gitmodules'
2. better to allow mutiple names
3. the implementation issue for mutiple names
--
Ping Yin
^ permalink raw reply
* Why empty directory for submodule not checked out?
From: Ping Yin @ 2007-12-07 15:36 UTC (permalink / raw)
To: Git Mailing List
It's so annoying to see so many empty directories when only few of all
submodules are checked out.
So, why empty directories? Does we have to technically or other considerations?
--
Ping Yin
^ permalink raw reply
* Re: In future, to replace autotools by cmake like KDE4 did?
From: J.C. Pizarro @ 2007-12-07 14:42 UTC (permalink / raw)
To: Jakub Narebski
Cc: Andreas Ericsson, gcc, git, David Miller, Daniel Berlin,
Ismail Donmez, Marcel Holtmann
In-Reply-To: <200712071456.11019.jnareb@gmail.com>
On 2007/12/7, Jakub Narebski <jnareb@gmail.com> wrote:
> Andreas Ericsson wrote:
> > Jakub Narebski wrote:
> > >
> > > Although there was some talk about whether giw should use autotools,
> > > or perhaps CMake, or handmade ./configure script like MPlayer IIRC,
> > > instead of its own handmade Makefile...
> > >
> >
> > To tell the truth, I'd be much happier if everything like that got
> > put in a header file or some such. 95% of what we figure out by looking
> > at "uname" output can already be learned by looking at the various
> > pre-defined macros.
> >
> > Fortunately, there's a project devoted solely to this, so most of
> > the tedious research need not be done. It can be found at
> > http://predef.sourceforge.net/
>
> Code talks, bullsh*t walks.
>
> Pre-defined macros cannot tell us if one have specific libraries
> installed, cannot tell us if formatted IO functions support 'size
> specifiers' even though compiler claim C99 compliance or even though
> compiler doesn't claim C99 compliance but supports this, etc.
>
> But perhaps the "uname" based compile configuration could be replaced
> by testing pre-defined macros... at least for C code, and git is not
> only C code.
>
> --
> Jakub Narebski
> Poland
>
A powerful tool can do better things that old generators-based tools
(as autotools).
To imagine, there are many scripts in subdirectories or subprojects:
* Before: (many copy and paste of code as below paragraph)
A_VARIABLE_OS = `uname -a | grep .... ` # <- slow
case "$A_VARIABLE_OS" in
*linux*) ... ;;
*bsd*) ... ;;
*aix*) ... ;;
*) ...;;
esac
m4 foo.sh.m4 > bar.sh # <- very slow
./bar.sh
* Later: (with the powerful tool that had cached many predefined variables in
a ramdisk's file or in a daemon's memory)
# call once at 1st time to internal uname of powerful tool for all ocurrences of
# below predefined variable from many scripts:
case "$FOO_VARIABLE_OS" in
*linux*) ... ;;
*bsd*) ... ;;
*aix*) ... ;;
*) ...;;
esac
# i don't need to generate more scripts to inspect still more it.
J.C.Pizarro
^ permalink raw reply
* Re: In future, to replace autotools by cmake like KDE4 did?
From: Jakub Narebski @ 2007-12-07 13:56 UTC (permalink / raw)
To: Andreas Ericsson
Cc: J.C. Pizarro, gcc, git, David Miller, Daniel Berlin,
Ismail Donmez
In-Reply-To: <47594021.40200@op5.se>
Andreas Ericsson wrote:
> Jakub Narebski wrote:
> >
> > Although there was some talk about whether giw should use autotools,
> > or perhaps CMake, or handmade ./configure script like MPlayer IIRC,
> > instead of its own handmade Makefile...
> >
>
> To tell the truth, I'd be much happier if everything like that got
> put in a header file or some such. 95% of what we figure out by looking
> at "uname" output can already be learned by looking at the various
> pre-defined macros.
>
> Fortunately, there's a project devoted solely to this, so most of
> the tedious research need not be done. It can be found at
> http://predef.sourceforge.net/
Code talks, bullsh*t walks.
Pre-defined macros cannot tell us if one have specific libraries
installed, cannot tell us if formatted IO functions support 'size
specifiers' even though compiler claim C99 compliance or even though
compiler doesn't claim C99 compliance but supports this, etc.
But perhaps the "uname" based compile configuration could be replaced
by testing pre-defined macros... at least for C code, and git is not
only C code.
--
Jakub Narebski
Poland
^ permalink raw reply
* [PATCH v2] Let git-help prefer man-pages installed with this version of git
From: Sergei Organov @ 2007-12-06 18:33 UTC (permalink / raw)
To: git; +Cc: gitster
Prepend $(prefix)/share/man to the MANPATH environment variable before
invoking 'man' from help.c:show_man_page(). There may be other git
documentation in the user's MANPATH but the user is asking a specific
instance of git about its own documentation, so we'd better show the
documentation for _that_ instance of git.
Signed-off-by: Sergei Organov <osv@javad.com>
---
Apart from better commit message suggested by Junio, this version of the
patch fixes behavior when MANPATH environment variable is _not_
set. With this patch, if it happens that manual pages are not installed
for given version of git, the git-help will indeed try to find manual
page elsewhere, according to system-wide configuration.
Makefile | 5 ++++-
help.c | 24 ++++++++++++++++++++++++
2 files changed, 28 insertions(+), 1 deletions(-)
diff --git a/Makefile b/Makefile
index 999391e..3030d31 100644
--- a/Makefile
+++ b/Makefile
@@ -154,6 +154,7 @@ STRIP ?= strip
prefix = $(HOME)
bindir = $(prefix)/bin
+mandir = $(prefix)/share/man
gitexecdir = $(bindir)
sharedir = $(prefix)/share
template_dir = $(sharedir)/git-core/templates
@@ -744,6 +745,7 @@ ETC_GITCONFIG_SQ = $(subst ','\'',$(ETC_GITCONFIG))
DESTDIR_SQ = $(subst ','\'',$(DESTDIR))
bindir_SQ = $(subst ','\'',$(bindir))
+mandir_SQ = $(subst ','\'',$(mandir))
gitexecdir_SQ = $(subst ','\'',$(gitexecdir))
template_dir_SQ = $(subst ','\'',$(template_dir))
prefix_SQ = $(subst ','\'',$(prefix))
@@ -790,7 +792,8 @@ git$X: git.o $(BUILTIN_OBJS) $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ git.o \
$(BUILTIN_OBJS) $(ALL_LDFLAGS) $(LIBS)
-help.o: common-cmds.h
+help.o: help.c common-cmds.h GIT-CFLAGS
+ $(QUIET_CC)$(CC) -o $*.o -c $(ALL_CFLAGS) '-DGIT_MAN_PATH="$(mandir_SQ)"' $<
git-merge-subtree$X: git-merge-recursive$X
$(QUIET_BUILT_IN)$(RM) $@ && ln git-merge-recursive$X $@
diff --git a/help.c b/help.c
index 37a9c25..1782730 100644
--- a/help.c
+++ b/help.c
@@ -8,6 +8,8 @@
#include "exec_cmd.h"
#include "common-cmds.h"
+static const char *builtin_man_path = GIT_MAN_PATH;
+
/* most GUI terminals set COLUMNS (although some don't export it) */
static int term_columns(void)
{
@@ -239,6 +241,27 @@ void list_common_cmds_help(void)
}
}
+static void setup_man_path(void)
+{
+ struct strbuf new_path;
+ const char *old_path = getenv("MANPATH");
+
+ strbuf_init(&new_path, 0);
+
+ /* We should always put ':' after our path. If there is no
+ * old_path, the ':' at the end will let 'man' to try
+ * system-wide paths after ours to find the manual page. If
+ * there is old_path, we need ':' as delimiter. */
+ strbuf_addstr(&new_path, builtin_man_path);
+ strbuf_addch(&new_path, ':');
+ if (old_path)
+ strbuf_addstr(&new_path, old_path);
+
+ setenv("MANPATH", new_path.buf, 1);
+
+ strbuf_release(&new_path);
+}
+
static void show_man_page(const char *git_cmd)
{
const char *page;
@@ -254,6 +277,7 @@ static void show_man_page(const char *git_cmd)
page = p;
}
+ setup_man_path();
execlp("man", "man", page, NULL);
}
--
1.5.3.4
^ permalink raw reply related
* Re: Some git performance measurements..
From: Johannes Schindelin @ 2007-12-07 13:49 UTC (permalink / raw)
To: Mike Ralphson
Cc: Steffen Prohaska, Junio C Hamano, Nicolas Pitre, Linus Torvalds,
Jakub Narebski, Git Mailing List
In-Reply-To: <e2b179460712070535x2eb10710s75a581664139e0cf@mail.gmail.com>
Hi,
On Fri, 7 Dec 2007, Mike Ralphson wrote:
> I benchmarked 3 alternative qsorts, qsortG [2] was the fastest on my
> system but has funky licensing, the NetBSD qsort was middle-range and
> the glibc one the slowest of the three (but that could be due to it
> being tuned for a "Sun 4/260"). All of them show over 100x speed
> improvements on a git-status of my main repo (104s -> ~0.7s)
How is "You may use it in anything you like;" funky licensing? It is
effectively public domain.
BTW if you need a starting point (easing on your time constraints):
http://repo.or.cz/w/git/mingw/4msysgit.git?a=commitdiff;h=bba554dd0114dc436cfdd3f17edc836bbaf3d95f
Ciao,
Dscho
^ permalink raw reply
* Re: Some git performance measurements..
From: Mike Ralphson @ 2007-12-07 13:35 UTC (permalink / raw)
To: Steffen Prohaska, Junio C Hamano
Cc: Nicolas Pitre, Linus Torvalds, Jakub Narebski, Git Mailing List
In-Reply-To: <B161871F-E812-44B4-A699-44341B5783D3@zib.de>
On Nov 30, 2007 6:11 AM, Steffen Prohaska <prohaska@zib.de> wrote:
> Brian Downing measured horrid performance of qsort on Windows
> 2000 [1]. qsort seems to show worst case behaviour.
>
> This resulted in a patch replacing Window's qsort implementation
> for the mingw port [2].
>
> [1] http://thread.gmane.org/gmane.comp.version-control.msysgit/1084
> [2] http://thread.gmane.org/gmane.comp.version-control.msysgit/1086
>
>
> Avoiding qsort would even be better. I'm not sure, though,
> if the particular qsort call that triggered the current
> discussion, is the very same qsort call that Brian was hit by.
> I'm only claiming that in general avoiding qsort on Windows
> is a good idea.
This is a vote for pulling this into mainline git. AIX (at least 5.3) also
has the horrible worst-case performance of the libc qsort on sorted or
near-sorted lists (such as those provided by some filesystems, or a
directory which has been rsynced).
Some versions of Solaris have the same problem [1]
I benchmarked 3 alternative qsorts, qsortG [2] was the fastest on my system
but has funky licensing, the NetBSD qsort was middle-range and the glibc one
the slowest of the three (but that could be due to it being tuned for a "Sun
4/260"). All of them show over 100x speed improvements on a git-status of my
main repo (104s -> ~0.7s)
I like the idea of a BROKEN_QSORT make variable. I was trying to come up
with a patch which would discover the problem in a performance/regression
test and suggest the setting, but have had insufficient free time so far.
Cheers, Mike
[1] http://bugs.opensolaris.org/view_bug.do?bug_id=1258570
[2] http://www.mccaughan.org.uk/g/software.html#qsort
^ permalink raw reply
* Re: [PATCH] Teach "git add -i" to colorize whitespace errors
From: Wincent Colaiuta @ 2007-12-07 13:00 UTC (permalink / raw)
To: Wincent Colaiuta; +Cc: git, gitster
In-Reply-To: <1197030910-29638-1-git-send-email-win@wincent.com>
El 7/12/2007, a las 13:35, Wincent Colaiuta escribió:
> @@ -662,8 +648,10 @@ sub split_hunk {
> (($n_cnt != 1) ? ",$n_cnt" : '') .
> " @@\n");
> unshift @{$hunk->{TEXT}}, $head;
> + unshift @{$hunk->{DISPLAY}},
> + $use_color ? (colored $fraginfo_color, $head) : $head;
> }
> - return map { $_->{TEXT} } @split;
> + return @split;
> }
Actually, $diff_use_color would probably be more appropriate than
$use_color above.
Wincent
^ permalink raw reply
* Re: [PATCH] Let git-help prefer man-pages installed with this version of git
From: Sergei Organov @ 2007-12-07 12:49 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <47593EB2.3020309@op5.se>
Andreas Ericsson <ae@op5.se> writes:
> Sergei Organov wrote:
[...]
>> To tell the truth, I'd prefer to just use -M option of man and don't
>> rely on MANPATH at all, so that 'git help' will issue error if there is
>> no documentation installed for this particular version of git.
>>
>
> Does "man -M" work everywhere, or is your patch opening a can of worms
> to get probably-not-needed functionality?
This patch doesn't use "man -M", it tweaks MANPATH instead. Partly because
the rest of 'git' tweaks 'PATH' to get correct executable to be run, and
not run it using explicit absolute path, so tweaking MANPATH is
consistent with the rest of git.
--
Sergei.
^ permalink raw reply
* Re: Git and GCC
From: David Miller @ 2007-12-07 12:53 UTC (permalink / raw)
To: jonsmirl; +Cc: peff, nico, dberlin, harvey.harrison, ismail, gcc, git
In-Reply-To: <9e4733910712062310s30153afibc44a5550fd9ea99@mail.gmail.com>
From: "Jon Smirl" <jonsmirl@gmail.com>
Date: Fri, 7 Dec 2007 02:10:49 -0500
> On 12/7/07, Jeff King <peff@peff.net> wrote:
> > On Thu, Dec 06, 2007 at 07:31:21PM -0800, David Miller wrote:
> >
> > # and test multithreaded large depth/window repacking
> > cd test
> > git config pack.threads 4
>
> 64 threads with 64 CPUs, if they are multicore you want even more.
> you need to adjust chunk_size as mentioned in the other mail.
It's an 8 core system with 64 cpu threads.
> > time git repack -a -d -f --window=250 --depth=250
Didn't work very well, even with the one-liner patch for
chunk_size it died. I think I need to build 64-bit
binaries.
davem@huronp11:~/src/GCC/git/test$ time git repack -a -d -f --window=250 --depth=250
Counting objects: 1190671, done.
fatal: Out of memory? mmap failed: Cannot allocate memory
real 58m36.447s
user 289m8.270s
sys 4m40.680s
davem@huronp11:~/src/GCC/git/test$
While it did run the load was anywhere between 5 and 9, although it
did create 64 threads, and the size of the process was about 3.2GB
This may be in part why it wasn't able to use all 64 thread
effectively. Like I said it seemed to have 9 active at best, at any
one time, most of the time only 4 or 5 were busy doing anything.
Also I could end up being performance limited by SHA, it's not very
well tuned on Sparc. It's been on my TODO list to code up the crypto
unit support for Niagara-2 in the kernel, then work with Herbert Xu on
the userland interfaces to take advantage of that in things like
libssl. Even a better C/asm version would probably improve GIT
performance a bit.
Is SHA a significant portion of the compute during these repacks?
I should run oprofile...
^ permalink raw reply
* Re: In future, to replace autotools by cmake like KDE4 did?
From: Andreas Ericsson @ 2007-12-07 12:44 UTC (permalink / raw)
To: Jakub Narebski
Cc: J.C. Pizarro, gcc, git, David Miller, Daniel Berlin,
Ismail Donmez
In-Reply-To: <m3lk86u2fq.fsf@roke.D-201>
Jakub Narebski wrote:
>
> Although there was some talk about whether giw should use autotools,
> or perhaps CMake, or handmade ./configure script like MPlayer IIRC,
> instead of its own handmade Makefile...
>
To tell the truth, I'd be much happier if everything like that got
put in a header file or some such. 95% of what we figure out by looking
at "uname" output can already be learned by looking at the various
pre-defined macros.
Fortunately, there's a project devoted solely to this, so most of
the tedious research need not be done. It can be found at
http://predef.sourceforge.net/
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH] Let git-help prefer man-pages installed with this version of git
From: Andreas Ericsson @ 2007-12-07 12:38 UTC (permalink / raw)
To: Sergei Organov; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <871w9y7mei.fsf@osv.gnss.ru>
Sergei Organov wrote:
> Junio C Hamano <gitster@pobox.com> writes:
>
>> Having written that, it is very tempting to further clarify the above:
>>
>> Usually, if a user has his own version of git and regularly uses it
>> by having the non-system executable directory (e.g. $HOME/bin/git)
>> early in his $PATH, its corresponding documentation would also be in
>> a non-system documentation directory (e.g. $HOME/man) early in his
>> $MANPATH, and this change is a no-op. The only case this change
>> matters is where the user installs his own git outside of his $PATH
>> and $MANPATH, and explicitly runs his git executable
>> (e.g. "$HOME/junk/git-1.5.4/bin/git diff").
>
> First, I don't think you need to clarify like this. It is just
> implementation detail of git-help that it uses 'man', and thus
> implicitly relies on MANPATH. The essential thing has been already
> stated above: git-help should show correct documentation.
>
> Second, the change is still useful even if user did put custom path to
> 'git' into its PATH, but didn't even thought of customizing
> MANPATH. Besides, a user could be entirely unaware of 'man' the utility.
>
The number of users in the entire world that are completely unaware of
the 'man' utility but still manages to build git and install it in a
non-default path can probably be counted on one hand of a 65 year old
saw-mill worker.
I'm not sure if we're doing them a greater service by DWIMing this or
by telling them about the 'man' utility.
>
>> How typical would that use be, to run your git executable by always
>> naming it by path without relying on $PATH environment variable?
>
> To tell the truth, I'd prefer to just use -M option of man and don't
> rely on MANPATH at all, so that 'git help' will issue error if there is
> no documentation installed for this particular version of git.
>
Does "man -M" work everywhere, or is your patch opening a can of worms
to get probably-not-needed functionality?
Otoh, you submitted a patch, so there are probably a few people out
there that care about this. I'm not one of them, so I'll shut up now
that my lunch is over ;-)
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] Teach "git add -i" to colorize whitespace errors
From: Wincent Colaiuta @ 2007-12-07 12:35 UTC (permalink / raw)
To: git; +Cc: gitster, Wincent Colaiuta
Rather than replicating the colorization logic of "git diff-files" we
rely on "git diff-files" itself. This guarantees consistent colorization
in and outside "git add -i".
Seeing as speed is not a concern here (the bottleneck is how fast the
user can read, not how fast "git diff-files" runs) we do this by
actually running it twice, once without color and once with.
In this way as the whitespace colorization provided by "git diff-files"
evolves (per-path attributes, new classes of whitespace error), "git
add -i" will automatically benefit from it and stay in synch.
Also, by working with two sets of diff output (an uncolorized one for
internal processing and a colorized one for display only) we minimize
the risk of regressions because the changes required to implement this
are minimally invasive.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
---
This applies on top of these patches that Junio sent out yesterday:
git config --get-colorbool
Color support for "git-add -i"
I've tested it here and it works for me but it would be nice if
someone else could play with it and see if this is good.
git-add--interactive.perl | 67 +++++++++++++++++++-------------------------
1 files changed, 29 insertions(+), 38 deletions(-)
diff --git a/git-add--interactive.perl b/git-add--interactive.perl
index 1019a72..e492fac 100755
--- a/git-add--interactive.perl
+++ b/git-add--interactive.perl
@@ -525,42 +525,21 @@ sub add_untracked_cmd {
sub parse_diff {
my ($path) = @_;
my @diff = run_cmd_pipe(qw(git diff-files -p --), $path);
- my (@hunk) = { TEXT => [] };
+ my @colored = run_cmd_pipe(qw(git diff-files -p --color --), $path)
+ if $diff_use_color;
+ my (@hunk) = { TEXT => [], DISPLAY => [] };
- for (@diff) {
- if (/^@@ /) {
- push @hunk, { TEXT => [] };
+ for (my $i = 0; $i < @diff; $i++) {
+ if ($diff[$i] =~ /^@@ /) {
+ push @hunk, { TEXT => [], DISPLAY => [] };
}
- push @{$hunk[-1]{TEXT}}, $_;
+ push @{$hunk[-1]{TEXT}}, $diff[$i];
+ push @{$hunk[-1]{DISPLAY}},
+ $diff_use_color ? $colored[$i] : $diff[$i];
}
return @hunk;
}
-sub colored_diff_hunk {
- my ($text) = @_;
- # return the text, so that it can be passed to print()
- my @ret;
- for (@$text) {
- if (!$diff_use_color) {
- push @ret, $_;
- next;
- }
-
- if (/^\+/) {
- push @ret, colored($new_color, $_);
- } elsif (/^\-/) {
- push @ret, colored($old_color, $_);
- } elsif (/^\@/) {
- push @ret, colored($fraginfo_color, $_);
- } elsif (/^ /) {
- push @ret, colored($normal_color, $_);
- } else {
- push @ret, colored($metainfo_color, $_);
- }
- }
- return @ret;
-}
-
sub hunk_splittable {
my ($text) = @_;
@@ -578,7 +557,9 @@ sub parse_hunk_header {
}
sub split_hunk {
- my ($text) = @_;
+ my $text = shift;
+ my $display = shift;
+ $display = $text unless $display;
my @split = ();
# If there are context lines in the middle of a hunk,
@@ -594,16 +575,19 @@ sub split_hunk {
my $i = $hunk_start - 1;
my $this = +{
TEXT => [],
+ DISPLAY => [],
OLD => $o_ofs,
NEW => $n_ofs,
OCNT => 0,
NCNT => 0,
ADDDEL => 0,
POSTCTX => 0,
+ USE => undef,
};
while (++$i < @$text) {
my $line = $text->[$i];
+ my $display = $display->[$i];
if ($line =~ /^ /) {
if ($this->{ADDDEL} &&
!defined $next_hunk_start) {
@@ -615,6 +599,7 @@ sub split_hunk {
$next_hunk_start = $i;
}
push @{$this->{TEXT}}, $line;
+ push @{$this->{DISPLAY}}, $display;
$this->{OCNT}++;
$this->{NCNT}++;
if (defined $next_hunk_start) {
@@ -637,6 +622,7 @@ sub split_hunk {
redo OUTER;
}
push @{$this->{TEXT}}, $line;
+ push @{$this->{DISPLAY}}, $display;
$this->{ADDDEL}++;
if ($line =~ /^-/) {
$this->{OCNT}++;
@@ -662,8 +648,10 @@ sub split_hunk {
(($n_cnt != 1) ? ",$n_cnt" : '') .
" @@\n");
unshift @{$hunk->{TEXT}}, $head;
+ unshift @{$hunk->{DISPLAY}},
+ $use_color ? (colored $fraginfo_color, $head) : $head;
}
- return map { $_->{TEXT} } @split;
+ return @split;
}
sub find_last_o_ctx {
@@ -794,7 +782,9 @@ sub patch_update_file {
my ($ix, $num);
my $path = shift;
my ($head, @hunk) = parse_diff($path);
- print colored_diff_hunk($head->{TEXT});
+ for (@{$head->{DISPLAY}}) {
+ print;
+ }
$num = scalar @hunk;
$ix = 0;
@@ -836,7 +826,9 @@ sub patch_update_file {
if (hunk_splittable($hunk[$ix]{TEXT})) {
$other .= '/s';
}
- print colored_diff_hunk($hunk[$ix]{TEXT});
+ for (@{$hunk[$ix]{DISPLAY}}) {
+ print;
+ }
print colored $prompt_color, "Stage this hunk [y/n/a/d$other/?]? ";
my $line = <STDIN>;
if ($line) {
@@ -889,14 +881,13 @@ sub patch_update_file {
next;
}
elsif ($other =~ /s/ && $line =~ /^s/) {
- my @split = split_hunk($hunk[$ix]{TEXT});
+ my @split = split_hunk($hunk[$ix]{TEXT},
+ $hunk[$ix]{DISPLAY});
if (1 < @split) {
print colored $header_color, "Split into ",
scalar(@split), " hunks.\n";
}
- splice(@hunk, $ix, 1,
- map { +{ TEXT => $_, USE => undef } }
- @split);
+ splice (@hunk, $ix, 1, @split);
$num = scalar @hunk;
next;
}
--
1.5.3.7.1079.gb270a-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