Thread (10 messages) flat view 10 messages, 4 authors, 2018-12-11

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

From: biswaranjan panda <hidden>
Date: 2018-12-07 21:51:12

On Thu, Dec 6, 2018 at 11:26 PM Jeff King [off-list ref] wrote:
quoted
On Thu, Dec 06, 2018 at 11:07:00PM -0800, biswaranjan panda wrote:
quoted
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 [off-list ref] wrote:
On Thu, Dec 6, 2018 at 11:26 PM Jeff King [off-list ref] wrote:
quoted
On Thu, Dec 06, 2018 at 11:07:00PM -0800, biswaranjan panda wrote:
quoted
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.
quoted
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
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help