neulab/tldr huggingface dataset:
<commit>... Commits, usually other branch heads, to merge into our branch. Specifying more than one commit will create a merge with more than two parents (affectionately called an Octopus merge).
If no commit is given from the command line, merge the remote-tracking branches that the current branch is configured to use as its upstream. See also the configuration section of this manual page.
When FETCH_HEAD (and no other commit) is specified, the branches recorded in the .git/FETCH_HEAD file by the previous invocation of git fetch for merging are merged to the current branch.
PRE-MERGE CHECKS Before applying outside changes, you should get your own work in good shape and committed locally, so it will not be clobbered if there are conflicts. See also git-stash(1). git pull and git merge will stop without doing anything when local uncommitted changes overlap with files that git pull/git merge may need to update.
To avoid recording unrelated changes in the merge commit, git pull and git merge will also abort if there are any changes registered in the index relative to the HEAD commit. (Special narrow exceptions to this rule may exist depending on which merge strategy is in use, but generally, the index must match HEAD.)
If all named commits are already ancestors of HEAD, git merge will exit early with the message "Already up to date."
FAST-FORWARD MERGE Often the current branch head is an ancestor of the named commit. This is the most common case especially when invoked from git pull: you are tracking an upstream repository, you have committed no local changes, and now you want to update to a newer upstream revision. In this case, a new commit is not needed to store the combined history; instead, the HEAD (along with the index) is updated to point at the named commit, without creating an extra merge commit.
This behavior can be suppressed with the --no-ff option.
Except in a fast-forward merge (see above), the branches to be merged must be tied together by a merge commit that has both of them as its parents.
A merged version reconciling the changes from all branches to be merged is committed, and your HEAD, index, and working tree are updated to it. It is possible to have modifications in the working tree as long as they do not overlap; the update will preserve them.
When it is not obvious how to reconcile the changes, the following happens:
1. The HEAD pointer stays the same.
2. The MERGE_HEAD ref is set to point to the other branch head.
3. Paths that merged cleanly are updated both in the index file and in your working tree.
4. For conflicting paths, the index file records up to three versions: stage 1 stores the version from the common ancestor, stage 2 from HEAD, and stage 3 from MERGE_HEAD (you can inspect the stages with git ls-files -u). The working tree files contain the result of the "merge" program; i.e. 3-way merge results with familiar conflict markers <<< === >>>.
5. No other changes are made. In particular, the local modifications you had before you started merge will stay the same and the index entries for them stay as they were, i.e. matching HEAD.
If you tried a merge which resulted in complex conflicts and want to start over, you can recover with git merge --abort.
When merging an annotated (and possibly signed) tag, Git always creates a merge commit even if a fast-forward merge is possible, and the commit message template is prepared with the tag message. Additionally, if the tag is signed, the signature check is reported as a comment in the message template. See also git-tag(1).
When you want to just integrate with the work leading to the commit that happens to be tagged, e.g. synchronizing with an upstream release point, you may not want to make an unnecessary merge commit.
In such a case, you can "unwrap" the tag yourself before feeding it to git merge, or pass --ff-only when you do not have any work on your own. e.g.
git fetch origin git merge v1.2.3^0 git merge --ff-only v1.2.3
During a merge, the working tree files are updated to reflect the result of the merge. Among the changes made to the common ancestor’s version, non-overlapping ones (that is, you changed an area of the file while the other side left that area intact, or vice versa) are incorporated in the final result verbatim. When both sides made changes to the same area, however, Git cannot randomly pick one side over the other, and asks you to resolve it by leaving what both sides did to that area.
By default, Git uses the same style as the one used by the "merge" program from the RCS suite to present such a conflicted hunk, like this:
Here are lines that are either unchanged from the common ancestor, or cleanly resolved because only one side changed. <<<<<<< yours:sample.txt Conflict resolution is hard; let's go shopping. ======= Git makes conflict resolution easy. >>>>>>> theirs:sample.txt And here is another line that is cleanly resolved or unmodified.
The area where a pair of conflicting changes happened is marked with markers <<<<<<<, =======, and >>>>>>>. The part before the ======= is typically your side, and the part afterwards is typically their side.
The default format does not show what the original said in the conflicting area. You cannot tell how many lines are deleted and replaced with Barbie’s remark on your side. The only thing you can tell is that your side wants to say it is hard and you’d prefer to go shopping, while the other side wants to claim it is easy.
An alternative style can be used by setting the "merge.conflictStyle" configuration variable to "diff3". In "diff3" style, the above conflict may look like this:
Here are lines that are either unchanged from the common ancestor, or cleanly resolved because only one side changed. <<<<<<< yours:sample.txt Conflict resolution is hard; let's go shopping. ||||||| Conflict resolution is hard. ======= Git makes conflict resolution easy. >>>>>>> theirs:sample.txt And here is another line that is cleanly resolved or unmodified.
In addition to the <<<<<<<, =======, and >>>>>>> markers, it uses another ||||||| marker that is followed by the original text. You can tell that the original just stated a fact, and your side simply gave in to that statement and gave up, while the other side tried to have a more positive attitude. You can sometimes come up with a better resolution by viewing the original.
After seeing a conflict, you can do two things:
•   Decide not to merge. The only clean-ups you need are to reset the index file to the HEAD commit to reverse 2. and to clean up working tree changes made by 2. and 3.; git merge --abort can be used for this.
•   Resolve the conflicts. Git will mark the conflicts in the working tree. Edit the files into shape and git add them to the index. Use git commit or git merge --continue to seal the deal. The latter command checks whether there is a (interrupted) merge in progress before calling git commit.
You can work through the conflict with a number of tools:
•   Use a mergetool.  git mergetool to launch a graphical mergetool which will work you through the merge.
•   Look at the diffs.  git diff will show a three-way diff, highlighting changes from both the HEAD and MERGE_HEAD versions.
•   Look at the diffs from each branch.  git log --merge -p <path> will show diffs first for the HEAD version and then the MERGE_HEAD version.
•   Look at the originals.  git show :1:filename shows the common ancestor, git show :2:filename shows the HEAD version, and git show :3:filename shows the MERGE_HEAD version.
•   Merge branches fixes and enhancements on top of the current branch, making an octopus merge:
$ git merge fixes enhancements
•   Merge branch obsolete into the current branch, using ours merge strategy:
$ git merge -s ours obsolete
•   Merge branch maint into the current branch, but do not make a new commit automatically:
$ git merge --no-commit maint
This can be used when you want to include further changes to the merge, or want to write your own merge commit message.
You should refrain from abusing this option to sneak substantial changes into a merge commit. Small fixups like bumping release/version name would be acceptable.
merge.conflictStyle Specify the style in which conflicted hunks are written out to working tree files upon merge. The default is "merge", which shows a <<<<<<< conflict marker, changes made by one side, a ======= marker, changes made by the other side, and then a >>>>>>> marker. An alternate style, "diff3", adds a ||||||| marker and the original text before the ======= marker.
merge.defaultToUpstream If merge is called without any commit argument, merge the upstream branches configured for the current branch by using their last observed values stored in their remote-tracking branches. The values of the branch.<current branch>.merge that name the branches at the remote named by branch.<current branch>.remote are consulted, and then they are mapped via remote.<remote>.fetch to their corresponding remote-tracking branches, and the tips of these tracking branches are merged. Defaults to true.
merge.ff By default, Git does not create an extra merge commit when merging a commit that is a descendant of the current commit. Instead, the tip of the current branch is fast-forwarded. When set to false, this variable tells Git to create an extra merge commit in such a case (equivalent to giving the --no-ff option from the command line). When set to only, only such fast-forward merges are allowed (equivalent to giving the --ff-only option from the command line).
merge.verifySignatures If true, this is equivalent to the --verify-signatures command line option. See git-merge(1) for details.
merge.branchdesc In addition to branch names, populate the log message with the branch description text associated with them. Defaults to false.
merge.log In addition to branch names, populate the log message with at most the specified number of one-line descriptions from the actual commits that are being merged. Defaults to false, and true is a synonym for 20.
merge.suppressDest By adding a glob that matches the names of integration branches to this multi-valued configuration variable, the default merge message computed for merges into these integration branches will omit "into <branch name>" from its title.
An element with an empty value can be used to clear the list of globs accumulated from previous configuration entries. When there is no merge.suppressDest variable defined, the default value of master is used for backward compatibility.
merge.renameLimit The number of files to consider in the exhaustive portion of rename detection during a merge. If not specified, defaults to the value of diff.renameLimit. If neither merge.renameLimit nor diff.renameLimit are specified, currently defaults to 7000. This setting has no effect if rename detection is turned off.
merge.renames Whether Git detects renames. If set to "false", rename detection is disabled. If set to "true", basic rename detection is enabled. Defaults to the value of diff.renames.
merge.directoryRenames Whether Git detects directory renames, affecting what happens at merge time to new files added to a directory on one side of history when that directory was renamed on the other side of history. If merge.directoryRenames is set to "false", directory rename detection is disabled, meaning that such new files will be left behind in the old directory. If set to "true", directory rename detection is enabled, meaning that such new files will be moved into the new directory. If set to "conflict", a conflict will be reported for such paths. If merge.renames is false, merge.directoryRenames is ignored and treated as false. Defaults to "conflict".
merge.renormalize Tell Git that canonical representation of files in the repository has changed over time (e.g. earlier commits record text files with CRLF line endings, but recent ones use LF line endings). In such a repository, Git can convert the data recorded in commits to a canonical form before performing a merge to reduce unnecessary conflicts. For more information, see section "Merging branches with differing checkin/checkout attributes" in gitattributes(5).
merge.stat Whether to print the diffstat between ORIG_HEAD and the merge result at the end of the merge. True by default.
merge.autoStash When set to true, automatically create a temporary stash entry before the operation begins, and apply it after the operation ends. This means that you can run merge on a dirty worktree. However, use with care: the final stash application after a successful merge might result in non-trivial conflicts. This option can be overridden by the --no-autostash and --autostash options of git-merge(1). Defaults to false.
merge.tool Controls which merge tool is used by git-mergetool(1). The list below shows the valid built-in values. Any other value is treated as a custom merge tool and requires that a corresponding mergetool.<tool>.cmd variable is defined.
merge.guitool Controls which merge tool is used by git-mergetool(1) when the -g/--gui flag is specified. The list below shows the valid built-in values. Any other value is treated as a custom merge tool and requires that a corresponding mergetool.<guitool>.cmd variable is defined.
•   araxis
•   bc
•   bc3
•   bc4
•   codecompare
•   deltawalker
•   diffmerge
•   diffuse
•   ecmerge
•   emerge
•   examdiff
•   guiffy
•   gvimdiff
•   gvimdiff1
•   gvimdiff2
•   gvimdiff3
•   kdiff3
•   meld
•   nvimdiff
•   nvimdiff1
•   nvimdiff2
•   nvimdiff3
•   opendiff
•   p4merge
•   smerge
•   tkdiff
•   tortoisemerge
•   vimdiff
•   vimdiff1
•   vimdiff2
•   vimdiff3
•   winmerge
•   xxdiff
merge.verbosity Controls the amount of output shown by the recursive merge strategy. Level 0 outputs nothing except a final error message if conflicts were detected. Level 1 outputs only conflicts, 2 outputs conflicts and file changes. Level 5 and above outputs debugging information. The default is level 2. Can be overridden by the GIT_MERGE_VERBOSITY environment variable.
merge.<driver>.name Defines a human-readable name for a custom low-level merge driver. See gitattributes(5) for details.
merge.<driver>.driver Defines the command that implements a custom low-level merge driver. See gitattributes(5) for details.
merge.<driver>.recursive Names a low-level merge driver to be used when performing an internal merge between common ancestors. See gitattributes(5) for details.
branch.<name>.mergeOptions Sets default options for merging into branch <name>. The syntax and supported options are the same as those of git merge, but option values containing whitespace characters are currently not supported.
git-fmt-merge-msg(1), git-pull(1), gitattributes(5), git-reset(1), git- diff(1), git-ls-files(1), git-add(1), git-rm(1), git-mergetool(1)
GIT-BISECT(1)                      Git Manual                      GIT-BISECT(1)
git-bisect - Use binary search to find the commit that introduced a bug
git bisect <subcommand> <options>
git bisect start [--term-{new,bad}=<term> --term-{old,good}=<term>] [--no-checkout] [--first-parent] [<bad> [<good>...]] [--] [<paths>...] git bisect (bad|new|<term-new>) [<rev>] git bisect (good|old|<term-old>) [<rev>...] git bisect terms [--term-good | --term-bad] git bisect skip [(<rev>|<range>)...] git bisect reset [<commit>] git bisect (visualize|view) git bisect replay <logfile> git bisect log git bisect run <cmd>... git bisect help
This command uses a binary search algorithm to find which commit in your project’s history introduced a bug. You use it by first telling it a "bad" commit that is known to contain the bug, and a "good" commit that is known to be before the bug was introduced. Then git bisect picks a commit between those two endpoints and asks you whether the selected commit is "good" or "bad". It continues narrowing down the range until it finds the exact commit that introduced the change.
In fact, git bisect can be used to find the commit that changed any property of your project; e.g., the commit that fixed a bug, or the commit that caused a benchmark’s performance to improve. To support this more general usage, the terms "old" and "new" can be used in place of "good" and "bad", or you can choose your own terms. See section "Alternate terms" below for more information.
Basic bisect commands: start, bad, good As an example, suppose you are trying to find the commit that broke a feature that was known to work in version v2.6.13-rc2 of your project. You start a bisect session as follows:
$ git bisect start $ git bisect bad                 # Current version is bad $ git bisect good v2.6.13-rc2    # v2.6.13-rc2 is known to be good
Once you have specified at least one bad and one good commit, git bisect selects a commit in the middle of that range of history, checks it out, and outputs something similar to the following:
Bisecting: 675 revisions left to test after this (roughly 10 steps)
You should now compile the checked-out version and test it. If that version works correctly, type
$ git bisect good
If that version is broken, type
$ git bisect bad
Then git bisect will respond with something like
Bisecting: 337 revisions left to test after this (roughly 9 steps)
Keep repeating the process: compile the tree, test it, and depending on whether it is good or bad run git bisect good or git bisect bad to ask for the next commit that needs testing.
Eventually there will be no more revisions left to inspect, and the command will print out a description of the first bad commit. The reference refs/bisect/bad will be left pointing at that commit.
Bisect reset After a bisect session, to clean up the bisection state and return to the original HEAD, issue the following command:
$ git bisect reset
By default, this will return your tree to the commit that was checked out before git bisect start. (A new git bisect start will also do that, as it cleans up the old bisection state.)
With an optional argument, you can return to a different commit instead:
$ git bisect reset <commit>
For example, git bisect reset bisect/bad will check out the first bad revision, while git bisect reset HEAD will leave you on the current bisection commit and avoid switching commits at all.
Alternate terms Sometimes you are not looking for the commit that introduced a breakage, but rather for a commit that caused a change between some other "old" state and "new" state. For example, you might be looking for the commit that introduced a particular fix. Or you might be looking for the first commit in which the source-code filenames were finally all converted to your company’s naming standard. Or whatever.
In such cases it can be very confusing to use the terms "good" and "bad" to refer to "the state before the change" and "the state after the change". So instead, you can use the terms "old" and "new", respectively, in place of "good" and "bad". (But note that you cannot mix "good" and "bad" with "old" and "new" in a single session.)
In this more general usage, you provide git bisect with a "new" commit that has some property and an "old" commit that doesn’t have that property. Each time git bisect checks out a commit, you test if that commit has the property. If it does, mark the commit as "new"; otherwise, mark it as "old". When the bisection is done, git bisect will report which commit introduced the property.
To use "old" and "new" instead of "good" and bad, you must run git bisect start without commits as argument and then run the following commands to add the commits:
git bisect old [<rev>]
to indicate that a commit was before the sought change, or
git bisect new [<rev>...]
to indicate that it was after.
To get a reminder of the currently used terms, use
git bisect terms
You can get just the old (respectively new) term with git bisect terms --term-old or git bisect terms --term-good.
If you would like to use your own terms instead of "bad"/"good" or "new"/"old", you can choose any names you like (except existing bisect subcommands like reset, start, ...) by starting the bisection using
git bisect start --term-old <term-old> --term-new <term-new>
For example, if you are looking for a commit that introduced a performance regression, you might use
git bisect start --term-old fast --term-new slow
Or if you are looking for the commit that fixed a bug, you might use
git bisect start --term-new fixed --term-old broken
Then, use git bisect <term-old> and git bisect <term-new> instead of git bisect good and git bisect bad to mark commits.
Bisect visualize/view To see the currently remaining suspects in gitk, issue the following command during the bisection process (the subcommand view can be used as an alternative to visualize):
$ git bisect visualize
If the DISPLAY environment variable is not set, git log is used instead. You can also give command-line options such as -p and --stat.
$ git bisect visualize --stat
Bisect log and bisect replay After having marked revisions as good or bad, issue the following command to show what has been done so far:
$ git bisect log
If you discover that you made a mistake in specifying the status of a revision, you can save the output of this command to a file, edit it to remove the incorrect entries, and then issue the following commands to return to a corrected state:
$ git bisect reset $ git bisect replay that-file
Avoiding testing a commit If, in the middle of a bisect session, you know that the suggested revision is not a good one to test (e.g. it fails to build and you know that the failure does not have anything to do with the bug you are chasing), you can manually select a nearby commit and test that one instead.
$ git bisect good/bad                   # previous round was good or bad. Bisecting: 337 revisions left to test after this (roughly 9 steps) $ git bisect visualize                  # oops, that is uninteresting. $ git reset --hard HEAD~3               # try 3 revisions before what # was suggested
Then compile and test the chosen revision, and afterwards mark the revision as good or bad in the usual manner.
Bisect skip Instead of choosing a nearby commit by yourself, you can ask Git to do it for you by issuing the command:
$ git bisect skip                 # Current version cannot be tested
However, if you skip a commit adjacent to the one you are looking for, Git will be unable to tell exactly which of those commits was the first bad one.
You can also skip a range of commits, instead of just one commit, using range notation. For example:
$ git bisect skip v2.5..v2.6
This tells the bisect process that no commit after v2.5, up to and including v2.6, should be tested.
Note that if you also want to skip the first commit of the range you would issue the command:
$ git bisect skip v2.5 v2.5..v2.6
This tells the bisect process that the commits between v2.5 and v2.6 (inclusive) should be skipped.
Cutting down bisection by giving more parameters to bisect start You can further cut down the number of trials, if you know what part of the tree is involved in the problem you are tracking down, by specifying path parameters when issuing the bisect start command:
$ git bisect start -- arch/i386 include/asm-i386
If you know beforehand more than one good commit, you can narrow the bisect space down by specifying all of the good commits immediately after the bad commit when issuing the bisect start command:
$ git bisect start v2.6.20-rc6 v2.6.20-rc4 v2.6.20-rc1 -- # v2.6.20-rc6 is bad # v2.6.20-rc4 and v2.6.20-rc1 are good
Bisect run If you have a script that can tell if the current source code is good or bad, you can bisect by issuing the command:
$ git bisect run my_script arguments
Note that the script (my_script in the above example) should exit with code 0 if the current source code is good/old, and exit with a code between 1 and 127 (inclusive), except 125, if the current source code is bad/new.
Any other exit code will abort the bisect process. It should be noted that a program that terminates via exit(-1) leaves $? = 255, (see the exit(3) manual page), as the value is chopped with & 0377.
The special exit code 125 should be used when the current source code cannot be tested. If the script exits with this code, the current revision will be skipped (see git bisect skip above). 125 was chosen as the highest sensible value to use for this purpose, because 126 and 127 are used by POSIX shells to signal specific error status (127 is for command not found, 126 is for command found but not executable—these details do not matter, as they are normal errors in the script, as far as bisect run is concerned).
You may often find that during a bisect session you want to have temporary modifications (e.g. s/#define DEBUG 0/#define DEBUG 1/ in a header file, or "revision that does not have this commit needs this patch applied to work around another problem this bisection is not interested in") applied to the revision being tested.
To cope with such a situation, after the inner git bisect finds the next revision to test, the script can apply the patch before compiling, run the real test, and afterwards decide if the revision (possibly with the needed patch) passed the test and then rewind the tree to the pristine state. Finally the script should exit with the status of the real test to let the git bisect run command loop determine the eventual outcome of the bisect session.
--no-checkout Do not checkout the new working tree at each iteration of the bisection process. Instead just update a special reference named BISECT_HEAD to make it point to the commit that should be tested.
This option may be useful when the test you would perform in each step does not require a checked out tree.
If the repository is bare, --no-checkout is assumed.
--first-parent Follow only the first parent commit upon seeing a merge commit.
In detecting regressions introduced through the merging of a branch, the merge commit will be identified as introduction of the bug and its ancestors will be ignored.
This option is particularly useful in avoiding false positives when a merged branch contained broken or non-buildable commits, but the merge itself was OK.
•   Automatically bisect a broken build between v1.2 and HEAD:
$ git bisect start HEAD v1.2 --      # HEAD is bad, v1.2 is good $ git bisect run make                # "make" builds the app $ git bisect reset                   # quit the bisect session
•   Automatically bisect a test failure between origin and HEAD:
$ git bisect start HEAD origin --    # HEAD is bad, origin is good $ git bisect run make test           # "make test" builds and tests $ git bisect reset                   # quit the bisect session
•   Automatically bisect a broken test case:
$ cat ~/test.sh #!/bin/sh make || exit 125                     # this skips broken builds ~/check_test_case.sh                 # does the test case pass? $ git bisect start HEAD HEAD~10 --   # culprit is among the last 10 $ git bisect run ~/test.sh $ git bisect reset                   # quit the bisect session
Here we use a test.sh custom script. In this script, if make fails, we skip the current commit.  check_test_case.sh should exit 0 if the test case passes, and exit 1 otherwise.
It is safer if both test.sh and check_test_case.sh are outside the repository to prevent interactions between the bisect, make and test processes and the scripts.
•   Automatically bisect with temporary modifications (hot-fix):
$ cat ~/test.sh #!/bin/sh
# tweak the working tree by merging the hot-fix branch # and then attempt a build if      git merge --no-commit --no-ff hot-fix && make then # run project specific test and report its status ~/check_test_case.sh status=$? else # tell the caller this is untestable status=125 fi
# undo the tweak to allow clean flipping to the next commit git reset --hard
# return control exit $status
This applies modifications from a hot-fix branch before each test run, e.g. in case your build or test environment changed so that older revisions may need a fix which newer ones have already. (Make sure the hot-fix branch is based off a commit which is contained in all revisions which you are bisecting, so that the merge does not pull in too much, or use git cherry-pick instead of git merge.)
$ git bisect start HEAD HEAD~10 --   # culprit is among the last 10 $ git bisect run sh -c "make || exit 125; ~/check_test_case.sh" $ git bisect reset                   # quit the bisect session
This shows that you can do without a run script if you write the test on a single line.
•   Locate a good region of the object graph in a damaged repository
$ git bisect start HEAD <known-good-commit> [ <boundary-commit> ... ] --no-checkout $ git bisect run sh -c ' GOOD=$(git for-each-ref "--format=%(objectname)" refs/bisect/good-*) && git rev-list --objects BISECT_HEAD --not $GOOD >tmp.$$ && git pack-objects --stdout >/dev/null <tmp.$$ rc=$? rm -f tmp.$$ test $rc = 0'
$ git bisect reset                   # quit the bisect session
In this case, when git bisect run finishes, bisect/bad will refer to a commit that has at least one parent whose reachable graph is fully traversable in the sense required by git pack objects.
•   Look for a fix instead of a regression in the code
$ git bisect start $ git bisect new HEAD    # current commit is marked as new $ git bisect old HEAD~10 # the tenth commit from now is marked as old
$ git bisect start --term-old broken --term-new fixed $ git bisect fixed $ git bisect broken HEAD~10
Getting help Use git bisect to get a short usage description, and git bisect help or git bisect -h to get a long usage description.
Fighting regressions with git bisect[1], git-blame(1).
1. Fighting regressions with git bisect file:///usr/share/doc/git-doc/git-bisect-lk2009.html
MKE2FS(8)                    System Manager's Manual                   MKE2FS(8)
mke2fs - create an ext2/ext3/ext4 file system
mke2fs [ -c | -l filename ] [ -b block-size ] [ -C cluster-size ] [ -d root-directory ] [ -D ] [ -g blocks-per-group ] [ -G number-of-groups ] [ -i bytes-per-inode ] [ -I inode-size ] [ -j ] [ -J journal-options ] [ -N number-of-inodes ] [ -n ] [ -m reserved-blocks-percentage ] [ -o creator- os ] [ -O [^]feature[,...]  ] [ -q ] [ -r fs-revision-level ] [ -E extended-options ] [ -v ] [ -F ] [ -L volume-label ] [ -M last-mounted- directory ] [ -S ] [ -t fs-type ] [ -T usage-type ] [ -U UUID ] [ -V ] [ -e errors-behavior ] [ -z undo_file ] device [ fs-size ]
mke2fs -O journal_dev [ -b block-size ] [ -L volume-label ] [ -n ] [ -q ] [ -v ] external-journal [ fs-size ]
mke2fs is used to create an ext2, ext3, or ext4 file system, usually in a disk partition (or file) named by device.
The file system size is specified by fs-size.  If fs-size does not have a suffix, it is interpreted as power-of-two kilobytes, unless the -b blocksize option is specified, in which case fs-size is interpreted as the number of blocksize blocks.   If the fs-size is suffixed by 'k', 'm', 'g', 't' (either upper-case or lower-case), then it is interpreted in power-of-two kilobytes, megabytes, gigabytes, terabytes, etc.  If fs-size is omitted, mke2fs will create the file system based on the device size.
If mke2fs is run as mkfs.XXX (i.e., mkfs.ext2, mkfs.ext3, or mkfs.ext4) the option -t XXX is implied; so mkfs.ext3 will create a file system for use with ext3, mkfs.ext4 will create a file system for use with ext4, and so on.
The defaults of the parameters for the newly created file system, if not overridden by the options listed below, are controlled by the /etc/mke2fs.conf configuration file.  See the mke2fs.conf(5) manual page for more details.
-b block-size Specify the size of blocks in bytes.  Valid block-size values are powers of two from 1024 up to 65536 (however note that the kernel is able to mount only file systems with block-size smaller or equal to the system page size - 4k on x86 systems, up to 64k on ppc64 or aarch64 depending on kernel configuration).  If omitted, block-size is heuristically determined by the file system size and the expected usage of the file system (see the -T option).  In most common cases, the default block size is 4k. If block-size is preceded by a negative sign ('-'), then mke2fs will use heuristics to determine the appropriate block size, with the constraint that the block size will be at least block-size bytes.  This is useful for certain hardware devices which require that the blocksize be a multiple of 2k.
-c     Check the device for bad blocks before creating the file system. If this option is specified twice, then a slower read-write test is used instead of a fast read-only test.
-C  cluster-size Specify the size of cluster in bytes for file systems using the bigalloc feature.  Valid cluster-size values are from 2048 to 256M bytes per cluster.  This can only be specified if the bigalloc feature is enabled.  (See the ext4 (5) man page for more details about bigalloc.)   The default cluster size if bigalloc is enabled is 16 times the block size.
-d root-directory Copy the contents of the given directory into the root directory of the file system.
-D     Use direct I/O when writing to the disk.  This avoids mke2fs dirtying a lot of buffer cache memory, which may impact other applications running on a busy server.  This option will cause mke2fs to run much more slowly, however, so there is a tradeoff to using direct I/O.
-E extended-options Set extended options for the file system.  Extended options are comma separated, and may take an argument using the equals ('=') sign.  The -E option used to be -R in earlier versions of mke2fs. The -R option is still accepted for backwards compatibility, but is deprecated.  The following extended options are supported:
encoding=encoding-name Enable the casefold feature in the super block and set encoding-name as the encoding to be used.  If encoding-name is not specified, the encoding defined in mke2fs.conf(5) is used.
encoding_flags=encoding-flags Define parameters for file name character encoding operations.  If a flag is not changed using this parameter, its default value is used.  encoding-flags should be a comma-separated lists of flags to be enabled.  To disable a flag, add it to the list with the prefix "no".
stride=stride-size Configure the file system for a RAID array with stride-size file system blocks. This is the number of blocks read or written to disk before moving to the next disk, which is sometimes referred to as the chunk size.  This mostly affects placement of file system metadata like bitmaps at mke2fs time to avoid placing them on a single disk, which can hurt performance.  It may also be used by the block allocator.
stripe_width=stripe-width Configure the file system for a RAID array with stripe-width file system blocks per stripe. This is typically stride-size * N, where N is the number of data-bearing disks in the RAID (e.g. for RAID 5 there is one parity disk, so N will be the number of disks in the array minus 1).  This allows the block allocator to prevent read-modify-write of the parity in a RAID stripe if possible when the data is written.
offset=offset Create the file system at an offset from the beginning of the device or file.  This can be useful when creating disk images for virtual machines.
resize=max-online-resize Reserve enough space so that the block group descriptor table can grow to support a file system that has max-online-resize blocks.
lazy_itable_init[= <0 to disable, 1 to enable>] If enabled and the uninit_bg feature is enabled, the inode table will not be fully initialized by mke2fs. This speeds up file system initialization noticeably, but it requires the kernel to finish initializing the file system in the background when the file system is first mounted.  If the option value is omitted, it defaults to 1 to enable lazy inode table zeroing.
lazy_journal_init[= <0 to disable, 1 to enable>] If enabled, the journal inode will not be fully zeroed out by mke2fs.  This speeds up file system initialization noticeably, but carries some small risk if the system crashes before the journal has been overwritten entirely one time.  If the option value is omitted, it defaults to 1 to enable lazy journal inode zeroing.
no_copy_xattrs Normally mke2fs will copy the extended attributes of the files in the directory hierarchy specified via the (optional) -d option.  This will disable the copy and leaves the files in the newly created file system without any extended attributes.
num_backup_sb=<0|1|2> If the sparse_super2 file system feature is enabled this option controls whether there will be 0, 1, or 2 backup superblocks created in the file system.
packed_meta_blocks[= <0 to disable, 1 to enable>] Place the allocation bitmaps and the inode table at the beginning of the disk.  This option requires that the flex_bg file system feature to be enabled in order for it to have effect, and will also create the journal at the beginning of the file system.  This option is useful for flash devices that use SLC flash at the beginning of the disk.  It also maximizes the range of contiguous data blocks, which can be useful for certain specialized use cases, such as supported Shingled Drives.
root_owner[=uid:gid] Specify the numeric user and group ID of the root directory.  If no UID:GID is specified, use the user and group ID of the user running mke2fs.  In mke2fs 1.42 and earlier the UID and GID of the root directory were set by default to the UID and GID of the user running the mke2fs command.  The root_owner= option allows explicitly specifying these values, and avoid side-effects for users that do not expect the contents of the file system to change based on the user running mke2fs.
discard Attempt to discard blocks at mkfs time (discarding blocks initially is useful on solid state devices and sparse / thin-provisioned storage). When the device advertises that discard also zeroes data (any subsequent read after the discard and before write returns zero), then mark all not-yet-zeroed inode tables as zeroed. This significantly speeds up file system initialization. This is set as default.
nodiscard Do not attempt to discard blocks at mkfs time.
quotatype Specify the which  quota types (usrquota, grpquota, prjquota) which should be enabled in the created file system.  The argument of this extended option should be a colon separated list.  This option has effect only if the quota feature is set.   The default quota types to be initialized if this option is not specified is both user and group quotas.  If the project feature is enabled that project quotas will be initialized as well.
-F     Force mke2fs to create a file system, even if the specified device is not a partition on a block special device, or if other parameters do not make sense.  In order to force mke2fs to create a file system even if the file system appears to be in use or is mounted (a truly dangerous thing to do), this option must be specified twice.
-g blocks-per-group Specify the number of blocks in a block group.  There is generally no reason for the user to ever set this parameter, as the default is optimal for the file system.  (For administrators who are creating file systems on RAID arrays, it is preferable to use the stride RAID parameter as part of the -E option rather than manipulating the number of blocks per group.)  This option is generally used by developers who are developing test cases.
If the bigalloc feature is enabled, the -g option will specify the number of clusters in a block group.
-G number-of-groups Specify the number of block groups that will be packed together to create a larger virtual block group (or "flex_bg group") in an ext4 file system.  This improves meta-data locality and performance on meta-data heavy workloads.  The number of groups must be a power of 2 and may only be specified if the flex_bg file system feature is enabled.
-i bytes-per-inode Specify the bytes/inode ratio.  mke2fs creates an inode for every bytes-per-inode bytes of space on the disk.  The larger the bytes- per-inode ratio, the fewer inodes will be created.  This value generally shouldn't be smaller than the blocksize of the file system, since in that case more inodes would be made than can ever be used.  Be warned that it is not possible to change this ratio on a file system after it is created, so be careful deciding the correct value for this parameter.  Note that resizing a file system changes the number of inodes to maintain this ratio.
-I inode-size Specify the size of each inode in bytes.  The inode-size value must be a power of 2 larger or equal to 128.  The larger the inode-size the more space the inode table will consume, and this reduces the usable space in the file system and can also negatively impact performance.  It is not possible to change this value after the file system is created.
The default inode size is controlled by the mke2fs.conf(5) file. In the mke2fs.conf file shipped with e2fsprogs, the default inode size is 256 bytes for most file systems, except for small file systems where the inode size will be 128 bytes.
-j     Create the file system with an ext3 journal.  If the -J option is not specified, the default journal parameters will be used to create an appropriately sized journal (given the size of the file system) stored within the file system.  Note that you must be using a kernel which has ext3 support in order to actually make use of the journal.
-J journal-options Create the ext3 journal using options specified on the command- line.  Journal options are comma separated, and may take an argument using the equals ('=')  sign.  The following journal options are supported:
size=journal-size Create an internal journal (i.e., stored inside the file system) of size journal-size megabytes.  The size of the journal must be at least 1024 file system blocks (i.e., 1MB if using 1k blocks, 4MB if using 4k blocks, etc.)  and may be no more than 10,240,000 file system blocks or half the total file system size (whichever is smaller)
device=external-journal Attach the file system to the journal block device located on external-journal.  The external journal must already have been created using the command
Note that external-journal must have been created with the same block size as the new file system.  In addition, while there is support for attaching multiple file systems to a single external journal, the Linux kernel and e2fsck(8) do not currently support shared external journals yet.
-l filename Read the bad blocks list from filename.  Note that the block numbers in the bad block list must be generated using the same block size as used by mke2fs.  As a result, the -c option to mke2fs is a much simpler and less error-prone method of checking a disk for bad blocks before formatting it, as mke2fs will automatically pass the correct parameters to the badblocks program.
-L new-volume-label Set the volume label for the file system to new-volume-label.  The maximum length of the volume label is 16 bytes.
-m reserved-blocks-percentage Specify the percentage of the file system blocks reserved for the super-user.  This avoids fragmentation, and allows root-owned daemons, such as syslogd(8), to continue to function correctly after non-privileged processes are prevented from writing to the file system.  The default percentage is 5%.
-M last-mounted-directory Set the last mounted directory for the file system.  This might be useful for the sake of utilities that key off of the last mounted directory to determine where the file system should be mounted.
-n     Causes mke2fs to not actually create a file system, but display what it would do if it were to create a file system.  This can be used to determine the location of the backup superblocks for a particular file system, so long as the mke2fs parameters that were passed when the file system was originally created are used again. (With the -n option added, of course!)
-N number-of-inodes Overrides the default calculation of the number of inodes that should be reserved for the file system (which is based on the number of blocks and the bytes-per-inode ratio).  This allows the user to specify the number of desired inodes directly.
-o creator-os Overrides the default value of the "creator operating system" field of the file system.  The creator field is set by default to the name of the OS the mke2fs executable was compiled for.
-O [^]feature[,...] Create a file system with the given features (file system options), overriding the default file system options.  The features that are enabled by default are specified by the base_features relation, either in the [defaults] section in the /etc/mke2fs.conf configuration file, or in the [fs_types] subsections for the usage types as specified by the -T option, further modified by the features relation found in the [fs_types] subsections for the file system and usage types.  See the mke2fs.conf(5) manual page for more details.  The file system type-specific configuration setting found in the [fs_types] section will override the global default found in [defaults].
The file system feature set will be further edited using either the feature set specified by this option, or if this option is not given, by the default_features relation for the file system type being created, or in the [defaults] section of the configuration file.
The file system feature set is comprised of a list of features, separated by commas, that are to be enabled.  To disable a feature, simply prefix the feature name with a caret ('^') character.  Features with dependencies will not be removed successfully.  The pseudo-file system feature "none" will clear all file system features.
For more information about the features which can be set, please see the manual page ext4(5).
-q     Quiet execution.  Useful if mke2fs is run in a script.
-r revision Set the file system revision for the new file system.  Note that 1.2 kernels only support revision 0 file systems.  The default is to create revision 1 file systems.
-S     Write superblock and group descriptors only.  This is an extreme measure to be taken only in the very unlikely case that all of the superblock and backup superblocks are corrupted, and a last-ditch recovery method is desired by experienced users.  It causes mke2fs to reinitialize the superblock and group descriptors, while not touching the inode table and the block and inode bitmaps.  The e2fsck program should be run immediately after this option is used, and there is no guarantee that any data will be salvageable. Due to the wide variety of possible options to mke2fs that affect the on-disk layout, it is critical to specify exactly the same format options, such as blocksize, fs-type, feature flags, and other tunables when using this option, or the file system will be further corrupted.  In some cases, such as file systems that have been resized, or have had features enabled after format time, it is impossible to overwrite all of the superblocks correctly, and at least some file system corruption will occur.  It is best to run this on a full copy of the file system so other options can be tried if this doesn't work.
-t fs-type Specify the file system type (i.e., ext2, ext3, ext4, etc.) that is to be created.  If this option is not specified, mke2fs will pick a default either via how the command was run (for example, using a name of the form mkfs.ext2, mkfs.ext3, etc.) or via a default as defined by the /etc/mke2fs.conf file.   This option controls which file system options are used by default, based on the fstypes configuration stanza in /etc/mke2fs.conf.
If the -O option is used to explicitly add or remove file system options that should be set in the newly created file system, the resulting file system may not be supported by the requested fs- type.  (e.g., "mke2fs -t ext3 -O extent /dev/sdXX" will create a file system that is not supported by the ext3 implementation as found in the Linux kernel; and "mke2fs -t ext3 -O ^has_journal /dev/hdXX" will create a file system that does not have a journal and hence will not be supported by the ext3 file system code in the Linux kernel.)
-T usage-type[,...] Specify how the file system is going to be used, so that mke2fs can choose optimal file system parameters for that use.  The usage types that are supported are defined in the configuration file /etc/mke2fs.conf.  The user may specify one or more usage types using a comma separated list.
If this option is is not specified, mke2fs will pick a single default usage type based on the size of the file system to be created.  If the file system size is less than 3 megabytes, mke2fs will use the file system type floppy.  If the file system size is greater than or equal to 3 but less than 512 megabytes, mke2fs(8) will use the file system type small.  If the file system size is greater than or equal to 4 terabytes but less than 16 terabytes, mke2fs(8) will use the file system type big.  If the file system size is greater than or equal to 16 terabytes, mke2fs(8) will use the file system type huge.  Otherwise, mke2fs(8) will use the default file system type default.