* Re: b5227d8 changes meaning of "ls-files -x 'pattern'"
From: Michael J Gruber @ 2009-12-14 16:15 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <2e24e5b90912140751y5d769f15pa6782914bdb04dbd@mail.gmail.com>
Sitaram Chamarty venit, vidit, dixit 14.12.2009 16:51:
> Hello,
>
> Before b5227d8, the following two commands would produce different
> outputs (say on git.git):
>
> git ls-files
> git ls-files -x '*.c'
>
> From b5227d8 onward, they produce the same output. The second command
> no longer excludes *.c files.
>
> I was unable to understand the commit message completely but it sounds
> like this was intentionally changed to do this.
Yes. Generally, git commands never ignore tracked files, and this patch
reintroduces this for git ls-files
> I've never been real clear on ls-files, and was wondering if someone
> would be able to clarify the various ways of using it, including why
> this change was made and is there a way (using some other combination of
> flags perhaps) to get a list of files without *.c (to continue this
> example).
You can still use file glob patterns as the file argument, such as
git ls-files '*.[^c]'
Michael
^ permalink raw reply
* Re: git gc logs to standard error
From: Richard Rossel @ 2009-12-14 16:23 UTC (permalink / raw)
To: git
In-Reply-To: <8c9a060912140804t409030b4g168014bd80a0b88c@mail.gmail.com>
>
> On Mon, Dec 14, 2009 at 07:55, Johan Herland<johan@herland.net> wrote:
>
>> On Monday 14 December 2009, Richard Rossel wrote:
>>
>>> Hi,
>>> I have a question related to the output of git gc logs. Let me
>>> explain,
>>>
>>> [...]
>>>
>>> I realized that the message are sent to standard error,
>>> so the question is why is the reason to do that?
>>>
>>> The quick solution to my problem of annoying mails is send the output
>>> error to /dev/null
>>> but what happens when an error really occur, there will be no message
>>> to alert me.
>>>
>> Try the --quiet parameter to "git gc" (and other git commands).
>>
>>
>> ...Johan
>>
>> --
>> Johan Herland,<johan@herland.net>
>> www.herland.net
>>
> I think the real problem that Richard is experiencing is that git
> fetch isn't respecting the --quiet option. The output being similar
> to git gc, and also being on STDERR seems to be a red-herring.
>
> Richard,
>
> What version of git are you using?
>
> Also, what is the output from 'git fetch --q; echo $?' if you just run
> that in your repo? If the last line you see is '0', then that should
> be the only output you see.
>
> -Jacob
>
$ git --version
git version 1.5.4.3
And when there is no change in the repo
$ git fetch --q; echo $?
0
no messages and no error , but when there is a change to syncronize
$ git fetch --q; echo $?
remote: Counting objects: 7, done.
remote: Compressing objects: 100% (5/5), done.
remote: Total 5 (delta remote: 2), reused 0 (delta 0)
Unpacking objects: 100% (5/5), done.
From git@boss:sandbox
3e4df7f..b92d27c master -> origin/master
0
here come the messages but the return value is still 0
I will try to update git to v1.6.5.6 and see what happend
--
Richard Rossel
Airsage Inc.
Valparaiso - Chile
^ permalink raw reply
* Re: git gc logs to standard error
From: Jacob Helwig @ 2009-12-14 16:28 UTC (permalink / raw)
To: Richard Rossel; +Cc: git
In-Reply-To: <4B26669A.8020806@inf.utfsm.cl>
On Mon, Dec 14, 2009 at 08:23, Richard Rossel <rrossel@inf.utfsm.cl> wrote:
>
> $ git --version
> git version 1.5.4.3
>
> And when there is no change in the repo
>
> $ git fetch --q; echo $?
> 0
>
> no messages and no error , but when there is a change to syncronize
>
> $ git fetch --q; echo $?
> remote: Counting objects: 7, done.
> remote: Compressing objects: 100% (5/5), done.
> remote: Total 5 (delta remote: 2), reused 0 (delta 0)
> Unpacking objects: 100% (5/5), done.
> From git@boss:sandbox
> 3e4df7f..b92d27c master -> origin/master
> 0
>
Don't use a double dash, if you're using the short option.
git fetch -q
OR
git fetch --quiet
git fetch --q <--- This is not what you think it is.
-Jacob
^ permalink raw reply
* Re: git gc logs to standard error
From: Richard Rossel @ 2009-12-14 16:37 UTC (permalink / raw)
To: git
In-Reply-To: <8c9a060912140828p3b05972lf9abc82c7b0f9bc1@mail.gmail.com>
>
> On Mon, Dec 14, 2009 at 08:23, Richard Rossel<rrossel@inf.utfsm.cl> wrote:
>
>> $ git --version
>> git version 1.5.4.3
>>
>> And when there is no change in the repo
>>
>> $ git fetch --q; echo $?
>> 0
>>
>> no messages and no error , but when there is a change to syncronize
>>
>> $ git fetch --q; echo $?
>> remote: Counting objects: 7, done.
>> remote: Compressing objects: 100% (5/5), done.
>> remote: Total 5 (delta remote: 2), reused 0 (delta 0)
>> Unpacking objects: 100% (5/5), done.
>> From git@boss:sandbox
>> 3e4df7f..b92d27c master -> origin/master
>> 0
>>
>>
> Don't use a double dash, if you're using the short option.
>
> git fetch -q
> OR
> git fetch --quiet
>
> git fetch --q<--- This is not what you think it is.
>
> -Jacob
>
>
doh, sorry, my mistake
$ git fetch -q; echo $?
remote: Counting objects: 5, done.
remote: Compressing objects: 100% (2/2), done.
remote: Total 3 (delta 1), reused 0 (delta 0)
Unpacking objects: 100% (3/3), done.
From git@boss:sandbox
b92d27c..17b8b5d master -> origin/master
0
These is the output when there is a change to be syncronized
BTW, in crontab the commands are using -q option, the mistake was made
just here :)
--
Richard Rossel
Softare Engineer at Airsage Inc.
Valparaiso - Chile
^ permalink raw reply
* Re: git gc logs to standard error
From: Jacob Helwig @ 2009-12-14 16:46 UTC (permalink / raw)
To: Richard Rossel; +Cc: git
In-Reply-To: <4B2669CD.9020505@inf.utfsm.cl>
On Mon, Dec 14, 2009 at 08:37, Richard Rossel <rrossel@inf.utfsm.cl> wrote:
>>
>> On Mon, Dec 14, 2009 at 08:23, Richard Rossel<rrossel@inf.utfsm.cl>
>> wrote:
>>
>>>
>>> $ git --version
>>> git version 1.5.4.3
>>>
>>> And when there is no change in the repo
>>>
>>> $ git fetch --q; echo $?
>>> 0
>>>
>>> no messages and no error , but when there is a change to syncronize
>>>
>>> $ git fetch --q; echo $?
>>> remote: Counting objects: 7, done.
>>> remote: Compressing objects: 100% (5/5), done.
>>> remote: Total 5 (delta remote: 2), reused 0 (delta 0)
>>> Unpacking objects: 100% (5/5), done.
>>> From git@boss:sandbox
>>> 3e4df7f..b92d27c master -> origin/master
>>> 0
>>>
>>>
>>
>> Don't use a double dash, if you're using the short option.
>>
>> git fetch -q
>> OR
>> git fetch --quiet
>>
>> git fetch --q<--- This is not what you think it is.
>>
>> -Jacob
>>
>>
>
> doh, sorry, my mistake
>
> $ git fetch -q; echo $?
> remote: Counting objects: 5, done.
> remote: Compressing objects: 100% (2/2), done.
> remote: Total 3 (delta 1), reused 0 (delta 0)
> Unpacking objects: 100% (3/3), done.
> From git@boss:sandbox
> b92d27c..17b8b5d master -> origin/master
> 0
>
> These is the output when there is a change to be syncronized
>
> BTW, in crontab the commands are using -q option, the mistake was made just
> here :)
>
It looks like you want to upgrade to at least 1.6.0.3 (I know that
with 1.6.5.5 I get no output with 'git fetch -q', whether or not there
are pending updates). There's a fix (fe8aa148) for the issue[1] it
looks like you're having.
[1] http://marc.info/?l=git&m=121529226023180&w=2
^ permalink raw reply
* Re: b5227d8 changes meaning of "ls-files -x 'pattern'"
From: Jeff King @ 2009-12-14 18:25 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: Git Mailing List
In-Reply-To: <2e24e5b90912140751y5d769f15pa6782914bdb04dbd@mail.gmail.com>
On Mon, Dec 14, 2009 at 09:21:06PM +0530, Sitaram Chamarty wrote:
> Before b5227d8, the following two commands would produce different
> outputs (say on git.git):
>
> git ls-files
> git ls-files -x '*.c'
>
> From b5227d8 onward, they produce the same output. The second command
> no longer excludes *.c files.
>
> I was unable to understand the commit message completely but it sounds
> like this was intentionally changed to do this.
Yes, it was intentional. Excludes are about untracked files, not about
restricting parts of the index. The point of the change was to bring
"ls-files" in harmony with other parts of git. For example, prior to
b5227d8, you could do:
$ git init
$ echo content >file && git add . && git commit -m base
$ echo changes >file
$ echo file >.gitignore
$ git ls-files --exclude-standard -m
<no output>
$ git diff-files --name-only
file
But both "ls-files --exclude-standard" and "diff-files" should
produce the same list (and they do post-b5227d8).
However, for your use case, I can see the utility of an option to limit
the output of ls-files for a particular invocation. It's just that "-x"
is tied into the excludes mechanism, which doesn't do that.
I would not be opposed to a patch to add an option that means "exclude
these index entries from the output list." And for the sake of backwards
compatibility, it may even be reasonable to call that option "-x". The
change in b5227d8 was really about ls-files mis-using .gitignore and
.git/info/exclude; people providing "-x" for a particular invocation
probably want to limit everything.
-Peff
^ permalink raw reply
* am fails to apply patches for files with CRLF lineendings
From: Björn Steinbrink @ 2009-12-14 18:33 UTC (permalink / raw)
To: Junio C Hamano; +Cc: jk, git
Hi,
Jason King (cc'd) reported that a patch for a file with CRLF lineendings
fails to apply, even if generated and applied in the same repo.
doener@atjola:x $ git init
doener@atjola:x (master) $ for x in $(seq 10); do echo -e "$x\r" >> foo; done
doener@atjola:x (master) $ vim foo
doener@atjola:x (master) $ git add foo; git commit -m init
[master (root-commit) b59b963] init
1 files changed, 10 insertions(+), 0 deletions(-)
create mode 100644 foo
doener@atjola:x (master) $ sed -ie s/5/changed/ foo
doener@atjola:x (master) $ git commit -am changed
[master fe4ee44] changed
1 files changed, 1 insertions(+), 1 deletions(-)
doener@atjola:x (master) $ git format-patch HEAD^
0001-changed.patch
doener@atjola:x (master) $ git checkout HEAD^
Note: moving to 'HEAD^' which isn't a local branch
doener@atjola:x ((b59b963...)) $ git am 0001-changed.patch
Applying: changed
error: patch failed: foo:2
error: foo: patch does not apply
Patch failed at 0001 changed
When you have resolved this problem run "git am --resolved".
If you would prefer to skip this patch, instead run "git am --skip".
To restore the original branch and stop patching run "git am --abort".
Using "--whitespace=fix" makes the patch apply, but converts the changed
line and the context area from CRLF to LF.
Commit c2ca1d7 "Allow mailsplit ... to handle mails with CRLF line-endings"
seems to be responsible. Using "git am --rebasing" to trigger the
--keep-cr flag to mailsplit makes things work:
doener@atjola:x ((b59b963...)) $ git am --rebasing 0001-changed.patch
Applying: changed
And reverting that commit also gives the expected whitespace warning
(which is somehow squelched by the --rebasing flag it seems).
doener@atjola:x ((b59b963...)) $ git am 0001-changed.patch
Applying: changed
/home/doener/x/.git/rebase-apply/patch:14: trailing whitespace.
changed
warning: 1 line adds whitespace errors.
Björn
^ permalink raw reply
* Re: git --version wrong
From: B Smith-Mannschott @ 2009-12-14 18:41 UTC (permalink / raw)
To: Brad Hutchins; +Cc: git
In-Reply-To: <4b308ad10912140852k15b5b815ge77c54525634d454@mail.gmail.com>
> On Sun, Dec 13, 2009 at 10:17 PM, B Smith-Mannschott <bsmith.occs@gmail.com>
> wrote:
>>
>> On Sun, Dec 13, 2009 at 23:51, oshybrid <oshybrid@gmail.com> wrote:
>> >
>> > After i Instal 1.6.5.5 my "git --version" still shows 1.6.0.5
>> >
>>
>> How, exactly, did you install it?
>> What's the output when you type "which git" at the command line?
>>
>> // Ben
On Mon, Dec 14, 2009 at 17:52, Brad Hutchins <oshybrid@gmail.com> wrote:
> /opt/local/bin/git
Judging by the path, it looks like the git that is actually running on
your machine was installed through macports. Is that accurate? The
current version of git offered by macports, however, is 1.6.5.3
<http://trac.macports.org/browser/trunk/dports/devel/git-core/Portfile>
which is neither the version you are expecting, nor the version you
actually have installed.
Here's my guess, based on insufficient information:
(1) You have macports package manager installed.
(2) It's been a while since you've updated it, so...
(3) The git installed by macports is outdated (1.6.0.5)
(4) You tried to install git 1.6.5.5 via some other mechanism other
than macports. Maybe one of the stand-alone git installers floating
around. Maybe you built it from source. I can't tell, because you
haven't told me.
(5) Where ever that install placed your new git, it wasn't in /opt/local/bin
(6) Your PATH environment variable either does not contain the
directory where the newer git is installed or it contains it, but said
directory is after /opt/local/bin in PATH.
(type "echo $PATH" in the shell to see what's in PATH).
I'd look in /usr/local/bin and /usr/local/git/bin to see if you can't
find the newer git there.
Failing that, please come back with an answer to the question "How,
exactly, did you install it?" from my first reply and I'll see if I
can help you further.
// Ben
^ permalink raw reply
* Re: [PATCH] help.autocorrect: do not run a command if the command given is junk
From: Junio C Hamano @ 2009-12-14 20:08 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Johannes Schindelin, Git Mailing List, Alex Riesen
In-Reply-To: <4B263797.5070808@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> From: Johannes Sixt <j6t@kdbg.org>
>
> If a given command is not found, then help.c tries to guess which one the
> user could have meant. If help.autocorrect is 0 or unset, then a list of
> suggestions is given as long as the dissimilarity between the given command
> and the candidates is not excessively high. But if help.autocorrect was
> non-zero (i.e., a delay after which the command is run automatically), the
> latter restriction on dissimilarity was not obeyed.
>
> In my case, this happened:
>
> $ git ..daab02
> WARNING: You called a Git command named '..daab02', which does not exist.
> Continuing under the assumption that you meant 'read-tree'
> in 4.0 seconds automatically...
>
> The similarity limit that this patch introduces is already used a few lines
> later where the list of suggested commands is printed.
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> help.c | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
Thanks. Will apply to 'maint'.
But I am curious about and would prefer to see the story behind '6'
someday.
This is not entirely a new problem that you are introducing, as the same
comparison-with-six appears in a later part of the code, but this patch
duplicates the magic number whose two instances need to match, so in that
sense it makes it more necessary than before to document the choice of
magic number somewhere in a comment in the code.
Did 8af84da (git wrapper: DWIM mistyped commands, 2008-08-31) made up just
a random number out of thin-air? What bad things would happen if we used
'600' (or '1') instead of '6'? What kind of correlation does the cut-off
value we use here should have with some intrinsic numbers your git
installation has (e.g. perhaps "must be at least 80% of average length of
available commands" or something like that)?
In the meantime, I think squashing the following in would help us keep the
two magic numbers in sync.
diff --git a/help.c b/help.c
index db888cf..fbf80d9 100644
--- a/help.c
+++ b/help.c
@@ -297,6 +297,9 @@ static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
old->names = NULL;
}
+/* how did we decide this is a good cutoff??? */
+#define SIMILAR_ENOUGH(x) ((x) < 6)
+
const char *help_unknown_cmd(const char *cmd)
{
int i, n, best_similarity = 0;
@@ -331,7 +334,7 @@ const char *help_unknown_cmd(const char *cmd)
n = 1;
while (n < main_cmds.cnt && best_similarity == main_cmds.names[n]->len)
++n;
- if (autocorrect && n == 1 && best_similarity < 6) {
+ if (autocorrect && n == 1 && SIMILAR_ENOUGH(best_similarity)) {
const char *assumed = main_cmds.names[0]->name;
main_cmds.names[0] = NULL;
clean_cmdnames(&main_cmds);
@@ -349,7 +352,7 @@ const char *help_unknown_cmd(const char *cmd)
fprintf(stderr, "git: '%s' is not a git-command. See 'git --help'.\n", cmd);
- if (best_similarity < 6) {
+ if (SIMILAR_ENOUGH(best_similarity)) {
fprintf(stderr, "\nDid you mean %s?\n",
n < 2 ? "this": "one of these");
^ permalink raw reply related
* Re: am fails to apply patches for files with CRLF lineendings
From: Junio C Hamano @ 2009-12-14 20:27 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: jk, git, Brandon Casey
In-Reply-To: <20091214183337.GA25462@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> Commit c2ca1d7 "Allow mailsplit ... to handle mails with CRLF line-endings"
> seems to be responsible.
Yes, that commit is not only responsible but was deliberate. For a better
backstory, see:
http://thread.gmane.org/gmane.comp.version-control.git/124718/focus=124721
You'd notice that I was one of the people who didn't want to have this
change, so you don't need to convince _me_ that this was not a change to
keep everybody happy, but you'd need to try a better job than I did back
then to convince people who thought that "am" should directly work on
"Thunderbird saved mails" that what they want was a bad idea X-<.
^ permalink raw reply
* git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-14 20:28 UTC (permalink / raw)
To: git
So I have no idea what is interesting or relevant what I can collect,
what you want to know or anything like that, so this is a bit of a dump
of info and I'm sorry to whoever tries to pick anything useful out of
it. Somone who understands git might glean some interesting information
(or tell me what a fool I am) I'm going to lay out my whole working
process here and maybe people will even point out how to improve what I
do....
git-1.5.5.6-4.el5 (git in extras for RHEL5)
I have about 5 local trees that way I can work on different things
without having to rebuild quite a much especially as I go back and
change history so often with stgit. Each local tree has a .git/config
file that has about 5 different kernel trees set up as remotes. They
look something like this.
[core]
repositoryformatversion = 0
filemode = true
bare = false
logallrefupdates = true
[remote "origin"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/*:refs/remotes/origin/*
[remote "linus"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux-2.6.git
fetch = +refs/heads/master:refs/remotes/linus/master
[remote "linux-next"]
url = git://git.kernel.org/pub/scm/linux/kernel/git/sfr/linux-next.git
fetch = +refs/heads/*:refs/remotes/linux-next/*
{snipped}
Each of these trees also has a .git/objects/info/alternatives file which
looks like so (am I using alternatives right?)
/export/kernel/kernel-1/.git/objects
/storage/kernel/kernel-1/.git/objects
On this particular machine (a very beefy dual quad core
Nehalem) /storage is a bind mount of /export. On other machines I will
mount these using NFS in which case /export doesn't exist and /storage
is the mount point. Typically (but not always) the only thing I do over
the NFS mount point is 'make install'.
In this particular tree I use stgit and on a daily basis will update my
remotes and rebase my stgit patch series on top of linux-next. I don't
know the details of the git commands going on under the covers, I just
do git remote update; stg rebase remotes/linux-next/master; I don't
know if that's relevant, but it might leave me lots of crap in the tree?
Today I decided to make a clean branch to ask Linus to pull. I exported
a patch series (about 80 patches) to an mbox file from one of my other 5
trees and I did the following
git remote update
git checkout -b working remotes/linus/master
git-am -3 -k mbox.file
all 80 or so patches in the mbox file applied and then I got
Auto packing your repository for optimum performance. You may also
run "git gc" manually. See "git help gc" for more information.
I waited for a while, but it still hasn't come back.
#ps -ef | grep git
paris 24134 22057 0 14:09 pts/12 00:00:00 /bin/sh /usr/bin/git-am -3 -k /tmp/fanotify.mbox
paris 25638 24134 0 14:09 pts/12 00:00:00 git gc --auto
paris 25640 25638 99 14:09 pts/12 00:58:07 git-reflog expire --all
#top
25640 paris 25 0 920m 211m 149m R 99.8 2.1 69:09.55 git-reflog
#ls -ld /proc/pid/cwd
lrwxrwxrwx 1 paris paris 0 Dec 14 15:02 /proc/25640/cwd -> /storage/kernel/kernel-2
#strace -p -T -ttt
1260821793.751746 stat(".git/objects/b2/ad3c1470e751c53bf7a4d3d53514e0debab1fc", {st_mode=S_IFREG|0444, st_size=291, ...}) = 0 <0.000043>
1260821793.751917 open(".git/objects/b2/ad3c1470e751c53bf7a4d3d53514e0debab1fc", O_RDONLY|O_NOATIME) = 40 <0.000041>
1260821793.752032 mmap(NULL, 291, PROT_READ, MAP_PRIVATE, 40, 0) = 0x2b4d6a90e000 <0.000041>
1260821793.752148 close(40) = 0 <0.000026>
1260821793.752286 munmap(0x2b4d6a90e000, 291) = 0 <0.000035>
1260821793.752538 stat(".git/objects/85/7d99d3a4f9780402fbff3d59b6b3de8d614cc7", {st_mode=S_IFREG|0444, st_size=330, ...}) = 0 <0.000138>
1260821793.752743 open(".git/objects/85/7d99d3a4f9780402fbff3d59b6b3de8d614cc7", O_RDONLY|O_NOATIME) = 40 <0.000027>
1260821793.752942 mmap(NULL, 330, PROT_READ, MAP_PRIVATE, 40, 0) = 0x2b4d6a90e000 <0.000024>
1260821793.753018 close(40) = 0 <0.000038>
1260821793.753289 munmap(0x2b4d6a90e000, 330) = 0 <0.000040>
1260821796.796243 stat(".git/objects/85/7d99d3a4f9780402fbff3d59b6b3de8d614cc7", {st_mode=S_IFREG|0444, st_size=330, ...}) = 0 <0.000076>
1260821796.796440 open(".git/objects/85/7d99d3a4f9780402fbff3d59b6b3de8d614cc7", O_RDONLY|O_NOATIME) = 40 <0.000036>
1260821796.796553 mmap(NULL, 330, PROT_READ, MAP_PRIVATE, 40, 0) = 0x2b4d6a90e000 <0.000031>
1260821796.796624 close(40) = 0 <0.000017>
1260821796.796828 munmap(0x2b4d6a90e000, 330) = 0 <0.000042>
1260821796.797124 stat(".git/objects/40/c92d2149426ea7fd8c70bf7c7727af15eed75d", {st_mode=S_IFREG|0444, st_size=293, ...}) = 0 <0.008584>
1260821796.805844 open(".git/objects/40/c92d2149426ea7fd8c70bf7c7727af15eed75d", O_RDONLY|O_NOATIME) = 40 <0.000114>
1260821796.806062 mmap(NULL, 293, PROT_READ, MAP_PRIVATE, 40, 0) = 0x2b4d6a90e000 <0.000041>
1260821796.806144 close(40) = 0 <0.000018>
1260821796.806341 munmap(0x2b4d6a90e000, 293) = 0 <0.000023>
1260821799.863480 stat(".git/objects/40/c92d2149426ea7fd8c70bf7c7727af15eed75d", {st_mode=S_IFREG|0444, st_size=293, ...}) = 0 <0.000118>
1260821799.863737 open(".git/objects/40/c92d2149426ea7fd8c70bf7c7727af15eed75d", O_RDONLY|O_NOATIME) = 40 <0.000042>
1260821799.863855 mmap(NULL, 293, PROT_READ, MAP_PRIVATE, 40, 0) = 0x2b4d6a90e000 <0.000075>
1260821799.863973 close(40) = 0 <0.000021>
1260821799.864101 munmap(0x2b4d6a90e000, 293) = 0 <0.000033>
1260821799.864306 stat(".git/objects/43/77e6fe8ac62e7b3a1b65a83665f172550440b6", {st_mode=S_IFREG|0444, st_size=272, ...}) = 0 <0.000177>
1260821799.864551 open(".git/objects/43/77e6fe8ac62e7b3a1b65a83665f172550440b6", O_RDONLY|O_NOATIME) = 40 <0.000025>
1260821799.864635 mmap(NULL, 272, PROT_READ, MAP_PRIVATE, 40, 0) = 0x2b4d6a90e000 <0.000041>
1260821799.864729 close(40) = 0 <0.000058>
1260821799.865064 munmap(0x2b4d6a90e000, 272) = 0 <0.000031>
First things I notice in the strace is that git is opening the same
objects multiple times, and there are seconds between the munmap of the
last object and the second stat of that same object....
What can I collect, do, whatever?
-Eric
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Junio C Hamano @ 2009-12-14 20:34 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Björn Steinbrink, jk, git, Brandon Casey
In-Reply-To: <7vvdg9i9mn.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>
>> Commit c2ca1d7 "Allow mailsplit ... to handle mails with CRLF line-endings"
>> seems to be responsible.
>
> Yes, that commit is not only responsible but was deliberate. For a better
> backstory, see:
>
> http://thread.gmane.org/gmane.comp.version-control.git/124718/focus=124721
>
> You'd notice that I was one of the people who didn't want to have this
> change, so you don't need to convince _me_ that this was not a change to
> keep everybody happy, but you'd need to try a better job than I did back
> then to convince people who thought that "am" should directly work on
> "Thunderbird saved mails" that what they want was a bad idea X-<.
Having said that, I think you can tell "format-patch" to emit it as mime
attachment to work this around. It _might_ even make sense to do so
automatically when the payload contains CRLF but that is a separate issue.
^ permalink raw reply
* Help: approach for rebasing to older commits after merging more recent commits
From: Jay Soffian @ 2009-12-14 20:38 UTC (permalink / raw)
To: git
In-Reply-To: <76718490912091204u3a4596fdi504005624d5a5bce@mail.gmail.com>
[He asks again...]
I have an interesting problem I'm not sure how best to tackle.
A small development team is basing its product on an upstream git repo that is
itself an svn clone. Currently the process looks like this:
r1--r2--r3--r4--r5 upstream trunk (git svn clone)
\ \ \
A---B---C---D---E local trunk (git clone of upstream)
\ /
F---G developerN trunk (git clones of local)
So local trunk has both daily merges from the local developers, as well as
less periodic (typically weekly) merges from upstream trunk. The reason being
that it is necessary to remain on top of the upstream bleeding edge.
This works out okay, but there is a minor problem and a major problem.
The minor problem is that the local trunk is cluttered with the developerN
merges. That is easy to solve by having local developers rebase before pushing
to local trunk. That would look like:
r1--r2--r3--r4--r5 upstream trunk
\ \ \
A---B---C---D---E---F'---G' local trunk
The major problem is that local trunk is also cluttered with merges from
upstream. The is a problem because at some point in the future, upstream
is going to declare some rN as being officially blessed. And we're going to
want to rewind any rN changes past that point.
So the question is, what's the best way to do this? Say r2 is blessed by
upstream. The obvious thing to do (I think...) is:
(local-trunk)$ git rebase -i r2
removing C and E from the pick list.
But, occassionally the merges from upstream require much conflict resolution.
Would enabling rerere during merges help with the rebasing? I would want to
reuse as much conflict resolution as possible.
Is there a better approach altogether? Should we be doing something other
than merging to stay atop upstream?
Suggestions/comments greatly appreciated.
j.
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Sverre Rabbelier @ 2009-12-14 20:41 UTC (permalink / raw)
To: Eric Paris; +Cc: git
In-Reply-To: <1260822484.9379.53.camel@localhost>
Heya,
On Mon, Dec 14, 2009 at 21:28, Eric Paris <eparis@redhat.com> wrote:
> What can I collect, do, whatever?
If this really is a case that we end up wanting to optimize somehow,
it would probably be very helpful to make a copy of the repository
state _before_ the gc is done.
Also, 1.5.5 is really really old in git terms, consider compiling your
own. Something post 1.6.4 might be a good idea :).
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Björn Steinbrink @ 2009-12-14 20:55 UTC (permalink / raw)
To: Jason King; +Cc: Junio C Hamano, git, Brandon Casey
In-Reply-To: <776A5AB0-E6BC-4230-800E-BE1B7A6B09BF@silentcow.com>
On 2009.12.14 12:38:30 -0800, Jason King wrote:
> On Dec 14, 2009, at 12:27 PM, Junio C Hamano wrote:
>
> >Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> >
> >>Commit c2ca1d7 "Allow mailsplit ... to handle mails with CRLF
> >>line-endings"
> >>seems to be responsible.
> >
> >Yes, that commit is not only responsible but was deliberate. For
> >a better
> >backstory, see:
> >
> > http://thread.gmane.org/gmane.comp.version-control.git/124718/focus=124721
> >
> >You'd notice that I was one of the people who didn't want to have this
> >change, so you don't need to convince _me_ that this was not a
> >change to
> >keep everybody happy, but you'd need to try a better job than I
> >did back
> >then to convince people who thought that "am" should directly work on
> >"Thunderbird saved mails" that what they want was a bad idea X-<.
>
> I dunno Junio, the back story doesn't really seem like a convincing
> argument for totally breaking am's handling of real CRLFs. Right
> now, it seems to be a very bad thing that git can create a patch
> that it can't apply. The default am should always be able to apply
> whatever format-patch has generated.
>
> If it's desirable to have am translate CRLFs to LFs, then why not
> provide this as an option to am so as not to break merging of real
> CRLF patches? Eg.:
>
> git am --convert-crlf
Hm, currently it checks everyline. I didn't really think this through,
but wouldn't it makes sense to have a per-mail flag, that checks just
the first line, and if that has CRLF, then enable the dropping (unless
--keep-cr is given), otherwise, keep things verbatim. That should (I
think) make things work with non-messed up patches regardless of the
files being patch, as well as with messed up patches as long as they
don't try to patch files with CRLF line-endings.
I can't seem to come up with a clean patch though (btw, is the comment
for split_one that says that buf may contain a partial line still
true?), but maybe I'll find some time to try again later this week
(don't count on it though, I'm pretty stressed...)
Björn
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Jeff King @ 2009-12-14 21:11 UTC (permalink / raw)
To: Eric Paris; +Cc: git
In-Reply-To: <1260822484.9379.53.camel@localhost>
On Mon, Dec 14, 2009 at 03:28:04PM -0500, Eric Paris wrote:
> So I have no idea what is interesting or relevant what I can collect,
> what you want to know or anything like that, so this is a bit of a dump
> of info and I'm sorry to whoever tries to pick anything useful out of
It sounds like you might have found an infinite loop, as reflog should
never really need a lot of CPU. Is it possible to tar the whole
repository and make it available publicly for us to look at?
-Peff
^ permalink raw reply
* Re: am fails to apply patches for files with CRLF lineendings
From: Jason King @ 2009-12-14 21:16 UTC (permalink / raw)
To: Björn Steinbrink; +Cc: Junio C Hamano, git, Brandon Casey
In-Reply-To: <20091214205517.GA1317@atjola.homenet>
On Dec 14, 2009, at 12:55 PM, Björn Steinbrink wrote:
> On 2009.12.14 12:38:30 -0800, Jason King wrote:
>> On Dec 14, 2009, at 12:27 PM, Junio C Hamano wrote:
>>
>>> Björn Steinbrink <B.Steinbrink@gmx.de> writes:
>>>
>>>> Commit c2ca1d7 "Allow mailsplit ... to handle mails with CRLF
>>>> line-endings"
>>>> seems to be responsible.
>>>
>>> Yes, that commit is not only responsible but was deliberate. For
>>> a better
>>> backstory, see:
>>>
>>> http://thread.gmane.org/gmane.comp.version-control.git/124718/focus=124721
>>>
>>> You'd notice that I was one of the people who didn't want to have
>>> this
>>> change, so you don't need to convince _me_ that this was not a
>>> change to
>>> keep everybody happy, but you'd need to try a better job than I
>>> did back
>>> then to convince people who thought that "am" should directly work
>>> on
>>> "Thunderbird saved mails" that what they want was a bad idea X-<.
>>
>> I dunno Junio, the back story doesn't really seem like a convincing
>> argument for totally breaking am's handling of real CRLFs. Right
>> now, it seems to be a very bad thing that git can create a patch
>> that it can't apply. The default am should always be able to apply
>> whatever format-patch has generated.
>>
>> If it's desirable to have am translate CRLFs to LFs, then why not
>> provide this as an option to am so as not to break merging of real
>> CRLF patches? Eg.:
>>
>> git am --convert-crlf
>
> Hm, currently it checks everyline. I didn't really think this through,
> but wouldn't it makes sense to have a per-mail flag, that checks just
> the first line, and if that has CRLF, then enable the dropping (unless
> --keep-cr is given), otherwise, keep things verbatim. That should (I
> think) make things work with non-messed up patches regardless of the
> files being patch, as well as with messed up patches as long as they
> don't try to patch files with CRLF line-endings.
Sure, it won't affect LFers at all if you test the header lines of the
patch file - we'll be immune from that conversion then. Works for me :)
Thanks again,
Jason
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-14 21:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091214211142.GC9364@coredump.intra.peff.net>
On Mon, 2009-12-14 at 16:11 -0500, Jeff King wrote:
> On Mon, Dec 14, 2009 at 03:28:04PM -0500, Eric Paris wrote:
>
> > So I have no idea what is interesting or relevant what I can collect,
> > what you want to know or anything like that, so this is a bit of a dump
> > of info and I'm sorry to whoever tries to pick anything useful out of
>
> It sounds like you might have found an infinite loop, as reflog should
> never really need a lot of CPU. Is it possible to tar the whole
> repository and make it available publicly for us to look at?
Updated to git-1.6.5.3-1 from Fedora rawhide and still git reflog ran
for >5 minutes at 100% cpu (I killed it, it didn't finish)
I'm pushing a copy of the whole repo (all 1.9G after bzip compression)
to
http://people.redhat.com/~eparis/git-tar/
But it's going to take a couple hours.
-Eric
^ permalink raw reply
* Re: [PATCH] help.autocorrect: do not run a command if the command given is junk
From: Johannes Schindelin @ 2009-12-14 21:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List, Alex Riesen
In-Reply-To: <7v7hspjp3q.fsf@alter.siamese.dyndns.org>
Hi,
On Mon, 14 Dec 2009, Junio C Hamano wrote:
> I am curious about and would prefer to see the story behind '6' someday.
The '6' as a cut-off to the levenshtein distances we list when
autocorrecting was derived in a totally scientific manner:
1) first I implemented Levenshtein-Damerau with a configurable weight of
neighbor flips ("switches"), substitutions, additions and deletions,
2) next I patched the code to sort the availablecommands by their distance
to the mispelt command,
3) as this lists way too much, I implemented a cut-off that was
configurable by an environment variable (without any safety checks, as
I did not plan to release that code anyway),
4) now comes the totally, unbelievably cunningly scientific part: I did a
self-experiment! I deliberately mispelt commands in a totally random
manner!
5) then I changed the code to actually output the distances so I could
determine a cut-off that makes sense with my type of tyops,
6) after about 15 tries of deliberate mistakes (mostly doing what I
usually do, something like "git pull" and "git log" or something like
that, but watching TV, chatting on the phone _and_ cleaning the dishes
at the same time), I found that 5 was too low and 7 too large.
The number '6' happily coincided with the number of steps I needed to come
up with the number. You see? The _perfect_ way to determine a completely
arbitrary number.
Actually, you probably see that I just made up that number and tested a
few times, and it seemed to work reasonably well.
FWIW almost the same procedure led to the weights 0, 2, 1 and 4 that you
see in help.c. The weights are basically factors with which mistakes are
punished: if you just confuse two adjacent letters, such as "psuh" instead
of "push" (which can be quite common if you use two hands, one on the left
side, and one on the right side of the keyboard, with an en-US layout so
many of us use, myself included) it costs 0.
If you write a different character than what you intended, the cost is 2.
The idea behind it is that you're more likely to miss a key than to hit
the wrong key. With the laptop I am typing this email on, it is
particularly likely that I miss a key, because there are certain
key combinations where only the first key triggers an input event, but the
second only triggers an input event when it is _released_ after the first
one. So when I type "er" real fast and happen to release the "e" key
after the "r" key, no "r" appears on my screen.
Okay, so the weight for adding a character must be smaller than
substituting a character, but why is the cost for deletion so high?
Well, I really rarely type unnecessary characters (except when writing to
the Git mailing list, arguably) so those costs must be substantially
higher than for typing the wrong character.
My original plan was to log all my tyops into a log file and analyze those
errors later, but then my initial 0, 2, 1, 4 and 6 constants worked well
enough for me that I did not bother.
Satisfied?
Ciao,
Dscho
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Jeff King @ 2009-12-14 21:23 UTC (permalink / raw)
To: Eric Paris; +Cc: git
In-Reply-To: <1260825629.9379.56.camel@localhost>
On Mon, Dec 14, 2009 at 04:20:29PM -0500, Eric Paris wrote:
> Updated to git-1.6.5.3-1 from Fedora rawhide and still git reflog ran
> for >5 minutes at 100% cpu (I killed it, it didn't finish)
>
> I'm pushing a copy of the whole repo (all 1.9G after bzip compression)
> to
>
> http://people.redhat.com/~eparis/git-tar/
Wowzers, that's big. Can you send just what's in .git?
-Peff
^ permalink raw reply
* Re: Help: approach for rebasing to older commits after merging more recent commits
From: Junio C Hamano @ 2009-12-14 21:33 UTC (permalink / raw)
To: Jay Soffian; +Cc: git
In-Reply-To: <76718490912141238k4ca1ba55jeff928efe875f020@mail.gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> [He asks again...]
>
> I have an interesting problem I'm not sure how best to tackle.
>
> A small development team is basing its product on an upstream git repo that is
> itself an svn clone. Currently the process looks like this:
>
> r1--r2--r3--r4--r5 upstream trunk (git svn clone)
> \ \ \
> A---B---C---D---E local trunk (git clone of upstream)
> \ /
> F---G developerN trunk (git clones of local)
>
> So local trunk has both daily merges from the local developers, as well as
> less periodic (typically weekly) merges from upstream trunk. The reason being
> that it is necessary to remain on top of the upstream bleeding edge.
>
> This works out okay, but there is a minor problem and a major problem.
>
> The minor problem is that the local trunk is cluttered with the developerN
> merges. That is easy to solve by having local developers rebase before pushing
> to local trunk. That would look like:
>
> r1--r2--r3--r4--r5 upstream trunk
> \ \ \
> A---B---C---D---E---F'---G' local trunk
>
> The major problem is that local trunk is also cluttered with merges from
> upstream. The is a problem because at some point in the future, upstream
> is going to declare some rN as being officially blessed. And we're going to
> want to rewind any rN changes past that point.
>
> So the question is, what's the best way to do this? Say r2 is blessed by
> upstream.
You should re-think your earlier claim:
The reason being that it is necessary to remain on top of the upstream
bleeding edge.
and then think about ways you can take advantage of the distributed nature
of git, especially the topic branch workflow it supports well.
The key realization is this:
It is necessary to remain on top of the upstream" does not mean "all
of the new development done by my group must build _on top of_ the
upstream" at all.
for one obvious reason: near the tip of the upstream is not necessarily
what you want in your final product. If the "blessed" point will be r2,
you won't want any topic to be based on r3 or later before forking your
release branch that contains the upstream up to r2.
You _would_ want to remain as compatible as possible with upstream later
than r2 even if the "blessed" point _for this cycle_ is r2, so you would
need a daily integration testing branch that is rebuilt by merging all the
topics from your group _and_ upstream tip and run your tests there. But
once you know which commit from the upstream side (r2 in your example)
will be the one your group will base your changes on and go into a pre-
release mode, you will likely to want to have _another_ test integration
branch to merge all the topics from your group that have forked from a
commit before r2, on top of r2. There _will_ be topics from some members
who unfortunately based their topic on commits newer than r2 and they need
to adjust their work on r2 or older. If they didn't depend on new API,
new features, or modified semantics r3 or later introduced, this rebase
should be trivial. On the other hand, if they did depend on new things,
the project management needs to make a decision. You may choose to
keep the topic out of your upcoming release (because it will depend on
features of upstream newer than the "blassed" upstream release your
product will be based on), or you may choose to "backport" the upstream
features the topic needs without slurping all the new and unstable
upstream features (e.g. if a topic based its work on a new feature
implemented in r5, but what r3 or r4 do are unnecessary for it, or any
other topics in your product, you will cherry-pick r5 on top of r2 and
then rebase the topic on top of the result).
It also means that your group members try not to base their work on the
daily integration branch which is your 'master' branch current is, nor
rebase their work on it before merging. Instead, fork from a known good
state where the result of building on it and then merging that with the
tip of the upstream and with other topics won't introduce excessive
conflicts.
The project manager may want to establish and maintain a reasonable
baseline that:
- merges from upstream trunk (but not its tip) only occasionally; Being
behind is perfectly fine and even preferable than being too hasty and
merging r3 and later into this branch.
- merges from group members' topics _only_ after they are _fully_
completed _and_ you are sure that you want these topics in your next
release.
and have group members fork from its tip. I'd recommend using 'master'
for that. Don't let random topics that are half-done (i.e. "this doesn't
do what it should do, but it hopefully doesn't break other things") merged
into this branch.
Then every test cycle (once a day, or continuous, it doesn't matter)
creates a throw-away test branch to the tip of this branch, merges all the
topics that are still cooking and testable, and merges from the updated
upstream. This may need conflict resolution, and rerere will help here.
And test the result. That way you will ensure that you will be "on top of
the bleeding edge".
When conflicts with the updated upstream become getting excessive, it is a
good sign that you would want to update the "baseline" (see above) with
(an early part of) the upstream.
If conflicts between topics of your group members become excessive, it is
a sign that you are not partitioning the work correctly. SCM is never a
substitute for developer communication and you may need to have the
members involved in the conflict talk with each other and resolve the
conflict between themselves. E.g. they may want to decide to merge their
work so far and build their topics upon a consolidated base.
And that "reasonable baseline", as long as it won't overstep 'r2' in the
end, will be directly the branch you cut your release from. On the day
you decide to base your next product on r2, you will fork 'release' branch
from the tip of 'master', and merge up to 'r2' from the upstream, and you
have your release with fully cooked topics. If on the other hand you have
already merged from the upstream up to 'r5' to 'master', then you would
need to build a separate 'release' branch, forking from some commits in
'master' before the branch merged commits later than 'r2' from the
upstream. Betweeen this fork-point and the tip of your 'master', there
will be some topics that have graduated to 'master'. You need to examine
them and see if they merge to 'release' without dragging 'r3' and later in
from the upstream, and make the management decision I mentioned 60 lines
ago.
^ permalink raw reply
* Re: [PATCH] help.autocorrect: do not run a command if the command given is junk
From: Junio C Hamano @ 2009-12-14 21:47 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Johannes Sixt, Git Mailing List, Alex Riesen
In-Reply-To: <alpine.DEB.1.00.0912142146590.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> Satisfied?
Very much.
FWIW almost the same procedure led to the weights 0, 2, 1 and 4 that you
see in help.c. The weights are basically factors with which mistakes are
punished: if you just confuse two adjacent letters, such as "psuh" instead
of "push" (which can be quite common if you use two hands, one on the left
side, and one on the right side of the keyboard, with an en-US layout so
many of us use, myself included) it costs 0.
If you write a different character than what you intended, the cost is 2.
The idea behind it is that you're more likely to miss a key than to hit
the wrong key. With the laptop I am typing this email on, it is
particularly likely that I miss a key, because there are certain
key combinations where only the first key triggers an input event, but the
second only triggers an input event when it is _released_ after the first
one. So when I type "er" real fast and happen to release the "e" key
after the "r" key, no "r" appears on my screen.
Okay, so the weight for adding a character must be smaller than
substituting a character, but why is the cost for deletion so high?
Well, I really rarely type unnecessary characters (except when writing to
the Git mailing list, arguably) so those costs must be substantially
higher than for typing the wrong character.
These are actually very good justifications in the sense that people who
might want to tweak the heuristics can see the reason behind the current
choice and agree or disagree with it.
I somehow suspect that a good mathematician can come up with a rationale
for 6 after the fact that sounds convincing, along the lines of "the
average length of commands being N, and levenshtein penalties being
<0,2,1,4>, you can insert X mistaken keystroke and/or omit Y mistaken
keystroke per every correct keystroke without exceeding this value 6, and
the percentage X and/or Y represents is not too low to be practical but low
enough to reject false positives".
In any case, I'll further squash in the following. Thanks for an amusing
explanation ;-).
diff --git a/help.c b/help.c
index fbf80d9..de1e2ea 100644
--- a/help.c
+++ b/help.c
@@ -297,7 +297,7 @@ static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
old->names = NULL;
}
-/* how did we decide this is a good cutoff??? */
+/* An empirically derived magic number */
#define SIMILAR_ENOUGH(x) ((x) < 6)
const char *help_unknown_cmd(const char *cmd)
^ permalink raw reply related
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Eric Paris @ 2009-12-14 21:56 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091214212343.GA11131@coredump.intra.peff.net>
On Mon, 2009-12-14 at 16:23 -0500, Jeff King wrote:
> On Mon, Dec 14, 2009 at 04:20:29PM -0500, Eric Paris wrote:
>
> > Updated to git-1.6.5.3-1 from Fedora rawhide and still git reflog ran
> > for >5 minutes at 100% cpu (I killed it, it didn't finish)
> >
> > I'm pushing a copy of the whole repo (all 1.9G after bzip compression)
> > to
> >
> > http://people.redhat.com/~eparis/git-tar/
>
> Wowzers, that's big. Can you send just what's in .git?
So I zipped up just .git 1.2G. I did a make clean and zipped up the
whole repo 1.3G.
Just started pushing the 1.3G file.
Maybe having a .git directory that large is the problem?
^ permalink raw reply
* Re: [PATCH] help.autocorrect: do not run a command if the command given is junk
From: Johannes Schindelin @ 2009-12-14 22:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Git Mailing List, Alex Riesen
In-Reply-To: <7vocm1grdb.fsf@alter.siamese.dyndns.org>
Hi,
On Mon, 14 Dec 2009, Junio C Hamano wrote:
> I somehow suspect that a good mathematician can come up with a rationale
> for 6 after the fact that sounds convincing, along the lines of "the
> average length of commands being N, and levenshtein penalties being
> <0,2,1,4>, you can insert X mistaken keystroke and/or omit Y mistaken
> keystroke per every correct keystroke without exceeding this value 6,
> and the percentage X and/or Y represents is not too low to be practical
> but low enough to reject false positives".
Being a mathematician, I was tempted to invent such a reasoning in
hindsight.
But I decided to be truthful instead,
Dscho
^ permalink raw reply
* Re: git-reflog 70 minutes at 100% cpu and counting
From: Sverre Rabbelier @ 2009-12-14 22:03 UTC (permalink / raw)
To: Eric Paris; +Cc: Jeff King, git
In-Reply-To: <1260827790.9379.59.camel@localhost>
Heya,
On Mon, Dec 14, 2009 at 22:56, Eric Paris <eparis@redhat.com> wrote:
> Just started pushing the 1.3G file.
>
> Maybe having a .git directory that large is the problem?
What did you say this repository contained again? Your home video's?
Ah, well that explains ;).
--
Cheers,
Sverre Rabbelier
^ 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