Login or Register to Ask a Question and Join Our Community

Linux and UNIX Man Pages

Linux & Unix Commands - Search Man Pages

git-replace(1) [suse man page]

GIT-REPLACE(1)							    Git Manual							    GIT-REPLACE(1)

NAME

       git-replace - Create, list, delete refs to replace objects

SYNOPSIS

       git replace [-f] <object> <replacement>
       git replace -d <object>...
       git replace -l [<pattern>]

DESCRIPTION

       Adds a replace reference in .git/refs/replace/

       The name of the replace reference is the SHA1 of the object that is replaced. The content of the replace reference is the SHA1 of the
       replacement object.

       Unless -f is given, the replace reference must not yet exist in .git/refs/replace/ directory.

       Replacement references will be used by default by all git commands except those doing reachability traversal (prune, pack transfer and
       fsck).

       It is possible to disable use of replacement references for any command using the --no-replace-objects option just after git.

       For example if commit foo has been replaced by commit bar:

	   .ft C
	   $ git --no-replace-objects cat-file commit foo
	   .ft

       shows information about commit foo, while:

	   .ft C
	   $ git cat-file commit foo
	   .ft

       shows information about commit bar.

       The GIT_NO_REPLACE_OBJECTS environment variable can be set to achieve the same effect as the --no-replace-objects option.

OPTIONS

       -f
	   If an existing replace ref for the same object exists, it will be overwritten (instead of failing).

       -d
	   Delete existing replace refs for the given objects.

       -l <pattern>
	   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.

BUGS

       Comparing blobs or trees that have been replaced with those that replace them will not work properly. And using git reset --hard to 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 pending objects. And of course things may break if an object of one type is
       replaced by an object of another type (for example a blob replaced by a commit).

SEE ALSO

       git-tag(1) git-branch(1) git(1)

AUTHOR

       Written by Christian Couder <chriscool@tuxfamily.org[1]> and Junio C Hamano <gitster@pobox.com[2]>, based on git tag by Kristian Hogsberg
       <krh@redhat.com[3]> and Carlos Rica <jasampler@gmail.com[4]>.

DOCUMENTATION

       Documentation by Christian Couder <chriscool@tuxfamily.org[1]> and the git-list <git@vger.kernel.org[5]>, based on git tag documentation.

GIT

       Part of the git(1) suite

NOTES

	1. chriscool@tuxfamily.org
	   mailto:chriscool@tuxfamily.org

	2. gitster@pobox.com
	   mailto:gitster@pobox.com

	3. krh@redhat.com
	   mailto:krh@redhat.com

	4. jasampler@gmail.com
	   mailto:jasampler@gmail.com

	5. git@vger.kernel.org
	   mailto:git@vger.kernel.org

Git 1.7.1							    07/05/2010							    GIT-REPLACE(1)

Check Out this Related Man Page

GIT-CHERRY(1)							    Git Manual							     GIT-CHERRY(1)

NAME

       git-cherry - Find commits not merged upstream

SYNOPSIS

       git cherry [-v] [<upstream> [<head> [<limit>]]]

DESCRIPTION

       The changeset (or "diff") of each commit between the fork-point and <head> is compared against each commit between the fork-point and
       <upstream>. The commits are compared with their patch id, obtained from the git patch-id program.

       Every commit that doesn't exist in the <upstream> branch has its id (sha1) reported, prefixed by a symbol. The ones that have equivalent
       change already in the <upstream> branch are prefixed with a minus (-) sign, and those that only exist in the <head> branch are prefixed
       with a plus (+) symbol:

		      __*__*__*__*__> <upstream>
		     /
	   fork-point
		     \__+__+__-__+__+__-__+__> <head>

       If a <limit> has been given then the commits along the <head> branch up to and including <limit> are not reported:

		      __*__*__*__*__> <upstream>
		     /
	   fork-point
		     \__*__*__<limit>__-__+__> <head>

       Because git cherry compares the changeset rather than the commit id (sha1), you can use git cherry to find out if a commit you made locally
       has been applied <upstream> under a different commit id. For example, this will happen if you're feeding patches <upstream> via email
       rather than pushing or pulling commits directly.

OPTIONS

       -v
	   Verbose.

       <upstream>
	   Upstream branch to compare against. Defaults to the first tracked remote branch, if available.

       <head>
	   Working branch; defaults to HEAD.

       <limit>
	   Do not report commits up to (and including) limit.

SEE ALSO

       git-patch-id(1)

AUTHOR

       Written by Junio C Hamano <gitster@pobox.com[1]>

DOCUMENTATION

       Documentation by Junio C Hamano and the git-list <git@vger.kernel.org[2]>.

GIT

       Part of the git(1) suite

NOTES

	1. gitster@pobox.com
	   mailto:gitster@pobox.com

	2. git@vger.kernel.org
	   mailto:git@vger.kernel.org

Git 1.7.1							    07/05/2010							     GIT-CHERRY(1)
Man Page