* Re: [PATCH v2] Use warning function instead of fprintf(stderr, "Warning: ...").
From: Nanako Shiraishi @ 2010-01-04 0:18 UTC (permalink / raw)
To: Thiago Farina; +Cc: gitster, git
In-Reply-To: <1262535630-3918-1-git-send-email-tfransosi@gmail.com>
Quoting Thiago Farina <tfransosi@gmail.com>
> Signed-off-by: Thiago Farina <tfransosi@gmail.com>
> ---
> Removed the LF from the end of the strings.
Trying this patch makes t6030-bisect-porcelain.sh fail for me. Was this tested at all?
--
Nanako Shiraishi
http://ivory.ap.teacup.com/nanako3/
^ permalink raw reply
* Re: [PATCH v2] Use warning function instead of fprintf(stderr, "Warning: ...").
From: Junio C Hamano @ 2010-01-04 0:41 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Thiago Farina, gitster, git
In-Reply-To: <20100104091847.6117@nanako3.lavabit.com>
Nanako Shiraishi <nanako3@lavabit.com> writes:
> Quoting Thiago Farina <tfransosi@gmail.com>
>
>> Signed-off-by: Thiago Farina <tfransosi@gmail.com>
>> ---
>> Removed the LF from the end of the strings.
>
> Trying this patch makes t6030-bisect-porcelain.sh fail for me. Was this tested at all?
I noticed it as well; will squash this in.
diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
index def397c..c51865f 100755
--- a/t/t6030-bisect-porcelain.sh
+++ b/t/t6030-bisect-porcelain.sh
@@ -423,7 +423,7 @@ test_expect_success 'skipped merge base when good and bad are siblings' '
grep "merge base must be tested" my_bisect_log.txt &&
grep $HASH4 my_bisect_log.txt &&
git bisect skip > my_bisect_log.txt 2>&1 &&
- grep "Warning" my_bisect_log.txt &&
+ grep "warning" my_bisect_log.txt &&
grep $SIDE_HASH6 my_bisect_log.txt &&
git bisect reset
'
^ permalink raw reply related
* Re: git-svn: handling merge-base failures
From: Andrew Myrick @ 2010-01-04 1:37 UTC (permalink / raw)
To: git; +Cc: Eric Wong, Sam Vilain
In-Reply-To: <931B0483-7628-488E-BB9F-C40346353149@apple.com>
[-- Attachment #1: Type: text/plain, Size: 1536 bytes --]
On Dec 23, 2009, at 11:54 AM, Andrew Myrick wrote:
> One of my projects is failing to clone because merge-base is failing on one of the revisions; the branch is a partial branch, so merge-base can't find a common ancestor with trunk. I'd like to catch the exception that command_oneline should throw when merge-base fails,
Instead of using the Error.pm module, I was able to handle the exception with the more basic eval block. However, there are some details here I would like to discuss with the community.
When git-svn fetches a partial branch, it appears to refetch all of the history of the subdirectory from which the branch was created. This creates new commits for the old revisions, and these new commits exist as a separate history for the partial branch. When git-svn fetches the revision at which this partial branch is merged back to trunk, git-svn attempts to run merge-base to find a common ancestor. However, because the partial branch has its own history, the merge-base fails, and git-svn dies.
Naively handling the exception with an eval block and skipping the merge ticket works fine in that it brings us back to parity with git 1.6.5.7, but it means that the merge parent relationship between trunk and the partial branch is lost. Is there any way to preserve this information, or does the separate commit history of the partial branch make it fundamentally impossible?
I've created a small svn repository that demonstrates this failure with git v1.6.6. Its dump is attached.
-Andrew
[-- Attachment #2: partial.dump --]
[-- Type: application/octet-stream, Size: 4314 bytes --]
SVN-fs-dump-format-version: 2
UUID: ef8533a7-8eba-4e00-b9e4-68f81a8a4a0e
Revision-number: 0
Prop-content-length: 56
Content-length: 56
K 8
svn:date
V 27
2010-01-04T00:41:48.890110Z
PROPS-END
Revision-number: 1
Prop-content-length: 119
Content-length: 119
K 7
svn:log
V 17
Initial import
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:42:12.648154Z
PROPS-END
Node-path: branches
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Node-path: tags
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Node-path: trunk
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Revision-number: 2
Prop-content-length: 113
Content-length: 113
K 7
svn:log
V 11
New files
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:43:30.046704Z
PROPS-END
Node-path: trunk/a
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Node-path: trunk/a/file
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 0
Text-content-md5: d41d8cd98f00b204e9800998ecf8427e
Text-content-sha1: da39a3ee5e6b4b0d3255bfef95601890afd80709
Content-length: 10
PROPS-END
Node-path: trunk/b
Node-kind: dir
Node-action: add
Prop-content-length: 10
Content-length: 10
PROPS-END
Node-path: trunk/b/file
Node-kind: file
Node-action: add
Prop-content-length: 10
Text-content-length: 0
Text-content-md5: d41d8cd98f00b204e9800998ecf8427e
Text-content-sha1: da39a3ee5e6b4b0d3255bfef95601890afd80709
Content-length: 10
PROPS-END
Revision-number: 3
Prop-content-length: 122
Content-length: 122
K 7
svn:log
V 20
Create full branch
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:44:34.670334Z
PROPS-END
Node-path: branches/fullbranch
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 2
Node-copyfrom-path: trunk
Revision-number: 4
Prop-content-length: 112
Content-length: 112
K 7
svn:log
V 10
Add text
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:45:11.654184Z
PROPS-END
Node-path: branches/fullbranch/a/file
Node-kind: file
Node-action: change
Text-content-length: 5
Text-content-md5: 6137cde4893c59f76f005a8123d8e8e6
Text-content-sha1: c5d84736ba451747dd5f0eb9d17e104f3697ef47
Content-length: 5
data
Revision-number: 5
Prop-content-length: 129
Content-length: 129
K 7
svn:log
V 27
Merge fullbranch to trunk
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:45:41.203114Z
PROPS-END
Node-path: trunk
Node-kind: dir
Node-action: change
Prop-content-length: 59
Content-length: 59
K 13
svn:mergeinfo
V 24
/branches/fullbranch:3-4
PROPS-END
Node-path: trunk/a/file
Node-kind: file
Node-action: change
Text-content-length: 5
Text-content-md5: 6137cde4893c59f76f005a8123d8e8e6
Text-content-sha1: c5d84736ba451747dd5f0eb9d17e104f3697ef47
Content-length: 5
data
Revision-number: 6
Prop-content-length: 125
Content-length: 125
K 7
svn:log
V 23
Create partial branch
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:47:34.954727Z
PROPS-END
Node-path: branches/partialbranch
Node-kind: dir
Node-action: add
Node-copyfrom-rev: 5
Node-copyfrom-path: trunk/b
Prop-content-length: 61
Content-length: 61
K 13
svn:mergeinfo
V 26
/branches/fullbranch/b:3-4
PROPS-END
Revision-number: 7
Prop-content-length: 110
Content-length: 110
K 7
svn:log
V 9
Add data
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:48:22.334502Z
PROPS-END
Node-path: branches/partialbranch/file
Node-kind: file
Node-action: change
Text-content-length: 10
Text-content-md5: 284b44f9273171eb622b27d9a4df5acd
Text-content-sha1: 59cb3d79577306b6be81d41c273ea47cd47968e1
Content-length: 10
more data
Revision-number: 8
Prop-content-length: 133
Content-length: 133
K 7
svn:log
V 31
Merge partial branch to trunk
K 10
svn:author
V 7
amyrick
K 8
svn:date
V 27
2010-01-04T00:49:11.588697Z
PROPS-END
Node-path: trunk/b
Node-kind: dir
Node-action: change
Prop-content-length: 89
Content-length: 89
K 13
svn:mergeinfo
V 54
/branches/fullbranch/b:3-4
/branches/partialbranch:6-7
PROPS-END
Node-path: trunk/b/file
Node-kind: file
Node-action: change
Text-content-length: 10
Text-content-md5: 284b44f9273171eb622b27d9a4df5acd
Text-content-sha1: 59cb3d79577306b6be81d41c273ea47cd47968e1
Content-length: 10
more data
^ permalink raw reply
* Re: git-svn: handling merge-base failures
From: Eric Wong @ 2010-01-04 3:45 UTC (permalink / raw)
To: Andrew Myrick; +Cc: git, Sam Vilain
In-Reply-To: <7878A426-9D87-43B5-A10A-38F3C9369165@apple.com>
Andrew Myrick <amyrick@apple.com> wrote:
> On Dec 23, 2009, at 11:54 AM, Andrew Myrick wrote:
> > One of my projects is failing to clone because merge-base is failing
> > on one of the revisions; the branch is a partial branch, so
> > merge-base can't find a common ancestor with trunk. I'd like to
> > catch the exception that command_oneline should throw when
> > merge-base fails,
>
> Instead of using the Error.pm module, I was able to handle the
> exception with the more basic eval block. However, there are some
> details here I would like to discuss with the community.
>
> When git-svn fetches a partial branch, it appears to refetch all of
> the history of the subdirectory from which the branch was created.
> This creates new commits for the old revisions, and these new commits
> exist as a separate history for the partial branch. When git-svn
> fetches the revision at which this partial branch is merged back to
> trunk, git-svn attempts to run merge-base to find a common ancestor.
> However, because the partial branch has its own history, the
> merge-base fails, and git-svn dies.
>
> Naively handling the exception with an eval block and skipping the
> merge ticket works fine in that it brings us back to parity with git
> 1.6.5.7, but it means that the merge parent relationship between trunk
> and the partial branch is lost. Is there any way to preserve this
> information, or does the separate commit history of the partial branch
> make it fundamentally impossible?
Hi Andrew,
A method of preserving the $SVN_PATH <=> $PARENT@$REV mapping for
reusing follow_parent-created branches is definitely desired.
I've just been lacking time and motivation these days with other
projects taking priority. Help (even if it's just to refactor/cleanup
existing code) would definitely be appreciated here.
> I've created a small svn repository that demonstrates this failure
> with git v1.6.6. Its dump is attached.
Thanks. This (and a similar dump a few weeks back) will definitely
come in handy for writing test cases and fixing this long-standing
issue.
--
Eric Wong
^ permalink raw reply
* Re: git-svn: handling merge-base failures
From: Andrew Myrick @ 2010-01-04 4:43 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Sam Vilain
In-Reply-To: <20100104034540.GA4548@dcvr.yhbt.net>
On Jan 3, 2010, at 7:45 PM, Eric Wong wrote:
> Andrew Myrick <amyrick@apple.com> wrote:
>> On Dec 23, 2009, at 11:54 AM, Andrew Myrick wrote:
>>> One of my projects is failing to clone because merge-base is failing
>>> on one of the revisions; the branch is a partial branch, so
>>> merge-base can't find a common ancestor with trunk. I'd like to
>>> catch the exception that command_oneline should throw when
>>> merge-base fails,
>>
>> Instead of using the Error.pm module, I was able to handle the
>> exception with the more basic eval block. However, there are some
>> details here I would like to discuss with the community.
>>
>> When git-svn fetches a partial branch, it appears to refetch all of
>> the history of the subdirectory from which the branch was created.
>> This creates new commits for the old revisions, and these new commits
>> exist as a separate history for the partial branch. When git-svn
>> fetches the revision at which this partial branch is merged back to
>> trunk, git-svn attempts to run merge-base to find a common ancestor.
>> However, because the partial branch has its own history, the
>> merge-base fails, and git-svn dies.
>>
>> Naively handling the exception with an eval block and skipping the
>> merge ticket works fine in that it brings us back to parity with git
>> 1.6.5.7, but it means that the merge parent relationship between trunk
>> and the partial branch is lost. Is there any way to preserve this
>> information, or does the separate commit history of the partial branch
>> make it fundamentally impossible?
>
> Hi Andrew,
>
> A method of preserving the $SVN_PATH <=> $PARENT@$REV mapping for
> reusing follow_parent-created branches is definitely desired.
>
> I've just been lacking time and motivation these days with other
> projects taking priority. Help (even if it's just to refactor/cleanup
> existing code) would definitely be appreciated here.
Thanks for the explanation, Eric. Unfortunately, I also don't have the time to commit to taking this on for the foreseeable future. I'll try to get my existing patches out in the next couple of days that at least fix the regressions from 1.6.5.7.
Regards,
Andrew
^ permalink raw reply
* Re: git file sharing/versioning.
From: Bas Driessen @ 2010-01-04 4:47 UTC (permalink / raw)
To: git
In-Reply-To: <1262580346.9041.20.camel@ams.xobas.net>
Hello,
I have a project where I have 2 trees with several hundreds of files.
Let's call them tree1 and tree2. Only a handful of files in tree2 are
different. What is the best way to set this up in GIT? Basically most
files in tree2 should act as a symbolic link to tree1. So if the file
changes in tree 1, it automatically changes in tree 2. Obviously, I
don't want to store everything double. Branching does not appear to be
an option as changes in tree1 would not be visible in the tree2 branch.
Any advise of how to set this up?
Thanks in advance for your help.
Bas.
--
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-04 5:31 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7v3a2mzzg4.fsf@alter.siamese.dyndns.org>
On Sun, Jan 03, 2010 at 12:49:15PM -0800, Junio C Hamano wrote:
> Linus Torvalds <torvalds@linux-foundation.org> writes:
>
> > Which means that if you put /usr/xpg4/bin before other paths in your PATH,
> > you'll totally break such systems, because now you get the (inferior)
> > tools in xpg4 before the preferred tools in /usr/local. Or - this also
> > happens - people end up installing their own versions in $HOME/bin,
> > because the system admin is uncaring or incompetent.
>
> The build allows you to define SANE_TOOL_PATH ("the tools found in here
> are saner than the ones in /usr/bin or /bin" is what it means) and we
> insert it just in front of /usr/bin or /bin in the original PATH (see
> git_brokne_path_fix in git-sh-setup.sh).
>
> I would call this the right thing (TM) or the best workaround we could do
> under the constraints, depending on the mood.
I agree that Solaris default tools are insane, but is there any reason
to munge the PATH for a single feature like external grep? Why not
EXTERNAL_GREP=/usr/xpg4/bin/grep (or /usr/local/bin/grep) in the
Makefile? Why not GIT_EXTERNAL_GREP=$HOME/bin/grep in the environment?
Obviously we still need SANE_TOOL_PATH for systems where the /usr/bin is
so crappy as to be unusable for our scripts. But surely we can do better
for individual tools where the user might have some more specific
preference about which tool he uses.
-Peff
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Junio C Hamano @ 2010-01-04 5:52 UTC (permalink / raw)
To: Jeff King
Cc: Junio C Hamano, Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy,
git
In-Reply-To: <20100104053125.GA5083@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> On Sun, Jan 03, 2010 at 12:49:15PM -0800, Junio C Hamano wrote:
>
>> Linus Torvalds <torvalds@linux-foundation.org> writes:
>>
>> > Which means that if you put /usr/xpg4/bin before other paths in your PATH,
>> > you'll totally break such systems, because now you get the (inferior)
>> > tools in xpg4 before the preferred tools in /usr/local. Or - this also
>> > happens - people end up installing their own versions in $HOME/bin,
>> > because the system admin is uncaring or incompetent.
>>
>> The build allows you to define SANE_TOOL_PATH ("the tools found in here
>> are saner than the ones in /usr/bin or /bin" is what it means) and we
>> insert it just in front of /usr/bin or /bin in the original PATH (see
>> git_brokne_path_fix in git-sh-setup.sh).
>>
>> I would call this the right thing (TM) or the best workaround we could do
>> under the constraints, depending on the mood.
>
> I agree that Solaris default tools are insane, but is there any reason
> to munge the PATH for a single feature like external grep? Why not
> EXTERNAL_GREP=/usr/xpg4/bin/grep (or /usr/local/bin/grep) in the
> Makefile? Why not GIT_EXTERNAL_GREP=$HOME/bin/grep in the environment?
That git-sh-setup "fix" is not for running external grep. It is for our
scripted Porcelains that rely on working basic tools (sed, tr, who knows
what else is broken).
In fact, our Makefile by default punts on external grep on Sun's. Run
"git grep NO_EXTERNAL_GREP -- Makefile" to see for yourself --- it would
work even on Solaris ;-)
> Obviously we still need SANE_TOOL_PATH for systems where the /usr/bin is
> so crappy as to be unusable for our scripts. But surely we can do better
> for individual tools where the user might have some more specific
> preference about which tool he uses.
>
> -Peff
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Mike Hommey @ 2010-01-04 6:06 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Miles Bader, Junio C Hamano, Nguyen Thai Ngoc Duy, git
In-Reply-To: <alpine.LFD.2.00.1001031124420.3630@localhost.localdomain>
On Sun, Jan 03, 2010 at 11:32:24AM -0800, Linus Torvalds wrote:
>
>
> On Sun, 3 Jan 2010, Miles Bader wrote:
> >
> > Since it's a general attribute of solaris that the default (/usr/bin)
> > tools are horrible sysv things and the actual useful tools are in
> > e.g. /usr/xpg4/bin, maybe it would be better to just try and add that
> > directory to the path...?
>
> There is no generic way to make solaris sane, I'm afraid.
>
> Everybody agrees that the "normal" Solaris tools are so horrible that they
> all set up some alternative. However, qutie often the preferred
> alternative is the GNU versions, mostly installed in /usr/local, and then
> they put that first in the path.
Or /usr/sfw, where Sun themselves ship some GNU tools
> Which means that if you put /usr/xpg4/bin before other paths in your PATH,
> you'll totally break such systems, because now you get the (inferior)
> tools in xpg4 before the preferred tools in /usr/local. Or - this also
> happens - people end up installing their own versions in $HOME/bin,
> because the system admin is uncaring or incompetent.
>
> In other words, there is no single normal or default Solaris installation
> that we can work around. The normal/default installation is so horrible
> that it's virtually never used in any environment where people actually
> have shell access and do development.
>
> Don't ask me why. EVERYBODY knows that the default /usr/bin is total crap.
> Even Sun people know. But there's apparently some very deep-seated reason
> (probably not technical, but mental/historical) why they can't be fixed or
> replaced, probably relating to "make world" and the whole build system.
There is simply no explanation for these tools to be that crappy at all.
The most common reason that is given for these tools to stay as crappy as
they always have been is for backwards compatibility. But how does that
prevent from adding features is beyond me. And on the other hand, they
*do* add features to their /usr/bin tools, such as -h in (at least) df
and ls.
Anyways, why not generate the hash-bang lines of the shell scripts from a
Makefile variable that would be set to /usr/xpg4/bin/sh on Solaris and
/bin/sh on others ?
Mike
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-04 6:44 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vbphaquwl.fsf@alter.siamese.dyndns.org>
On Sun, Jan 03, 2010 at 09:52:10PM -0800, Junio C Hamano wrote:
> > I agree that Solaris default tools are insane, but is there any reason
> > to munge the PATH for a single feature like external grep? Why not
> > EXTERNAL_GREP=/usr/xpg4/bin/grep (or /usr/local/bin/grep) in the
> > Makefile? Why not GIT_EXTERNAL_GREP=$HOME/bin/grep in the environment?
>
> That git-sh-setup "fix" is not for running external grep. It is for our
> scripted Porcelains that rely on working basic tools (sed, tr, who knows
> what else is broken).
Right, but I thought this thread was about external grep, and I thought
you were saying "if you want decent tools, you can use SANE_TOOL_PATH".
And I think we can do much better for that particular case than
recommending SANE_TOOL_PATH (but it seems that is not what you were
actually recommending).
But I admit, I have never really wanted to specify my own external grep.
Wanting your own grep for _features_ is probably insane, as some of your
greps (on worktree files) will use the external grep, and some (on
cached files) will not. So it is really just an optimization, and I
have never felt it so slow that I cared about messing with an
alternative grep on Solaris.
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?
> In fact, our Makefile by default punts on external grep on Sun's. Run
> "git grep NO_EXTERNAL_GREP -- Makefile" to see for yourself --- it would
> work even on Solaris ;-)
Yes, I am even mentioned in the commit log of 01ae841c. :)
-Peff
^ permalink raw reply
* A question about changing remote repo name
From: Dongas @ 2010-01-04 6:45 UTC (permalink / raw)
To: git
Hi ALL,
I'm running ubuntu 9.04 and the git coming along with it doesn't
support git remote rename command.
Below is the man page of it:
GIT-REMOTE(1)
Git Manual
GIT-REMOTE(1)
NAME
git-remote - manage set of tracked repositories
SYNOPSIS
git remote [-v | --verbose]
git remote add [-t <branch>] [-m <master>] [-f] [--mirror]
<name> <url>
git remote rm <name>
git remote show [-n] <name>
git remote prune [-n | --dry-run] <name>
git remote update [group]
Note: There's no rename option.
So i need to change the remote name manually.
I tried modifying the .git/config file locally but it didn't work.
Could someone help tell how to do it?
Thanks
Regards
Dongas
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-04 7:04 UTC (permalink / raw)
To: Mike Hommey
Cc: Linus Torvalds, Miles Bader, Junio C Hamano, Nguyen Thai Ngoc Duy,
git
In-Reply-To: <20100104060646.GA14520@glandium.org>
On Mon, Jan 04, 2010 at 07:06:46AM +0100, Mike Hommey wrote:
> Anyways, why not generate the hash-bang lines of the shell scripts from a
> Makefile variable that would be set to /usr/xpg4/bin/sh on Solaris and
> /bin/sh on others ?
We do that already (though we default it to /bin/bash). SANE_TOOL_PATH
is about picking up all the _other_ tools for use inside our shell
scripts, like non-crappy sed, grep, etc.
Brandon did some testing with ksh and sent a patch to default to the
stock ksh on Solaris and IRIX, which is probably saner than bash for a
default, but it seems to have gotten dropped:
http://article.gmane.org/gmane.comp.version-control.git/129830
-Peff
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Junio C Hamano @ 2010-01-04 7:08 UTC (permalink / raw)
To: Jeff King; +Cc: Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100104064408.GA7785@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> 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?
I vaguely recall that somebody fairly competent mentioned that modern grep
implementations are based on DFA engines, but I offhand don't remember if
the discussion had concrete numbers.
> Could we simply ship a better grep engine and obsolete external grep?
Yes, that is a very constructive longer term solution.
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Junio C Hamano @ 2010-01-04 7:14 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jeff King, Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vhbr2pcsh.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Jeff King <peff@peff.net> writes:
>
>> 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?
>
> I vaguely recall that somebody fairly competent mentioned that modern grep
> implementations are based on DFA engines, but I offhand don't remember if
> the discussion had concrete numbers.
I found only this one. The author was indeed somebody fairly competent.
http://thread.gmane.org/gmane.comp.version-control.git/23798
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-04 7:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7vhbr2pcsh.fsf@alter.siamese.dyndns.org>
On Sun, Jan 03, 2010 at 11:08:46PM -0800, Junio C Hamano 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?
>
> I vaguely recall that somebody fairly competent mentioned that modern grep
> implementations are based on DFA engines, but I offhand don't remember if
> the discussion had concrete numbers.
Probably this:
http://article.gmane.org/gmane.comp.version-control.git/41685
Also of interest is:
http://article.gmane.org/gmane.comp.version-control.git/50174
The pcre analysis there came from just using the "pcreposix" header, I
think. From my limited research, modern pcre may have some tuning
options (including a DFA engine!) that could do a lot better.
-Peff
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-04 7:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <7v4on2pciw.fsf@alter.siamese.dyndns.org>
On Sun, Jan 03, 2010 at 11:14:31PM -0800, Junio C Hamano wrote:
> > I vaguely recall that somebody fairly competent mentioned that modern grep
> > implementations are based on DFA engines, but I offhand don't remember if
> > the discussion had concrete numbers.
>
> I found only this one. The author was indeed somebody fairly competent.
>
> http://thread.gmane.org/gmane.comp.version-control.git/23798
Er, that link seems to be about internal grep beating external on a cold
cache because it does less I/O. Did you mean something else (maybe the
thread I pointed to in another message)?
-Peff
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Jeff King @ 2010-01-04 8:09 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Linus Torvalds, Miles Bader, Nguyen Thai Ngoc Duy, git
In-Reply-To: <20100104072659.GA10611@coredump.intra.peff.net>
On Mon, Jan 04, 2010 at 02:26:59AM -0500, Jeff King wrote:
> The pcre analysis there came from just using the "pcreposix" header, I
> think. From my limited research, modern pcre may have some tuning
> options (including a DFA engine!) that could do a lot better.
Hmm. I was able to get some improvements by using pcre_dfa_exec, but
still not as good as external grep. For "git grep 'foo.*bar'" in the
linux-2.6 repo, I got:
external grep: 0.76s
pcre_dfa_exec: 1.85s
pcre_exec: 3.21s
glibc: 4.00s
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.
By the way, you can see the abysmal performance of our internal code by
doing a "git grep foo". It uses the "fixed" internal engine and weighs
in at 3.24s on the same machine, _slower_ than pcre doing an actual
regex.
-Peff
^ permalink raw reply
* What's cooking in git.git (Jan 2010, #01; Mon, 04)
From: Junio C Hamano @ 2010-01-04 8:39 UTC (permalink / raw)
To: git
Here are the topics that have been cooking. Commits prefixed with '-' are
only in 'pu' while commits prefixed with '+' are in 'next'. The ones
marked with '.' do not appear in any of the integration branches, but I am
still holding onto them.
The tip of 'next' has been rebuilt on top of the current 'master'.
--------------------------------------------------
[New Topics]
* da/difftool (2009-12-22) 2 commits
- git-difftool: Add '--gui' for selecting a GUI tool
- t7800-difftool: Set a bogus tool for use by tests
* jh/gitweb-cached (2010-01-03) 4 commits
- gitweb: Makefile improvements
- gitweb: Optionally add "git" links in project list page
- gitweb: Add option to force version match
- gitweb: Load checking
* tc/test-locate-httpd (2010-01-02) 1 commit
- t/lib-http.sh: Restructure finding of default httpd location
* jc/fix-tree-walk (2009-09-14) 7 commits
- read-tree --debug-unpack
- unpack-trees.c: look ahead in the index
- unpack-trees.c: prepare for looking ahead in the index
- Aggressive three-way merge: fix D/F case
- traverse_trees(): handle D/F conflict case sanely
- more D/F conflict tests
- tests: move convenience regexp to match object names to test-lib.sh
Resurrected from "Ejected" category.
--------------------------------------------------
[Cooking]
* cc/reset-more (2010-01-04) 6 commits
(merged to 'next' on 2010-01-04 at 8802c2c)
+ Fix bit assignment for CE_CONFLICTED
(merged to 'next' on 2010-01-03 at f83d4c6)
+ "reset --merge": fix unmerged case
+ reset: use "unpack_trees()" directly instead of "git read-tree"
+ reset: add a few tests for "git reset --merge"
+ Documentation: reset: add some tables to describe the different options
+ reset: improve mixed reset error message when in a bare repo
* bg/maint-remote-update-default (2009-12-31) 1 commit
(merged to 'next' on 2010-01-03 at 113009e)
+ Fix "git remote update" with remotes.defalt set
* jc/branch-d (2009-12-29) 1 commit
- branch -d: base the "already-merged" safety on the branch it merges with
* jc/rerere (2009-12-04) 1 commit
- Teach --[no-]rerere-autoupdate option to merge, revert and friends
* jk/maint-1.6.5-reset-hard (2009-12-30) 1 commit
(merged to 'next' on 2010-01-02 at 190d63b)
+ reset: unbreak hard resets with GIT_WORK_TREE
* jk/push-to-delete (2009-12-30) 1 commit
(merged to 'next' on 2010-01-03 at 9ee293b)
+ builtin-push: add --delete as syntactic sugar for :foo
* 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
* mm/config-path (2009-12-30) 1 commit
(merged to 'next' on 2010-01-03 at 9c0e81a)
+ builtin-config: add --path option doing ~ and ~user expansion.
* pm/cvs-environ (2009-12-30) 1 commit
(merged to 'next' on 2010-01-03 at 4c22932)
+ CVS Server: Support reading base and roots from environment
* rs/maint-archive-match-pathspec (2009-12-12) 1 commit
(merged to 'next' on 2010-01-03 at 92d7d15)
+ archive: complain about path specs that don't match anything
* so/cvsserver-update (2009-12-07) 1 commit
(merged to 'next' on 2010-01-03 at 99959b6)
+ cvsserver: make the output of 'update' more compatible with cvs.
* tc/clone-v-progress (2009-12-26) 4 commits
- clone: use --progress to force progress reporting
- clone: set transport->verbose when -v/--verbose is used
- git-clone.txt: reword description of progress behaviour
- check stderr with isatty() instead of stdout when deciding to show progress
* tc/smart-http-restrict (2010-01-02) 4 commits
- Smart-http tests: Test http-backend without curl or a webserver
- Smart-http tests: Break test t5560-http-backend into pieces
- Smart-http tests: Improve coverage in test t5560
- Smart-http: check if repository is OK to export before serving it
* tr/maint-1.6.5-bash-prompt-show-submodule-changes (2009-12-31) 1 commit
(merged to 'next' on 2010-01-03 at b785974)
+ bash completion: factor submodules into dirty state
* jc/cache-unmerge (2009-12-25) 9 commits
- rerere forget path: forget recorded resolution
- rerere: refactor rerere logic to make it independent from I/O
- rerere: remove silly 1024-byte line limit
- resolve-undo: teach "update-index --unresolve" to use resolve-undo info
- resolve-undo: "checkout -m path" uses resolve-undo information
- resolve-undo: allow plumbing to clear the information
- resolve-undo: basic tests
- resolve-undo: record resolved conflicts in a new index extension section
- builtin-merge.c: use standard active_cache macros
* js/filter-branch-prime (2009-12-15) 1 commit
(merged to 'next' on 2010-01-03 at 7c90319)
+ filter-branch: remove an unnecessary use of 'git read-tree'
* mg/tag-d-show (2009-12-10) 1 commit
(merged to 'next' on 2010-01-03 at 87657d2)
+ tag -d: print sha1 of deleted tag
* sb/maint-octopus (2009-12-11) 3 commits
(merged to 'next' on 2010-01-03 at ffe77d6)
+ octopus: remove dead code
+ octopus: reenable fast-forward merges
+ octopus: make merge process simpler to follow
* jh/commit-status (2009-12-07) 1 commit
- [test?] Add commit.status, --status, and --no-status
* jc/checkout-merge-base (2009-11-20) 2 commits
(merged to 'next' on 2010-01-02 at 6a8f6fc)
+ "rebase --onto A...B" replays history on the merge base between A and B
+ "checkout A...B" switches to the merge base between A and B
* tr/http-push-ref-status (2009-12-24) 6 commits
- transport-helper.c::push_refs(): emit "no refs" error message
- transport-helper.c::push_refs(): ignore helper-reported status if ref is not to be pushed
- transport.c::transport_push(): make ref status affect return value
- refactor ref status logic for pushing
- t5541-http-push.sh: add test for unmatched, non-fast-forwarded refs
- t5541-http-push.sh: add tests for non-fast-forward pushes
* bg/maint-add-all-doc (2009-12-07) 4 commits
(merged to 'next' on 2010-01-03 at b19a323)
+ squash! rm documentation--also mention add-u where we mention commit-a
+ git-rm doc: Describe how to sync index & work tree
+ git-add/rm doc: Consistently back-quote
+ Documentation: 'git add -A' can remove files
* il/vcs-helper (2009-12-09) 8 commits
- Remove special casing of http, https and ftp
- Support remote archive from all smart transports
- Support remote helpers implementing smart transports
- Support taking over transports
- Refactor git transport options parsing
- Pass unknown protocols to external protocol handlers
- Support mandatory capabilities
- Add remote helper debug mode
* mm/diag-path-in-treeish (2009-12-07) 1 commit
- Detailed diagnosis when parsing an object name fails.
* mh/rebase-fixup (2009-12-07) 2 commits
- Add a command "fixup" to rebase --interactive
- t3404: Use test_commit to set up test repository
(this branch is used by ns/rebase-auto-squash.)
Initial round of "fixup" action that is similar to "squash" action in
"rebase -i" that excludes the commit log message from follow-up commits
when composing the log message for the updated one. Expected is a further
improvement to skip opening the editor if a pick is followed only by
"fixup" and no "squash".
* ns/rebase-auto-squash (2009-12-08) 2 commits
- fixup! rebase -i --autosquash
- rebase -i --autosquash: auto-squash commits
(this branch uses mh/rebase-fixup.)
* jh/notes (2009-12-07) 11 commits
- Refactor notes concatenation into a flexible interface for combining notes
- Notes API: Allow multiple concurrent notes trees with new struct notes_tree
- Notes API: for_each_note(): Traverse the entire notes tree with a callback
- Notes API: get_note(): Return the note annotating the given object
- Notes API: add_note(): Add note objects to the internal notes tree structure
- Notes API: init_notes(): Initialize the notes tree from the given notes ref
- Notes API: get_commit_notes() -> format_note() + remove the commit restriction
- Minor style fixes to notes.c
(merged to 'next' on 2010-01-02 at ae42130)
+ Add more testcases to test fast-import of notes
+ Rename t9301 to t9350, to make room for more fast-import tests
+ fast-import: Proper notes tree manipulation
* fc/opt-quiet-gc-reset (2009-12-02) 1 commit
- General --quiet improvements
* mv/commit-date (2009-12-03) 2 commits
(merged to 'next' on 2010-01-03 at 1c45fdf)
+ Document date formats accepted by parse_date()
+ builtin-commit: add --date option
* sr/gfi-options (2009-12-04) 7 commits
- fast-import: add (non-)relative-marks feature
- fast-import: allow for multiple --import-marks= arguments
- fast-import: test the new option command
- fast-import: add option command
- fast-import: add feature command
- fast-import: put marks reading in its own function
- fast-import: put option parsing code in separate functions
* ap/merge-backend-opts (2008-07-18) 6 commits
- Document that merge strategies can now take their own options
- Extend merge-subtree tests to test -Xsubtree=dir.
- Make "subtree" part more orthogonal to the rest of merge-recursive.
- Teach git-pull to pass -X<option> to git-merge
- git merge -X<option>
- git-merge-file --ours, --theirs
"git pull" patch needs sq-then-eval fix to protect it from $IFS
but otherwise seemed good.
* mo/bin-wrappers (2009-12-02) 3 commits
(merged to 'next' on 2010-01-03 at 8c5fa27)
+ INSTALL: document a simpler way to run uninstalled builds
+ run test suite without dashed git-commands in PATH
+ build dashless "bin-wrappers" directory similar to installed bindir
* tr/http-updates (2009-12-28) 4 commits
(merged to 'next' on 2010-01-02 at cf25698)
+ Remove http.authAny
+ Allow curl to rewind the RPC read buffer
+ Add an option for using any HTTP authentication scheme, not only basic
+ http: maintain curl sessions
* nd/sparse (2009-12-30) 23 commits
(merged to 'next' on 2010-01-02 at 5499bbe)
+ grep: do not do external grep on skip-worktree entries
+ commit: correctly respect skip-worktree bit
+ ie_match_stat(): do not ignore skip-worktree bit with CE_MATCH_IGNORE_VALID
+ tests: rename duplicate t1009
+ sparse checkout: inhibit empty worktree
+ Add tests for sparse checkout
+ read-tree: add --no-sparse-checkout to disable sparse checkout support
+ unpack-trees(): ignore worktree check outside checkout area
+ unpack_trees(): apply $GIT_DIR/info/sparse-checkout to the final index
+ unpack-trees(): "enable" sparse checkout and load $GIT_DIR/info/sparse-checkout
+ unpack-trees.c: generalize verify_* functions
+ unpack-trees(): add CE_WT_REMOVE to remove on worktree alone
+ Introduce "sparse checkout"
+ dir.c: export excluded_1() and add_excludes_from_file_1()
+ excluded_1(): support exclude files in index
+ unpack-trees(): carry skip-worktree bit over in merged_entry()
+ Read .gitignore from index if it is skip-worktree
+ Avoid writing to buffer in add_excludes_from_file_1()
+ Teach Git to respect skip-worktree bit (writing part)
+ Teach Git to respect skip-worktree bit (reading part)
+ Introduce "skip-worktree" bit in index, teach Git to get/set this bit
+ Add test-index-version
+ update-index: refactor mark_valid() in preparation for new options
^ permalink raw reply
* Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johannes Schindelin @ 2010-01-04 9:44 UTC (permalink / raw)
To: Jens Lehmann
Cc: Git Mailing List, Junio C Hamano, Shawn O. Pearce, Paul Mackerras,
Heiko Voigt, Lars Hjemli
In-Reply-To: <4B3F6742.6060402@web.de>
Hi,
On Sat, 2 Jan 2010, Jens Lehmann wrote:
> Now that we have much better output when displaying diffs of submodules
> in git gui and gitk (many thanks to all involved!), another usability
> issue shows up: A dirty working directory of a submodule isn't visible
> in git gui or gitk.
>
> So you might think a "submodule update" would be ok - as you see no
> changes - just too see it fail because the submodules working directory
> is dirty.
>
> Or - even worse - you /think/ you committed your changes in a submodule
> while you didn't. That can lead to 'interesting' problems which can be
> pretty hard to diagnose (like breaking builds on other peoples
> machines).
>
>
> A possible solution could look like this:
>
> AFAICS, git gui and gitk use "git diff-files" both to get the file names
> of unstaged local changes and to later display the actual differences.
>
> If they could tell the diff core to also check the submodule working
> directories and to output an extra line - maybe something like
> "Submodule <name> contains uncommitted local changes" - when a
> submodules working directory is dirty, git gui and gitk could show the
> submodules state adequately.
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.
The implementation might be a bit tricky as parts of Git's source code
still use the_index, but at least adding the submodule's object database
is no longer that difficult.
Ciao,
Dscho
^ permalink raw reply
* Re: [PATCH] grep: do not do external grep on skip-worktree entries
From: Nguyen Thai Ngoc Duy @ 2010-01-04 10:14 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, Linus Torvalds, Miles Bader, git
In-Reply-To: <7vbphaquwl.fsf@alter.siamese.dyndns.org>
On Mon, Jan 4, 2010 at 12:52 PM, Junio C Hamano <gitster@pobox.com> wrote:
>> I agree that Solaris default tools are insane, but is there any reason
>> to munge the PATH for a single feature like external grep? Why not
>> EXTERNAL_GREP=/usr/xpg4/bin/grep (or /usr/local/bin/grep) in the
>> Makefile? Why not GIT_EXTERNAL_GREP=$HOME/bin/grep in the environment?
>
> That git-sh-setup "fix" is not for running external grep. It is for our
> scripted Porcelains that rely on working basic tools (sed, tr, who knows
> what else is broken).
>
> In fact, our Makefile by default punts on external grep on Sun's. Run
> "git grep NO_EXTERNAL_GREP -- Makefile" to see for yourself --- it would
> work even on Solaris ;-)
A bit off-topic. But it seems to me on linux (main development
platform?) GNU grep may be tested more than the builtin grep because
NO_EXTERNAL_GREP would be undefined by default. Should we test both
greps in that case?
--
Duy
^ permalink raw reply
* Re: [PATCH] git-update-index: report(...) now flushes stdout after printing the report line
From: Sebastian Thiel @ 2010-01-04 10:30 UTC (permalink / raw)
Cc: git
In-Reply-To: <be6fef0d1001031503h11cb65c6ha34eee345b9b7055@mail.gmail.com>
Thanks Ray Chuan, for the clarification, the progress is supposed to
be sent in git-push and git-fetch ( not git-pull as I mentioned ).
A --progress flag would already do it for me, is there a way to fetch
your code from somewhere for a test run ?
When do you think will your changes be available for a mainline merge,
or would it even be possible to separate the --progress adjustment
from your feature to merge it into mainline individually ?
Thanks,
Sebastian
^ permalink raw reply
* Re: RFC: display dirty submodule working directory in git gui and gitk
From: Heiko Voigt @ 2010-01-04 10:44 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>
Hi,
Johannes 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).
Do you mean the complete workflow (submodules are links to other git repos)
or the current implementation? Do you have links to other design
approaches/threads? Would be nice if we could take that into account for any
decision.
cheers Heiko
^ permalink raw reply
* submodules, was Re: RFC: display dirty submodule working directory in git gui and gitk
From: Johannes Schindelin @ 2010-01-04 11:46 UTC (permalink / raw)
To: Heiko Voigt
Cc: Jens Lehmann, Git Mailing List, Junio C Hamano, Shawn O. Pearce,
Paul Mackerras, Lars Hjemli
In-Reply-To: <61083.85.16.196.198.1262601871.squirrel@archive.darksea.de>
Hi,
On Mon, 4 Jan 2010, Heiko Voigt wrote:
> Johannes 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).
>
> Do you mean the complete workflow (submodules are links to other git
> repos) or the current implementation? Do you have links to other design
> approaches/threads? Would be nice if we could take that into account for
> any decision.
Unfortunately, I do not have any information about different approaches
except the approach Subversion takes. While Subversion's externals are
not perfect for all applications, for some, they are. So I consider this
a serious shortcoming that Git does not support that workflow (and in
fact, AFAIR Shawn's repo does not use submodules for that exact reason).
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.)
Ciao,
Dscho
^ permalink raw reply
* Beginner's question on how to use git for multiple parallel versions
From: Christian C. Schouten @ 2010-01-04 11:29 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 1131 bytes --]
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.
I read about branching, merging, rebasing and cherry-picking commits but I don’t get it yet.
Can anyone enlighten me on how I should approach this in a way that I can maintain easily
throughout future development for my situation?
Thanks in advance for any pointers,
Best,
Chris
^ permalink raw reply
* [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
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