Git blame see all history of commit

Question

We have a Git repo in which we all made deliveries and track details.

One of the other teams in our organization has another project to re-organize the code in our repo and they made some changes in file location [no code] / created new library etc and created a new repo.

Now doing a git blame refers me to one who migrated the code not who has written the code?

How can I get the actual author of the code via blame now?

Does this answer your question? [Git blame -- prior commits?](https://stackoverflow.com/questions/5098256/git-blame-prior-commits) — jonrsharpe, Jun 29 '20 at 06:37
"*and created a new repo*" If they created a new repository and copied the code there, it will not have the history from the old repository. You can stitch the history back together. — Schwern, Jun 29 '20 at 06:44
Git blame prior commits post did not helped - I could not get the information or history prior to migration — Programmer, Jun 29 '20 at 06:48
@Schwern - please let me know how to stitch the history back together? — Programmer, Jun 29 '20 at 06:48
@Schwern is there a way that when files are migrated we can carry the Git history also? — Programmer, Jun 29 '20 at 06:52
By "migrated", did you keep the history or did you just commit a snapshot of the latest files into a new repository? Please be explicit about what you did. — Lasse V. Karlsen, Jun 29 '20 at 07:51
If you committed a snapshot of the latest files from one repository into a completely new repository, then no, that new repository will not show any history from the old repository. If by "actual author" you mean the original author of the first commit of that file, you will have to go to the old repository and look at the history there. — Lasse V. Karlsen, Jun 29 '20 at 07:53
Also be aware that you can have 2 names attached to a commit, the author and the committer. In this case it sounds like the person doing the migration should leave author for a file according to original author, if that's what you wanted to see, and use their own name as committer, but this will be hard if there are many authors involved across the repository. — Lasse V. Karlsen, Jun 29 '20 at 07:53
(further elements on @LasseV.Karlsen comment) in that `new repo` : when you look at the history of all commits, do you see the complete history of your initial repo ? or does the history start with a big new commit "imported code from team A" ? — LeGEC, Jun 29 '20 at 08:06

score 0 · Accepted Answer · answered Jun 29 '20 at 19:02

What I understand is someone copied the files to a new repo and lost their history.

It should not have been necessary to copy the files to a new repo in the first place. The reorganization should have happened as a normal commit. Then tools such as git log and git blame would be able to continue to track the history of the files across renames and copies. The only reason I can think you would need a new repository is if the history got bloated with large files like videos, images, and office documents. That is better solved using git-lfs retroactively.

Now that you're in this situation, the best thing to do is to rewrite the new repository on top of the old one. Let's say your old and new repos look like this.

old
A - B - C - D [master]

origin
X - Y - Z [master]

local
X - Y - Z [origin/master]
          [master]

"origin" is the new repository you cloned from. "local" is your clone.

You want to stitch them together like this.

old
A - B - C - D [master]

origin
A - B - C - D - X1 - Y1 - Z1 [master]

new
A - B - C - D - X1 - Y1 - Z1 [origin/master]
                             [master]

First, make the old repository a remote of the new one and fetch it.

$ cd new
$ git remote add old <url to old repo>
$ git fetch old

old
A - B - C - D [master]

origin
X - Y - Z [master]

local
A - B - C - D [old/master]

X - Y - Z [origin/master]
          [master]

Now your new repository has the old history of master available as origin/master.

Then rebase the new commits on top of the old commits.

$ git checkout master
$ git rebase old/master

old
A - B - C - D [master]

origin
X - Y - Z [master]

local
A - B - C - D [old/master]
             \
              X1 - Y1 - Z1 [master]

X - Y - Z [origin/master]

Now it's time to push your changes. Your local master and remote master have "diverged", your local changes are no longer simply on top of the remote ones. You will need to force the push. Use git push --force-with-lease to safely force the push.

$ git push --force-with-lease

old
A - B - C - D [master]

origin
A - B - C - D - X1 - Y1 - Z1 [master]

local
A - B - C - D [old/master]
             \
              X1 - Y1 - Z1 [origin/master]
                           [master]

Remove old as a remote.

$ git remote rm old

old
A - B - C - D [master]

origin
A - B - C - D - X1 - Y1 - Z1 [master]

local
A - B - C - D - X1 - Y1 - Z1 [origin/master]
                             [master]

Others who have cloned the new repository and done work should git pull --rebase to update their master branch.

Git blame see all history of commit

1 Answers1