* 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
* Re: install does not obey DESTDIR or --prefix for perl modules
From: Brandon Casey @ 2009-09-22 14:52 UTC (permalink / raw)
To: c; +Cc: git
In-Reply-To: <20090922113151.GO8173@gryning.com>
Craig Taylor wrote:
> 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
I have not been able to reproduce your problem on Solaris. The DESTDIR
feature is working for me.
Possibly it is related to the version of MakeMaker? I am using version
6.17 (Revision: 1.133) along with Perl 5.8.4 on Solaris 10 x86. The
MakeMaker version should be in the header at the top of the perl.mak
file.
The perl.mak snippet that you provided above looks different than mine.
In mine, in the vicinity of the 'PREFIX = ' line I also have a
'DESTDIR = ' line. The right hand side of 'DESTDIR = ' is empty even
when I specify a DESTDIR on the make command line.
Here's a snippet from my perl.mak file:
DESTDIR =
PREFIX = /usr/local/git-1.6.4.4
PERLPREFIX = $(PREFIX)
SITEPREFIX = $(PREFIX)
VENDORPREFIX = $(PREFIX)
INSTALLPRIVLIB = $(PERLPREFIX)/lib
DESTINSTALLPRIVLIB = $(DESTDIR)$(INSTALLPRIVLIB)
INSTALLSITELIB = $(SITEPREFIX)/lib/site_perl
DESTINSTALLSITELIB = $(DESTDIR)$(INSTALLSITELIB)
INSTALLVENDORLIB = $(VENDORPREFIX)/lib
DESTINSTALLVENDORLIB = $(DESTDIR)$(INSTALLVENDORLIB)
INSTALLARCHLIB = $(PERLPREFIX)/lib/i86pc-solaris-64int
DESTINSTALLARCHLIB = $(DESTDIR)$(INSTALLARCHLIB)
Notice the variable assignments that begin with 'DEST'. Does your
perl.mak file have those? If not, then it seems MakeMaker is not
producing them for some reason.
Did you try Junio's patch? If the version of MakeMaker is the problem,
then perhaps setting NO_PERL_MAKER=1 on the make command line along
with Junio's patch is the best way forward for you.
-brandon
^ permalink raw reply
* [PATCH RESEND] git submodule add: make the <path> parameter optional
From: Jens Lehmann @ 2009-09-22 15:10 UTC (permalink / raw)
To: Lars Hjemli; +Cc: Junio C Hamano, git
When <path> is not given, use the "humanish" part of the source repository
instead.
Signed-off-by: Jens Lehmann <Jens.Lehmann@web.de>
---
With this patch, git submodule add behaves like git clone in this respect.
Didn't get a response the last weeks, so here is a resend.
Documentation/git-submodule.txt | 8 ++++++--
git-submodule.sh | 7 ++++++-
t/t7400-submodule-basic.sh | 16 ++++++++++++++++
3 files changed, 28 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-submodule.txt b/Documentation/git-submodule.txt
index 5ccdd18..4ef70c4 100644
--- a/Documentation/git-submodule.txt
+++ b/Documentation/git-submodule.txt
@@ -10,7 +10,7 @@ SYNOPSIS
--------
[verse]
'git submodule' [--quiet] add [-b branch]
- [--reference <repository>] [--] <repository> <path>
+ [--reference <repository>] [--] <repository> [<path>]
'git submodule' [--quiet] status [--cached] [--recursive] [--] [<path>...]
'git submodule' [--quiet] init [--] [<path>...]
'git submodule' [--quiet] update [--init] [-N|--no-fetch] [--rebase]
@@ -69,7 +69,11 @@ add::
to the changeset to be committed next to the current
project: the current project is termed the "superproject".
+
-This requires two arguments: <repository> and <path>.
+This requires at least one argument: <repository>. The optional
+argument <path> is the relative location for the cloned submodule
+to exist in the superproject. If <path> is not given, the
+"humanish" part of the source repository is used ("repo" for
+"/path/to/repo.git" and "foo" for "host.xz:foo/.git").
+
<repository> is the URL of the new submodule's origin repository.
This may be either an absolute URL, or (if it begins with ./
diff --git a/git-submodule.sh b/git-submodule.sh
index bfbd36b..0c617eb 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -5,7 +5,7 @@
# Copyright (c) 2007 Lars Hjemli
dashless=$(basename "$0" | sed -e 's/-/ /')
-USAGE="[--quiet] add [-b branch] [--reference <repository>] [--] <repository> <path>
+USAGE="[--quiet] add [-b branch] [--reference <repository>] [--] <repository> [<path>]
or: $dashless [--quiet] status [--cached] [--recursive] [--] [<path>...]
or: $dashless [--quiet] init [--] [<path>...]
or: $dashless [--quiet] update [--init] [-N|--no-fetch] [--rebase] [--reference <repository>] [--merge] [--recursive] [--] [<path>...]
@@ -160,6 +160,11 @@ cmd_add()
repo=$1
path=$2
+ if test -z "$path"; then
+ path=$(echo "$repo" |
+ sed -e 's|/$||' -e 's|:*/*\.git$||' -e 's|.*[/:]||g')
+ fi
+
if test -z "$repo" -o -z "$path"; then
usage
fi
diff --git a/t/t7400-submodule-basic.sh b/t/t7400-submodule-basic.sh
index 0f2ccc6..a0cc99a 100755
--- a/t/t7400-submodule-basic.sh
+++ b/t/t7400-submodule-basic.sh
@@ -306,4 +306,20 @@ test_expect_success 'submodule <invalid-path> warns' '
'
+test_expect_success 'add submodules without specifying an explicit path' '
+ mkdir repo &&
+ cd repo &&
+ git init &&
+ echo r >r &&
+ git add r &&
+ git commit -m "repo commit 1" &&
+ cd .. &&
+ git clone --bare repo/ bare.git &&
+ cd addtest &&
+ git submodule add "$submodurl/repo" &&
+ git config -f .gitmodules submodule.repo.path repo &&
+ git submodule add "$submodurl/bare.git" &&
+ git config -f .gitmodules submodule.bare.path bare
+'
+
test_done
--
1.6.4.1.246.g7bae7.dirty
^ permalink raw reply related
* Re: install does not obey DESTDIR or --prefix for perl modules
From: Brandon Casey @ 2009-09-22 15:16 UTC (permalink / raw)
To: c; +Cc: git, Junio C Hamano
In-Reply-To: <20090922115542.GP8173@gryning.com>
c^ wrote:
> 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.
Craig, you're referring to _your_ last change where you hand modified the
perl.mak file so that the 'PREFIX =' line contained $(DESTDIR) right? And
not something in the above patch?
Junio, your patch looks good and seems to work for me.
-brandon
ps. Craig, it's best to hit 'Reply-All' when replying so that everyone is kept
in the cc list. People often filter their mail based on the 'To:' and 'cc:'
fields and are more likely to notice mail that includes their address in one
of those fields. I added Junio back to this reply.
^ permalink raw reply
* Re: install does not obey DESTDIR or --prefix for perl modules
From: Brandon Casey @ 2009-09-22 15:21 UTC (permalink / raw)
To: c; +Cc: git
In-Reply-To: <Hfm4AdtlXpMutgmdj0vm7yb0ucfu_cijUloasBDWh6NfRCwLhP4OCA@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> Did you try Junio's patch? If the version of MakeMaker is the problem,
> then perhaps setting NO_PERL_MAKER=1 on the make command line along
^^^^^^^^^^^^^
Should be NO_PERL_MAKEMAKER=1
^ permalink raw reply
* Re: Big project, slow access!
From: R. Tyler Ballance @ 2009-09-22 15:22 UTC (permalink / raw)
To: Toan Pham; +Cc: git
In-Reply-To: <ffb2c0280909220751r79946d76x3b23b146077781f5@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 3523 bytes --]
On Tue, 22 Sep 2009, Toan Pham wrote:
> 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?
This wholly depends on how your project laid out, for example, if your
sub-repositories are on different project timelines (shared components
come to mind) where you would want to update that submodule's HEAD in
the super-project. It's worth making sure you're aware of what you're
getting yourself into with git-submodule(1) before you dive in and start
splitting your project into submodules:
http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#submodules
http://github.com/guides/developing-with-submodules
You could also look at using submodules and Android's repo command:
http://source.android.com/download/using-repo
> >>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.
This was tongue-in-cheek, I can't afford an SSD in my laptop just yet ;)
Cheers
> 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.
> >
-R. Tyler Ballance
Slide, Inc.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: [PATCH 4/4] bash: teach 'git checkout' options
From: Shawn O. Pearce @ 2009-09-22 15:28 UTC (permalink / raw)
To: SZEDER G??bor; +Cc: git, Junio C Hamano
In-Reply-To: <7c8c4f6a4c581bcba101b8ca467d241738aa376e.1253009868.git.szeder@ira.uka.de>
SZEDER G??bor <szeder@ira.uka.de> wrote:
> @@ -809,7 +809,18 @@ _git_checkout ()
> {
> __git_has_doubledash && return
>
> - __gitcomp "$(__git_refs)"
> + local cur="${COMP_WORDS[COMP_CWORD]}"
> + case "$cur" in
> + --*)
> + __gitcomp "
> + --quiet --ours --theirs --track --no-track --merge
> + --conflict= --patch
If we are completing long options, shouldn't we also complete the
supported values for --conflict? According to the docs, this is
'merge' and 'diff3'.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 3/4] bash: teach 'git reset --patch'
From: Shawn O. Pearce @ 2009-09-22 15:29 UTC (permalink / raw)
To: SZEDER G??bor; +Cc: git, Junio C Hamano
In-Reply-To: <ccf129a01115027ee7438ac47f1bc35631a1b2bb.1253009868.git.szeder@ira.uka.de>
SZEDER G??bor <szeder@ira.uka.de> wrote:
> Signed-off-by: SZEDER G??bor <szeder@ira.uka.de>
> ---
> contrib/completion/git-completion.bash | 2 +-
> 1 files changed, 1 insertions(+), 1 deletions(-)
1-3 of this series are:
Trivially-acked-by: Shawn O. Pearce <spearce@spearce.org>
--
Shawn.
^ permalink raw reply
* Re: thoughts on a possible "pre-upload" hook
From: Randal L. Schwartz @ 2009-09-22 16:00 UTC (permalink / raw)
To: Sitaram Chamarty; +Cc: git
In-Reply-To: <2e24e5b90909220320rbd5fd1l40c7898656445232@mail.gmail.com>
>>>>> "Sitaram" == Sitaram Chamarty <sitaramc@gmail.com> writes:
Sitaram> Hello,
Sitaram> As git is used more and more in corporate-type environments, at some
Sitaram> point it becomes convenient to have *branches* (or more accurately,
Sitaram> refs) that are not readable. The simplest way to do this (from git's
Sitaram> point of view) is to allow a "pre-upload" hook, rather like the
Sitaram> "pre-receive" hook or "update" hook.
It would seem that you would need to do this even before the commit. So
you're looking for the pre-commit hook. Otherwise, the commit is invalid,
because it doesn't accurately represent everything it references. And the
commit is the unit of transfer between repos.
--
Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095
<merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/>
Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc.
See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
^ permalink raw reply
* gitk management of git diff-tree processes
From: David Holmer @ 2009-09-22 15:10 UTC (permalink / raw)
To: git
I find that if I am in gitk browsing through commits, gitk seems to be
spawning a git diff-tree process in order to display the changes and
patch file list in the bottom panes.
I have a certain commit that adds a very large amount of data to my
repository (1.2 GB). Understandably, the git diff-tree process that
tries to display the changes in this commit takes a VERY long time to
run (e.g. churns indefinitely).
The issue is that I find that if I simply browse past this commit (e.g.
using up/down arrows), gitk starts up a git diff-tree process and leaves
it running. As many times as I pass the commit (e.g. while looking at
changes before and after this commit), I end up with multiple processes
all running and my CPUs quickly go to 100%. Furthermore, even if I exit
gitk, all the git diff-tree processes keep running unless I manually
kill them.
Perhaps gitk could kill the git diff-tree process it spawns if its
output is no longer needed (e.g. user browses to a different commit, or
gitk exits).
Thank you,
David
$ ps -aF
UID PID PPID C SZ RSS PSR STIME TTY TIME CMD
david 23635 1 18 88365 102892 0 10:49 pts/1 00:01:11 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
david 23640 1 18 88368 102908 1 10:49 pts/1 00:01:10 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
david 23644 1 16 88368 102904 0 10:49 pts/1 00:01:04 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
david 23646 1 16 88367 102916 0 10:49 pts/1 00:01:04 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
david 23652 1 17 88365 102892 1 10:49 pts/1 00:01:07 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
david 23656 1 17 88368 102920 1 10:49 pts/1 00:01:06 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
david 23660 1 16 88369 102932 0 10:49 pts/1 00:01:03 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
david 23664 1 16 88368 102908 0 10:49 pts/1 00:01:03 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
david 23670 1 16 88368 102904 1 10:49 pts/1 00:01:03 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
david 23680 1 17 88365 102896 1 10:49 pts/1 00:01:05 git diff-tree -r -p --textconv -C --cc --no-commit-id -U3 8df50645c4cadf26dc951540e0c713b0826247b8
david 23851 10444 0 692 1032 0 10:56 pts/1 00:00:00 ps -aF
$ git version
git version 1.6.4.4
--
David G. Holmer, Ph.D.
dholmer@persistentsystems.com
CTO and Co-Founder
Persistent Systems, LLC
www.persistentsystems.com
Office: 212-561-5895
Mobile: 650-533-4964
Fax: 212-202-3625
^ permalink raw reply
* Re: thoughts on a possible "pre-upload" hook
From: Matthieu Moy @ 2009-09-22 16:05 UTC (permalink / raw)
To: Randal L. Schwartz; +Cc: Sitaram Chamarty, git
In-Reply-To: <867hvr2cms.fsf@blue.stonehenge.com>
merlyn@stonehenge.com (Randal L. Schwartz) writes:
>>>>>> "Sitaram" == Sitaram Chamarty <sitaramc@gmail.com> writes:
>
> Sitaram> Hello,
> Sitaram> As git is used more and more in corporate-type environments, at some
> Sitaram> point it becomes convenient to have *branches* (or more accurately,
> Sitaram> refs) that are not readable. The simplest way to do this (from git's
> Sitaram> point of view) is to allow a "pre-upload" hook, rather like the
> Sitaram> "pre-receive" hook or "update" hook.
>
> It would seem that you would need to do this even before the commit. So
> you're looking for the pre-commit hook. Otherwise, the commit is invalid,
> because it doesn't accurately represent everything it references. And the
> commit is the unit of transfer between repos.
I don't get the point. The OP's question is not about commiting, but
about preventing a branch from being fetched. So, right before sending
the commits in a branch, the server would execute a hook, and fail if
it's not allowed.
But that alone would make it rather painfull for the user : "git
clone" would fail if any branch in the repository is not readable, for
example.
Also, don't forget that branches are just references, which means that
if you prevent reference A from being uploaded, then another reference
B may point to the same commits as A, and then you can bypass the
safety hook on A by using B.
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] builtin-mailinfo.c: Trim only first pair of square brackets in subject
From: Junio C Hamano @ 2009-09-22 16:15 UTC (permalink / raw)
To: Neil Roberts; +Cc: git
In-Reply-To: <87hbuv5km2.fsf@janet.wally>
Neil Roberts <bpeeluk@yahoo.co.uk> writes:
> 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?
I do not think it is likely to happen for a patch without much comments
nor progress after this long blank period, without a refresher discussion.
It definitely won't be applied silently in its original form, especially
because the final comment in the old discussion on the patch in question
began with "One could _update_ ..." from the author of the patch, and then
nothing happened.
http://thread.gmane.org/gmane.comp.version-control.git/122418/focus=122466
I actually liked the much simpler one by Andreas in the original thread,
but if you really want to use a regexp (which we didn't have to) we should
make it configurable. See the neighbouring discussion here as well.
http://thread.gmane.org/gmane.comp.version-control.git/123322
I think we all agree that the behaviour should be improved, but I think
neither Roger's patch nor Andreas's one was the solution.. People who
care need to carry discussions and proposed patches forward to help us
agree on an acceptable solution.
^ 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