* [PATCH 2/2] t7002: add tests for skip-worktree fixes in commit a67e281
From: Nguyễn Thái Ngọc Duy @ 2010-01-04 12:34 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <7v7hs09tpi.fsf@alter.siamese.dyndns.org>
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
builtin-grep.c | 1 +
t/t7002-grep.sh | 12 ++++++++++++
2 files changed, 13 insertions(+), 0 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index f093b60..59c4b12 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -222,6 +222,7 @@ static int exec_grep(int argc, const char **argv)
int status;
argv[argc] = NULL;
+ trace_argv_printf(argv, "trace: grep:");
pid = fork();
if (pid < 0)
return pid;
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index ffda0df..ac0a658 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -438,4 +438,16 @@ test_expect_success 'grep -Fi' '
test_cmp expected actual
'
+test_expect_success external-grep 'external grep is called' '
+ GIT_TRACE=2 git grep foo >/dev/null 2>actual &&
+ grep "trace: grep:.*foo" actual >/dev/null
+'
+
+test_expect_success external-grep 'no external grep when skip-worktree entries exist' '
+ git update-index --skip-worktree file &&
+ GIT_TRACE=2 git grep foo >/dev/null 2>actual &&
+ ! grep "trace: grep:" actual >/dev/null &&
+ git update-index --no-skip-worktree file
+'
+
test_done
--
1.6.6.315.g1a406
^ permalink raw reply related
* [PATCH 1/2] t7002: set test prerequisite "external-grep" if supported
From: Nguyễn Thái Ngọc Duy @ 2010-01-04 12:34 UTC (permalink / raw)
To: Junio C Hamano, git; +Cc: Nguyễn Thái Ngọc Duy
In-Reply-To: <7v7hs09tpi.fsf@alter.siamese.dyndns.org>
Add another test to set prerequisite "external-grep" if the current
build supports external grep. This can be used to skip external grep
only tests on builds that do not support this optimization.
Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com>
---
t/t7002-grep.sh | 12 ++++++++++++
1 files changed, 12 insertions(+), 0 deletions(-)
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index abd14bf..ffda0df 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -8,6 +8,18 @@ test_description='git grep various.
. ./test-lib.sh
+test_expect_success 'Check for external grep support' '
+ case "$(git grep -h 2>&1|grep ext-grep)" in
+ *"(default)"*)
+ test_set_prereq external-grep
+ true;;
+ *"(ignored by this build)"*)
+ true;;
+ *)
+ false;;
+ esac
+'
+
cat >hello.c <<EOF
#include <stdio.h>
int main(int argc, const char **argv)
--
1.6.6.315.g1a406
^ permalink raw reply related
* Re: Beginner's question on how to use git for multiple parallel versions
From: Bill Lear @ 2010-01-04 13:29 UTC (permalink / raw)
To: Christian C. Schouten; +Cc: git
In-Reply-To: <F8CC469C9CCA415696101414EA997C0.MAI@sohosted19.com>
On Monday, January 4, 2010 at 12:29:52 (+0100) Christian C. Schouten writes:
>Hello all,
>
>I've got a project that I want to do version management on with
>git but being a beginner in cvs/svn/dvcs etc. terminology I
>don't know yet how to set it up. My project needs to exist as
>several parallel copies, i.e. there is a "main version" in
>which I do my development but it needs to end up being available as a
>couple of different configurations. For instance, say there is a file
>table.xml then this needs to contain different rows for versions A and
>B. Likewise, a file process.bpel needs to be named identical for each
>version but contain different content depending on whether it is
>distributed as version A or version B. Any changes made in non-version
>specific files should be visible in all copies, but changes made to
>version-specific files need to remain isolated to that particular
>version.
What you are asking for is this, I think:
% git checkout A
% cat table.xml
<table A>
% echo "<table A v2>" > table.xml
% git commit -a -m "fix table on Branch A"
% git checkout B
% cat table.xml
<table B>
% echo "<table B v2>" > table.xml
% git commit -a -m "fix table on Branch B"
% git checkout master
% cat table.xml
<non-version-specific table info>
% cat process.bpel
main line process stuff
% echo "add more process stuff" >> process.bpel
% git commit -a -m "fix process stuff on mainline"
% git checkout A
% git merge master
% cat process.bpel
main line process stuff
add more process stuff
% git checkout B
% git merge master
% cat process.bpel
main line process stuff
add more process stuff
Is that not it?
Bill
^ permalink raw reply
* RE: Beginner's question on how to use git for multiple parallel versions
From: Christian C. Schouten @ 2010-01-04 13:35 UTC (permalink / raw)
To: git
In-Reply-To: <19265.60728.17437.665860@blake.zopyra.com>
Dear Bill,
Thanks for your prompt reply. It may very well be exactly what I need, but
I'm afraid that I don't understand the syntax just yet (am still in the
phase orienting on what version management is and how it should be set up).
Could you please add to your answer whether I am using branches or another
git technique (terminology?) and whether these are instructions that I can
use to commit a change once the system has already been set up or if these
actually are the instructions for defining the multiplicity of my project
versions?
Sorry for the newbie-ness and thanks in advance,
Best,
Chris
-----Original Message-----
From: Bill Lear [mailto:rael@zopyra.com]
Sent: maandag 4 januari 2010 14:29
To: Christian C. Schouten
Cc: git@vger.kernel.org
Subject: Re: Beginner's question on how to use git for multiple parallel
versions
On Monday, January 4, 2010 at 12:29:52 (+0100) Christian C. Schouten writes:
>Hello all,
>
>I've got a project that I want to do version management on with
>git but being a beginner in cvs/svn/dvcs etc. terminology I
>don't know yet how to set it up. My project needs to exist as
>several parallel copies, i.e. there is a "main version" in
>which I do my development but it needs to end up being available as a
>couple of different configurations. For instance, say there is a file
>table.xml then this needs to contain different rows for versions A and
>B. Likewise, a file process.bpel needs to be named identical for each
>version but contain different content depending on whether it is
>distributed as version A or version B. Any changes made in non-version
>specific files should be visible in all copies, but changes made to
>version-specific files need to remain isolated to that particular
>version.
What you are asking for is this, I think:
% git checkout A
% cat table.xml
<table A>
% echo "<table A v2>" > table.xml
% git commit -a -m "fix table on Branch A"
% git checkout B
% cat table.xml
<table B>
% echo "<table B v2>" > table.xml
% git commit -a -m "fix table on Branch B"
% git checkout master
% cat table.xml
<non-version-specific table info>
% cat process.bpel
main line process stuff
% echo "add more process stuff" >> process.bpel
% git commit -a -m "fix process stuff on mainline"
% git checkout A
% git merge master
% cat process.bpel
main line process stuff
add more process stuff
% git checkout B
% git merge master
% cat process.bpel
main line process stuff
add more process stuff
Is that not it?
Bill
^ permalink raw reply
* Re: [PATCH v3] Smart-http documentation: add example of how to execute from userdir
From: Shawn O. Pearce @ 2010-01-04 14:06 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Tay Ray Chuan, git, Tarmigan Casebolt
In-Reply-To: <7vzl4v1t91.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> Tarmigan Casebolt <tarmigan+git@gmail.com> writes:
>
> > Smart-http may be an attactive and easy way for people to setup git
> > hosting on shared servers whose primary web server configuration they
> > do not control. To facilite this, provide an example of how it may be
> > done.
> >
> > cc: Tay Ray Chuan <rctay89@gmail.com>
> > cc: Shawn O. Pearce <spearce@spearce.org>
> > Editing-by: Tay Ray Chuan <rctay89@gmail.com>
> > Signed-off-by: Tarmigan Casebolt <tarmigan+git@gmail.com>
>
> I still see Cc: here; are people named above (and others commented on
> earlier versions) happy with this round?
I don't get why Options +SymLinksIfOwnerMatch is needed here.
If we are linking to the root installed git-http-backend Apache
will actually reject the link, because the link owner is likely to
be $USER while the target is owned by root.
So I really can't ACK this, the instructions don't jive with my
understanding of the Apache configuration.
--
Shawn.
^ permalink raw reply
* What is the best way to convert a multi module CVS repository to git?
From: Wolfgang.Liebich @ 2010-01-04 15:53 UTC (permalink / raw)
To: git
Hi,
I have inherited a rather big, old, multi-module CVS repository which I
want to convert to GIT.
Most of the CVS modules do belong to one project now, i.e. the
separation into multiple modules is something of a historical accident
now. This means it does not make sense to put each CVS module into an
own GIT project and use submodules.
Furthermore the conversion will be one-way, i.e. afterwards the CVS repo
will be shutdown forever and moved to offline storage. Incremental
conversion is therefore not an issue.
If I need one day to convert everything (the repo is about 3GB), so be
it - the most important feature to me is correctness (I do NOT want to
have to run manual verifications for N days/weeks/months, just to verify
that everything was converted), and ideally even the possibility of
re-creating the history of files which were moved across directories
(this HAS happened sometimes - I did not fiddle around with the RCS
files, but used straight rm+add, and accepted the loss of history forced
on me by CVS).
What is the best (i.e. most trustworthy) method of conversion? For now
it seems to me that cvs2git (the ...2git companion to cvs2svn) is the
best choice (because it can handle multi-module projects in a sane way)
- but I'm open to suggestions!
Ciao,
Wolfgang Liebich
^ permalink raw reply
* Re: Beginner's question on how to use git for multiple parallel versions
From: Dmitry Potapov @ 2010-01-04 14:35 UTC (permalink / raw)
To: Christian C. Schouten; +Cc: git
In-Reply-To: <F8CC469C9CCA415696101414EA997C0.MAI@sohosted19.com>
Hi,
On Mon, Jan 4, 2010 at 2:29 PM, Christian C. Schouten <info@zark3.net> wrote:
>
> I’ve got a project that I want to do version management on with git but being a beginner in
> cvs/svn/dvcs etc. terminology I don’t know yet how to set it up.
> My project needs to exist as several parallel copies, i.e. there is a “main version” in
> which I do my development but it needs to end up being available as a couple of different
> configurations.
One way to achieve that is to use branches. You create a mainline
branch that will contain
what is common for all versions, and then create a few specific
branches from it. Each branch
will contain their own files, as well as modifications to some common
files if it is necessary.
Changes that a common to all branches should be committed to the
mainline, which is merged
to each version specific branch.
Git allows to quickly switch between branches, so you stay in all
worktree all the time.
Moreover, if you made modifications to some file on branchA but then
realized that it should
be commit to another branch, you can switch to another branch as usual
as long as the
modified files are the same on both branches. (If it is not the case,
you can use git stash).
Dmitry
^ permalink raw reply
* RE: Beginner's question on how to use git for multiple parallel versions
From: Bill Lear @ 2010-01-04 15:44 UTC (permalink / raw)
To: Christian C. Schouten; +Cc: git
In-Reply-To: <22D57EF90F8E4A2799F739FC14F8BA63@Duthler.local>
On Monday, January 4, 2010 at 14:35:25 (+0100) Christian C. Schouten writes:
>Dear Bill,
>
>Thanks for your prompt reply. It may very well be exactly what I need, but
>I'm afraid that I don't understand the syntax just yet (am still in the
>phase orienting on what version management is and how it should be set up).
>
>Could you please add to your answer whether I am using branches or another
>git technique (terminology?) and whether these are instructions that I can
>use to commit a change once the system has already been set up or if these
>actually are the instructions for defining the multiplicity of my project
>versions?
In my example, I used branches, but did not show how to set them up.
Here is the complete example, complete with repository and branch
creation; you would start your project here:
# Set up repo and add first file to main branch:
% mkdir my_project
% cd my_project
% git init
% echo "main line process stuff" > process.bpel
% git add process.bpel
% echo "<non-version-specific table info>" > table.xml
% git add table.xml
% git commit -a -m "First commit on master branch"
# Create branch A and branch B:
% git branch A
% git branch B
# Modify file on branch A:
% git checkout A
% echo "<table A>" > table.xml
% git commit -a -m "Modify table on Branch A"
# Modify file on branch B:
% git checkout B
% echo "<table B>" > table.xml
% git commit -a -m "Modify table on Branch B"
# Now go back to master and make some changes on common file:
% git checkout master
% cat process.bpel
main line process stuff
% echo "add more process stuff" >> process.bpel
% git commit -a -m "fix process stuff on master"
# Now go to branch A and pull in the common file:
% git checkout A
% git merge master
% cat process.bpel
main line process stuff
add more process stuff
# Now go to branch B and pull in the common file:
% git checkout B
% git merge master
% cat process.bpel
main line process stuff
add more process stuff
That should be just about all you need.
Bill
^ permalink raw reply
* Re: [PATCH 7/6] t0021: use $SHELL_PATH for the filter script
From: Johannes Sixt @ 2010-01-04 15:50 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20100103072408.GA23031@sigill.intra.peff.net>
Jeff King schrieb:
> On Fri, Jan 01, 2010 at 11:14:06PM +0100, Johannes Sixt wrote:
>
>> On Windows, we need the shbang line to correctly invoke shell scripts via
>> a POSIX shell, except when the script is invoked via 'sh -c' because
>> sh (a bash) does "the right thing". Since nowadays the clean and smudge
>> filters are not always invoked via 'sh -c' anymore, we have to mark the
>> the one in t0021-conversion with #!$SHELL_PATH.
>
> Hrm. This does mean we might be breaking users who have helper scripts
> in a similar state to those in the test suite...
Not helper scripts in general, but only clean and smudge filters, because
these have been invoked with "sh -c" so far. Everything else, that was not
run via "sh -c", but now is, is safe.
-- Hannes
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Linus Torvalds @ 2010-01-04 15:54 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100104064408.GA7785@coredump.intra.peff.net>
On Mon, 4 Jan 2010, Jeff King wrote:
>
> I have to wonder, though...did anybody ever actually profile our
> internal grep to find out _why_ it was so much slower than GNU grep?
> Could we simply ship a better grep engine and obsolete external grep?
The internal grep is about 2.5 times slower than the external one for me.
That's a big deal:
- external grep:
[torvalds@nehalem linux]$ time git grep qwerty
...
real 0m0.412s
user 0m0.196s
sys 0m0.132s
- NO_EXTERNAL_GREP:
[torvalds@nehalem linux]$ time ~/git/git grep qwerty
...
real 0m1.006s
user 0m0.900s
sys 0m0.096s
so that's not even close.
And "perf record" followed by "perf report" on the internal one shows
that it's not even regexec() - we use strstr() for the trivial case:
43.63% git /home/torvalds/git/git [.] grep_buffer_1
25.19% git /lib64/libc-2.11.so [.] __strstr_sse42
9.16% git /home/torvalds/git/git [.] match_one_pattern
4.79% git /lib64/libc-2.11.so [.] __m128i_strloadu
bit it seems to be all that line-per-line crud. If we got rid of that one,
and could do the match as a _single_ regexec() instead (at least for the
trivial cases of just one grep expression), perhaps we'd be better off.
Linus
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Linus Torvalds @ 2010-01-04 16:01 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100104080940.GA4815@coredump.intra.peff.net>
On Mon, 4 Jan 2010, Jeff King wrote:
>
> However, gprof reports that for the pcre dfa case, we spend more time in
> grep.c:end_of_line than we do actually running the regex. So clearly
> there are some other micro-optimizations in GNU grep that are making a
> difference, too.
Don't use gprof. You're _much_ better off using the newish Linux 'perf'
tool. It's quite competent, and doesn't need the code to be compiled with
-pg (which totally changes all performance characteristics).
Do something like this:
perf record git grep qwerty
followed by
perf report
perf annotate grep_buffer_1
(that "perf report" gives a per-symbol overview, the "perf annotate" gives
a disassembly with source annotations and per-instruction costs). It works
with inlining too, so you get things like this:
...
: static char *end_of_line(char *cp, unsigned long *left)
: {
: unsigned long l = *left;
: while (l && *cp != '\n') {
24.76 : 476a50: 80 3b 0a cmpb $0xa,(%rbx)
10.46 : 476a53: 0f 84 e7 00 00 00 je 476b40 <grep_buffer_1+0x1b0>
: l--;
: cp++;
21.19 : 476a59: 48 83 c3 01 add $0x1,%rbx
: }
:
: static char *end_of_line(char *cp, unsigned long *left)
: {
: unsigned long l = *left;
: while (l && *cp != '\n') {
0.94 : 476a5d: 49 83 ed 01 sub $0x1,%r13
4.85 : 476a61: 75 ed jne 476a50 <grep_buffer_1+0xc0>
:
...
and yes, it's all the per-line crap.
The perf tools are included with modern kernels in tools/perf (which also
has a Documentation subdirectory). I can pretty much guarantee that once
you start using it, you'll never use gprof or oprofile again.
Linus
^ permalink raw reply
* Re: [PATCH] Use warning function instead of fprintf(stderr, "Warning: ...").
From: Johannes Sixt @ 2010-01-04 16:02 UTC (permalink / raw)
To: Thiago Farina; +Cc: git
In-Reply-To: <1262463886-8956-1-git-send-email-tfransosi@gmail.com>
Did you actually test any of the changed warnings? You should see extra
empty lines because warning() adds its own LF and you didn't remove any.
-- Hannes
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Linus Torvalds @ 2010-01-04 16:03 UTC (permalink / raw)
To: Miles Bader; +Cc: Jeff King, Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <fc339e4a1001040757n31298f3h724eacfafb68c63e@mail.gmail.com>
On Tue, 5 Jan 2010, Miles Bader wrote:
> On Tue, Jan 5, 2010 at 12:54 AM, Linus Torvalds
> <torvalds@linux-foundation.org> wrote:
> > And "perf record" followed by "perf report" on the internal one shows
> > that it's not even regexec() - we use strstr() for the trivial case:
>
> Does strstr use e.g. boyer-moore? I imagine grep does...
It doesn't matter. Since we do the line-by-line thing, the input is always
so short that DFA vs NFA vs BM vs other-clever-search doesn't matter.
There is no scaling - the grep buffer tends to be too small for the
algorithm to matter.
And the reason we do things line-by-line is that we need to then output
things line-per-line.
Linus
^ permalink raw reply
* Re: [PATCH 7/6] t0021: use $SHELL_PATH for the filter script
From: Jeff King @ 2010-01-04 16:03 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <4B420E4F.1040706@kdbg.org>
On Mon, Jan 04, 2010 at 04:50:39PM +0100, Johannes Sixt wrote:
> >>On Windows, we need the shbang line to correctly invoke shell scripts via
> >>a POSIX shell, except when the script is invoked via 'sh -c' because
> >>sh (a bash) does "the right thing". Since nowadays the clean and smudge
> >>filters are not always invoked via 'sh -c' anymore, we have to mark the
> >>the one in t0021-conversion with #!$SHELL_PATH.
> >
> >Hrm. This does mean we might be breaking users who have helper scripts
> >in a similar state to those in the test suite...
>
> Not helper scripts in general, but only clean and smudge filters,
> because these have been invoked with "sh -c" so far. Everything else,
> that was not run via "sh -c", but now is, is safe.
I converted more than that; see my 2/6. It is also the pager, the
imap-send tunnel helper, and external merge helpers. Not the editor,
since it already had the no-metacharacters optimization (though it, too,
could be affected if we implement your DWIM trick instead of the
metacharacter thing).
So I think we need to make a conscious decision that this is an
acceptable change of behavior (and I am totally fine with the change
happening -- I just want to be clear about the extent of what is being
changed).
-Peff
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Miles Bader @ 2010-01-04 15:57 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Jeff King, Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.LFD.2.00.1001040659150.3630@localhost.localdomain>
On Tue, Jan 5, 2010 at 12:54 AM, Linus Torvalds
<torvalds@linux-foundation.org> wrote:
> And "perf record" followed by "perf report" on the internal one shows
> that it's not even regexec() - we use strstr() for the trivial case:
Does strstr use e.g. boyer-moore? I imagine grep does...
-miles
--
Do not taunt Happy Fun Ball.
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Matthieu Moy @ 2010-01-04 16:19 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljgei7rs.fsf@alter.siamese.dyndns.org>
Hi,
Junio C Hamano <gitster@pobox.com> writes:
> * mm/diag-path-in-treeish (2009-12-07) 1 commit
> - Detailed diagnosis when parsing an object name fails.
This one has been there for quite some time and shouldn't be
controversial. Do I need anything to push it into next?
Thanks,
--
Matthieu Moy
http://www-verimag.imag.fr/~moy/
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Linus Torvalds @ 2010-01-04 16:24 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.LFD.2.00.1001040659150.3630@localhost.localdomain>
On Mon, 4 Jan 2010, Linus Torvalds wrote:
>
> - external grep:
>
> [torvalds@nehalem linux]$ time git grep qwerty
> ...
> real 0m0.412s
> user 0m0.196s
> sys 0m0.132s
>
> - NO_EXTERNAL_GREP:
>
> [torvalds@nehalem linux]$ time ~/git/git grep qwerty
> ...
> real 0m1.006s
> user 0m0.900s
> sys 0m0.096s
>
> so that's not even close.
Side note: at least for me, if we did some auto-parallelization, the
internal grep would make up for all its other suckiness. Do four or eight
greps in parallel, and buffer the results (you still need to show them in
the right order).
That might be an acceptable way to "fix" it. Developers pretty much all
have at least two cores these days, some of us have four+HT. We use
threads in other places, maybe this could be one more of them.
(Start 'n' threads, do an initial per-thread regex and 'regcomp()' to make
it thread-safer, and the only interesting issue would be serializing the
output. Whenever you get a result, you'd need to make sure that all files
before have been completed, but you could do that all under a specific
lock that protects completion information).
Linus
^ permalink raw reply
* Git Server Authentication & Management
From: Pedro Lemos @ 2010-01-04 16:27 UTC (permalink / raw)
To: Git
Hi,
I'm relatively new to Git.
At the moment I'm trying to understand if it will be possible to:
1 - configure a central server (server A) to host all my git repositories.
2 - also I would like to configure access to those Git repositories in
order to use authentication:
- using LDAP;
- using MS Active Directory;
3 - Moreover, I would like to know if is there any administration
interface to use within git repositories?
4 - And to close this email, I need a way to manage access permissions
over the server repositories. Such as:
- read-write, read-only, or no access at all;
- deletes-allowed, renames-allowed, tags allowed;
Can anyone guide me through any items referred above?
Any help appreciated!
Best Regards,
Pedro Lemos
^ permalink raw reply
* Re: What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Johannes Sixt @ 2010-01-04 16:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vljgei7rs.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> * jk/run-command-use-shell (2010-01-01) 8 commits
> - t4030, t4031: work around bogus MSYS bash path conversion
> - t0021: use $SHELL_PATH for the filter script
> - diff: run external diff helper with shell
> - textconv: use shell to run helper
> - editor: use run_command's shell feature
> - run-command: optimize out useless shell calls
> - run-command: convert simple callsites to use_shell
> - run-command: add "use shell" option
Two notes about this:
1. My patch "t0021:..." contains an unrelated change to t4030 (it changes
a /bin/sh to $SHELL_PATH) that is not necessary. I included it in my first
version of the patch, but later noticed that we already have many similar
uses of /bin/sh instead of $SHELL_PATH in test scriptlets and decided to
remove the change, but I only changed the commit message and forgot to
unstage t4030.
2. If you intend to merge the early part of the topic to master early and
hold "diff:..." and "textconv:..." in next a bit longer (as proposed by
Jeff), then you should move "t0021:..." after "run-command: optimize out
useless shell calls".
Thanks,
-- Hannes
^ permalink raw reply
* Re: Git Server Authentication & Management
From: Shawn O. Pearce @ 2010-01-04 16:33 UTC (permalink / raw)
To: Pedro Lemos; +Cc: Git
In-Reply-To: <1a710981001040827q23f61bdew8db1ae76d5bfb855@mail.gmail.com>
Pedro Lemos <pedrolemos454@gmail.com> wrote:
> I'm relatively new to Git.
> At the moment I'm trying to understand if it will be possible to:
>
> 1 - configure a central server (server A) to host all my git repositories.
> 2 - also I would like to configure access to those Git repositories in
> order to use authentication:
> - using LDAP;
> - using MS Active Directory;
You might want to look at Gerrit Code Review [1]. It has
out-of-the-box support for integration with Active Directory.
[1] http://code.google.com/p/gerrit/
> 3 - Moreover, I would like to know if is there any administration
> interface to use within git repositories?
Gerrit Code Review uses a web based administration interface, though
with an LDAP/Active Directory configuration access controls will
most likely be managed in the directory server by user membership
to groups.
> 4 - And to close this email, I need a way to manage access permissions
> over the server repositories. Such as:
> - read-write, read-only, or no access at all;
> - deletes-allowed, renames-allowed, tags allowed;
Yup, Gerrit Code Review can do that.
It also can be used as a code review system. :-) But if you don't
want to use the code review features, you can just grant out the
Push Branch +1 (or +2 or +3) permission to allow pushing to a branch.
A different, but much more popular choice is gitosis [2], but that
doesn't use LDAP for user authentication and access management.
It uses its own SSH key repository. To be fair, Gerrit Code Review
also uses its own SSH key repository... but users can manage their
keys individually through the web interface, which is authenticated
by LDAP.
[2] http://eagain.net/gitweb/?p=gitosis.git
--
Shawn.
^ permalink raw reply
* Re: [PATCH 7/6] t0021: use $SHELL_PATH for the filter script
From: Johannes Sixt @ 2010-01-04 16:46 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, Nanako Shiraishi, git
In-Reply-To: <20100104160317.GB9136@coredump.intra.peff.net>
Jeff King schrieb:
> I converted more than that; see my 2/6. It is also the pager, the
> imap-send tunnel helper, and external merge helpers. Not the editor,
> since it already had the no-metacharacters optimization (though it, too,
> could be affected if we implement your DWIM trick instead of the
> metacharacter thing).
>
> So I think we need to make a conscious decision that this is an
> acceptable change of behavior (and I am totally fine with the change
> happening -- I just want to be clear about the extent of what is being
> changed).
Hm, ok, I see.
- The clean and smudge filters are probably the most important cases.
- I *did* write my own merge script (to merge PNGs!), but I made sure to
begin it with #!/bin/bash, and I don't think anybody else is crazy enough
to write a custom merge script ;)
- imap-send on Windows is so new that I don't think anyone is already
using it with a custom tunneling script.
- The change in pager.c is unimportant because all versions shipped so far
(via msysgit) have the conflicting change that tried without "sh -c" first.
I think that these can be handled with an entry in the release notes.
-- Hannes
^ permalink raw reply
* Re: RFC: display dirty submodule working directory in git gui and gitk
From: Jens Lehmann @ 2010-01-04 17:04 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce, Paul Mackerras,
Heiko Voigt, Lars Hjemli
In-Reply-To: <alpine.DEB.1.00.1001041038520.4985@pacific.mpi-cbg.de>
Am 04.01.2010 10:44, schrieb Johannes Schindelin:
> The real problem is that submodules in the current form are not very well
> designed.
IMVHO using the tree sha1 for a submodule seems to be the 'natural' way
to include another git repo. And it gives the reproducibility i expect
from a scm. Or am i missing something?
It looks to me as most shortcomings come from the fact that most git
commands tend to ignore submodules (and if they don't, like git gui and
gitk do now, they e.g. only show certain aspects of their state).
Submodules are in heavy use in our company since last year. Virtually
every patch i submitted for submodules came from that experience and
scratched an itch i or one of my colleagues had (and the situation did
already improve noticeably by the few things we changed). We are still
convinced that using submodules was the right decision. But some work
has still to be done to be able to use them easily and to get rid of
some pitfalls.
> In ths short run, we can paper over the shortcomings of the submodules by
> introducing a command line option "--include-submodules" to
> update-refresh, diff-files and diff-index, though.
Maybe this is the way to go for now (and hopefully we can turn this
option on by default later because we did the right thing ;-).
^ permalink raw reply
* Re: RFC: display dirty submodule working directory in git gui and gitk
From: Nguyen Thai Ngoc Duy @ 2010-01-04 17:51 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Jens Lehmann, Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Paul Mackerras, Heiko Voigt, Lars Hjemli
In-Reply-To: <alpine.DEB.1.00.1001041038520.4985@pacific.mpi-cbg.de>
On 1/4/10, Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> The real problem is that submodules in the current form are not very well
> designed. For example, a submodule being at a different commit than in
> the superproject's index is not as fatal as the submodule having changes.
>
> So in the long run, IMHO a proper redesign of the submodules would not
> make only a little sense (it does not help, though, that those who
> implemented and furthered the current approach over other discussed
> approaches do not use submodules themselves -- not even now).
>
> In ths short run, we can paper over the shortcomings of the submodules by
> introducing a command line option "--include-submodules" to
> update-refresh, diff-files and diff-index, though.
Incidentally I was just drafting git-super.sh it see how far it goes.
The goal was to implement some cross-module operations over time. "git
super status", "git super commit" and others could be handy.
--
Duy
^ permalink raw reply
* Re: submodules, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Avery Pennarun @ 2010-01-04 18:29 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Heiko Voigt, Jens Lehmann, Git Mailing List, Junio C Hamano,
Shawn O. Pearce, Paul Mackerras, Lars Hjemli
In-Reply-To: <alpine.DEB.1.00.1001041157020.3695@intel-tinevez-2-302>
On Mon, Jan 4, 2010 at 6:46 AM, Johannes Schindelin
<Johannes.Schindelin@gmx.de> wrote:
> But I think that an important precondition to come up with a better design
> of the submodules is to have suffered the current implementation in
> real-world work using submodules. (Which reminds me very much of the
> autocrlf mess.)
I suffered the current implementation, which is why I wrote
git-subtree :) I'm still suffering, though; git-subtree works much
better for my own use cases, but after some experience with it, I'm
still not totally happy.
For me one big problem comes down to producing accurate output for
'git log'. git submodules assume that the history inside the module
is entirely separate (you need to run multiple 'git log' instances to
see the full history); git-subtree assumes that it's entirely
integrated. In that sense, git-subtree is somewhat more in line with
the core principle of git (we track the history of "the content", not
any particular file or subdir). Unfortunately, it also exposes a
problem with that core principle: taken to its extreme, "the content"
includes all data in the universe. And while git could branch and
merge the universe very efficiently in about O(log n) time, 'git log'
output gets less useful about O(n) with the size of the tree.
Neither git-subtree nor git submodules seem to help with this "log
pollution" problem very much - but I don't know what to do that would
be better.
Outside of this, my major problem with submodules is they use separate
work trees and repositories, and thus require lots of extra
housekeeping to get anything done. I'd be much happier if submodules
would share the same objects/packs/.gitdir/refs/indexfile as the
superproject, and the *only* thing special about them would be that
the superproject's tree points at a commit object instead of a tree
object. In other words, I think the actual repo format is correct
as-is, but the tools surrounding it cause a lot of confusion.
Imagine if cloning a superproject also checked out the subproject
transparently, and committing dirty data inside the subproject's tree
created a new commit object for the subproject, then tacked that
commit object into the superproject's index for a later commit
(exactly as changing a subdir creates a new tree object that the
parent directory can refer to).
This doesn't solve some use cases, however, such as ones where people
really don't want to check out (or even fetch) the contents of some
submodules, even when they check out the superproject. The current
implementation *does* handle that situation. I'm not sure how many
people rely on that behaviour, though. (And maybe the correct
solution to *that* is proper support for sparse clone/checkout
regardless of submodules.)
Have fun,
Avery
^ permalink raw reply
* Re: RFC: display dirty submodule working directory in git gui and gitk
From: Jens Lehmann @ 2010-01-04 18:40 UTC (permalink / raw)
To: Nguyen Thai Ngoc Duy
Cc: Johannes Schindelin, Git Mailing List, Junio C Hamano,
Shawn O. Pearce, Paul Mackerras, Heiko Voigt, Lars Hjemli
In-Reply-To: <fcaeb9bf1001040951r3f797750o5ebd25e93c0272ea@mail.gmail.com>
Am 04.01.2010 18:51, schrieb Nguyen Thai Ngoc Duy:
> Incidentally I was just drafting git-super.sh it see how far it goes.
> The goal was to implement some cross-module operations over time. "git
> super status", "git super commit" and others could be handy.
Hm, i'm not sure if this will really help us. I would rather see "git
status" and friends do the right thing for submodules too. Maybe this
has to be configurable but i think the separate commands that one has
to use for submodules now are part of the usability problems we are
seeing.
IMHO putting the functionality of "git submodule summary" into "git
diff" was a step in the right direction. This thread is about adding a
line to the diff output when diffing against the working directory and
a submodule has a dirty working directory too. Then you can ask "git
diff" and it tells you anything you need to know about the submodule
before committing or checking out in the supermodule (And IMO later on
"git status" should give us this information too).
^ 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