Perrin Meyer <perrinmeyer@xxxxxxxxx> wrote: > $ mv doc/ Documentation/ > $ git commit -a > where I see a lot of deletes > > $ git add Documentation/ > $ git commit -a > and I see that a all my doc files added, as expected. > > But when I got to look at the history of the Documentation/ directory > > $ git log Documentation/ > > I only see one commit message > > $ git log --follow Documentation/ --follow only works on a single file. So you cannot use it for an entire directory. > $ git log --follow README > > I only see the single rename commit, not any history. Right, because the file came into existance in that commit and we cannot find any deleted path in that same commit that is "highly similar" to the file now called Documentation/README. So we don't call it a rename. > I'm guessing, in hindsight, that I probably should have done > > $ mv doc/ Documentation/ > $ git add Documentation/ > $ git commit -a Correct. Rename detection works by looking for an add/delete pair _in the same commit_ that have file content that is higly similar between the two paths. You broke that by doing the two changes in two different commits. > but is there anyway to get my history back given what I have done? I can't think of one other than to squash the two commits together with a tool like `git rebase -i` and then force push it back to your upstream repository. Note that doing this would change the commit SHA-1 names so anyone who has built on top of these changes would also need to rebase their changes. -- Shawn. - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
