summaryrefslogtreecommitdiff
path: root/Documentation/git-filter-branch.txt
Commit message (Collapse)AuthorAgeFilesLines
* filter-branch doc: fix filter-repo typoChristian Couder2020-10-201-1/+1
| | | | | | | | | The name of the tool is 'git-filter-repo' not 'git-repo-filter'. Signed-off-by: Christian Couder <chriscool@tuxfamily.org> Reviewed-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git-filter-branch.txt: wrap "maths" notation in backticksMartin Ågren2020-02-041-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | In this paragraph, we have a few instances of the '^' character, which we give as "\^". This renders well with AsciiDoc ("^"), but Asciidoctor renders it literally as "\^". Dropping the backslashes renders fine with Asciidoctor, but not AsciiDoc... An earlier version of this patch used "{caret}" instead of "^", which avoided these escaping problems. The rendering was still so-so, though -- these expressions end up set as normal text, similarly to when one provides, e.g., computer code in the middle of running text, without properly marking it with `backticks` to be monospaced. As noted by Jeff King, this suggests actually wrapping these expressions in backticks, setting them in monospace. The lone "5" could be left as is or wrapped as `5`. Spell it out as "five" instead -- this generally looks better anyway for small numbers in the middle of text like this. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ja/doc-markup-cleanup'Junio C Hamano2019-12-251-124/+133
|\ | | | | | | | | | | | | | | Doc cleanup. * ja/doc-markup-cleanup: doc: indent multi-line items in list doc: remove non pure ASCII characters
| * doc: indent multi-line items in listJean-Noël Avila2019-12-131-124/+133
| | | | | | | | | | | | | | | | Although Asciidoc allows to not indent following lines in a list item, it is clearer and safer to follow the recommended rule. Signed-off-by: Jean-Noël Avila <jn.avila@free.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Merge branch 'en/doc-typofix'Junio C Hamano2019-12-011-1/+1
|\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Docfix. * en/doc-typofix: Fix spelling errors in no-longer-updated-from-upstream modules multimail: fix a few simple spelling errors sha1dc: fix trivial comment spelling error Fix spelling errors in test commands Fix spelling errors in messages shown to users Fix spelling errors in names of tests Fix spelling errors in comments of testcases Fix spelling errors in code comments Fix spelling errors in documentation outside of Documentation/ Documentation: fix a bunch of typos, both old and new
| * | Documentation: fix a bunch of typos, both old and newElijah Newren2019-11-071-1/+1
| |/ | | | | | | | | | | Reported-by: Jens Schleusener <Jens.Schleusener@fossies.org> Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | git-filter-branch.txt: correct argument name typoElijah Newren2019-11-071-1/+1
|/ | | | | Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Recommend git-filter-repo instead of git-filter-branchElijah Newren2019-09-051-30/+243
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 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>
* doc: format pathnames and URLs as monospace.Corentin BOMPARD2019-03-131-1/+1
| | | | | | | | | | | | Applying CodingGuidelines about monospace on pathnames and URLs. See Documentation/CodingGuidelines.txt for more information. Signed-off-by: Corentin BOMPARD <corentin.bompard@etu.univ-lyon1.fr> Signed-off-by: Nathan BERBEZIER <nathan.berbezier@etu.univ-lyon1.fr> Signed-off-by: Pablo CHABANNE <pablo.chabanne@etu.univ-lyon1.fr> Signed-off-by: Matthieu MOY <matthieu.moy@univ-lyon1.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'nd/doc-header'Junio C Hamano2018-05-231-3/+3
|\ | | | | | | | | | | | | Doc formatting fix. * nd/doc-header: doc: keep first level section header in upper case
| * doc: keep first level section header in upper caseNguyễn Thái Ngọc Duy2018-05-021-3/+3
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When formatted as a man page, 1st section header is always in upper case even if we write it otherwise. Make all 1st section headers uppercase to keep it close to the final output. This does affect html since case is kept there, but I still think it's a good idea to maintain a consistent style for 1st section headers. Some sections perhaps should become second sections instead, where case is kept, and for better organization. I will update if anyone has suggestions about this. While at there I also make some header more consistent (e.g. examples vs example) and fix a couple minor things here and there. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | filter-branch: stop suggesting to use graftsJohannes Schindelin2018-04-301-1/+1
|/ | | | | | | | | The graft file is deprecated now, so let's use replace refs in the example in filter-branch's man page instead. Suggested-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* filter-branch: return 2 when nothing to rewriteml/filter-branch-no-op-errorMichele Locati2018-03-151-0/+8
| | | | | | | | | | Using the --state-branch option allows us to perform incremental filtering. This may lead to having nothing to rewrite in subsequent filtering, so we need a way to recognize this case. So, let's exit with 2 instead of 1 when this "error" occurs. Signed-off-by: Michele Locati <michele@locati.it> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'dg/filter-branch-filter-order-doc'Junio C Hamano2017-10-191-10/+10
|\ | | | | | | | | | | | | | | | | Update the documentation for "git filter-branch" so that the filter options are listed in the same order as they are applied, as described in an earlier part of the doc. * dg/filter-branch-filter-order-doc: doc: list filter-branch subdirectory-filter first
| * doc: list filter-branch subdirectory-filter firstdg/filter-branch-filter-order-docDavid Glasser2017-10-181-10/+10
| | | | | | | | | | | | | | | | | | | | | | | | | | The docs claim that filters are applied in the listed order, so subdirectory-filter should come first. For consistency, apply the same order to the SYNOPSIS and the script's usage, as well as the switch while parsing arguments. Add missing --prune-empty to the script's usage. Signed-off-by: David Glasser <glasser@davidglasser.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | filter-branch: stash away ref map in a branchIan Campbell2017-09-221-1/+7
|/ | | | | | | | | | With "--state-branch=<branchname>" option, the mapping from old object names and filtered ones in ./map/ directory is stashed away in the object database, and the one from the previous run is read to populate the ./map/ directory, allowing for incremental updates of large trees. Signed-off-by: Ian Campbell <ijc@hellion.org.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* filter-branch: add `--setup` stepAndreas Heiduk2017-06-121-5/+12
| | | | | | | | | | | A `--setup` step in `git filter-branch` makes it much easier to define the initial values of variables used in the real filters. Also sourcing/defining utility functions here instead of `--env-filter` improves performance and minimizes clogging the output in case of errors. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'ah/doc-filter-branch-export-env'Junio C Hamano2017-06-041-4/+1
|\ | | | | | | | | | | | | Docfix. * ah/doc-filter-branch-export-env: doc: filter-branch does not require re-export of vars
| * doc: filter-branch does not require re-export of varsah/doc-filter-branch-export-envAndreas Heiduk2017-05-291-4/+1
| | | | | | | | | | | | | | | | | | | | The function `set_ident` in `filter-branch` exported the variables GIT_(AUTHOR|COMMITTER)_(NAME|EMAIL|DATE) at least since 6f6826c52b in 2007. Therefore the filter scripts don't need to re-eport them again. Signed-off-by: Andreas Heiduk <asheiduk@gmail.com> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | filter-branch: fix --prune-empty on parentless commitsDevin J. Pohly2017-03-031-8/+6
|/ | | | | | | | | | | | | | | | Previously, the git_commit_non_empty_tree function would always pass any commit with no parents to git-commit-tree, regardless of whether the tree was nonempty. The new commit would then be recorded in the filter-branch revision map, and subsequent commits which leave the tree untouched would be correctly filtered. With this change, parentless commits with an empty tree are correctly pruned, and an empty file is recorded in the revision map, signifying that it was rewritten to "no commits." This works naturally with the parent mapping for subsequent commits. Signed-off-by: Devin J. Pohly <djpohly@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* doc: typeset '--' as literalMatthieu Moy2016-06-281-1/+1
| | | | | | | | | This was obtained with: perl -pi -e "s/'--'/\`--\`/g" *.txt Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* doc: typeset long command-line options as literalMatthieu Moy2016-06-281-2/+2
| | | | | | | | | | | | | | | Similarly to the previous commit, use backquotes instead of forward-quotes, for long options. This was obtained with: perl -pi -e "s/'(--[a-z][a-z=<>-]*)'/\`\$1\`/g" *.txt and manual tweak to remove false positive in ascii-art (o'--o'--o' to describe rewritten history). Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* doc: typeset short command-line options as literalMatthieu Moy2016-06-281-1/+1
| | | | | | | | | | | | | | It was common in our documentation to surround short option names with forward quotes, which renders as italic in HTML. Instead, use backquotes which renders as monospace. This is one more step toward conformance to Documentation/CodingGuidelines. This was obtained with: perl -pi -e "s/'(-[a-z])'/\`\$1\`/g" *.txt Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* doc: more consistency in environment variables formatTom Russello2016-06-081-1/+1
| | | | | | | | | | | | | | | | | | | Wrap with backticks (monospaced font) unwrapped or single-quotes wrapped (italic type) environment variables which are followed by the word "environment". It was obtained with: perl -pi -e "s/\'?(\\\$?[0-9A-Z\_]+)\'?(?= environment ?)/\`\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>
* Documentation: fix linkgit referencesjc/linkgit-fixJunio C Hamano2016-05-091-1/+1
| | | | | | | | | | | | | | | | | | | | There are a handful of incorrect "linkgit:<page>[<section>]" instances in our documentation set. * Some have an extra colon after "linkgit:"; fix them by removing the extra colon; * Some refer to a page outside the Git suite, namely curl(1); fix them by using the `curl(1)` that already appears on the same page for the same purpose of referring the readers to its manual page. * Some spell the name of the page incorrectly, e.g. "rev-list" when they mean "git-rev-list"; fix them. * Some list the manual section incorrectly; fix them to make sure they match what is at the top of the target of the link. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation: typofixesThomas Ackermann2014-11-041-2/+2
| | | | | | | | | | | | In addition to fixing trivial and obvious typos, be careful about the following points: - Spell ASCII, URL and CRC in ALL CAPS; - Spell Linux as Capitalized; - Do not omit periods in "i.e." and "e.g.". Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation: fix documentation AsciiDoc links for external urlsrt/links-for-asciidoctorRoberto Tyley2014-02-201-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Turns out that putting 'link:' before the 'http' is actually superfluous in AsciiDoc, as there's already a predefined macro to handle it. "http, https, [etc] URLs are rendered using predefined inline macros." http://www.methods.co.nz/asciidoc/userguide.html#_urls "Hypertext links to files on the local file system are specified using the link inline macro." http://www.methods.co.nz/asciidoc/userguide.html#_linking_to_local_documents Despite being superfluous, the reference implementation of AsciiDoc tolerates the extra 'link:' and silently removes it, giving a functioning link in the generated HTML. However, AsciiDoctor (the Ruby implementation of AsciiDoc used to render the http://git-scm.com/ site) does /not/ have this behaviour, and so generates broken links, as can be seen here: http://git-scm.com/docs/git-cvsimport (links to cvs2git & parsecvs) http://git-scm.com/docs/git-filter-branch (link to The BFG) It's worth noting that after this change, the html generated by 'make html' in the git project is identical, and all links still work. Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* docs: add filter-branch notes on The BFGrt/bfg-ad-in-filter-branch-docRoberto Tyley2013-12-181-1/+32
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The BFG is a tool specifically designed for the task of removing unwanted data from Git repository history - a common use-case for which git-filter-branch has been the traditional workhorse. It's beneficial to let users know that filter-branch has an alternative here: * speed : The BFG is 10-50x faster http://rtyley.github.io/bfg-repo-cleaner/#speed * complexity of configuration : filter-branch is a very flexible tool, but demands very careful usage in order to get the desired results http://rtyley.github.io/bfg-repo-cleaner/#examples Obviously, filter-branch has it's advantages too - it permits very complex rewrites, and doesn't require a JVM - but for the common use-case of deleting unwanted data, it's helpful to users to be aware that an alternative exists. The BFG was released under the GPL in February 2013, and has since seen widespread production use (The Guardian, RedHat, Google, UK Government Digital Service), been tested against large repos (~300K commits, ~5GB packfiles) and received significant positive feedback from users: http://rtyley.github.io/bfg-repo-cleaner/#feedback Signed-off-by: Roberto Tyley <roberto.tyley@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'tk/doc-filter-branch'Junio C Hamano2013-03-191-2/+25
|\ | | | | | | | | | | * tk/doc-filter-branch: Documentation: filter-branch env-filter example git-filter-branch.txt: clarify ident variables usage
| * Documentation: filter-branch env-filter exampleTadeusz Andrzej Kadłubowski2013-02-261-0/+20
| | | | | | | | | | | | | | | | filter-branch --env-filter example that shows how to change the email address in all commits before publishing a project. Signed-off-by: Tadeusz Andrzej Kadłubowski <yess@hell.org.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * git-filter-branch.txt: clarify ident variables usageTadeusz Andrzej Kadłubowski2013-02-261-2/+5
| | | | | | | | | | | | | | | | | | There is a rare edge case of git-filter-branch: a filter that unsets identity variables from the environment. Link to git-commit-tree clarifies how Git would fall back in this situation. Signed-off-by: Tadeusz Andrzej Kadłubowski <yess@hell.org.pl> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | Documentation: the name of the system is 'Git', not 'git'Thomas Ackermann2013-02-011-3/+3
|/ | | | | Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation/git-filter-branch: Move note about effect of removing commitsAndreas Schwab2012-09-181-10/+9
| | | | | | | | | | | | | | The note that explains that changes introduced by removed commits are preserved should be placed directly after the paragraph that describes such commits removal. Otherwise the reference to "the commits" appears out of context. Also the big example that follows "Consider this history" is about rewriting part of the history DAG. Move the paragraph that describes the operation close to it. Signed-off-by: Andreas Schwab <schwab@linux-m68k.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'jc/tag-doc' into maint-1.7.11Junio C Hamano2012-08-241-1/+2
|\ | | | | | | | | | | | | | | | | Our documentation used to assume having files in .git/refs/* directories was the only to have branches and tags, but that is not true for quite some time. * jc/tag-doc: Documentation: do not mention .git/refs/* directories
| * Documentation: do not mention .git/refs/* directoriesJunio C Hamano2012-08-061-1/+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>
* | docs: stop using asciidoc no-inline-literalJeff King2012-04-261-17/+17
|/ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | In asciidoc 7, backticks like `foo` produced a typographic effect, but did not otherwise affect the syntax. In asciidoc 8, backticks introduce an "inline literal" inside which markup is not interpreted. To keep compatibility with existing documents, asciidoc 8 has a "no-inline-literal" attribute to keep the old behavior. We enabled this so that the documentation could be built on either version. It has been several years now, and asciidoc 7 is no longer in wide use. We can now decide whether or not we want inline literals on their own merits, which are: 1. The source is much easier to read when the literal contains punctuation. You can use `master~1` instead of `master{tilde}1`. 2. They are less error-prone. Because of point (1), we tend to make mistakes and forget the extra layer of quoting. This patch removes the no-inline-literal attribute from the Makefile and converts every use of backticks in the documentation to an inline literal (they must be cleaned up, or the example above would literally show "{tilde}" in the output). Problematic sites were found by grepping for '`.*[{\\]' and examined and fixed manually. The results were then verified by comparing the output of "html2text" on the set of generated html pages. Doing so revealed that in addition to making the source more readable, this patch fixes several formatting bugs: - HTML rendering used the ellipsis character instead of literal "..." in code examples (like "git log A...B") - some code examples used the right-arrow character instead of '->' because they failed to quote - api-config.txt did not quote tilde, and the resulting HTML contained a bogus snippet like: <tt><sub></tt> foo <tt></sub>bar</tt> which caused some parsers to choke and omit whole sections of the page. - git-commit.txt confused ``foo`` (backticks inside a literal) with ``foo'' (matched double-quotes) - mentions of `A U Thor <author@example.com>` used to erroneously auto-generate a mailto footnote for author@example.com - the description of --word-diff=plain incorrectly showed the output as "[-removed-] and {added}", not "{+added+}". - using "prime" notation like: commit `C` and its replacement `C'` confused asciidoc into thinking that everything between the first backtick and the final apostrophe were meant to be inside matched quotes - asciidoc got confused by the escaping of some of our asterisks. In particular, `credential.\*` and `credential.<url>.\*` properly escaped the asterisk in the first case, but literally passed through the backslash in the second case. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation: git-filter-branch honors replacement refsPeter Collingbourne2011-07-211-2/+3
| | | | | | | | Make it clear that git-filter-branch will honor and make permanent replacement refs as well as grafts. Signed-off-by: Peter Collingbourne <peter@pcc.me.uk> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2011-04-011-1/+1
|\ | | | | | | | | * maint: docs: fix filter-branch subdir example for exotic repo names
| * docs: fix filter-branch subdir example for exotic repo namesJeff King2011-04-011-1/+1
| | | | | | | | | | | | | | | | | | The GIT_INDEX_FILE variable we get from git has the full path to the repo, which may contain spaces. When we use it in our shell snippet, it needs to be quoted. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | doc: drop author/documentation sections from most pagesJeff King2011-03-111-10/+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.
* Use parentheses and `...' where appropriateŠtěpán Němec2010-10-081-1/+1
| | | | | | | | | Remove some stray usage of other bracket types and asterisks for the same purpose. Signed-off-by: Štěpán Němec <stepnem@gmail.com> Acked-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation: Refer to git-commit-tree in git-filter-branch helpWesley J. Landaker2010-09-271-1/+1
| | | | | | | | | | Currently, the help for git filter-branch refers users of --env-filter to git-commit for information about environment variables affecting commits. However, this information is not contained in the git-commit help, but is very explicitly detailed in git-commit-tree. Signed-off-by: Wesley J. Landaker <wjl@icecavern.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* filter-branch: retire --remap-to-ancestorCsaba Henk2010-08-271-13/+13
| | | | | | | | | | We can be clever and know by ourselves when we need the behavior implied by "--remap-to-ancestor". No need to encumber users by having them exposed to it as a tunable. (Option kept for backward compatibility, but it's now a no-op.) Signed-off-by: Csaba Henk <csaba@gluster.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* docs: fix filter-branch example for quoted pathsJeff King2010-02-061-1/+1
| | | | | | | | | If there is a quoted path, update-index will correctly unquote it. However, we must take care to put our new prefix inside the double-quote. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Documentation: spell 'git cmd' without dash throughoutThomas Rast2010-01-101-9/+9
| | | | | | | | | | | | | | | The documentation was quite inconsistent when spelling 'git cmd' if it only refers to the program, not to some specific invocation syntax: both 'git-cmd' and 'git cmd' spellings exist. The current trend goes towards dashless forms, and there is precedent in 647ac70 (git-svn.txt: stop using dash-form of commands., 2009-07-07) to actively eliminate the dashed variants. Replace 'git-cmd' with 'git cmd' throughout, except where git-shell, git-cvsserver, git-upload-pack, git-receive-pack, and git-upload-archive are concerned, because those really live in the $PATH.
* Documentation: format full commands in typewriter fontThomas Rast2010-01-101-3/+3
| | | | | | | | | | | | | | 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>
* filter-branch: nearest-ancestor rewriting outside subdir filterThomas Rast2009-11-131-1/+12
| | | | | | | | | | | | | | | | | | | | | | | Since a0e4639 (filter-branch: fix ref rewriting with --subdirectory-filter, 2008-08-12) git-filter-branch has done nearest-ancestor rewriting when using a --subdirectory-filter. However, that rewriting strategy is also a useful building block in other tasks. For example, if you want to split out a subset of files from your history, you would typically call git filter-branch -- <refs> -- <files> But this fails for all refs that do not point directly to a commit that affects <files>, because their referenced commit will not be rewritten and the ref remains untouched. The code was already there for the --subdirectory-filter case, so just introduce an option that enables it independently. Signed-off-by: Thomas Rast <trast@student.ethz.ch> Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* filter-branch: add --prune-empty to option summaryAdam Brewster2009-10-021-0/+1
| | | | | Signed-off-by: Adam Brewster <adambrewster@gmail.com> Signed-off-by: Jeff King <peff@peff.net>
* filter-branch: add an example how to add ACKs to a range of commitsJohannes Schindelin2009-08-181-0/+10
| | | | | | | | | | | | | | When you have to add certain lines like ACKs (or for that matter, Signed-off-by:s) to a range of commits starting with HEAD, you might be tempted to use 'git rebase -i -10', but that is a waste of your time. It is better to use 'git filter-branch' with an appropriate message filter, and this commit adds an example how to do so to filter-branch's man page. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Merge branch 'maint'Junio C Hamano2009-04-121-0/+3
|\ | | | | | | | | | | | | | | | | | | * maint: GIT 1.6.2.3 State the effect of filter-branch on graft explicitly process_{tree,blob}: Remove useless xstrdup calls Conflicts: GIT-VERSION-GEN
View Lorry Controller Status