"Modifying" an old commit by checking it out, --amend'ing it, then
rebasing on top of it, is a slightly cumbersome technique, but I've
found it useful frequently enough to make it seem worth documenting.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The content-addressable design is too important not to be worth at least
a brief mention a little earlier on.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The generated user manual is rather hard to read thanks to the lack of
the css that's supposed to be included from docbook-xsl.css.
I'm totally ignorant of the toolchain; grubbing through xmlto and
related scripts, the easiest way I could find to ensure that the
generated html links to the stylesheet is by calling xsltproc directly.
Maybe there's some better way.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
As Linus pointed out recently on the mailing list,
git reset --hard HEAD^
doesn't undo a merge in the case where the merge did a fast-forward. So
the rcommendation here is a little dangerous.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The git-cvsimport argument that specifies a cvs module to import should
probably be included in the default example.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This should only be set based on the capability of your
compiler/library to support c99 format specifiers. In this
case the version of gcc/newlib and indirectly the version
of Cygwin. It should probably only be set in your config.mak
file.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
In particular, the second parameter in the call to iconv() will
cause this warning if your library declares iconv() with the
second (input buffer pointer) parameter of type const char **.
This is the old prototype, which is none-the-less used by the
current version of newlib on Cygwin. (It appears in old versions
of glibc too).
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
On Cygwin the wchar_t type is an unsigned short (16-bit) int.
This results in the above warnings from the return statement in
the wcwidth() function (in particular, the expressions involving
constants with values larger than 0xffff). Simply replace the
use of wchar_t with an unsigned int, typedef-ed as ucs_char_t.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The function at issue being initgroups() from the <grp.h> header
file. On Cygwin, setting _XOPEN_SOURCE suppresses the definition
of initgroups(), which causes the warning while compiling daemon.c.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Junio C Hamano <junkio@cox.net>
When we cannot fast forward the working tree and the current
branch, git-merge did not exit with non-zero status.
Noticed by Larry Streepy, the section to be fixed identfied by
Johannes Schindelin.
Signed-off-by: Junio C Hamano <junkio@cox.net>
By default allowunannotated is unset in the repo config, hence
$allowunannotated is empty, and must be quoted to not break the syntax.
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Mark continuation paragraphs of list entries as such to avoid
getting literal paragraphs instead.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Mark the continuation paragraph of a list entry as such to avoid
getting a literal paragraph instead.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Adding dependencies on included files to the generated man pages is
wrong - includes are processed by asciidoc, therefore the intermediate
Docbook XML files really depend on included files. Because of these
wrong dependencies the man pages were not rebuilt properly if the
intermediate XML files were left in the tree.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
config.mak.autogen is already there. Without this change it is not
possible to override mandir in config.mak.
Signed-off-by: Uwe Kleine-König <ukleinek@informatik.uni-freiburg.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If not otherwise specified, take the default coding system for commits
from the 'i18n.commitencoding' repository configuration value.
Also set the buffer-file-coding-system variable in the log buffer to
make the selected coding system visible on the modeline.
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't fail if the summary line in an arch commit is empty. In this case,
try to use the first line in the commit message followed by an ellipsis.
In addition, if the summary is multi-line, it is joined on a single line.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Starting from offset 11 might have been good back when it was
only used for updating "refs/heads/*", but it is used to update
"info/refs" and "refs/tags/*" as well.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Unless the -c option is given, and the commit to cvs was successful,
.msg shouldn't be deleted to be able to run the command suggested by
git-cvsexportcommit.
See http://bugs.debian.org/412732
Signed-off-by: Gerrit Pape <pape@smarden.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A filesystem might not be able to completely supply our pread
request in one system call, such as if we are reading data from a
network file system and the requested length is just simply huge.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A pair of commits on January 8th added option documentation (for -a,
-S and -L) in the middle of the documentation for the -A option. This
makes -A's documentation contiguous again.
Signed-off-by: Michael Poole <mdpoole@troilus.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
So when we do
git show v1.4.4..v1.5.0
that's an illogical thing to do, since "git show" is defined to be a
non-revision-walking action, which means the range operator be pointless
and wrong. The fact that we happily accept it (and then _only_ show
v1.5.0, which is the positive end of the range) is quite arguably not very
logical.
We should complain, and say that you can only do "no_walk" with positive
refs. Negative object refs really don't make any sense unless you walk
the obejct list (or you're "git diff" and know about ranges explicitly).
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix asciidoc markup so that the man page is properly formatted in the
EXAMPLES section.
Signed-off-by: "Theodore Ts'o" <tytso@mit.edu>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Internal function apply_line() is called to copy both context lines
and added lines to the output buffer, while possibly fixing the
whitespace breakages depending on --whitespace=strip settings.
However, it did its fix-up on both context lines and added lines.
This resulted in two symptoms:
(1) The number of lines reported to have been fixed up included
these context lines.
(2) However, the lines actually shown were limited to the added
lines that had whitespace breakages.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Few of us use git to compare or even version-control 2GB files,
but when we do, we'll want it to work.
Reading a recent patch, I noticed two lines like this:
int len = st.st_size;
Instead of "int", that should be "size_t". Otherwise, in the
non-symlink case, with 64-bit size_t, if the file's size is 2GB,
the following xmalloc will fail:
result = xmalloc(len + 1);
trying to allocate 2^64 - 2^31 + 1 bytes (assuming sign-extension
in the int-to-size_t promotion). And even if it didn't fail, the
subsequent "result[len] = 0;" would be equivalent to an unpleasant
"result[-2147483648] = 0;"
The other nearby "int"-declared size variable, sz, should also be of
type size_t, for the same reason. If sz ever wraps around and becomes
negative, xread will corrupt memory _before_ the "result" buffer.
Signed-off-by: Jim Meyering <jim@meyering.net>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It basically considers all the continuation lines to be lines of their
own, and if the total line is bigger than what we can fit in it, we just
truncate the result rather than stop in the middle and then get confused
when we try to parse the "next" line (which is just the remainder of the
first line).
[jc: added test, and tightened boundary a bit per list discussion.]
Signed-off-by: Linus Torvalds <torvalds@linux-foundation.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
[jc: the original from Pavel was limiting the variable names to only
fetch and url, but I loosened it to take valid variable names.]
[jc: cherry-picked from 'master', since people seem to be reinventing
this many times.]
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
"git-diff-files --cc" to show conflicts during merge did not pass
the correct mode information for the working tree down, and showed
bogus combined diff.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Commit 3af244ca added unlink(2) before running symlink(2) to
update the working tree with the merge result, but it was
unlinking a wrong path. This resulted in loss of the path
pointed by a symlink.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Ancient commit e2b6a9d0 added code to pass "file modes" from
merge-index to merge-one-file, and then later commit 54dd99a1
wanted to make sure we do not end up creating a nonsense symlink
that points at a path whose name contains conflict markers.
However, nobody noticed that the code in merge-index added by
e2b6a9d0 were stripping the S_IFMT bits and the code in 54dd99a1
was meaningless. This fixes it.
Signed-off-by: Junio C Hamano <junkio@cox.net>
If a repository ever gets in a situation where there are too many
packs (more than 60 or so), perhaps because of frequent use of
git-fetch -k or incremental git-repack, then it becomes impossible to
fully repack the repository with git-repack -a. That command just
dies with the cryptic message
fatal: too many internal rev-list options
This message comes from git-pack-objects, which is passed one command
line option like --unpacked=pack-<SHA1>.pack for each pack file to be
repacked. However, the current code has a static limit of 64 command
line arguments and just aborts if more arguments are passed to it.
Fix this by dynamically allocating the array of command line
arguments, and doubling the size each time it overflows.
Signed-off-by: Roland Dreier <roland@digitalvampire.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
J. Bruce Fields