* Re: [PATCH] git-tag: Fix -l option to use better shell style globs.
From: Junio C Hamano @ 2007-09-01 6:16 UTC (permalink / raw)
To: Carlos Rica; +Cc: git, Johannes Schindelin, Shawn O. Pearce
In-Reply-To: <46D8F431.70801@gmail.com>
Carlos Rica <jasampler@gmail.com> writes:
> if (pattern == NULL)
> - pattern = "";
> + pattern = "*";
>
> - /* prepend/append * to the shell pattern: */
> - newpattern = xmalloc(strlen(pattern) + 3);
> - sprintf(newpattern, "*%s*", pattern);
> -
> - filter.pattern = newpattern;
> + filter.pattern = pattern;
> filter.lines = lines;
>
> for_each_tag_ref(show_reference, (void *) &filter);
I think it is conceptually simpler on the show_reference side to
allow (filter.pattern == NULL) and say:
if (!filter->pattern || !fnmatch(filter->pattern, refname, 0)) {
... show that ref ...
}
It is not such a big deal now you do not do newpattern
allocation anymore, so I'll apply the patch as is.
^ permalink raw reply
* Re: [ANNOUNCE] git/gitweb.git repository
From: David Symonds @ 2007-09-01 5:46 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, jnareb, ltuikov
In-Reply-To: <ee77f5c20708301756k60b4d295j907da463af477982@mail.gmail.com>
On 31/08/07, David Symonds <dsymonds@gmail.com> wrote:
> On 31/08/2007, Petr Baudis <pasky@suse.cz> wrote:
> > Please feel encouraged to make random forks for your development
> > efforts, or push your random patches (preferrably just bugfixes,
> > something possibly controversial should be kept in safe containment like
> > a fork or separate branch) to the mob branch.
>
> Sorry, I'm still relatively new to git, and couldn't work out how to
> push to the mob branch, so it's inline below. It's fairly minor, just
> adding <span title="foo">..</span> around author names when they get
> abbreviated.
Okay, I worked out how to push to the mob branch: it's commit 37c8546.
I can refactor this somewhat if that's an issue.
Dave.
^ permalink raw reply
* Re: [PATCH] git-svn: fix dcommit clobbering upstream when committing multiple changes
From: Karl Hasselström @ 2007-09-01 5:43 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, Johannes Schindelin, git
In-Reply-To: <20070901011612.GA3407@untitled>
On 2007-08-31 18:16:12 -0700, Eric Wong wrote:
> Although dcommit could detect if the first commit in the series
> would conflict with the HEAD revision in SVN, it could not detect
> conflicts in further commits it made.
>
> Now we rebase each uncommitted change after each revision is
> committed to SVN to ensure that we are up-to-date. git-rebase will
> bail out on conflict errors if our next change cannot be applied and
> committed to SVN cleanly, preventing accidental clobbering of
> changes on the SVN-side.
>
> --no-rebase users will have trouble with this, and are thus warned
> if they are committing more than one commit. Fixing this for
> (hopefully uncommon) --no-rebase users would be more complex and
> will probably happen at a later date.
Shouldn't it be a simple matter of checking if the total diff over the
whole series would conflict with the SVN HEAD?
--
Karl Hasselström, kha@treskal.com
www.treskal.com/kalle
^ permalink raw reply
* Re: [PATCH] git-tag: Fix -l option to use better shell style globs.
From: Junio C Hamano @ 2007-09-01 5:39 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Carlos Rica, git, Johannes Schindelin
In-Reply-To: <20070901053158.GF18160@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Carlos Rica <jasampler@gmail.com> wrote:
>> This patch removes certain behaviour of "git tag -l foo", currently
>> listing every tag name having "foo" as a substring. The same
>> thing now could be achieved doing "git tag -l '*foo*'".
>
> Even though this is a behavior change, I think its the right thing
> to do. The current behavior of searching "*$arg*" is downright
> annoying.
Yes, I concur. It is very annoying that "git tag -l gui"
matches "gitgui-0.7.0".
Let's fix this.
^ permalink raw reply
* Re: [PATCH] git-tag: Fix -l option to use better shell style globs.
From: Shawn O. Pearce @ 2007-09-01 5:31 UTC (permalink / raw)
To: Carlos Rica; +Cc: git, Junio C Hamano, Johannes Schindelin
In-Reply-To: <46D8F431.70801@gmail.com>
Carlos Rica <jasampler@gmail.com> wrote:
> This patch removes certain behaviour of "git tag -l foo", currently
> listing every tag name having "foo" as a substring. The same
> thing now could be achieved doing "git tag -l '*foo*'".
Even though this is a behavior change, I think its the right thing
to do. The current behavior of searching "*$arg*" is downright
annoying and not what most users would expect I think, especially
when tools like for-each-ref don't do that.
Then again, I do "*$arg*" in git-gui's revision selection widget.
But there its immediately obvious what is happening and anyone I
have talked[*1*] to prefers it that way.
*1*: Disclaimer: people I talked to has thus far been limited to
day-job coworkers.
--
Shawn.
^ permalink raw reply
* [PATCH] git-tag: Fix -l option to use better shell style globs.
From: Carlos Rica @ 2007-09-01 5:10 UTC (permalink / raw)
To: git, Junio C Hamano, Johannes Schindelin, Shawn O. Pearce
This patch removes certain behaviour of "git tag -l foo", currently
listing every tag name having "foo" as a substring. The same
thing now could be achieved doing "git tag -l '*foo*'".
This feature was added recently when git-tag.sh got the -n option
for showing tag annotations, because that commit also replaced the
old "grep pattern" behaviour with a more preferable "shell pattern"
behaviour (although slightly modified as you can see).
Thus, the following builtin-tag.c implemented it in order to
ensure that tests were passing unchanged with both programs.
Since common "shell patterns" match names with a given substring
_only_ when * is inserted before and after (as in "*substring*"), and
the "plain" behaviour cannot be achieved easily with the current
implementation, this is mostly the right thing to do, in order to
make it more flexible and consistent.
Tests for "git tag" were also changed to reflect this.
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
builtin-tag.c | 11 ++---------
t/t7004-tag.sh | 20 +++++++++-----------
2 files changed, 11 insertions(+), 20 deletions(-)
diff --git a/builtin-tag.c b/builtin-tag.c
index d6d38ad..348919c 100644
--- a/builtin-tag.c
+++ b/builtin-tag.c
@@ -123,22 +123,15 @@ static int show_reference(const char *refname, const unsigned char *sha1,
static int list_tags(const char *pattern, int lines)
{
struct tag_filter filter;
- char *newpattern;
if (pattern == NULL)
- pattern = "";
+ pattern = "*";
- /* prepend/append * to the shell pattern: */
- newpattern = xmalloc(strlen(pattern) + 3);
- sprintf(newpattern, "*%s*", pattern);
-
- filter.pattern = newpattern;
+ filter.pattern = pattern;
filter.lines = lines;
for_each_tag_ref(show_reference, (void *) &filter);
- free(newpattern);
-
return 0;
}
diff --git a/t/t7004-tag.sh b/t/t7004-tag.sh
index c4fa446..606d4f2 100755
--- a/t/t7004-tag.sh
+++ b/t/t7004-tag.sh
@@ -185,18 +185,17 @@ cba
EOF
test_expect_success \
'listing tags with substring as pattern must print those matching' '
- git-tag -l a > actual &&
+ git-tag -l "*a*" > actual &&
git diff expect actual
'
cat >expect <<EOF
v0.2.1
v1.0.1
-v1.1.3
EOF
test_expect_success \
- 'listing tags with substring as pattern must print those matching' '
- git-tag -l .1 > actual &&
+ 'listing tags with a suffix as pattern must print those matching' '
+ git-tag -l "*.1" > actual &&
git diff expect actual
'
@@ -205,37 +204,36 @@ t210
t211
EOF
test_expect_success \
- 'listing tags with substring as pattern must print those matching' '
- git-tag -l t21 > actual &&
+ 'listing tags with a prefix as pattern must print those matching' '
+ git-tag -l "t21*" > actual &&
git diff expect actual
'
cat >expect <<EOF
a1
-aa1
EOF
test_expect_success \
- 'listing tags using a name as pattern must print those matching' '
+ 'listing tags using a name as pattern must print that one matching' '
git-tag -l a1 > actual &&
git diff expect actual
'
cat >expect <<EOF
v1.0
-v1.0.1
EOF
test_expect_success \
- 'listing tags using a name as pattern must print those matching' '
+ 'listing tags using a name as pattern must print that one matching' '
git-tag -l v1.0 > actual &&
git diff expect actual
'
cat >expect <<EOF
+v1.0.1
v1.1.3
EOF
test_expect_success \
'listing tags with ? in the pattern should print those matching' '
- git-tag -l "1.1?" > actual &&
+ git-tag -l "v1.?.?" > actual &&
git diff expect actual
'
--
1.5.0
^ permalink raw reply related
* Re: [ANNOUNCE] git/gitweb.git repository
From: Junio C Hamano @ 2007-09-01 4:57 UTC (permalink / raw)
To: ltuikov; +Cc: Petr Baudis, Johannes Schindelin, git, jnareb
In-Reply-To: <400762.26134.qm@web31810.mail.mud.yahoo.com>
Luben Tuikov <ltuikov@yahoo.com> writes:
> --- Junio C Hamano <gitster@pobox.com> wrote:
> ...
>> I am a bit worried about the 'master' being a "StGIT stack",
>> though. Playgrounds to be cherry-picked from (aka 'pu') would
>> make *perfect* sense to be managed that way (and the topics that
>> go only 'pu' of git.git itself are managed the same except that
>> I do not do so using StGIT), but I think we need a stable
>> history for the branch git.git will eventually pull from.
>
> That was my concern too, but seeing the immediate hostility
> I got about asking about the review process I decided not
> to mention it.
I do not think Johannes meant any hostility against you by
mentioning the obvious "person A sets up a repository, he gets
to decide rule for _his_ repository", implication of which is
that anobody else can do the same.
It is a completely different matter how the bits of the results
are decided to be good and bad and merged as part of git.git,
and that will be done with community input as always.
I asked Pasky to host series of patches for various reasons.
(1) I know I am less qualified than Pasky, you nor Jakub (the
three people I publicly said I consider more interested in
and have experience with gitweb than I am). If I were to
sift through the patches, I am sure many patches will rot
because of indecision. I wanted to make sure people more
interested in gitweb than myself play more active role in
its development and maintenance.
(2) It would make it easier to view and judge the impact of
pending patches if the code is used on to show various real
repositories to the public. repo.or.cz is an ideal place,
and Pasky has shown competence managing that service to the
community. A change to gitweb may look obviously correct
with just minor performance impact while code inspection,
but may have scaling issues in the real world --- he will
have the first hand experience to catch that. Anybody
could set something like that up, but I trust the three
gitweb gang more or less equally, so why not utilize the
infrastructure we already have, especially Pasky agreed to
help?
(3) I have disagreed on a handful technical issues with Pasky,
you and Jakub, but I do not expect all of us to always
agree something is good or bad unanimously, nor I expect it
would satisfy everybody in the community even if we agree
on something unanimously, if we acted as a Cabal. One
thing that is important is that the process is transparent.
I trust Pasky to be open-minded as any of us would be. I
do not expect him to start acting as a dictator on gitweb
issues and force bad technical decisions without listening
to others. I trust him at least that much. I would
probably trust you or Jakub the same way, but I do not have
to pick one single person that I trust _most_. As long as
the person who maintains the gitweb patch queue is trusted
and respected _enough_ by the community, I think that is
good enough. And this is all volunteer work. Good
maintainers are hard to find.
> I'd be interesting to see how gitweb support pans out
> given this initial hostility to inquiry of accountability.
>
> Over the years I've seen that the best support and accountability
> has been had when the maintainer is not the main contributor/developer,
> especially for shared development. Otherwise personal preferences over
> feature X and Y come into play and then things get ugly.
I understand your concern, and I think that is where you can
help the most. If you see questionable patches queued, spot
them and raise issues. We've been a friendly community, and
luckily we haven't had too many burnt bridges over personality
differences.
We have a _LOT_ of work ahead of us in gitweb area. You may
remember that there was a call-for-help from k.org gitweb master
(J. H. "warthog9", with comments from HPA) some time ago. The
installation there is heavily modified to support a large and
heavily-hit site better than the stock gitweb, but the codebase
has diverged quite a bit. We need to fold that effort back so
that (1) they do not have to keep maintaining their fork, and
(2) everybody else will benefit from their scalability work.
^ permalink raw reply
* git-gui i18n status?
From: Shawn O. Pearce @ 2007-09-01 4:29 UTC (permalink / raw)
To: Johannes Schindelin, Christian Stimming, git
Now that git-gui 0.8.2 is out and git 1.5.3 is just around the corner
I am starting to think about bringing the git-gui i18n work into the
main git-gui tree, so we can start working from a common codebase.
Looking at the repository on repo.or.cz it looks like it needs to
be merged/rebased onto 0.8.2. There is a trivial merge conflict,
but there are some more subtle ones caused by the movement of
the library directory initialization down lower in git-gui.sh.
For example translations won't be initialized if we have an issue
with the output of git-version and want to prompt the user.
What is the current plan? Should I be looking at the master branch
of git://repo.or.cz/git-gui/git-gui-i18n.git for pulling? Or are
folks expecting that this series will be cleaned up before I pull it?
--
Shawn.
^ permalink raw reply
* [PATCH] Teach bash about completing arguments for git-tag
From: Shawn O. Pearce @ 2007-09-01 3:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
Please pull from:
repo.or.cz:/srv/git/git/fastimport.git master
-->8--
Lately I have been doing a lot of calls to `git tag -d` and also to
`git tag -v`. In both such cases being able to complete the names
of existing tags saves the fingers some typing effort. We now look
for the -d or -v option to git-tag in the bash completion support
and offer up existing tag names as possible choices for these.
When creating a new tag we now also offer bash completion support
for the second argument to git-tag (the object to be tagged) as this
can often be a specific existing branch name and is not necessarily
the current HEAD.
If the -f option is being used to recreate an existing tag we now
also offer completion support on the existing tag names for the
first argument of git-tag, helping to the user to reselect the
prior tag name that they are trying to replace.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
contrib/completion/git-completion.bash | 58 ++++++++++++++++++++++++++++++++
1 files changed, 58 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 5ed1821..cad842a 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -114,6 +114,27 @@ __git_heads ()
done
}
+__git_tags ()
+{
+ local cmd i is_hash=y dir="$(__gitdir "$1")"
+ if [ -d "$dir" ]; then
+ for i in $(git --git-dir="$dir" \
+ for-each-ref --format='%(refname)' \
+ refs/tags ); do
+ echo "${i#refs/tags/}"
+ done
+ return
+ fi
+ for i in $(git-ls-remote "$1" 2>/dev/null); do
+ case "$is_hash,$i" in
+ y,*) is_hash=n ;;
+ n,*^{}) is_hash=y ;;
+ n,refs/tags/*) is_hash=y; echo "${i#refs/tags/}" ;;
+ n,*) is_hash=y; echo "$i" ;;
+ esac
+ done
+}
+
__git_refs ()
{
local cmd i is_hash=y dir="$(__gitdir "$1")"
@@ -1050,6 +1071,40 @@ _git_submodule ()
fi
}
+_git_tag ()
+{
+ local i c=1 f=0
+ while [ $c -lt $COMP_CWORD ]; do
+ i="${COMP_WORDS[c]}"
+ case "$i" in
+ -d|-v)
+ __gitcomp "$(__git_tags)"
+ return
+ ;;
+ -f)
+ f=1
+ ;;
+ esac
+ c=$((++c))
+ done
+
+ case "${COMP_WORDS[COMP_CWORD-1]}" in
+ -m|-F)
+ COMPREPLY=()
+ ;;
+ -*|tag|git-tag)
+ if [ $f = 1 ]; then
+ __gitcomp "$(__git_tags)"
+ else
+ COMPREPLY=()
+ fi
+ ;;
+ *)
+ __gitcomp "$(__git_refs)"
+ ;;
+ esac
+}
+
_git ()
{
local i c=1 command __git_dir
@@ -1117,6 +1172,7 @@ _git ()
show-branch) _git_log ;;
stash) _git_stash ;;
submodule) _git_submodule ;;
+ tag) _git_tag ;;
whatchanged) _git_log ;;
*) COMPREPLY=() ;;
esac
@@ -1167,6 +1223,7 @@ complete -o default -o nospace -F _git_show git-show
complete -o default -o nospace -F _git_stash git-stash
complete -o default -o nospace -F _git_submodule git-submodule
complete -o default -o nospace -F _git_log git-show-branch
+complete -o default -o nospace -F _git_tag git-tag
complete -o default -o nospace -F _git_log git-whatchanged
# The following are necessary only for Cygwin, and only are needed
@@ -1192,5 +1249,6 @@ complete -o default -o nospace -F _git_config git-config
complete -o default -o nospace -F _git_shortlog git-shortlog.exe
complete -o default -o nospace -F _git_show git-show.exe
complete -o default -o nospace -F _git_log git-show-branch.exe
+complete -o default -o nospace -F _git_tag git-tag.exe
complete -o default -o nospace -F _git_log git-whatchanged.exe
fi
--
1.5.3.rc7.16.ge340d
^ permalink raw reply related
* [PATCH] course/svn: Fix a link pointing to a .txt instead of its .html page
From: Carlos Rica @ 2007-09-01 3:41 UTC (permalink / raw)
To: git, Petr Baudis
Signed-off-by: Carlos Rica <jasampler@gmail.com>
---
course/svn.html | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/course/svn.html b/course/svn.html
index ccadfac..fbb9d91 100644
--- a/course/svn.html
+++ b/course/svn.html
@@ -514,7 +514,7 @@ repositories with no working copy at all - so called <em>bare</em>
repositories which are commonly used for public access or developers'
meeting point - just for exchange of history where a checked out copy
would be a waste of space anyway. You can create such a repository.
-See <a href="http://www.kernel.org/pub/software/scm/git/docs/user-manual.txt#setting-up-a-public-repository">Setting up a public repository</a> for details.</p>
+See <a href="http://www.kernel.org/pub/software/scm/git/docs/user-manual.html#setting-up-a-public-repository">Setting up a public repository</a> for details.</p>
<p>Git can work with the same workflow as Subversion, with a group of developers
using a single repository for exchange of their work. The only change
--
1.5.0
^ permalink raw reply related
* Re: repo.or.cz wishes?
From: Shawn O. Pearce @ 2007-09-01 2:58 UTC (permalink / raw)
To: Linus Torvalds; +Cc: Theodore Tso, Johannes Schindelin, Petr Baudis, git
In-Reply-To: <alpine.LFD.0.999.0708291009570.25853@woody.linux-foundation.org>
Linus Torvalds <torvalds@linux-foundation.org> wrote:
> On Wed, 29 Aug 2007, Shawn O. Pearce wrote:
> >
> > Not if I already have a pointer from B to A's refs. repo.or.cz
> > also has this same pointer:
> >
> > git clone --shared A B
> > ln -s A/refs B/refs/forkee
>
> Now, this doesn't work well with packed refs, I'm afraid.
No, it doesn't work well. So I actually also avoid packing A's refs.
Which is yet another reason why my A's don't allow pushing, that
way nobody goes nuts and creates a ton of refs in there. With only
refs/heads/master and it being unpacked its not a big deal.
> So I suspect that if we really want to support something like this, we'd
> need to do more than just avoid the recursion when you cross-link.
Yes. I've been thinking about trying to better share the ODB and
the ref database between repositories, but it has been low priority
for me.
I rely on this ref symlinking/alternate ODB trick a lot at day-job
to help me cope with an ugly situation I created across a number of
repositories. Most of our codebase came from one Git repository,
but has been refactored and split into about 10 different Git
repositories. I did that refactoring by just cloning and deleting
the uninteresting content, so each repository actually has a huge
block of its history in common with the other 9.
One such A is "common-crap.git" that is the shared common history.
Since its strictly history nobody changes that repository, and
everyone borrows objects from it. This reduces my common working
set by about 900MiB, as the history lives in only one packfile and
not in 10.
There are obviously other ways to deal with this:
- start the 10 repositories over again and use info/grafts to
reinsert the old history when/if required;
- just hardlink the same .keep'd packfile into the 10 repositories,
since it is held by .keep it won't be touched during repack.
So one reason it has been low priority for me to improve upon is
because there's more than one way to solve the problem, and the
particular solution I have settled upon may not be the best solution
for anyone.
Though I think we can all agree that repo.or.cz's use of forks
is increasingly more popular, and one of the more powerful social
features of git. Better supporting it out of the box by making it
easier to setup and manage can only be a good thing for our users.
--
Shawn.
^ permalink raw reply
* Re: [ANNOUNCE] git/gitweb.git repository
From: Luben Tuikov @ 2007-09-01 2:15 UTC (permalink / raw)
To: Junio C Hamano, Petr Baudis
Cc: Johannes Schindelin, Luben Tuikov, git, jnareb
In-Reply-To: <7v4pifw45n.fsf@gitster.siamese.dyndns.org>
--- Junio C Hamano <gitster@pobox.com> wrote:
> Petr Baudis <pasky@suse.cz> writes:
>
> > On Sat, Sep 01, 2007 at 03:25:16AM CEST, Johannes Schindelin wrote:
> >> On Fri, 31 Aug 2007, Luben Tuikov wrote:
> >>
> >> > So what's the review process now?
> >>
> >> Umm. Pasky set it up, so it's Pasky who decides what goes in and what
> >> not. What exactly is your problem?
> >
> > Junio will pull from it, so he has full right to ask. :-)
>
> Well, I won't blindly pull from it, but honestly when it comes
> to gitweb I trust Pasky's judgement as much as I trust myself,
> if not even more. And I think the review process Pasky
> described is good --- people will see both the patches on the
> list and code in action at repo.or.cz/.
>
> I am a bit worried about the 'master' being a "StGIT stack",
> though. Playgrounds to be cherry-picked from (aka 'pu') would
> make *perfect* sense to be managed that way (and the topics that
> go only 'pu' of git.git itself are managed the same except that
> I do not do so using StGIT), but I think we need a stable
> history for the branch git.git will eventually pull from.
That was my concern too, but seeing the immediate hostility
I got about asking about the review process I decided not
to mention it.
I'd be interesting to see how gitweb support pans out
given this initial hostility to inquiry of accountability.
Over the years I've seen that the best support and accountability
has been had when the maintainer is not the main contributor/developer,
especially for shared development. Otherwise personal preferences over
feature X and Y come into play and then things get ugly. This is
why you were such a good maintainer of gitweb.
Luben
^ permalink raw reply
* Re: [ANNOUNCE] git/gitweb.git repository
From: Luben Tuikov @ 2007-09-01 2:06 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Petr Baudis, git, jnareb
In-Reply-To: <Pine.LNX.4.64.0709010224410.28586@racer.site>
--- Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> Hi,
>
> On Fri, 31 Aug 2007, Luben Tuikov wrote:
>
> > --- Petr Baudis <pasky@suse.cz> wrote:
> > > Hi,
> > >
> > > due to popular (Junio's) demand, I have set up a gitweb-oriented fork
> > > of git at repo.or.cz:
> > >
> > > http://repo.or.cz/w/git/gitweb.git
> > >
> > > It is meant as a hub for various gitweb-related patches and
> > > development efforts. So far it is pre-seeded by the patches repo.or.cz's
> > > gitweb uses.
> >
> > Is this right?
> >
> > So what's the review process now?
>
> Umm. Pasky set it up, so it's Pasky who decides what goes in and what
> not. What exactly is your problem?
That's perfectly fine as long as Junio doesn't pull from it ever.
Now since Junio is going to pull from it, there needs to be some
sort of accountability.
Luben
^ permalink raw reply
* Re: [ANNOUNCE] git/gitweb.git repository
From: Junio C Hamano @ 2007-09-01 1:44 UTC (permalink / raw)
To: Petr Baudis; +Cc: Johannes Schindelin, Luben Tuikov, git, jnareb
In-Reply-To: <20070901013159.GP1219@pasky.or.cz>
Petr Baudis <pasky@suse.cz> writes:
> On Sat, Sep 01, 2007 at 03:25:16AM CEST, Johannes Schindelin wrote:
>> On Fri, 31 Aug 2007, Luben Tuikov wrote:
>>
>> > So what's the review process now?
>>
>> Umm. Pasky set it up, so it's Pasky who decides what goes in and what
>> not. What exactly is your problem?
>
> Junio will pull from it, so he has full right to ask. :-)
Well, I won't blindly pull from it, but honestly when it comes
to gitweb I trust Pasky's judgement as much as I trust myself,
if not even more. And I think the review process Pasky
described is good --- people will see both the patches on the
list and code in action at repo.or.cz/.
I am a bit worried about the 'master' being a "StGIT stack",
though. Playgrounds to be cherry-picked from (aka 'pu') would
make *perfect* sense to be managed that way (and the topics that
go only 'pu' of git.git itself are managed the same except that
I do not do so using StGIT), but I think we need a stable
history for the branch git.git will eventually pull from.
^ permalink raw reply
* Re: [PATCH] git-svn: fix dcommit clobbering upstream when committing multiple changes
From: Johannes Schindelin @ 2007-09-01 1:32 UTC (permalink / raw)
To: Eric Wong; +Cc: Junio C Hamano, git
In-Reply-To: <20070901011612.GA3407@untitled>
Hi,
On Fri, 31 Aug 2007, Eric Wong wrote:
> Although dcommit could detect if the first commit in the series
> would conflict with the HEAD revision in SVN, it could not
> detect conflicts in further commits it made.
>
> Now we rebase each uncommitted change after each revision is
> committed to SVN to ensure that we are up-to-date. git-rebase
> will bail out on conflict errors if our next change cannot be
> applied and committed to SVN cleanly, preventing accidental
> clobbering of changes on the SVN-side.
Thanks for the quick fix; will play with it on Sunday...
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] git/gitweb.git repository
From: Petr Baudis @ 2007-09-01 1:31 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Luben Tuikov, git, jnareb
In-Reply-To: <Pine.LNX.4.64.0709010224410.28586@racer.site>
Hi,
On Sat, Sep 01, 2007 at 03:25:16AM CEST, Johannes Schindelin wrote:
> On Fri, 31 Aug 2007, Luben Tuikov wrote:
>
> > --- Petr Baudis <pasky@suse.cz> wrote:
> > > Hi,
> > >
> > > due to popular (Junio's) demand, I have set up a gitweb-oriented fork
> > > of git at repo.or.cz:
> > >
> > > http://repo.or.cz/w/git/gitweb.git
> > >
> > > It is meant as a hub for various gitweb-related patches and
> > > development efforts. So far it is pre-seeded by the patches repo.or.cz's
> > > gitweb uses.
> >
> > Is this right?
> >
> > So what's the review process now?
>
> Umm. Pasky set it up, so it's Pasky who decides what goes in and what
> not. What exactly is your problem?
Junio will pull from it, so he has full right to ask. :-) As I wrote
in the web README, to enter #next your patch should see some git@ review;
that holds for repo.or.cz patches as well as for any other patches. I
suppose we will sort out the exact distinction between #next and #master
on the fly; the general idea is that patches that go on #master have
more or less approached perfectness. ;-)
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: [PATCH] diff: resurrect the traditional empty "diff --git" behaviour
From: Junio C Hamano @ 2007-09-01 1:27 UTC (permalink / raw)
To: Steven Grimm; +Cc: git, Michael S. Tsirkin, Jeff King
In-Reply-To: <46D89844.8050605@midwinter.com>
Steven Grimm <koreth@midwinter.com> writes:
> Junio C Hamano wrote:
>> This commit reinstates the traditional behaviour as the default,
>> but with a twist.
>>
>> If you set diff.autorefreshindex configuration variable, it
>> squelches the empty "diff --git" output, and at the end of the
>> command, it automatically runs "update-index --refresh" without
>> even bothering the user. In other words, with the configuration
>> variable set, people who do not care about the cache-dirtyness
>> do not even have to see the warning.
>
> As the person who submitted the patch you're reversing with this, I
> agree 100% this is the better approach. Having the system self-heal is
> far preferable to requiring user action.
>
> I would vote for reversing the sense of that config variable,
(grudgingly...) Ok.
Old timers like myself have been warned on the list that
diff output will get quieter, so why not.
This is on top of the previous one in this thread.
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 903610f..cf7617a 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -396,6 +396,16 @@ color.status.<slot>::
commit.template::
Specify a file to use as the template for new commit messages.
+diff.autorefreshindex::
+ When using `git diff` to compare with work tree
+ files, do not consider stat-only change as changed.
+ Instead, silently run `git update-index --refresh` to
+ update the cached stat information for paths whose
+ contents in the work tree match the contents in the
+ index. This option defaults to true. Note that this
+ affects only `git diff` Porcelain, and not lower level
+ `diff` commands, such as `git diff-files`.
+
diff.renameLimit::
The number of files to consider when performing the copy/rename
detection; equivalent to the git diff option '-l'.
diff --git a/diff.c b/diff.c
index 75d95da..0d30d05 100644
--- a/diff.c
+++ b/diff.c
@@ -19,7 +19,7 @@
static int diff_detect_rename_default;
static int diff_rename_limit_default = -1;
static int diff_use_color_default;
-int diff_auto_refresh_index;
+int diff_auto_refresh_index = 1;
static char diff_colors[][COLOR_MAXLEN] = {
"\033[m", /* reset */
^ permalink raw reply related
* Re: [ANNOUNCE] git/gitweb.git repository
From: Johannes Schindelin @ 2007-09-01 1:25 UTC (permalink / raw)
To: Luben Tuikov; +Cc: Petr Baudis, git, jnareb
In-Reply-To: <767502.77573.qm@web31812.mail.mud.yahoo.com>
Hi,
On Fri, 31 Aug 2007, Luben Tuikov wrote:
> --- Petr Baudis <pasky@suse.cz> wrote:
> > Hi,
> >
> > due to popular (Junio's) demand, I have set up a gitweb-oriented fork
> > of git at repo.or.cz:
> >
> > http://repo.or.cz/w/git/gitweb.git
> >
> > It is meant as a hub for various gitweb-related patches and
> > development efforts. So far it is pre-seeded by the patches repo.or.cz's
> > gitweb uses.
>
> Is this right?
>
> So what's the review process now?
Umm. Pasky set it up, so it's Pasky who decides what goes in and what
not. What exactly is your problem?
Ciao,
Dscho
^ permalink raw reply
* Re: [ANNOUNCE] git/gitweb.git repository
From: Luben Tuikov @ 2007-09-01 1:23 UTC (permalink / raw)
To: Petr Baudis; +Cc: git, jnareb
In-Reply-To: <20070901011608.GC10749@pasky.or.cz>
--- Petr Baudis <pasky@suse.cz> wrote:
> On Sat, Sep 01, 2007 at 03:06:02AM CEST, Luben Tuikov wrote:
> > --- Petr Baudis <pasky@suse.cz> wrote:
> > > Hi,
> > >
> > > due to popular (Junio's) demand, I have set up a gitweb-oriented fork
> > > of git at repo.or.cz:
> > >
> > > http://repo.or.cz/w/git/gitweb.git
> > >
> > > It is meant as a hub for various gitweb-related patches and
> > > development efforts. So far it is pre-seeded by the patches repo.or.cz's
> > > gitweb uses.
> >
> > Is this right?
> >
> > So what's the review process now? "Because it is part of repo.or.cz's
> > gitweb" seems to be a weak argument.
>
> Have you even looked at the page I linked? I tried to explain how are
> the patches organized to branches there. Please ask if something is
> still unclear.
Yes, I did. I saw that gitweb::master is identical to Junio's, but
for safety measure I decided to ask. Thanks for your reply.
Luben
^ permalink raw reply
* [PATCH] git-svn: fix dcommit clobbering upstream when committing multiple changes
From: Eric Wong @ 2007-09-01 1:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Schindelin, git
In-Reply-To: <20070901002501.GA11591@mimvista.com>
Although dcommit could detect if the first commit in the series
would conflict with the HEAD revision in SVN, it could not
detect conflicts in further commits it made.
Now we rebase each uncommitted change after each revision is
committed to SVN to ensure that we are up-to-date. git-rebase
will bail out on conflict errors if our next change cannot be
applied and committed to SVN cleanly, preventing accidental
clobbering of changes on the SVN-side.
--no-rebase users will have trouble with this, and are thus
warned if they are committing more than one commit. Fixing this
for (hopefully uncommon) --no-rebase users would be more complex
and will probably happen at a later date.
Thanks to David Watson for finding this and the original test.
---
David Watson <dwatson@mimvista.com> wrote:
> If you make multiple commits, and a commit other than the first applies
> to the same file as a new change in the SVN repository, git-svn will blow
> away the other commit's changes.
Thanks David. I separated out the test case to not modify existing
ones.
git-svn.perl | 60 +++++++++++++++++---------------
t/t9106-git-svn-commit-diff-clobber.sh | 30 ++++++++++++++++
2 files changed, 62 insertions(+), 28 deletions(-)
diff --git a/git-svn.perl b/git-svn.perl
index 98218da..d3c8cd0 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -384,6 +384,12 @@ sub cmd_dcommit {
}
my $last_rev;
my ($linear_refs, $parents) = linearize_history($gs, \@refs);
+ if ($_no_rebase && scalar(@$linear_refs) > 1) {
+ warn "Attempting to commit more than one change while ",
+ "--no-rebase is enabled.\n",
+ "If these changes depend on each other, re-running ",
+ "without --no-rebase will be required."
+ }
foreach my $d (@$linear_refs) {
unless (defined $last_rev) {
(undef, $last_rev, undef) = cmt_metadata("$d~1");
@@ -395,6 +401,7 @@ sub cmd_dcommit {
if ($_dry_run) {
print "diff-tree $d~1 $d\n";
} else {
+ my $cmt_rev;
my %ed_opts = ( r => $last_rev,
log => get_commit_entry($d)->{log},
ra => Git::SVN::Ra->new($gs->full_url),
@@ -402,42 +409,39 @@ sub cmd_dcommit {
tree_b => $d,
editor_cb => sub {
print "Committed r$_[0]\n";
- $last_rev = $_[0]; },
+ $cmt_rev = $_[0];
+ },
svn_path => '');
if (!SVN::Git::Editor->new(\%ed_opts)->apply_diff) {
print "No changes\n$d~1 == $d\n";
} elsif ($parents->{$d} && @{$parents->{$d}}) {
- $gs->{inject_parents_dcommit}->{$last_rev} =
+ $gs->{inject_parents_dcommit}->{$cmt_rev} =
$parents->{$d};
}
+ $_fetch_all ? $gs->fetch_all : $gs->fetch;
+ next if $_no_rebase;
+
+ # we always want to rebase against the current HEAD,
+ # not any head that was passed to us
+ my @diff = command('diff-tree', 'HEAD',
+ $gs->refname, '--');
+ my @finish;
+ if (@diff) {
+ @finish = rebase_cmd();
+ print STDERR "W: HEAD and ", $gs->refname,
+ " differ, using @finish:\n",
+ "@diff";
+ } else {
+ print "No changes between current HEAD and ",
+ $gs->refname,
+ "\nResetting to the latest ",
+ $gs->refname, "\n";
+ @finish = qw/reset --mixed/;
+ }
+ command_noisy(@finish, $gs->refname);
+ $last_rev = $cmt_rev;
}
}
- return if $_dry_run;
- unless ($gs) {
- warn "Could not determine fetch information for $url\n",
- "Will not attempt to fetch and rebase commits.\n",
- "This probably means you have useSvmProps and should\n",
- "now resync your SVN::Mirror repository.\n";
- return;
- }
- $_fetch_all ? $gs->fetch_all : $gs->fetch;
- unless ($_no_rebase) {
- # we always want to rebase against the current HEAD, not any
- # head that was passed to us
- my @diff = command('diff-tree', 'HEAD', $gs->refname, '--');
- my @finish;
- if (@diff) {
- @finish = rebase_cmd();
- print STDERR "W: HEAD and ", $gs->refname, " differ, ",
- "using @finish:\n", "@diff";
- } else {
- print "No changes between current HEAD and ",
- $gs->refname, "\nResetting to the latest ",
- $gs->refname, "\n";
- @finish = qw/reset --mixed/;
- }
- command_noisy(@finish, $gs->refname);
- }
}
sub cmd_find_rev {
diff --git a/t/t9106-git-svn-commit-diff-clobber.sh b/t/t9106-git-svn-commit-diff-clobber.sh
index 6f132f2..79b7968 100755
--- a/t/t9106-git-svn-commit-diff-clobber.sh
+++ b/t/t9106-git-svn-commit-diff-clobber.sh
@@ -66,4 +66,34 @@ test_expect_success 'dcommit does the svn equivalent of an index merge' "
git-svn dcommit
"
+test_expect_success 'commit another change from svn side' "
+ svn co $svnrepo t.svn &&
+ cd t.svn &&
+ echo third line from svn >> file &&
+ poke file &&
+ svn commit -m 'third line from svn' &&
+ cd .. &&
+ rm -rf t.svn
+ "
+
+test_expect_failure 'multiple dcommit from git-svn will not clobber svn' "
+ git reset --hard refs/remotes/git-svn &&
+ echo new file >> new-file &&
+ git update-index --add new-file &&
+ git commit -a -m 'new file' &&
+ echo clobber > file &&
+ git commit -a -m 'clobber' &&
+ git svn dcommit
+ " || true
+
+
+test_expect_success 'check that rebase really failed' 'test -d .dotest'
+
+test_expect_success 'resolve, continue the rebase and dcommit' "
+ echo clobber and I really mean it > file &&
+ git update-index file &&
+ git rebase --continue &&
+ git svn dcommit
+ "
+
test_done
--
Eric Wong
^ permalink raw reply related
* Re: [ANNOUNCE] git/gitweb.git repository
From: Petr Baudis @ 2007-09-01 1:16 UTC (permalink / raw)
To: Luben Tuikov; +Cc: git, jnareb
In-Reply-To: <767502.77573.qm@web31812.mail.mud.yahoo.com>
On Sat, Sep 01, 2007 at 03:06:02AM CEST, Luben Tuikov wrote:
> --- Petr Baudis <pasky@suse.cz> wrote:
> > Hi,
> >
> > due to popular (Junio's) demand, I have set up a gitweb-oriented fork
> > of git at repo.or.cz:
> >
> > http://repo.or.cz/w/git/gitweb.git
> >
> > It is meant as a hub for various gitweb-related patches and
> > development efforts. So far it is pre-seeded by the patches repo.or.cz's
> > gitweb uses.
>
> Is this right?
>
> So what's the review process now? "Because it is part of repo.or.cz's
> gitweb" seems to be a weak argument.
Have you even looked at the page I linked? I tried to explain how are
the patches organized to branches there. Please ask if something is
still unclear.
--
Petr "Pasky" Baudis
Early to rise and early to bed makes a male healthy and wealthy and dead.
-- James Thurber
^ permalink raw reply
* Re: [ANNOUNCE] git/gitweb.git repository
From: Luben Tuikov @ 2007-09-01 1:06 UTC (permalink / raw)
To: Petr Baudis, git; +Cc: jnareb, ltuikov
In-Reply-To: <20070831000149.GK1219@pasky.or.cz>
--- Petr Baudis <pasky@suse.cz> wrote:
> Hi,
>
> due to popular (Junio's) demand, I have set up a gitweb-oriented fork
> of git at repo.or.cz:
>
> http://repo.or.cz/w/git/gitweb.git
>
> It is meant as a hub for various gitweb-related patches and
> development efforts. So far it is pre-seeded by the patches repo.or.cz's
> gitweb uses.
Is this right?
So what's the review process now? "Because it is part of repo.or.cz's
gitweb" seems to be a weak argument.
Luben
> It is divided to three main branches (StGIT patchstacks in
> reality), where master is what Junio is gonna pull to git's master.
>
> Please feel encouraged to make random forks for your development
> efforts, or push your random patches (preferrably just bugfixes,
> something possibly controversial should be kept in safe containment like
> a fork or separate branch) to the mob branch.
>
> Have fun,
>
> --
> Petr "Pasky" Baudis
> Early to rise and early to bed makes a male healthy and wealthy and dead.
> -- James Thurber
>
^ permalink raw reply
* [PATCH] Test for git-svn dcommit clobbering changes
From: David Watson @ 2007-09-01 0:25 UTC (permalink / raw)
To: Johannes Schindelin, Eric Wong, git
In-Reply-To: <20070831234854.GA6451@mimvista.com>
If you make multiple commits, and a commit other than the first applies
to the same file as a new change in the SVN repository, git-svn will blow
away the other commit's changes.
---
On Fri, Aug 31, 2007 at 07:48:55PM -0400, David Watson wrote:
> I just reproduced this one in a live repository. Here's what you do:
>
> $ git checkout -b breakme trunk
> $ vi file1.txt
> $ git-commit -a -m 'first change'
> $ vi file2.txt
> $ git-commit -a -m 'second change'
> ..... Full moon, become a werewolf ......
> C:\svnrepo> edit file2.txt
> C:\svnrepo> svn commit -m 'this will be gone'
> ..... Become yourself again ....
> $ git svn fetch --all # (not sure if this is necessary)
> $ git svn dcommit
> $ git log -p
t/t9106-git-svn-commit-diff-clobber.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/t/t9106-git-svn-commit-diff-clobber.sh b/t/t9106-git-svn-commit-diff-clobber.sh
index 6f132f2..2706153 100755
--- a/t/t9106-git-svn-commit-diff-clobber.sh
+++ b/t/t9106-git-svn-commit-diff-clobber.sh
@@ -50,6 +50,9 @@ test_expect_failure 'dcommit fails to commit because of conflict' "
svn commit -m 'fourth line from svn' &&
cd .. &&
rm -rf t.svn &&
+ echo another file from git >> file2 &&
+ git add file2 &&
+ git commit -m 'another file here' &&
echo 'fourth line from git' >> file &&
git commit -a -m 'fourth line from git' &&
git-svn dcommit
--
1.5.3.rc4
Dave Watson
^ permalink raw reply related
* Re: [PATCH] gitweb: Clearly distinguish regexp / exact match searches
From: Jakub Narebski @ 2007-09-01 0:13 UTC (permalink / raw)
To: git
In-Reply-To: <20070826013831.17924.75365.stgit@rover>
[Cc: Petr Baudis <pasky@suse.cz>, git@vger.kernel.org]
Nice idea, although most probably post 1.5.3.
Ack, FWIW.
Petr Baudis wrote:
> This patch does a couple of things:
>
> * Makes commit/author/committer search case insensitive
>
> To be consistent with the grep search; I see no convincing
> reason for the search to be case sensitive, and you might
> get in trouble especially with contributors e.g. from Japan
> or France where they sometimes like to uppercase their last
> name.
>
> * Makes grep search by default grep for fixed strings
>
> Since we will have a checkbox.
>
> * Introduces 're' checkbox that enables POSIX extended regexp searches
>
> This works for all the search types. The idea comes from Jakub.
>
> It does not make much sense (and is not easy at all) to untangle most of
> these changes from each other, thus they all go in a single patch.
The last two changes certainly _have_ to go together, as they have
no much sense individually. I'm not so sure about making commit search
case insensitive; I agree that it would be not easy to untangle those
changes from the regexp changes.
Nevertheless I'd separate one patch: changing usage of parse_commits
(see comments below).
> Cc: Jakub Narebski <jnareb@gmail.com>
I didn't get a copy by email...
> Signed-off-by: Petr Baudis <pasky@suse.cz>
> ---
>
> Sorry, previous version kept git_feed() the user of parse_commits() with
> unchanged usage.
> ---
>
> gitweb/gitweb.perl | 52 ++++++++++++++++++++++++++++++++++------------------
> 1 files changed, 34 insertions(+), 18 deletions(-)
>
> diff --git a/gitweb/gitweb.perl b/gitweb/gitweb.perl
> index 1ac4523..bdb0b1f 100755
> --- a/gitweb/gitweb.perl
> +++ b/gitweb/gitweb.perl
> @@ -473,13 +473,15 @@ if (defined $searchtype) {
> }
> }
>
> +our $search_use_regexp = $cgi->param('sr');
> +
> our $searchtext = $cgi->param('s');
> our $search_regexp;
> if (defined $searchtext) {
> if (length($searchtext) < 2) {
> die_error(undef, "At least two characters are required for search parameter");
> }
> - $search_regexp = quotemeta $searchtext;
> + $search_regexp = $search_use_regexp ? $searchtext : quotemeta $searchtext;
> }
Nice idea, good solution... although: yet another CGI parameter?
> @@ -609,6 +611,7 @@ sub href(%) {
> searchtype => "st",
> snapshot_format => "sf",
> extra_options => "opt",
> + search_use_regexp => "sr",
> );
> my %mapping = @mapping;
>
I would put 'search_use_regexp' after searchtype, not at the end of
the @mapping list.
> @@ -1937,7 +1940,7 @@ sub parse_commit {
> }
>
> sub parse_commits {
> - my ($commit_id, $maxcount, $skip, $arg, $filename) = @_;
> + my ($commit_id, $maxcount, $skip, $filename, @args) = @_;
> my @cos;
>
> $maxcount ||= 1;
> @@ -1947,7 +1950,7 @@ sub parse_commits {
>
> open my $fd, "-|", git_cmd(), "rev-list",
> "--header",
> - ($arg ? ($arg) : ()),
> + @args,
> ("--max-count=" . $maxcount),
> ("--skip=" . $skip),
> @extra_options,
This is a good idea. It not only allows passing more than single
parameter to rev-list, but also make it easier to use "no extra
options" parse_commits invocation. Although it makes order of
types of options different than in git-rev-list invocation.
But I'd rather have this, and changes in calling parse_commits,
as a separate commit.
We could always use anonymous array reference if we want to pass
more than one option:
parse_commits(commit, maxcount, skip, [arg1, arg2], filename)
> @@ -2422,6 +2425,9 @@ EOF
> $cgi->sup($cgi->a({-href => href(action=>"search_help")}, "?")) .
> " search:\n",
> $cgi->textfield(-name => "s", -value => $searchtext) . "\n" .
> + "<span title=\"Extended regular expression\">" .
> + $cgi->checkbox(-name => 'sr', -value => 1, -checked => $search_use_regexp, -label => 're') .
> + "</span>" .
> "</div>" .
> $cgi->end_form() . "\n";
> }
Perhaps this checkbox should be _below_ search form text field,
rather than after it.
> @@ -5095,7 +5101,7 @@ sub git_history {
> $ftype = git_get_type($hash);
> }
>
> - my @commitlist = parse_commits($hash_base, 101, (100 * $page), "--full-history", $file_name);
> + my @commitlist = parse_commits($hash_base, 101, (100 * $page), $file_name, "--full-history");
>
> my $paging_nav = '';
> if ($page > 0) {
> @@ -5185,7 +5191,9 @@ sub git_search {
> $greptype = "--committer=";
> }
> $greptype .= $search_regexp;
> - my @commitlist = parse_commits($hash, 101, (100 * $page), $greptype);
> + my @commitlist = parse_commits($hash, 101, (100 * $page), undef,
> + $greptype, $search_use_regexp ? ('--extended-regexp') : (),
> + '--regexp-ignore-case');
>
> my $paging_nav = '';
> if ($page > 0) {
The change makes it harder to write getting log of commits with
some extra option but without the path limiter.
> @@ -5235,8 +5243,9 @@ sub git_search {
> my $git_command = git_cmd_str();
> my $searchqtext = $searchtext;
> $searchqtext =~ s/'/'\\''/;
> + my $pickaxe_flags = $search_use_regexp ? '--pickaxe-regex' : '';
> open my $fd, "-|", "$git_command rev-list $hash | " .
> - "$git_command diff-tree -r --stdin -S\'$searchqtext\'";
> + "$git_command diff-tree -r --stdin -S\'$searchqtext\' $pickaxe_flags";
> undef %co;
> my @files;
> while (my $line = <$fd>) {
Nice.
[...]
> @@ -5364,27 +5375,31 @@ sub git_search_help {
> git_header_html();
> git_print_page_nav('','', $hash,$hash,$hash);
> print <<EOT;
> +<p><strong>Pattern</strong> is by default a normal string that is matched precisely (but without
> +regard to case, except in the case of pickaxe). However, when you check the <em>re</em> checkbox,
> +the pattern entered is recognized as the POSIX extended
> +<a href="http://en.wikipedia.org/wiki/Regular_expression">regular expression</a> (also case
> +insensitive).</p>
> <dl>
> <dt><b>commit</b></dt>
> -<dd>The commit messages and authorship information will be scanned for the given string.</dd>
> +<dd>The commit messages and authorship information will be scanned for the given pattern.</dd>
> EOT
> my ($have_grep) = gitweb_check_feature('grep');
> if ($have_grep) {
> print <<EOT;
> <dt><b>grep</b></dt>
> <dd>All files in the currently selected tree (HEAD unless you are explicitly browsing
> - a different one) are searched for the given
> -<a href="http://en.wikipedia.org/wiki/Regular_expression">regular expression</a>
> -(POSIX extended) and the matches are listed. On large
> -trees, this search can take a while and put some strain on the server, so please use it with
> -some consideration.</dd>
> + a different one) are searched for the given pattern. On large trees, this search can take
> +a while and put some strain on the server, so please use it with some consideration. Note that
> +due to git-grep peculiarity, currently if regexp mode is turned off, the matches are
> +case-sensitive.</dd>
> EOT
[...]
> @@ -5392,7 +5407,8 @@ EOT
> <dt><b>pickaxe</b></dt>
> <dd>All commits that caused the string to appear or disappear from any file (changes that
> added, removed or "modified" the string) will be listed. This search can take a while and
> -takes a lot of strain on the server, so please use it wisely.</dd>
> +takes a lot of strain on the server, so please use it wisely. Note that since you may be
> +interested even in changes just changing the case as well, this search is case sensitive.</dd>
> EOT
> }
> print "</dl>\n";
I'd rather have case-insensitive search _only_ for commit search
(commit message, author, committer), and case-sensitive for the
rest: pickaxe and grep search.
--
Jakub Narebski
Warsaw, Poland
ShadeHawk on #git
^ permalink raw reply
* Re: Perl warning in git-svn (git v1.5.3-rc7-16-ge340d7d)
From: Johannes Schindelin @ 2007-08-31 23:51 UTC (permalink / raw)
To: Sam Vilain; +Cc: Junio C Hamano, Git Mailing List
In-Reply-To: <46D8A886.5060701@vilain.net>
Hi,
On Sat, 1 Sep 2007, Sam Vilain wrote:
> Junio C Hamano wrote:
> >> I was almost going to suggest us to change "*.color = true" to
> >> mean 'auto'. Because git can internally use pager and has a way
> >> for the user to control enabling/disabling colors when the pager
> >> is used, there is no _logical_ reason to enable pager when the
> >> output is not going to a tty.
> >>
> >
> > Gaah, sorry; I meant "no logical reason to enable _color_ when
> > the output is not going to a tty".
>
> Sure there is, when the output is "less -R"
This argument was already raised by Junio himself. But your _option_ to
use "git log | less -R" does not make it a good option. Since "git log"
is so much more elegant already.
Hth,
Dscho
^ 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