* 'jk/doc-credits' of git://github.com/peff/git:
docs: point git.txt author credits to git-scm.com
doc: add missing git footers
doc: drop author/documentation sections from most pages
This change makes it clearer that the change to the history effected by
executing 'git rebase master' while on 'topic' branch, and by executing
'git rebase master topic' on any branch, will be the same; the implicit
checkout of the second form will remain after the rebase exits.
Signed-off-by: Drew Northup <drew.northup@maine.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
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.
'git rebase' without arguments is currently not supported. Make it
default to 'git rebase @{upstream}'. That is also what 'git pull
[--rebase]' defaults to, so it only makes sense that 'git rebase'
defaults to the same thing.
Defaulting to @{upstream} will make it possible to run e.g. 'git
rebase -i' without arguments, which is probably a quite common use
case. It also improves the scenario where you have multiple branches
that rebase against a remote-tracking branch, where you currently have
to choose between the extra network delay of 'git pull' or the
slightly awkward keys to enter 'git rebase @{u}'.
The error reporting when no upstream is configured for the current
branch or when no branch is checked out is reused from git-pull.sh. A
function is extracted into git-parse-remote.sh for this purpose.
Helped-by: Yann Dirson <ydirson@altern.org>
Helped-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Interactive rebase allows the '--verify' option to be passed, but it will
be ignored. Implement proper support for the option for both interactive
and non-interactive rebase by making it override any previous
'--no-verify'.
Signed-off-by: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* mm/rebase-i-exec:
git-rebase--interactive.sh: use printf instead of echo to print commit message
git-rebase--interactive.sh: rework skip_unnecessary_picks
test-lib: user-friendly alternatives to test [-d|-f|-e]
rebase -i: add exec command to launch a shell command
Conflicts:
git-rebase--interactive.sh
t/t3404-rebase-interactive.sh
The symmetric difference or merge-base operator ... as used by
rev-list and diff is actually three period characters. If it
gets replaced by an ellipsis glyph in the manual, that would
stop readers from copying and pasting it.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The typical usage pattern would be to run a test (or simply a compilation
command) at given points in history.
The shell command is ran (from the worktree root), and the rebase is
stopped when the command fails, to give the user an opportunity to fix
the problem before continuing with "git rebase --continue".
This needs a little rework of skip_unnecessary_picks, which wasn't robust
enough to deal with lines like
exec >"file name with many spaces"
in the todolist. The new version extracts command, sha1 and rest from
each line, but outputs the line itself verbatim to avoid changing the
whitespace layout.
Signed-off-by: Matthieu Moy <Matthieu.Moy@imag.fr>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-rebase calls out to merge strategies, but did not support merge
strategy options so far. Add this, in the same style used in
git-merge.
Sadly we have to do the full quoting/eval dance here, since
merge-recursive supports the --subtree=<path> option which potentially
contains whitespace.
This patch does not cover git rebase -i, which does not call any merge
strategy directly except in --preserve-merges, and even then only for
merges.
[jc: with a trivial fix-up for 'expr']
Signed-off-by: Mike Lundy <mike@fluffypenguin.org>
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
If you use this feature regularly you can now enable it by default. In
case the user wants to override this config on the commandline
--no-autosquash can be used to force disabling.
Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The rebase --preserve-merges facility presents a list of commits
in its instruction sheet and uses a separate table to keep
track of their parents. Unfortunately, in practice this means
that with -p after most attempts to rearrange patches, some
commits have the "wrong" parent and the resulting history is
rarely what the caller expected.
Yes, it would be nice to fix that. But first, add a warning to the
manual to help the uninitiated understand what is going on.
Reported-by: Jiří Paleček <jpalecek@web.de>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Describe the A...B shortcuts for checkout and rebase [-i] which were
introduced in these commits:
619a64e ("checkout A...B" switches to the merge base between A and B, 2009-10-18)
61dfa1b ("rebase --onto A...B" replays history on the merge base between A and B, 2009-11-20)
230a456 (rebase -i: teach --onto A...B syntax, 2010-01-07)
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For git-rebase.sh, --no-ff is a synonym for --force-rebase.
For git-rebase--interactive.sh, --no-ff cherry-picks all the commits in
the rebased branch, instead of fast-forwarding over any unchanged commits.
--no-ff offers an alternative way to deal with reverted merges. Instead of
"reverting the revert" you can use "rebase --no-ff" to recreate the branch
with entirely new commits (they're new because at the very least the
committer time is different). This obviates the need to revert the
reversion, as you can re-merge the new topic branch directly. Added an
addendum to revert-a-faulty-merge.txt describing the situation and how to
use --no-ff to handle it.
Signed-off-by: Marc Branchaud <marcnarc@xiplink.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* remotes/trast-doc/for-next:
Documentation: spell 'git cmd' without dash throughout
Documentation: format full commands in typewriter font
Documentation: warn prominently against merging with dirty trees
Documentation/git-merge: reword references to "remote" and "pull"
Conflicts:
Documentation/config.txt
Documentation/git-config.txt
Documentation/git-merge.txt
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.
Teach a new option, --autosquash, to the interactive rebase.
When the commit log message begins with "!fixup ...", and there
is a commit whose title begins with the same ..., automatically
modify the todo list of rebase -i so that the commit marked for
squashing come right after the commit to be modified, and change
the action of the moved commit from pick to squash.
Signed-off-by: Nanako Shiraishi <nanako3@lavabit.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The command is like "squash", except that it discards the commit message
of the corresponding commit.
Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu>
Acked-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add a paragraph about the swapped sides in a --merge rebase, which was
otherwise only documented in the sources.
Add a paragraph about the effects of the 'ours' strategy to the -s
description. Also remove the mention of the 'octopus' strategy, which
was copied from the git-merge description but is pointless in a
rebase.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Make it easier to edit just the commit message for a commit
using 'git rebase -i' by introducing the "reword" command.
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Introduce --ignore-whitespace option and corresponding config bool to
ignore whitespace differences while applying patches, akin to the
'patch' program.
'git am', 'git rebase' and the bash git completion are made aware of
this option.
Signed-off-by: Giuseppe Bilotta <giuseppe.bilotta@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-am and git-rebase are talkative scripts. Teach them to be quiet when
told, allowing them to speak only when they fail or experience errors.
The quiet option is maintained when git-am or git-rebase fails to apply
a patch. This means subsequent --resolved, --continue, --skip, --abort
invocations will be quiet if the original invocation was quiet.
Drop a handful of >&2 redirection; the rest of the program sends all the
info messages to stdout, not to stderr.
Signed-off-by: Stephen Boyd <bebarino@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Add the options --committer-date-is-author-date and --ignore-date
to git-rebase. They were introduced in commit a79ec62d0 for git-am.
These options imply --force-rebase.
Signed-off-by: Michele Ballabio <barra_cuda@katamail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The behavior of --verbose is unchanged, but uses a different state
variable internally, so that the meaning of verbose output may be
expanded without affecting the diffstat. This is also reflected in
the documentation.
The configuration option rebase.stat works the same was as merg.stat,
but the default is currently false.
Signed-off-by: Tor Arne Vestbø <torarnv@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The parameters accepted by the --whitespace option of "git apply" have
changed over time, and the documentation for "git rebase" was out of
sync. Remove the specific parameter list from the "git rebase"
documentation and simply point to the "git apply" documentation for
details, as is already done in the "git am" documentation.
Signed-off-by: Todd Zullinger <tmz@pobox.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the new option depends on --onto and omission of <upstream>, use
a separate invocation style, and omit most options to save space.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* tr/workflow-doc:
Documentation: add manpage about workflows
Documentation: Refer to git-rebase(1) to warn against rewriting
Documentation: new upstream rebase recovery section in git-rebase
As a result of implementation details, 'git rebase' could
previously only preserve merges in interactive mode. That
limitation was hard for users to understand and awkward to
explain.
This patch works around it by running the interactive rebase
helper git-rebase--interactive with GIT_EDITOR set to ':'
when the user passes "-p" but not "-i" to the rebase command.
The effect is that the interactive rebase helper is used but
the user never sees an editor.
The test-case included in this patch was originally written
by Stephen Habermann <stephen@exigencecorp.com>, but has
been extensively modified since its creation.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Generally, the dependent clause "for example" is suffixed with a comma.
Used present tense where appropriate to be consistent with the other
paragraphs.
Rewrote the paragraph in the second hunk to be more clear.
Signed-off-by: Garry Dolley <gdolley@ucla.edu>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Document how to recover if the upstream that you pull from has
rebased the branches you depend your work on. Hopefully this can also
serve as a warning to potential rebasers.
Signed-off-by: Thomas Rast <trast@student.ethz.ch>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With git-am, it sounds awkward to have the patches in ".git/rebase/",
but for technical reasons, we have to keep the same directory name
for git-am and git-rebase. ".git/rebase-apply" seems to be a good
compromise.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the files generated and used during a rebase are never to be
tracked, they should live in $GIT_DIR. While at it, avoid the rather
meaningless term "dotest" to "rebase", and unhide ".dotest-merge".
This was wished for on the mailing list, but so far unimplemented.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Merge has always set ORIG_HEAD but never mentioned it, while we
recently added it to am and rebase. These facts should be reflected
in the documentation.
git-reset also sets ORIG_HEAD, but that fact is already mentioned in
the very first example so no changes were needed there.
Signed-off-by: Brian Gernhardt <benji@silverinsanity.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The names of git commands are not meant to be entered at the
commandline; they are just names. So we render them in italics,
as is usual for command names in manpages.
Using
doit () {
perl -e 'for (<>) { s/\`(git-[^\`.]*)\`/'\''\1'\''/g; print }'
}
for i in git*.txt config.txt diff*.txt blame*.txt fetch*.txt i18n.txt \
merge*.txt pretty*.txt pull*.txt rev*.txt urls*.txt
do
doit <"$i" >"$i+" && mv "$i+" "$i"
done
git diff
.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
With git-commands moving out of $(bindir), it is useful to make a
clearer distinction between the git subcommand 'git-whatever' and
the command you type, `git whatever <options>`. So we use a dash
after "git" when referring to the former and not the latter.
I already sent a patch doing this same thing, but I missed some
spots.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Following what appears to be the predominant style, format
names of commands and commandlines both as `teletype text`.
While we're at it, add articles ("a" and "the") in some
places, italicize the name of the command in the manual page
synopsis line, and add a comma or two where it seems appropriate.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since the git-* commands are not installed in $(bindir), using
"git-command <parameters>" in examples in the documentation is
not a good idea. On the other hand, it is nice to be able to
refer to each command using one hyphenated word. (There is no
escaping it, anyway: man page names cannot have spaces in them.)
This patch retains the dash in naming an operation, command,
program, process, or action. Complete command lines that can
be entered at a shell (i.e., without options omitted) are
made to use the dashless form.
The changes consist only of replacing some spaces with hyphens
and vice versa. After a "s/ /-/g", the unpatched and patched
versions are identical.
Signed-off-by: Jonathan Nieder <jrnieder@uchicago.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The OPTIONS section of a documentation file contains a list
of the options a git command accepts.
Currently there are several variants to describe the case that
different options (almost) do the same in the OPTIONS section.
Some are:
-f, --foo::
-f|--foo::
-f | --foo::
But AsciiDoc has the special form:
-f::
--foo::
This patch applies this form to the documentation of the whole git suite,
and removes useless em-dash prevention, so \--foo becomes --foo.
Signed-off-by: Stephan Beyer <s-beyer@gmx.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
As the "git" man page describes the "git" command at the end-user
level, it seems better to move it to man section 1.
Signed-off-by: Christian Couder <chriscool@tuxfamily.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Being in the project's top directory when starting or continuing a rebase
is not necessary since 533b703 (Allow whole-tree operations to be started
from a subdirectory, 2007-01-12).
Signed-off-by: SZEDER Gábor <szeder@ira.uka.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Between AsciiDoc 8.2.2 and 8.2.3, the following change was made to the stock
Asciidoc configuration:
@@ -149,7 +153,10 @@
# Inline macros.
# Backslash prefix required for escape processing.
# (?s) re flag for line spanning.
-(?su)[\\]?(?P<name>\w(\w|-)*?):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
+# Explicit so they can be nested.
+(?su)[\\]?(?P<name>(http|https|ftp|file|mailto|callto|image|link)):(?P<target>\S*?)(\[(?P<attrlist>.*?)\])=
+
# Anchor: [[[id]]]. Bibliographic anchor.
(?su)[\\]?\[\[\[(?P<attrlist>[\w][\w-]*?)\]\]\]=anchor3
# Anchor: [[id,xreflabel]]
This default regex now matches explicit values, and unfortunately in this
case gitlink was being matched by just 'link', causing the wrong inline
macro template to be applied. By renaming the macro, we can avoid being
matched by the wrong regex.
Signed-off-by: Dan McGee <dpmcgee@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-rebase uses format-patch's --ignore-if-in-upstream
option, but we never document the user-visible behavior. The
example is placed near the top of the example list rather
than at the bottom because it is:
a. a simple example
b. a reasonably common scenario for many projects (mail
some patches which get accepted upstream, then rebase)
[sp: Corrected direction of 'HEAD..<upstream>' set comparsion]
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
* maint:
git-remote: exit with non-zero status after detecting errors.
rebase -i: squash should retain the authorship of the _first_ commit
git-add--interactive: Improve behavior on bogus input
git-add--interactive: Allow Ctrl-D to exit
It was determined on the mailing list, that it makes more sense for a
"squash" to keep the author of the first commit as the author for the
result of the squash.
Make it so.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Pass --whitespace=<option> to git-apply. Since git-apply and git-am
expect this, I'm always surprised when I try to give it to git-rebase
and it doesn't work.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The interactive mode of rebase can be used to split commits. Tell the
interested parties about it, with a dedicated section in the man page.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The option "-p" (or long "--preserve-merges") makes it possible to
rebase side branches including merges, without straightening the
history.
Example:
X
\
A---M---B
/
---o---O---P---Q
When the current HEAD is "B", "git rebase -i -p --onto Q O" will yield
X
\
---o---O---P---Q---A'---M'---B'
Note that this will
- _not_ touch X [*1*], it does
- _not_ work without the --interactive flag [*2*], it does
- _not_ guess the type of the merge, but blindly uses recursive or
whatever strategy you provided with "-s <strategy>" for all merges it
has to redo, and it does
- _not_ make use of the original merge commit via git-rerere.
*1*: only commits which reach a merge base between <upstream> and HEAD
are reapplied. The others are kept as-are.
*2*: git-rebase without --interactive is inherently patch based (at
least at the moment), and therefore merges cannot be preserved.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Don't you just hate the fact sometimes, that git-rebase just applies
the patches, without any possibility to edit them, or rearrange them?
With "--interactive", git-rebase now lets you edit the list of patches,
so that you can reorder, edit and delete patches.
Such a list will typically look like this:
pick deadbee The oneline of this commit
pick fa1afe1 The oneline of the next commit
...
By replacing the command "pick" with the command "edit", you can amend
that patch and/or its commit message, and by replacing it with "squash"
you can tell rebase to fold that patch into the patch before that.
It is derived from the script sent to the list in
<Pine.LNX.4.63.0702252156190.22628@wbgn013.biozentrum.uni-wuerzburg.de>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This uses "git-apply --whitespace=strip" to fix whitespace errors that have
crept in to our source files over time. There are a few files that need
to have trailing whitespaces (most notably, test vectors). The results
still passes the test, and build result in Documentation/ area is unchanged.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Since `git add` is the approved porcelain for an end-user to invoke
when they want to manipulate the index, porcelain documentation
should steer the user to this command rather than the pure plumbing
update-index.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It was mentioned on #git this morning that the lead-in description
of git-rebase is very confusing. Too many branch this and branch
that in a very short run of text.
This new description attempts to walk the user through the command
syntax, while also describing exactly what git-rebase is doing to
their repository.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add -C[NUM] to git-am and git-rebase so that patches can be applied even
if context has changed a bit.
Signed-off-by: Michael S. Tsirkin <mst@mellanox.co.il>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This particular use of git-rebase to remove a single commit or a
range of commits from the history of a branch recently came up on
the mailing list. Documenting the example should help other users
arrive at the same solution on their own.
It also was not obvious to the newcomer that git-rebase is able to
accept any commit for --onto <newbase> and <upstream>. We should
at least minimally document this, as much of the language in
git-rebase's manpage refers to 'branch' rather than 'committish'.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* maint:
Documentation: Transplanting branch with git-rebase --onto
merge-recursive implicitely depends on trust_executable_bit
adjust_shared_perm: chmod() only when needed.
Fix git-runstatus for repositories containing a file named HEAD
Added example of transplantig feature branch from one development
branch (for example "next") into the other development branch (for
example "master").
[jc: talking Carl's advice this contains both examples sent to
the list by Jakub in his original message.]
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now that we control the merge base selection, we won't be forced
into rolling things in that we wanted to skip beforehand.
Also, add a test to ensure this all works as intended.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This solves the problem of rebasing local commits against an
upstream that has renamed files.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git rebase [--onto <newbase>] <upstream> [<branch>]
git rebase --continue
git rebase --abort
Add "--continue" to restart the rebase process after
manually resolving conflicts. The user is warned if
there are still differences between the index and the
working files.
Add "--abort" to restore the original branch, and
remove the .dotest working files.
Some minor additions to the git-rebase documentation.
[jc: fix that applies to the maintenance track has been dealt
with separately.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
I found a paper thin man page for git-rebase, but was quite happy to
see something much more useful in the usage statement of the script
when I went there to find out how this thing worked. Here it is
cleaned up slightly and expanded a bit into the actual documentation.
Signed-off-by: Carl Worth <cworth@cworth.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The replacement was performed automatically by these commands:
perl -pi -e 's/link:(git.+)\.html\[\1\]/gitlink:$1\[1\]/g' \
README Documentation/*.txt
perl -pi -e 's/link:git\.html\[git\]/gitlink:git\[7\]/g' \
README Documentation/*.txt
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As promised, this is the "big tool rename" patch. The primary differences
since 0.99.6 are:
(1) git-*-script are no more. The commands installed do not
have any such suffix so users do not have to remember if
something is implemented as a shell script or not.
(2) Many command names with 'cache' in them are renamed with
'index' if that is what they mean.
There are backward compatibility symblic links so that you and
Porcelains can keep using the old names, but the backward
compatibility support is expected to be removed in the near
future.
Signed-off-by: Junio C Hamano <junkio@cox.net>
