* Re: [PATCH] Trivial fix: Display a more friendly message with git-shell.
From: Thiago Farina @ 2009-09-21 20:45 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Johannes Sixt, git
In-Reply-To: <vpqeiq0ssn7.fsf@bauges.imag.fr>
Hi Matthieu
On Mon, Sep 21, 2009 at 3:45 AM, Matthieu Moy
<Matthieu.Moy@grenoble-inp.fr> wrote:
> Perhaps one more line saying what 'man git-shell' says in addition
> would help:
>
> $ git-shell
> git-shell: Restricted login shell for GIT-only SSH access
> Usage: ...
I added this line to the output usage, but would be good to show the
commands that git-shell accept too?
^ permalink raw reply
* Re: [msysGit] Issue 332 in msysgit: .gitattributes dir/ patterns are not processed
From: Heiko Voigt @ 2009-09-21 21:39 UTC (permalink / raw)
To: git; +Cc: msysgit
In-Reply-To: <001636d33903a05b960474181c0a@google.com>
On Mon, Sep 21, 2009 at 03:26:55PM +0000, codesite-noreply@google.com wrote:
> New issue 332 by vsuvo...@geolearning.com: .gitattributes dir/ patterns are
> not processed
> http://code.google.com/p/msysgit/issues/detail?id=332
>
> What steps will reproduce the problem?
> 1. Create a project and initialize git:
> md foo
> cd foo
> git init
>
> 2. create subdirectory and a file in it:
> md bar
> echo sample text >bar\testfile.txt
>
> 3. create .gitatributes, add/commit it:
> echo bar/ binary >.gitattributes
> git add .gitattributes
> git commit -m "ground zero"
>
> 4. check bar\testfile.txt
> git check-attr binary bar/testfile.txt
>
> What is the expected output? What do you see instead?
> expected output: "bar/testfile.txt": binary: set
> see instead: "bar/testfile.txt": binary: unspecified
This issue came up on the msysgit bug tracker. So here is either the
documentation wrong or the implementation.
Because it does not make sense to specify any attributes to directories
itself I would expect the contents of the directory to get the
attributes.
What do you think?
cheers Heiko
^ permalink raw reply
* Re: [PATCH] Trivial fix: Make all the builtin usage strings to use the same pattern.
From: Thiago Farina @ 2009-09-21 21:39 UTC (permalink / raw)
To: Johannes Sixt; +Cc: git
In-Reply-To: <4AB7A534.2070406@viscovery.net>
On Mon, Sep 21, 2009 at 1:09 PM, Johannes Sixt <j.sixt@viscovery.net> wrote:
> Thiago Farina schrieb:
>> They follow the pattern of file name:
>> File name pattern: builtin-command-name.c
>> Usage string pattern: builtin_command_name_usage
>
> Well, file names are not so constant: every now and then an external
> command is turned into a builtin (and the filename is changed), and we
> have even seen that a builtin was turned into an external command.
> Moreover, some commands are implemented in the same file, for example 'git
> log' and 'git show'. How about naming the variable after the command name?
> E.g.:
>
> command: git cat-file
> variable: git_cat_file_usage
That sounds good, I will follow this pattern in the next patch. So all
existing builtin_command_name_usage will be changed to
git_command_name_usage, command_name_usage to git_command_name_usage,
etc.
^ permalink raw reply
* Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Pat Thoyts @ 2009-09-21 23:56 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Murphy, John, Paul Mackerras, git
In-Reply-To: <4AB7A2E7.5000601@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
>Murphy, John schrieb:
>
>On Windows, 'gitk --all' starts with branch-0797, on Linux it starts with
>branch-0999 aka master.
That script gives me a repository I can test against. thanks.
The start_rev_list function calls parseviewrevs and expands the
arguments into a list of appropriate revision ids. In this case --all
gets expanded to a list of 1000 sha1 ids. This is appended to any
other view arguments and passed to git log on the command line
yielding our error.
git log can accept a --all argument it seems so it looks like we can
just short-circuit the parseviewrevs function when --all is passed in
and return --all instead of expanding the list. The following seems to
work for me with this test repository.
John, if this works for you can you also check that editing and
creating new gitk views on your real repository continues to work ok.
commit 7f289ca8370e5e2f9622a4fbc30b934eb97b984f
Author: Pat Thoyts <patthoyts@users.sourceforge.net>
Date: Tue Sep 22 00:55:50 2009 +0100
Avoid expanding --all when passing arguments to git log.
There is no need to expand --all into a list of all revisions as
git log can accept --all as an argument. This avoids any
command-line
length limitations caused by expanding --all into a list of all
revision ids.
Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
diff --git a/gitk b/gitk
index a0214b7..635b97e 100755
--- a/gitk
+++ b/gitk
@@ -241,6 +241,8 @@ proc parseviewrevs {view revs} {
if {$revs eq {}} {
set revs HEAD
+ } elseif {$revs eq "--all"} {
+ return $revs
}
if {[catch {set ids [eval exec git rev-parse $revs]} err]} {
# we get stdout followed by stderr in $err
--
Pat Thoyts http://www.patthoyts.tk/
PGP fingerprint 2C 6E 98 07 2C 59 C8 97 10 CE 11 E6 04 E0 B9 DD
^ permalink raw reply related
* [PATCH] RelNotes-1.6.5: fix spelling of 'Mozilla'
From: Miklos Vajna @ 2009-09-22 0:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Signed-off-by: Miklos Vajna <vmiklos@frugalware.org>
---
Documentation/RelNotes-1.6.5.txt | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/Documentation/RelNotes-1.6.5.txt b/Documentation/RelNotes-1.6.5.txt
index 25529f7..3c46192 100644
--- a/Documentation/RelNotes-1.6.5.txt
+++ b/Documentation/RelNotes-1.6.5.txt
@@ -46,7 +46,7 @@ Updates since v1.6.4
* On major platforms, the system can be compiled to use with Linus's
block-sha1 implementation of the SHA-1 hash algorithm, which
outperforms the default fallback implementation we borrowed from
- Mozzilla.
+ Mozilla.
* Unnecessary inefficiency in deepening of a shallow repository has
been removed.
--
1.6.4
^ permalink raw reply related
* RE: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Murphy, John @ 2009-09-22 1:23 UTC (permalink / raw)
To: Pat Thoyts, Johannes Sixt; +Cc: Paul Mackerras, git
In-Reply-To: <874oqvc0n3.fsf@users.sourceforge.net>
Pat Thoyts writes:
> John, if this works for you can you also check that editing and
> creating new gitk views on your real repository continues to work ok.
Works like a charm.
I look forward to it coming in a new version of git.
Thank you very much.
^ permalink raw reply
* Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Junio C Hamano @ 2009-09-22 1:39 UTC (permalink / raw)
To: Pat Thoyts; +Cc: Johannes Sixt, Murphy, John, Paul Mackerras, git
In-Reply-To: <874oqvc0n3.fsf@users.sourceforge.net>
Pat Thoyts <patthoyts@users.sourceforge.net> writes:
> commit 7f289ca8370e5e2f9622a4fbc30b934eb97b984f
> Author: Pat Thoyts <patthoyts@users.sourceforge.net>
> Date: Tue Sep 22 00:55:50 2009 +0100
>
> Avoid expanding --all when passing arguments to git log.
> There is no need to expand --all into a list of all revisions as
> git log can accept --all as an argument. This avoids any
> command-line
> length limitations caused by expanding --all into a list of all
> revision ids.
>
> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
>
> diff --git a/gitk b/gitk
> index a0214b7..635b97e 100755
> --- a/gitk
> +++ b/gitk
> @@ -241,6 +241,8 @@ proc parseviewrevs {view revs} {
>
> if {$revs eq {}} {
> set revs HEAD
> + } elseif {$revs eq "--all"} {
> + return $revs
> }
That looks like an ugly hack (aka sweeping the issue under the rug).
What if there are many tags and the user used --tags? Don't you have
exactly the same problem? Likewise, what if $revs were "..master"?
The right approach would be to understand what limit it is busting (it is
not likely to be the command line length limit for this particular "exec",
as it only gets "git" "rev-parse" "--all") first, and then fix that.
> if {[catch {set ids [eval exec git rev-parse $revs]} err]} {
> # we get stdout followed by stderr in $err
^ permalink raw reply
* Re: [PATCH] Re: Gitk --all error when there are more than 797 refs in a repository
From: Junio C Hamano @ 2009-09-22 1:47 UTC (permalink / raw)
To: Junio C Hamano
Cc: Pat Thoyts, Johannes Sixt, Murphy, John, Paul Mackerras, git
In-Reply-To: <7v1vlzvjtg.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Pat Thoyts <patthoyts@users.sourceforge.net> writes:
>
>> commit 7f289ca8370e5e2f9622a4fbc30b934eb97b984f
>> Author: Pat Thoyts <patthoyts@users.sourceforge.net>
>> Date: Tue Sep 22 00:55:50 2009 +0100
>>
>> Avoid expanding --all when passing arguments to git log.
>> There is no need to expand --all into a list of all revisions as
>> git log can accept --all as an argument. This avoids any
>> command-line
>> length limitations caused by expanding --all into a list of all
>> revision ids.
>>
>> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
>>
>> diff --git a/gitk b/gitk
>> index a0214b7..635b97e 100755
>> --- a/gitk
>> +++ b/gitk
>> @@ -241,6 +241,8 @@ proc parseviewrevs {view revs} {
>>
>> if {$revs eq {}} {
>> set revs HEAD
>> + } elseif {$revs eq "--all"} {
>> + return $revs
>> }
>
> That looks like an ugly hack (aka sweeping the issue under the rug).
>
> What if there are many tags and the user used --tags? Don't you have
> exactly the same problem? Likewise, what if $revs were "..master"?
Sorry, I meant "--all --not master" to grab all the topics not merged to
master yet.
But my point still stands.
I do not understand what computed values storedin vposids() and vnegids()
arrays are being used in the other parts of the program that rely on this
function to do what it was asked to do, but if this patch can ever be
correct, a much simpler solution to make this function almost no-op and
always return {} (empty array ret is initialized to) would be an equally
valid fix, no? And my gut feeling tells me that such a change to make
this function a no-op _can't_ be a valid fix.
> The right approach would be to understand what limit it is busting (it is
> not likely to be the command line length limit for this particular "exec",
> as it only gets "git" "rev-parse" "--all") first, and then fix that.
>
>> if {[catch {set ids [eval exec git rev-parse $revs]} err]} {
>> # we get stdout followed by stderr in $err
^ permalink raw reply
* [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Michael Wookey @ 2009-09-22 4:10 UTC (permalink / raw)
To: git
MSVC builds define UNICODE which results in the "WIDE" variation of
Win32 API's being used.
Explicitly use the ANSI variation of the API's for compatibility with
msysgit.
Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
---
compat/mingw.c | 26 +++++++++++++-------------
1 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 6b5b5b2..39be42f 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -135,7 +135,7 @@ int mingw_open (const char *filename, int oflags, ...)
fd = open(filename, oflags, mode);
if (fd < 0 && (oflags & O_CREAT) && errno == EACCES) {
- DWORD attrs = GetFileAttributes(filename);
+ DWORD attrs = GetFileAttributesA(filename);
if (attrs != INVALID_FILE_ATTRIBUTES && (attrs & FILE_ATTRIBUTE_DIRECTORY))
errno = EISDIR;
}
@@ -607,7 +607,7 @@ static char *lookup_prog(const char *dir, const
char *cmd, int isexe, int exe_on
return xstrdup(path);
path[strlen(path)-4] = '\0';
if ((!exe_only || isexe) && access(path, F_OK) == 0)
- if (!(GetFileAttributes(path) & FILE_ATTRIBUTE_DIRECTORY))
+ if (!(GetFileAttributesA(path) & FILE_ATTRIBUTE_DIRECTORY))
return xstrdup(path);
return NULL;
}
@@ -641,14 +641,14 @@ static int env_compare(const void *a, const void *b)
static pid_t mingw_spawnve(const char *cmd, const char **argv, char **env,
int prepend_cmd)
{
- STARTUPINFO si;
+ STARTUPINFOA si;
PROCESS_INFORMATION pi;
struct strbuf envblk, args;
unsigned flags;
BOOL ret;
/* Determine whether or not we are associated to a console */
- HANDLE cons = CreateFile("CONOUT$", GENERIC_WRITE,
+ HANDLE cons = CreateFileA("CONOUT$", GENERIC_WRITE,
FILE_SHARE_WRITE, NULL, OPEN_EXISTING,
FILE_ATTRIBUTE_NORMAL, NULL);
if (cons == INVALID_HANDLE_VALUE) {
@@ -717,7 +717,7 @@ static pid_t mingw_spawnve(const char *cmd, const
char **argv, char **env,
}
memset(&pi, 0, sizeof(pi));
- ret = CreateProcess(cmd, args.buf, NULL, NULL, TRUE, flags,
+ ret = CreateProcessA(cmd, args.buf, NULL, NULL, TRUE, flags,
env ? envblk.buf : NULL, NULL, &si, &pi);
if (env)
@@ -965,23 +965,23 @@ int mingw_rename(const char *pold, const char *pnew)
if (errno != EEXIST)
return -1;
repeat:
- if (MoveFileEx(pold, pnew, MOVEFILE_REPLACE_EXISTING))
+ if (MoveFileExA(pold, pnew, MOVEFILE_REPLACE_EXISTING))
return 0;
/* TODO: translate more errors */
gle = GetLastError();
if (gle == ERROR_ACCESS_DENIED &&
- (attrs = GetFileAttributes(pnew)) != INVALID_FILE_ATTRIBUTES) {
+ (attrs = GetFileAttributesA(pnew)) != INVALID_FILE_ATTRIBUTES) {
if (attrs & FILE_ATTRIBUTE_DIRECTORY) {
errno = EISDIR;
return -1;
}
if ((attrs & FILE_ATTRIBUTE_READONLY) &&
- SetFileAttributes(pnew, attrs & ~FILE_ATTRIBUTE_READONLY)) {
- if (MoveFileEx(pold, pnew, MOVEFILE_REPLACE_EXISTING))
+ SetFileAttributesA(pnew, attrs & ~FILE_ATTRIBUTE_READONLY)) {
+ if (MoveFileExA(pold, pnew, MOVEFILE_REPLACE_EXISTING))
return 0;
gle = GetLastError();
/* revert file attributes on failure */
- SetFileAttributes(pnew, attrs);
+ SetFileAttributesA(pnew, attrs);
}
}
if (tries < ARRAY_SIZE(delay) && gle == ERROR_ACCESS_DENIED) {
@@ -1006,7 +1006,7 @@ struct passwd *getpwuid(int uid)
static struct passwd p;
DWORD len = sizeof(user_name);
- if (!GetUserName(user_name, &len))
+ if (!GetUserNameA(user_name, &len))
return NULL;
p.pw_name = user_name;
p.pw_gecos = "unknown";
@@ -1151,7 +1151,7 @@ void mingw_open_html(const char *unixpath)
{
const char *htmlpath = make_backslash_path(unixpath);
printf("Launching default browser to display HTML ...\n");
- ShellExecute(NULL, "open", htmlpath, NULL, "\\", 0);
+ ShellExecuteA(NULL, "open", htmlpath, NULL, "\\", 0);
}
int link(const char *oldpath, const char *newpath)
@@ -1160,7 +1160,7 @@ int link(const char *oldpath, const char *newpath)
static T create_hard_link = NULL;
if (!create_hard_link) {
create_hard_link = (T) GetProcAddress(
- GetModuleHandle("kernel32.dll"), "CreateHardLinkA");
+ GetModuleHandleA("kernel32.dll"), "CreateHardLinkA");
if (!create_hard_link)
create_hard_link = (T)-1;
}
--
1.6.5.rc1.44.ga1675
^ permalink raw reply related
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Johannes Sixt @ 2009-09-22 6:08 UTC (permalink / raw)
To: Michael Wookey, Marius Storm-Olsen; +Cc: git
In-Reply-To: <d2e97e800909212110w423e3b2fm85ac6f76439e0591@mail.gmail.com>
Michael Wookey schrieb:
> MSVC builds define UNICODE which results in the "WIDE" variation of
> Win32 API's being used.
>
> Explicitly use the ANSI variation of the API's for compatibility with
> msysgit.
>
> Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
Marius,
I would like to understand why you did not have this issue.
The patch itself looks fine.
-- Hannes
^ permalink raw reply
* Re: Cygwin git dies silently
From: Clemens Buchacher @ 2009-09-22 7:08 UTC (permalink / raw)
To: John Ousterhout; +Cc: git
In-Reply-To: <33D78C6C5C9F45379BC3C07BD3017260@ouster>
[re-adding the list to Cc for future reference]
On Mon, Sep 21, 2009 at 03:37:43PM -0700, John Ousterhout wrote:
> your message eventually led me to the problem, which
> is that somehow I didn't have libz installed. Once I installed libz
> git is now working.
I'm surprised that cygwin did not take care of installing the dependencies
for you. After all, you were installing the version "that came with cygwin"?
If that is the case, please file a bug report with cygwin, because it's
clearly a problem with their packaging.
Thanks,
Clemens
^ permalink raw reply
* Re: [PATCH] Trivial fix: Display a more friendly message with git-shell.
From: Matthieu Moy @ 2009-09-22 7:28 UTC (permalink / raw)
To: Thiago Farina; +Cc: Johannes Sixt, git
In-Reply-To: <a4c8a6d00909211345q593e673bo4964204afa5ce807@mail.gmail.com>
Thiago Farina <tfransosi@gmail.com> writes:
> Hi Matthieu
> On Mon, Sep 21, 2009 at 3:45 AM, Matthieu Moy
> <Matthieu.Moy@grenoble-inp.fr> wrote:
>> Perhaps one more line saying what 'man git-shell' says in addition
>> would help:
>>
>> $ git-shell
>> git-shell: Restricted login shell for GIT-only SSH access
>> Usage: ...
> I added this line to the output usage, but would be good to show the
> commands that git-shell accept too?
Well, at some point, I think the user will have to read the man page.
I find it better to have a non-agressive error message, but I'm not
sure it's relevant to try to give the complete manual here.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Marius Storm-Olsen @ 2009-09-22 7:23 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Michael Wookey, Marius Storm-Olsen, git
In-Reply-To: <4AB869EE.1020200@viscovery.net>
Johannes Sixt said the following on 22.09.2009 08:08:
> Michael Wookey schrieb:
>> MSVC builds define UNICODE which results in the "WIDE" variation of
>> Win32 API's being used.
>>
>> Explicitly use the ANSI variation of the API's for compatibility with
>> msysgit.
>>
>> Signed-off-by: Michael Wookey <michaelwookey@gmail.com>
>
> Marius,
>
> I would like to understand why you did not have this issue.
>
> The patch itself looks fine.
I never added the UNICODE define to the Git compile
process with MSVC (Check the Makefile), so then the
windows API should use the ANSI version by default.
And the following patch proved my point (sorry, will
probably wrap):
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1201,6 +1201,12 @@ struct mingw_DIR
char dd_name[1]; /* given path for dir with search pattern (struct is extended) */
};
+#ifdef UNICODE
+#pragma message("We have UNICODE defined")
+#else
+#pragma message("Nope, UNICODE is not defined here")
+#endif
+
struct dirent *mingw_readdir(DIR *dir)
{
WIN32_FIND_DATAA buf;
> make MSVC=1
CC compat/msvc.o
msvc.c
d:\msvc\git\compat\mingw.c(223) : warning C4133: 'function' : incompatible types - from '_stati64 *' to '_stat64 *'
d:\msvc\git\compat\mingw.c(636) : warning C4090: 'initializing' : different 'const' qualifiers
d:\msvc\git\compat\mingw.c(637) : warning C4090: 'initializing' : different 'const' qualifiers
d:\msvc\git\compat\mingw.c(787) : warning C4090: 'function' : different 'const' qualifiers
d:\msvc\git\compat\mingw.c(797) : warning C4090: 'function' : different 'const' qualifiers
Nope, UNICODE is not defined here
AR libgit.a
Microsoft (R) Library Manager Version 9.00.21022.08
Copyright (C) Microsoft Corporation. All rights reserved.
Michael, how are you trying to compile git? With the IDE or
the GNU Make? Which version of MSVC? If you use the IDE, can
you make sure it doesn't contain the UNICODE define in the
compiler section of the properties of the projects?
In general though, I'm ok with patches which specifies the
correct API, so we won't have the problem, should we decide
to add UNICODE in the future.
--
.marius
^ permalink raw reply
* Re: Re: [PATCH] Trivial fix: Display a more friendly message with git-shell.
From: Heiko Voigt @ 2009-09-22 8:15 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Thiago Farina, Johannes Sixt, git
In-Reply-To: <vpqr5tzqvzm.fsf@bauges.imag.fr>
On Tue, Sep 22, 2009 at 09:28:13AM +0200, Matthieu Moy wrote:
> Thiago Farina <tfransosi@gmail.com> writes:
>
> > On Mon, Sep 21, 2009 at 3:45 AM, Matthieu Moy
> > <Matthieu.Moy@grenoble-inp.fr> wrote:
> >> $ git-shell
> >> git-shell: Restricted login shell for GIT-only SSH access
> >> Usage: ...
> > I added this line to the output usage, but would be good to show the
> > commands that git-shell accept too?
>
> Well, at some point, I think the user will have to read the man page.
> I find it better to have a non-agressive error message, but I'm not
> sure it's relevant to try to give the complete manual here.
Why not simply like this? I liked the old output as well. And sometimes its
just better to have commands behave like humans ;)
diff --git a/shell.c b/shell.c
index e4864e0..a0da191 100644
--- a/shell.c
+++ b/shell.c
@@ -74,7 +74,8 @@ int main(int argc, char **argv)
* where "cmd" is a very limited subset of git commands.
*/
else if (argc != 3 || strcmp(argv[1], "-c"))
- die("What do you think I am? A shell?");
+ die("What do you think I am? A shell?\n\
+ See: git help shell");
prog = argv[2];
if (!strncmp(prog, "git", 3) && isspace(prog[3]))
^ permalink raw reply related
* Re: [PATCH] Trivial fix: Display a more friendly message with git-shell.
From: Jakub Narebski @ 2009-09-22 8:17 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Thiago Farina, Johannes Sixt, git
In-Reply-To: <vpqr5tzqvzm.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Thiago Farina <tfransosi@gmail.com> writes:
>
>> Hi Matthieu
>> On Mon, Sep 21, 2009 at 3:45 AM, Matthieu Moy
>> <Matthieu.Moy@grenoble-inp.fr> wrote:
>>> Perhaps one more line saying what 'man git-shell' says in addition
>>> would help:
>>>
>>> $ git-shell
>>> git-shell: Restricted login shell for GIT-only SSH access
>>> Usage: ...
>> I added this line to the output usage, but would be good to show the
>> commands that git-shell accept too?
>
> Well, at some point, I think the user will have to read the man page.
> I find it better to have a non-agressive error message, but I'm not
> sure it's relevant to try to give the complete manual here.
Perhaps:
$ git-shell
git-shell: Restricted login shell for GIT-only SSH access
This shell cannot be used as a login (interactive) shell
and/or
$ ssh user@repo.example.com
This user is restricted to GIT-only SSH access
(or something like that, especially in the second case).
I don't think giving 'Usage:' here would be a good idea, as this
program is not meant for end user, but for automatic use.
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Michael Wookey @ 2009-09-22 9:17 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Sixt, git
In-Reply-To: <4AB87B6B.1070808@gmail.com>
2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
> Michael, how are you trying to compile git? With the IDE or
> the GNU Make? Which version of MSVC? If you use the IDE, can
> you make sure it doesn't contain the UNICODE define in the
> compiler section of the properties of the projects?
I'm using the VS 2008 Professional IDE (the solution doesn't open in
VS 2005). I made no changes to the build settings. In the Preprocessor
section of the project, UNICODE is defined.
On another note, I see *many* build warnings for things like
"signed/unsigned compares". I'd be willing to work through these
warnings and fix them. Thoughts?
^ permalink raw reply
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Marius Storm-Olsen @ 2009-09-22 9:40 UTC (permalink / raw)
To: Michael Wookey; +Cc: Johannes Sixt, git
In-Reply-To: <d2e97e800909220217y5bda4698pc286711a3535f87d@mail.gmail.com>
Michael Wookey said the following on 22.09.2009 11:17:
> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>> Michael, how are you trying to compile git? With the IDE or the
>> GNU Make? Which version of MSVC? If you use the IDE, can you make
>> sure it doesn't contain the UNICODE define in the compiler
>> section of the properties of the projects?
>
> I'm using the VS 2008 Professional IDE (the solution doesn't open
> in VS 2005). I made no changes to the build settings. In the
> Preprocessor section of the project, UNICODE is defined.
Were these projects generated with the Vcproj generator in
contrib/buildsystem, with the Qmake generator, or the projects from
Frank's repo?
> On another note, I see *many* build warnings for things like
> "signed/unsigned compares". I'd be willing to work through these
> warnings and fix them. Thoughts?
Well, first find out why these are a problem with MSVC and not GCC.
Are the types different on these platforms? signed vs unsigned should
show up with GCC as well. We need to make sure that we don't fix
signed/unsigned issues on one platform, just to introduce it to
another platform.
In any case, it would be good for someone to have a look at these,
just so we can determine the cause for most of them, and then we
should figure out on the list how to deal with them.
Just my €0.2..
--
.marius
^ permalink raw reply
* Re: [PATCH] compat/mingw.c: MSVC build must use ANSI Win32 API's
From: Michael Wookey @ 2009-09-22 9:54 UTC (permalink / raw)
To: Marius Storm-Olsen; +Cc: Johannes Sixt, git
In-Reply-To: <4AB89B7F.3050902@gmail.com>
2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
> Michael Wookey said the following on 22.09.2009 11:17:
>>
>> 2009/9/22 Marius Storm-Olsen <mstormo@gmail.com>:
>>>
>>> Michael, how are you trying to compile git? With the IDE or the
>>> GNU Make? Which version of MSVC? If you use the IDE, can you make
>>> sure it doesn't contain the UNICODE define in the compiler
>>> section of the properties of the projects?
>>
>> I'm using the VS 2008 Professional IDE (the solution doesn't open
>> in VS 2005). I made no changes to the build settings. In the
>> Preprocessor section of the project, UNICODE is defined.
>
> Were these projects generated with the Vcproj generator in
> contrib/buildsystem, with the Qmake generator, or the projects from Frank's
> repo?
The project was generated from the vcproj generator in
contrib/buildsystem from git.git/master.
>> On another note, I see *many* build warnings for things like
>> "signed/unsigned compares". I'd be willing to work through these warnings
>> and fix them. Thoughts?
>
> Well, first find out why these are a problem with MSVC and not GCC. Are the
> types different on these platforms? signed vs unsigned should show up with
> GCC as well. We need to make sure that we don't fix signed/unsigned issues
> on one platform, just to introduce it to another platform.
> In any case, it would be good for someone to have a look at these, just so
> we can determine the cause for most of them, and then we should figure out
> on the list how to deal with them.
Well, at warning level 4, MSVC is quite verbose. Perhaps the current
gcc build flags are more forgiving?
^ permalink raw reply
* thoughts on a possible "pre-upload" hook
From: Sitaram Chamarty @ 2009-09-22 10:20 UTC (permalink / raw)
To: git
Hello,
As git is used more and more in corporate-type environments, at some
point it becomes convenient to have *branches* (or more accurately,
refs) that are not readable. The simplest way to do this (from git's
point of view) is to allow a "pre-upload" hook, rather like the
"pre-receive" hook or "update" hook.
I don't know the upload pack protocol enough to know whether this is a
stupid idea or not; please tell me if so :-) But things that were
seemingly "impossible" in the early days are being talked about now
and even being implemented so I felt brave enough to ask.
I'm afraid my C programming days are long gone, but if anything can be
done in shell or perl, with a little git.guidance, I'll do whatever I
can.
--
Sitaram
^ permalink raw reply
* Re: [PATCH] builtin-mailinfo.c: Trim only first pair of square brackets in subject
From: Neil Roberts @ 2009-09-22 10:39 UTC (permalink / raw)
To: git
In-Reply-To: <1246310220-16909-1-git-send-email-rleigh@debian.org>
Roger Leigh <rleigh@debian.org> writes:
> Use a regular expression to match text after "Re:" or any text in the
> first pair of square brackets such as "[PATCH n/m]". This replaces
> the complex hairy string munging with a simple single pattern match.
Is this patch going to get applied? We like to use the '[topic]' format
in Clutter¹ because it looks so much nicer than 'topic:' and it would be
really nice not to have to manually fix the commit when a contributor
sends a patch in the same format.
- Neil
[1] http://git.clutter-project.org/cgit.cgi?url=clutter/log/
^ permalink raw reply
* Re: install does not obey DESTDIR or --prefix for perl modules
From: Craig Taylor @ 2009-09-22 11:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Brandon Casey, git
In-Reply-To: <7vocp4ulq2.fsf@alter.siamese.dyndns.org>
On Mon, Sep 21, 2009 at 12:44:05PM -0700, Junio C Hamano wrote:
> Craig Taylor <c@gryning.com> writes:
>
> > Exactly as you describe here, different paths but same goal.
> > All binaries follow the DESTDIR path except the perl modules.
> >
> > To register this as a bug do I need to do more than send this email?
>
> Do you use NO_PERL_MAKEMAKER in your build?
>
> If not, we need to summon an expert on ExtUtils::MakeMaker to look into
> this issue, but if you do, perhaps you can try this patch and report how
> well it works for you.
>
> ---
> perl/Makefile | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/perl/Makefile b/perl/Makefile
> index e3dd1a5..4ab21d6 100644
> --- a/perl/Makefile
> +++ b/perl/Makefile
> @@ -29,11 +29,11 @@ $(makfile): ../GIT-CFLAGS Makefile
> '$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
> echo ' cp private-Error.pm blib/lib/Error.pm' >> $@
> echo install: >> $@
> - echo ' mkdir -p "$(instdir_SQ)"' >> $@
> - echo ' $(RM) "$(instdir_SQ)/Git.pm"; cp Git.pm "$(instdir_SQ)"' >> $@
> - echo ' $(RM) "$(instdir_SQ)/Error.pm"' >> $@
> + echo ' mkdir -p "$$(DESTDIR)$(instdir_SQ)"' >> $@
> + echo ' $(RM) "$$(DESTDIR)$(instdir_SQ)/Git.pm"; cp Git.pm "$$(DESTDIR)$(instdir_SQ)"' >> $@
> + echo ' $(RM) "$$(DESTDIR)$(instdir_SQ)/Error.pm"' >> $@
> '$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
> - echo ' cp private-Error.pm "$(instdir_SQ)/Error.pm"' >> $@
> + echo ' cp private-Error.pm "$$(DESTDIR)$(instdir_SQ)/Error.pm"' >> $@
> echo instlibdir: >> $@
> echo ' echo $(instdir_SQ)' >> $@
> else
ExtUtils::MakeMaker is available and I am using it.
The problem seems to be in the generated perl.mak.
On line 1652 of my git-1.6.4.3/Makefile
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
I see that it is passing DESTDIR to the makefile in git-1.6.4.3/perl.
However, the DESTDIR variable is not seemingly included in perl/perl.mak for
use by the perl/Makefile. It is all absolute paths which I think is the
main cause.
I have manually manipulated the perl.mak file and install works fine.
I'm just updating my build area to 1.6.4.4 and then will try something
more permanent. However I am moving outside my knowldge of 'make' now so
may request assistance later ;)
CraigT
--
c^ [c%5e]
Never talk about your knowledge, it might make it disappear.
^ permalink raw reply
* Re: install does not obey DESTDIR or --prefix for perl modules
From: Craig Taylor @ 2009-09-22 11:31 UTC (permalink / raw)
To: git
In-Reply-To: <7vocp4ulq2.fsf@alter.siamese.dyndns.org>
On Mon, Sep 21, 2009 at 12:44:05PM -0700, Junio C Hamano wrote:
> Craig Taylor <c@gryning.com> writes:
>
> > Exactly as you describe here, different paths but same goal.
> > All binaries follow the DESTDIR path except the perl modules.
> >
> > To register this as a bug do I need to do more than send this email?
>
> Do you use NO_PERL_MAKEMAKER in your build?
>
> If not, we need to summon an expert on ExtUtils::MakeMaker to look into
> this issue, but if you do, perhaps you can try this patch and report how
> well it works for you.
>
> ---
> perl/Makefile | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/perl/Makefile b/perl/Makefile
> index e3dd1a5..4ab21d6 100644
> --- a/perl/Makefile
> +++ b/perl/Makefile
> @@ -29,11 +29,11 @@ $(makfile): ../GIT-CFLAGS Makefile
> '$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
> echo ' cp private-Error.pm blib/lib/Error.pm' >> $@
> echo install: >> $@
> - echo ' mkdir -p "$(instdir_SQ)"' >> $@
> - echo ' $(RM) "$(instdir_SQ)/Git.pm"; cp Git.pm "$(instdir_SQ)"' >> $@
> - echo ' $(RM) "$(instdir_SQ)/Error.pm"' >> $@
> + echo ' mkdir -p "$$(DESTDIR)$(instdir_SQ)"' >> $@
> + echo ' $(RM) "$$(DESTDIR)$(instdir_SQ)/Git.pm"; cp Git.pm "$$(DESTDIR)$(instdir_SQ)"' >> $@
> + echo ' $(RM) "$$(DESTDIR)$(instdir_SQ)/Error.pm"' >> $@
> '$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
> - echo ' cp private-Error.pm "$(instdir_SQ)/Error.pm"' >> $@
> + echo ' cp private-Error.pm "$$(DESTDIR)$(instdir_SQ)/Error.pm"' >> $@
> echo instlibdir: >> $@
> echo ' echo $(instdir_SQ)' >> $@
> else
Further to my last email, modifying the perl.mak file as below resolves
the problem for me to a satisfactory level.
I will have to leave a more permanent solution to someone more familar with
make/makemaker.
--- git-1.6.4.4/perl/perl.mak_to20090922 2009-09-22 12:07:18.000000000 +0100
+++ git-1.6.4.4/perl/perl.mak 2009-09-22 12:21:17.791887000 +0100
@@ -57,7 +57,7 @@
INST_LIB = blib/lib
INST_ARCHLIB = blib/arch
INST_SCRIPT = blib/script
-PREFIX = /usr/local/git-1.6.4.4
+PREFIX = $(DESTDIR)/usr/local/git-1.6.4.4
INSTALLDIRS = site
INSTALLPRIVLIB = $(PREFIX)/lib/5.6.1
INSTALLARCHLIB = $(PREFIX)/lib/5.6.1/sun4-solaris
Many thanks...
CraigT
--
c^ [c%5e]
Failure is natural.
^ permalink raw reply
* Re: install does not obey DESTDIR or --prefix for perl modules
From: c^ @ 2009-09-22 11:55 UTC (permalink / raw)
To: git
In-Reply-To: <7vocp4ulq2.fsf@alter.siamese.dyndns.org>
On Mon, Sep 21, 2009 at 12:44:05PM -0700, Junio C Hamano wrote:
> Craig Taylor <c@gryning.com> writes:
>
> > Exactly as you describe here, different paths but same goal.
> > All binaries follow the DESTDIR path except the perl modules.
> >
> > To register this as a bug do I need to do more than send this email?
>
> Do you use NO_PERL_MAKEMAKER in your build?
>
> If not, we need to summon an expert on ExtUtils::MakeMaker to look into
> this issue, but if you do, perhaps you can try this patch and report how
> well it works for you.
>
> ---
> perl/Makefile | 8 ++++----
> 1 files changed, 4 insertions(+), 4 deletions(-)
>
> diff --git a/perl/Makefile b/perl/Makefile
> index e3dd1a5..4ab21d6 100644
> --- a/perl/Makefile
> +++ b/perl/Makefile
> @@ -29,11 +29,11 @@ $(makfile): ../GIT-CFLAGS Makefile
> '$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
> echo ' cp private-Error.pm blib/lib/Error.pm' >> $@
> echo install: >> $@
> - echo ' mkdir -p "$(instdir_SQ)"' >> $@
> - echo ' $(RM) "$(instdir_SQ)/Git.pm"; cp Git.pm "$(instdir_SQ)"' >> $@
> - echo ' $(RM) "$(instdir_SQ)/Error.pm"' >> $@
> + echo ' mkdir -p "$$(DESTDIR)$(instdir_SQ)"' >> $@
> + echo ' $(RM) "$$(DESTDIR)$(instdir_SQ)/Git.pm"; cp Git.pm "$$(DESTDIR)$(instdir_SQ)"' >> $@
> + echo ' $(RM) "$$(DESTDIR)$(instdir_SQ)/Error.pm"' >> $@
> '$(PERL_PATH_SQ)' -MError -e 'exit($$Error::VERSION < 0.15009)' || \
> - echo ' cp private-Error.pm "$(instdir_SQ)/Error.pm"' >> $@
> + echo ' cp private-Error.pm "$$(DESTDIR)$(instdir_SQ)/Error.pm"' >> $@
> echo instlibdir: >> $@
> echo ' echo $(instdir_SQ)' >> $@
> else
Frustratingly the last change forces the lib referenced in the perl
scripts to include the DESTDIR.
I will work around this for now, but would apprieciate it if someone
more familair could fix for the future.
CraigT
--
c^ [c%5e]
Failure is natural.
^ permalink raw reply
* Re: [PATCH] builtin-mailinfo.c: Improve the regexp for cleaning up the subject
From: Neil Roberts @ 2009-09-22 12:56 UTC (permalink / raw)
To: git
In-Reply-To: <87hbuv5km2.fsf@janet.wally>
Previously the regular expression would remove the first set of square
brackets regardless of what came before it. If a patch with a summary
such as 'Added a[0] to a line' was passed through git-format-patch
with the -k option then the summary would be cropped to 'to a line'
when applied with git-am.
The new regular expression also matches any number of 're:' prefixes
which apparently can be generated by some old mail clients.
The old regexp required that there be at least one set of square
brackets before it would remove the 're:' and this is now fixed.
---
builtin-mailinfo.c | 9 ++++-----
1 files changed, 4 insertions(+), 5 deletions(-)
This patch is meant to apply on top of the two previous patches by
Roger Leigh which are available here:
http://marc.info/?l=git&m=124839483217718&w=2
http://marc.info/?l=git&m=124839483317722&w=2
It fixes some small problems as described above.
diff --git a/builtin-mailinfo.c b/builtin-mailinfo.c
index 7098c90..f5799f1 100644
--- a/builtin-mailinfo.c
+++ b/builtin-mailinfo.c
@@ -227,7 +227,7 @@ static void cleanup_subject(struct strbuf *subject)
/* Strip off 'Re:' and/or the first text in square brackets, such as
'[PATCH]' at the start of the mail Subject. */
status = regcomp(®ex,
- "^([Rr]e:)?([^]]*\\[[^]]+\\])(.*)$",
+ "^([Rr]e:[ \t]*)*(\\[[^]]+\\][ \t]*)?",
REG_EXTENDED);
if (status) {
@@ -248,10 +248,9 @@ static void cleanup_subject(struct strbuf *subject)
/* Store any matches in match. */
status = regexec(®ex, subject->buf, 4, match, 0);
- /* If there was a match for \3 in the regex, trim the subject
- to this match. */
- if (!status && match[3].rm_so > 0) {
- strbuf_remove(subject, 0, match[3].rm_so);
+ /* If there was a match, remove it */
+ if (!status && match[0].rm_so >= 0) {
+ strbuf_remove(subject, 0, match[0].rm_eo);
strbuf_trim(subject);
}
--
1.6.0.4
^ permalink raw reply related
* Re: Big project, slow access!
From: Toan Pham @ 2009-09-22 14:51 UTC (permalink / raw)
To: R. Tyler Ballance, git
In-Reply-To: <20090918213216.GJ18785@starfruit.corp.slide.com>
Dear Tyler
Thank you for your valuable feedback.
I'll research into git-filter-branch and also dividing a big project
into several sub-repositories.
This seems to increase the performance very much; however, there is a
draw-back that I am a little bit
concern with. When we use several sub-repos option, we would probably
do manual book-keeping as to
which repo commits are compatible/built-able with other repo. commits.
How did you manage to track
dependencies and their versions between different depos?
>>i'm waiting for a new fancy SSD to help alleviate my issues.
Please report the performance increase after you tested on your SS Drive.
On Fri, Sep 18, 2009 at 5:32 PM, R. Tyler Ballance <tyler@slide.com> wrote:
>
> On Fri, 18 Sep 2009, Toan Pham wrote:
>
>> Hi,
>>
>> I use git to maintain a project that is at least 8 gigs in size.
>> The project is a Linux from Scratch repository that includes source
>> codes to approximately 2000 open source projects,
>> gcc tool-chain, 1000+ configurations for different software packages,
>> source code for different kernel versions,
>> and many linux distributions/flavors resulted from this LFS build environment.
>>
>> The git's object repository is now 4.6 gigs and consists of approx.
>> 610,000 files and folders.
>> The speed of git is now terribly slow. Each time I use basic commands
>> like 'git status' or 'git diff',
>> it would take at least 5 minutes for git to give me back a result.
>> Again, the machine that i run git on is a P4 3.2 gig-hertz with HT.
>
> Howdy Toan, we have a similarly large repository ~405k files, the .git
> folder fully packed is ~6GB.
>
> The advise to fully-pack your repository is likely going to have the
> greatest impact on your performance in the short term, in the long term
> however you might want to consider using git-filter-branch(1) or other
> tools available to separate our the components of your current Git
> reposotory into a series of repos.
>
> The performance hit you're seeing likely has nothing to do with your
> processor speed either, but rather your disk search speed (i'm waiting
> for a new fancy SSD to help alleviate my issues ;))
>
>> would someone please recommend on how i can optimize git's performance?
>> Git is so slow, are there better ways to manage a project like this?
>
> Rethink how your project is laid out, and whether certain binaries files
> need to sit in the tree, or can be build on a need-by-need basis.
>
>
>
> Cheers
> -R. Tyler Ballance
> Slide, Inc.
>
^ 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