2009-04-14 00:36:59 +02:00
|
|
|
git-replace(1)
|
|
|
|
==============
|
|
|
|
|
|
|
|
NAME
|
|
|
|
----
|
|
|
|
git-replace - Create, list, delete refs to replace objects
|
|
|
|
|
|
|
|
SYNOPSIS
|
|
|
|
--------
|
|
|
|
[verse]
|
|
|
|
'git replace' [-f] <object> <replacement>
|
2014-05-17 14:16:39 +02:00
|
|
|
'git replace' [-f] --edit <object>
|
2014-07-19 17:01:10 +02:00
|
|
|
'git replace' [-f] --graft <commit> [<parent>...]
|
2018-04-29 00:44:35 +02:00
|
|
|
'git replace' [-f] --convert-graft-file
|
2009-04-14 00:36:59 +02:00
|
|
|
'git replace' -d <object>...
|
2013-12-11 08:46:13 +01:00
|
|
|
'git replace' [--format=<format>] [-l [<pattern>]]
|
2009-04-14 00:36:59 +02:00
|
|
|
|
|
|
|
DESCRIPTION
|
|
|
|
-----------
|
2012-08-06 22:36:47 +02:00
|
|
|
Adds a 'replace' reference in `refs/replace/` namespace.
|
2009-04-14 00:36:59 +02:00
|
|
|
|
2013-04-15 19:49:04 +02:00
|
|
|
The name of the 'replace' reference is the SHA-1 of the object that is
|
|
|
|
replaced. The content of the 'replace' reference is the SHA-1 of the
|
2009-04-14 00:36:59 +02:00
|
|
|
replacement object.
|
|
|
|
|
2013-09-06 07:10:54 +02:00
|
|
|
The replaced object and the replacement object must be of the same type.
|
|
|
|
This restriction can be bypassed using `-f`.
|
|
|
|
|
2012-08-06 22:36:47 +02:00
|
|
|
Unless `-f` is given, the 'replace' reference must not yet exist.
|
2009-04-14 00:36:59 +02:00
|
|
|
|
2013-09-06 07:10:54 +02:00
|
|
|
There is no other restriction on the replaced and replacement objects.
|
2013-09-08 14:10:44 +02:00
|
|
|
Merge commits can be replaced by non-merge commits and vice versa.
|
2013-09-06 07:10:54 +02:00
|
|
|
|
2013-01-21 20:17:53 +01:00
|
|
|
Replacement references will be used by default by all Git commands
|
2009-11-19 07:13:15 +01:00
|
|
|
except those doing reachability traversal (prune, pack transfer and
|
|
|
|
fsck).
|
2009-10-12 22:30:32 +02:00
|
|
|
|
2009-11-19 07:13:15 +01:00
|
|
|
It is possible to disable use of replacement references for any
|
|
|
|
command using the `--no-replace-objects` option just after 'git'.
|
2009-10-12 22:30:32 +02:00
|
|
|
|
2009-11-19 07:13:15 +01:00
|
|
|
For example if commit 'foo' has been replaced by commit 'bar':
|
2009-10-12 22:30:32 +02:00
|
|
|
|
|
|
|
------------------------------------------------
|
2009-11-19 07:13:15 +01:00
|
|
|
$ git --no-replace-objects cat-file commit foo
|
2009-10-12 22:30:32 +02:00
|
|
|
------------------------------------------------
|
|
|
|
|
2009-11-19 07:13:15 +01:00
|
|
|
shows information about commit 'foo', while:
|
2009-10-12 22:30:32 +02:00
|
|
|
|
|
|
|
------------------------------------------------
|
|
|
|
$ git cat-file commit foo
|
|
|
|
------------------------------------------------
|
|
|
|
|
2009-11-19 07:13:15 +01:00
|
|
|
shows information about commit 'bar'.
|
2009-10-12 22:30:32 +02:00
|
|
|
|
2016-06-08 00:35:06 +02:00
|
|
|
The `GIT_NO_REPLACE_OBJECTS` environment variable can be set to
|
2009-11-19 07:13:16 +01:00
|
|
|
achieve the same effect as the `--no-replace-objects` option.
|
|
|
|
|
2009-04-14 00:36:59 +02:00
|
|
|
OPTIONS
|
|
|
|
-------
|
|
|
|
-f::
|
2013-09-06 07:10:58 +02:00
|
|
|
--force::
|
2009-04-14 00:36:59 +02:00
|
|
|
If an existing replace ref for the same object exists, it will
|
|
|
|
be overwritten (instead of failing).
|
|
|
|
|
|
|
|
-d::
|
2013-09-06 07:10:58 +02:00
|
|
|
--delete::
|
2009-04-14 00:36:59 +02:00
|
|
|
Delete existing replace refs for the given objects.
|
|
|
|
|
2014-05-17 14:16:39 +02:00
|
|
|
--edit <object>::
|
|
|
|
Edit an object's content interactively. The existing content
|
|
|
|
for <object> is pretty-printed into a temporary file, an
|
|
|
|
editor is launched on the file, and the result is parsed to
|
|
|
|
create a new object of the same type as <object>. A
|
|
|
|
replacement ref is then created to replace <object> with the
|
|
|
|
newly created object. See linkgit:git-var[1] for details about
|
|
|
|
how the editor will be chosen.
|
|
|
|
|
2014-06-24 11:46:31 +02:00
|
|
|
--raw::
|
|
|
|
When editing, provide the raw object contents rather than
|
|
|
|
pretty-printed ones. Currently this only affects trees, which
|
|
|
|
will be shown in their binary form. This is harder to work with,
|
|
|
|
but can help when repairing a tree that is so corrupted it
|
|
|
|
cannot be pretty-printed. Note that you may need to configure
|
|
|
|
your editor to cleanly read and write binary data.
|
|
|
|
|
2014-07-19 17:01:10 +02:00
|
|
|
--graft <commit> [<parent>...]::
|
|
|
|
Create a graft commit. A new commit is created with the same
|
|
|
|
content as <commit> except that its parents will be
|
|
|
|
[<parent>...] instead of <commit>'s parents. A replacement ref
|
|
|
|
is then created to replace <commit> with the newly created
|
2018-04-29 00:44:35 +02:00
|
|
|
commit. Use `--convert-graft-file` to convert a
|
|
|
|
`$GIT_DIR/info/grafts` file and use replace refs instead.
|
|
|
|
|
|
|
|
--convert-graft-file::
|
|
|
|
Creates graft commits for all entries in `$GIT_DIR/info/grafts`
|
|
|
|
and deletes that file upon success. The purpose is to help users
|
|
|
|
with transitioning off of the now-deprecated graft file.
|
2014-07-19 17:01:10 +02:00
|
|
|
|
2009-04-14 00:36:59 +02:00
|
|
|
-l <pattern>::
|
2013-09-06 07:10:58 +02:00
|
|
|
--list <pattern>::
|
2009-04-14 00:36:59 +02:00
|
|
|
List replace refs for objects that match the given pattern (or
|
|
|
|
all if no pattern is given).
|
|
|
|
Typing "git replace" without arguments, also lists all replace
|
|
|
|
refs.
|
|
|
|
|
2013-12-11 08:46:13 +01:00
|
|
|
--format=<format>::
|
|
|
|
When listing, use the specified <format>, which can be one of
|
2013-12-28 12:00:05 +01:00
|
|
|
'short', 'medium' and 'long'. When omitted, the format
|
2013-12-11 08:46:13 +01:00
|
|
|
defaults to 'short'.
|
|
|
|
|
|
|
|
FORMATS
|
|
|
|
-------
|
|
|
|
|
|
|
|
The following format are available:
|
|
|
|
|
|
|
|
* 'short':
|
|
|
|
<replaced sha1>
|
|
|
|
* 'medium':
|
|
|
|
<replaced sha1> -> <replacement sha1>
|
2013-12-28 12:00:05 +01:00
|
|
|
* 'long':
|
2013-12-11 08:46:13 +01:00
|
|
|
<replaced sha1> (<replaced type>) -> <replacement sha1> (<replacement type>)
|
|
|
|
|
2013-09-06 07:10:57 +02:00
|
|
|
CREATING REPLACEMENT OBJECTS
|
|
|
|
----------------------------
|
|
|
|
|
Recommend git-filter-repo instead of git-filter-branch
filter-branch suffers from a deluge of disguised dangers that disfigure
history rewrites (i.e. deviate from the deliberate changes). Many of
these problems are unobtrusive and can easily go undiscovered until the
new repository is in use. This can result in problems ranging from an
even messier history than what led folks to filter-branch in the first
place, to data loss or corruption. These issues cannot be backward
compatibly fixed, so add a warning to both filter-branch and its manpage
recommending that another tool (such as filter-repo) be used instead.
Also, update other manpages that referenced filter-branch. Several of
these needed updates even if we could continue recommending
filter-branch, either due to implying that something was unique to
filter-branch when it applied more generally to all history rewriting
tools (e.g. BFG, reposurgeon, fast-import, filter-repo), or because
something about filter-branch was used as an example despite other more
commonly known examples now existing. Reword these sections to fix
these issues and to avoid recommending filter-branch.
Finally, remove the section explaining BFG Repo Cleaner as an
alternative to filter-branch. I feel somewhat bad about this,
especially since I feel like I learned so much from BFG that I put to
good use in filter-repo (which is much more than I can say for
filter-branch), but keeping that section presented a few problems:
* In order to recommend that people quit using filter-branch, we need
to provide them a recomendation for something else to use that
can handle all the same types of rewrites. To my knowledge,
filter-repo is the only such tool. So it needs to be mentioned.
* I don't want to give conflicting recommendations to users
* If we recommend two tools, we shouldn't expect users to learn both
and pick which one to use; we should explain which problems one
can solve that the other can't or when one is much faster than
the other.
* BFG and filter-repo have similar performance
* All filtering types that BFG can do, filter-repo can also do. In
fact, filter-repo comes with a reimplementation of BFG named
bfg-ish which provides the same user-interface as BFG but with
several bugfixes and new features that are hard to implement in
BFG due to its technical underpinnings.
While I could still mention both tools, it seems like I would need to
provide some kind of comparison and I would ultimately just say that
filter-repo can do everything BFG can, so ultimately it seems that it
is just better to remove that section altogether.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05 00:32:38 +02:00
|
|
|
linkgit:git-hash-object[1], linkgit:git-rebase[1], and
|
|
|
|
https://github.com/newren/git-filter-repo[git-filter-repo], among other git commands, can be used to
|
|
|
|
create replacement objects from existing objects. The `--edit` option
|
|
|
|
can also be used with 'git replace' to create a replacement object by
|
2014-05-17 14:16:39 +02:00
|
|
|
editing an existing object.
|
2013-09-06 07:10:57 +02:00
|
|
|
|
|
|
|
If you want to replace many blobs, trees or commits that are part of a
|
|
|
|
string of commits, you may just want to create a replacement string of
|
|
|
|
commits and then only replace the commit at the tip of the target
|
|
|
|
string of commits with the commit at the tip of the replacement string
|
|
|
|
of commits.
|
|
|
|
|
2009-04-14 00:36:59 +02:00
|
|
|
BUGS
|
|
|
|
----
|
|
|
|
Comparing blobs or trees that have been replaced with those that
|
2010-01-07 17:49:12 +01:00
|
|
|
replace them will not work properly. And using `git reset --hard` to
|
2009-04-14 00:36:59 +02:00
|
|
|
go back to a replaced commit will move the branch to the replacement
|
|
|
|
commit instead of the replaced commit.
|
|
|
|
|
|
|
|
There may be other problems when using 'git rev-list' related to
|
2013-09-06 07:10:54 +02:00
|
|
|
pending objects.
|
2009-04-14 00:36:59 +02:00
|
|
|
|
|
|
|
SEE ALSO
|
|
|
|
--------
|
2013-09-06 07:10:57 +02:00
|
|
|
linkgit:git-hash-object[1]
|
|
|
|
linkgit:git-rebase[1]
|
2009-04-14 00:36:59 +02:00
|
|
|
linkgit:git-tag[1]
|
|
|
|
linkgit:git-branch[1]
|
2014-05-17 14:16:39 +02:00
|
|
|
linkgit:git-commit[1]
|
|
|
|
linkgit:git-var[1]
|
2009-10-12 22:30:32 +02:00
|
|
|
linkgit:git[1]
|
Recommend git-filter-repo instead of git-filter-branch
filter-branch suffers from a deluge of disguised dangers that disfigure
history rewrites (i.e. deviate from the deliberate changes). Many of
these problems are unobtrusive and can easily go undiscovered until the
new repository is in use. This can result in problems ranging from an
even messier history than what led folks to filter-branch in the first
place, to data loss or corruption. These issues cannot be backward
compatibly fixed, so add a warning to both filter-branch and its manpage
recommending that another tool (such as filter-repo) be used instead.
Also, update other manpages that referenced filter-branch. Several of
these needed updates even if we could continue recommending
filter-branch, either due to implying that something was unique to
filter-branch when it applied more generally to all history rewriting
tools (e.g. BFG, reposurgeon, fast-import, filter-repo), or because
something about filter-branch was used as an example despite other more
commonly known examples now existing. Reword these sections to fix
these issues and to avoid recommending filter-branch.
Finally, remove the section explaining BFG Repo Cleaner as an
alternative to filter-branch. I feel somewhat bad about this,
especially since I feel like I learned so much from BFG that I put to
good use in filter-repo (which is much more than I can say for
filter-branch), but keeping that section presented a few problems:
* In order to recommend that people quit using filter-branch, we need
to provide them a recomendation for something else to use that
can handle all the same types of rewrites. To my knowledge,
filter-repo is the only such tool. So it needs to be mentioned.
* I don't want to give conflicting recommendations to users
* If we recommend two tools, we shouldn't expect users to learn both
and pick which one to use; we should explain which problems one
can solve that the other can't or when one is much faster than
the other.
* BFG and filter-repo have similar performance
* All filtering types that BFG can do, filter-repo can also do. In
fact, filter-repo comes with a reimplementation of BFG named
bfg-ish which provides the same user-interface as BFG but with
several bugfixes and new features that are hard to implement in
BFG due to its technical underpinnings.
While I could still mention both tools, it seems like I would need to
provide some kind of comparison and I would ultimately just say that
filter-repo can do everything BFG can, so ultimately it seems that it
is just better to remove that section altogether.
Signed-off-by: Elijah Newren <newren@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
2019-09-05 00:32:38 +02:00
|
|
|
https://github.com/newren/git-filter-repo[git-filter-repo]
|
2009-04-14 00:36:59 +02:00
|
|
|
|
|
|
|
GIT
|
|
|
|
---
|
|
|
|
Part of the linkgit:git[1] suite
|