git-svn: fix segfaults due to initial SVN pool being cleared
Some parts of SVN always seem to use it, even if the SVN::Ra
object we're using is no longer used and we've created a new one
in its place. It's also true that only one SVN::Ra connection
can exist at once... Using SVN::Pool->new_default when the
SVN::Ra object is created doesn't seem to help very much,
either...
Hopefully this fixes all segfault problems users have been
experiencing over the past few months.
This patch was originally intended to make the Perl GC more
sensitive to the SVN::Pool objects and not accidentally clean
them up when they shouldn't be (causing segfaults). That didn't
work, but this patch makes the code a bit cleaner regardless
Put our caches for get_dir and check_path calls directly into
the SVN::Ra object so they auto-expire when it is destroyed.
dirents returned by get_dir() no longer needs the pool object
stored persistently along with the cache data, as they'll be
converted to native Perl hash references.
Since calling rev_proplist repeatedly per-revision is no longer
needed in git-svn, we do not cache calls to it.
git-svn: don't drop the username from URLs when dcommit is run
We no longer store usernames in URLs stored in git-svn-id lines
for dcommit, so we shouldn't rely on those URLs when connecting
to the remote repository to commit.
git-config: do not forget seeing "a.b.var" means we are out of "a.var" section.
Earlier code tried to be half-careful and knew the logic that
seeing "a.var" after seeing "a.b.var" is a sign of the previous
"a.b." section has ended, but forgot it has to handle the other
way. Seeing "a.b.var" after seeing "a.var" is a sign that "a."
section has ended, so a new "a.var2" variable should be added
before the location "a.b.var" appears.
not only from the three defined: heads, tags and remotes.
Noticed when I tried to fetch the references created by git-p4-import.bat:
they are placed into separate namespace (refs/p4import/, to avoid showing
them in git-branch output). As canon_refs_list_for_fetch always prepended
refs/heads/ it was impossible, and annoying: it worked before. Normally,
the p4import references are useless anywhere but in the directory managed
by perforce, but in this special case the cloned directory was supposed
to be a backup, including the p4import branch: it keeps information about
where the imported perforce state came from.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
If you have /home/me/git symlink pointing at /pub/git/mine,
trying to clone from /pub/git/his/ using relative path would not
work as expected:
$ cd /home/me
$ cd git
$ ls ../
his mine
$ git clone -l -s -n ../his/stuff.git
This is because "cd ../his/stuff.git" done inside git-clone to
check if the repository is local is confused by $PWD, which is
set to /home/me, and tries to go to /home/his/stuff.git which is
different from /pub/git/his/stuff.git.
We could probably say "set -P" (or "cd -P") instead, if we know
the shell is POSIX, but the way the patch is coded is probably
more portable.
[jc: this is updated with Andy Whitcroft's improvements]
Build fails for git 1.5.1.3 on AIX, with the message:
utf8.c:66: error: conflicting types for 'wcwidth'
/.../lib/gcc/powerpc-ibm-aix5.3.0.0/4.0.3/include/string.h:266: error: previous declaration of 'wcwidth' was here
Fix this by renaming our static variant to our own name.
Signed-off-by: Amos Waterland <apw@us.ibm.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Randal L. Schwartz pointed out multiple times that we should be
testing the length of the name string here, not if it is "true".
The problem is the string '0' is actually false in Perl when we
try to evaluate it in this context, as '0' is 0 numerically and
the number 0 is treated as a false value. This would cause us
to break out of the import loop early if anyone had a file or
directory named "0".
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
It's just as much a work-in-progress, but at least now it's gotten
enough technical review to shake out most of the really bad lies, so
hopefully it doesn't do any actual damage. And if we encourage people
to read it, they'll be more likely to whine about it, which will help
get it fixed faster.
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
I cherry-picked some additional miscellaneous fixes from those suggested
by Santi Béjar, including fixes to:
- correct discussion of repository/HEAD->repository shortcut
- add mention of git-mergetool
- add mention of --track
- mention "-f" as well as "+" for fetch
Cc: Santi Béjar <sbejar@gmail.com> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
Santi Béjar points out that when telling people how to "introduce
themselves" to git we're advising them to replace their entire
.gitconfig file. Fix that.
Cc: "Santi Béjar <sbejar@gmail.com> Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
user-manual: clean up fast-forward and dangling-objects sections
The previous commit calls attention to the fact that we have two
sections each devoted to fast-forwards and to dangling objects. Revise
and attempt to differentiate them a bit. Some more reorganization may
be required later....
Any section lacking an id gets an annoying warning when you build
the manual. More seriously, the table of contents then generates
volatile id's which change with every build, with the effect that
we get URL's that change all the time.
The ID's are manually generated and sometimes inconsistent, but
that's OK.
XXX: what to do about the preface?
Signed-off-by: "J. Bruce Fields" <bfields@citi.umich.edu>
When you do this, existing "blame -C -C" would not find that the
latter half of the file2 came from the existing file1:
... both file1 and file2 are tracked ...
$ cat file1 >>file2
$ git add file1 file2
$ git commit
This is because we avoid the expensive find-copies-harder code
that makes unchanged file (in this case, file1) as a candidate
for copy & paste source when annotating an existing file
(file2). The third -C now allows it. However, this obviously
makes the process very expensive. We've actually seen this
patch before, but I dismissed it because it covers such a narrow
(and arguably stupid) corner case.
blame: Notice a wholesale incorporation of an existing file.
The -C option to blame tries to find a section of a preimage
file by running diff against the lines whose origin is still
unknown, and excluding the different parts. The code however
did not cover the case where the tail part of the section
matched, which we handle for the normal non-move/copy codepath.
This breakage was most visible when preimage file matches in its
entirety and failed to pass blame in such a case.
Most other documentation will frequently be read from an installation
of git so will naturally be associated with the installed version.
But these two documents in particular are often read from web pages
while users are still exploring git. It's important to mention
version 1.5.1 since these documents provide example commands that
won't work with previous versions of git.
git-svn dcommit exports commits to Subversion, then imports them back
to git again, and last but not least rebases or resets HEAD to the
last of the new commits. I guess this rebasing is convenient when
using just git, but when the commits to be exported are managed by
StGIT, it's really annoying. So add an option to disable this
behavior. And document it, too!
Signed-off-by: Karl Hasselström <kha@treskal.com> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
There is a mechanism PERL_PATH in the Makefile to specify path to
Perl binary, but sometimes it is convenient to let 'env' figure
out where Perl comes from, with PERL_PATH="/usr/bin/env perl".
Allowing this would make things easier to MacPorts, where we wish
to work with the MacPorts perl if it is installed, but fall back
to the system perl if it isn't.
Signed-off-by: Bryan Larsen <bryan@larsen.st> Signed-off-by: Junio C Hamano <junkio@cox.net>
This also improves the implementation to match how strndup is
specified (by GNU): if the length given is longer than the string,
only the string's length is allocated and copied, but the string need
not be null-terminated if it is at least as long as the given length.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
We broke the size-cache handling when we changed the function
signature of sha1_object_info() in 21666f1a. We obviously
wanted to cache the size we obtained when sha1_object_info()
succeeded, not when it failed.
http-fetch: Disable use of curl multi support for libcurl < 7.16.
curl_multi_remove_handle() is broken in libcurl < 7.16, in that it
doesn't correctly update the active handles count when a request is
aborted. This causes the transfer to hang forever waiting for the
handle count to become less than the number of active requests.
Signed-off-by: Alexandre Julliard <julliard@winehq.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
We can't unconditionally assign revision 1.1 to
newly added files. In case the file did exist in the
past and was deleted we need to honor the old
revision number.
Signed-off-by: Frank Lichtenheld <frank@lichtenheld.de> Signed-off-by: Junio C Hamano <junkio@cox.net>
Teach import-tars about GNU tar's @LongLink extension.
This extension allows GNU tar to process file names in excess of the 100
characters defined by the original tar standard. It does this by faking a
file, named '././@LongLink' containing the true file name, and then adding
the file with a truncated name. The idea is that tar without this
extension will write out a file with the long file name, and write the
contents into a file with truncated name.
Unfortunately, GNU tar does a lousy job at times. When truncating results
in a _directory_ name, it will happily use _that_ as a truncated name for
the file.
An example where this actually happens is gcc-4.1.2, where the full path
of the file WeThrowThisExceptionHelper.java truncates _exactly_ before the
basename. So, we have to support that ad-hoc extension.
This bug was noticed by Chris Riddoch on IRC.
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
If the path of our wish executable that are running under
contains spaces we need to make sure they are escaped in
a proper Tcl list, otherwise we are unable to start gitk.
Reported by Randal L. Schwartz on #git.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Fix symlink handling in git-svn, related to PerlIO
After reading the leading contents from a symlink data obtained
from subversion, which we expect to begin with 'link ', the code
forked to hash the remainder (which should match readlink()
result) using git-hash-objects, by redirecting its STDIN from
the filehandle we read that 'link ' from. This was Ok with Perl
on modern Linux, but on Mac OS, the read in the parent process
slurped more than we asked for in stdio buffer, and the child
did not correctly see the "remainder".
This attempts to fix the issue by using lower level sysseek and
sysread instead of seek and read to bypass the stdio buffer.
Signed-off-by: Junio C Hamano <junkio@cox.net> Acked-by: Eric Wong <normalperson@yhbt.net> Acked-by: Seth Falcon <sethfalcon@gmail.com>
http.c: Fix problem with repeated calls of http_init
Calling http_init after calling http_cleanup causes a segfault. This
is due to the pragma_header curl_slist being freed but not being set
to NULL. The subsequent call to http_init tries to setup the slist
again, but it now points to an invalid memory location.
Signed-off-by: Julian Phillips <julian@quantumfyre.co.uk> Signed-off-by: Junio C Hamano <junkio@cox.net>
Released versions of fast-import have been able to create a tree that
contains files or subtrees that contain no name. Unfortunately these
trees aren't valid, but people may have actually tried to create them
due to bugs in import-tars.perl or their own fast-import frontend.
We now look for this unusual condition and warn the user if at
least one of their tree objects contains the problem.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
* commit 'jc/maint': (35 commits)
Update git-http-fetch documentation
Update git-local-fetch documentation
Update git-http-push documentation
Update -L documentation for git-blame/git-annotate
Update git-grep documentation
Update git-fmt-merge documentation
Document additional options for git-fetch
Removing -n option from git-diff-files documentation
Start preparing for 1.5.1.3
Sanitize @to recipients.
git-svn: Ignore usernames in URLs in find_by_url
Document --dry-run and envelope-sender for git-send-email.
Allow users to optionally specify their envelope sender.
Ensure clean addresses are always used with Net::SMTP
Validate @recipients before using it for sendmail and Net::SMTP.
Perform correct quoting of recipient names.
Change the scope of the $cc variable as it is not needed outside of send_message.
Debugging cleanup improvements
Prefix Dry- to the message status to denote dry-runs.
Document --dry-run parameter to send-email.
...
riddochc on #git noticed corruption caused by import-tars. This
was fixed in the prior commit by Dscho, but fast-import was wrong
to have allowed a tree to be created with an empty string as the
filename. No operating system allows this, and Git itself doesn't
accept this into the index.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Documentation/git-local-fetch.txt: -s to use
symbolic links instead of file-to-file copy, -l
to use hardlinks, -n to never use file-to-file
copies, --recover to resume a failed fetch.
Signed-off-by: Andrew Ruder <andy@aeruder.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-grep.txt: Document -F/--fixed-strings to
search for non-regexp patterns. Document -I to not search
binary files. Document -<num> as a shortcut for -C<num>.
Signed-off-by: Andrew Ruder <andy@aeruder.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Documentation/git-fmt-merge-msg.txt:
--summary to list commit summaries on merge
--no-summary
--file to take merged objects from a file.
Configuration option merge.summary
Signed-off-by: Andrew Ruder <andy@aeruder.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Allow users to optionally specify their envelope sender.
If your normal user is not the same user you are subscribed to a list with,
then the default envelope sender used will cause your messages to bounce or
silently vanish into the ether.
This patch provides an optional parameter to set the envelope sender.
To use it with the sendmail binary, you must have privileges to use the -f
parameter!
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Validate @recipients before using it for sendmail and Net::SMTP.
Ensure that @recipients is only raw addresses when it is handed to the sendmail
binary OR Net::SMTP, otherwise BCC cases might get an extra <, or wierd stuff
might be passed to the exec.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Always perform quoting of the recipient names if they contain periods,
previously only the author's address was treated this way. This stops sendmail
binaries from exploding the name into bad addresses.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
The debug output is much more helpful if it has the parameters that were used.
Pull the sendmail parameters into a seperate array for that, and also include
similar data during the Net::SMTP case.
Signed-off-by: Robin H. Johnson <robbat2@gentoo.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
git-svn: Don't rely on $_ after making a function call
Many functions and operators in perl set $_, so its value cannot be relied upon
after calling arbitrary functions. The solution is simply to copy the value of
$_ into a local variable that will not get overwritten.
Signed-off-by: Adam Roben <aroben@apple.com> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a quick and dirty fix for the broken "git cherry-pick -n" on
some broken OS, which does not remove the directory entry after unlink
succeeded(!) if the file is still open somewher.
The entry is left but "protected": no open, no unlink, no stat.
Very annoying.
Signed-off-by: Alex Riesen <raa.lkml@gmail.com> Signed-off-by: Junio C Hamano <junkio@cox.net>
Tim Ansell discovered his Debian server didn't permit git-daemon to
use as much memory as it needed to handle cloning a project with
a 128 MiB packfile. Filtering the strace provided by Tim of the
rev-list child showed this gem of a sequence:
open("./objects/pack/pack-*.pack", O_RDONLY|O_LARGEFILE <unfinished ...>
<... open resumed> ) = 5
And we asked for another window further into the file. But got
denied. In Tim's case this was due to a resource limit on the
git-daemon process, and its children.
Now where are we in the code? We're down inside use_pack(),
after we have called unuse_one_window() enough times to make sure
we stay within our allowed maximum window size. However since we
didn't unmap the prior window at 0xb5e2d000 we aren't exceeding
the current limit (which probably was just the defaults).
But we're actually down inside xmmap()...
So we release the window we do have (by calling release_pack_memory),
assuming there is some memory pressure...
And that was the last window in this packfile. So we closed it.
Way to go us. Our xmmap did not expect release_pack_memory to
close the fd its about to map...
And we report the bad file descriptor error, and not the ENOMEM,
and die, claiming we are out of memory. But actually that mmap
should have succeeded, as we had enough memory for that window,
seeing as how we released the prior one.
Originally when I developed the sliding window mmap feature I had
this exact same bug in fast-import, and I dealt with it by handing
in the struct packed_git* we want to open the new window for, as the
caller wasn't prepared to reopen the packfile if unuse_one_window
closed it. The same is true here from xmmap, but the caller doesn't
have the struct packed_git* handy. So I'm using the file descriptor
instead to perform the same test.
Signed-off-by: Shawn O. Pearce <spearce@spearce.org> Signed-off-by: Junio C Hamano <junkio@cox.net>
Remove usernames from all commit messages, not just when using svmprops
Signed-off-by: Sam Vilain <sam.vilain@catalyst.net.nz> Signed-off-by: Adam Roben <aroben@apple.com> Acked-by: Eric Wong <normalperson@yhbt.net> Signed-off-by: Junio C Hamano <junkio@cox.net>
Create a sysconfdir variable, and use it for ETC_GITCONFIG
ETC_GITCONFIG defaults to $(prefix)/etc/gitconfig, so if you just set
prefix=/usr, you end up with a git that looks in /usr/etc/gitconfig, rather
than /etc/gitconfig as specified by the FHS. Furthermore, setting
ETC_GITCONFIG does not fix the paths to any future system-wide configuration
files.
Factor out the path to the system-wide configuration directory into a variable
sysconfdir, normally set to $(prefix)/etc, but set to /etc when prefix=/usr .
This fixes the prefix=/usr problem for ETC_GITCONFIG, and allows centralized
configuration of any future system-wide configuration files without requiring
further action from package maintainers or other people building and
installing git.
Signed-off-by: Josh Triplett <josh@freedesktop.org> Signed-off-by: Junio C Hamano <junkio@cox.net>