'git log' doesn't keep log of un-removed and then renamed directory

'git log' doesn't keep log of un-removed and then renamed directory

[Yuri]

In the FreeBSD ports tree I restored the previously removed directory 
math/dynare:

1. git checkout 3fb72e318f7be~1 -- math/dynare

2. git mv math/dynare science/dynare

3. rm -rf science/dynare && cp -r science/dynare.new science/dynare

4. git add science/dynare

5. git commit science/dynare


After this 'git log science/dynare' only shows my last commit, and not 
the previous history of 'math/dynare' that existed before its removal.


The above sequence of commands should have kept and migrated the history 
of math/dynare to science/dynare, but it didn't.


The corresponding subversion command sequence keeps history.


Yuri

Re: 'git log' doesn't keep log of un-removed and then renamed directory

[Chris Torek]

On Sat, Aug 14, 2021 at 2:21 AM Yuri <yuri@freebsd.org> wrote:
>
> In the FreeBSD ports tree I restored the previously removed directory
> math/dynare:
>
> 1. git checkout 3fb72e318f7be~1 -- math/dynare

[remaining complex shuffling action that mimics what's needed
in SVN, snipped]

Git is not SVN; do not expect it to behave *like* SVN.

In particular, Git does not have file history.  Git has only commits.

SVN has commits, but SVN commits contain file history.  In Git, the
commits *are* the history, and are the *only history*.  Each commit has
a full snapshot of every file, under the names you told Git to use, with
the contents that you told Git to save.

The command `git log science/dynare` tells Git: Look through
commits, one by one, and whenever there's a file whose name
starts with `science/dynare` that's different in *this* commit, vs the
previous one, tell me about this commit.  Since the old commits
have files named `math/dynare/something` instead, Git doesn't
tell you about them.

The `git log` command has a flag, `--follow`, that has a trick up its
sleeve (wait: does `git log` have sleeves? well, anyway). This trick
is a bit limited though. Let's say there's a README file in the
science/dynare/ directory, as of the latest commit.  If you run:

    git log --follow science/dynare/README

Git will look at *this* commit and find the file, and will look at this
commit's *parent* and *not* find the file, because the parent does
not have `science/dynare/README` in it.  But the parent does
have `math/dynare/README` in it *and that file exactly matches*
this commit's copy.  So `git log` will tell you about this commit and
say that the file was *renamed*.  From this point backwards,
`git log` will be looking, not for `science/dynare/README`, but
instead for `math/dynare/README`.

Unfortunately, the `--follow` trick only works on *one file*. But it
will let you know that if you re-run your `git log` with `math/dynare`
you can see what happened before the renaming.

A future `git log` really should be smarter about detecting the
whole-subtree renaming, and be able to follow it.  This won't
require any change in the repository, just a smarter `git log`.
But someone has to write that smarter `git log`.

Chris

Re: 'git log' doesn't keep log of un-removed and then renamed directory

[Chris Torek]

I should add: to make this work in that future smarter
`git log` command, be sure to:

 1. commit the un-removal first; then
 2. commit the rename (you can just `git mv` the
directory and commit)

so that the future smarter `git log` has an easy way of
finding this.  Ideally, it would find this even without that,
but having all the files / sub-trees have identical hash IDs
will make this much faster and easier.