This patch renames man1 and man7 variables to man1dir and man7dir,
according to "Makefile Conventions: Variables for Installation
Directories" in make.info of GNU Make.
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Makefiles in subdirectories now use existing value of INSTALL, bindir,
mandir if it is set, allowing those to be set in main Makefile or in
included config.mak. Main Makefile exports variables which it sets.
Accidentally it renames bin to bindir in Documentation/Makefile
(should be bindir from start, but is unused, perhaps to be removed).
Signed-off-by: Jakub Narebski <jnareb@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* ew/rebase:
rebase: allow --skip to work with --merge
rebase: cleanup rebasing with --merge
rebase: allow --merge option to handle patches merged upstream
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>
Some people tend to do many little commits on a topic branch,
recording all the trials and errors, and when the topic is
reasonably cooked well, would want to record the net effect of
the series as one commit on top of the mainline, removing the
cruft from the history. The topic is then abandoned or forked
off again from that point at the mainline.
The barebone porcelainish that comes with core git tools does
not officially support such operation, but you can fake it by
using "git pull --no-merge" when such a topic branch is not a
strict superset of the mainline, like this:
git checkout mainline
git pull --no-commit . that-topic-branch
: fix conflicts if any
rm -f .git/MERGE_HEAD
git commit -a -m 'consolidated commit log message'
git branch -f that-topic-branch ;# now fully merged
This however does not work when the topic branch is a fast
forward of the mainline, because normal "git pull" will never
create a merge commit in such a case, and there is nothing
special --no-commit could do to begin with.
This patch introduces a new option, --squash, to support such a
workflow officially in both fast-forward case and true merge
case. The user-level operation would be the same in both cases:
git checkout mainline
git pull --squash . that-topic-branch
: fix conflicts if any -- naturally, there would be
: no conflict if fast forward.
git commit -a -m 'consolidated commit log message'
git branch -f that-topic-branch ;# now fully merged
When the current branch is already up-to-date with respect to
the other branch, there truly is nothing to do, so the new
option does not have any effect.
This was brought up in #git IRC channel recently.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* ew/rebase:
rebase --merge: fix for rebasing more than 7 commits.
rebase: error out for NO_PYTHON if they use recursive merge
Add renaming-rebase test.
rebase: Allow merge strategies to be used when rebasing
* jc/upload-corrupt:
daemon: send stderr to /dev/null instead of closing.
upload-pack/fetch-pack: support side-band communication
Retire git-clone-pack
upload-pack: prepare for sideband message support.
upload-pack: avoid sending an incomplete pack upon failure
* pb/config:
git_config: access() returns 0 on success, not > 0
repo-config: Fix late-night bug
Read configuration also from $HOME/.gitconfig
Fix setting config variables with an alternative GIT_CONFIG
Support for extracting configuration from different files
When multiple recipients are given to git-send-email on the same
--cc line the code does not properly handle it.
Full and proper parsing of the email addresses so I can detect
which commas mean a new email address is more than I care to implement.
In particular this email address: "bibo,mao" <bibo.mao@intel.com>
must not be treated as two email addresses.
So this patch simply treats all commas in recipient lists as
an error and fails if one is given.
At the same time it documents that git-send-email wants multiple
instances of --cc specified on the command line if you want to
cc multiple recipients.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
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>
The program is not used by git-clone since git-fetch-pack was extended
to allow its caller do what git-clone-pack alone did, and git-clone was
updated to use it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add $GIT_CONFIG environment variable whose content is used instead
of .git/config if set. Also add $GIT_CONFIG_LOCAL as a
forward-compatibility cue for whenever we will finally come to support]
global configuration files (properly).
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* add example on how to avoid adding a global extended pax header
* don't mention linux anymore, use git itself as an example instead
* update to v1.4.0 ;-)
* append missing :: to the examples
Signed-off-by: Rene Scharfe <rene.scharfe@lsrfire.ath.cx>
Signed-off-by: Junio C Hamano <junkio@cox.net>
fix the usage string and clean up the docs while we are at it
Signed-off-by: Fredrik Kuivinen <freku045@student.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
P4import currently creates a git tag for every commit it imports.
When importing from a large repository too many tags can be created
for git to manage, so this provides an option to shut that feature
off if necessary.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
No content change here.
html output improved. man output changed.
Signed-off-by: Francis Daly <francis@daoine.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch ports and modifies appropriately the git aliases documentation
from my patch, shall it rest in peace.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
All should be clear enough, except perhaps committish / commitish.
I just kept the more-used one within the current docs.
[jc: with rephrasing of check-ref-format description later discussed
on the list]
Signed-off-by: Francis Daly <francis@daoine.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Additionally notices and complains to an -o option without
directory or a duplicated -o option, -o and --stdout given
together. Also delays the creation of directory until all
arguments are parsed, so that the command does not leave an
empty directory behind when it exits after seeing an unrelated
invalid option.
[jc: originally from Dennis Stosberg but with minor fixes, and
documentation updates from Dennis.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
This should be obvious enough.
I didn't actually _test_ the tutorial, but if the old command worked,
something is really wrong!
Signed-off-by: Linus "Duh!" Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Many Linux distributions use xinetd(8), not inetd(8).
Give a sample configuration file.
Signed-off-by: Horst H. von Brand <vonbrand@inf.utfsm.cl>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* sp/reflog:
fetch.c: do not pass uninitialized lock to unlock_ref().
Test that git-branch -l works.
Verify git-commit provides a reflog message.
Enable ref log creation in git checkout -b.
Create/delete branch ref logs.
Include ref log detail in commit, reset, etc.
Change order of -m option to update-ref.
Correct force_write bug in refs.c
Change 'master@noon' syntax to 'master@{noon}'.
Log ref updates made by fetch.
Force writing ref if it doesn't exist.
Added logs/ directory to repository layout.
General ref log reading improvements.
Fix ref log parsing so it works properly.
Support 'master@2 hours ago' syntax
Log ref updates to logs/refs/<ref>
Convert update-ref to use ref_lock API.
Improve abstraction of ref lock/write.
While trying to implement a pack reader in Java I was mislead by
some facts listed in this documentation as well as found a few
details to be missing about the pack header.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Give the git-core tutorial a name that better reflects its intended
audience.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I'd rather avoid git cat-file so early on, but the
git-cat-file -p old-commit:/path/to/file
trick is too useful....
Also fix a nearby typo while we're at it.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Kind of silly, but the font I get by default in gitk makes it mostly
unusable for me, so this is the first thing I'd want to know about.
(But maybe there's a better suggestion than just Ctrl-='ing until
satisfied.)
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As both DESTDIR and the prefix are supposed to be absolute pathnames
they can simply be concatenated without an extra / (like in the main Makefile).
The extra slash may even break installation on Windows.
[jc: adjusted an earlier workaround for this problem in the dist-doc
target in the main Makefile as well. ]
Signed-off-by: Martin Waitz <tali@admingilde.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* master: (90 commits)
fetch.c: remove an unused variable and dead code.
Clean up sha1 file writing
Builtin git-cat-file
builtin format-patch: squelch content-type for 7-bit ASCII
CMIT_FMT_EMAIL: Q-encode Subject: and display-name part of From: fields.
add more informative error messages to git-mktag
remove the artificial restriction tagsize < 8kb
git-rebase: use canonical A..B syntax to format-patch
git-format-patch: now built-in.
fmt-patch: Support --attach
fmt-patch: understand old <his> notation
Teach fmt-patch about --keep-subject
Teach fmt-patch about --numbered
fmt-patch: implement -o <dir>
fmt-patch: output file names to stdout
Teach fmt-patch to write individual files.
built-in tar-tree and remote tar-tree
Builtin git-diff-files, git-diff-index, git-diff-stages, and git-diff-tree.
Builtin git-show-branch.
Builtin git-apply.
...
Add a sequel to tutorial.txt which discusses the index file and
the object database.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Expand the history-browsing section of the tutorial a bit, in part to
address Junio's suggestion that we mention "git grep" and Linus's
complaint that people are missing the flexibility of the commandline
interfaces for selecting commits.
This reads a little more like a collection of examples than a
"tutorial", but maybe that's what people need at this point.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Junio suggested changing references to git-whatchanged to git-log.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With the new cat-file syntax of 'v1.3.3:refs.c' we should mention
it as part of the reason why ':' is not permitted in a ref name.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Its nice to have git-check-ref-format actually get mentioned in
git-branch's documentation as the syntax of a ref name must conform
to what is described in git-check-ref-format.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Switch git checkout -b to use git-update-ref rather than echo and
a shell I/O redirection. This is more in line with typical GIT
commands and allows -b to be logged according to the normal ref
logging rules.
Added -l option to allow users to create the ref log at the same
time as creating a branch.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When crating a new branch offer '-l' as a way for the user to
quickly enable ref logging for the new branch.
When deleting a branch also delete its ref log.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The actual position doesn't matter but most people prefer to see
options appear before the arguments.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Its ambiguous to parse "master@2006-05-17 18:30:foo" when foo is
meant as a file name and ":30" is meant as 30 minutes past 6 pm.
Therefore all date specifications in a sha1 expression must now
appear within brackets and the ':' splitter used for the path name
in a sha1 expression ignores ':' appearing within brackets.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since large quilt trees like -mm can easily have patches
without clear authorship information, add a --dry-run
option to make the problem patches easy to find.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Importing a quilt patch series into git is not very difficult
but parsing the patch descriptions and all of the other
minutia take a bit of effort to get right, so this automates it.
Since git and quilt complement each other it makes sense
to make it easy to go back and forth between the two.
If a patch is encountered that it cannot derive the author
from the user is asked.
Signed-off-by: Junio C Hamano <junkio@cox.net>
[jc: rewrote by stealing from what I run to update html and
man branches automatically]
Signed-off-by: Tilman Sauerbeck <tilman@code-monkey.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Extended sha1 expressions may now include date specifications
which indicate a point in time within the local repository's
history. If the ref indicated to the left of '@' has a log in
$GIT_DIR/logs/<ref> then the value of the ref at the time indicated
by the specification is obtained from the ref's log.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If config parameter core.logAllRefUpdates is true or the log
file already exists then append a line to ".git/logs/refs/<ref>"
whenever git-update-ref <ref> is executed. Each log line contains
the following information:
oldsha1 <SP> newsha1 <SP> committer <LF>
where committer is the current user, date, time and timezone in
the standard GIT ident format. If the caller is unable to append
to the log file then git-update-ref will fail without updating <ref>.
An optional message may be included in the log line with the -m flag.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This conversion also adds the '-m' switch to update-ref allowing
the caller to record why the ref is changing. At present this is
merely copied down into the ref_lock API.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/grep: (22 commits)
Fix silly typo in new builtin grep
builtin-grep: unparse more command line options.
builtin-grep: use external grep when we can take advantage of it
builtin-grep: -F (--fixed-strings)
builtin-grep: -w fix
builtin-grep: typofix
builtin-grep: tighten argument parsing.
builtin-grep: documentation
Teach -f <file> option to builtin-grep.
builtin-grep: -L (--files-without-match).
builtin-grep: binary files -a and -I
builtin-grep: terminate correctly at EOF
builtin-grep: tighten path wildcard vs tree traversal.
builtin-grep: support -w (--word-regexp).
builtin-grep: support -c (--count).
builtin-grep: allow more than one patterns.
builtin-grep: allow -<n> and -[ABC]<n> notation for context lines.
builtin-grep: printf %.*s length is int, not ptrdiff_t.
builtin-grep: do not use setup_revisions()
builtin-grep: support '-l' option.
...
Remove the need to pipe git diff through git apply to
get the extended headers summary.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
"git branch" uses "rev-parse --all" and becomes much too slow when
there are many tags (it scans all refs). Use the new "--branches"
option of rev-parse to speed things up.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* ml/cvs:
Change to allow subdir updates from Eclipse
Many fixes for most operations in Eclipse.
Added logged warnings for CVS error returns
cvsserver: use git-rev-list instead of git-log
git-cvsexportcommit: Add -f(orce) and -m(essage prefix) flags, small cleanups.
* 'tojunio' of http://locke.catalyst.net.nz/git/git-martinlanghoff:
Change to allow subdir updates from Eclipse
Many fixes for most operations in Eclipse.
Added logged warnings for CVS error returns
cvsserver: use git-rev-list instead of git-log
git-cvsexportcommit: Add -f(orce) and -m(essage prefix) flags, small cleanups.
When optional paths arguments are given, git-clean passes them
to underlying git-ls-files; with this, you can say:
git clean 'temp-*'
to clean only the garbage files whose names begin with 'temp-'.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Signed-off-by: Pavel Roskin <proski@gnu.org>
* fix:
repack: honor -d even when no new pack was created
clone: keep --reference even with -l -s
repo-config: document what value_regexp does a bit more clearly.
Release config lock if the regex is invalid
core-tutorial.txt: escape asterisk
After running 'git-update-index' for some paths, you may want to
do the update on the same set of paths again.
The new flag --again checks the paths whose index entries are
are different from the HEAD commit and updates them from the
working tree contents.
This was brought up by Carl Worth on #git.
Signed-off-by: Junio C Hamano <junkio@cox.net>
When inspecting a project whose build infrastructure used to
assume that .git/HEAD is a symlink ref, core.prefersymlinkrefs
in the config file of such a project would help to bisect its
history.
Signed-off-by: Junio C Hamano <junkio@cox.net>
(cherry picked from 9f0bb90d16 commit)
Document that git-unpack-objects will not produce any
results when used on a pack that exists in a repository;
move it first.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A bare "--" doesn't show up in man or html pages correctly
as two individual dashes unless backslashed as \--
in the asciidoc source. Note, no backslash is needed
inside a literal block.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Move incorrect asciidoc level 2 titles back to level 1.
Show output of git-name-rev in man page example.
Reword sentences that begin with a period (.) in asciidoc
numbered lists to work around conversion to man page bug.
Mention that git-repack now calls git-prune-packed
when the -d option is passed to it.
[imap] section headers in the config file example need to be
contained in a literal block. imap.pass is the proper config
file variable to use, not imap.password.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Clean up a few entries and fix typos.
bare repository
cherry-picking
hook
topic branch
[jc: removing questionable "symbolic ref -- see 'ref'" for now.]
Signed-off-by: Jon Loeliger <jdl@jdl.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
fast forward
pickaxe
refspec
tracking branch
Wild hack allows "link:git-" prefix to reference commands too.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When inspecting a project whose build infrastructure used to
assume that .git/HEAD is a symlink ref, core.prefersymlinkrefs
in the config file of such a project would help to bisect its
history.
Signed-off-by: Junio C Hamano <junkio@cox.net>
With --get-regexp, output all key/value pairs where the key matches a
regexp. Example:
git-repo-config --get-regexp remote.*.url
will output something like
remote.junio.url git://git.kernel.org/pub/scm/git/git.git
remote.gitk.url git://git.kernel.org/pub/scm/gitk/gitk.git
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Remove the shell-script version, make the hardlink from the git
binary, and update the documentation to describe a new option.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The "bind" commit can express an aggregation of multiple
projects into a single commit.
In such an organization, there would be one project, root of
whose tree object is at the same level of the root of the
aggregated projects, and other projects have their toplevel in
separate subdirectories. Let's call that root level project the
"primary project", and call other ones just "subprojects".
You would first read-tree the primary project, and then graft
the subprojects under their appropriate location using read-tree
--prefix=<subdir>/ repeatedly.
To write out a tree object from such an index for a subproject,
write-tree --prefix=<subdir>/ is used.
Signed-off-by: Junio C Hamano <junkio@cox.net>
With "--prefix=<path>/" option, read-tree keeps the current
index contents, and reads the contents of named tree-ish under
directory at `<prefix>`. The original index file cannot have
anything at the path `<prefix>` itself, and have nothing in
`<prefix>/` directory. This can be used to graft an
independent tree into a subdirectory of the current index.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* fix:
Fix trivial typo in git-log man page.
Properly render asciidoc "callouts" in git man pages.
Fix up remaining man pages that use asciidoc "callouts".
Update the git-branch man page to include the "-r" option,
annotate: display usage information if no filename was given
annotate: fix warning about uninitialized scalar
git-am --resolved: more usable error message.
Adds an xsl fragment to render docbook callouts when
converting to man page format. Update the Makefile
to have "xmlto" use it when generating man pages.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
Unfortunately docbook does not allow a callout to be
referenced from inside a callout list description.
Rewrite one paragraph in git-reset man page to work
around this limitation.
Signed-off-by: Sean Estabrooks <seanlkml@sympatico.ca>
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>
This has been an unfortunate sideway in the git API evolution.
We use git-repo-config for all the other .git/config interaction
so let's also use git-repo-config -l for the variable listing.
Signed-off-by: Petr Baudis <pasky@suse.cz>
This adds git-repo-config --list (or git-repo-config -l) support,
similar to what git-var -l does now (to be phased out so that we
have a single sane interface to the config file instead of fragmented
and confused API).
Signed-off-by: Petr Baudis <pasky@suse.cz>
This patch adds a Documentation/config.txt file included by git-repo-config
and currently aggregating hopefully all the available git plumbing / core
porcelain configuration variables, as well as briefly describing the format.
It also updates an outdated bit of the example in git-repo-config(1).
Signed-off-by: Petr Baudis <pasky@suse.cz>
The new --reference flag introduced to git-clone in
GIT 1.3.0 was not documented but is rather handy.
So document it.
Also corrected a minor issue with the documentation for the
-s flag; the info/alternates file name was spelled wrong.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
With this option, git prepends a diffstat in front of the patch.
Since I really, really do not know what a diffstat of a combined diff
("merge diff") should look like, the diffstat is not generated for these.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Now, you can say "git diff --stat" (to get an idea how many changes are
uncommitted), or "git log --stat".
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Ok this really should be the good version. The option
handling has been reworked to be automation safe.
Currently to import the -mm tree I have to work around
git-apply by using patch. Because some of Andrews
patches in quilt will only apply with fuzz.
I started out implementing a --fuzz option and then I realized
fuzz is not a very safe concept for an automated system. What
you really want is a minimum number of context lines that must
match. This allows policy to be set without knowing how many
lines of context a patch actually provides. By default
the policy remains to match all provided lines of context.
Allowng git-apply to match a restricted set of context makes
it much easier to import the -mm tree into git. I am still only
processing 1.5 to 1.6 patches a second for the 692 patches in
2.6.17-rc1-mm2 is still painful but it does help.
If I just loop through all of Andrews patches in order
and run git-apply --index -C1 I process the entire patchset
in 1m53s or about 6 patches per second. So running
git-mailinfo, git-write-tree, git-commit-tree, and
git-update-ref everytime has a measurable impact,
and shows things can be speeded up even more.
All of these timings were taking on my poor 700Mhz Athlon
with 512MB of ram. So people with fast machiens should
see much better performance.
When a match is found after the number of context are reduced a
warning is generated. Since this is a rare event and possibly
dangerous this seems to make sense. Unless you are patching
a single file the error message is a little bit terse at
the moment, but it should be easy to go back and fix.
I have also updated the documentation for git-apply to reflect
the new -C option that sets the minimum number of context
lines that must match.
Signed-off-by: Eric W. Biederman <ebiederm@xmission.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This tries to clarify the -c/-cc documentation and clean up the style and
grammar.
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Once the content has been generated, the formatting elves can reorder
it to be pretty...
Signed-off-by: Francis Daly <francis@daoine.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The "--amend" option is used to amend the tip of the current branch. This
documentation text was copied straight from the commit that implemented it.
Some minor format tweaks for asciidoc were taken from work by Francis Daly
in commit b0d08a5.. It looks good now also in the html page.
[jc: amended further to follow the recommendation by Francis in
commit 3070b60].
Signed-off-by: Marco Roeland <marco.roeland@xs4all.nl>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This command removes untracked files from the working tree. This
implementation is based on cg-clean with some simplifications. The
documentation is included.
[jc: with trivial documentation fix, noticed by Jakub Narebski]
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-diff-* --pickaxe-regex will change the -S pickaxe to match
POSIX extended regular expressions instead of fixed strings.
The regex.h library is a rather stupid interface and I like pcre too, but
with any luck it will be everywhere we will want to run Git on, it being
POSIX.2 and all. I'm not sure if we can expect platforms like AIX to
conform to POSIX.2 or if win32 has regex.h. We might add a flag to
Makefile if there is a portability trouble potential.
Signed-off-by: Petr Baudis <pasky@suse.cz>
I'm afraid I'll be accused of trying to suck all the jokes and the
personality out of the git documentation. I'm not! Really!
That said, "man git" is one of the first things a new user is likely try,
and it seems a little cruel to start off with a somewhat obscure joke
about the architecture of git.
So instead I'm trying for a relatively straightforward description of what
git does, and what features distinguish it from other systems, together
with immediate links to introductory documentation.
I also did some minor reorganization in an attempt to clarify the
classification of commands. And revised a bit for conciseness (as is
obvious from the diffstat--hopefully I didn't cut anything important).
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* master:
Optionally do not list empty directories in git-ls-files --others
Document git-rebase behavior on conflicts.
Fix error handling for nonexistent names
Without the --directory flag, git-ls-files wouldn't ever list directories,
producing no output for empty directories, which is good since they cannot
be added and they bear no content, even untracked one (if Git ever starts
tracking directories on their own, this should obviously change since the
content notion will change).
With the --directory flag however, git-ls-files would list even empty
directories. This may be good in some situations but sometimes you want to
prevent that. This patch adds a --no-empty-directory option which makes
git-ls-files omit empty directories.
Signed-off-by: Petr Baudis <pasky@suse.cz>
* rs/tar-tree:
tar-tree: Use the prefix field of a tar header
tar-tree: Remove obsolete code
tar-tree: Use write_entry() to write the archive contents
tar-tree: Introduce write_entry()
tar-tree: Use SHA1 of root tree for the basedir
git-apply: safety fixes
Removed bogus "<snap>" identifier.
Clarify and expand some hook documentation.
commit-tree: check return value from write_sha1_file()
send-email: Identify author at the top when sending e-mail
Format tweaks for asciidoc.
Clarify update and post-update hooks.
Made a few references to the hooks documentation.
Signed-off-by: Jon Loeliger <jdl@jdl.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Some documentation "options" were followed by independent preformatted
paragraphs. Now they are associated plain text paragraphs. The
difference is clear in the generated html.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/name:
core.warnambiguousrefs: warns when "name" is used and both "name" branch and tag exists.
contrib/git-svn: allow rebuild to work on non-linear remote heads
http-push: don't assume char is signed
http-push: add support for deleting remote branches
Be verbose when !initial commit
Fix multi-paragraph list items in OPTIONS section
http-fetch: nicer warning for a server with unreliable 404 status
This patch makes the html docs right, makes the asciidoc docs a bit odd
but consistent with what is there already, and makes the manpages look
OK using docbook-xsl 1.68, but miss a paragraph separator when using 1.69.
For the manpages, current is like
-A <author_file>
Read a file with lines on the form
username = User's Full Name <email@addr.es>
and use "User's Full Name <email@addr.es>" as the GIT
With this patch, docbook-xsl v1.68 looks like
-A <author_file>
Read a file with lines on the form
username = User's Full Name <email@addr.es>
and use "User's Full Name <email@addr.es>" as the GIT author and
while docbook-xsl v1.69 becomes
-A <author_file>
Read a file with lines on the form
username = User's Full Name <email@addr.es>
and use "User's Full Name <email@addr.es>" as the GIT author and
The extra indentation is to keep the v1.69 manpage looking sane.
* master:
3% tighter packs for free
Rewrite synopsis to clarify the two primary uses of git-checkout.
Fix minor typo.
Reference git-commit-tree for env vars.
Clarify git-rebase example commands.
Document the default source of template files.
Call out the two different uses of git-branch and fix a typo.
Add git-show reference
The fsck-objects command (back then it was called fsck-cache)
used to complain if objects referred to by files in .git/refs/
or objects stored in files under .git/objects/??/ were not found
as stand-alone SHA1 files (i.e. found in alternate object pools
or packed archives stored under .git/objects/pack). Back then,
packs and alternates were new curiosity and having everything as
loose objects were the norm.
When we adjusted the behaviour of fsck-cache to consider objects
found in packs are OK, we introduced the --standalone flag as a
backward compatibility measure.
It still correctly checks if your repository is complete and
consists only of loose objects, so in that sense it is doing the
"right" thing, but checking that is pointless these days. This
commit removes --standalone flag.
See also:
23676d407c8a498a05c3
Signed-off-by: Junio C Hamano <junkio@cox.net>
The code which tried to update the master branch was somewhat broken.
=> People should do that manually, with "git merge".
Signed-off-by: Matthias Urlichs <smurf@smurf.noris.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
docbook-xsl v1.68 incorrectly converts "<screen>" from docbook to
manpage by not rendering it verbatim. v1.69 handles it correctly, but
not many current popular distributions ship with it.
asciidoc by default converts "listingblock" to "<screen>". This change
causes asciidoc in git to convert "listingblock" to "<literallayout>", which
both old and new docbook-xsl handle correctly.
The difference can be seen in any manpage which includes a multi-line
example, such as git-branch.
[jc: the original patch was an disaster for html backends, so I made
it apply only to docbook backends. ]
Signed-off-by: Junio C Hamano <junkio@cox.net>
Pair up git-add and git-rm by adding a 'see also' section that
references the opposite command to each of their documentation files.
Signed-off-by: Junio C Hamano <junkio@cox.net>
In particular, git-tools.txt isn't a manpage, and my Asciidoc gets upset
by it. The simplest fix is to Remove articles from the list of manpages
the Makefile.
Signed-off-by: Mark Wooding <mdw@distorted.org.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... and stripped trailing whitespace to appease the Gods...
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Sometimes it is convient for a Porcelain to be able to checkout all
unmerged files in all stages so that an external merge tool can be
executed by the Porcelain or the end-user. Using git-unpack-file
on each stage individually incurs a rather high penalty due to the
need to fork for each file version obtained. git-checkout-index -a
--stage=all will now do the same thing, but faster.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* lt/rev-list:
setup_revisions(): handle -n<n> and -<n> internally.
git-log (internal): more options.
git-log (internal): add approxidate.
Rip out merge-order and make "git log <paths>..." work again.
Tie it all together: "git log"
Introduce trivial new pager.c helper infrastructure
git-rev-list libification: rev-list walking
Splitting rev-list into revisions lib, end of beginning.
rev-list split: minimum fixup.
First cut at libifying revlist generation
A brief survey of useful git tools, including third-party
and external projects.
Signed-off-by: Marco Costalba <mcostalba@gmail.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Found with:
for i in *.txt; do
grep -A 2 "SYNOPSIS" "$i" | grep -q "^\[verse\]$" && continue
multiline=$(grep -A 3 "SYNOPSIS" "$i" | tail -n 1)
test -n "$multiline" && echo "$i: $multiline"
done
Signed-off-by: Jonas Fonseca <fonseca@diku.dk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We were missing the --whitespace option in the usage string for
git-apply and git-am, so this commit adds them.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Well, assuming breaking --merge-order is fine, here's a patch (on top of
the other ones) that makes
git log <filename>
actually work, as far as I can tell.
I didn't add the logic for --before/--after flags, but that should be
pretty trivial, and is independent of this anyway.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since git-checkout-index is often used from scripts which
may have a stream of filenames they wish to checkout it is
more convenient to use --stdin than xargs. On platforms
where fork performance is currently sub-optimal and
the length of a command line is limited (*cough* Cygwin
*cough*) running a single git-checkout-index process for
a large number of files beats spawning it multiple times
from xargs.
File names are still accepted on the command line if
--stdin is not supplied. Nothing is performed if no files
are supplied on the command line or by stdin.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When the user specifies a username -> Full Name <email@addr.es> map
file with the -A option, save a copy of that file as
$git_dir/svn-authors. When running git-svnimport with an existing GIT
directory, use $git_dir/svn-authors (if it exists) unless a file was
explicitly specified with -A.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-cvsimport uses a username => Full Name <email@addr.es> mapping
file with this syntax:
kha=Karl Hasselström <kha@treskal.com>
Since there is no reason to use another format for git-svnimport, use
the same format.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Read a file with lines on the form
username User's Full Name <email@addres.org>
and use "User's Full Name <email@addres.org>" as the GIT author and
committer for Subversion commits made by "username". If encountering a
commit made by a user not in the list, abort.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Put the value of the svn:ignore property in a regular file when
converting a Subversion repository to GIT. The Subversion and GIT
ignore syntaxes are similar enough that it often just works to set the
filename to .gitignore and do nothing else.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
I added the -r option to git-svnimport some time ago, but forgot to
update the usage summary in the documentation.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds a git-rm command which provides convenience similar to
git-add, (and a bit more since it takes care of the rm as well if
given -f).
Like git-add, git-rm expands the given path names through
git-ls-files. This means it only acts on files listed in the
index. And it does act recursively on directories by default, (no -r
needed as in the case of rm itself). When it recurses, it does not
remove empty directories that are left behind.
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-cvsserver is highly functional. However, not all methods are implemented,
and for those methods that are implemented, not all switches are implemented.
All the common read operations are implemented, and add/remove/commit are
supported.
Testing has been done using both the CLI CVS client, and the Eclipse CVS
plugin. Most functionality works fine with both of these clients.
Currently git-cvsserver only works over SSH connections, see the
Documentation for more details on how to configure your client. It
does not support pserver for anonymous access but it should not be
hard to implement. Anonymous access will need tighter input validation.
In our very informal tests, it seems to be significantly faster than a real
CVS server.
This utility depends on a version of git-cvsannotate that supports -S and on
DBD::SQLite.
Licensed under GPLv2. Copyright The Open University UK.
Authors: Martyn Smith <martyn@catalyst.net.nz>
Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
* fix:
git-push: Update documentation to describe the no-refspec behavior.
format-patch: pretty-print timestamp correctly.
git-add: Add support for --, documentation, and test.
* jc/pack-reuse:
pack-objects: avoid delta chains that are too long.
git-repack: allow passing a couple of flags to pack-objects.
pack-objects: finishing touches.
pack-objects: reuse data from existing packs.
* jc/nostat:
cache_name_compare() compares name and stage, nothing else.
"assume unchanged" git: documentation.
ls-files: split "show-valid-bit" into a different option.
"Assume unchanged" git: --really-refresh fix.
ls-files: debugging aid for CE_VALID changes.
"Assume unchanged" git: do not set CE_VALID with --refresh
"Assume unchanged" git
It turns out that the git-push documentation didn't describe what it
would do when not given a refspec, (not on the command line, nor in a
remotes file). This is fairly important for the user who is trying to
understand operations such as:
git clone git://something/some/where
# hack, hack, hack
git push origin
I tracked the mystery behavior down to git-send-pack and lifted the
relevant portion of its documentation up to git-push, (namely that all
refs existing both locally and remotely are updated).
Signed-off-by: Carl Worth <cworth@cworth.org>
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>
This adds support to git-add to allow the common -- to separate
command-line options and file names. It adds documentation and a new
git-add test case as well.
[jc: this should apply to 1.2.X maintenance series, so I reworked
git-ls-files --error-unmatch test. ]
Signed-off-by: Junio C Hamano <junkio@cox.net>
A new flag -q makes underlying pack-objects less chatty.
A new flag -f forces delta to be recomputed from scratch.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This introduces --no-reuse-delta option to disable reusing of
existing delta, which is a large part of the optimization
introduced by this series. This may become necessary if
repeated repacking makes delta chain too long. With this, the
output of the command becomes identical to that of the older
implementation. But the performance suffers greatly.
It still allows reusing non-deltified representations; there is
no point uncompressing and recompressing the whole text.
It also adds a couple more statistics output, while squelching
it under -q flag, which the last round forgot to do.
$ time old-git-pack-objects --stdout >/dev/null <RL
Generating pack...
Done counting 184141 objects.
Packing 184141 objects....................
real 12m8.530s user 11m1.450s sys 0m57.920s
$ time git-pack-objects --stdout >/dev/null <RL
Generating pack...
Done counting 184141 objects.
Packing 184141 objects.....................
Total 184141, written 184141 (delta 138297), reused 178833 (delta 134081)
real 0m59.549s user 0m56.670s sys 0m2.400s
$ time git-pack-objects --stdout --no-reuse-delta >/dev/null <RL
Generating pack...
Done counting 184141 objects.
Packing 184141 objects.....................
Total 184141, written 184141 (delta 134833), reused 47904 (delta 0)
real 11m13.830s user 9m45.240s sys 0m44.330s
There is one remaining issue when --no-reuse-delta option is not
used. It can create delta chains that are deeper than specified.
A<--B<--C<--D E F G
Suppose we have a delta chain A to D (A is stored in full either
in a pack or as a loose object. B is depth1 delta relative to A,
C is depth2 delta relative to B...) with loose objects E, F, G.
And we are going to pack all of them.
B, C and D are left as delta against A, B and C respectively.
So A, E, F, and G are examined for deltification, and let's say
we decided to keep E expanded, and store the rest as deltas like
this:
E<--F<--G<--A
Oops. We ended up making D a bit too deep, didn't we? B, C and
D form a chain on top of A!
This is because we did not know what the final depth of A would
be, when we checked objects and decided to keep the existing
delta. Unfortunately, deferring the decision until just before
the deltification is not an option. To be able to make B, C,
and D candidates for deltification with the rest, we need to
know the type and final unexpanded size of them, but the major
part of the optimization comes from the fact that we do not read
the delta data to do so -- getting the final size is quite an
expensive operation.
To prevent this from happening, we should keep A from being
deltified. But how would we tell that, cheaply?
To do this most precisely, after check_object() runs, each
object that is used as the base object of some existing delta
needs to be marked with the maximum depth of the objects we
decided to keep deltified (in this case, D is depth 3 relative
to A, so if no other delta chain that is longer than 3 based on
A exists, mark A with 3). Then when attempting to deltify A, we
would take that number into account to see if the final delta
chain that leads to D becomes too deep.
However, this is a bit cumbersome to compute, so we would cheat
and reduce the maximum depth for A arbitrarily to depth/4 in
this implementation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
New -r flag for prepending the corresponding Subversion revision
number to each commit message.
Signed-off-by: Karl Hasselström <kha@treskal.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Since Junio used this in an example, and I've personally tried to use it, I
suppose the option should actually exist.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
The documentation was mistakenly describing the --only semantics to
be default. The 1.2.0 release and its maintenance series 1.2.X will
keep the traditional --include semantics as the default. Clarify the
situation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This changes the "git commit paths..." to default to --only
semantics from traditional --include semantics, as agreed on the
list.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This howto consists of a footnote from an email by JC to the git
mailing list (<7vfyms0x4p.fsf@assigned-by-dhcp.cox.net>).
Signed-off-by: Kent Engstrom <kent@lysator.liu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Currently, git-repo-config will just return the raw value of option
as specified in the config file; this makes things difficult for scripts
calling it, especially if the value is supposed to be boolean.
This patch makes it possible to ask git-repo-config to check if the option
is of the given type (int or bool) and write out the value in its
canonical form. If you do not pass --int or --bool, the behaviour stays
unchanged and the raw value is emitted.
This also incidentally fixes the segfault when option with no value is
encountered.
[jc: tweaked the option parsing a bit to make it easier to see
that the patch does not change anything but the type stuff in
the diff output. Also changed to avoid "foo ? : bar" construct. ]
Signed-off-by: Petr Baudis <pasky@suse.cz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't mention it in docs or --help output.
Remove mbox, date and author variables from git-format-patch.sh.
Use DESCRIPTION text from man-page to update LONG_USAGE output. It's
a bit silly to have two texts saying the same thing in different words,
and I'm too lazy to update both.
Signed-off-by: Andreas Ericsson <ae@op5.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
- "git commit" without _any_ parameter keeps the traditional
behaviour. It commits the current index.
We commit the whole index even when this form is run from a
subdirectory.
- "git commit --include paths..." (or "git commit -i paths...")
is equivalent to:
git update-index --remove paths...
git commit
- "git commit paths..." acquires a new semantics. This is an
incompatible change that needs user training, which I am
still a bit reluctant to swallow, but enough people seem to
have complained that it is confusing to them. It
1. refuses to run if $GIT_DIR/MERGE_HEAD exists, and reminds
trained git users that the traditional semantics now needs
-i flag.
2. refuses to run if named paths... are different in HEAD and
the index (ditto about reminding). Added paths are OK.
3. reads HEAD commit into a temporary index file.
4. updates named paths... from the working tree in this
temporary index.
5. does the same updates of the paths... from the working
tree to the real index.
6. makes a commit using the temporary index that has the
current HEAD as the parent, and updates the HEAD with this
new commit.
- "git commit --all" can run from a subdirectory, but it updates
the index with all the modified files and does a whole tree
commit.
- In all cases, when the command decides not to create a new
commit, the index is left as it was before the command is
run. This means that the two "git diff" in the following
sequence:
$ git diff
$ git commit -a
$ git diff
would show the same diff if you abort the commit process by
making the commit log message empty.
This commit also introduces much requested --author option.
$ git commit --author 'A U Thor <author@example.com>'
Signed-off-by: Junio C Hamano <junkio@cox.net>
In a workflow that employs relatively long lived topic branches,
the developer sometimes needs to resolve the same conflict over
and over again until the topic branches are done (either merged
to the "release" branch, or sent out and accepted upstream).
This commit introduces a new command, "git rerere", to help this
process by recording the conflicted automerge results and
corresponding hand-resolve results on the initial manual merge,
and later by noticing the same conflicted automerge and applying
the previously recorded hand resolution using three-way merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The sections on git urls and remotes files in the git-fetch,
git-pull, and git-push manpages seem long enough to be worth a
manpage section of their own.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The push and pull man pages include a bunch of shared text from
pull-fetch-param.txt. This simplifies maintenance somewhat, but
there's actually quite a bit of text that applies only to one or the
other.
So, separate out the push- and pull/fetch-specific text into
pull-fetch-param.txt and git-push.txt, then include the largest chunk
of common stuff (the description of protocols and url's) from
urls.txt. That cuts some irrelevant stuff from the man pages without
making us duplicate too much.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
We still talked about HEAD symlinks but these days we use
symrefs by default.
Also 'failed/prevented' message is now gone from the merge
output.
Signed-off-by: Junio C Hamano <junkio@cox.net>
* jc/daemon:
daemon: extend user-relative path notation.
daemon: Set SO_REUSEADDR on listening sockets.
daemon: do not forbid user relative paths unconditionally under --base-path
* mw/http:
http-fetch: Tidy control flow in process_alternate_response
http: Turn on verbose Curl messages if GIT_CURL_VERBOSE set in environment
http-fetch: Fix message reporting rename of object file.
http-fetch: Fix object list corruption in fill_active_slots().
Also reorganizes the man page to list options alphabetically.
Signed-off-by: Ryan Anderson <ryan@michonline.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Earlier, we made --base-path to automatically forbid
user-relative paths, which was probably a mistake. This
introduces --user-path (or --user-path=path) option to control
the use of user-relative paths independently. The latter form
of the option can be used to restrict accesses to a part of each
user's home directory, similar to "public_html" some webservers
supports.
If we're invoked with --user-path=FOO option, then a URL of the
form git://~USER/PATH/... resolves to the path HOME/FOO/PATH/...,
where HOME is USER's home directory.
[jc: This is much reworked by me so bugs are mine, but the
original patch was done by Mark Wooding.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
A misguided attempt to show logs at all time was inserted only to
the documentation of this flag. Worse yet, it was not even implemented,
causing more confusion. Drop it.
We might want to have an option to show --pretty even when there is no
diff output, but that is applicable to all forms of diff, not just --cc.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This only applies to traditional diffs, not to git diffs.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Here's some changes to the cvs-migration.txt. As usual, in my attempt
to make things clearer someone may have found I've made them less so, or
I may have just gotten something wrong; so any review is welcomed.
I can break up this sort of thing into smaller steps if preferred, the
monolothic patch is just a bit simpler for me for this sort of
thing.
I moved the material describing shared repository management from
core-tutorial.txt to cvs-migration.txt, where it seems more appropriate,
and combined two sections to eliminate some redundancy.
I also revised the earlier sections of cvs-migration.txt, mainly trying
to make it more concise.
I've left the last section of cvs-migration.txt (on CVS annotate
alternatives) alone for now.
Signed-off-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
