* git gui blame: git-blame loops at 100% cpu
@ 2010-04-17 23:13 5% Konrad Karl
0 siblings, 0 replies; 24+ results
From: Konrad Karl @ 2010-04-17 23:13 UTC (permalink / raw)
To: git
Dear list,
I have converted one of our Visual Source Safe repos to git (about 47000 commits, about 11 years of history, .git about 200 MB git gc'ed).
Everything seems to be working fine but git gui blame some_file seems to
procedure correct output in the file viewer but the progress bar stops
at 1271 of 2783 lines for one specific file and then the git-blame process
consumes 100% cpu.
Plain git blame completes in a fraction of a second just fine.
git-1.7.0.1-1.fc13.x86_64 (Fedora 13). I have also tested git 1.7.0.5
- same behaviour. ditto for the latest msys git in Windows.
perhaps I should mention that most of the source files in the repo are
using crlf line endings.
The hang does not happen on all files but on many - progress percentage
varying.
Konrad
--
Sicherer, schneller und einfacher. Die aktuellen Internet-Browser -
jetzt kostenlos herunterladen! http://portal.gmx.net/de/go/atbrowser
^ permalink raw reply [relevance 5%]
* git clone over smart-http hanging for just one repo.
@ 2010-03-22 6:52 4% Brady Catherman
0 siblings, 0 replies; 24+ results
From: Brady Catherman @ 2010-03-22 6:52 UTC (permalink / raw)
To: Git Mailing List
I have a git repo that fails to clone or fetch over smart-http, but
works great over dav. I am wondering if somebody can help me debug the
issue since I am at a loss why this is happening.
Just for clarification, I have several dozen repos in a directory,
almost all others work without issue, but one of them is messed up.
Replacing it with a different repo works so the error has to be
somewhere in the git files themselves. Cloning the repo via DAV works
and git fsck reports no problems with the repo.
This is all on git 1.7.0.1 on a Linux machine.
The interesting parts of a strace of git-http-backend following a git
clone follow:
12037 execve("/usr/libexec/git-core/git-http-backend.real", ["/usr/
libexec/git-core/git-http-backend.real"], [/* 33 vars */]) = 0
... various library loads and such ...
12037 access("/usr/local/git/gitrepo", F_OK) = 0
12037 chdir("/usr/local/git/gitrepo") = 0
12037 access("objects", X_OK) = 0
12037 access("refs", X_OK) = 0
12037 lstat("HEAD", {st_mode=S_IFREG|0644, st_size=23, ...}) = 0
12037 open("HEAD", O_RDONLY) = 3
12037 read(3, "ref: refs/heads/master\n", 255) = 23
12037 access("/usr/local/etc/gitconfig", R_OK) = -1 ENOENT (No such
file or directory)
12037 access("./config", R_OK) = 0
12037 open("./config", O_RDONLY) = 3
12037 read(3, "[core]\n\trepositoryformatversion = 0\n\tfilemode = true
\n\tbare = true\n\tlogallrefupdates = true\n\tsharedRepository = true
\n", 4096) = 116
12037 read(3, "", 4096) = 0
12037 close(3) = 0
12037 munmap(0x2aaaaaaac000, 4096) = 0
12037 write(1, "Expires: Fri, 01 Jan 1980 00:00:00 GMT\r\n", 40) = 40
12037 write(1, "Pragma: no-cache\r\n", 18) = 18
12037 write(1, "Cache-Control: no-cache, max-age=0, must-revalidate\r
\n", 53) = 53
12037 write(1, "Content-Type: application/x-git-upload-pack-result\r
\n", 52) = 52
12037 write(1, "\r\n", 2) = 2
12037 pipe([3, 4]) = 0
12037 pipe([3, 4]) = 012037 pipe([5,
6]) = 0
12037 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|
CLONE_CHILD_SETTID|SIGCHLD
, child_tidptr=0x2aaaaae12c20) = 12038
12038 close(5 <unfinished ...>
12037 close(6) = 0
12037 read(5, <unfinished ...>
12038 <... close resumed> ) = 0
12038 fcntl(6, F_GETFD) = 0
12038 fcntl(6, F_SETFD, FD_CLOEXEC) = 012038 dup2(3,
0) = 0
12038 close(3) = 012038
close(4) = 0
12038 execve("/usr/local/libexec/git-core/git", ["git", "upload-pack",
"--stateless-rpc", "."], [/* 36 vars */]) = -1 ENOENT (No such file or
directory)
12038 execve("/usr/libexec/git-core/git", ["git", "upload-pack", "--
stateless-rp
c", "."], [/* 36 vars */] <unfinished ...>
12037 <... read resumed> "", 1) = 0
12037 <... read resumed> "", 1) = 012037
close(5) = 0
12037 close(3) = 012038 <... execve
resumed> ) = 0
12037 close(1) = 0
... More random library loads ...
12038 pipe([3, 4]) = 0
12038 clone(child_stack=0, flags=CLONE_CHILD_CLEARTID|
CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x2aaaaae12c40) = 12039
12039 close(3) = 0
12039 fcntl(4, F_GETFD) = 0
12039 fcntl(4, F_SETFD, FD_CLOEXEC) = 0
12039 execve("/usr/libexec/git-core/git-upload-pack", ["git-upload-
pack", "--stateless-rpc", "."], [/* 36 vars */] <unfinished ...>
12038 close(4) = 0
12037 read(0, "0067want c83f5a4ec9fb6b6681e74dc3c2276de5b947a76c
multi_ack_detailed side-band-64k thin-pack ofs-delta\n0032want
92e9b73bbd59b5ecf711381716c8aa13948f5a5d\n0032want
.. clipped out lots of sha's ..
98040a8100513ad2852ca911ac330ebd4ff9e10d\n00000009done\n", 8192) = 2316
12039 <... execve resumed> ) = 0
12038 <... read resumed> "", 1) = 0
12038 close(3) = 0
12039 brk(0 <unfinished ...>
12038 wait4(12039, <unfinished ...>
12039 <... brk resumed> ) = 0xf9d1000
12037 write(1, "Status: 500 Internal Server Error\r\n", 35
<unfinished ...>
12039 mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|
MAP_ANONYMOUS, -1, 0 <unfinished ...>
12037 <... write resumed> ) = -1 EBADF (Bad file descriptor)
12039 <... mmap resumed> ) = 0x2aaaaaaab000
... This repeats for a while.. spitting out 500's on a bad file
descriptor...
12037 write(1, "Status: 500 Internal Server Error\r\n", 35) = -1 EBADF
(Bad file descriptor)
... Eventually this just repeats a few thousand times ...
12037 write(1, "Status: 500 Internal Server Error\r\n", 35) = -1 EBADF
(Bad file descriptor)
12037 --- SIGSEGV (Segmentation fault) @ 0 (0) ---
12037 +++ killed by SIGSEGV +++
12039 <... read resumed> "", 4) = 0
12039 write(2, "fatal: The remote end hung up unexpectedly\n", 43) = 43
12039 exit_group(128) = ?
12038 <... wait4 resumed> [{WIFEXITED(s) && WEXITSTATUS(s) == 128}],
0, NULL) = 12039
12038 --- SIGCHLD (Child exited) @ 0 (0) ---
12038 exit_group(128) = ?
Anybody have any thoughts why this would happen or what can be done to
fix it?
^ permalink raw reply [relevance 4%]
* Modified files directly after clone
@ 2010-03-09 20:26 5% Benedikt Andreas Koeppel
0 siblings, 0 replies; 24+ results
From: Benedikt Andreas Koeppel @ 2010-03-09 20:26 UTC (permalink / raw)
To: git
Dear Sir/Madam,
I'm experiencing a strange problem with one of my GIT repositories. The repo is hosted on my Debian 5 server with gitosis. I clone the repo to my Mac OS X 10.6 notebook. Directly after cloning the repository, there are already some modified files which are "Changed but not updated".
This is how I do it:
==== bash start ====
beninb:Desktop beni$ mkdir tmp
beninb:Desktop beni$ cd tmp
beninb:tmp beni$ git clone git@gmuasch:ife-maemo.git git
Initialized empty Git repository in /Users/beni/Desktop/tmp/git/.git/
remote: Counting objects: 43316, done.
remote: Compressing objects: 100% (33045/33045), done.
remote: Total 43316 (delta 10942), reused 42064 (delta 9790)
Receiving objects: 100% (43316/43316), 518.25 MiB | 640 KiB/s, done.
Resolving deltas: 100% (10942/10942), done.
Checking out files: 100% (68385/68385), done.
beninb:tmp beni$ cd git/
beninb:git beni$ git status
# On branch master
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: source/crn/toolbox/doc/html/classVector.html
# modified: source/maemo-beagle/www/files/maemo5-alpha/kernel-2.6.28/Documentation/IO-mapping.txt
# some more lines
# modified: source/maemo-beagle/www/files/maemo5-alpha/kernel-2.6.28/net/netfilter/xt_TCPMSS.c
# modified: source/maemo-kernel/kernel-2.6.28/Documentation/IO-mapping.txt
# some more lines
# modified: source/maemo-kernel/kernel-2.6.28/net/netfilter/xt_TCPMSS.c
#
no changes added to commit (use "git add" and/or "git commit -a")
==== bash end ====
"gmuasch" is an SSH-alias for my Debian server
git diff gives the following: http://pastie.org/861916
On my server, I'm running git version 1.6.2.4. Locally on my Mac, I have git version 1.6.2. But there were some commits done from Ubuntu 9.10 with git 1.7.0.1.
Those folders are SVN checkouts:
source/crn
source/maemo-beagle
But source/maemo-kernel is not a SVN checkout.
I tried the same procedure on a different machine (running Debian 5, git version 1.6.2.4), and did not have any modified files after cloning the repo.
How can this happen? Does my Mac somehow interfere with the newly cloned repository?
Best Regards,
Benedikt Köppel
^ permalink raw reply [relevance 5%]
* git-rebase -i prunes commits with empty commit-message
@ 2010-03-08 20:07 5% Erik Faye-Lund
0 siblings, 0 replies; 24+ results
From: Erik Faye-Lund @ 2010-03-08 20:07 UTC (permalink / raw)
To: Git Mailing List
I'm in the process of converting an SVN repo to Git, and in the
process I found one quite disturbing feature of
git-rebase--interactive.sh: It discards commits with empty commit
messages!
Here's a recepie for reproducing the issue:
--->8---
git init
git commit -m "dummy" --allow-empty
git commit -m "dummy" --allow-empty
git commit -m "dummy" --allow-empty
git filter-branch -f --msg-filter 'sed -e "s/dummy//"'
git rebase -i HEAD~2
--->8---
The editor window will show "noop", and exiting the editor goes ahead
and deletes all but the initial commit.
This gets even weirder if it's a mixture of empty and non-empty
commits; the commit-identifiers gets appended, together with an
angle-bracket ('>'), to the previous line.
I'm guessing that this is unintended behavior. This was observed on git 1.7.0.1.
--
Erik "kusma" Faye-Lund
^ permalink raw reply [relevance 5%]
* Re: git-http-backend: hook output not delivered to client
2010-03-06 22:30 0% ` Shawn O. Pearce
@ 2010-03-06 22:53 0% ` BJ Hargrave
0 siblings, 0 replies; 24+ results
From: BJ Hargrave @ 2010-03-06 22:53 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
Thanks for the quick feedback. I will keep my eye out for 1.7.0.2.
--
BJ Hargrave
On Mar 6, 2010, at 17:30 , Shawn O. Pearce wrote:
> BJ Hargrave <bj@bjhargrave.com> wrote:
>> I have compiled and installed git 1.7.0.1 on a RHEL4 box
> ...
>> So the push properly fails in both cases because the hook exits
>> with a non-zero return code, but it seems there is a problem with
>> git-http-backend not ferrying the hook output messages back to
>> the client.
>
> Yes, we know about this problem.
>
> You need commit 466dbc42f5 ("receive-pack: Send internal errors over
> side-band #2") on both the client and the server for hook messages
> to work over HTTP.
>
> This hasnt been released yet. It is slated for 1.7.0.2.
>
> --
> Shawn.
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [relevance 0%]
* Re: git-http-backend: hook output not delivered to client
2010-03-06 22:24 5% git-http-backend: hook output not delivered to client BJ Hargrave
@ 2010-03-06 22:30 0% ` Shawn O. Pearce
2010-03-06 22:53 0% ` BJ Hargrave
0 siblings, 1 reply; 24+ results
From: Shawn O. Pearce @ 2010-03-06 22:30 UTC (permalink / raw)
To: BJ Hargrave; +Cc: git
BJ Hargrave <bj@bjhargrave.com> wrote:
> I have compiled and installed git 1.7.0.1 on a RHEL4 box
...
> So the push properly fails in both cases because the hook exits
> with a non-zero return code, but it seems there is a problem with
> git-http-backend not ferrying the hook output messages back to
> the client.
Yes, we know about this problem.
You need commit 466dbc42f5 ("receive-pack: Send internal errors over
side-band #2") on both the client and the server for hook messages
to work over HTTP.
This hasnt been released yet. It is slated for 1.7.0.2.
--
Shawn.
^ permalink raw reply [relevance 0%]
* git-http-backend: hook output not delivered to client
@ 2010-03-06 22:24 5% BJ Hargrave
2010-03-06 22:30 0% ` Shawn O. Pearce
0 siblings, 1 reply; 24+ results
From: BJ Hargrave @ 2010-03-06 22:24 UTC (permalink / raw)
To: git
I have compiled and installed git 1.7.0.1 on a RHEL4 box and am using Apache httpd with git-http-backend. I have developed a pre-receive hook to validate that incoming commits are from a list of committers. I have tested the hook and it correctly detects invalid committers, outputs error message and exits with a non-zero return code.
If I push a commit from an invalid committer to a repo using ssh, the hook properly detects this. git-push displays the pre-receive hook's output messages and indicates the push failed.
However if I push a commit from an invalid committer to the repo using http (git-http-backend), the hook is run and detects the invalid committer but the output messages (stderr) end up in the httpd error log instead of being ferried back to git-push. git-push does exit with an error code but the user has no visible indication there was an error on the push. The git-push output look like everything went fine even though the push failed.
So the push properly fails in both cases because the hook exits with a non-zero return code, but it seems there is a problem with git-http-backend not ferrying the hook output messages back to the client. Has anyone seen this? Or have I some how configure the system wrong?
Thanks,
--
BJ Hargrave
^ permalink raw reply [relevance 5%]
* Re: gitignore broken in git 1.7.0.1: slash checks leading dirs
2010-03-05 17:25 7% ` Jonathan Nieder
@ 2010-03-05 19:30 7% ` Jiri Slaby
0 siblings, 0 replies; 24+ results
From: Jiri Slaby @ 2010-03-05 19:30 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Johannes Sixt, git
On 03/05/2010 06:25 PM, Jonathan Nieder wrote:
> Jiri Slaby wrote:
>
>> Thinking about it, there is no way to specify a *filename* no matter
>> where it lies? I.e. patterns such as *.o matches also a/b/test.o/test.c?
>> Am I missing something?
>
> Is
>
> *.o
> !*.o/
>
> what you are looking for? The first line matches *.o anywhere, and
> the second matches *.o anywhere as long as it is a directory.
As I wrote above, *.o also matches against a/b/test.o/test.c, correct?
^ permalink raw reply [relevance 7%]
* Re: gitignore broken in git 1.7.0.1: slash checks leading dirs
2010-03-05 9:29 7% ` Jiri Slaby
@ 2010-03-05 17:25 7% ` Jonathan Nieder
2010-03-05 19:30 7% ` Jiri Slaby
0 siblings, 1 reply; 24+ results
From: Jonathan Nieder @ 2010-03-05 17:25 UTC (permalink / raw)
To: Jiri Slaby; +Cc: Johannes Sixt, git
Jiri Slaby wrote:
> Thinking about it, there is no way to specify a *filename* no matter
> where it lies? I.e. patterns such as *.o matches also a/b/test.o/test.c?
> Am I missing something?
Is
*.o
!*.o/
what you are looking for? The first line matches *.o anywhere, and
the second matches *.o anywhere as long as it is a directory.
^ permalink raw reply [relevance 7%]
* Re: gitignore broken in git 1.7.0.1: slash checks leading dirs
2010-03-05 9:05 7% ` Johannes Sixt
2010-03-05 9:07 7% ` Jiri Slaby
2010-03-05 15:12 5% ` Jonathan Nieder
@ 2010-03-05 17:01 7% ` Junio C Hamano
2 siblings, 0 replies; 24+ results
From: Junio C Hamano @ 2010-03-05 17:01 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jiri Slaby, git, LKML
Johannes Sixt <j.sixt@viscovery.net> writes:
> Jiri Slaby schrieb:
>> having 'linux' line in .gitignore makes 'include/linux/vga_switcheroo.h'
>> to be ignored
>
> That's the behavior that I would expect.
Also the initial report made it sound as if there were a regression, but
it doesn't seem to be the case; I don't see it behaving any differently
among 1.7.0, 1.7.0.1, 1.6.0, 1.6.6, or even 1.5.4.
^ permalink raw reply [relevance 7%]
* Re: gitignore broken in git 1.7.0.1: slash checks leading dirs
2010-03-05 15:12 5% ` Jonathan Nieder
2010-03-05 15:15 7% ` Jonathan Nieder
@ 2010-03-05 15:34 7% ` Johannes Sixt
1 sibling, 0 replies; 24+ results
From: Johannes Sixt @ 2010-03-05 15:34 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Jiri Slaby, git
Jonathan Nieder schrieb:
> · Otherwise, git treats the pattern as a shell glob suitable for
> consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the
> pattern will not match a / in the pathname. For example,
> "Documentation/*.html" matches "Documentation/git.html" and
> "tools/perf/Documentation/perf-diff.html" but not
> "Documentation/ppc/ppc.html".
This is not correct: When the pattern "Documentation/*.html" matches
"Documentation/git.html", then it cannot match
"tools/perf/Documentation/perf-diff.html". This is because patterns that
contain a slash (after stripping a trailing slash) are anchored at the
directory that contains the .gitignore.
Said pattern would match the latter name only if it appeared in
tools/perf/.gitignore (but in this case it wouldn't match the former name,
of course).
-- Hannes
^ permalink raw reply [relevance 7%]
* Re: gitignore broken in git 1.7.0.1: slash checks leading dirs
2010-03-05 15:12 5% ` Jonathan Nieder
@ 2010-03-05 15:15 7% ` Jonathan Nieder
2010-03-05 15:34 7% ` Johannes Sixt
1 sibling, 0 replies; 24+ results
From: Jonathan Nieder @ 2010-03-05 15:15 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jiri Slaby, git
Jonathan Nieder wrote:
> Johannes Sixt wrote:
>> Jiri Slaby schrieb:
>
>>> having 'linux' line in .gitignore makes 'include/linux/vga_switcheroo.h'
>>> to be ignored
[...]
>> and this citation confirms my expectation. Note that it says "pathname",
>> not "filename". 'include/linux' is a "pathname".
>
> It would be more precise to say this citation does not have much to do
> with it. 'include/linux' contains a slash, so that paragraph does not
> describe what it means.
Curse my quick reading. Sorry for the nonsense, please ignore.
My suggested patch still might make sense, though. :)
Jonathan
^ permalink raw reply [relevance 7%]
* Re: gitignore broken in git 1.7.0.1: slash checks leading dirs
2010-03-05 9:05 7% ` Johannes Sixt
2010-03-05 9:07 7% ` Jiri Slaby
@ 2010-03-05 15:12 5% ` Jonathan Nieder
2010-03-05 15:15 7% ` Jonathan Nieder
2010-03-05 15:34 7% ` Johannes Sixt
2010-03-05 17:01 7% ` Junio C Hamano
2 siblings, 2 replies; 24+ results
From: Jonathan Nieder @ 2010-03-05 15:12 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Jiri Slaby, git
Johannes Sixt wrote:
> Jiri Slaby schrieb:
>> having 'linux' line in .gitignore makes 'include/linux/vga_switcheroo.h'
>> to be ignored
>
> That's the behavior that I would expect.
>
>> though the documentation says:
>> ***
>> If the pattern does not contain a slash /, git treats it as a shell
>> glob pattern and checks for a match against the pathname without
>> leading directories.
>> ***
>
> and this citation confirms my expectation. Note that it says "pathname",
> not "filename". 'include/linux' is a "pathname".
It would be more precise to say this citation does not have much to do
with it. 'include/linux' contains a slash, so that paragraph does not
describe what it means.
The next paragraph is more on point:
· Otherwise, git treats the pattern as a shell glob suitable for
consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the
pattern will not match a / in the pathname. For example,
"Documentation/*.html" matches "Documentation/git.html" but not
"Documentation/ppc/ppc.html". A leading slash matches the beginning of
the pathname; for example, "/*.c" matches "cat-file.c" but not
"mozilla-sha1/sha1.c".
The relevant sentence is the last one, and I can see how the length of the
paragraph might be daunting. Maybe splitting it up would help?
· Otherwise, git treats the pattern as a shell glob suitable for
consumption by fnmatch(3) with the FNM_PATHNAME flag: wildcards in the
pattern will not match a / in the pathname. For example,
"Documentation/*.html" matches "Documentation/git.html" and
"tools/perf/Documentation/perf-diff.html" but not
"Documentation/ppc/ppc.html".
· A leading slash matches the beginning of the pathname; for example,
"/*.c" matches "cat-file.c" but not "mozilla-sha1/sha1.c".
Not sure.
Jonathan
-- %< --
Subject: gitignore.5: Clarify that path matches are not anchored
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/gitignore.txt | 11 +++++++----
1 files changed, 7 insertions(+), 4 deletions(-)
diff --git a/Documentation/gitignore.txt b/Documentation/gitignore.txt
index 98c459d..fa15422 100644
--- a/Documentation/gitignore.txt
+++ b/Documentation/gitignore.txt
@@ -89,10 +89,13 @@ Patterns have the following format:
for consumption by fnmatch(3) with the FNM_PATHNAME flag:
wildcards in the pattern will not match a / in the pathname.
For example, "Documentation/\*.html" matches
- "Documentation/git.html" but not
- "Documentation/ppc/ppc.html". A leading slash matches the
- beginning of the pathname; for example, "/*.c" matches
- "cat-file.c" but not "mozilla-sha1/sha1.c".
+ "Documentation/git.html" and
+ "tools/perf/Documentation/perf-diff.html" but not
+ "Documentation/ppc/ppc.html".
+
+ - A leading slash matches the beginning of the pathname;
+ for example, "/*.c" matches "cat-file.c" but not
+ "mozilla-sha1/sha1.c".
An example:
--
1.7.0
^ permalink raw reply related [relevance 5%]
* Re: gitignore broken in git 1.7.0.1: slash checks leading dirs
2010-03-05 9:16 7% ` Johannes Sixt
@ 2010-03-05 9:29 7% ` Jiri Slaby
2010-03-05 17:25 7% ` Jonathan Nieder
0 siblings, 1 reply; 24+ results
From: Jiri Slaby @ 2010-03-05 9:29 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, LKML
On 03/05/2010 10:16 AM, Johannes Sixt wrote:
> The cited sentence says that the particular check considers only the last
> path component of the pathname.
Thinking about it, there is no way to specify a *filename* no matter
where it lies? I.e. patterns such as *.o matches also a/b/test.o/test.c?
Am I missing something?
--
js
^ permalink raw reply [relevance 7%]
* Re: gitignore broken in git 1.7.0.1: slash checks leading dirs
2010-03-05 9:07 7% ` Jiri Slaby
@ 2010-03-05 9:16 7% ` Johannes Sixt
2010-03-05 9:29 7% ` Jiri Slaby
0 siblings, 1 reply; 24+ results
From: Johannes Sixt @ 2010-03-05 9:16 UTC (permalink / raw)
To: Jiri Slaby; +Cc: git, LKML
Jiri Slaby schrieb:
> On 03/05/2010 10:05 AM, Johannes Sixt wrote:
>> Jiri Slaby schrieb:
>>> ***
>>> If the pattern does not contain a slash /, git treats it as a shell
>>> glob pattern and checks for a match against the pathname without
>>> leading directories.
>>> ***
>> and this citation confirms my expectation. Note that it says "pathname",
>> not "filename". 'include/linux' is a "pathname".
>
> What are 'leading directories' then?
'include/' is the leading directory of 'include/linux'.
The cited sentence says that the particular check considers only the last
path component of the pathname.
-- Hannes
^ permalink raw reply [relevance 7%]
* Re: gitignore broken in git 1.7.0.1: slash checks leading dirs
2010-03-05 9:05 7% ` Johannes Sixt
@ 2010-03-05 9:07 7% ` Jiri Slaby
2010-03-05 9:16 7% ` Johannes Sixt
2010-03-05 15:12 5% ` Jonathan Nieder
2010-03-05 17:01 7% ` Junio C Hamano
2 siblings, 1 reply; 24+ results
From: Jiri Slaby @ 2010-03-05 9:07 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git, LKML
On 03/05/2010 10:05 AM, Johannes Sixt wrote:
> Jiri Slaby schrieb:
>> having 'linux' line in .gitignore makes 'include/linux/vga_switcheroo.h'
>> to be ignored
>
> That's the behavior that I would expect.
>
>> though the documentation says:
>> ***
>> If the pattern does not contain a slash /, git treats it as a shell
>> glob pattern and checks for a match against the pathname without
>> leading directories.
>> ***
>
> and this citation confirms my expectation. Note that it says "pathname",
> not "filename". 'include/linux' is a "pathname".
What are 'leading directories' then?
--
js
^ permalink raw reply [relevance 7%]
* Re: gitignore broken in git 1.7.0.1: slash checks leading dirs
2010-03-05 8:55 7% gitignore broken in git 1.7.0.1: slash checks leading dirs Jiri Slaby
@ 2010-03-05 9:05 7% ` Johannes Sixt
2010-03-05 9:07 7% ` Jiri Slaby
` (2 more replies)
0 siblings, 3 replies; 24+ results
From: Johannes Sixt @ 2010-03-05 9:05 UTC (permalink / raw)
To: Jiri Slaby; +Cc: git, LKML
Jiri Slaby schrieb:
> having 'linux' line in .gitignore makes 'include/linux/vga_switcheroo.h'
> to be ignored
That's the behavior that I would expect.
> though the documentation says:
> ***
> If the pattern does not contain a slash /, git treats it as a shell
> glob pattern and checks for a match against the pathname without
> leading directories.
> ***
and this citation confirms my expectation. Note that it says "pathname",
not "filename". 'include/linux' is a "pathname".
-- Hannes
^ permalink raw reply [relevance 7%]
* gitignore broken in git 1.7.0.1: slash checks leading dirs
@ 2010-03-05 8:55 7% Jiri Slaby
2010-03-05 9:05 7% ` Johannes Sixt
0 siblings, 1 reply; 24+ results
From: Jiri Slaby @ 2010-03-05 8:55 UTC (permalink / raw)
To: git; +Cc: LKML
Hi,
having 'linux' line in .gitignore makes 'include/linux/vga_switcheroo.h'
to be ignored though the documentation says:
***
If the pattern does not contain a slash /, git treats it as a shell
glob pattern and checks for a match against the pathname without
leading directories.
***
$ touch test
$ touch include/linux/vga_asdads.h
$ git ls-files -o --exclude-from=test
include/linux/vga_asdads.h
test
$ echo linux >test
$ git ls-files -o --exclude-from=test
test
This does not happen with git 1.6.
thanks,
--
js
^ permalink raw reply [relevance 7%]
* Re: git svn fetch gives Index mismatch
@ 2010-03-03 22:12 5% ` Felix Möller
0 siblings, 0 replies; 24+ results
From: Felix Möller @ 2010-03-03 22:12 UTC (permalink / raw)
To: Andrew Myrick; +Cc: git
Hi Andrew,
Am 03.03.2010 22:18, schrieb Andrew Myrick:
> This may have been fixed with commit 41c01693ac13846c73a31c8f5c3a60206e1643be. Try git-1.7.0.
I am now running a rebuilt git-1.7.0.1-1.fc14.i686 on Fedora 12 and get
the following with it:
> [fm@thinkpad adempiere.git]$ git svn fetch
> ^[^NIndex mismatch: fac38f8fdc7d816e9dd26b469e08a98428f3f2a5 != 0aea771bc7629d194ada8bb448e863ffe7868189
> rereading e662b48c06fb9a263f717546ffbb41a39f94d597
> M mvcForms/db/ddlutils/postgresql/functions/round.sql
> M mvcForms/db/ddlutils/oracle/functions/documentNo.sql
...
> M mvcForms/client/src/org/adempiere/apps/graph/Graph.java
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/branches/stable/data/hu_HU
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/data/hu_HU
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/branches/adempiere341/zkwebui/WEB-INF/src
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/branches/stable/zkwebui/WEB-INF/src
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/extend/posterita/webui/WEB-INF/src
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/extension/posterita/webui/WEB-INF/src
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/zkwebui/WEB-INF/src
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/branches/adempiere341/base/src
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/base/src
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/migration/351a-352a
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/migration/352a-353a
> W: Cannot find common ancestor between e662b48c06fb9a263f717546ffbb41a39f94d597 and 7ac062d801daf46537377154daf39e5b21a8f447. Ignoring merge info.
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/branches/adempiere341/zkwebui
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/branches/stable/zkwebui
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/zkwebui
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/branches/adempiere341/zkwebui/css
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/branches/stable/zkwebui/css
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/zkwebui/css
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/branches/adempiere341/base
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/base
> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/migration/All320-340
> r10767 = e2069c625b3dc0639b31992186ab0f20da1cbf13 (refs/remotes/metas)
> A tools/lib/miglayout-3.7.1-swing.jar
> M tools/build.xml
so it seems to be handled gracefully now.
Thanks for your tip!
regards
Felix Möller
> On Mar 3, 2010, at 1:07 PM, Felix Möller wrote:
>> Hi,
>>
>> I am new to git and tried to checkout the Subversion Repository of ADempiere. https://adempiere.svn.sourceforge.net/svnroot/adempiere
>>
>> I get the following doing it:
>>> [fm@thinkpad adempiere.git]$ git svn fetch
>>> Index mismatch: fac38f8fdc7d816e9dd26b469e08a98428f3f2a5 != 0aea771bc7629d194ada8bb448e863ffe7868189
>>> rereading e662b48c06fb9a263f717546ffbb41a39f94d597
>>> M mvcForms/db/ddlutils/postgresql/functions/round.sql
>>> M mvcForms/db/ddlutils/oracle/functions/documentNo.sql
>>> ...
>>> M mvcForms/client/src/org/compiere/grid/ed/VLookup.java
>>> M mvcForms/client/src/org/compiere/print/Viewer.java
>>> M mvcForms/client/src/org/adempiere/apps/graph/Graph.java
>>> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/branches/stable/data/hu_HU
>>> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/data/hu_HU
>>> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/branches/adempiere341/zkwebui/WEB-INF/src
>>> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/branches/stable/zkwebui/WEB-INF/src
>>> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/extend/posterita/webui/WEB-INF/src
>>> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/extension/posterita/webui/WEB-INF/src
>>> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/zkwebui/WEB-INF/src
>>> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/branches/adempiere341/base/src
>>> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/base/src
>>> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/migration/351a-352a
>>> Couldn't find revmap for https://adempiere.svn.sourceforge.net/svnroot/adempiere/trunk/migration/352a-353a
>>> merge-base e662b48c06fb9a263f717546ffbb41a39f94d597 7ac062d801daf46537377154daf39e5b21a8f447: command returned error: 1
^ permalink raw reply [relevance 5%]
* Re: error when installing 1.7.0.1: "ImportError: No module named distutils.core"
@ 2010-03-01 17:04 0% Oliver Kullmann
0 siblings, 0 replies; 24+ results
From: Oliver Kullmann @ 2010-03-01 17:04 UTC (permalink / raw)
To: git
Okay, with --without-python it works now.
If it's not needed for most people, wouldn't it be
better that this would be the default?
Thanks!
Oliver
On Mon, Mar 01, 2010 at 11:15:41AM -0500, Todd Zullinger wrote:
> Oliver Kullmann wrote:
> > I've installed 1.6.6.2, but now when
> > installing 1.7.0.1 (same machine) I get
> >
> > make[3]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Git/git-1.7.0.1/perl'
> > make[2]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Git/git-1.7.0.1/perl'
> > make[2]: Entering directory `/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Git/git-1.7.0.1/git_remote_helpers'
> > Traceback (most recent call last):
> > File "setup.py", line 5, in ?
> > from distutils.core import setup
> > ImportError: No module named distutils.core
> >
> >
> > I'm using
> >
> > make configure
> > sh ./configure --prefix=InstallDir
> > make all
>
> If you have no need for the git_remote_helpers (and unless you are
> working on adding a git remote helper in python, I don't think you
> do), you can pass --without-python to configure. I think that's the
> right way using configure, I use make directly and pass NO_PYTHON = 1
> for the time being.
>
> --
> Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
> There are no differences but differences of degree between different
> degrees of difference and no difference.
> -- William James, under nitrous oxide; 1882
>
--
Dr. Oliver Kullmann
Computer Science Department
Swansea University
Faraday Building, Singleton Park
Swansea SA2 8PP, UK
http://cs.swan.ac.uk/~csoliver/
^ permalink raw reply [relevance 0%]
* Re: error when installing 1.7.0.1: "ImportError: No module named distutils.core"
2010-03-01 14:40 8% error when installing 1.7.0.1: "ImportError: No module named distutils.core" Oliver Kullmann
2010-03-01 15:15 0% ` Tay Ray Chuan
@ 2010-03-01 16:15 0% ` Todd Zullinger
1 sibling, 0 replies; 24+ results
From: Todd Zullinger @ 2010-03-01 16:15 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: git
[-- Attachment #1: Type: text/plain, Size: 1343 bytes --]
Oliver Kullmann wrote:
> I've installed 1.6.6.2, but now when
> installing 1.7.0.1 (same machine) I get
>
> make[3]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Git/git-1.7.0.1/perl'
> make[2]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Git/git-1.7.0.1/perl'
> make[2]: Entering directory `/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Git/git-1.7.0.1/git_remote_helpers'
> Traceback (most recent call last):
> File "setup.py", line 5, in ?
> from distutils.core import setup
> ImportError: No module named distutils.core
>
>
> I'm using
>
> make configure
> sh ./configure --prefix=InstallDir
> make all
If you have no need for the git_remote_helpers (and unless you are
working on adding a git remote helper in python, I don't think you
do), you can pass --without-python to configure. I think that's the
right way using configure, I use make directly and pass NO_PYTHON = 1
for the time being.
--
Todd OpenPGP -> KeyID: 0xBEAF0CE3 | URL: www.pobox.com/~tmz/pgp
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
There are no differences but differences of degree between different
degrees of difference and no difference.
-- William James, under nitrous oxide; 1882
[-- Attachment #2: Type: application/pgp-signature, Size: 542 bytes --]
^ permalink raw reply [relevance 0%]
* Re: error when installing 1.7.0.1: "ImportError: No module named distutils.core"
2010-03-01 14:40 8% error when installing 1.7.0.1: "ImportError: No module named distutils.core" Oliver Kullmann
@ 2010-03-01 15:15 0% ` Tay Ray Chuan
2010-03-01 16:15 0% ` Todd Zullinger
1 sibling, 0 replies; 24+ results
From: Tay Ray Chuan @ 2010-03-01 15:15 UTC (permalink / raw)
To: Oliver Kullmann; +Cc: git, Sverre Rabbelier
Hi,
On Mon, Mar 1, 2010 at 10:40 PM, Oliver Kullmann
<O.Kullmann@swansea.ac.uk> wrote:
> make[3]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Git/git-1.7.0.1/perl'
> make[2]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Git/git-1.7.0.1/perl'
> make[2]: Entering directory `/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Git/git-1.7.0.1/git_remote_helpers'
> Traceback (most recent call last):
> File "setup.py", line 5, in ?
> from distutils.core import setup
> ImportError: No module named distutils.core
(adding Sverre to the Cc list, perhaps he has something to add)
you need to install setuptools from python, or pass NO_PYTHON to make/configure.
> I've checked the README and INSTALL file, but I don't see that there are new
> requirements? (That is not regarding doc.)
I guess we should improve on this.
--
Cheers,
Ray Chuan
^ permalink raw reply [relevance 0%]
* error when installing 1.7.0.1: "ImportError: No module named distutils.core"
@ 2010-03-01 14:40 8% Oliver Kullmann
2010-03-01 15:15 0% ` Tay Ray Chuan
2010-03-01 16:15 0% ` Todd Zullinger
0 siblings, 2 replies; 24+ results
From: Oliver Kullmann @ 2010-03-01 14:40 UTC (permalink / raw)
To: git
Hello,
I've installed 1.6.6.2, but now when
installing 1.7.0.1 (same machine) I get
make[3]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Git/git-1.7.0.1/perl'
make[2]: Leaving directory `/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Git/git-1.7.0.1/perl'
make[2]: Entering directory `/home/csoliver/SAT-Algorithmen/OKplatform/ExternalSources/builds/Git/git-1.7.0.1/git_remote_helpers'
Traceback (most recent call last):
File "setup.py", line 5, in ?
from distutils.core import setup
ImportError: No module named distutils.core
I'm using
make configure
sh ./configure --prefix=InstallDir
make all
I've checked the README and INSTALL file, but I don't see that there are new
requirements? (That is not regarding doc.)
Oliver
^ permalink raw reply [relevance 8%]
* [ANNOUNCE] Git 1.7.0.1
@ 2010-03-01 9:08 14% Junio C Hamano
0 siblings, 0 replies; 24+ results
From: Junio C Hamano @ 2010-03-01 9:08 UTC (permalink / raw)
To: git
The latest maintenance release Git 1.7.0.1 is available at the
usual places:
http://www.kernel.org/pub/software/scm/git/
git-1.7.0.1.tar.{gz,bz2} (source tarball)
git-htmldocs-1.7.0.1.tar.{gz,bz2} (preformatted docs)
git-manpages-1.7.0.1.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
RPMS/$arch/git-*-1.7.0.1-1.fc11.$arch.rpm (RPM)
Git v1.7.0.1 Release Notes
==========================
Fixes since v1.7.0
------------------
* In a freshly created repository "rev-parse HEAD^0" complained that
it is dangling symref, even though "rev-parse HEAD" didn't.
* "git show :no-such-name" tried to access the index without bounds
check, leading to a potential segfault.
* Message from "git cherry-pick" was harder to read and use than necessary
when it stopped due to conflicting changes.
* We referred to ".git/refs/" throughout the documentation when we
meant to talk about abstract notion of "ref namespace". Because
people's repositories often have packed refs these days, this was
confusing.
* "git diff --output=/path/that/cannot/be/written" did not correctly
error out.
* "git grep -e -pattern-that-begin-with-dash paths..." could not be
spelled as "git grep -- -pattern-that-begin-with-dash paths..." which
would be a GNU way to use "--" as "end of options".
* "git grep" compiled with threading support tried to access an
uninitialized mutex on boxes with a single CPU.
* "git stash pop -q --index" failed because the unnecessary --index
option was propagated to "git stash drop" that is internally run at the
end.
And other minor fixes and documentation updates.
----------------------------------------------------------------
Changes since v1.7.0 are as follows:
Bert Wesarg (2):
Documentation: mention conflict marker size argument (%L) for merge driver
rerere: fix memory leak if rerere images can't be read
Evan Powers (1):
git-p4: fix bug in symlink handling
Jacob Helwig (1):
Documentation: Fix indentation problem in git-commit(1)
Jeff King (9):
accept "git grep -- pattern"
cherry-pick: rewrap advice message
cherry-pick: refactor commit parsing code
cherry-pick: format help message as strbuf
cherry-pick: show commit name instead of sha1
cherry-pick: prettify the advice message
dwim_ref: fix dangling symref warning
docs: don't talk about $GIT_DIR/refs/ everywhere
rm: fix bug in recursive subdirectory removal
Johannes Sixt (1):
t3301-notes: insert a shbang line in ./fake_editor.sh
Jonathan Nieder (1):
am: remove rebase-apply directory before gc
Junio C Hamano (6):
Typofixes outside documentation area
Start 1.7.0 maintenance track
Fix use of mutex in threaded grep
Prepare 1.7.0.1 release notes
Update 1.7.0.1 release notes
Git 1.7.0.1
Larry D'Anna (1):
diff: make sure --output=/bad/path is caught
Mark Lodato (2):
grep documentation: clarify what files match
Remove reference to GREP_COLORS from documentation
Markus Heidelberg (1):
sha1_name: fix segfault caused by invalid index access
Matt Kraai (1):
commit: quote the user name in the example
Pete Harlan (1):
Remove hyphen from "git-command" in two error messages
René Scharfe (1):
fix minor memory leak in get_tree_entry()
Stephen Boyd (1):
Documentation: describe --thin more accurately
Thomas Rast (2):
stash pop: remove 'apply' options during 'drop' invocation
t1450: fix testcases that were wrongly expecting failure
^ permalink raw reply [relevance 14%]
Results 1-24 of 24 | reverse | options above
-- pct% links below jump to the message on this page, permalinks otherwise --
2010-03-01 9:08 14% [ANNOUNCE] Git 1.7.0.1 Junio C Hamano
2010-03-01 14:40 8% error when installing 1.7.0.1: "ImportError: No module named distutils.core" Oliver Kullmann
2010-03-01 15:15 0% ` Tay Ray Chuan
2010-03-01 16:15 0% ` Todd Zullinger
2010-03-01 17:04 0% Oliver Kullmann
2010-03-03 21:07 git svn fetch gives Index mismatch Felix Möller
2010-03-03 21:18 ` Andrew Myrick
2010-03-03 22:12 5% ` Felix Möller
2010-03-05 8:55 7% gitignore broken in git 1.7.0.1: slash checks leading dirs Jiri Slaby
2010-03-05 9:05 7% ` Johannes Sixt
2010-03-05 9:07 7% ` Jiri Slaby
2010-03-05 9:16 7% ` Johannes Sixt
2010-03-05 9:29 7% ` Jiri Slaby
2010-03-05 17:25 7% ` Jonathan Nieder
2010-03-05 19:30 7% ` Jiri Slaby
2010-03-05 15:12 5% ` Jonathan Nieder
2010-03-05 15:15 7% ` Jonathan Nieder
2010-03-05 15:34 7% ` Johannes Sixt
2010-03-05 17:01 7% ` Junio C Hamano
2010-03-06 22:24 5% git-http-backend: hook output not delivered to client BJ Hargrave
2010-03-06 22:30 0% ` Shawn O. Pearce
2010-03-06 22:53 0% ` BJ Hargrave
2010-03-08 20:07 5% git-rebase -i prunes commits with empty commit-message Erik Faye-Lund
2010-03-09 20:26 5% Modified files directly after clone Benedikt Andreas Koeppel
2010-03-22 6:52 4% git clone over smart-http hanging for just one repo Brady Catherman
2010-04-17 23:13 5% git gui blame: git-blame loops at 100% cpu Konrad Karl
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).