* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: Johannes Schindelin @ 2007-10-16 16:44 UTC (permalink / raw)
To: René Scharfe; +Cc: Pierre Habouzit, git, Shawn O. Pearce
In-Reply-To: <4714E90C.80305@lsrfire.ath.cx>
Hi,
On Tue, 16 Oct 2007, Ren? Scharfe wrote:
> Pierre Habouzit schrieb:
> > This bit is to allow to aggregate options with arguments together when
> > the argument is numeric.
> >
> > +#if 0
> > + /* can be used to understand -A1B1 like -A1 -B1 */
> > + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> > + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> > + return 0;
> > + }
> > +#endif
>
> I don't like it, it complicates number options with unit suffixes (e.g.
> --windows-memory of git-pack-objects).
Why? It only means that you cannot say -W10mxabc instead of -W10m xabc.
Remember: this is a special case for OPT_INTEGER. Nothing to do with
OPT_SIZE, which you'd probably implement as a callback.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: Nicolas Pitre @ 2007-10-16 16:44 UTC (permalink / raw)
To: René Scharfe; +Cc: Pierre Habouzit, git, Shawn O. Pearce
In-Reply-To: <4714E90C.80305@lsrfire.ath.cx>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 603 bytes --]
On Tue, 16 Oct 2007, René Scharfe wrote:
> Pierre Habouzit schrieb:
> > This bit is to allow to aggregate options with arguments together when
> > the argument is numeric.
> >
> > +#if 0
> > + /* can be used to understand -A1B1 like -A1 -B1 */
> > + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> > + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> > + return 0;
> > + }
> > +#endif
>
> I don't like it, it complicates number options with unit suffixes (e.g.
> --windows-memory of git-pack-objects).
This is my opinion too.
Nicolas
^ permalink raw reply
* Re: [PATCH] git-svn: use "no warnings 'once'" to disable false-positives
From: Eygene Ryabinkin @ 2007-10-16 16:50 UTC (permalink / raw)
To: Eric Wong; +Cc: git
In-Reply-To: <20071016074318.GA32348@soma>
Eric, good day.
Tue, Oct 16, 2007 at 12:43:18AM -0700, Eric Wong wrote:
> Thanks, minor nit regarding fixed in the patch below.
>
> "{ no warnings 'once';"
>
> on the same line as the "{"
Yes, I did this intentionally to signify that this block is used
just for the pragma. But I felt that it is against the style, so
you're right.
Thank you!
--
Eygene
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: Pierre Habouzit @ 2007-10-16 16:50 UTC (permalink / raw)
To: René Scharfe; +Cc: git, Shawn O. Pearce
In-Reply-To: <4714E90C.80305@lsrfire.ath.cx>
[-- Attachment #1: Type: text/plain, Size: 1662 bytes --]
On Tue, Oct 16, 2007 at 04:38:36PM +0000, René Scharfe wrote:
> Pierre Habouzit schrieb:
> > This bit is to allow to aggregate options with arguments together when
> > the argument is numeric.
> >
> > +#if 0
> > + /* can be used to understand -A1B1 like -A1 -B1 */
> > + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> > + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> > + return 0;
> > + }
> > +#endif
>
> I don't like it, it complicates number options with unit suffixes (e.g.
> --windows-memory of git-pack-objects).
Oh yeah, you're right, well you example is not an issue, but indeed
you pointed out a real probable issue:
With that chunk, if an option that takes now an integer, becomes an
option with a suffix, we would then break backward compatibility. I'm
not sure I'm clear, but if you had a -S option (for size) that for now
gets sizes in kilooctet, git foo -S1000. Then if we decide that it's
worth understanting M/G/.. suffixes for this option, we would make the
type of the option be a CALLBACK using git_parse_ulong. This would mean
that with such a change:
before:
git foo -S1000a would mean git foo -S1000 -a
After:
git foo -S1000a would be rejected because 'a' isn't a valid size
suffix.
This of course become worse if we take git foo -S1000k where the
breakage would be silent.
This is a very strong argument _against_ this chunk IMO.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: Pierre Habouzit @ 2007-10-16 16:53 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: René Scharfe, git, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0710161742040.25221@racer.site>
[-- Attachment #1: Type: text/plain, Size: 1424 bytes --]
On Tue, Oct 16, 2007 at 04:44:44PM +0000, Johannes Schindelin wrote:
> Hi,
>
> On Tue, 16 Oct 2007, Ren? Scharfe wrote:
>
> > Pierre Habouzit schrieb:
> > > This bit is to allow to aggregate options with arguments together when
> > > the argument is numeric.
> > >
> > > +#if 0
> > > + /* can be used to understand -A1B1 like -A1 -B1 */
> > > + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> > > + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> > > + return 0;
> > > + }
> > > +#endif
> >
> > I don't like it, it complicates number options with unit suffixes (e.g.
> > --windows-memory of git-pack-objects).
>
> Why? It only means that you cannot say -W10mxabc instead of -W10m xabc.
>
> Remember: this is a special case for OPT_INTEGER. Nothing to do with
> OPT_SIZE, which you'd probably implement as a callback.
Yeah but the point is that you can't migrate an option currently being
an integer to an OPT_SIZE because of that (see my other mail). Meaning
that once an argument is of type OPT_INTEGER you can't change it's type
in the future _AT ALL_ without breaking backward compatibility badly.
I'd say it's a rather sucky design.
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: [PATCH] gitweb: Speed up get_projects_list for large source trees
From: Andreas Ericsson @ 2007-10-16 16:55 UTC (permalink / raw)
To: Luke Lu; +Cc: git
In-Reply-To: <3A2DCEC6-953A-41B0-AB9E-7374EEB625E8@vicaya.com>
Luke Lu wrote:
> Hi, I've been using git for a month now and loving it.
Hello Luke, and welcome to the community :)
> This is my first ever patch for git using git.
It shows. The patch is whitespace damaged, and the commit message leaves
a little something to desire. I suggest you read through
Documentation/SubmittingPatches and then re-send your patch. Try sending
to yourself and looking at the result with a monospace font. It's what I
always do to make sure patches look okay before sending them to the list.
Not trying to be rude or anything. Oldtime list-members sometimes get to
hear the exact same thing.
Also, Junio, the maintainer, is currently away, so don't worry if your
patches are left in limbo for some time. Someone will pick it up and
carry it forward for Junio to pull, or he'll hack up some script to
get all patces from his mailbox and review them one by one. He's a very
thorough fellow, usually.
> I spent sometime to find out why the
> project listing is taking 200s, everytime! I guess that gitweb is mostly
> used to serve bare repositories, which would never encounter such
> problems. It takes .2s, after the patch on my laptop. That's 1000x
> improvement for me (on Mac OS X 1.4.10.)
>
Sweet job :)
I'll have to test this, as we've got a few repos at work with a checked out
working tree connected to the repos. I haven't run into your issues though,
but perhaps that's because we run it under Linux.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 09/25] Port builtin-add.c to use the new option parser.
From: Pierre Habouzit @ 2007-10-16 16:55 UTC (permalink / raw)
To: Michael Witten; +Cc: git
In-Reply-To: <2209D123-A245-43C4-8DD9-A83386852556@mit.edu>
[-- Attachment #1: Type: text/plain, Size: 1146 bytes --]
On mar, oct 16, 2007 at 08:55:41 +0000, Michael Witten wrote:
>
> On 16 Oct 2007, at 4:39:42 AM, Pierre Habouzit wrote:
>
> >+ OPT_BOOLEAN('u', NULL, &take_worktree_changes, "update only files that
> >git already knows about"),
>
> "update only files in the current directory that git already knows about"
As a general rule, as I'm not a native speaker, I'd be glad if someone
went through the diffs and made it better english. I'm not sure what the
more efficient way to merge those corrections is, as I'm not able to see
if it's any better or not. So the someone mergint it (Shawn ?) may have
to go through every OPTION_* and check the helps strings, and --amend
fixes on top of the patches if needed. It looks like the best way to me.
Alternatively, a native speaker could propose a 26th patch that fixes
all of the bad strings on top of this series. But again, I won't do
that, not because of lazyness, just because I can't decide :)
--
·O· Pierre Habouzit
··O madcoder@debian.org
OOO http://www.madism.org
[-- Attachment #2: Type: application/pgp-signature, Size: 189 bytes --]
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Andreas Ericsson @ 2007-10-16 16:59 UTC (permalink / raw)
To: Eli Zaretskii
Cc: barkalow, raa.lkml, Johannes.Schindelin, tsuna, git, make-w32
In-Reply-To: <E1Ihfrl-0007w1-3I@fencepost.gnu.org>
Eli Zaretskii wrote:
>> From: Andreas Ericsson <ae@op5.se>
>
>> I *think* (correct me if I'm wrong) that git is still faster
>> than a whole bunch of other scm's on windows, but to one who's used to
>> its performance on Linux that waiting several seconds to scan 10k files
>> just feels wrong.
>
> Unless that 10K is a typo and you really meant 100K, I don't think 10K
> files should take several seconds to scan on Windows. I just tried
> "find -print" on a directory with 32K files in 4K subdirectories, and
> it took 8 sec elapsed with a hot cache. So 10K files should take at
> most 2 seconds, even without optimizing file traversal code. Doing
> the same with native Windows system calls ("dir /s") brings that down
> to 4 seconds for 32K files.
>
It was a typo. Thanks for correcting me.
> On the other hand, what packages have 100K files? If there's only one
> -- the Linux kernel -- then I think this kind of performance is for
> all practical purposes unimportant on Windows
But it's most definitely not. The *huge* projects that have looked at
git have sometimes turned it down simply because they're either cross-
platform (Mozilla) or they have translators that use windows exclusively
(KDE and Mozilla, just to mention two).
Both Mozilla and KDE repos are *much* larger than the Linux repo.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Switching from CVS to GIT
From: Daniel Barkalow @ 2007-10-16 17:04 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Eli Zaretskii, raa.lkml, ae, tsuna, git
In-Reply-To: <Pine.LNX.4.64.0710161335260.25221@racer.site>
On Tue, 16 Oct 2007, Johannes Schindelin wrote:
> Hi,
>
> [culled make-w32, as per explicit request]
>
> On Tue, 16 Oct 2007, Eli Zaretskii wrote:
>
> > > Date: Tue, 16 Oct 2007 01:56:46 -0400 (EDT)
> > > From: Daniel Barkalow <barkalow@iabervon.org>
> > > cc: raa.lkml@gmail.com, Johannes.Schindelin@gmx.de, ae@op5.se,
> > > tsuna@lrde.epita.fr, git@vger.kernel.org, make-w32@gnu.org
> > >
> > > Ah, that's helpful. We don't actually care too much about the
> > > particular info in stat; we just want to know quickly if the file has
> > > changed, so we can hash only the ones that have been touched and get
> > > the actual content changes.
> >
> > As I wrote in my other message, using native APIs improves performance
> > by at least a factor of two.
>
> Somehow this does not appeal to my "portability is good" side. You know,
> if we had to do such trickeries for every platform we support, we'd soon
> be as big as Subversion *cough*.
I think that it would be a worthwhile project, from the point of view of
making the code easier to follow and making the internal APIs clearer, to
organize git's source to abstract the object database to read_sha1_file(),
has_sha1_file(), hash_sha1_file(), and write_sha1_file() as the arbiters
of what is in the local database (with other functions public as support
for over-the-wire protocols, which may, by not-really-coincidence, by used
for local storage as well); then Windows could have an entirely different
storage mechanism that doesn't rely on filesystem metadata speed.
It would also be worthwhile to untangle the index's stat cache aspects and
its tree-object-related aspects, so that there can be a platform- and
repository-specific concept of how to handle the working area, and then
Windows could do different stuff for the default case of setting up a
directory on the local filesystem.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: René Scharfe @ 2007-10-16 17:04 UTC (permalink / raw)
To: Johannes Schindelin, Pierre Habouzit; +Cc: git, Shawn O. Pearce
In-Reply-To: <Pine.LNX.4.64.0710161742040.25221@racer.site>
Johannes Schindelin schrieb:
> Hi,
>
> On Tue, 16 Oct 2007, Ren? Scharfe wrote:
>
>> Pierre Habouzit schrieb:
>>> This bit is to allow to aggregate options with arguments together when
>>> the argument is numeric.
>>>
>>> +#if 0
>>> + /* can be used to understand -A1B1 like -A1 -B1 */
>>> + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
>>> + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
>>> + return 0;
>>> + }
>>> +#endif
>> I don't like it, it complicates number options with unit suffixes (e.g.
>> --windows-memory of git-pack-objects).
>
> Why? It only means that you cannot say -W10mxabc instead of -W10m xabc.
>
> Remember: this is a special case for OPT_INTEGER. Nothing to do with
> OPT_SIZE, which you'd probably implement as a callback.
You mean I need to take a look at the actual patch to get a bit more
context? ;-) Now that I did, I retract my comment.
Pierre, FYI: I didn't see your patches coming through the NNTP gateway
of gmane.org, which is my way of reading this list. Its web interface
doesn't show them, either, so it's probably not caused by my news reader.
René
^ permalink raw reply
* Re: How to Import a bitkeeper repo into git
From: Andreas Ericsson @ 2007-10-16 17:05 UTC (permalink / raw)
To: Marco Costalba; +Cc: pete, Linus Torvalds, VMiklos, free cycle, git
In-Reply-To: <e5bfff550710160211g5dbfa7fai95386b173edc45c3@mail.gmail.com>
Marco Costalba wrote:
> On 10/16/07, Pete/Piet Delaney <pete@bluelane.com> wrote:
>
>> Would it be worthwhile
>> to install Qt4 from src and try to use qgit-2.0?
>>
>
> Yes it is. There are a lot of new featrures, is almost as stable as
> the previous and if you are interested in file history (annotations)
> in qgit-2.0 this feature has been greatly speeded up.
>
The only thing I really, really, really don't like about qgit4 is the
fact that it fudges up the commit-message. I've been trying for two
days to get rid of the HTML output, but I just can't get it done
without the signed-off-by email being enclosed in <> tags.
Marco, is there any chance you could make the old commit-message view
an option? Especially, the subject line should really, really be at the
bottom, with the rest of the message-text (although I liked the other
view without the colored box a lot more). The little arrows in the
commit window are also fairly annoying, as one quite quickly understands
that up-/down-arrows work much better for that sort of stuff anyway.
I'm at my wits end wrt c++ and qt, and can't for the life of me think of
how to make it an option :(
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* [PATCH] git-commit.sh: Remove option -n from tail
From: Jari Aalto @ 2007-10-16 16:57 UTC (permalink / raw)
To: git; +Cc: Jari Aalto
In-Reply-To: <1192553837-18302-2-git-send-email-jari.aalto@cante.net>
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
git-commit.sh | 6 ++++--
1 files changed, 4 insertions(+), 2 deletions(-)
diff --git a/git-commit.sh b/git-commit.sh
index fcb8443..637cf48 100755
--- a/git-commit.sh
+++ b/git-commit.sh
@@ -3,6 +3,8 @@
# Copyright (c) 2005 Linus Torvalds
# Copyright (c) 2006 Junio C Hamano
+TAIL="tail"
+
USAGE='[-a | --interactive] [-s] [-v] [--no-verify] [-m <message> | -F <logfile> | (-C|-c) <commit> | --amend] [-u] [-e] [--author <author>] [--template <file>] [[-i | -o] <path>...]'
SUBDIRECTORY_OK=Yes
. git-sh-setup
@@ -442,10 +444,10 @@ t)
s/^/Signed-off-by: /
')
blank_before_signoff=
- tail -n 1 "$GIT_DIR"/COMMIT_EDITMSG |
+ $TAIL 1 "$GIT_DIR"/COMMIT_EDITMSG |
grep 'Signed-off-by:' >/dev/null || blank_before_signoff='
'
- tail -n 1 "$GIT_DIR"/COMMIT_EDITMSG |
+ $TAIL 1 "$GIT_DIR"/COMMIT_EDITMSG |
grep "$sign"$ >/dev/null ||
printf '%s%s\n' "$blank_before_signoff" "$sign" \
>>"$GIT_DIR"/COMMIT_EDITMSG
--
1.5.3.2.81.g17ed
^ permalink raw reply related
* [PATCH] git-rebase--interactive.sh: Remove option -n from tail
From: Jari Aalto @ 2007-10-16 16:57 UTC (permalink / raw)
To: git; +Cc: Jari Aalto
In-Reply-To: <1192553837-18302-3-git-send-email-jari.aalto@cante.net>
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
git-rebase--interactive.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 050140d..58e164c 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -10,6 +10,8 @@
# The original idea comes from Eric W. Biederman, in
# http://article.gmane.org/gmane.comp.version-control.git/22407
+TAIL="tail"
+
USAGE='(--continue | --abort | --skip | [--preserve-merges] [--verbose]
[--onto <branch>] <upstream> [<branch>])'
@@ -204,7 +206,7 @@ nth_string () {
make_squash_message () {
if test -f "$SQUASH_MSG"; then
COUNT=$(($(sed -n "s/^# This is [^0-9]*\([1-9][0-9]*\).*/\1/p" \
- < "$SQUASH_MSG" | tail -n 1)+1))
+ < "$SQUASH_MSG" | $TAIL 1)+1))
echo "# This is a combination of $COUNT commits."
sed -n "2,\$p" < "$SQUASH_MSG"
else
--
1.5.3.2.81.g17ed
^ permalink raw reply related
* [PATCH] git-am.sh: Remove option -n from tail
From: Jari Aalto @ 2007-10-16 16:57 UTC (permalink / raw)
To: git; +Cc: Jari Aalto
In-Reply-To: <1192553837-18302-1-git-send-email-jari.aalto@cante.net>
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
git-am.sh | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index b02ae6a..09a991c 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -2,6 +2,8 @@
#
# Copyright (c) 2005, 2006 Junio C Hamano
+TAIL="tail"
+
USAGE='[--signoff] [--dotest=<dir>] [--keep] [--utf8 | --no-utf8]
[--3way] [--interactive] [--binary]
[--whitespace=<option>] [-C<n>] [-p<n>]
@@ -321,7 +323,7 @@ do
LAST_SIGNED_OFF_BY=`
sed -ne '/^Signed-off-by: /p' \
"$dotest/msg-clean" |
- tail -n 1
+ $TAIL 1
`
ADD_SIGNOFF=`
test "$LAST_SIGNED_OFF_BY" = "$SIGNOFF" || {
--
1.5.3.2.81.g17ed
^ permalink raw reply related
* [PATCH] tail -n not supported in all OSs
From: Jari Aalto @ 2007-10-16 16:57 UTC (permalink / raw)
To: git
SunOS/Solaris tail(1) does not support option '-n'. The
following patches change occurrances of:
tail -n <N>
to
tail <N>
---------------------------------------------------------------------
REFERENCES:
User Commands TAIL(1)
NAME
tail - output the last part of files
SYNOPSIS
tail [OPTION]... [FILE]...
- - -
$ uname -a
SunOS host 5.9 Generic_118558-35 sun4u sparc SUNW,Serverblade1
$ echo | tail -n 1
usage: tail [+/-[n][lbc][f]] [file]
tail [+/-[n][l][r|f]] [file]
^ permalink raw reply
* Re: [PATCH] tail -n not supported in all OSs
From: David Brown @ 2007-10-16 17:12 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <1192553837-18302-1-git-send-email-jari.aalto@cante.net>
On Tue, Oct 16, 2007 at 07:57:14PM +0300, Jari Aalto wrote:
>
>SunOS/Solaris tail(1) does not support option '-n'. The
>following patches change occurrances of:
>
> tail -n <N>
>
>to
>
> tail <N>
On Linux, I get
tail: cannot open `1' for reading: No such file or directory
Did you want
tail -<N>
David
^ permalink raw reply
* Re: [PATCH] tail -n not supported in all OSs
From: YOSHIFUJI Hideaki / 吉藤英明 @ 2007-10-16 17:16 UTC (permalink / raw)
To: jari.aalto; +Cc: git, yoshfuji
In-Reply-To: <1192553837-18302-1-git-send-email-jari.aalto@cante.net>
In article <1192553837-18302-1-git-send-email-jari.aalto@cante.net> (at Tue, 16 Oct 2007 19:57:14 +0300), Jari Aalto <jari.aalto@cante.net> says:
>
> SunOS/Solaris tail(1) does not support option '-n'. The
> following patches change occurrances of:
>
> tail -n <N>
>
> to
>
> tail <N>
You should say "tail -<N>".
--yoshfuji
^ permalink raw reply
* git-merge performance
From: Andrew Morton @ 2007-10-16 17:17 UTC (permalink / raw)
To: git
My git-pulling script (git-1.4.2) seems to have got quite a bit slower
since the post-2.6.23 patchflood. I just did a bit of poking and it's
git-merge which is taking most of the time.
Using git-watchdog as an example:
box:/usr/src/git26> cat .git/branches/git-watchdog
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/wim/linux-2.6-watchdog-mm.git
box:/usr/src/git26> git reset --hard origin
box:/usr/src/git26> git fetch git-watchdog
box:/usr/src/git26> time git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null
Automatic merge failed; fix conflicts and then commit the result.
git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null 47.03s user 26.53s system 97% cpu 1:15.67 total
Try git-md-accel:
box:/usr/src/git26> cat .git/branches/git-md-accel
git://lost.foo-projects.org/~dwillia2/git/iop#md-for-linus
box:/usr/src/git26> time git reset --hard origin
git reset --hard origin 0.51s user 0.11s system 100% cpu 0.615 total
box:/usr/src/git26> time git fetch git-md-accel
git fetch git-md-accel 0.12s user 0.05s system 11% cpu 1.379 total
box:/usr/src/git26> time git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null
Automatic merge failed; fix conflicts and then commit the result.
git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null 42.52s user 24.18s system 96% cpu 1:08.93 total
And git-unionfs:
box:/usr/src/git26> cat .git/branches/git-unionfs
git+ssh://master.kernel.org/pub/scm/linux/kernel/git/ezk/unionfs.git
box:/usr/src/git26> time git reset --hard origin
git reset --hard origin 0.52s user 0.09s system 100% cpu 0.611 total
box:/usr/src/git26> time git fetch git-unionfs
git fetch git-unionfs 0.16s user 0.03s system 8% cpu 2.285 total
box:/usr/src/git26> time git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null
Automatic merge went well; stopped before committing as requested
git merge --no-commit 'test merge' HEAD FETCH_HEAD > /dev/null 42.81s user 24.86s system 96% cpu 1:09.98 total
Everything is in pagecache, and I just did git-repack -a -d;git
prune;git-fsck-objects --full.
Pulling 70-80 trees at a minute and a half each gets a bit dull ;)
^ permalink raw reply
* Re: [PATCH] git-commit.sh: Remove option -n from tail
From: Johannes Schindelin @ 2007-10-16 17:18 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <1192553837-18302-3-git-send-email-jari.aalto@cante.net>
Hi,
On Tue, 16 Oct 2007, Jari Aalto wrote:
> Signed-off-by: Jari Aalto <jari.aalto@cante.net>
Rationale?
And also, can't this wait for the builtin-commit, which will solve this
problem?
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] tail -n not supported in all OSs
From: Johannes Schindelin @ 2007-10-16 17:19 UTC (permalink / raw)
To: Jari Aalto; +Cc: git
In-Reply-To: <1192553837-18302-1-git-send-email-jari.aalto@cante.net>
Hi,
On Tue, 16 Oct 2007, Jari Aalto wrote:
>
> SunOS/Solaris tail(1) does not support option '-n'.
This belongs into the commit message.
Ciao,
Dscho
^ permalink raw reply
* Re: On Tabs and Spaces
From: Andreas Ericsson @ 2007-10-16 17:20 UTC (permalink / raw)
To: Michael Witten; +Cc: Shawn O. Pearce, git
In-Reply-To: <11F85069-1013-4685-9D56-C53F0F8231BF@MIT.EDU>
Michael Witten wrote:
> On 16 Oct 2007, at 3:04:21 AM, Shawn O. Pearce wrote:
>
>> The C code is all tabs, with the tabs set at 8 spaces, but the
>> actual tab width isn't too important here as we never use the tab
>> for alignment beyond the left indent.
>
> Consider this from diff-lib.c:
>
>> /* A file entry went away or appeared */
>> static void diff_index_show_file(struct rev_info *revs,
>> const char *prefix,
>> struct cache_entry *ce,
>> unsigned char *sha1, unsigned int mode)
>> {
>> diff_addremove(&revs->diffopt, prefix[0], ntohl(mode),
>> sha1, ce->name, NULL);
>> }
>
> There are mixed tabs and spaces for alignment.
>
Function declarations don't count ;-)
> I suppose I'll be fine if I just set tab widths to 8.
> But 8 spaces! Good Lord. ;-)
>
> I really hate tabs.
>
Well, using hard tabs is the only way we can let everyone have
different levels of indentation while still having things look
sort of sane.
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: [PATCH 07/25] parse-options: make some arguments optional, add callbacks.
From: Nicolas Pitre @ 2007-10-16 17:21 UTC (permalink / raw)
To: Pierre Habouzit
Cc: Johannes Schindelin, René Scharfe, git, Shawn O. Pearce
In-Reply-To: <20071016165319.GC13946@artemis.corp>
On Tue, 16 Oct 2007, Pierre Habouzit wrote:
> On Tue, Oct 16, 2007 at 04:44:44PM +0000, Johannes Schindelin wrote:
> > Hi,
> >
> > On Tue, 16 Oct 2007, Ren? Scharfe wrote:
> >
> > > Pierre Habouzit schrieb:
> > > > This bit is to allow to aggregate options with arguments together when
> > > > the argument is numeric.
> > > >
> > > > +#if 0
> > > > + /* can be used to understand -A1B1 like -A1 -B1 */
> > > > + if (flag & OPT_SHORT && opt->opt && isdigit(*opt->opt)) {
> > > > + *(int *)opt->value = strtol(opt->opt, (char **)&opt->opt, 10);
> > > > + return 0;
> > > > + }
> > > > +#endif
> > >
> > > I don't like it, it complicates number options with unit suffixes (e.g.
> > > --windows-memory of git-pack-objects).
> >
> > Why? It only means that you cannot say -W10mxabc instead of -W10m xabc.
> >
> > Remember: this is a special case for OPT_INTEGER. Nothing to do with
> > OPT_SIZE, which you'd probably implement as a callback.
>
> Yeah but the point is that you can't migrate an option currently being
> an integer to an OPT_SIZE because of that (see my other mail). Meaning
> that once an argument is of type OPT_INTEGER you can't change it's type
> in the future _AT ALL_ without breaking backward compatibility badly.
> I'd say it's a rather sucky design.
And what's the point of supporting so criptic arguments?
It doesn't have to go that far.
Nicolas
^ permalink raw reply
* Re: On Tabs and Spaces
From: Andreas Ericsson @ 2007-10-16 17:23 UTC (permalink / raw)
To: Jeffrey C. Ollie; +Cc: Adam Piatyszek, Lars Hjemli, Michael Witten, git
In-Reply-To: <1192548367.3821.4.camel@lt21223.campus.dmacc.edu>
Jeffrey C. Ollie wrote:
> On Tue, 2007-10-16 at 12:16 +0200, Adam Piatyszek wrote:
>> And if one change the tab size, it will result in a messy alignment in
>> line 5.
>
> Which is why one should never should change the tab size from anything
> but 8.
>
I have mine set to 4. With an 11.2" screen and 1024x768 resolution, it's
not as if I've got much choice if I want to be able to see anything on
the screen. Some whitespace-damaged places look ugly, but it's usually
not too bad.
>> I guess there is no ideal solution for this in Emacs.
>
> Instead of using "(setq indent-tabs-mode t)" use "(setq indent-tabs-mode
> nil)". This will force emacs to always use spaces to indent.
>
... but don't do this when hacking on Linux or git. Thanks
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: git-merge performance
From: Andreas Ericsson @ 2007-10-16 17:34 UTC (permalink / raw)
To: Andrew Morton; +Cc: git
In-Reply-To: <20071016101748.ff132685.akpm@linux-foundation.org>
Andrew Morton wrote:
> My git-pulling script (git-1.4.2) seems to have got quite a bit slower
> since the post-2.6.23 patchflood. I just did a bit of poking and it's
> git-merge which is taking most of the time.
>
That's odd. If it had been the remote fetching it would have been
understandable. Is this also happening with more recent gits? I know there
are some significant performance-improvements in 1.5.3.4 (or below).
--
Andreas Ericsson andreas.ericsson@op5.se
OP5 AB www.op5.se
Tel: +46 8-230225 Fax: +46 8-230231
^ permalink raw reply
* Re: Some git mv questions
From: Linus Torvalds @ 2007-10-16 17:34 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Jan Wielemaker, git list
In-Reply-To: <8c5c35580710160905v69787856m7ed11b037c1adef1@mail.gmail.com>
On Tue, 16 Oct 2007, Lars Hjemli wrote:
> On 10/16/07, Jan Wielemaker <wielemak@science.uva.nl> wrote:
> > * On a somewhat bigger test I moved a large directory using
> > "git mv dir newdir" (where newdir is an existing directory).
> > Now "git status" gives a lot of new and deleted files!?
>
> You could try to adjust diff.renameLimit in .git/config
Yes. The default rename limit I did has turned out to be a disaster. It's
quite common to have more than a 100x100 matrix of deleted files.
For people with any kind of beefy hardware, I'd just suggest doing a
git config --global diff.renamelimit 0
which disables the rename limiting entirely.
There's a related (embarrassing) problem, namely that I think that the
current released versions (1.5.3.3 and 1.5.3.4) don't honor the
renamelimit configuration for merging, so if you do merges across renames
with changes to the renamed files, you need to use either an older git
that didn't have the rename limit at all (nor any of the speed-ups) or you
need to use current git from the 'master' branch.
Linus
^ 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