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
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html