Re: Retrieving a file in git that was deleted and committed

[biswaranjan panda <biswaranjan.nitrkl@gmail.com>]

On Thu, Dec 6, 2018 at 11:26 PM Jeff King <peff@peff.net> wrote:
>>
>> On Thu, Dec 06, 2018 at 11:07:00PM -0800, biswaranjan panda wrote:
>>
> >> Thanks! Strangely git log --follow does work.
>>
>> I suspect it would work even without --follow. When you limit a log
>> traversal with a pathspec, like:
>>
>>   git log foo
>>
>> that is not about following some continuous stream of content, but
>> rather just applying that pathspec to the diff of each commit, and
>> pruning ones where it did not change. So even if there are gaps where
>> the file did not exist, we continue to apply the pathspec to the older
>> commits.

> Ah, of course. Thanks for the clarification, Jeff. And my > apologies to
> Biswaranjan Panda for the incorrect information.

Thanks Jeff and Bryan! However, I am curious that if there were a way
to tell git blame to skip a commit (the one which added the file again
and maybe the one which deleted it originally) while it walks back
through history, then it should just get back the
entire history right ?
On Thu, Dec 6, 2018 at 11:37 PM Bryan Turner <bturner@atlassian.com> wrote:
>
> On Thu, Dec 6, 2018 at 11:26 PM Jeff King <peff@peff.net> wrote:
> >
> > On Thu, Dec 06, 2018 at 11:07:00PM -0800, biswaranjan panda wrote:
> >
> > > Thanks! Strangely git log --follow does work.
> >
> > I suspect it would work even without --follow. When you limit a log
> > traversal with a pathspec, like:
> >
> >   git log foo
> >
> > that is not about following some continuous stream of content, but
> > rather just applying that pathspec to the diff of each commit, and
> > pruning ones where it did not change. So even if there are gaps where
> > the file did not exist, we continue to apply the pathspec to the older
> > commits.
>
> Ah, of course. Thanks for the clarification, Jeff. And my apologies to
> Biswaranjan Panda for the incorrect information.
>
> >
> > Tools like git-blame will _not_ work, though, as they really are trying
> > to track the content as they walk back through history. And Once all of
> > the content seems to appear from nowhere in your new commit, that seems
> > like a dead end.
> >
> > In theory there could be some machine-readable annotation in the commit
> > object (or in a note created after the fact) to say "even though 'foo'
> > is a new file here, it came from $commit:foo".  And then git-blame could
> > keep following the content there. But such a feature does not yet exist.
> >
> > -Peff



-- 
Thanks,
-Biswa