From: Phil Hord <hordp@cisco.com>
To: Jakub Narebski <jnareb@gmail.com>
Cc: git@vger.kernel.org,
"John 'Warthog9' Hawley" <warthog9@kernel.org>,
admin@repo.or.cz
Subject: Re: [PATCH 0/5] gitweb: Improve search code
Date: Wed, 22 Jun 2011 15:24:32 -0400 [thread overview]
Message-ID: <4E024170.6000407@cisco.com> (raw)
In-Reply-To: <201106222000.04854.jnareb@gmail.com>
On 06/22/2011 02:00 PM, Jakub Narebski wrote:
> On Wed, 22 Jun 2011, Phil Hord wrote:
>> On 06/22/2011 11:28 AM, Jakub Narebski wrote:
>>> P.S. Another addition that I sometimes wanted git to have would be
> ^^^
>
> This is a typo: I actually wanted to say "gitweb" here.
>
> Therefore this discussion is totally OFF-TOPIC now.
Dang.
>> I normally revert to 'git log --name-status | less <CR> /filename.foo',
>> which is awful, of course. I've always assumed there's a better way I
>> haven't discovered yet. But if there is, well... I haven't discovered
>> it yet.
>>
>> This syntax works on some files, but is limited and/or broken:
>> # Finds all commits touching the file named './foo.bar', iff
>> ./foo.bar exists in the current commit.
>> git log -- foo.bar
> Errr... if you use "git log foo.bar" it is true, but "git log -- foo.bar"
> will find commits even if foo.bar existed only in the past... though
> history simplification can make git return empty set.
That doesn't work for me. Does it work for you? I only see the
gitweb.pl history if I include --full-history.
git version
#-- git version 1.7.5.rc1
git log -- gitweb.pl | wc
#-- 0 0 0
git log --full-history -- gitweb.pl | wc
#-- 175 412 4087
>> I say 'broken', but maybe it's not; it feels like it is when I do this:
>>
>> # Returns zero logs
>> git log -- some-deleted-file.txt
>>
>> # Returns at least two logs
>> git log --all -- some-deleted-file.txt
> git log --full-history -- some-deleted-file.txt
>
Thanks very much. That is exactly what I was missing.
I obviously didn't know about --full-history. I didn't notice it in
spite of looking for this before and consulting 'git help log'. So I'm
guessing the documentation could use some help there. It's already
pretty crowded, though. Maybe just a note next to '--all' which, for
me, served as a distractingly red herring.
> For example in git.git repository:
>
> $ # git log --full-history --oneline -- gitweb.pl | cat
> 2ad9331 v053
> 185f09e v049
> ff7669a v048
> fbb592a v043
> [...]
> e0389bd v001
> ecb378f v000
> 4c02e3c v000
> 161332a first working version
>
> (Don't you just love Kay Sievers commit messages ;-) ?).
>
>> I think I understand why that happens (search optimization), but it is
>> unexpected from the user's perspective. I also suspect it will miss the
>> 'pre-resurrection' commits for files which were deleted and resurrected
>> in the past.
>>
>>
>> What do you think of these as new 'Commit limiters' for git log:
>>
>> --name=<pattern>, --name-glob=<glob>
>> Limit the commits output to ones touching files that match the
>> specified pattern (regular expression) or glob (shell glob
>> pattern).
> Why not use "git log --full-history -- '<glob>'" (i.e. remember about
> shell escaping glob)? I don't know if it works as intended in current
> git or not...
>
I think that'll work fine. But glob paths failed for me when I tried it
while composing the original email. I think I just mis-interpreted the
reason for the missing commits when I didn't have --full-history.
Also, globbing is not mentioned in the '[--] <path>' section of 'git log
--help'. In fact, the only references to globs in the 'git log' help
[1] are related to refs, not filenames. Ditto for 'git rev-list'.
I initially expected "git log -- 'foo.*'" to work. But it didn't (foo.*
had been deleted) or it only partially worked (no --full-history). So I
interpreted this as it being only partially supported. I did consult
the man page, but it did not do anything to correct my wrong
interpretation. A now-enwisened google search turned up a thread [2]
from 2009 apparently pre-dating this feature.
Thanks again for the education, Jakub. I really appreciate how helpful
this list is.
[1] excepting '-O'
[2] http://article.gmane.org/gmane.comp.version-control.git/109506/
Phil
next prev parent reply other threads:[~2011-06-22 19:24 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-06-22 15:28 [PATCH 0/5] gitweb: Improve search code Jakub Narebski
2011-06-22 15:28 ` [PATCHv3 1/5] gitweb: 'pickaxe' and 'grep' features requires 'search' to be enabled Jakub Narebski
2011-06-22 15:28 ` [PATCH 2/5] gitweb: Check permissions first in git_search Jakub Narebski
2011-06-22 15:28 ` [PATCH 3/5] gitweb: Split body of git_search into subroutines Jakub Narebski
2011-06-22 15:28 ` [PATCH 4/5] gitweb: Clean up code in git_search_* subroutines Jakub Narebski
2011-06-22 15:28 ` [PATCH 5/5] gitweb: Make git_search_* subroutines render whole pages Jakub Narebski
2011-06-22 17:10 ` [PATCH 0/5] gitweb: Improve search code Phil Hord
2011-06-22 18:00 ` Jakub Narebski
2011-06-22 19:24 ` Phil Hord [this message]
2011-06-22 18:55 ` Junio C Hamano
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=4E024170.6000407@cisco.com \
--to=hordp@cisco.com \
--cc=admin@repo.or.cz \
--cc=git@vger.kernel.org \
--cc=jnareb@gmail.com \
--cc=warthog9@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).