git/list[1] front-page[2] threads[3] people[4] search[5] about
 

Re: [PATCH 0/5] gitweb: Improve search code

From
Phil Hord <hordp@cisco.com>
Date
Jun 22, 2011, 19:24 UTC
Message-ID
<4E024170.6000407@cisco.com>
In-Reply-To
<201106222000.04854.jnareb@gmail.com>
On 06/22/2011 02:00 PM, Jakub Narebski wrote:
Show 8 quoted lines
> 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.
Show 12 quoted lines
>> 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
Show 9 quoted lines
>> 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.

Show 31 quoted lines
> 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
Previous: Jakub NarebskiNext: Junio C Hamano
Message 9 of 10 in “gitweb: Improve search code”
  1. 0/5 gitweb: Improve search codeJakub Narebski, Jun 22, 2011
  2. 1/5 gitweb: 'pickaxe' and 'grep' features requires 'search' to be enabledJakub Narebski, Jun 22, 2011
  3. 2/5 gitweb: Check permissions first in git_searchJakub Narebski, Jun 22, 2011
  4. 3/5 gitweb: Split body of git_search into subroutinesJakub Narebski, Jun 22, 2011
  5. 4/5 gitweb: Clean up code in git_search_* subroutinesJakub Narebski, Jun 22, 2011
  6. 5/5 gitweb: Make git_search_* subroutines render whole pagesJakub Narebski, Jun 22, 2011
  7. Phil HordJun 22, 2011
  8. Jakub NarebskiJun 22, 2011
  9. Phil HordJun 22, 2011
  10. Junio C HamanoJun 22, 2011

Read the whole thread, see it on lore, or plain text.

$ cat FOOTERMessages come from the public archive at lore.kernel.org/git, fetched every hour. The front page is chosen and written each morning by an AI editor and can be wrong; the threads themselves are the record. About and API. For agents: an MCP server at https://gitlist.dev/mcp, and any thread, story or person page as Markdown by adding .md to its URL (or sending Accept: text/markdown). Details in /llms.txt.