does not change the way the tree state is built at this commit.
If the `from` command is
omitted when creating a new branch, the first `merge` commit will be
the first ancestor of the current commit, and the branch will start
out with no files.  An unlimited number of `merge` commands per
commit are permitted by fast-import, thereby establishing an n-way merge.

Here `<commit-ish>` is any of the commit specification expressions
also accepted by `from` (see above).

`filemodify`
^^^^^^^^^^^^
Included in a `commit` command to add a new file or change the
content of an existing file.  This command has two different means
of specifying the content of the file.

External data format::
	The data content for the file was already supplied by a prior
	`blob` command.  The frontend just needs to connect it.
+
....
	'M' SP <mode> SP <dataref> SP <path> LF
....
+
Here usually `<dataref>` must be either a mark reference (`:<idnum>`)
set by a prior `blob` command, or a full 40-byte SHA-1 of an
existing Git blob object.  If `<mode>` is `040000`` then
`<dataref>` must be the full 40-byte SHA-1 of an existing
Git tree object or a mark reference set with `--import-marks`.

Inline data format::
	The data content for the file has not been supplied yet.
	The frontend wants to supply it as part of this modify
	command.
+
....
	'M' SP <mode> SP 'inline' SP <path> LF
	data
....
+
See below for a detailed description of the `data` command.

In both formats `<mode>` is the type of file entry, specified
in octal.  Git only supports the following modes:

* `100644` or `644`: A normal (not-executable) file.  The majority
  of files in most projects use this mode.  If in doubt, this is
  what you want.
* `100755` or `755`: A normal, but executable, file.
* `120000`: A symlink, the content of the file will be the link target.
* `160000`: A gitlink, SHA-1 of the object refers to a commit in
  another repository. Git links can only be specified either by SHA or through
  a commit mark. They are used to implement submodules.
* `040000`: A subdirectory.  Subdirectories can only be specified by
  SHA or through a tree mark set with `--import-marks`.

In both formats `<path>` is the complete path of the file to be added
(if not already existing) or modified (if already existing).

A `<path>` can be written as unquoted bytes or a C-style quoted string.

When a `<path>` does not start with a double quote (`"`), it is an
unquoted string and is parsed as literal bytes without any escape
sequences. However, if the filename contains `LF` or starts with double
quote, it cannot be represented as an unquoted string and must be
quoted. Additionally, the source `<path>` in `filecopy` or `filerename`
must be quoted if it contains SP.

When a `<path>` starts with a double quote (`"`), it is a C-style quoted
string, where the complete filename is enclosed in a pair of double
quotes and escape sequences are used. Certain characters must be escaped
by preceding them with a backslash: `LF` is written as `\n`, backslash
as `\\`, and double quote as `\"`. Some characters may optionally be
written with escape sequences: `\a` for bell, `\b` for backspace, `\f`
for form feed, `\n` for line feed, `\r` for carriage return, `\t` for
horizontal tab, and `\v` for vertical tab. Any byte can be written with
3-digit octal codes (e.g., `\033`). All filenames can be represented as
quoted strings.

A `<path>` must use UNIX-style directory separators (forward slash `/`)
and its value must be in canonical form. That is it must not:

* contain an empty directory component (e.g. `foo//bar` is invalid),
* end with a directory separator (e.g. `foo/` is invalid),
* start with a directory separator (e.g. `/foo` is invalid),
* contain the special component `.` or `..` (e.g. `foo/./bar` and
  `foo/../bar` are invalid).

The root of the tree can be represented by an empty string as `<path>`.

`<path>` cannot contain NUL, either literally or escaped as `\000`.
It is recommended that `<path>` always be encoded