summaryrefslogtreecommitdiff
path: root/Documentation/git-replace.txt
AgeCommit message (Collapse)AuthorFilesLines
2019-09-05Recommend git-filter-repo instead of git-filter-branchLibravatar Elijah Newren1-5/+5
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>
2018-04-30replace: introduce --convert-graft-fileLibravatar Johannes Schindelin1-3/+8
This option is intended to help with the transition away from the now-deprecated graft file. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2016-06-08doc: change environment variables formatLibravatar Tom Russello1-1/+1
This change GIT_* variables that where in italic style to monospaced font according to the guideline. It was obtained with perl -pi -e "s/\'(GIT_.*?)\'/\`\1\`/g" *.txt One of the main purposes is to stick to the CodingGuidelines as possible so that people writting new documentation by mimicking the existing are more likely to have it right (even if they didn't read the CodingGuidelines). Signed-off-by: Tom Russello <tom.russello@grenoble-inp.org> Signed-off-by: Erwan Mathoniere <erwan.mathoniere@grenoble-inp.org> Signed-off-by: Samuel Groot <samuel.groot@grenoble-inp.org> Signed-off-by: Matthieu Moy <matthieu.moy@grenoble-inp.fr> Reviewed-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-27Merge branch 'cc/replace-graft'Libravatar Junio C Hamano1-0/+10
"git replace" learned a "--graft" option to rewrite parents of a commit. * cc/replace-graft: replace: add test for --graft with a mergetag replace: check mergetags when using --graft replace: add test for --graft with signed commit replace: remove signature when using --graft contrib: add convert-grafts-to-replace-refs.sh Documentation: replace: add --graft option replace: add test for --graft replace: add --graft option replace: cleanup redirection style in tests
2014-07-21contrib: add convert-grafts-to-replace-refs.shLibravatar Christian Couder1-1/+3
This patch adds into contrib/ an example script to convert grafts from an existing grafts file into replace refs using the new --graft option of "git replace". While at it let's mention this new script in the "git replace" documentation for the --graft option. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-07-21Documentation: replace: add --graft optionLibravatar Christian Couder1-0/+8
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-06-25replace: add a --raw mode for --editLibravatar Jeff King1-0/+8
One of the purposes of "git replace --edit" is to help a user repair objects which are malformed or corrupted. Usually we pretty-print trees with "ls-tree", which is much easier to work with than the raw binary data. However, some forms of corruption break the tree-walker, in which case our pretty-printing fails, rendering "--edit" useless for the user. This patch introduces a "--raw" option, which lets you edit the binary data in these instances. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2014-05-19Documentation: replace: describe new --edit optionLibravatar Christian Couder1-1/+15
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-30replace info: rename 'full' to 'long' and clarify in-code symbolsLibravatar Christian Couder1-2/+2
Enum names SHORT/MEDIUM/FULL were too broad to be descriptive. And they clashed with built-in symbols on platforms like Windows. Clarify by giving them REPLACE_FORMAT_ prefix. Rename 'full' format in "git replace --format=<name>" to 'long', to match others (i.e. 'short' and 'medium'). Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-12-12Documentation/git-replace: describe --format optionLibravatar Christian Couder1-1/+18
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-09Doc: 'replace' merge and non-merge commitsLibravatar Philip Oakley1-0/+1
Merges are often treated as special case objects so tell users that they are not special here. Signed-off-by: Philip Oakley <philipoakley@iee.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-06replace: allow long option namesLibravatar Christian Couder1-0/+3
It is now standard practice in Git to have both short and long option names. So let's give a long option name to the git replace options too. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-06Documentation/replace: add Creating Replacement Objects sectionLibravatar Christian Couder1-0/+16
There were no hints in the documentation about how to create replacement objects. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-09-06Documentation/replace: state that objects must be of the same typeLibravatar Christian Couder1-3/+6
A previous patch ensures that both the replaced and the replacement objects passed to git replace must be of the same type, except if -f option is used. While at it state that there is no other restriction on both objects. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-04-15The name of the hash function is "SHA-1", not "SHA1"Libravatar Thomas Ackermann1-2/+2
Use "SHA-1" instead of "SHA1" whenever we talk about the hash function. When used as a programming symbol, we keep "SHA1". Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2013-02-01Documentation: the name of the system is 'Git', not 'git'Libravatar Thomas Ackermann1-1/+1
Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2012-08-06Documentation: do not mention .git/refs/* directoriesLibravatar Junio C Hamano1-3/+2
It is an implementation detail that a new tag is created by adding a file in the .git/refs/tags directory. The only thing the user needs to know is that a "git tag" creates a ref in the refs/tags namespace, and without "-f", it does not overwrite an existing tag. Inspired by a report from 乙酸鋰 <ch3cooli@gmail.com>; I think I caught all the existing mention in Documentation/ directory in the tip of 1.7.9.X maintenance track, but we may have added new ones since then. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2011-03-11doc: drop author/documentation sections from most pagesLibravatar Jeff King1-11/+0
The point of these sections is generally to: 1. Give credit where it is due. 2. Give the reader an idea of where to ask questions or file bug reports. But they don't do a good job of either case. For (1), they are out of date and incomplete. A much more accurate answer can be gotten through shortlog or blame. For (2), the correct contact point is generally git@vger, and even if you wanted to cc the contact point, the out-of-date and incomplete fields mean you're likely sending to somebody useless. So let's drop the fields entirely from all manpages except git(1) itself. We already point people to the mailing list for bug reports there, and we can update the Authors section to give credit to the major contributors and point to shortlog and blame for more information. Each page has a "This is part of git" footer, so people can follow that to the main git manpage.
2010-01-10Documentation: format full commands in typewriter fontLibravatar Thomas Rast1-1/+1
Use `code snippet` style instead of 'emphasis' for `git cmd ...` according to the following rules: * The SYNOPSIS sections are left untouched. * If the intent is that the user type the command exactly as given, it is `code`. If the user is only loosely referred to a command and/or option, it remains 'emphasised'. Signed-off-by: Thomas Rast <trast@student.ethz.ch>
2009-11-20Documentation: talk a little bit about GIT_NO_REPLACE_OBJECTSLibravatar Christian Couder1-0/+3
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-11-20Documentation: fix typos and spelling in replace documentationLibravatar Christian Couder1-10/+11
This patch fix a missing "s" at the end of an occurence of "--no-replace-objects" and, while at it, it also improves spelling and rendering. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-10-13git: add --no-replace-objects option to disable replacingLibravatar Christian Couder1-0/+21
Commit dae556b (environment: add global variable to disable replacement) adds a variable to enable/disable replacement, and it is enabled by default for most commands. So there is no way to disable it for some commands, which is annoying when we want to get information about a commit that has been replaced. For example: $ git cat-file -p N would output information about the replacement commit if commit N is replaced. With the "--no-replace-objects" option that this patch adds it is possible to get information about the original commit using: $ git --no-replace-objects cat-file -p N While at it, let's add some documentation about this new option in the "git replace" man page too. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2009-05-31Documentation: add documentation for "git replace"Libravatar Christian Couder1-0/+71
Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>