- The location of openssl development files got customizable.
- The location of iconv development files got customizable.
- Pass $TAR down to t5000 test so that the user can override with
'gmake TAR=gtar'.
- Solaris 'bc' does not seem to grok "define abs()". There is no
reason to use bc there -- expr would do.
Signed-off-by: Junio C Hamano <junio@twinsun.com>
This adds the counterpart of git-update-ref that lets you read
and create "symbolic refs". By default it uses a symbolic link
to represent ".git/HEAD -> refs/heads/master", but it can be compiled
to use the textfile symbolic ref.
The places that did 'readlink .git/HEAD' and 'ln -s refs/heads/blah
.git/HEAD' have been converted to use new git-symbolic-ref command, so
that they can deal with either implementation.
Signed-off-by: Junio C Hamano <junio@twinsun.com>
Symbolic refs are understood by resolve_ref(), so existing read_ref()
users will automatically understand them as well.
Signed-off-by: Junio C Hamano <junio@twinsun.com>
This extends the ref reading to understand a "symbolic ref": a ref file
that starts with "ref: " and points to another ref file, and thus
introduces the notion of ref aliases.
This is in preparation of allowing HEAD to eventually not be a symlink,
but one of these symbolic refs instead.
[jc: Linus originally required the prefix to be "ref: " five bytes
and nothing else, but I changed it to allow and strip any number of
leading whitespaces to match what update-ref.c does.]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
A symbolic ref is a regular file whose contents is "ref:", followed by
optional leading whitespaces, followed by a GIT_DIR relative pathname,
followed by optional trailing whitespaces (the optional whitespaces
are unconditionally removed, so you cannot have leading nor trailing
whitespaces). This can be used in place of a traditional symbolic
link .git/HEAD that usually points at "refs/heads/master". You can
instead have a regular file .git/HEAD whose contents is
"ref: refs/heads/master".
[jc: currently the code does not enforce the symbolic ref to begin with
refs/, unlike the symbolic link case. It may be worthwhile to require
either case to begin with refs/ and not have any /./ nor /../ in them.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
You can do
git fetch --tags <linus-kernel-repo>
and it should fetch all my tags automatically.
[jc: The original by Linus fetched and overwrote branch heads with
--all, which felt dangerous and wrong, so I removed it. Also this
version does not use any refs that resulted as --tags for later
merge. ]
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Don't unlink the temp file when an object transfer fails, so next attempt
will pick up where the failed transfer left off
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Add the sanity checks discussed on the list with Nick Hengeveld in
<20050927000931.GA15615@reactrix.com>.
* unlink of previous and rename from temp to previous can fail for
reasons other than benign ones (missing previous and missing temp).
Report these failures when we encounter them, to make diagnosing
problems easier.
* when rewinding the partially written result, make sure to
truncate the file.
Also verify the pack after downloading by calling
verify_packfile().
Signed-off-by: Junio C Hamano <junkio@cox.net>
HTTP partial transfer support for object, pack, and index transfers
[jc: this should not be placed in "master" -- it does not have any
fixes requested on the list.]
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Alexey Nezhdanov updated CVSps to generate author-name and
author-email information in its output.
If the input looks like it has that already properly formatted,
use that without our own munging.
Signed-off-by: Junio C Hamano <junkio@cox.net>
archimport was refusing to import commits that had merges from repositories
that it didn't know about. Fixed.
Also brings in nicer messages.
Signed-off-by: Martin Langhoff <martin@catalyst.net.nz>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The archive generated with git-tar-tree had 0755 and 0644 mode bits.
This inconvenienced the extractor with umask 002 by robbing g+w bit
unconditionally. Just write it out with loose permissions bits and
let the umask of the extractor do its job.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Fix the last two holdouts that forced mode bits stricter than the user's umask.
Noticed by Wolfgang Denk and fixed by Linus.
[jc: applied the same fix to mailsplit just for the sake of consistency.]
Signed-off-by: Junio C Hamano <junkio@cox.net>
A patch that contains no actual diff, and that doesn't change any
meta-data is bad. It shouldn't be a patch at all, and git-apply shouldn't
just accept it.
This caused a corrupted patch to be silently applied as an empty change in
the kernel, because the corruption ended up making the patch look empty.
An example of such a patch is one that contains the patch header, but
where the initial fragment header (the "@@ -nr,.." line) is missing,
causing us to not parse any fragments.
The real "patch" program will also flag such patches as bad, with the
message
patch: **** Only garbage was found in the patch input.
and we should do likewise.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
After seeing Jeff's guide, I changed my mind about the
big-rename transition plan. Even if Porcelains are kept up to
date, those web documents that describes older world order would
live longer and people will stumble across them via google
searches. And who knows how many mirrored copies there are.
The backward compatible symbolic links *will* be removed before
1.0. But that will not happen in 0.99.8.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The core part detected and died upon seeing a corrupted packfile, but
did not help the user by telling which packfile is corrupt and how.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Make logerror() and loginfo() static
logerror() and loginfo() in daemon.c are never declared and never called
from other files, therefore they should be declared static. Found by
sparse.
Signed-off-by: Pavel Roskin <proski@gnu.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
... so try to set it only in later versions.
Signed-off-by: Johannes Schindelin <Johannes.Schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This again makes git-pull to use git-merge, so that different merge
strategy can be specified from the command line. Without explicit
strategy parameter, it defaults to git-merge-resolve if only one
remote is pulled, and git-merge-octopus otherwise, to keep the
default behaviour of the command the same as the original.
Also this brings another usability measure: -n flag from the command
line, if given, is passed to git-merge to prevent it from running the
diffstat at the end of the merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This uses the git-update-ref command in scripts for safer updates.
Also places where we used to read HEAD ref by using "cat" were fixed
to use git-rev-parse. This will matter when we start using symbolic
references.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Added support for additional CURL SSL settings via environment variables.
Client certificate/key files can be specified as well as alternate CA
information.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The merge strategy would check this itself and typically does it
by using git-read-tree -m -u 3-way merge.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The refspecs specified in the .git/remotes/<remote> on the "Pull: "
lines are for fetching multiple heads in one go, but most of the time
making an Octopus out of them is not what is wanted. Make git-fetch
leave the marker in .git/FETCH_HEAD file so that later stages can
tell which heads are for merging and which are not.
Tom Prince made me realize how stupid the original behaviour was.
Signed-off-by: Junio C Hamano <junkio@cox.net>
It still talked about "the proposed alternative semantics" but we have
used those alternative semantics for quite some time. Update them to
avoid confusion.
Signed-off-by: Junio C Hamano <junkio@cox.net>
