On Mon, Jun 24, 2019 at 5:05 AM Lars Schneider <larsxschneider@xxxxxxxxx> wrote: > > Hi folks, > > Is my understanding correct, that `git fast-export | git fast-import` > should not modify the repository? I forgot to respond to this part. The answer is mostly yes, but actually no: * fast-export strips any extended commit headers, if any (it only looks for expected headers and handles those) * fast-export omits any tags of trees * fast-export sometimes rewrites tags of tags of commits to tags of commits (depends on options passed; it either mistakenly does this, or dies with an error) * fast-export defaults to re-encoding commits to be in UTF-8, with no option in git <= 2.22.0 to leave the encoding alone * annotated tags outside of the refs/tags/ namespace will have their location mangled * references that include commit cycles in their history (which can be created with git-replace(1)) will not be flagged to the user as an error but will be silently deleted by fast-export as though the branch or tag contained no interesting files * fast-export or fast-import may die on some repositories (e.g. if there are tags of blobs, if there are signed tags and no --signed-tags= option passed, if a commit has improperly formatted info such as a timezone with more than four digits (which exist in the wild, e.g. in the rails repo, and google will find you more), or in latest git master if the commit has a recorded encoding and no --reencode option is passed) * ...and the bug you just found. It's a valid question whether these are bugs or not; I'd say that some definitely are, but not all. I had to document all of these up at https://github.com/newren/git-filter-repo#inherited-limitations, among one or two others based on the options I default to passing to fast-export. Hope that helps, Elijah
