{"thread":{"id":"17836","subject":"fast-import, merges, and file changes -- lack of clarity in docs, possible minor bug, or PEBKAC?","startedAt":"2009-02-17T00:28:44Z","lastAt":"2009-02-17T05:47:09Z","messageCount":2,"participants":["Elijah Newren"],"isPatch":false,"patchVersion":null,"patchTotal":null},"messages":[{"id":"105035","messageId":"51419b2c0902161628x7a3475e6p2a70310e5b294444@mail.gmail.com","threadId":"17836","inReplyTo":null,"subject":"fast-import, merges, and file changes -- lack of clarity in docs, possible minor bug, or PEBKAC?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-02-17T00:28:44Z","receivedAt":"2009-02-17T00:28:44Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"Hi,\n\nIt appears the documentation for fast-import does not specify the\nbasis on which a commit command's file changes (filemodify,\nfiledelete, filecopy, or filerename) are relative to. For a non-merge\ncommit, it's obvious, and I thought that it would be obvious for a\nmerge commit too -- and then found out I had assumed the wrong answer.\n I assumed the file changes would be relative to the *combined* set of\nfiles from the parents, whereas fast-import apparently treats them as\nrelative to the first (or 'from') parent. (Since the combined set of\nfiles may have conflicts, I'd expect it to be an error if the merge\ncommit didn't specify an appropriate filemodify command for at least\neach of the filenames with conflicts.)\n\nIn case my description above isn't clear, I've got a simple example at\nthe end of this email that has a file 'world' on one branch, a file\n'bar' on another branch, and a merge of the two branches. In the\nmerge commit, I do not need to mention the 'world' file; it will be\nincluded automatically. However, unless I mention the 'bar' file (by\nadding a 'M 100644 :1 bar' line to the end of the input), it will not\nbe included in the merge commit.\n\nIs this intentional? I believe we could change this behavior without\nbreaking backward compatibility with older fast-export output streams,\nsince such older streams would simply be providing redundant\ninformation. But is there a reason for this behavior that I'm\nmissing?\n\n\nThanks,\nElijah\n\n\nSample input file for git fast-import (which merges two commits but\nsilently drops one of the files):\n\nblob\nmark :1\ndata 4\nfoo\n\nreset refs/heads/other\ncommit refs/heads/other\nmark :2\nauthor Elijah Newren 1234815015 -0700\ncommitter Elijah Newren 1234815015 -0700\ndata 29\nInitial commit, other branch\nM 100644 :1 bar\n\nblob\nmark :3\ndata 3\nhi\n\nreset refs/heads/master\ncommit refs/heads/master\nmark :4\nauthor Elijah Newren 1234814943 -0700\ncommitter Elijah Newren 1234814943 -0700\ndata 30\nInitial commit, master branch\nM 100644 :3 world\n\ncommit refs/heads/master\nmark :5\nauthor Elijah Newren 1234815029 -0700\ncommitter Elijah Newren 1234815029 -0700\ndata 21\nMerge branch 'other'\nfrom :4\nmerge :2\n"},{"id":"105076","messageId":"51419b2c0902162147y588ad4dfk58271f3434dea66c@mail.gmail.com","threadId":"17836","inReplyTo":"51419b2c0902161628x7a3475e6p2a70310e5b294444@mail.gmail.com","subject":"Re: fast-import, merges, and file changes -- lack of clarity in docs, possible minor bug, or PEBKAC?","fromName":"Elijah Newren","fromEmail":"newren@gmail.com","sentAt":"2009-02-17T05:47:09Z","receivedAt":"2009-02-17T05:47:09Z","isPatch":false,"sender":{"key":"newren@gmail.com","avatar":"https://avatars.githubusercontent.com/u/5455730?v=4"},"body":"I think I've at least partially discovered the answer my own\nquestion(s), so I figured I'd document them in case anyone else was\nwondering...\n\nOn Mon, Feb 16, 2009 at 5:28 PM, Elijah Newren wrote:\n> It appears the documentation for fast-import does not specify the\n> basis on which a commit command's file changes (filemodify,\n> filedelete, filecopy, or filerename) are relative to.\n\n> Is this intentional? I believe we could change this behavior without\n> breaking backward compatibility with older fast-export output streams,\n> since such older streams would simply be providing redundant\n> information. But is there a reason for this behavior that I'm\n> missing?\n\nIt is documented...though implicitly in discussion of other commands.\nIn particular, \"...a `merge` command may be used instead of `from` to\nstart the commit with an empty tree\" and later \"If the `from` command\nis omitted when creating a new branch, the first `merge` commit will\nbe the first ancestor of the current commit, and the branch will start\nout with no files.\" This implies that the files of a `merge` parent\nare ignored and any content must from that parent that is contained in\nthe commit must be explicitly spelled out to be included.\n\nAlso, as far as backward compatibility, my suggestion would not be\ncompatible; deletions involved in such merges would be handled by\ncurrent fast-export streams by simply omitting the file in the list of\nfile changes in the merge commit. My suggestion would require\nexplicitly specified file deletion to ensure its removal.\n\nSo, it appears this is intentional, any behavior change such as I\nsuggested would require different/new syntax, and would require\nsupport in fast-export too for my purposes. That certainly makes my\ngit-fast-filter script (a script in a pipeline between fast-export and\nfast-import designed to act somewhat like filter-branch but with\nbetter performance on my large repositories) much harder. Oh, well.\n\n\nElijah\n"}]}