Re: Retrieving a file in git that was deleted and committed
- From
Bryan Turner <bturner@atlassian.com>
- Date
- Dec 7, 2018, 07:37 UTC
- Message-ID
- <CAGyf7-EkyGOi02fqMcCPBzj-=wpsH4zCgvP5VhOoKMdG+wfoLw@mail.gmail.com>
- In-Reply-To
- <20181207072004.GA32603@sigill.intra.peff.net>
On Thu, Dec 6, 2018 at 11:26 PM Jeff King <peff@peff.net> wrote:
Show 15 quoted lines
> > 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.
Show 12 quoted lines
> > 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