Today, we’re going to duplicate a file while preserving git line history.<\/p>\n
This could be useful if you want two copies of a component, say, one where you are doing a bunch of disruptive work, and another that remains largely unchanged. The project continues to use the old, stable version, but there’s a feature flag to switch to the new, exciting one. Eventually, you’ll make the new, exciting one the default version.<\/p>\n
When you do this, you want the line history of the new version to be the same as the line history of the old version, because the new version is basically a fork of the old version.<\/p>\n
Again, let’s use the same scratch repo as we did for the last few days. You can follow the same copy\/paste script, or you can take your existing scratch repo and Let’s set up a scratch repo to demonstrate. I’ve omitted the command prompts so you can copy-paste this into your shell of choice and play along at home. (The timestamps and commit hashes will naturally be different.)<\/p>\n We employ our standard trick: Create a branch where the desired new file appears to have been created via a rename of the original file. And then restore the original file.<\/p>\n On this branch, we renamed And then we bring back the original The The line histories of the two files are identical, because the Synthesize it in a branch via a rename.<\/p>\n","protected":false},"author":1069,"featured_media":111744,"comment_status":"open","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[1],"tags":[25],"class_list":["post-102904","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-oldnewthing","tag-code"],"acf":[],"blog_post_summary":" Synthesize it in a branch via a rename.<\/p>\n","_links":{"self":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102904","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/users\/1069"}],"replies":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/comments?post=102904"}],"version-history":[{"count":0,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/posts\/102904\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media\/111744"}],"wp:attachment":[{"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/media?parent=102904"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/categories?post=102904"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/devblogs.microsoft.com\/oldnewthing\/wp-json\/wp\/v2\/tags?post=102904"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}git reset --hard ready<\/code> to get it back into its “ready to start experimenting” state.<\/p>\ngit init\r\n\r\n>foods echo apple\r\ngit add foods\r\ngit commit --author=\"Alice <alice>\" -m created\r\n\r\n>>foods echo orange\r\ngit commit --author=\"Bob <bob>\" -am orange\r\n\r\ngit blame foods\r\n\r\n^62ef37c (Alice 2019-09-19 07:00:00 -0700 1) apple\r\n335acb1b (Bob 2019-09-19 07:00:01 -0700 2) orange\r\n<\/pre>\n
git checkout -b dup\r\n\r\ngit mv foods foods-new\r\ngit commit --author=\"Greg <greg>\" -m \"duplicate foods to foods-new\"\r\n\r\ngit checkout HEAD~ foods\r\ngit commit --author=\"Greg <greg>\" -m \"restore foods\"\r\n\r\ngit checkout -\r\n<\/pre>\n
foods<\/code> to foods-new<\/code>. When git traces the history of the foods-new<\/code> file, it’ll see that the file was created via rename from foods<\/code>, so git will use food<\/code>‘s history to build the line history.<\/p>\nfoods<\/code> file. We use the git checkout HEAD~ foods<\/code> command to restore the file from a specific commit, namely the commit before we renamed it away.<\/p>\ngit merge --no-ff dup\r\n\r\nMerge made by the 'recursive' strategy.\r\n foods-new | 2 ++\r\n 1 file changed, 2 insertions(+)\r\n create mode 100644 foods-new\r\n<\/pre>\n
dup<\/code> branch deleted the foods<\/code> file, and then restored it. That means there was no net change to the file in the dup<\/code> branch, and even git log<\/code> won’t notice it by default. If you do a log of the foods<\/code> file, the merge doesn’t even show up.<\/p>\ngit log --oneline foods\r\n\r\n \u2190 the merge doesn't appear\r\n335acb1 orange\r\n62ef37c created\r\n<\/pre>\n
foods-new<\/code> was created at the same time an identical foods<\/code> file disappeared, which made git consider the operation to be a rename for the purpose of history tracking.<\/p>\ngit blame foods\r\n\r\n^62ef37c (Alice 2019-09-19 07:00:00 -0700 1) apple\r\n335acb1b (Bob 2019-09-19 07:00:01 -0700 2) orange\r\n\r\ngit blame foods-new\r\n\r\n^62ef37c foods (Alice 2019-09-19 07:00:00 -0700 1) apple\r\n335acb1b foods (Bob 2019-09-19 07:00:01 -0700 2) orange\r\n<\/pre>\n","protected":false},"excerpt":{"rendered":"