* Re: [PATCH] unset GREP_OPTIONS in test-lib.sh
From: Junio C Hamano @ 2009-11-23 18:27 UTC (permalink / raw)
To: Carlo Marcelo Arenas Belon; +Cc: Ren? Scharfe, Junio C Hamano, Bert Wesarg, git
In-Reply-To: <20091123112221.GA7175@sajinet.com.pe>
Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe> writes:
> why not better to apply the proposed patch from Junio in :
>
> http://article.gmane.org/gmane.comp.version-control.git/127980/
>
> it would IMHO correct all reported issues and serve as well as a catch
> all from other tools that could be introduced in the future and that
> will be similarly affected by this misfeature.
I think René's patch is more sensible than $gmane/127980 because we have
no business mucking with these environment variables when we are running
things other than external grep. You could be using system's "grep" in
your pre-commit hook to find some stuff, and your hook either may rely
on your having a particular set of GREP_OPTIONS in your environment, or
may be designed to work well with GREP_OPTIONS.
^ permalink raw reply
* Re: [PATCH] t/gitweb-lib: Split HTTP response with non-GNU sed
From: Junio C Hamano @ 2009-11-23 18:27 UTC (permalink / raw)
To: Brian Gernhardt; +Cc: Git List, Jakub Narebski
In-Reply-To: <1258997622-62403-1-git-send-email-brian@gernhardtsoftware.com>
Brian Gernhardt <brian@gernhardtsoftware.com> writes:
> Recognizing \r in a regex is something GNU sed will do, but other sed
> implementation's won't. (Found with BSD sed on OS X.) So use a
> literal carriage return instead.
I'd actually prefer not having to deal with this issue. How about doing
something like this instead?
t/gitweb-lib.sh | 14 ++++++++++++--
1 files changed, 12 insertions(+), 2 deletions(-)
diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
index 32b841d..3121950 100644
--- a/t/gitweb-lib.sh
+++ b/t/gitweb-lib.sh
@@ -52,8 +52,18 @@ gitweb_run () {
rm -f gitweb.log &&
perl -- "$SCRIPT_NAME" \
>gitweb.output 2>gitweb.log &&
- sed -e '/^\r$/q' <gitweb.output >gitweb.headers &&
- sed -e '1,/^\r$/d' <gitweb.output >gitweb.body &&
+ perl -w -e '
+ open O, ">gitweb.headers";
+ while (<>) {
+ print O;
+ last if (/^\r$/ || /^$/);
+ }
+ open O, ">gitweb.body";
+ while (<>) {
+ print O;
+ }
+ close O;
+ ' gitweb.output &&
if grep '^[[]' gitweb.log >/dev/null 2>&1; then false; else true; fi
# gitweb.log is left for debugging
^ permalink raw reply related
* Re: OS X and umlauts in file names
From: Martin Langhoff @ 2009-11-23 18:29 UTC (permalink / raw)
To: Thomas Singer; +Cc: Thomas Rast, git
In-Reply-To: <4B0AD02E.1040408@syntevo.com>
On Mon, Nov 23, 2009 at 7:10 PM, Thomas Singer
<thomas.singer@syntevo.com> wrote:
> I can't simply tunnel the file name as byte array to the
> invoked Git command - I simply don't know how to transform the characters of
> the file name to a representation the Git command line client will
> understand[2].
Ouch - so git is respecting whatever name the user and/or OS have
picked, but Java wants to canonicalize it, and whatever scheme it
uses does not match OSX? That must hurt Java usage on OSX a lot. Sure
they have a workaround...?
Suggestions:
1 - Configure Java to canonicalize in the same style as OSX. Actually,
OSX's canonicalization is somewhat arbitrary so I think it exposes a
call to canonicalize a string "the right way".
2 - Many git calls accept filenames via STDIN - Java will surely write
binary there...
3 - xargs with its -z parameter can complement #2
hth,
m
--
martin.langhoff@gmail.com
martin@laptop.org -- School Server Architect
- ask interesting questions
- don't get distracted with shiny stuff - working code first
- http://wiki.laptop.org/go/User:Martinlanghoff
^ permalink raw reply
* Re: [PATCH] pack-objects: split implications of --all-progress from progress activation
From: Nicolas Pitre @ 2009-11-23 18:27 UTC (permalink / raw)
To: Petr Baudis; +Cc: Junio C Hamano, Jeff King, bill lam, git
In-Reply-To: <20091123181206.GD26996@machine.or.cz>
On Mon, 23 Nov 2009, Petr Baudis wrote:
> On Mon, Nov 23, 2009 at 12:43:50PM -0500, Nicolas Pitre wrote:
> > Currently the --all-progress flag is used to use force progress display
> > during the writing object phase even if output goes to stdout which is
> > primarily the case during a push operation. This has the unfortunate
> > side effect of forcing progress display even if stderr is not a
> > terminal.
> >
> > Let's introduce the --all-progress-implied argument which has the same
> > intent except for actually forcing the activation of any progress
> > display. With this, progress display will be automatically inhibited
> > whenever stderr is not a terminal, or full progress display will be
> > included otherwise. This should let people use 'git push' within a cron
> > job without filling their logs with useless percentage displays.
> >
> > Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
>
> Ok, but what is currently the way to force the old behaviour?
If any existing out-of-tree users of pack-objects were using
--all-progress then nothing has changed for them.
> I believe that should be also part of the commit message.
>
> Naive deduction fails:
>
> $ git remote update --progress
> error: unknown option `progress'
Usage of 'git remote" is about fetching and not pushing, right? My patch
only affects pushes. So I don't know what old behavior you're after.
Nicolas
^ permalink raw reply
* Re: [PATCH] t/gitweb-lib: Split HTTP response with non-GNU sed
From: Brian Gernhardt @ 2009-11-23 18:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git List, Jakub Narebski
In-Reply-To: <7vocmtyu3v.fsf@alter.siamese.dyndns.org>
On Nov 23, 2009, at 1:27 PM, Junio C Hamano wrote:
> Brian Gernhardt <brian@gernhardtsoftware.com> writes:
>
>> Recognizing \r in a regex is something GNU sed will do, but other sed
>> implementation's won't. (Found with BSD sed on OS X.) So use a
>> literal carriage return instead.
>
> I'd actually prefer not having to deal with this issue. How about doing
> something like this instead?
Works for me. I just went for the obvious minimal change to make it work. But since we're testing a perl script, we might as well just use perl to deal with it's output.
~~ Brian
^ permalink raw reply
* Re: [PATCH] pack-objects: split implications of --all-progress from progress activation
From: Petr Baudis @ 2009-11-23 19:04 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Jeff King, bill lam, git
In-Reply-To: <alpine.LFD.2.00.0911231323010.2059@xanadu.home>
On Mon, Nov 23, 2009 at 01:27:14PM -0500, Nicolas Pitre wrote:
> On Mon, 23 Nov 2009, Petr Baudis wrote:
> > Naive deduction fails:
> >
> > $ git remote update --progress
> > error: unknown option `progress'
>
> Usage of 'git remote" is about fetching and not pushing, right? My patch
> only affects pushes. So I don't know what old behavior you're after.
Oh, I'm sorry, in that case I was confused from the very beginning;
somehow I saw pull instead of push in the initial mail.
Petr "Pasky" Baudis
^ permalink raw reply
* Re: how to suppress progress percentage in git-push
From: Jeff King @ 2009-11-23 19:25 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: bill lam, git
In-Reply-To: <alpine.LFD.2.00.0911231043310.2059@xanadu.home>
On Mon, Nov 23, 2009 at 11:56:43AM -0500, Nicolas Pitre wrote:
> > We need to do one of:
> >
> > 1. make --all-progress imply "if we are using progress, then make it
> > more verbose. Otherwise, ignore."
> >
> > 2. fix all callers to check isatty(2) before unconditionally passing
> > the option
>
> None of the above would fix the issue as this only affects progress
> display for phase #3. You'd still get progress display for the counting
> phase and the compressing phase.
I think it does fix the issue, as it is exactly the side effect that we
are concerned about (and I tested my patch for 1, which squelched it).
But your --all-progress-implied is a better fix, so I think we should go
with that.
> That doesn't mean it is OK for send-pack to unconditionally use
> --all-progress though, although it does provide the -q argument to
> pack-objects when push -q is used which inhibits any progress display
> already.
It does, and I almost suggested that (although -q is new as of 1.6.5, so
it may not help the original poster). But "-q" actually does more than
that; it also silences any output for a successful push, which may not
be desired.
-Peff
^ permalink raw reply
* Re: how to suppress progress percentage in git-push
From: Jeff King @ 2009-11-23 19:28 UTC (permalink / raw)
To: Petr Baudis; +Cc: bill lam, Nicolas Pitre, git
In-Reply-To: <20091123170547.GC26996@machine.or.cz>
On Mon, Nov 23, 2009 at 06:05:47PM +0100, Petr Baudis wrote:
> > You wouldn't need to do anything that drastic. You would just need to
> > pass "--progress --all-progress" instead of only --all-progress. But you
> > have provided the data point that such a change would break at least one
> > user.
> >
> > We could also leave --all-progress as-is and add new option to mean "if
> > you are already doing progress, do all progress".
>
> Hmm, maybe I'm confused - I just call
>
> git remote update
>
> and don't pass any progress switches - would your change still affect
> me? Can I pass --progress to `git remote update`?
Oh, I misunderstood; I thought you were calling pack-objects directly.
So you are actually relying on the "even though isatty(2) is not true,
we always print progress messages" behavior? I think that behavior is
buggy. It hurts everybody pushing via cron, and it violates the usual
rule for when we show progress messages.
I don't think you can get a --progress pushed all the way down to the
pack-objects in this case; we would need to add code to override the
isatty check.
That being said, your example of "remote update" means you are dealing
with fetch, and we are not touching the fetch code path at all.
-Peff
^ permalink raw reply
* Re: [PATCH] pack-objects: split implications of --all-progress from progress activation
From: Jeff King @ 2009-11-23 19:32 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: Junio C Hamano, Petr Baudis, bill lam, git
In-Reply-To: <alpine.LFD.2.00.0911231221320.2059@xanadu.home>
On Mon, Nov 23, 2009 at 12:43:50PM -0500, Nicolas Pitre wrote:
> Currently the --all-progress flag is used to use force progress display
> during the writing object phase even if output goes to stdout which is
> primarily the case during a push operation. This has the unfortunate
> side effect of forcing progress display even if stderr is not a
> terminal.
>
> Let's introduce the --all-progress-implied argument which has the same
> intent except for actually forcing the activation of any progress
> display. With this, progress display will be automatically inhibited
> whenever stderr is not a terminal, or full progress display will be
> included otherwise. This should let people use 'git push' within a cron
> job without filling their logs with useless percentage displays.
>
> Signed-off-by: Nicolas Pitre <nico@fluxnic.net>
Thanks,
Tested-by: Jeff King <peff@peff.net>
-Peff
^ permalink raw reply
* Re: how to suppress progress percentage in git-push
From: Nicolas Pitre @ 2009-11-23 19:40 UTC (permalink / raw)
To: Jeff King; +Cc: bill lam, git
In-Reply-To: <20091123192518.GA1607@coredump.intra.peff.net>
On Mon, 23 Nov 2009, Jeff King wrote:
> On Mon, Nov 23, 2009 at 11:56:43AM -0500, Nicolas Pitre wrote:
>
> > > We need to do one of:
> > >
> > > 1. make --all-progress imply "if we are using progress, then make it
> > > more verbose. Otherwise, ignore."
> > >
> > > 2. fix all callers to check isatty(2) before unconditionally passing
> > > the option
> >
> > None of the above would fix the issue as this only affects progress
> > display for phase #3. You'd still get progress display for the counting
> > phase and the compressing phase.
>
> I think it does fix the issue, as it is exactly the side effect that we
> are concerned about (and I tested my patch for 1, which squelched it).
Sorry, you were right. I somehow understood something else initially.
> But your --all-progress-implied is a better fix, so I think we should go
> with that.
OK.
Nicolas
^ permalink raw reply
* git-apply fails on creating a new file, with both -p and --directory specified
From: Steven J. Murdoch @ 2009-11-23 19:45 UTC (permalink / raw)
To: git
While trying to apply a patch from one repository (created by
git-format-patch), to another (using git-am), git fails with:
"fatal: git apply: bad git-diff - inconsistent new filename on line X"
This appears to be because I was both using -p to strip some path
components, and --directory to add different ones in. Only creating
new files was affected.
This was the case in git 1.6.5.2, and also the development version
1.6.6.rc0.15.g4fa80. I have tested this on MacOS X Snow Leopard.
This appears related to the bug discussed in:
http://marc.info/?l=git&m=122237537312597&w=2
in which the following fix was posted:
http://git.kernel.org/?p=git/git.git;a=commitdiff;h=969c877506cf8cc760c7b251fef6c5b6850bfc19
I have included a patch below to the test cases, which currently fails
but, if I understand correctly, should succeed.
Steven Murdoch.
-- >8 --
Test git-apply creating a new file, combining --directory and -p flags
Signed-off-by: Steven Murdoch <Steven.Murdoch@cl.cam.ac.uk>
---
t/t4128-apply-root.sh | 17 +++++++++++++++++
1 files changed, 17 insertions(+), 0 deletions(-)
diff --git a/t/t4128-apply-root.sh b/t/t4128-apply-root.sh
index 8f6aea4..6cc741a 100755
--- a/t/t4128-apply-root.sh
+++ b/t/t4128-apply-root.sh
@@ -58,6 +58,23 @@ test_expect_success 'apply --directory (new file)' '
'
cat > patch << EOF
+diff --git a/c/newfile2 b/c/newfile2
+new file mode 100644
+index 0000000..d95f3ad
+--- /dev/null
++++ b/c/newfile2
+@@ -0,0 +1 @@
++content
+EOF
+
+test_expect_success 'apply --directory -p (new file)' '
+ git reset --hard initial &&
+ git apply -p2 --directory=some/sub/dir/ --index patch &&
+ test content = $(git show :some/sub/dir/newfile2) &&
+ test content = $(cat some/sub/dir/newfile2)
+'
+
+cat > patch << EOF
diff --git a/delfile b/delfile
deleted file mode 100644
index d95f3ad..0000000
--
1.6.5.2
--
http://www.cl.cam.ac.uk/users/sjm217/
^ permalink raw reply related
* Re: [PATCH] send-email: new 'add-envelope' option
From: Felipe Contreras @ 2009-11-23 20:13 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jeff King, git
In-Reply-To: <7v6392h2d9.fsf@alter.siamese.dyndns.org>
On Sun, Nov 22, 2009 at 7:54 PM, Junio C Hamano <gitster@pobox.com> wrote:
> You can say that if you want to be difficult to work with, or you can be
> that somebody yourself and make a difference.
Being difficult to work with goes both ways. You as a maintainer are
entitled to say "I won't accept this without test cases", and I as a
contributor am entitled to say "I'm not going to do that". Since I'm
doing this on my free time I'd rather work on the things I like, which
doesn't include writing test cases from scratch, primarily because I'm
not familiar with them.
> Let me show you that we can be constructive for a change ;-)
>
> How about something trivial like this?
Looks good to me, but again, that doesn't say much.
Cheers.
--
Felipe Contreras
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Daniel Barkalow @ 2009-11-23 20:26 UTC (permalink / raw)
To: Thomas Singer; +Cc: git
In-Reply-To: <4B0ABA42.1060103@syntevo.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 1860 bytes --]
On Mon, 23 Nov 2009, Thomas Singer wrote:
> I'm on an English OS X 10.6.2 and I created a sample file with umlauts in
> its name (Überlänge.txt). When I try to stage the file in the terminal, I
> can't complete the file name by typing the Ü and hitting the tab key, but I
> can complete it by typing an U and hitting the tab key.
You've already got a bug before involving git at all. You create a
file "Überlänge.txt", but OS X writes "U:berla:nge.txt" (typing the
combining character umlaut as : so that you can see the difference), and
the directory listing doesn't contain any files that start with Ü, so the
terminal already can't find the file you created. Obviously, git is going
to have all the problems that the OS-provided readline library has, and
you're not going to be able to get predictable results in any case where
user-supplied filenames are compared with directory listings.
Part of the problem is that OS X does a canonicalization that is not what
anybody else does, so you hit the problem every single time, but the
fundamental issue is that there isn't any way to tell, when you create a
file, what name that file will be listed under.
Note that this isn't a matter of characters to byte sequences. OS X
actually uses different characters for the filename in its listings than
you've used.
If there's a difference between German and English versions, I suspect
that it's actually that you're not using a German keyboard with a key
that, under OS X, produces the two-character sequence U:, but using some
method that produces the single character Ü. I'd guess that your SmartGit
problem is that Java is converting the U: that the user typed into Ü, and
passing it to the OS, which turns it back into U: and then doesn't list
the file that Java thinks the user asked for.
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* Re: OS X and umlauts in file names
From: Thomas Singer @ 2009-11-23 20:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Rast, git
In-Reply-To: <alpine.DEB.1.00.0911231916510.4897@intel-tinevez-2-302>
I agree, that getting it done correctly could be a long and hard (maybe
incompatible) way. Neglecting the problem or blaming platform specific
"anomalies" does not help to solve that serious real-world problem for the
end-user. IMHO, telling a user to not use non-US-ASCII characters in file
names to stay platform-independent seems not to be state-of-the-art and
would exclude a lot of users world-wide. Finally, everyone would expect Git
to be better than CVS, also at this point.
But what about getting it working "somehow" on OS X in a few minutes? What
should I do to be able to stage/commit/work with files containing umlauts in
their name on my English OS X (by specifying the file names) as it seems to
work magically on a German OS X? Is this topic already /documented/
somewhere (I couldn't find something)?
Thanks in advance,
Tom
Johannes Schindelin wrote:
> Hi,
>
> On Mon, 23 Nov 2009, Thomas Singer wrote:
>
>> Basically, getting it "somehow" to work on OS X is just one minor step.
>> IMHO Git should standardize on file names in the repository and do the
>> platform-specific conversion independent of any locale setting, if
>> needed.
>
> That is contrary to the design of Git which honors content (byte-wise!) as
> much as possible, and treats file names very much as content.
>
> There were beginnings of supporting OSX' brain-damaged filename mangling,
> but an obnoxious OSX fan worked very hard on trying to defend the OSX
> design and to decry Git's respect for the raw bytes on this list, so hard
> that even the nicest developers had no fun working on this issue anymore.
>
> This little background may help you understand why there is no solution
> implemented in Git yet. And maybe quite a few developers are reluctant to
> discuss the issue and possible solutions due to said sad story, too.
>
> Ciao,
> Dscho
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
>
^ permalink raw reply
* Re: [PATCH 2/4] fast-import: define a new option command
From: Shawn O. Pearce @ 2009-11-23 20:50 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: Johannes Schindelin, Git List, Junio C Hamano
In-Reply-To: <fabb9a1e0911230939m56e20812o939456c41becf5fd@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> I think the simplest is to allow the stream to specify a marks file
> exactly once, and commandline arguments override what's in the stream.
> Listing import-marks on the commandline is still valid and keeps the
> old behavior.
>
> Sensible?
Yes.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 2/2] remote-curl.c: fix rpc_out()
From: Shawn O. Pearce @ 2009-11-23 21:04 UTC (permalink / raw)
To: Tay Ray Chuan; +Cc: git, Junio C Hamano
In-Reply-To: <20091123110338.2b230359.rctay89@gmail.com>
If I understand the change right, the only thing that really matters
here is removing the extra ';' in the if (max < avail) condition.
That bug was the only reason why rpc->len < rpc->pos, and is thus
the only reason why avail would "go negative" (which it can't do
since its unsigned, it just wrapped around to a massive value).
Tay Ray Chuan <rctay89@gmail.com> wrote:
> Use comparisons between rpc->len and rpc->pos, rather than computing
> their difference. This avoids potential errors when this value is
> negative and we access it.
I don't see this as being very relevant here.
> Use an int to store the return value from packet_read_line(), instead
> of a size_t.
Why? The code is actually harder to follow. packet_read_line does
not return a negative value.
> Handle the errorneous condition where rpc->pos exceeds rpc->len by
> printing a message and aborting the transfer (return 0).
This condition should be impossible. It only occurred because of
the bug you were trying to fix, which is this one next item:
> Remove extraneous semicolon (';') at the end of the if statement, that
> prevented code in its block from executing.
Right. This bug is really bad and should be fixed. But the message
above make this some little after-thought and doesn't explain what
was wrong with this being here.
> ---
>
> Users might experience issues when pushing with chunked encoding when
> size_t avail is negative.
Shouldn't this be in the commit message? Or something about how
pushing with chunked encoding was broken if the push was larger
than the default buffer size of 1 MiB?
--
Shawn.
^ permalink raw reply
* [PATCH RFC] git-send-email --expand-aliases
From: Alex Chiang @ 2009-11-23 22:16 UTC (permalink / raw)
To: gitster; +Cc: catalin.marinas, git
I'm an StGit user, and while StGit has its own 'stg mail'
feature, it doesn't know how to expand email aliases (yet).
Certainly, one way to solve that problem would be to hack stgit
so that it can parse alias files, but to me, that seems silly
when git-send-email can already do that.
This patch teaches git-send-email to only expand email addresses
so that other git porcelains don't have to roll their own mail
alias parsers.
I imagine the internal implementation of stg mail to work
something like:
call git-send-email --expand-aliases repeatedly, once for
all the combined --to= args, then for all the combined --cc= args,
and finally for all the combined --bcc= args (all passed
to stg mail), read from stdout until EOF
That API is a little ugly, requiring 3 calls to git-send-email
for each class of recipient (to, cc, bcc).
The other interface that I thought of would be to have
git-send-email print a heading like:
TO
<expanded alias 1>
<expanded alias 2>
CC
<expanded alias 3>
BCC
<expanded alias 4>
But, that requires more parsing in the porcelain. Requiring a
call to git-send-email for each class of recipient seems like a
reasonable interface for what will presumably be an API only used
in an automated manner by a porcelain like stg (and possibly
guilt?).
I haven't patched stg yet, wanted to see what the feedback on
this RFC patch was first. If folks are receptive, I can send a
fuller patch with expanded help text, etc.
Thanks,
/ac
---
diff --git a/git-send-email.perl b/git-send-email.perl
index a0279de..ac34bec 100755
--- a/git-send-email.perl
+++ b/git-send-email.perl
@@ -79,6 +79,7 @@ git send-email [options] <file | directory | rev-list options >
auto, cc, compose, always, or never.
--quiet * Output one line of info per email.
--dry-run * Don't actually send the emails.
+ --expand-aliases * Expands email aliases only and exits
--[no-]validate * Perform patch sanity checks. Default on.
--[no-]format-patch * understand any non optional arguments as
`git format-patch` ones.
@@ -156,7 +157,7 @@ if ($@) {
}
# Behavior modification variables
-my ($quiet, $dry_run) = (0, 0);
+my ($quiet, $dry_run, $expand_aliases_only) = (0, 0, 0);
my $format_patch;
my $compose_filename;
@@ -263,6 +264,7 @@ my $rc = GetOptions("sender|from=s" => \$sender,
"suppress-cc=s" => \@suppress_cc,
"signed-off-cc|signed-off-by-cc!" => \$signed_off_by_cc,
"confirm=s" => \$confirm,
+ "expand-aliases" => \$expand_aliases_only,
"dry-run" => \$dry_run,
"envelope-sender=s" => \$envelope_sender,
"thread!" => \$thread,
@@ -441,6 +443,22 @@ if (@alias_files and $aliasfiletype and defined $parse_alias{$aliasfiletype}) {
}
}
+if ($expand_aliases_only) {
+ my @expand_to = expand_aliases(@to);
+ my @expand_cc = expand_aliases(@initial_cc);
+ my @expand_bcc = expand_aliases(@bcclist);
+
+ @expand_to = (map { sanitize_address($_) } @expand_to);
+ @expand_cc = (map { sanitize_address($_) } @expand_cc);
+ @expand_bcc = (map { sanitize_address($_) } @expand_bcc);
+
+ for my $a (@expand_to, @expand_cc, @expand_bcc) {
+ print $a . "\n";
+ }
+
+ exit(1);
+}
+
($sender) = expand_aliases($sender) if defined $sender;
# returns 1 if the conflict must be solved using it as a format-patch argument
^ permalink raw reply related
* [PATCH] strbuf_add_wrapped_text(): skip over colour codes
From: René Scharfe @ 2009-11-23 22:40 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git Mailing List
In-Reply-To: <7vtywmayvk.fsf@alter.siamese.dyndns.org>
Ignore display mode escape sequences (colour codes) for the purpose of
text wrapping because they don't have a visible width.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
Renamed function to document its purpose and limitation, and remove
the note that is obsoleted by this patch.
Documentation/pretty-formats.txt | 4 +---
utf8.c | 22 +++++++++++++++++++++-
2 files changed, 22 insertions(+), 4 deletions(-)
diff --git a/Documentation/pretty-formats.txt b/Documentation/pretty-formats.txt
index 7ff6a6c..0683fb3 100644
--- a/Documentation/pretty-formats.txt
+++ b/Documentation/pretty-formats.txt
@@ -136,9 +136,7 @@ The placeholders are:
- '%n': newline
- '%x00': print a byte from a hex code
- '%w([<w>[,<i1>[,<i2>]]])': switch line wrapping, like the -w option of
- linkgit:git-shortlog[1]. NOTE: Color placeholders (`%C*`) are not
- recognized as having no width, so they should not be put into wrapped
- sections.
+ linkgit:git-shortlog[1].
NOTE: Some placeholders may depend on other options given to the
revision traversal engine. For example, the `%g*` reflog options will
diff --git a/utf8.c b/utf8.c
index 01d1869..7ddff23 100644
--- a/utf8.c
+++ b/utf8.c
@@ -314,6 +314,20 @@ static void strbuf_add_indented_text(struct strbuf *buf, const char *text,
}
}
+static size_t display_mode_esc_sequence_len(const char *s)
+{
+ const char *p = s;
+ if (*p++ != '\033')
+ return 0;
+ if (*p++ != '[')
+ return 0;
+ while (isdigit(*p) || *p == ';')
+ p++;
+ if (*p++ != 'm')
+ return 0;
+ return p - s;
+}
+
/*
* Wrap the text, if necessary. The variable indent is the indent for the
* first line, indent2 is the indent for all other lines.
@@ -337,7 +351,13 @@ int strbuf_add_wrapped_text(struct strbuf *buf,
}
for (;;) {
- char c = *text;
+ char c;
+ size_t skip;
+
+ while ((skip = display_mode_esc_sequence_len(text)))
+ text += skip;
+
+ c = *text;
if (!c || isspace(c)) {
if (w < width || !space) {
const char *start = bol;
--
1.6.5
^ permalink raw reply related
* [PATCH 0/2] Add support for IPv6 on MinGW
From: Martin Storsjö @ 2009-11-23 22:54 UTC (permalink / raw)
To: git; +Cc: gitster
[-- Attachment #1: Type: TEXT/PLAIN, Size: 555 bytes --]
Hi,
This is a short patch series that adds support for IPv6 on MinGW. These
patches have been in use in msysgit for a few months (but the code was
accidentally removed recently in a merge). For consistency, it would be
good to add them upstream, too.
Martin Storsjö (2):
Refactor winsock initialization into a separate function
Enable support for IPv6 on MinGW
Makefile | 1 -
compat/mingw.c | 184 ++++++++++++++++++++++++++++++++++++++++++++++++++++++-
compat/mingw.h | 13 ++++
3 files changed, 193 insertions(+), 5 deletions(-)
^ permalink raw reply
* [PATCH 1/2] Refactor winsock initialization into a separate function
From: Martin Storsjö @ 2009-11-23 22:55 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <alpine.DEB.2.00.0911240052440.14228@cone.home.martin.st>
Signed-off-by: Martin Storsjo <martin@martin.st>
---
compat/mingw.c | 15 ++++++++++++---
1 files changed, 12 insertions(+), 3 deletions(-)
diff --git a/compat/mingw.c b/compat/mingw.c
index 15fe33e..f9d82ff 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -903,16 +903,25 @@ char **make_augmented_environ(const char *const *vars)
return env;
}
-/* this is the first function to call into WS_32; initialize it */
-#undef gethostbyname
-struct hostent *mingw_gethostbyname(const char *host)
+static void ensure_socket_initialization(void)
{
WSADATA wsa;
+ static int initialized = 0;
+
+ if (initialized)
+ return;
if (WSAStartup(MAKEWORD(2,2), &wsa))
die("unable to initialize winsock subsystem, error %d",
WSAGetLastError());
atexit((void(*)(void)) WSACleanup);
+ initialized = 1;
+}
+
+#undef gethostbyname
+struct hostent *mingw_gethostbyname(const char *host)
+{
+ ensure_socket_initialization();
return gethostbyname(host);
}
--
1.6.4.4
^ permalink raw reply related
* [PATCH 2/2] Enable support for IPv6 on MinGW
From: Martin Storsjö @ 2009-11-23 22:55 UTC (permalink / raw)
To: git; +Cc: gitster
In-Reply-To: <alpine.DEB.2.00.0911240052440.14228@cone.home.martin.st>
The IPv6 support functions are loaded dynamically, to maintain backwards
compatibility with versions of Windows prior to XP, and fallback wrappers
are provided, implemented in terms of gethostbyname and gethostbyaddr.
Signed-off-by: Martin Storsjo <martin@martin.st>
---
Makefile | 1 -
compat/mingw.c | 169 +++++++++++++++++++++++++++++++++++++++++++++++++++++++-
compat/mingw.h | 13 ++++
3 files changed, 181 insertions(+), 2 deletions(-)
diff --git a/Makefile b/Makefile
index 25a9771..31db29d 100644
--- a/Makefile
+++ b/Makefile
@@ -982,7 +982,6 @@ ifneq (,$(findstring MINGW,$(uname_S)))
NEEDS_CRYPTO_WITH_SSL = YesPlease
NO_LIBGEN_H = YesPlease
NO_SYMLINK_HEAD = YesPlease
- NO_IPV6 = YesPlease
NO_SETENV = YesPlease
NO_UNSETENV = YesPlease
NO_STRCASESTR = YesPlease
diff --git a/compat/mingw.c b/compat/mingw.c
index f9d82ff..0d73f15 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -903,10 +903,129 @@ char **make_augmented_environ(const char *const *vars)
return env;
}
+/*
+ * Note, this isn't a complete replacement for getaddrinfo. It assumes
+ * that service contains a numerical port, or that it it is null. It
+ * does a simple search using gethostbyname, and returns one IPv4 host
+ * if one was found.
+ */
+static int WSAAPI getaddrinfo_stub(const char *node, const char *service,
+ const struct addrinfo *hints,
+ struct addrinfo **res)
+{
+ struct hostent *h = gethostbyname(node);
+ struct addrinfo *ai;
+ struct sockaddr_in *sin;
+
+ if (!h)
+ return WSAGetLastError();
+
+ ai = xmalloc(sizeof(struct addrinfo));
+ *res = ai;
+ ai->ai_flags = 0;
+ ai->ai_family = AF_INET;
+ ai->ai_socktype = hints->ai_socktype;
+ switch (hints->ai_socktype) {
+ case SOCK_STREAM:
+ ai->ai_protocol = IPPROTO_TCP;
+ break;
+ case SOCK_DGRAM:
+ ai->ai_protocol = IPPROTO_UDP;
+ break;
+ default:
+ ai->ai_protocol = 0;
+ break;
+ }
+ ai->ai_addrlen = sizeof(struct sockaddr_in);
+ ai->ai_canonname = strdup(h->h_name);
+
+ sin = xmalloc(ai->ai_addrlen);
+ memset(sin, 0, ai->ai_addrlen);
+ sin->sin_family = AF_INET;
+ if (service)
+ sin->sin_port = htons(atoi(service));
+ sin->sin_addr = *(struct in_addr *)h->h_addr;
+ ai->ai_addr = (struct sockaddr *)sin;
+ ai->ai_next = 0;
+ return 0;
+}
+
+static void WSAAPI freeaddrinfo_stub(struct addrinfo *res)
+{
+ free(res->ai_canonname);
+ free(res->ai_addr);
+ free(res);
+}
+
+static int WSAAPI getnameinfo_stub(const struct sockaddr *sa, socklen_t salen,
+ char *host, DWORD hostlen,
+ char *serv, DWORD servlen, int flags)
+{
+ const struct sockaddr_in *sin = (const struct sockaddr_in *)sa;
+ if (sa->sa_family != AF_INET)
+ return EAI_FAMILY;
+ if (!host && !serv)
+ return EAI_NONAME;
+
+ if (host && hostlen > 0) {
+ struct hostent *ent = NULL;
+ if (!(flags & NI_NUMERICHOST))
+ ent = gethostbyaddr((const char *)&sin->sin_addr,
+ sizeof(sin->sin_addr), AF_INET);
+
+ if (ent)
+ snprintf(host, hostlen, "%s", ent->h_name);
+ else if (flags & NI_NAMEREQD)
+ return EAI_NONAME;
+ else
+ snprintf(host, hostlen, "%s", inet_ntoa(sin->sin_addr));
+ }
+
+ if (serv && servlen > 0) {
+ struct servent *ent = NULL;
+ if (!(flags & NI_NUMERICSERV))
+ ent = getservbyport(sin->sin_port,
+ flags & NI_DGRAM ? "udp" : "tcp");
+
+ if (ent)
+ snprintf(serv, servlen, "%s", ent->s_name);
+ else
+ snprintf(serv, servlen, "%d", ntohs(sin->sin_port));
+ }
+
+ return 0;
+}
+
+static HMODULE ipv6_dll = NULL;
+static void (WSAAPI *ipv6_freeaddrinfo)(struct addrinfo *res);
+static int (WSAAPI *ipv6_getaddrinfo)(const char *node, const char *service,
+ const struct addrinfo *hints,
+ struct addrinfo **res);
+static int (WSAAPI *ipv6_getnameinfo)(const struct sockaddr *sa, socklen_t salen,
+ char *host, DWORD hostlen,
+ char *serv, DWORD servlen, int flags);
+/*
+ * gai_strerror is an inline function in the ws2tcpip.h header, so we
+ * don't need to try to load that one dynamically.
+ */
+
+static void socket_cleanup(void)
+{
+ WSACleanup();
+ if (ipv6_dll)
+ FreeLibrary(ipv6_dll);
+ ipv6_dll = NULL;
+ ipv6_freeaddrinfo = freeaddrinfo_stub;
+ ipv6_getaddrinfo = getaddrinfo_stub;
+ ipv6_getnameinfo = getnameinfo_stub;
+}
+
static void ensure_socket_initialization(void)
{
WSADATA wsa;
static int initialized = 0;
+ const char *libraries[] = { "ws2_32.dll", "wship6.dll", NULL };
+ const char **name;
if (initialized)
return;
@@ -914,7 +1033,35 @@ static void ensure_socket_initialization(void)
if (WSAStartup(MAKEWORD(2,2), &wsa))
die("unable to initialize winsock subsystem, error %d",
WSAGetLastError());
- atexit((void(*)(void)) WSACleanup);
+
+ for (name = libraries; *name; name++) {
+ ipv6_dll = LoadLibrary(*name);
+ if (!ipv6_dll)
+ continue;
+
+ ipv6_freeaddrinfo = (void (WSAAPI *)(struct addrinfo *))
+ GetProcAddress(ipv6_dll, "freeaddrinfo");
+ ipv6_getaddrinfo = (int (WSAAPI *)(const char *, const char *,
+ const struct addrinfo *,
+ struct addrinfo **))
+ GetProcAddress(ipv6_dll, "getaddrinfo");
+ ipv6_getnameinfo = (int (WSAAPI *)(const struct sockaddr *,
+ socklen_t, char *, DWORD,
+ char *, DWORD, int))
+ GetProcAddress(ipv6_dll, "getnameinfo");
+ if (!ipv6_freeaddrinfo || !ipv6_getaddrinfo || !ipv6_getnameinfo) {
+ FreeLibrary(ipv6_dll);
+ ipv6_dll = NULL;
+ } else
+ break;
+ }
+ if (!ipv6_freeaddrinfo || !ipv6_getaddrinfo || !ipv6_getnameinfo) {
+ ipv6_freeaddrinfo = freeaddrinfo_stub;
+ ipv6_getaddrinfo = getaddrinfo_stub;
+ ipv6_getnameinfo = getnameinfo_stub;
+ }
+
+ atexit(socket_cleanup);
initialized = 1;
}
@@ -925,6 +1072,26 @@ struct hostent *mingw_gethostbyname(const char *host)
return gethostbyname(host);
}
+void mingw_freeaddrinfo(struct addrinfo *res)
+{
+ ipv6_freeaddrinfo(res);
+}
+
+int mingw_getaddrinfo(const char *node, const char *service,
+ const struct addrinfo *hints, struct addrinfo **res)
+{
+ ensure_socket_initialization();
+ return ipv6_getaddrinfo(node, service, hints, res);
+}
+
+int mingw_getnameinfo(const struct sockaddr *sa, socklen_t salen,
+ char *host, DWORD hostlen, char *serv, DWORD servlen,
+ int flags)
+{
+ ensure_socket_initialization();
+ return ipv6_getnameinfo(sa, salen, host, hostlen, serv, servlen, flags);
+}
+
int mingw_socket(int domain, int type, int protocol)
{
int sockfd;
diff --git a/compat/mingw.h b/compat/mingw.h
index 51993ef..b3d299f 100644
--- a/compat/mingw.h
+++ b/compat/mingw.h
@@ -1,4 +1,5 @@
#include <winsock2.h>
+#include <ws2tcpip.h>
/*
* things that are not available in header files
@@ -178,6 +179,18 @@ char *mingw_getenv(const char *name);
struct hostent *mingw_gethostbyname(const char *host);
#define gethostbyname mingw_gethostbyname
+void mingw_freeaddrinfo(struct addrinfo *res);
+#define freeaddrinfo mingw_freeaddrinfo
+
+int mingw_getaddrinfo(const char *node, const char *service,
+ const struct addrinfo *hints, struct addrinfo **res);
+#define getaddrinfo mingw_getaddrinfo
+
+int mingw_getnameinfo(const struct sockaddr *sa, socklen_t salen,
+ char *host, DWORD hostlen, char *serv, DWORD servlen,
+ int flags);
+#define getnameinfo mingw_getnameinfo
+
int mingw_socket(int domain, int type, int protocol);
#define socket mingw_socket
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH] unset GREP_OPTIONS in test-lib.sh
From: René Scharfe @ 2009-11-23 23:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlo Marcelo Arenas Belon, Bert Wesarg, git
In-Reply-To: <7vtywlyu43.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Carlo Marcelo Arenas Belon <carenas@sajinet.com.pe> writes:
>
>> why not better to apply the proposed patch from Junio in :
>>
>> http://article.gmane.org/gmane.comp.version-control.git/127980/
>>
>> it would IMHO correct all reported issues and serve as well as a catch
>> all from other tools that could be introduced in the future and that
>> will be similarly affected by this misfeature.
>
> I think René's patch is more sensible than $gmane/127980 because we have
> no business mucking with these environment variables when we are running
> things other than external grep. You could be using system's "grep" in
> your pre-commit hook to find some stuff, and your hook either may rely
> on your having a particular set of GREP_OPTIONS in your environment, or
> may be designed to work well with GREP_OPTIONS.
Yes, but what about git commands that are implemented as shell scripts
and use grep? Something like the following patch?
We'd need to run this from time to time to make sure no new grep calls
creep in:
git grep -L "unset GREP_OPTIONS" -- $(git grep -l "grep" git-*.sh)
-- 8< --
Unset GREP_OPTIONS at the top of git commands that are implemented as
shell scripts and call grep, in order to avoid side effects caused by
unexpected default options of users.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
git-am.sh | 3 +++
git-bisect.sh | 3 +++
git-filter-branch.sh | 3 +++
git-instaweb.sh | 3 +++
git-notes.sh | 3 +++
git-rebase--interactive.sh | 3 +++
git-rebase.sh | 3 +++
git-submodule.sh | 3 +++
8 files changed, 24 insertions(+), 0 deletions(-)
diff --git a/git-am.sh b/git-am.sh
index 151512a..1390eec 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -38,6 +38,9 @@ set_reflog_action am
require_work_tree
cd_to_toplevel
+# Make sure we're in full control when calling grep in this script.
+unset GREP_OPTIONS
+
git var GIT_COMMITTER_IDENT >/dev/null ||
die "You need to set your committer info first"
diff --git a/git-bisect.sh b/git-bisect.sh
index a5ea843..fcf500f 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -30,6 +30,9 @@ OPTIONS_SPEC=
. git-sh-setup
require_work_tree
+# Make sure we're in full control when calling grep in this script.
+unset GREP_OPTIONS
+
_x40='[0-9a-f][0-9a-f][0-9a-f][0-9a-f][0-9a-f]'
_x40="$_x40$_x40$_x40$_x40$_x40$_x40$_x40$_x40"
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index 6b8b6a4..d3a8b3e 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -107,6 +107,9 @@ USAGE="[--env-filter <command>] [--tree-filter <command>]
OPTIONS_SPEC=
. git-sh-setup
+# Make sure we're in full control when calling grep in this script.
+unset GREP_OPTIONS
+
if [ "$(is_bare_repository)" = false ]; then
git diff-files --ignore-submodules --quiet &&
git diff-index --cached --quiet HEAD -- ||
diff --git a/git-instaweb.sh b/git-instaweb.sh
index 622a5f0..86916e1 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -21,6 +21,9 @@ restart restart the web server
. git-sh-setup
+# Make sure we're in full control when calling grep in this script.
+unset GREP_OPTIONS
+
fqgitdir="$GIT_DIR"
local="$(git config --bool --get instaweb.local)"
httpd="$(git config --get instaweb.httpd)"
diff --git a/git-notes.sh b/git-notes.sh
index e642e47..e5f0edf 100755
--- a/git-notes.sh
+++ b/git-notes.sh
@@ -3,6 +3,9 @@
USAGE="(edit [-F <file> | -m <msg>] | show) [commit]"
. git-sh-setup
+# Make sure we're in full control when calling grep in this script.
+unset GREP_OPTIONS
+
test -z "$1" && usage
ACTION="$1"; shift
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 27daaa9..d0bb8a3 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -33,6 +33,9 @@ root rebase all reachable commmits up to the root(s)
. git-sh-setup
require_work_tree
+# Make sure we're in full control when calling grep in this script.
+unset GREP_OPTIONS
+
DOTEST="$GIT_DIR/rebase-merge"
TODO="$DOTEST"/git-rebase-todo
DONE="$DOTEST"/done
diff --git a/git-rebase.sh b/git-rebase.sh
index 6830e16..18c680b 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -34,6 +34,9 @@ set_reflog_action rebase
require_work_tree
cd_to_toplevel
+# Make sure we're in full control when calling grep in this script.
+unset GREP_OPTIONS
+
OK_TO_SKIP_PRE_REBASE=
RESOLVEMSG="
When you have resolved this problem run \"git rebase --continue\".
diff --git a/git-submodule.sh b/git-submodule.sh
index 850d423..e557aca 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -17,6 +17,9 @@ OPTIONS_SPEC=
. git-parse-remote
require_work_tree
+# Make sure we're in full control when calling grep in this script.
+unset GREP_OPTIONS
+
command=
branch=
reference=
--
1.6.5
^ permalink raw reply related
* [PATCH] mergetool--lib: simplify guess_merge_tool()
From: René Scharfe @ 2009-11-23 23:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Carlo Marcelo Arenas Belon, Bert Wesarg, git
In-Reply-To: <4B0B185B.4090305@lsrfire.ath.cx>
Use a case statement instead of calling grep to find out if the editor's
name contains the string "vim". Remove the check for emacs, as this
branch did the same as the default one anyway.
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
---
This removes all grep calls from this script.
git-mergetool--lib.sh | 13 ++++++-------
1 files changed, 6 insertions(+), 7 deletions(-)
diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
index f7c571e..5b62785 100644
--- a/git-mergetool--lib.sh
+++ b/git-mergetool--lib.sh
@@ -338,15 +338,14 @@ guess_merge_tool () {
fi
tools="$tools gvimdiff diffuse ecmerge p4merge araxis"
fi
- if echo "${VISUAL:-$EDITOR}" | grep emacs > /dev/null 2>&1; then
- # $EDITOR is emacs so add emerge as a candidate
- tools="$tools emerge vimdiff"
- elif echo "${VISUAL:-$EDITOR}" | grep vim > /dev/null 2>&1; then
- # $EDITOR is vim so add vimdiff as a candidate
+ case "${VISUAL:-$EDITOR}" in
+ *vim*)
tools="$tools vimdiff emerge"
- else
+ ;;
+ *)
tools="$tools emerge vimdiff"
- fi
+ ;;
+ esac
echo >&2 "merge tool candidates: $tools"
# Loop over each candidate and stop when a valid merge tool is found.
--
1.6.5
^ permalink raw reply related
* Re: OS X and umlauts in file names
From: Jakub Narebski @ 2009-11-23 23:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Thomas Singer, Thomas Rast, git
In-Reply-To: <alpine.DEB.1.00.0911231916510.4897@intel-tinevez-2-302>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Mon, 23 Nov 2009, Thomas Singer wrote:
>
> > Basically, getting it "somehow" to work on OS X is just one minor step.
> > IMHO Git should standardize on file names in the repository and do the
> > platform-specific conversion independent of any locale setting, if
> > needed.
>
> That is contrary to the design of Git which honors content (byte-wise!) as
> much as possible, and treats file names very much as content.
>
> There were beginnings of supporting OSX' brain-damaged filename mangling,
> but an obnoxious OSX fan worked very hard on trying to defend the OSX
> design and to decry Git's respect for the raw bytes on this list, so hard
> that even the nicest developers had no fun working on this issue anymore.
>
> This little background may help you understand why there is no solution
> implemented in Git yet. And maybe quite a few developers are reluctant to
> discuss the issue and possible solutions due to said sad story, too.
To be more exact the problem is not that MacOS X uses denormalized
form (does file mangling). This would be the problem only in
cross-platform development (where some developers would work from
different operating system).
The problem is that the name under which Git creates file is different
from the name MacOS X lists file (in readdir etc.).
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH] unset GREP_OPTIONS in test-lib.sh
From: Junio C Hamano @ 2009-11-23 23:52 UTC (permalink / raw)
To: René Scharfe; +Cc: Carlo Marcelo Arenas Belon, Bert Wesarg, git
In-Reply-To: <4B0B185B.4090305@lsrfire.ath.cx>
René Scharfe <rene.scharfe@lsrfire.ath.cx> writes:
> Yes, but what about git commands that are implemented as shell scripts
> and use grep? Something like the following patch?
>
> We'd need to run this from time to time to make sure no new grep calls
> creep in:
>
> git grep -L "unset GREP_OPTIONS" -- $(git grep -l "grep" git-*.sh)
Hmm, but "bisect run" runs user's script and it may want to see
GREP_OPTIONS from the environment, no? Same for any of the hooks that am
and rebase might want to run.
git-sh-setup.sh | 14 ++++++++++++++
git-am.sh | 4 ++--
git-bisect.sh | 4 ++--
git-filter-branch.sh | 2 +-
git-instaweb.sh | 8 ++++----
git-rebase--interactive.sh | 10 +++++-----
git-rebase.sh | 2 +-
git-submodule.sh | 6 +++---
8 files changed, 32 insertions(+), 18 deletions(-)
diff --git a/git-sh-setup.sh b/git-sh-setup.sh
index c41c2f7..2b2afa6 100755
--- a/git-sh-setup.sh
+++ b/git-sh-setup.sh
@@ -114,6 +114,20 @@ git_editor() {
eval "${GIT_EDITOR:=vi}" '"$@"'
}
+sane_grep () {
+ GREP_OPTIONS= \
+ GREP_COLOR= \
+ GREP_COLORS= \
+ LC_ALL=C grep "$@"
+}
+
+sane_egrep () {
+ GREP_OPTIONS= \
+ GREP_COLOR= \
+ GREP_COLORS= \
+ LC_ALL=C egrep "$@"
+}
+
is_bare_repository () {
git rev-parse --is-bare-repository
}
diff --git a/git-am.sh b/git-am.sh
index c132f50..b49f26a 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -205,7 +205,7 @@ check_patch_format () {
# and see if it looks like that they all begin with the
# header field names...
sed -n -e '/^$/q' -e '/^[ ]/d' -e p "$1" |
- LC_ALL=C egrep -v '^[!-9;-~]+:' >/dev/null ||
+ sane_egrep -v '^[!-9;-~]+:' >/dev/null ||
patch_format=mbox
fi
} < "$1" || clean_abort
@@ -554,7 +554,7 @@ do
stop_here $this
# skip pine's internal folder data
- grep '^Author: Mail System Internal Data$' \
+ sane_grep '^Author: Mail System Internal Data$' \
<"$dotest"/info >/dev/null &&
go_next && continue
diff --git a/git-bisect.sh b/git-bisect.sh
index 6f6f039..0c422d5 100755
--- a/git-bisect.sh
+++ b/git-bisect.sh
@@ -393,7 +393,7 @@ bisect_run () {
cat "$GIT_DIR/BISECT_RUN"
- if grep "first bad commit could be any of" "$GIT_DIR/BISECT_RUN" \
+ if sane_grep "first bad commit could be any of" "$GIT_DIR/BISECT_RUN" \
> /dev/null; then
echo >&2 "bisect run cannot continue any more"
exit $res
@@ -405,7 +405,7 @@ bisect_run () {
exit $res
fi
- if grep "is the first bad commit" "$GIT_DIR/BISECT_RUN" > /dev/null; then
+ if sane_grep "is the first bad commit" "$GIT_DIR/BISECT_RUN" > /dev/null; then
echo "bisect run success"
exit 0;
fi
diff --git a/git-filter-branch.sh b/git-filter-branch.sh
index a480d6f..8ef1bde 100755
--- a/git-filter-branch.sh
+++ b/git-filter-branch.sh
@@ -457,7 +457,7 @@ if [ "$filter_tag_name" ]; then
git mktag) ||
die "Could not create new tag object for $ref"
if git cat-file tag "$ref" | \
- grep '^-----BEGIN PGP SIGNATURE-----' >/dev/null 2>&1
+ sane_grep '^-----BEGIN PGP SIGNATURE-----' >/dev/null 2>&1
then
warn "gpg signature stripped from tag object $sha1t"
fi
diff --git a/git-instaweb.sh b/git-instaweb.sh
index d96eddb..84805c6 100755
--- a/git-instaweb.sh
+++ b/git-instaweb.sh
@@ -41,7 +41,7 @@ resolve_full_httpd () {
case "$httpd" in
*apache2*|*lighttpd*)
# ensure that the apache2/lighttpd command ends with "-f"
- if ! echo "$httpd" | grep -- '-f *$' >/dev/null 2>&1
+ if ! echo "$httpd" | sane_grep -- '-f *$' >/dev/null 2>&1
then
httpd="$httpd -f"
fi
@@ -297,8 +297,8 @@ EOF
# check to see if Dennis Stosberg's mod_perl compatibility patch
# (<20060621130708.Gcbc6e5c@leonov.stosberg.net>) has been applied
- if test -f "$module_path/mod_perl.so" && grep 'MOD_PERL' \
- "$GIT_DIR/gitweb/gitweb.cgi" >/dev/null
+ if test -f "$module_path/mod_perl.so" &&
+ sane_grep 'MOD_PERL' "$GIT_DIR/gitweb/gitweb.cgi" >/dev/null
then
# favor mod_perl if available
cat >> "$conf" <<EOF
@@ -316,7 +316,7 @@ EOF
# plain-old CGI
resolve_full_httpd
list_mods=$(echo "$full_httpd" | sed "s/-f$/-l/")
- $list_mods | grep 'mod_cgi\.c' >/dev/null 2>&1 || \
+ $list_mods | sane_grep 'mod_cgi\.c' >/dev/null 2>&1 || \
echo "LoadModule cgi_module $module_path/mod_cgi.so" >> "$conf"
cat >> "$conf" <<EOF
AddHandler cgi-script .cgi
diff --git a/git-rebase--interactive.sh b/git-rebase--interactive.sh
index 23ded48..6268e76 100755
--- a/git-rebase--interactive.sh
+++ b/git-rebase--interactive.sh
@@ -106,8 +106,8 @@ mark_action_done () {
sed -e 1q < "$TODO" >> "$DONE"
sed -e 1d < "$TODO" >> "$TODO".new
mv -f "$TODO".new "$TODO"
- count=$(grep -c '^[^#]' < "$DONE")
- total=$(($count+$(grep -c '^[^#]' < "$TODO")))
+ count=$(sane_grep -c '^[^#]' < "$DONE")
+ total=$(($count+$(sane_grep -c '^[^#]' < "$TODO")))
if test "$last_count" != "$count"
then
last_count=$count
@@ -147,7 +147,7 @@ die_abort () {
}
has_action () {
- grep '^[^#]' "$1" >/dev/null
+ sane_grep '^[^#]' "$1" >/dev/null
}
pick_one () {
@@ -731,7 +731,7 @@ first and then run 'git rebase --continue' again."
git rev-list $REVISIONS |
while read rev
do
- if test -f "$REWRITTEN"/$rev -a "$(grep "$rev" "$DOTEST"/not-cherry-picks)" = ""
+ if test -f "$REWRITTEN"/$rev -a "$(sane_grep "$rev" "$DOTEST"/not-cherry-picks)" = ""
then
# Use -f2 because if rev-list is telling us this commit is
# not worthwhile, we don't want to track its multiple heads,
@@ -739,7 +739,7 @@ first and then run 'git rebase --continue' again."
# be rebasing on top of it
git rev-list --parents -1 $rev | cut -d' ' -s -f2 > "$DROPPED"/$rev
short=$(git rev-list -1 --abbrev-commit --abbrev=7 $rev)
- grep -v "^[a-z][a-z]* $short" <"$TODO" > "${TODO}2" ; mv "${TODO}2" "$TODO"
+ sane_grep -v "^[a-z][a-z]* $short" <"$TODO" > "${TODO}2" ; mv "${TODO}2" "$TODO"
rm "$REWRITTEN"/$rev
fi
done
diff --git a/git-rebase.sh b/git-rebase.sh
index 6ec155c..0ec4355 100755
--- a/git-rebase.sh
+++ b/git-rebase.sh
@@ -467,7 +467,7 @@ orig_head=$branch
mb=$(git merge-base "$onto" "$branch")
if test "$upstream" = "$onto" && test "$mb" = "$onto" &&
# linear history?
- ! (git rev-list --parents "$onto".."$branch" | grep " .* ") > /dev/null
+ ! (git rev-list --parents "$onto".."$branch" | sane_grep " .* ") > /dev/null
then
if test -z "$force_rebase"
then
diff --git a/git-submodule.sh b/git-submodule.sh
index 0462e52..b7ccd12 100755
--- a/git-submodule.sh
+++ b/git-submodule.sh
@@ -57,7 +57,7 @@ resolve_relative_url ()
#
module_list()
{
- git ls-files --error-unmatch --stage -- "$@" | grep '^160000 '
+ git ls-files --error-unmatch --stage -- "$@" | sane_grep '^160000 '
}
#
@@ -567,7 +567,7 @@ cmd_summary() {
cd_to_toplevel
# Get modified modules cared by user
modules=$(git $diff_cmd $cached --raw $head -- "$@" |
- egrep '^:([0-7]* )?160000' |
+ sane_egrep '^:([0-7]* )?160000' |
while read mod_src mod_dst sha1_src sha1_dst status name
do
# Always show modules deleted or type-changed (blob<->module)
@@ -581,7 +581,7 @@ cmd_summary() {
test -z "$modules" && return
git $diff_cmd $cached --raw $head -- $modules |
- egrep '^:([0-7]* )?160000' |
+ sane_egrep '^:([0-7]* )?160000' |
cut -c2- |
while read mod_src mod_dst sha1_src sha1_dst status name
do
^ 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