Setting CURLOPT_HTTPHEADER doesn't add HTTP headers, but replaces whatever
set of headers was configured before, so setting to NULL doesn't have any
magic meaning, and is pretty much useless when setting to another list
right after.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
It appears that despite being initialized, it was never used.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When a downloaded ref doesn't contain a sha1, the error message displays
a random sha1 because of uninitialized memory. This happens when cloning
a repository that is already a clone of another one, in which case
refs/remotes/origin/HEAD is a symref.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Avoids horrible 1-byte write(2) calls and cleans up the logic a bit.
Signed-off-by: Kristian Høgsberg <krh@redhat.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The specialized pool allocator fast-import uses aligned objects on the
size of a pointer, which was not sufficient at least on Sparc. Instead,
make the alignment for objects of type unitmax_t.
Signed-off-by: David S. Miller <davem@davemloft.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The configuration reader to enumerate branches that have configuration
data were not careful enough and failed to skip "branch.<variable>"
entries (e.g. branch.autosetupmerge). This resulted in bogus attempt to
allocate huge memory.
Noticed by David Miller.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
After tentatively applying a patch from a contributor, you can get a
replacement patch with corrected code and unusable commit log message.
In such a case, this sequence ought to give you an editor based on the
message in the earlier commit, to let you describe an incremental
improvement:
git reset --hard HEAD^ ;# discard the earlier one
git am <corrected-patch
git commit --amend -c HEAD@{1}
Unfortunately, --amend insisted reusing the message from the commit
being amended, ignoring the -c option. This corrects it.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, git-svn would ignore cases where the path we're
tracking is removed from the repository. This was to prevent
heads with follow-parent from ending up with a tree full of
empty revisions (and thus breaking rename detection).
The previous behavior is fine until the path we're tracking
is re-added later on, leading to the old files being merged
in with the new files in the directory (because the old
files were never marked as deleted)
We will now only remove all the old files locally that were
deleted remotely iff we detect the directory we're in is being
created from scratch.
Thanks for Marcus D. Hanwell for the bug report and
Peter Baumann for the analysis.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Because we feed the changed filenames to CVS on the command
line, it was possible for massive commits to overflow the
system exec limits. Instead, we now do an xargs-like split
of the arguments.
This means that we lose some of the atomicity of calling CVS
in one shot. Since CVS commits are not atomic, but the CVS
protocol is, the possible effects of this are not clear;
however, since CVS doesn't provide a different interface,
this is our only option for large commits (short of writing
a CVS client library).
The argument size limit is arbitrarily set to 64kB. This
should be high enough to trigger only in rare cases where it
is necessary, so normal-sized commits are not affected by
the atomicity change.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Lifted from the log message of c553ca25bd
(pack-objects: learn about pack index version 2).
Acked-by: Nicolas Pitre <nico@cam.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Inside xdiff library, the number of context lines is represented in
long, not int.
Noticed by Peter Baumann.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This implements earlier Linus's optimization to trim common lines at the
end before passing them down to low level xdiff interface for all of our
xdiff users.
We could later enhance this to also trim common leading lines, but that
would need tweaking the output function to add the number of lines
trimmed at the beginning to line numbers that appear in the hunk
headers.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This inserts a new function xdi_diff() that currently does not
do anything other than calling the underlying xdl_diff() to the
callchain of current callers of xdl_diff() function.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Being git, we can generate these very quickly on the fly as
needed, so there's no point in wasting space for these things
for large projects.
Signed-off-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The current parsing for From: and Signed-off-by: lines handles fully
specified names:
From: Full Name <email@address>
Expand this to include the raw email addresses and straight "names":
From: email@address -> email <email@address>
From: Full Name -> Full Name <unknown>
Signed-off-by: Andy Whitcroft <apw@shadowen.org>
Acked-by: Eric Wong <normalperson@yhbt.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Shawn Bohrer <shawn.bohrer@gmail.com>
Acked-by: J. Bruce Fields <bfields@citi.umich.edu>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When recording a merge that conflicted and ends up in no changes after
manual resolution, commit callchain looked like this:
cmd_commit() ->
prepare_log_message() ->
run_status() ->
wt_status_print()
This invocation of run_status() is asked to find out if there is a
committable change, but it unconditionally gave instructions such as
"use git-add" at the same time. When in merge, we do allow an empty
change to be recorded, so after showing this message the code still went
ahead and made a commit.
This introduces "nowarn" parameter to run_status() to avoid these
useless messages. If we are not allowed to create an empty commit, we
already call run_status() again in the original codepath, and the
message will be shown from that call anyway.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cc/help:
RPM spec: Adjust htmldir
git-help -w: do not require to be in git repository
git.spec.in: remove python_path
Documentation: rename git.texi to user-manual.texi
Add git-browse-help to .gitignore
git-help -i: show info documentation from matching version of git
git-help -i: invoke info with document and node name
Documentation: add gitman.info target
Documentation: describe -w/--web option to "git-help".
Use {web,instaweb,help}.browser config options.
git-help: add -w|--web option to display html man page in a browser.
Documentation: describe -i/--info option to "git-help"
git-help: add -i|--info option to display info page.
The users used to be able to say "git help cat-file" from anywhere, but
the browse-help script insisted to be in a git repository, which caused
"git help -w cat-file" to barf outside. Correct it.
While at it, remove leftover debugging "echo".
Signed-off-by: Junio C Hamano <gitster@pobox.com>
* jc/shortlog-e:
shortlog: default to HEAD when the standard input is a tty
Invert numbers and names in the git-shortlog summary mode.
shortlog: document -e option
git-shortlog -e: show e-mail address as well
"diff --check" would only detect spaces before tabs if a tab was the
last character in the leading indent. Fix that and add a test case to
make sure the bug doesn't regress in the future.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The "-z" format is all about machine parsability, but showing renamed
paths as "common/{a => b}/suffix" makes it impossible. The scripts would
never have successfully parsed "--numstat -z -M" in the old format.
This fixes the output format in a (hopefully minimally) backward
incompatible way.
* The output without -z is not changed. This has given a good way for
humans to view added and deleted lines separately, and showing the
path in combined, shorter way would preserve readability.
* The output with -z is unchanged for paths that do not involve renames.
Existing scripts that do not pass -M/-C are not affected at all.
* The output with -z for a renamed path is shown in a format that can
easily be distinguished from an unrenamed path.
This is based on Jakub Narebski's patch. Bugs and documentation typos
are mine.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
For consistency, change "white space" and "whitespaces" to
"whitespace", fixing a couple of adjacent grammar problems in the
docs.
Signed-off-by: Wincent Colaiuta <win@wincent.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
XML_Parser were never freed. While at it, move the parser initialization to
right before it is needed.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Run diff_tree_release_paths in the appropriate places, and add a test to
avoid NULL dereference. Better safe than sorry.
Signed-off-by: Mike Hommey <mh@glandium.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Writing 1 elements of size 0-byte successfully will cause fwrite(3) to
return 0, and flagging it as error is a mistake.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When git-clone detects that it can perform a local clone it
follows a path that silently ignores the depth parameter.
Presumably if the user explicitly requests a shallow clone they
have a reason to prefer a space efficient clone of just the recent
history so bypass the local magic if the user specifies the depth
parameter.
Signed-off-by: Charles Bailey <charles@hashpling.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Instead of warning the user that it is expecting git log output from
the standard input (and waiting for the user to type the log from
the keyboard, which is a silly thing to do), default to traverse from
HEAD when there is no rev parameter given and the standard input is
a tty.
This factors out a useful helper "add_head()" from builtin-diff.c to a
more appropriate place revision.c while renaming it to more descriptive
name add_head_to_pending(), as that is what the function is about.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
We used to keep the blob data for each origin that has any remaining
line in the result, but this will get very costly with a huge file that
has a deep history. This patch releases the blob after we ran diff
between the child rev and its parents. When passing blame from a parent
to its parent (i.e. the grandparent), the blob data for the parent may
need to be read again, but it should be relatively cheap, thanks to
delta-base cache.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Previously, cloning an empty repository looked like this:
$ (mkdir parent && cd parent && git --bare init)
$ git-clone parent child
Initialized empty Git repository in /home/peff/clone/child/.git/
$ cd child
-bash: cd: child: No such file or directory
$ echo 'wtf?' | mail git@vger.kernel.org
Now we at least report that the clone was not successful.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Also make it `cut` friendly using a tab to separate the numbers and names.
Signed-off-by: Pierre Habouzit <madcoder@debian.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Originally written by Rémi Vanicat, I just changed the layout a little.
Signed-off-by: Rémi Vanicat <vanicat@debian.org>
Signed-off-by: Alexandre Julliard <julliard@winehq.org>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
This also shortens option descriptions to fit in 80 columns.
Signed-off-by: Johannes Sixt <johannes.sixt@telecom.at>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
git-config recently learned a --get-colorbool option. By
using it, we will get the same color=auto behavior that
other git commands have.
Specifically, this fixes the case where "color.diff = true"
meant "always" in git-svn, but "auto" in other programs.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
When deciding whether or not to turn on automatic color
support, git_config_colorbool checks whether stdout is a
tty. However, because we run a pager, if stdout is not a
tty, we must check whether it is because we started the
pager. This used to be done by checking the pager_in_use
variable.
This variable was set only when the git program being run
started the pager; there was no way for an external program
running git indicate that it had already started a pager.
This patch allows a program to set GIT_PAGER_IN_USE to a
true value to indicate that even though stdout is not a tty,
it is because a pager is being used.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
merge-recursive did not support merging trees that have conflicting
changes in submodules they contain, and died. Support it exactly the
same way as how it handles conflicting symbolic link changes --- mark it
as a conflict, take the tentative result from the current side, and
letting the caller resolve the conflict, without dying in merge_file()
function.
Also reword the error message issued when merge_file() has to die
because it sees a tree entry of type it does not support yet.
[jc: fixed up initial draft by Finn Arne Gangstad]
Signed-off-by: Junio C Hamano <gitster@pobox.com>
The scripted version relied on the nice "auto-strip the terminating LF"
behaviour shell gives to "var=$(cmd)" construct, but we have to roll
that ourselves.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Mike Hommey