* Re: Projects within projects
From: Bill Lear @ 2009-10-29 19:33 UTC (permalink / raw)
To: Nick Colgan; +Cc: git
In-Reply-To: <ab1d51700910291140ncd80027j4ee9a30637d7bc40@mail.gmail.com>
On Thursday, October 29, 2009 at 14:40:36 (-0400) Nick Colgan writes:
>I'm currently working on a project made up of parts that could each be
>considered a project in itself. I plan on using redmine or trac to
>manage the project. Now I'm trying to figure out how to manage the
>repo(s) for the project.
>
>These are the current options I have in mind:
>
>1. Create a separate repository for each sub-project and manage each
>separately in redmine (separate bug tracker, wiki, etc.)
>
>2. Create a single repository with a subdirectory for each sub-project.
>
>3. Use git submodules or subversion externals to combine options 1 and 2
>by creating a separate repo for each sub-project, then creating a master
>repo with subdirectory for each sub-project that imports from their
>respective repositories.
>
>What's the best way to handle this situation? Are git submodules and/or
>svn externals sufficiently capable of dealing with this?
Let me give you an example of #3. I write a fair amount in C++ and
have written a reasonably sophisticated makefile system to allow me to
create a new directory in a project, put files in it, link in a master
makefile, cd into the directory and type 'make' and have things build
without me having to edit the makefile --- I don't want to write
makefile rules, etc., I want to write C++ (fill in the blank here).
It basically relies on naming conventions, but it suits me perfectly.
If I name a file test_*.cc or t_*.cc, or tc_*.cc, it is a unit test,
if I name it m_*.cc, or main_*.cc, it is a main program. Library
inter-dependencies are easy to set up in a central way, blah blah blah
--- the details are not terribly important.
In any case, I created a new project to work on some "real-time"
financial trading algorithms. I did this by creating a new repository
into which I added a src directory, under which were several other
directories of source code. At the top level of the new repo, I added
a git submodule 'mk' that contains my makefile system. I then linked
the master makefile to my source directory makefile and was off
compiling easily.
In this case, I do absolutely reuse my makefile system across multiple
projects. It is 100% orthogonal, and I have so far found it to be
very useful to use git submodules.
I imagine also if you are building software that is 100% orthogonal
that you would like to reuse in many projects, git submobules is the
way to go.
I read the Git Submodule Tutorial on the Git Wiki and found myself
able to use submodules very easily after that.
bill
^ permalink raw reply
* Tracking a remote branch in git
From: Sips @ 2009-10-29 19:45 UTC (permalink / raw)
To: git
Hello everyone.
My git setup is as follows:
One local repository residing at D:\Dev\ProjectName
One remote repository residing at W:\ProjectName
W is actually a removable disk.
Now, both repositories are connected through remotes. For example, git
remote -v in the local repository gives:
storengo W:\ProjectName (fetch)
storengo W:\ProjectName (push)
The same command in the remote repository gives:
origin D:\Dev\ProjectName (fetch)
origin D:\Dev\ProjectName (push)
Obviously, when I am in the master branch, I can synchronize repositories
between each other through git push and git pull.
Then I created a branch in the repository on the removable drive W and named
it newfeature. The question is: How can I work with this branch on the local
repository as well? I mean, I need the same 'relationship' between branches
as in case of the master branch.
I tried the following command on the local repository (which was checked out
to the master branch at that time):
git branch --track newfeature storengo/newfeature,
but received an error fatal: Not a valid object name: 'storengo/newfeature'.
With this command I was hoping to create a local branch which would be
'connected' to the same remote branch. As I've said, no luck there.
Strangely, the following command works without errors:
git branch --track newfeature storengo/master.
I mean, I am able to track the master branch from the remote repository. Why
can't I track some other branch as well? Any ideas what I'm doing wrong?
Thanks,
Kirill
--
View this message in context: http://www.nabble.com/Tracking-a-remote-branch-in-git-tp26119537p26119537.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH/RFC 2/2] Provide a build time default-editor setting
From: Junio C Hamano @ 2009-10-29 20:40 UTC (permalink / raw)
To: Johannes Sixt
Cc: David Roundy, Jonathan Nieder, Junio C Hamano, Ben Walton,
GIT List
In-Reply-To: <4AE98175.504@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> David Roundy schrieb:
>> Any chance this will be exported as plumbing? I know it's pretty
>> high-level, but it'd be handy to have be able to write `git editor
>> $FILENAME` and just have it do the right thing. This would also mean
>> that the perl scripts below could be simplified.
>
> Something like below? Possible usage in shell scripts:
>
> editor=$(git var GIT_EDITOR)
> "$editor" "$filename"
I think we support GIT_EDITOR that is command path plus its initial
command line arguments, so you do not want dq around $editor, right?
^ permalink raw reply
* Re: [PATCH/RFC 2/2] Provide a build time default-editor setting
From: Junio C Hamano @ 2009-10-29 20:43 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Ben Walton, GIT List
In-Reply-To: <20091029075021.GC15403@progeny.tock>
Jonathan Nieder <jrnieder@gmail.com> writes:
> Provide a DEFAULT_EDITOR knob to allow the fallback editor (to
> use instead of vi if VISUAL, EDITOR, and GIT_EDITOR are unset) to
> be set at build time according to a system’s policy. For
> example, on Debian systems, the default editor should be the
> 'editor' command.
I think we allow things like
GIT_EDITOR='"/c/my program/vi" --i-like-color --config=$HOME/.myvicfg'
and the eval construct in git-sh-setup.sh is about supporting that kind of
insanity^Wflexibility.
My "how about" patch on DEFAULT_PAGER might be minimally safe with
make DEFAULT_PAGER="/c/my program/less"
but if you are going to do this for real, you would need to use proper
quoting in the Makefile (look for _SQ for hints).
Also I do not think it allows this at all:
make DEFAULT_PAGER='"/c/my program/less" --i-like-color'
It probably is Ok to force the "default" one to be just the path to the
command (i.e. not part of command line), but I thought this would be worth
pointing out.
> This change makes t7005-editor into a mess. Any ideas for fixing
> this?
I think the introduction of DEFAULT_EDITOR makes it unfixable; your
DEFAULT_EDITOR may be set to '/usr/bin/vi' not 'vi'.
Just detect DEFAULT_EDITOR being not the default 'vi' and abort/skip the
entire test, perhaps?
^ permalink raw reply
* Re: [RFC PATCH v4 03/26] pkt-line: Make packet_read_line easier to debug
From: Junio C Hamano @ 2009-10-29 20:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20091029151152.GX10505@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Junio C Hamano <gitster@pobox.com> wrote:
>> "Shawn O. Pearce" <spearce@spearce.org> writes:
>> > diff --git a/pkt-line.c b/pkt-line.c
>> > index bd603f8..893dd3c 100644
>> > --- a/pkt-line.c
>> > +++ b/pkt-line.c
>> > @@ -124,12 +124,14 @@ static int packet_length(const char *linelen)
>> > int packet_read_line(int fd, char *buffer, unsigned size)
>> > {
>> > int len;
>> > - char linelen[4];
>> > + char linelen[5];
>> >
>> > safe_read(fd, linelen, 4);
>> > len = packet_length(linelen);
>> > - if (len < 0)
>> > - die("protocol error: bad line length character");
>> > + if (len < 0) {
>> > + linelen[4] = '\0';
>> > + die("protocol error: bad line length character: %s", linelen);
>> > + }
>>
>> Since this is not called recursively, you can make linelen[] static
>
> Sure. But it wasn't static before. It was stack allocated. Its a
> 5 byte stack allocation. Its not a lot of data to push onto the
> stack, why does it suddenly matter that we make it static and charge
> everyone for its memory instead of just those who really need it?
>
>> and do
>> without the NUL assignment; safe_read() won't read beyond 4 bytes anyway.
>
> The NUL assignment isn't about safe_read(), its about making the
> block of 4 bytes read a proper C-style string so we can safely pass
> it down into the snprintf that is within die().
I knew and understood all of what you just said. static linelen[] is not
about stack allocation. It's about letting the compiler initialize it to
five NULs so that you do not have to assign NUL to its fifth place before
you die. This removes one added line from your patch.
^ permalink raw reply
* Re: [RFC PATCH v4 14/26] Add stateless RPC options to upload-pack, receive-pack
From: Junio C Hamano @ 2009-10-29 20:43 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Junio C Hamano, git
In-Reply-To: <20091029152629.GY10505@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> One approach is to use an HMAC and sign each advertised SHA-1
> during the initial --advertise-refs phase. Requesters then present
> the SHA-1 and the HAMC signature in each "want" line, and the
> --stateless-rpc phase validates the signatures to ensure they came
> from a trusted party.
>
> The major problem with this approach is the private key management.
> All mirrors of that repository need to have a common private key
> so they can generate and later verify that HMAC signature. This is
> additional complexity, for perhaps not much gain.
I am not worried so much about malicious clients getting themselves
confused. One simple alternative would be to internally recreate the
response the requestee would send if it were the first phase request upon
receiving the request for the second phase---then you take an SHA-1 hash
of it. In the second phase request have the requestor include the SHA-1
hash of what it received in the response to its first phase request, and
the requestee can make sure they match. No per-ref signing nor secret key
management is necessary, and it would let the requestor retry if you allow
the response to the second phase request to be "your request is stale, try
again".
> A different approach is to have the --stateless-rpc phase validate
> the want lines against its refs (like we do now), but if the validate
> fails (no ref exactly matches) support walking backwards through the
> last few records in the reflog, or through that ref's own history
> for a few hundred commits, to see if the want SHA-1 appears in the
> recent prior past.
>
> Obviously when walking the reflog we would need to use a time bound,
> e.g. "only examine last record if more recent than 5 minutes ago".
I think that is probably too much complexity for too little gain. I think
detecting stale request and having requestor retry would be sufficient,
and validating the want lines as we already do would give the same level
of assurance as "check against the hash of first phase response" I
outlined above, and would be much simpler thus more robust.
^ permalink raw reply
* Re: [PATCH/RFC 2/2] Provide a build time default-editor setting
From: Johannes Sixt @ 2009-10-29 20:57 UTC (permalink / raw)
To: Junio C Hamano; +Cc: David Roundy, Jonathan Nieder, Ben Walton, GIT List
In-Reply-To: <7viqdy6ii1.fsf@alter.siamese.dyndns.org>
On Donnerstag, 29. Oktober 2009, Junio C Hamano wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
> > Something like below? Possible usage in shell scripts:
> >
> > editor=$(git var GIT_EDITOR)
> > "$editor" "$filename"
>
> I think we support GIT_EDITOR that is command path plus its initial
> command line arguments, so you do not want dq around $editor, right?
Yeah, whatever, I didn't take the time to think it through. But this may be an
opportunity to give some life back to the zombie that git-var currently is,
that is, to make it the plumbing that does value discovery for variables like
GIT_AUTHOR_INDENT, GIT_COMMITTER_IDENT, GIT_EDITOR, and perhaps also
GIT_PAGER.
-- Hannes
^ permalink raw reply
* finding the merge of two or more commits
From: E R @ 2009-10-29 21:12 UTC (permalink / raw)
To: git
Hi,
Given two commits c1 and c2, is it possible to ask git if there are
any commits in the repository that were created by either a sequence
of commands like:
git checkout c1
git merge c2
or:
git checkout c2
git merge c1
with any required conflict resolution?
That is, I don't want to merge c1 and c2 myself, but I want to know if
someone else has merged c1 and c2, performed any conflict resolution
and committed the result.
Thanks,
ER
^ permalink raw reply
* Re: finding the merge of two or more commits
From: Avery Pennarun @ 2009-10-29 21:34 UTC (permalink / raw)
To: E R; +Cc: git
In-Reply-To: <3a69fa7c0910291412l439f7f61vd3b55a77cd7e10b5@mail.gmail.com>
On Thu, Oct 29, 2009 at 5:12 PM, E R <pc88mxer@gmail.com> wrote:
> That is, I don't want to merge c1 and c2 myself, but I want to know if
> someone else has merged c1 and c2, performed any conflict resolution
> and committed the result.
Try this:
(git branch -a --contains c1; git branch -a --contains c2) | sort | uniq -d
It's not exactly pretty, but it works.
Have fun,
Avery
^ permalink raw reply
* [PATCH] More precise description of 'git describe --abbrev'
From: Gisle Aas @ 2009-10-29 21:38 UTC (permalink / raw)
To: git; +Cc: gitster
Also make the examples show what 'git describe' actually outputs
currently. I guess the default --abbrev value has been changed from 4
to 7 at some point.
Signed-off-by: Gisle Aas <gisle@aas.no>
---
Documentation/git-describe.txt | 12 +++++++-----
1 files changed, 7 insertions(+), 5 deletions(-)
diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
index b231dbb..743eb95 100644
--- a/Documentation/git-describe.txt
+++ b/Documentation/git-describe.txt
@@ -44,7 +44,9 @@ OPTIONS
--abbrev=<n>::
Instead of using the default 7 hexadecimal digits as the
- abbreviated object name, use <n> digits.
+ abbreviated object name, use <n> digits or as many digits
+ are needed to form a unique object name. An <n> of 0
+ will suppress long format, only showing the closest tag.
--candidates=<n>::
Instead of considering only the 10 most recent tags as
@@ -68,8 +70,8 @@ OPTIONS
This is useful when you want to see parts of the commit object name
in "describe" output, even when the commit in question happens to be
a tagged version. Instead of just emitting the tag name, it will
- describe such a commit as v1.2-0-deadbeef (0th commit since tag v1.2
- that points at object deadbeef....).
+ describe such a commit as v1.2-0-gdeadbee (0th commit since tag v1.2
+ that points at object deadbee....).
--match <pattern>::
Only consider tags matching the given pattern (can be used to avoid
@@ -106,10 +108,10 @@ With --all, the command can use branch heads as
references, so
the output shows the reference path as well:
[torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
- tags/v1.0.0-21-g975b
+ tags/v1.0.0-21-g975b3
[torvalds@g5 git]$ git describe --all HEAD^
- heads/lt/describe-7-g975b
+ heads/lt/describe-7-g975b31d
With --abbrev set to 0, the command can be used to find the
closest tagname without any suffix:
--
1.6.2.95.g934f7
^ permalink raw reply related
* Re: [RFC PATCH v4 03/26] pkt-line: Make packet_read_line easier to debug
From: Shawn O. Pearce @ 2009-10-29 21:58 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v1vkm6id9.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> > The NUL assignment isn't about safe_read(), its about making the
> > block of 4 bytes read a proper C-style string so we can safely pass
> > it down into the snprintf that is within die().
>
> I knew and understood all of what you just said. static linelen[] is not
> about stack allocation. It's about letting the compiler initialize it to
> five NULs so that you do not have to assign NUL to its fifth place before
> you die. This removes one added line from your patch.
Thanks, I get it now. Patch amended.
--
Shawn.
^ permalink raw reply
* [PATCH 1/2] t/gitweb-lib.sh: Split gitweb output into headers and body
From: Jakub Narebski @ 2009-10-29 22:07 UTC (permalink / raw)
To: git; +Cc: Mark Rada, Jakub Narebski
In-Reply-To: <1256854062-25496-1-git-send-email-jnareb@gmail.com>
Save HTTP headers into gitweb.headers, and the body of message into
gitweb.body in gitweb_run()
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
I hope that this use of sed is portable enough.
Please take into account that HTTP headers part contains at least one
line: HTTP status.
t/gitweb-lib.sh | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/t/gitweb-lib.sh b/t/gitweb-lib.sh
index 8452532..32b841d
--- a/t/gitweb-lib.sh
+++ b/t/gitweb-lib.sh
@@ -52,10 +52,14 @@ 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 &&
if grep '^[[]' gitweb.log >/dev/null 2>&1; then false; else true; fi
# gitweb.log is left for debugging
- # gitweb.output is used to parse http output
+ # gitweb.output is used to parse HTTP output
+ # gitweb.headers contains only HTTP headers
+ # gitweb.body contains body of message, without headers
}
. ./test-lib.sh
--
1.6.5
^ permalink raw reply related
* [RFC/PATCH v6 2/2] gitweb: Smarter snapshot names
From: Jakub Narebski @ 2009-10-29 22:07 UTC (permalink / raw)
To: git; +Cc: Mark Rada, Shawn O. Pearce, Jakub Narebski
In-Reply-To: <1256854062-25496-2-git-send-email-jnareb@gmail.com>
From: Mark Rada <marada@uwaterloo.ca>
Teach gitweb how to produce nicer snapshot names by only using the
short hash id. If clients make requests using a tree-ish that is not
a partial or full SHA-1 hash, then the short hash will also be appended
to whatever they asked for. If clients request snapshot of a tag
(which means that $hash ('h') parameter has 'refs/tags/' prefix),
use only tag name.
This also includes tests cases for t9502-gitweb-standalone-parse-output.
Signed-off-by: Mark Rada <marada@uwaterloo.ca>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
---
This is currently an RFC because commit message does not describe
changes completely. Among others it doesn't describe current rules.
Also tests could be better described.
Changes since v5 (by Mark Rada):
- put common parts of git_get_full_hash and git_get_short_hash
into git_get_hash, do not do double verification
- separate finding snapshot name and prefix in snapshot_name()
subroutine, more smarts for snapshot name
- improved tests (use 'tar' snapshot format, testing new smarts,
testing prefix)
gitweb/gitweb.perl | 76 +++++++++++++++----
t/t9502-gitweb-standalone-parse-output.sh | 112 +++++++++++++++++++++++++++++
2 files changed, 172 insertions(+), 16 deletions(-)
create mode 100755 t/t9502-gitweb-standalone-parse-output.sh
diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
index 8d4a2ae..d8dfd95 100755
--- a/gitweb/gitweb.perl
+++ b/gitweb/gitweb.perl
@@ -1983,16 +1983,27 @@ sub quote_command {
# get HEAD ref of given project as hash
sub git_get_head_hash {
- my $project = shift;
+ return git_get_full_hash(shift, 'HEAD');
+}
+
+sub git_get_full_hash {
+ return git_get_hash(@_);
+}
+
+sub git_get_short_hash {
+ return git_get_hash(@_, '--short=7');
+}
+
+sub git_get_hash {
+ my ($project, $hash, @options) = @_;
my $o_git_dir = $git_dir;
my $retval = undef;
$git_dir = "$projectroot/$project";
- if (open my $fd, "-|", git_cmd(), "rev-parse", "--verify", "HEAD") {
- my $head = <$fd>;
+ if (open my $fd, '-|', git_cmd(), 'rev-parse',
+ '--verify', '-q', @options, $hash) {
+ $retval = <$fd>;
+ chomp $retval if defined $retval;
close $fd;
- if (defined $head && $head =~ /^([0-9a-fA-F]{40})$/) {
- $retval = $1;
- }
}
if (defined $o_git_dir) {
$git_dir = $o_git_dir;
@@ -5179,6 +5190,43 @@ sub git_tree {
git_footer_html();
}
+sub snapshot_name {
+ my ($project, $hash) = @_;
+
+ # path/to/project.git -> project
+ # path/to/project/.git -> project
+ my $name = to_utf8($project);
+ $name =~ s,([^/])/*\.git$,$1,;
+ $name = basename($name);
+ # sanitize name
+ $name =~ s/[[:cntrl:]]/?/g;
+
+ my $ver = $hash;
+ if ($hash =~ /^[0-9a-fA-F]+$/) {
+ # shorten SHA-1 hash
+ my $full_hash = git_get_full_hash($project, $hash);
+ if ($full_hash =~ /^$hash/ && length($hash) > 7) {
+ $ver = git_get_short_hash($project, $hash);
+ }
+ } elsif ($hash =~ m!^refs/tags/(.*)$!) {
+ # tags don't need shortened SHA-1 hash
+ $ver = $1;
+ } else {
+ # branches and other need shortened SHA-1 hash
+ if ($hash =~ m!^refs/(?:heads|remotes)/(.*)$!) {
+ $ver = $1;
+ }
+ $ver .= '-' . git_get_short_hash($project, $hash);
+ }
+ # in case of hierarchical branch names
+ $ver =~ s!/!.!g;
+
+ # name = project-version_string
+ $name = "$name-$ver";
+
+ return wantarray ? ($name, $name) : $name;
+}
+
sub git_snapshot {
my $format = $input_params{'snapshot_format'};
if (!@snapshot_fmts) {
@@ -5203,24 +5251,20 @@ sub git_snapshot {
die_error(400, 'Object is not a tree-ish');
}
- my $name = $project;
- $name =~ s,([^/])/*\.git$,$1,;
- $name = basename($name);
- my $filename = to_utf8($name);
- $name =~ s/\047/\047\\\047\047/g;
- my $cmd;
- $filename .= "-$hash$known_snapshot_formats{$format}{'suffix'}";
- $cmd = quote_command(
+ my ($name, $prefix) = snapshot_name($project, $hash);
+ my $filename = "$name$known_snapshot_formats{$format}{'suffix'}";
+ my $cmd = quote_command(
git_cmd(), 'archive',
"--format=$known_snapshot_formats{$format}{'format'}",
- "--prefix=$name/", $hash);
+ "--prefix=$prefix/", $hash);
if (exists $known_snapshot_formats{$format}{'compressor'}) {
$cmd .= ' | ' . quote_command(@{$known_snapshot_formats{$format}{'compressor'}});
}
+ $filename =~ s/(["\\])/\\$1/g;
print $cgi->header(
-type => $known_snapshot_formats{$format}{'type'},
- -content_disposition => 'inline; filename="' . "$filename" . '"',
+ -content_disposition => 'inline; filename="' . $filename . '"',
-status => '200 OK');
open my $fd, "-|", $cmd
diff --git a/t/t9502-gitweb-standalone-parse-output.sh b/t/t9502-gitweb-standalone-parse-output.sh
new file mode 100755
index 0000000..fbf4e26
--- /dev/null
+++ b/t/t9502-gitweb-standalone-parse-output.sh
@@ -0,0 +1,112 @@
+#!/bin/sh
+#
+# Copyright (c) 2009 Mark Rada
+#
+
+test_description='gitweb as standalone script (parsing script output).
+
+This test runs gitweb (git web interface) as a CGI script from the
+commandline, and checks that it produces the correct output, either
+in the HTTP header or the actual script output.'
+
+
+. ./gitweb-lib.sh
+
+# ----------------------------------------------------------------------
+# snapshot file name
+
+cat >>gitweb_config.perl <<\EOF
+
+$known_snapshot_formats{'tar'} = {
+ 'display' => 'tar',
+ 'type' => 'application/x-tar',
+ 'suffix' => '.tar',
+ 'format' => 'tar',
+};
+
+$feature{'snapshot'}{'default'} = ['tar'];
+EOF
+
+test_expect_success setup '
+ test_commit first foo &&
+ git branch xx/test &&
+ FULL_ID=$(git rev-parse --verify HEAD) &&
+ SHORT_ID=$(git rev-parse --verify --short=7 HEAD)
+'
+test_debug '
+ echo "FULL_ID = $FULL_ID"
+ echo "SHORT_ID = $SHORT_ID"
+'
+
+test_expect_success 'snapshots: give full hash' '
+ gitweb_run "p=.git;a=snapshot;h=$FULL_ID;sf=tar" &&
+ grep ".git-$SHORT_ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+test_debug 'cat gitweb.log'
+
+test_expect_success 'snapshots: give short hash' '
+ gitweb_run "p=.git;a=snapshot;h=$SHORT_ID;sf=tar" &&
+ grep ".git-$SHORT_ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give almost full hash' '
+ ID=$(git rev-parse --short=30 HEAD) &&
+ gitweb_run "p=.git;a=snapshot;h=$ID;sf=tar" &&
+ grep ".git-$SHORT_ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give HEAD' '
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tar" &&
+ grep ".git-HEAD-$SHORT_ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give short branch name' '
+ gitweb_run "p=.git;a=snapshot;h=master;sf=tar" &&
+ ID=$(git rev-parse --verify --short=7 master) &&
+ grep ".git-master-$ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give short tag name' '
+ gitweb_run "p=.git;a=snapshot;h=first;sf=tar" &&
+ ID=$(git rev-parse --verify --short=7 first) &&
+ grep ".git-first-$ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give full branch name' '
+ gitweb_run "p=.git;a=snapshot;h=refs/heads/master;sf=tar" &&
+ ID=$(git rev-parse --verify --short=7 master) &&
+ grep ".git-master-$ID.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give full tag name' '
+ gitweb_run "p=.git;a=snapshot;h=refs/tags/first;sf=tar" &&
+ grep ".git-first.tar" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+test_expect_success 'snapshots: give hierarchical branch name' '
+ gitweb_run "p=.git;a=snapshot;h=xx/test;sf=tar" &&
+ grep -v "filename=.*/" gitweb.headers
+'
+test_debug 'cat gitweb.headers'
+
+cat >expected <<EOF
+.git-HEAD-$SHORT_ID/
+.git-HEAD-$SHORT_ID/foo
+EOF
+test_expect_success 'snapshots: check prefix' '
+ gitweb_run "p=.git;a=snapshot;h=HEAD;sf=tar" &&
+ grep ".git-HEAD-$SHORT_ID.tar" gitweb.headers &&
+ "$TAR" tf gitweb.body >actual &&
+ test_cmp expected actual
+'
+test_debug 'cat gitweb.headers'
+
+test_done
--
1.6.5
^ permalink raw reply related
* [PATCH 0/2] gitweb: Smarter snapshot names
From: Jakub Narebski @ 2009-10-29 22:07 UTC (permalink / raw)
To: git; +Cc: Mark Rada, Jakub Narebski
This series is proposed proposed replacement for a single top commit
in 'mr/gitweb-snapshot' branch, which was merged into pu.
Those two patches are meant to replace the following commit:
b411a7a (gitweb: append short hash ids to snapshot files, 2009-09-26)
Jakub Narebski (1):
t/gitweb-lib.sh: Split gitweb output into headers and body
Mark Rada (1):
gitweb: Smarter snapshot names
(formerly: gitweb: append short hash ids to snapshot files)
Table of contents:
~~~~~~~~~~~~~~~~~~
[PATCH 1/2] t/gitweb-lib.sh: Split gitweb output into headers and body
[RFC/PATCH v6 2/2] gitweb: Smarter snapshot names
gitweb/gitweb.perl | 76 +++++++++++++++----
t/gitweb-lib.sh | 6 ++-
t/t9502-gitweb-standalone-parse-output.sh | 112 +++++++++++++++++++++++++++++
3 files changed, 177 insertions(+), 17 deletions(-)
create mode 100755 t/t9502-gitweb-standalone-parse-output.sh
--
Jakub Narebski
Poland
^ permalink raw reply
* Re: [PATCH/RFC 2/2] Provide a build time default-editor setting
From: Junio C Hamano @ 2009-10-29 22:12 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, David Roundy, Jonathan Nieder, Ben Walton,
GIT List
In-Reply-To: <200910292157.37474.j.sixt@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Yeah, whatever, I didn't take the time to think it through. But this may be an
> opportunity to give some life back to the zombie that git-var currently is,
> that is, to make it the plumbing that does value discovery for variables like
> GIT_AUTHOR_INDENT, GIT_COMMITTER_IDENT, GIT_EDITOR, and perhaps also
> GIT_PAGER.
Hmm, wouldn't it make even more sense to "run" them for the calling
Porcelain script?
A shell script Porcelain can already ". git-sh-setup" and say
git_editor this-file
when it needs to spawn the editor of choice. Your new plumbing support
could make the definition of git_editor in git-sh-setup.sh into something
like:
git_editor() {
git var --run GIT_EDITOR "$@"
}
git_pager() {
git var --run GIT_PAGER "$@"
}
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool option
From: Charles Bailey @ 2009-10-29 22:12 UTC (permalink / raw)
To: Scott Chacon, Jay Soffian; +Cc: git list, Junio C Hamano, David Aguilar
In-Reply-To: <d411cc4a0910281439v3388c243v42b3700f73744623@mail.gmail.com>
On Wed, Oct 28, 2009 at 02:39:32PM -0700, Scott Chacon wrote:
> p4merge is now a built-in diff/merge tool.
> This adds p4merge to git-completion and updates
> the documentation to mention p4merge.
>
> Signed-Off-By: Scott Chacon <schacon@gmail.com>
> ---
>
> This is the same patch, but I tested it on Linux as well as Mac and it
> works fine as long as the [difftool|mergetool].p4merge.path configs
> are set or it's in your path.
I've examined the two patches and I feel more comfortable with
Scott's, mainly due to it's simplicity.
I'm not sure I understand why only p4merge on Mac OS X is special, we
don't seem to treat any other mergetool specially and we don't seem to
need absolute paths anywhere else.
If it's a Mac OS X only thing, can we (and should we) avoid special
treatment for p4merge on other platforms?
The only other question I have is what are the merits of using
/dev/null as the base vs. a second copy of the local version in the
baseless merge case? It's the only other difference between the two
p4merge patches that I noticed.
Perhaps we could consider having both p4merge and launchp4merge as
separate options?
--
Charles Bailey
http://ccgi.hashpling.plus.com/blog/
^ permalink raw reply
* [PATCH] Teach 'git merge' and 'git pull' the option --ff-only
From: Björn Gustavsson @ 2009-10-29 22:08 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
For convenience in scripts and aliases, add the option
--ff-only to only allow fast-forwards (and up-to-date,
despite the name).
Disallow combining --ff-only and --no-ff, since they
flatly contradict each other.
Allow all other options to be combined with --ff-only
(i.e. do not add any code to handle them specially),
including the following options:
* --strategy (one or more): As long as the chosen merge
strategy results in up-to-date or fast-forward, the
command will succeed.
* --squash: I cannot imagine why anyone would want to
squash commits only if fast-forward is possible, but I
also see no reason why it should not be allowed.
* --message: The message will always be ignored, but I see
no need to explicitly disallow providing a redundant message.
Acknowledgements: I did look at Yuval Kogman's earlier
patch (107768 in gmane), mainly as shortcut to find my
way in the code, but I did not copy anything directly.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
Here is a re-roll of my previous patch with improvements
suggested by Junio's review. Compared to the previous version,
I have changed the following:
* The documentation now clearly states that up-to-date
is also allowed.
* The redundant and incorrect test to reject merge strategies
that do not allow fast-forward has been removed (along
with the corresponding test case).
* I have added some background on the design decisions to
the commit message.
* I have added two test cases to test --squash in combination
with --ff-only.
Documentation/merge-options.txt | 5 ++++
builtin-merge.c | 11 +++++++++-
git-pull.sh | 7 ++++-
t/t7600-merge.sh | 41 +++++++++++++++++++++++++++++++++++++++
4 files changed, 61 insertions(+), 3 deletions(-)
diff --git a/Documentation/merge-options.txt b/Documentation/merge-options.txt
index adadf8e..27a9a84 100644
--- a/Documentation/merge-options.txt
+++ b/Documentation/merge-options.txt
@@ -60,6 +60,11 @@
a fast-forward, only update the branch pointer. This is
the default behavior of git-merge.
+--ff-only::
+ Refuse to merge and exit with a non-zero status unless the
+ current `HEAD` is already up-to-date or the merge can be
+ resolved as a fast-forward.
+
-s <strategy>::
--strategy=<strategy>::
Use the given merge strategy; can be supplied more than
diff --git a/builtin-merge.c b/builtin-merge.c
index b6b8428..5e8c4b5 100644
--- a/builtin-merge.c
+++ b/builtin-merge.c
@@ -43,6 +43,7 @@ static const char * const builtin_merge_usage[] = {
static int show_diffstat = 1, option_log, squash;
static int option_commit = 1, allow_fast_forward = 1;
+static int fast_forward_only;
static int allow_trivial = 1, have_message;
static struct strbuf merge_msg;
static struct commit_list *remoteheads;
@@ -167,6 +168,8 @@ static struct option builtin_merge_options[] = {
"perform a commit if the merge succeeds (default)"),
OPT_BOOLEAN(0, "ff", &allow_fast_forward,
"allow fast forward (default)"),
+ OPT_BOOLEAN(0, "ff-only", &fast_forward_only,
+ "abort if fast forward is not possible"),
OPT_CALLBACK('s', "strategy", &use_strategies, "strategy",
"merge strategy to use", option_parse_strategy),
OPT_CALLBACK('m', "message", &merge_msg, "message",
@@ -874,6 +877,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
option_commit = 0;
}
+ if (!allow_fast_forward && fast_forward_only)
+ die("You cannot combine --no-ff with --ff-only.");
+
if (!argc)
usage_with_options(builtin_merge_usage,
builtin_merge_options);
@@ -1040,7 +1046,7 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
* only one common.
*/
refresh_cache(REFRESH_QUIET);
- if (allow_trivial) {
+ if (allow_trivial && !fast_forward_only) {
/* See if it is really trivial. */
git_committer_info(IDENT_ERROR_ON_NO_NAME);
printf("Trying really trivial in-index merge...\n");
@@ -1079,6 +1085,9 @@ int cmd_merge(int argc, const char **argv, const char *prefix)
}
}
+ if (fast_forward_only)
+ die("Not possible to fast forward, aborting.");
+
/* We are going to make a new commit. */
git_committer_info(IDENT_ERROR_ON_NO_NAME);
diff --git a/git-pull.sh b/git-pull.sh
index fc78592..37f3d93 100755
--- a/git-pull.sh
+++ b/git-pull.sh
@@ -16,7 +16,8 @@ cd_to_toplevel
test -z "$(git ls-files -u)" ||
die "You are in the middle of a conflicted merge."
-strategy_args= diffstat= no_commit= squash= no_ff= log_arg= verbosity=
+strategy_args= diffstat= no_commit= squash= no_ff= ff_only=
+log_arg= verbosity=
curr_branch=$(git symbolic-ref -q HEAD)
curr_branch_short=$(echo "$curr_branch" | sed "s|refs/heads/||")
rebase=$(git config --bool branch.$curr_branch_short.rebase)
@@ -45,6 +46,8 @@ do
no_ff=--ff ;;
--no-ff)
no_ff=--no-ff ;;
+ --ff-only)
+ ff_only=--ff-only ;;
-s=*|--s=*|--st=*|--str=*|--stra=*|--strat=*|--strate=*|\
--strateg=*|--strategy=*|\
-s|--s|--st|--str|--stra|--strat|--strate|--strateg|--strategy)
@@ -215,5 +218,5 @@ merge_name=$(git fmt-merge-msg $log_arg <"$GIT_DIR/FETCH_HEAD") || exit
test true = "$rebase" &&
exec git-rebase $diffstat $strategy_args --onto $merge_head \
${oldremoteref:-$merge_head}
-exec git-merge $diffstat $no_commit $squash $no_ff $log_arg $strategy_args \
+exec git-merge $diffstat $no_commit $squash $no_ff $ff_only $log_arg $strategy_args \
"$merge_name" HEAD $merge_head $verbosity
diff --git a/t/t7600-merge.sh b/t/t7600-merge.sh
index e5b210b..57f6d2b 100755
--- a/t/t7600-merge.sh
+++ b/t/t7600-merge.sh
@@ -243,6 +243,16 @@ test_expect_success 'merge c0 with c1' '
test_debug 'gitk --all'
+test_expect_success 'merge c0 with c1 with --ff-only' '
+ git reset --hard c0 &&
+ git merge --ff-only c1 &&
+ git merge --ff-only HEAD c0 c1 &&
+ verify_merge file result.1 &&
+ verify_head "$c1"
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c2' '
git reset --hard c1 &&
test_tick &&
@@ -263,6 +273,14 @@ test_expect_success 'merge c1 with c2 and c3' '
test_debug 'gitk --all'
+test_expect_success 'failing merges with --ff-only' '
+ git reset --hard c1 &&
+ test_tick &&
+ test_must_fail git merge --ff-only c2 &&
+ test_must_fail git merge --ff-only c3 &&
+ test_must_fail git merge --ff-only c2 c3
+'
+
test_expect_success 'merge c0 with c1 (no-commit)' '
git reset --hard c0 &&
git merge --no-commit c1 &&
@@ -303,6 +321,17 @@ test_expect_success 'merge c0 with c1 (squash)' '
test_debug 'gitk --all'
+test_expect_success 'merge c0 with c1 (squash, ff-only)' '
+ git reset --hard c0 &&
+ git merge --squash --ff-only c1 &&
+ verify_merge file result.1 &&
+ verify_head $c0 &&
+ verify_no_mergehead &&
+ verify_diff squash.1 .git/SQUASH_MSG "[OOPS] bad squash message"
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c2 (squash)' '
git reset --hard c1 &&
git merge --squash c2 &&
@@ -314,6 +343,13 @@ test_expect_success 'merge c1 with c2 (squash)' '
test_debug 'gitk --all'
+test_expect_success 'unsuccesful merge of c1 with c2 (squash, ff-only)' '
+ git reset --hard c1 &&
+ test_must_fail git merge --squash --ff-only c2
+'
+
+test_debug 'gitk --all'
+
test_expect_success 'merge c1 with c2 and c3 (squash)' '
git reset --hard c1 &&
git merge --squash c2 c3 &&
@@ -432,6 +468,11 @@ test_expect_success 'combining --squash and --no-ff is refused' '
test_must_fail git merge --no-ff --squash c1
'
+test_expect_success 'combining --ff-only and --no-ff is refused' '
+ test_must_fail git merge --ff-only --no-ff c1 &&
+ test_must_fail git merge --no-ff --ff-only c1
+'
+
test_expect_success 'merge c0 with c1 (ff overrides no-ff)' '
git reset --hard c0 &&
git config branch.master.mergeoptions "--no-ff" &&
--
1.6.5.1.69.g36942
^ permalink raw reply related
* Add gitk-hit/po Hungarian translation
From: Laszlo Papp @ 2009-10-29 22:40 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 116 bytes --]
Hello,
See the Hungarian translation for gitk-git in the attachment!
Thanks in advance
Best Regards,
Laszlo Papp
[-- Attachment #2: hu.po.tar.bz2 --]
[-- Type: application/x-bzip2, Size: 6776 bytes --]
^ permalink raw reply
* Re: [PATCH] More precise description of 'git describe --abbrev'
From: Junio C Hamano @ 2009-10-29 22:47 UTC (permalink / raw)
To: Gisle Aas; +Cc: git
In-Reply-To: <b48ea8a00910291438r8b66a0fq9e821393ecfff0bf@mail.gmail.com>
Gisle Aas <gisle@aas.no> writes:
> Also make the examples show what 'git describe' actually outputs
> currently. I guess the default --abbrev value has been changed from 4
> to 7 at some point.
Some are good changes, but I do not think the example with --abbrev=4 is.
$ git describe 975bf9cf5ad5d440f98f464ae8124609a4835ce1
v1.3.2-216-g975bf9c
$ git describe 975b31dc6e12fba8f7b067ddbe32230995e05400
v1.0.0-21-g975b31d
Next time somebody adds a new object whose name happens to begin with
975b3 you would need to update the example output.
> Signed-off-by: Gisle Aas <gisle@aas.no>
> ---
> Documentation/git-describe.txt | 12 +++++++-----
> 1 files changed, 7 insertions(+), 5 deletions(-)
>
> diff --git a/Documentation/git-describe.txt b/Documentation/git-describe.txt
> index b231dbb..743eb95 100644
> --- a/Documentation/git-describe.txt
> +++ b/Documentation/git-describe.txt
> @@ -44,7 +44,9 @@ OPTIONS
>
> --abbrev=<n>::
> Instead of using the default 7 hexadecimal digits as the
> - abbreviated object name, use <n> digits.
> + abbreviated object name, use <n> digits or as many digits
> + are needed to form a unique object name. An <n> of 0
> + will suppress long format, only showing the closest tag.
>
> --candidates=<n>::
> Instead of considering only the 10 most recent tags as
> @@ -68,8 +70,8 @@ OPTIONS
> This is useful when you want to see parts of the commit object name
> in "describe" output, even when the commit in question happens to be
> a tagged version. Instead of just emitting the tag name, it will
> - describe such a commit as v1.2-0-deadbeef (0th commit since tag v1.2
> - that points at object deadbeef....).
> + describe such a commit as v1.2-0-gdeadbee (0th commit since tag v1.2
> + that points at object deadbee....).
>
> --match <pattern>::
> Only consider tags matching the given pattern (can be used to avoid
> @@ -106,10 +108,10 @@ With --all, the command can use branch heads as
> references, so
> the output shows the reference path as well:
>
> [torvalds@g5 git]$ git describe --all --abbrev=4 v1.0.5^2
> - tags/v1.0.0-21-g975b
> + tags/v1.0.0-21-g975b3
>
> [torvalds@g5 git]$ git describe --all HEAD^
> - heads/lt/describe-7-g975b
> + heads/lt/describe-7-g975b31d
>
> With --abbrev set to 0, the command can be used to find the
> closest tagname without any suffix:
> --
> 1.6.2.95.g934f7
^ permalink raw reply
* Re: Tracking a remote branch in git
From: Tim Mazid @ 2009-10-30 0:26 UTC (permalink / raw)
To: git
In-Reply-To: <26119537.post@talk.nabble.com>
Sips wrote:
>
> Then I created a branch in the repository on the removable drive W and
> named it newfeature. The question is: How can I work with this branch on
> the local repository as well? I mean, I need the same 'relationship'
> between branches as in case of the master branch.
>
> ...
>
> I mean, I am able to track the master branch from the remote repository.
> Why can't I track some other branch as well? Any ideas what I'm doing
> wrong?
>
Have you tried doing 'git fetch'? That should get and track all new remote
branches automatically.
Once you have a remote branch, if you've deleted the local branch, you can
just do 'git branch LOCAL REMOTE', and that should set up a tracking branch.
If this doesn't work for you, check your git version with 'git --version'.
It works for v1.6.5.2.
Good luck,
Tim.
--
View this message in context: http://www.nabble.com/Tracking-a-remote-branch-in-git-tp26119537p26123156.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool option
From: Jay Soffian @ 2009-10-30 0:47 UTC (permalink / raw)
To: Charles Bailey; +Cc: Scott Chacon, git list, Junio C Hamano, David Aguilar
In-Reply-To: <20091029221234.GB32590@hashpling.org>
On Thu, Oct 29, 2009 at 6:12 PM, Charles Bailey <charles@hashpling.org> wrote:
> I'm not sure I understand why only p4merge on Mac OS X is special, we
> don't seem to treat any other mergetool specially and we don't seem to
> need absolute paths anywhere else.
On other platforms, the merge tool is very likely to be in your PATH.
On OS X, p4merge is going to be installed as part of an application
bundle (/Applications/p4merge.app or $HOME/Applications/p4merge.app).
This is virtually never going to be in a user's PATH.
So in order to provide equivalent behavior for OS X as Linux (i.e., so
that you can just specify p4merge as the mergetool without having to
provide it's path), we need to look in these additional locations.
> If it's a Mac OS X only thing, can we (and should we) avoid special
> treatment for p4merge on other platforms?
It is a Mac OS X only thing. Yes, we could avoid looking in these
locations on other platforms, but why? Using type to look for the
executable is virtually no cost. The alternative (calling uname to
determine the platform) requires running a separate process.
> The only other question I have is what are the merits of using
> /dev/null as the base vs. a second copy of the local version in the
> baseless merge case? It's the only other difference between the two
> p4merge patches that I noticed.
p4merge's argument handling is stupid, you need to pass it a dummy
argument in some cases. A second copy of the local version is probably
better than /dev/null. Actually, I think just passing it an empty
argument ("") works too.
> Perhaps we could consider having both p4merge and launchp4merge as
> separate options?
I think that would be over-engineered. Decide on one or the other.
They have slightly different semantics as I've previously described.
Personally I think calling launchp4merge provides a more Mac-like
behavior, but honestly it doesn't make much difference.
j.
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool option
From: Markus Heidelberg @ 2009-10-30 1:02 UTC (permalink / raw)
To: Jay Soffian
Cc: Charles Bailey, Scott Chacon, git list, Junio C Hamano,
David Aguilar
In-Reply-To: <76718490910291747l165baf49tab781727d010610a@mail.gmail.com>
Jay Soffian, 30.10.2009:
> On Thu, Oct 29, 2009 at 6:12 PM, Charles Bailey <charles@hashpling.org> wrote:
> > I'm not sure I understand why only p4merge on Mac OS X is special, we
> > don't seem to treat any other mergetool specially and we don't seem to
> > need absolute paths anywhere else.
>
> On other platforms, the merge tool is very likely to be in your PATH.
He didn't mean p4merge on other platforms, but other merge tools on Mac
OS X. What about all the other merge tools already in mergetool--lib?
Should they get special handling, too?
> On OS X, p4merge is going to be installed as part of an application
> bundle (/Applications/p4merge.app or $HOME/Applications/p4merge.app).
> This is virtually never going to be in a user's PATH.
>
> So in order to provide equivalent behavior for OS X as Linux (i.e., so
> that you can just specify p4merge as the mergetool without having to
> provide it's path), we need to look in these additional locations.
And for Windows we could add C:\Program Files\MergeToolX\tool.exe for
every merge tool.
But where will we end?
Markus
^ permalink raw reply
* [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Brian Collins @ 2009-10-30 1:21 UTC (permalink / raw)
To: git
You will have to excuse me, this is my first patch and I don't know if
this is the right place to post this. Apologies in advance if I'm in
the wrong place.
git-grep currently throws an error when you combine the -F and -i
flags. This isn't in line with how GNU grep handles it. This patch
allows the simultaneous use of those flags.
---
builtin-grep.c | 8 +++++---
grep.c | 16 ++++++++++++----
grep.h | 2 ++
3 files changed, 19 insertions(+), 7 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 761799d..c73f05b 100644
--- a/builtin-grep.c
+++ b/builtin-grep.c
@@ -367,7 +367,7 @@ static int external_grep(struct grep_opt *opt,
const char **paths, int cached)
push_arg("-h");
if (opt->regflags & REG_EXTENDED)
push_arg("-E");
- if (opt->regflags & REG_ICASE)
+ if (opt->caseless)
push_arg("-i");
if (opt->binary == GREP_BINARY_NOMATCH)
push_arg("-I");
@@ -706,8 +706,8 @@ int cmd_grep(int argc, const char **argv, const
char *prefix)
OPT_GROUP(""),
OPT_BOOLEAN('v', "invert-match", &opt.invert,
"show non-matching lines"),
- OPT_BIT('i', "ignore-case", &opt.regflags,
- "case insensitive matching", REG_ICASE),
+ OPT_BOOLEAN('i', "ignore-case", &opt.caseless,
+ "case insensitive matching"),
OPT_BOOLEAN('w', "word-regexp", &opt.word_regexp,
"match patterns only at word boundaries"),
OPT_SET_INT('a', "text", &opt.binary,
@@ -830,6 +830,8 @@ int cmd_grep(int argc, const char **argv, const
char *prefix)
external_grep_allowed = 0;
if (!opt.pattern_list)
die("no pattern given.");
+ if (!opt.fixed && opt.caseless)
+ opt.regflags |= REG_ICASE;
if ((opt.regflags != REG_NEWLINE) && opt.fixed)
die("cannot mix --fixed-strings and regexp");
compile_grep_patterns(&opt);
diff --git a/grep.c b/grep.c
index 5d162da..d8f14be 100644
--- a/grep.c
+++ b/grep.c
@@ -41,7 +41,8 @@ static void compile_regexp(struct grep_pat *p,
struct grep_opt *opt)
int err;
p->word_regexp = opt->word_regexp;
-
+ p->caseless = opt->caseless;
+
if (opt->fixed || is_fixed(p->pattern))
p->fixed = 1;
if (opt->regflags & REG_ICASE)
@@ -262,9 +263,16 @@ static void show_name(struct grep_opt *opt, const
char *name)
printf("%s%c", name, opt->null_following_name ? '\0' : '\n');
}
-static int fixmatch(const char *pattern, char *line, regmatch_t *match)
+
+static int fixmatch(const char *pattern, char *line, int caseless,
regmatch_t *match)
{
- char *hit = strstr(line, pattern);
+ char *hit;
+ if (caseless) {
+ hit = strcasestr(line, pattern);
+ } else {
+ hit = strstr(line, pattern);
+ }
+
if (!hit) {
match->rm_so = match->rm_eo = -1;
return REG_NOMATCH;
@@ -326,7 +334,7 @@ static int match_one_pattern(struct grep_pat *p,
char *bol, char *eol,
again:
if (p->fixed)
- hit = !fixmatch(p->pattern, bol, pmatch);
+ hit = !fixmatch(p->pattern, bol, p->caseless, pmatch);
else
hit = !regexec(&p->regexp, bol, 1, pmatch, eflags);
diff --git a/grep.h b/grep.h
index f6eecc6..24b7d44 100644
--- a/grep.h
+++ b/grep.h
@@ -32,6 +32,7 @@ struct grep_pat {
enum grep_header_field field;
regex_t regexp;
unsigned fixed:1;
+ unsigned caseless:1;
unsigned word_regexp:1;
};
@@ -64,6 +65,7 @@ struct grep_opt {
regex_t regexp;
int linenum;
int invert;
+ int caseless;
int status_only;
int name_only;
int unmatch_name_only;
--
1.6.4.4
^ permalink raw reply related
* Re: [PATCH/RFC 2/2] Provide a build time default-editor setting
From: David Roundy @ 2009-10-30 2:21 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, Jonathan Nieder, Ben Walton, GIT List
In-Reply-To: <7vfx916ea6.fsf@alter.siamese.dyndns.org>
On Thu, Oct 29, 2009 at 6:12 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Johannes Sixt <j.sixt@viscovery.net> writes:
>
>> Yeah, whatever, I didn't take the time to think it through. But this may be an
>> opportunity to give some life back to the zombie that git-var currently is,
>> that is, to make it the plumbing that does value discovery for variables like
>> GIT_AUTHOR_INDENT, GIT_COMMITTER_IDENT, GIT_EDITOR, and perhaps also
>> GIT_PAGER.
>
> Hmm, wouldn't it make even more sense to "run" them for the calling
> Porcelain script?
That was what I had been thinking. That way the caller doesn't need
to know whether it may be a space-containing absolute path or an
executable with flags, as long as git knows what to do.
David
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add p4merge as a pre-configured mergetool option
From: Jay Soffian @ 2009-10-30 3:00 UTC (permalink / raw)
To: markus.heidelberg
Cc: Charles Bailey, Scott Chacon, git list, Junio C Hamano,
David Aguilar
In-Reply-To: <200910300202.02016.markus.heidelberg@web.de>
On Thu, Oct 29, 2009 at 9:02 PM, Markus Heidelberg
<markus.heidelberg@web.de> wrote:
> He didn't mean p4merge on other platforms, but other merge tools on Mac
> OS X. What about all the other merge tools already in mergetool--lib?
> Should they get special handling, too?
If someone wants to scratch that itch, then yes. The default diff tool
for OS X has its helper already in /usr/bin (opendiff). p4merge is
arguably a better merge tool, and it installs as an app bundle in
/Applications. I'm not sure about the other diff tools, I haven't
looked.
> And for Windows we could add C:\Program Files\MergeToolX\tool.exe for
> every merge tool.
If it makes those tools easier to use with git, and if someone on
Windows wants to scratch that itch, then yes, we should.
> But where will we end?
I don't understand this argument. It's a few lines of code to make git
a little friendlier. We end when folks stop contributing patches
because either no one cares of there's nothing left to improve.
j.
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox