From: biswaranjan panda <hidden> Date: 2018-12-07 06:49:36
I have the following scenario:
On a branch A, I deleted a file foo.txt and committed the change. Then
I did a bunch of other changes.
Now I want to undelete foo.txt.
One way is to checkout a separate branch B where the file is present.
Then checkout A. Then do
git checkout B -- path_to_file
While this does gets the file back, the file shows up as a new file to
be committed. Once I commit it, git blame doesn't show the old history
for the file.
I would appreciate if anyone knows how to preserve git blame history.
On Thu, Dec 6, 2018 at 10:49 PM biswaranjan panda
[off-list ref] wrote:
I have the following scenario:
On a branch A, I deleted a file foo.txt and committed the change. Then
I did a bunch of other changes.
Now I want to undelete foo.txt.
One way is to checkout a separate branch B where the file is present.
Then checkout A. Then do
git checkout B -- path_to_file
It doesn't change anything, but note that you don't need to checkout B
first, to restore the file. If you know a commit SHA where the file is
present, "git checkout SHA -- path_to_file" will pull back the file as
it existed at that commit.
While this does gets the file back, the file shows up as a new file to
be committed. Once I commit it, git blame doesn't show the old history
for the file.
I would appreciate if anyone knows how to preserve git blame history
It's not possible, as far as I'm aware. While the new file has the
same name as the old file, to Git they are two unrelated entries that
happen to reside at the same path. Even things like "git log --follow"
won't consider the file to be related to its previous history.
Bryan
From: biswaranjan panda <hidden> Date: 2018-12-07 07:07:15
Thanks! Strangely git log --follow does work.
On Thu, Dec 6, 2018 at 10:55 PM Bryan Turner [off-list ref] wrote:
On Thu, Dec 6, 2018 at 10:49 PM biswaranjan panda
[off-list ref] wrote:
quoted
I have the following scenario:
On a branch A, I deleted a file foo.txt and committed the change. Then
I did a bunch of other changes.
Now I want to undelete foo.txt.
One way is to checkout a separate branch B where the file is present.
Then checkout A. Then do
git checkout B -- path_to_file
It doesn't change anything, but note that you don't need to checkout B
first, to restore the file. If you know a commit SHA where the file is
present, "git checkout SHA -- path_to_file" will pull back the file as
it existed at that commit.
quoted
While this does gets the file back, the file shows up as a new file to
be committed. Once I commit it, git blame doesn't show the old history
for the file.
I would appreciate if anyone knows how to preserve git blame history
It's not possible, as far as I'm aware. While the new file has the
same name as the old file, to Git they are two unrelated entries that
happen to reside at the same path. Even things like "git log --follow"
won't consider the file to be related to its previous history.
Bryan
From: Jeff King <hidden> Date: 2018-12-07 07:26:49
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
On Thu, Dec 6, 2018 at 11:26 PM Jeff King [off-list ref] wrote:
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.
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
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
From: Jeff King <hidden> Date: 2018-12-08 07:33:07
On Fri, Dec 07, 2018 at 01:50:57PM -0800, biswaranjan panda wrote:
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 ?
Not easily. ;)
You can feed a set of revisions to git-blame with the "-S" option, but I
don't offhand know how it handles diffs (I think it would have to still
diff each commit against its parent, since history is non-linear, and a
list is inherently linear). You might want to experiment with that.
Other than that, you can play with git-replace to produce a fake
history, as if the deletion never happened. But note that will affect
all commands, not just one particular blame. It might be a neat way to
play with blame, but I doubt I'd leave the replacement in place in the
long term.
-Peff
From: biswaranjan panda <hidden> Date: 2018-12-09 00:07:58
You can feed a set of revisions to git-blame with the "-S" option, but I
don't offhand know how it handles diffs (I think it would have to still
diff each commit against its parent, since history is non-linear, and a
list is inherently linear). You might want to experiment with that.
Other than that, you can play with git-replace to produce a fake
history, as if the deletion never happened. But note that will affect
all commands, not just one particular blame. It might be a neat way to
play with blame, but I doubt I'd leave the replacement in place in the
long term.
-Peff
Ah I see. Will try git-replace. Thanks!
On Fri, Dec 7, 2018 at 11:29 PM Jeff King [off-list ref] wrote:
On Fri, Dec 07, 2018 at 01:50:57PM -0800, biswaranjan panda wrote:
quoted
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 ?
Not easily. ;)
You can feed a set of revisions to git-blame with the "-S" option, but I
don't offhand know how it handles diffs (I think it would have to still
diff each commit against its parent, since history is non-linear, and a
list is inherently linear). You might want to experiment with that.
Other than that, you can play with git-replace to produce a fake
history, as if the deletion never happened. But note that will affect
all commands, not just one particular blame. It might be a neat way to
play with blame, but I doubt I'd leave the replacement in place in the
long term.
-Peff
On Thu, Dec 6, 2018 at 11:48 PM Jeff King [off-list ref] wrote:
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.
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.
From: Jeff King <hidden> Date: 2018-12-11 09:46:59
On Mon, Dec 10, 2018 at 01:33:18PM -0800, Elijah Newren wrote:
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?
Yeah, I think that should work, and is a clever way of representing in
the actual history graph what you're we're trying to express. And it
shouldn't have any real downsides.
-Peff