# 'git log' doesn't keep log of un-removed and then renamed directory 3 messages from 2021-08-14 to 2021-08-14. Participants: Yuri, Chris Torek. Thread: https://gitlist.dev/t/56282 ## Yuri, 2021-08-14 09:09 Subject: 'git log' doesn't keep log of un-removed and then renamed directory Message-ID: <75911f47-1433-f0a4-7d46-f1fb2fd44cf4@rawbw.com> URL: https://gitlist.dev/e/75911f47-1433-f0a4-7d46-f1fb2fd44cf4%40rawbw.com ``` 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 ``` ## Chris Torek, 2021-08-14 10:18 Subject: Re: 'git log' doesn't keep log of un-removed and then renamed directory Message-ID: URL: https://gitlist.dev/e/CAPx1Gvdb%3DrtjWmc1Qe5iZyuwSF%2Bs-YO7G__VUZ%3DiZw3x4bAKCw%40mail.gmail.com In-Reply-To: <75911f47-1433-f0a4-7d46-f1fb2fd44cf4@rawbw.com> ``` On Sat, Aug 14, 2021 at 2:21 AM Yuri 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 ``` ## Chris Torek, 2021-08-14 10:22 Subject: Re: 'git log' doesn't keep log of un-removed and then renamed directory Message-ID: URL: https://gitlist.dev/e/CAPx1Gve4GoMtH5s-3-RQgf0szvpW-DdFn7GygzAzg_e6vTCrLQ%40mail.gmail.com In-Reply-To: ``` 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. ```