From: Elijah Newren <newren@gmail.com>
To: Jeff King <peff@peff.net>
Cc: biswaranjan.nitrkl@gmail.com,
Bryan Turner <bturner@atlassian.com>,
Git Mailing List <git@vger.kernel.org>
Subject: Re: Retrieving a file in git that was deleted and committed
Date: Mon, 10 Dec 2018 13:33:18 -0800 [thread overview]
Message-ID: <CABPp-BHjR7Wq-D9tFMyPHZE1ogL5udOt8ri1rN3E1CasfD-2PQ@mail.gmail.com> (raw)
In-Reply-To: <20181207072004.GA32603@sigill.intra.peff.net>
On Thu, Dec 6, 2018 at 11:48 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.
>
> 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
Hmm...sure, if the file is deleted on the only relevant branch through
history...but what if there were another branch where it weren't
deleted? What does git blame do then?
In other words, do NOT restore the file as biswaranjan suggested, but
instead restore it this way[1]:
git checkout -b keep-foo $REVISION_BEFORE_FOO_DELETED
git commit --allow-empty -m "We want to keep foo"
git checkout A
git merge --no-commit keep-foo
git checkout keep-foo -- foo.txt
git commit
Now, when you run
git blame foo.txt
blame should notice that foo.txt didn't exist in the first parent
history on A, so it won't bother walking it to find that at some point
foo.txt did exist there. Instead, it'll walk down the second parent
and follow its history, where it should keep walking back and show all
the old changes...right? Or did I mess up my testcase and
misunderstand something somehow?
Elijah
[1] Sidenote: it seems like those commands I gave should have simplified down to
git merge --no-commit --no-ff $REVISION_BEFORE_FOO_DELETED
git checkout $REVISION_BEFORE_FOO_DELETED -- foo.txt
git commit
But that seems to error out with "Already up-to-date"...even when
testing with older versions of git, so it wasn't any of my changes.
Not sure why the --no-ff flag doesn't work.
next prev parent reply other threads:[~2018-12-10 21:33 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-12-07 6:49 Retrieving a file in git that was deleted and committed biswaranjan panda
2018-12-07 6:55 ` Bryan Turner
2018-12-07 7:07 ` biswaranjan panda
2018-12-07 7:20 ` Jeff King
2018-12-07 7:37 ` Bryan Turner
2018-12-07 21:50 ` biswaranjan panda
2018-12-08 7:29 ` Jeff King
2018-12-09 0:07 ` biswaranjan panda
2018-12-11 1:19 ` Junio C Hamano
2018-12-10 21:33 ` Elijah Newren [this message]
2018-12-11 9:46 ` Jeff King
2018-12-10 15:12 ` Sergey Organov
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: http://vger.kernel.org/majordomo-info.html
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=CABPp-BHjR7Wq-D9tFMyPHZE1ogL5udOt8ri1rN3E1CasfD-2PQ@mail.gmail.com \
--to=newren@gmail.com \
--cc=biswaranjan.nitrkl@gmail.com \
--cc=bturner@atlassian.com \
--cc=git@vger.kernel.org \
--cc=peff@peff.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://80x24.org/mirrors/git.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).