* Re: Idea for git-touch
From: Luís Sousa @ 2009-11-16 10:57 UTC (permalink / raw)
To: Andreas Ericsson; +Cc: git
In-Reply-To: <4AFD26ED.4020602@op5.se>
Andreas Ericsson wrote:
> On 11/12/2009 06:13 PM, Luís Sousa wrote:
>> Yeah, but still need some copy&paste of message :)
>>
>> Jan Krüger wrote:
>>> On Thu, 12 Nov 2009 17:05:21 +0000, Luís Sousa <llsousa@ualg.pt> wrote:
>>>> But still preserves the original date, isn't it?
>>>
>>> Yes, and I just remembered that, too. Sorry. Today is not my day.
>>>
>>> Even so, you can still save one command:
>>>
>>> git reset --soft HEAD^
>>> git commit
>>>
>
Thanks, but still preserves timestamp.
> Make that
>
> git reset --soft HEAD^ && git commit -C ORIG_HEAD
>
> and you won't have to bother with copy-pasting.
>
^ permalink raw reply
* Re: git am and CRLF files
From: Stefan Naewe @ 2009-11-16 11:15 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: git@vger.kernel.org
In-Reply-To: <20091116195036.6117@nanako3.lavabit.com>
On 11/16/2009 11:50 AM, Nanako Shiraishi wrote:
> Quoting Stefan Naewe <stefan.naewe@atlas-elektronik.com>
>
>>> A repository with some UNIX (LF) and some Windows (CRLF) files.
>>> (and no: I will not change the files. My editors handle CRLF and LF correctly)
>>>
>>> My problem:
>>>
>>> 'git am' can't handle changes in CRLF files because the patch
>>> gets converted (by git mailsplit) to contain only LF.
>>> Stefan
>> Does anyone have any comment on this ?
>
> This was done very much on purpose.
>
> The "am" command is meant to handle e-mailed patches, and traditionally
> mails are known to clobber carriage returns.
>
> See commit c2ca1d79dbd54b06a05e5d14a897699e59dc9f9f
>
> Allow mailsplit (and hence git-am) to handle mails with CRLF line-endings
>
> It is not that uncommon to have mails with DOS line-ending, notably
> Thunderbird and web mailers like Gmail (when saving what they call
> "original" message). So modify mailsplit to convert CRLF line-endings to
> just LF.
>
I've noticed that.
But converting everything just breaks git am for CRLF files, doesn't it ?
Wouldn't it be possible (and sensible) to not convert the diff text, but
only the rest (mail text, headers, etc.) ?
Regards,
Stefan
--
----------------------------------------------------------------
/dev/random says: Change is inevitable, except from a vending machine.
^ permalink raw reply
* Re: git am and CRLF files
From: Erik Faye-Lund @ 2009-11-16 11:43 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Stefan Naewe, git@vger.kernel.org
In-Reply-To: <20091116195036.6117@nanako3.lavabit.com>
On Mon, Nov 16, 2009 at 11:50 AM, Nanako Shiraishi <nanako3@lavabit.com> wrote:
> Quoting Stefan Naewe <stefan.naewe@atlas-elektronik.com>
>
>>> A repository with some UNIX (LF) and some Windows (CRLF) files.
>>> (and no: I will not change the files. My editors handle CRLF and LF correctly)
>>>
>>> My problem:
>>>
>>> 'git am' can't handle changes in CRLF files because the patch
>>> gets converted (by git mailsplit) to contain only LF.
>>
>>> Stefan
>>
>> Does anyone have any comment on this ?
>
> This was done very much on purpose.
>
> The "am" command is meant to handle e-mailed patches, and traditionally
> mails are known to clobber carriage returns.
>
According to RFC 5322, email messages use CRLF as the
newline-sequence. In order to be able to distinguish between CRLF and
LF in an e-mail patch, the message needs to be use some
transfer-encoding that preserves newline style (like base64).
Perhaps this would be better fixed by having format-patch (or prehaps
the MUA ?) base64-encode the message body if the file contains
non-LF-newlines, and normalizing CRLF to LF before transport-decoding?
Or does some MUAs transport-decode before storing the message to disk?
I realize this might make it a bit tricky to review patches that
contains CRLF-newlines before mailing them out, but perhaps inspecting
the format-patch output is the wrong place to do this?
--
Erik "kusma" Faye-Lund
^ permalink raw reply
* Re: Question about "git pull --rebase"
From: Francis Moreau @ 2009-11-16 12:00 UTC (permalink / raw)
To: Johan 't Hart; +Cc: Junio C Hamano, git
In-Reply-To: <4B006549.8050803@gmail.com>
On Sun, Nov 15, 2009 at 9:32 PM, Johan 't Hart <johanthart@gmail.com> wrote:
> Junio C Hamano schreef:
>>
>> Johan 't Hart <johanthart@gmail.com> writes:
>>>>
>>>> I've been somehow confused by the git-pull man page, which says:
>>>>
>>>> A parameter <ref> without a colon is equivalent to <ref>: when
>>>> pulling/fetching, so it merges <ref> into the current branch without
>>>> storing the remote branch anywhere locally
>>>>
>
>> Thanks for clearing it up.
>>
>> I was puzzled by the above pointing-finger because I wanted to see where a
>> misinformation originated from to fix it at the source. But still don't
>> see anything wrong with it.
>>
>
> My guess is that he was confused by '<ref>:' not meaning '<ref>:<ref>'. But
> I can't speak for him ofcource :)
>
Well, I don't remember how I started to think that:
<src>:
was equivalent to
<src>:<current-branch>
so, assuming I'm on branch 'foo':
$ git pull --rebase origin master:
was equivalent to
$ git pull --rebase origin master:foo
hence my confusion, which certainly due to my lack of attention
(sorry) when reading the man page.
> Refspecs confused me too at the beginning... But knowing more and more about
> git, it seems that this part of the docs look OK to me.. At most an example
> might make things a little more clear, but I doubt it is necessary.
Perhaps, the definition of a refspec with an empty string for <dst>
might be clearer if defined on its own. For example, doing this in the
git-pull man page:
<refspec>
The format of a <refspec> parameter is an ....
The remote ref that matches <src> is fetched,
if <dst> is not empty string, the local ref that
matches it is fast
forwarded using <src>. If the optional plus + is
used, the local ref is
updated even if it does not result in a fast forward update.
if <dst> is an empty string the fetched <src> is
merged into the
current branch without updating any local refs. In
this case the
optional + has no meaning.
Note
....
Some short-cut notations are also supported.
. A parameter <src> (<ref> without the ':<dst>' part)
is equivalent
to '<src>:' (a ref with an empty string for <dst>).
--
Francis
^ permalink raw reply
* Git graph with branch labels for all paths in text environment
From: rhlee @ 2009-11-16 12:03 UTC (permalink / raw)
To: git
Hi git forum,
Is there anyway to to view a text based git grah that shows all paths with
the branch labels? Like a on gitk but ncurses based?
I can get all paths in git log --graph, but I can't get the branch labels.
I can get all branch labels in tig, but only for the current branch.
Is there any feature that has the best of both worlds in a text-based
environment? I ask to text-based as I only have shell access to the server,
an X Windows environment.
Regards,
Richard
--
View this message in context: http://n2.nabble.com/Git-graph-with-branch-labels-for-all-paths-in-text-environment-tp4011651p4011651.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Question about "git pull --rebase"
From: Francis Moreau @ 2009-11-16 12:17 UTC (permalink / raw)
To: Johan 't Hart; +Cc: git
In-Reply-To: <4AFF3D4D.7000308@gmail.com>
On Sun, Nov 15, 2009 at 12:29 AM, Johan 't Hart <johanthart@gmail.com> wrote:
> This does not update any remote tracking branches, but it will rebase your
> foo branch on the remote master branch (which is what you want)
> It could also be done with:
>
> git pull --rebase origin master:origin/master
>
> This will also update your remote tracking branch refs/remotes/origin/master
> to match the master branch on the remote repo. Your foo branch will then be
> rebased onto it.
BTW, this seems to be not exact.
$ git pull --rebase origin master:origin/master
fetches the 'master' branch on the remote repo, then creates a new
branch 'origin/master', which is updated with the fetched branch.
To update the remote tracking branch refs/remotes/origin/master, I
need to issue:
$ git pull --rebase origin master:remotes/origin/master
BTW2, it looks like if the <dst> local ref doesn't exist the it will
be created. This something that appears very lately in the man page
(actually I can see the information only in the last example). This
could be part of the <refspec> defintion.
Thanks
--
Francis
^ permalink raw reply
* Re: Git graph with branch labels for all paths in text environment
From: Santi Béjar @ 2009-11-16 12:23 UTC (permalink / raw)
To: rhlee; +Cc: git
In-Reply-To: <1258373038892-4011651.post@n2.nabble.com>
On Mon, Nov 16, 2009 at 1:03 PM, rhlee <richard@webdezign.co.uk> wrote:
>
> Hi git forum,
>
> Is there anyway to to view a text based git grah that shows all paths with
> the branch labels? Like a on gitk but ncurses based?
For third-party tools you can check:
http://git-scm.com/tools
>
> I can get all paths in git log --graph, but I can't get the branch labels.
Have you tried --decorate?
I have an alias for this:
alias.logk = log --graph --pretty=oneline --abbrev-commit --decorate
HTH,
Santi
^ permalink raw reply
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Johannes Schindelin @ 2009-11-16 12:35 UTC (permalink / raw)
To: Thomas Rast
Cc: git, Nicolas Sebrecht, Baz, Peter Krefting, Björn Steinbrink
In-Reply-To: <efd7770d166a97481e8e31e407b9c2da02a341e5.1258309432.git.trast@student.ethz.ch>
Hi,
On Sun, 15 Nov 2009, Thomas Rast wrote:
> Using the "ours" strategy with rebase just discards all changes, turning
> <branch> into <upstream> (or <newbase> if given). This is unlikely to
> be what the user wants, so simply refuse to do it.
"Unlikely" or "impossible"?
Besides, I find it rather arbitrary that the "ours" strategy is refused,
but none of the user-provided merge strategies. IOW disallowing "ours"
may very well foster unreasonable expectations.
Ciao,
Dscho
^ permalink raw reply
* Re: Git graph with branch labels for all paths in text environment
From: Bill Lear @ 2009-11-16 13:30 UTC (permalink / raw)
To: Santi Béjar; +Cc: rhlee, git
In-Reply-To: <adf1fd3d0911160423q4e21126dm37be7838f0ce8379@mail.gmail.com>
On Monday, November 16, 2009 at 13:23:10 (+0100) Santi Béjar writes:
>On Mon, Nov 16, 2009 at 1:03 PM, rhlee <richard@webdezign.co.uk> wrote:
>> Is there anyway to to view a text based git grah that shows all paths with
>> the branch labels? Like a on gitk but ncurses based?
>
>For third-party tools you can check:
>
>http://git-scm.com/tools
Anything that can print this?:
H---I---J topicB
/
E---F---G topicA
/
A---B---C---D master
I've always liked the text-based format that keeps things in-line, as
above. Very readable. I thought someone on this list posted
something about a tool that could produce such graphs from
reasonably-sized git repos. Anyone have such a thing?
Bill
^ permalink raw reply
* Re: pushing remote branches
From: Lorenzo Bettini @ 2009-11-16 15:27 UTC (permalink / raw)
To: git
In-Reply-To: <2e24e5b90911150304i1472ed13k6c60611ef2e9ba19@mail.gmail.com>
Sitaram Chamarty wrote:
>
>> Thus, if I had
>>
>> [remote "origin"]
>> fetch = +refs/heads/*:refs/remotes/origin/*
>> url = git@...
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>> [branch "experiments"]
>> remote = origin
>> merge = refs/heads/experiments
>>
>> instead of
>>
>> [remote "origin"]
>> fetch = +refs/heads/*:refs/remotes/origin/*
>> url = git://...
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>> [branch "experiments"]
>> remote = origin
>> merge = refs/heads/experiments
>>
>> I would have been able to push also to branch experiments? Without having
>> to add
>>
>> [remote "experiments"]
>> url = git@...
>> fetch = +refs/heads/experiments:refs/remotes/experiments/experiments
>>
>> ?
>
> (by the way: do you mean refs/remotes/origin/experiments in that last
> line above?)
>
no, it's just like I wrote it...
you mean in
[remote "experiments"]
url = git@gitorious.org...
fetch =
+refs/heads/experiments:refs/remotes/experiments/experiments
or in
[branch "experiments"]
remote = origin
merge = refs/heads/experiments
?
> Anyway to answer your question, I do not see the refspec line as the issue
> here, but the URL for the repo, which determines how you access it.
so this would have been enough:
>> [remote "origin"]
>> fetch = +refs/heads/*:refs/remotes/origin/*
>> url = git://...
>> [branch "master"]
>> remote = origin
>> merge = refs/heads/master
>> [branch "experiments"]
>> remote = origin
>> merge = refs/heads/experiments
?
thanks
Lorenzo
--
Lorenzo Bettini, PhD in Computer Science, DI, Univ. Torino
HOME: http://www.lorenzobettini.it MUSIC: http://www.purplesucker.com
BLOGS: http://tronprog.blogspot.com http://longlivemusic.blogspot.com
^ permalink raw reply
* Re: Git graph with branch labels for all paths in text environment
From: Michael J Gruber @ 2009-11-16 15:27 UTC (permalink / raw)
To: Bill Lear; +Cc: Santi Béjar, rhlee, git
In-Reply-To: <19201.21478.127959.431877@lisa.zopyra.com>
Bill Lear venit, vidit, dixit 16.11.2009 14:30:
> On Monday, November 16, 2009 at 13:23:10 (+0100) Santi Béjar writes:
>> On Mon, Nov 16, 2009 at 1:03 PM, rhlee <richard@webdezign.co.uk> wrote:
>>> Is there anyway to to view a text based git grah that shows all paths with
>>> the branch labels? Like a on gitk but ncurses based?
>>
>> For third-party tools you can check:
>>
>> http://git-scm.com/tools
>
> Anything that can print this?:
>
> H---I---J topicB
> /
> E---F---G topicA
> /
> A---B---C---D master
>
> I've always liked the text-based format that keeps things in-line, as
> above. Very readable. I thought someone on this list posted
> something about a tool that could produce such graphs from
> reasonably-sized git repos. Anyone have such a thing?
You really mean horizontally? I know those wide screen monitors are
becoming ubiquitious, but still...
Or are you more after the "in-line" part in the sense that "each branch
is on its line"? This is a bit difficult to define, though (the graph
above is linear, e.g.).
Michael
^ permalink raw reply
* [PATCH 0/2] diffcore-break optimizations
From: Jeff King @ 2009-11-16 15:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
On one of my more ridiculously gigantic repositories, I recently tried
to make a commit that ran git out of memory while trying to commit. The
repository has about 3 gigabytes of data, and I made a small-ish change
to every file. Pathological, yes, but I think we can do better than
chugging for 5 minutes and dying.
The culprit turned out to be memory usage in diffcore-break, which is on
by default for "git status" (and for the "git commit" template message).
It wants to have every changed blob in memory at once, which is just
silly.
The patches are:
[1/2]: diffcore-break: free filespec data as we go
This addresses the memory consumption issue. If you have enough
memory, it doesn't actually yield a speed improvement, but nor does it
show any slowdown for practical workloads.
There is a theoretical slowdown when doing -B -M, because the rename
phase has to re-fetch the blobs from the object store. However, I
wasn't able to measure any slowdown for real-world cases (like "git
log --summary -M -B >/dev/null" on git.git).
I did manage to produce the slowdown on a pathological case: ten
20-megabyte files, each copied with a slight modification to another
file, and then replaced with totally different contents (so each one
will be broken and then trigger an inexact rename). That diff went
from 16s to 17s.
But I improved that and more with the next optimization.
[2/2]: diffcore-break: save cnt_data for other phases
We already do this in rename detection, and since they use the same
data format, there is little reason not to do so. My pathological case
above went from 17s down to 12s. I wasn't able to detect any speedup
or slowdown for sane cases.
So I doubt anybody will even notice this, but I think since we can
address pathological cases, we might as well (and as you will see, the
code change is quite small).
All of that being said, I was able to do my commit, but I still had to
wait five minutes for it to chug through 3G of data. :) I am tempted to
add a "quick" mode to git-commit, but perhaps such a ridiculous case is
rare enough not to worry about. I worked around it by writing my commit
message separately and using "git commit -F".
-Peff
^ permalink raw reply
* [PATCH 1/2] diffcore-break: free filespec data as we go
From: Jeff King @ 2009-11-16 15:56 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091116155331.GA30719@coredump.intra.peff.net>
As we look at each changed file and consider breaking it, we
load the blob data and make a decision about whether to
break, which is independent of any other blobs that might
have changed. However, we keep the data in memory while we
consider breaking all of the other files. Which means that
both versions of every file you are diffing are in memory at
the same time.
This patch instead frees the blob data as we finish with
each file pair, leading to much lower memory usage.
Signed-off-by: Jeff King <peff@peff.net>
---
As I noted in the cover letter, this can actually slow things down
slightly for some pathological cases, but I think the reduced memory
consumption is worth it. I couldn't come up with a real-world case where
it made any difference to the speed.
One other thing where _thought_ I might cause a slowdown was in fetching
the blobs for doing patch generation. But it turns out we drop the blobs
already after the diffcore merge, so they weren't living that long
anyway.
diffcore-break.c | 4 ++++
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/diffcore-break.c b/diffcore-break.c
index d7097bb..15562e4 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -204,12 +204,16 @@ void diffcore_break(int break_score)
dp->score = score;
dp->broken_pair = 1;
+ diff_free_filespec_data(p->one);
+ diff_free_filespec_data(p->two);
free(p); /* not diff_free_filepair(), we are
* reusing one and two here.
*/
continue;
}
}
+ diff_free_filespec_data(p->one);
+ diff_free_filespec_data(p->two);
diff_q(&outq, p);
}
free(q->queue);
--
1.6.5.2.187.g29317
^ permalink raw reply related
* [PATCH 2/2] diffcore-break: save cnt_data for other phases
From: Jeff King @ 2009-11-16 16:02 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091116155331.GA30719@coredump.intra.peff.net>
The "break" phase works by counting changes between two
blobs with the same path. We do this by splitting the file
into chunks (or lines for text oriented files) and then
keeping a count of chunk hashes.
The "rename" phase counts changes between blobs at two
different paths. However, it uses the exact same set of
chunk hashes (which are immutable for a given sha1).
The rename phase can therefore use the same hash data as
break. Unfortunately, we were throwing this data away after
computing it in the break phase. This patch instead attaches
it to the filespec and lets it live through the rename
phase, working under the assumption that most of the time
that breaks are being computed, renames will be too.
We only do this optimization for files which have actually
been broken, as those ones will be candidates for rename
detection (and it is a time-space tradeoff, so we don't want
to waste space keeping useless data).
Signed-off-by: Jeff King <peff@peff.net>
---
Note the two assumptions above:
1. If we are running break, we will probably run rename detection.
2. We are not looking for inexact copies, which could re-use data even
for non-broken pairs.
We could test both of those assumptions by peeking at the other
diff_options that have been set up, but that would involve some code
restructuring. I'm also not sure it is worth it.
For (1), if we don't do rename detection, the next thing we will do is
the diffcore merge, which will then free the data anyway. So we are
really just carrying around the extra cnt_data through the break, and it
is much smaller than the actual blob data.
For (2), keep in mind that this is just a heuristic. We may not have any
good rename candidates anyway, or we may find an exact rename. So it is
just a guess as to which data might be useful. Keeping all the data for
all pairs, broken or not, may be pushing us too far along the time-space
tradeoff.
diffcore-break.c | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/diffcore-break.c b/diffcore-break.c
index 15562e4..3a7b60a 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -69,7 +69,7 @@ static int should_break(struct diff_filespec *src,
return 0; /* we do not break too small filepair */
if (diffcore_count_changes(src, dst,
- NULL, NULL,
+ &src->cnt_data, &dst->cnt_data,
0,
&src_copied, &literal_added))
return 0;
@@ -204,8 +204,8 @@ void diffcore_break(int break_score)
dp->score = score;
dp->broken_pair = 1;
- diff_free_filespec_data(p->one);
- diff_free_filespec_data(p->two);
+ diff_free_filespec_blob(p->one);
+ diff_free_filespec_blob(p->two);
free(p); /* not diff_free_filepair(), we are
* reusing one and two here.
*/
--
1.6.5.2.187.g29317
^ permalink raw reply related
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Jeff King @ 2009-11-16 16:25 UTC (permalink / raw)
To: Nanako Shiraishi; +Cc: Junio C Hamano, git, Brian Collins
In-Reply-To: <20091116195050.6117@nanako3.lavabit.com>
On Mon, Nov 16, 2009 at 07:50:50PM +0900, Nanako Shiraishi wrote:
> Quoting Brian Collins <bricollins@gmail.com>
>
> > 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.
>
> Junio, may I ask what happened to this patch?
I think I owed it another review.
I just looked it over and the idea and implementation look sane to me.
There were a few minor problems with the submission:
1. The patch was line-wrapped; I had to de-munge it manually to apply.
2. The original submission had cover-letter material mixed in with the
commit message. The follow-up version had no commit message at all.
3. No signed-off-by. Brian, can you please acknowledge the DCO with a
signoff?
4. The patch introduced some stray trailing whitespace.
5. There were a few style fixups, like omitting braces for a
single-line conditional.
To save Junio time, here is a version that fixes all of those things. I
think it's probably worth applying to 'next'.
-- >8 --
From: Brian Collins <bricollins@gmail.com>
Date: Fri, 6 Nov 2009 01:22:35 -0800
Subject: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
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.
Signed-off-by: Jeff King <peff@peff.net>
---
builtin-grep.c | 8 +++++---
grep.c | 13 ++++++++++---
grep.h | 2 ++
t/t7002-grep.sh | 9 +++++++++
4 files changed, 26 insertions(+), 6 deletions(-)
diff --git a/builtin-grep.c b/builtin-grep.c
index 1df25b0..a2616fc 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..bbb0d18 100644
--- a/grep.c
+++ b/grep.c
@@ -41,6 +41,7 @@ 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;
@@ -262,9 +263,15 @@ 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 +333,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;
diff --git a/t/t7002-grep.sh b/t/t7002-grep.sh
index ae5290a..24a9445 100755
--- a/t/t7002-grep.sh
+++ b/t/t7002-grep.sh
@@ -411,4 +411,13 @@ test_expect_success 'grep from a subdirectory to search wider area (2)' '
)
'
+cat >expected <<EOF
+hello.c: return 0;
+EOF
+
+test_expect_success 'grep -Fi' '
+ git grep -Fi rEtUrN >actual &&
+ test_cmp expected actual
+'
+
test_done
--
1.6.5.2.187.g29317
^ permalink raw reply related
* Advice/help needed
From: Ian Hobson @ 2009-11-16 16:27 UTC (permalink / raw)
To: git
Hi all,
I am trying to switch to GIT (from SVN), and have become sorely
confused. I am not sure of the best way to solve the problem I have,
(nor how to actually implement a solution when one is chosen).
I am building a web application in php. There are 2 (soon to be four)
versions each slightly different for different customers. Each needs
testing when installed in "/" and "/dir" on the web site.
So far I have one system that in installed in a git repo on a Linux VM
with a share. This way I can develop in windows where I am familiar,
serve the files under linux (to match the production environment) and
run unit tests using phpUnit. The test files are all in a sub-directory
of the main directory. The application is served from a directory in the
website, so I could have different directories for different purposes,
but I have not had to use this yet.
Before release, I fetch and merge the files into a second installation
under windows, where I can serve it from the root. This forms a second
level of test. I release by copying the files with FTP (so that test
files and the GIT repo don't go on the production server).
This arrangement only works because I have been able to set up the
configuration files, database users and similar so they are all the same
on each installation. With 4 similar versions this will no longer be
possible.
What I want to be able to do is control all 4 versions in the same
manner, keep all file - common, different and test - in git, and have
checkout worry about changing versions.
My thoughts are to have 4 branches, one for each customer. 99% of all
changes will be needed by all (or at least most)
of the customers (P,W,S and E). How can I make a change to master and
then use git to apply those changes to the four branches, without losing
the differences between branches?
For example (if this is the best way) go from this
O-----O-----A-----B-----C (master)
\----P
\---W
\--S
\-E
to first this, where D is the net effect of A B and C (this is for ease
of reading logs, and commit messages),
O-----O-----D (head)
\----P
\---W
\--S
\-E
and then to this, (without editing all the files four times?)
O-----O-----D (head)
\----P-----D'
\---W----D''
\--S-----D'''
\-E-----D''''
Or would I be better having 4 repositories, one for each customer? Then
I need to pull changes and cherry pick the changes I want for each
customer?
I am the only developer, so the processes need to be simple so I am not
faced with sorting out my own errors! :)
Regards
Ian
^ permalink raw reply
* Re: Advice/help needed
From: Yann Simon @ 2009-11-16 16:40 UTC (permalink / raw)
To: Ian Hobson; +Cc: git
In-Reply-To: <4B017D77.6060505@ianhobson.co.uk>
2009/11/16 Ian Hobson <ian@ianhobson.co.uk>:
> My thoughts are to have 4 branches, one for each customer. 99% of all
> changes will be needed by all (or at least most)
> of the customers (P,W,S and E). How can I make a change to master and then
> use git to apply those changes to the four branches, without losing the
> differences between branches?
>
> For example (if this is the best way) go from this
> O-----O-----A-----B-----C (master)
> \----P
> \---W
> \--S
> \-E
>
> to first this, where D is the net effect of A B and C (this is for ease of
> reading logs, and commit messages),
> O-----O-----D (head) \----P
> \---W
> \--S
> \-E
>
> and then to this, (without editing all the files four times?)
> O-----O-----D (head)
> \----P-----D'
> \---W----D''
> \--S-----D'''
> \-E-----D''''
What I would do is:
- one branch for the common
- one branch for each customer, which contains the specific
differences compare to the common branch
You could program on the common branch.
When you are ready, you can checkout each specific branch and rebase
on the common branch.
For example:
$ git checkout common
edit, test, commit
$ git checkout client1
$ git rebase common
$ git checkout client2
$ git rebase common
Another solution is to have a branch for each customer, to commit on
one branch, and to cherry-pick this last commit on all the other
branches.
Yann
^ permalink raw reply
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Brian Collins @ 2009-11-16 16:58 UTC (permalink / raw)
To: Jeff King; +Cc: Nanako Shiraishi, Junio C Hamano, git
In-Reply-To: <20091116162533.GA30737@coredump.intra.peff.net>
> 1. The patch was line-wrapped; I had to de-munge it manually to apply.
Ugh, does gmail do this? Sorry
> 3. No signed-off-by. Brian, can you please acknowledge the DCO with a
> signoff?
Signed-off-by: Brian Collins <bricollins@gmail.com>
> 4. The patch introduced some stray trailing whitespace.
>
> 5. There were a few style fixups, like omitting braces for a
> single-line conditional.
Again sorry, thought the opposite was in the style guide.
--
Brian Collins
^ permalink raw reply
* Re: [PATCH] gitweb: Support for no project list on gitweb front page
From: Petr Baudis @ 2009-11-16 17:52 UTC (permalink / raw)
To: J.H.; +Cc: git
In-Reply-To: <4AF472E5.1000602@eaglescrag.net>
On Fri, Nov 06, 2009 at 11:03:01AM -0800, J.H. wrote:
> Petr Baudis wrote:
> >On very large sites like repo.or.cz (but maybe also git.debian.org,
> >git.kernel.org, etc.),
>
> I think between our own caching (which I'll be submitting a cleaned
> up patch for here shortly for mainline inclusion) and our users want
> to *NOT* deal with searching or pagination this actually isn't that
> useful to us, despite having a signifigant number of projects, and
> the front page (at leas for us) only weighing in at 567,710bytes
> means that we are moving less data to show the git.kernel.org page
> than facebook does to show their home screen (I.E. anything modern
> can trivially cope with that)
Sure, you still have much fewer projects than repo.or.cz. :-)
Perhaps others will still find it useful.
> >it is desirable not to have the project list
> >on the front page since generating it is significant overhead and it
> >takes significant data transfer and load time for the user, who might
> >prefer to instead use the search form and possibly content tags to
> >navigate to the target project. A link to the full list of projects is
> >still available on the front page for users who wish to browse it. The
> >whole feature is turned off by default.
> >
> >The patch introduces a new config variable $frontpage_no_project_list,
> >by default 0 keeping the current behavior; if set to 1, no project list
> >will be shown, but all projects will be still scanned if ctags are
> >enabled; if set to 2, no project will be shown and no projects will
> >be scanned while showing the front page. The compromise value of 1 is
> >useful for sites where project scan time is not an issue or which
> >use additional project list caching patches.
>
> I question the need for 0,1,2. If the site doesn't want something
> like the tag cloud they are already going to turn it off with the
> normal cloud system. I think this should be either a bitmask or an
> array to explicitly turn particular things on or off, or a binary
> value that would *ONLY* deal with showing the project listing.
I have no problem with either way, 2 seemed useful so that people can
continue to use ctags but have the front page without any project
scanning whatsoever, but if people think it makes no sense to have it,
I can drop it. I will resend the patch with this being a bitmask
instead, though.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: [PATCH] gitweb: Refactor project list routines
From: Petr Baudis @ 2009-11-16 17:56 UTC (permalink / raw)
To: J.H.; +Cc: git
In-Reply-To: <4AF47142.4010609@eaglescrag.net>
Hi!
On Fri, Nov 06, 2009 at 10:56:02AM -0800, J.H. wrote:
> 2) If the repository is cloned the ctag information is not retained,
> which means there is no real way for the original developer to
> manage or move this information between different hosting sites,
> I.E. repo.or.cz and kernel.org (though I'll admit I have it turned
> off)
This is interesting argument, I have always thought about ctags being
a rather site-specific mechanism and I think it would've meet with a lot
of user opposition to e.g. keep ctags in a specific branch; I can think
of no other good way to do it either.
> So if your going to eliminate the project listing, with the general
> intention of using the tag cloud as more of a primary search
> mechanism, including the search box, I think there's some serious
> work that needs to be put into the ctags system because in it's
> current state, for the likes of kernel.org, it's unusable, unstable
> and not something I would recommend to anyone to run in production.
> I like the idea, I just have concerns over it's current
> implementation.
This patch is orthogonal to that, I believe. I agree that the ctags
mechanism is somewhat hackish; unfortunately, I personally don't have
the time to fix it up properly. I think it is still good enough for
many users, and the frontpage mechanism would be quite useful even for
people who don't want to use content tags.
--
Petr "Pasky" Baudis
A lot of people have my books on their bookshelves.
That's the problem, they need to read them. -- Don Knuth
^ permalink raw reply
* Re: [PATCH] RFC Allow case insensitive search flag with git-grep for fixed-strings
From: Brandon Casey @ 2009-11-16 18:00 UTC (permalink / raw)
To: Brian Collins; +Cc: Jeff King, Nanako Shiraishi, Junio C Hamano, git
In-Reply-To: <d1c0fbfa0911160858k2cdd35bfvf27df2a5c97348ad@mail.gmail.com>
Brian Collins wrote:
>> 1. The patch was line-wrapped; I had to de-munge it manually to apply.
>
> Ugh, does gmail do this?
In my experience, yes.
There's a section in Documentation/SubmittingPatches about using the imap
interface to upload patches into gmail's "Drafts" folder. SubmittingPatches
then says to "Go to your Gmail account, open the Drafts folder, and find the
patch email, fill in the To: and CC: fields and send away". I tried that
once and the gmail web interface still introduced new lines. Either I'm doing
something wrong, or that document should be changed to clarify that the web
interface cannot be used even if the patch is uploaded to the Drafts folder
via imap.
-brandon
^ permalink raw reply
* git multisite setup
From: Matt Di Pasquale @ 2009-11-16 18:18 UTC (permalink / raw)
To: git
Hi,
In my sites folder i have folders for different sites of mine:
example.com example2.com, and i also have generic files like an
includes dir and a .htaccess file that all sites use. what is the best
way to track the generic files and the different sites?
i was thinking each site has its own .git repo. and then make a .git
repo for my sites folder but ignore the individual sites dirs.
actually that's what i'm doing now.
should i use submodules? i don't really understand submodules and the
examples i saw did not cover nested folders
Thanks!
matt
^ permalink raw reply
* Re: [PATCH 3/3] rebase: refuse to rebase with -s ours
From: Junio C Hamano @ 2009-11-16 19:57 UTC (permalink / raw)
To: Johannes Schindelin
Cc: Thomas Rast, git, Nicolas Sebrecht, Baz, Peter Krefting,
Björn Steinbrink
In-Reply-To: <alpine.DEB.1.00.0911161333470.4985@pacific.mpi-cbg.de>
Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
> On Sun, 15 Nov 2009, Thomas Rast wrote:
>
>> Using the "ours" strategy with rebase just discards all changes, turning
>> <branch> into <upstream> (or <newbase> if given). This is unlikely to
>> be what the user wants, so simply refuse to do it.
>
> "Unlikely" or "impossible"?
It is more like "very likely to be a mistake".
Our tradition has been to give them long enough rope, but the recent trend
is to consider ourselves experienced enough with various git workflows to
be capable of identifying not just "cannot possibly a meaningful request"
but also "almost always a mistake" cases, and tighten the rope to help
people from stumbling, I think.
But it needs more careful thought to avoid forbidding useful use cases,
and your input is hugely appreciated if you have doubts (even better, an
example of useful use case that will become impossible).
> Besides, I find it rather arbitrary that the "ours" strategy is refused,
> but none of the user-provided merge strategies. IOW disallowing "ours"
> may very well foster unreasonable expectations.
I cannot read this quite clearly. Unreasonable expectations being...?
* "ours" is disallowed but anything else including user-provided ones are
Ok, so we are allowed to circumvent this restriction by adding a
synonym for "ours" as a user-defined one, and are encouraged to do
so. ---that is a wrong message to send. Is that what you mean?
* strategy X, unlike "ours", is allowed, so users will have rights to
expect use of X as a rebase strategy would yield useful result, but
that is wrong---Dscho knows that merge strategy X (I cannot read which
one you had in mind if this is what you are talking about) does not
work well in this and that cases. Is this what you mean, and if so
what is X?
Perhaps you had something other than the above two in mind?
^ permalink raw reply
* Re: pushing remote branches
From: Junio C Hamano @ 2009-11-16 20:05 UTC (permalink / raw)
To: Lorenzo Bettini; +Cc: git
In-Reply-To: <hdrr1e$oub$1@ger.gmane.org>
Lorenzo Bettini <bettini@dsi.unifi.it> writes:
>> Anyway to answer your question, I do not see the refspec line as the issue
>> here, but the URL for the repo, which determines how you access it.
>
> so this would have been enough:
>
>>> [remote "origin"]
>>> fetch = +refs/heads/*:refs/remotes/origin/*
>>> url = git://...
>>> [branch "master"]
>>> remote = origin
>>> merge = refs/heads/master
>>> [branch "experiments"]
>>> remote = origin
>>> merge = refs/heads/experiments
Because "git://" is almost always read-only, you wouldn't be able to push
back to the origin with that configuration. If you are only following the
project that is perfectly fine.
Otherwise, either use "git@..." in remote.origin.url to use git-over-ssh
in both directions, or you can use pushurl if you have recent enough
version of git, like:
[remote "origin"]
fetch = +refs/heads/*:refs/remotes/origin/*
url = git://...
pushurl = git@...
When you primed your repository with "git clone git://...", it would be
nice if "clone" added a "corresponding" pushurl for you. But ... part of
the two lines are often different, depending on how hosting site is
organized, so unfortunately "clone" cannot do so.
^ permalink raw reply
* Re: [PATCH 2/2] diffcore-break: save cnt_data for other phases
From: Junio C Hamano @ 2009-11-16 21:20 UTC (permalink / raw)
To: Jeff King; +Cc: git
In-Reply-To: <20091116160202.GB30777@coredump.intra.peff.net>
Jeff King <peff@peff.net> writes:
> The "break" phase works by counting changes between two
> blobs with the same path. We do this by splitting the file
> into chunks (or lines for text oriented files) and then
> keeping a count of chunk hashes.
>
> The "rename" phase counts changes between blobs at two
> different paths. However, it uses the exact same set of
> chunk hashes (which are immutable for a given sha1).
>
> The rename phase can therefore use the same hash data as
> break. Unfortunately, we were throwing this data away after
> computing it in the break phase. This patch instead attaches
> it to the filespec and lets it live through the rename
> phase, working under the assumption that most of the time
> that breaks are being computed, renames will be too.
The change looks correct, but I initially got worried about your change
interacts badly with this part in estimate_similarity() around line 176:
if (!src->cnt_data && diff_populate_filespec(src, 0))
return 0;
if (!dst->cnt_data && diff_populate_filespec(dst, 0))
return 0;
I think the reason why it (not your patch but the original code) felt a
bit brittle is because the above if() statements know too much about the
internal of d-c-c (namely, it never looks at src->data when src->cnt_data
is already available, so it is safe to leave src->data NULL).
The same logic suggests that the loop to build the matrix in
diffcore_rename() could free two->data at the end of the innermost loop.
We currently loop this way (around ll. 505-530):
for each two (i.e. rename destination candidate):
for each one (i.e. rename source candidate):
compute and record how similar one and two are
free one->data
free two->data
After computing how similar "one" and something else is only once, we have
one->cnt_data so we won't need one->data (the same fact is exploited by
your patch for optimization), and that is why freeing one->data in the
innermost loop does not result in constant re-reading of the same blob
data when we iterate more than one rename destination. But the same logic
applies to "two" and we should be able to free the blob data early to
reduce the memory pressure.
I dunno if it would give us measurable performance benefit, though.
Here is the idea on top of your patch, but I think it can be applied
independently.
diffcore-rename.c | 7 +++++--
1 files changed, 5 insertions(+), 2 deletions(-)
diff --git a/diffcore-rename.c b/diffcore-rename.c
index 63ac998..875ca81 100644
--- a/diffcore-rename.c
+++ b/diffcore-rename.c
@@ -523,10 +523,13 @@ void diffcore_rename(struct diff_options *options)
this_src.dst = i;
this_src.src = j;
record_if_better(m, &this_src);
+ /*
+ * Once we run estimate_similarity,
+ * We do not need the text anymore.
+ */
diff_free_filespec_blob(one);
+ diff_free_filespec_blob(two);
}
- /* We do not need the text anymore */
- diff_free_filespec_blob(two);
dst_cnt++;
}
^ 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