Following the list discussion, define two functions, quote_c_style and
unquote_c_style, to help adopting the proposed way for quoting funny
pathname letters for GNU patch. The rule is described in:
http://marc.theaimsgroup.com/?l=git&m=112927316408690&w=2
Currently we do not support the leading '!', but we probably should
barf upon seeing it. Rule B4. is interpreted to require always 3
octal digits in \XYZ notation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
The original semantics of pretending as if all files were
specified where '-a' appeared and using only the flags given so
far was too confusing.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Follow the "encode minimally" principle -- our tools, including
git-apply and git-status, can handle pathnames with embedded SP just
fine. The only problematic ones are TAB and LF, and we need to quote
the metacharacters introduced for quoting.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This will be removed when merging the second phase of Linus' "Create
object subdirectories on demand" change anyway, but the code to
recreate the empty .git/objects/??/ directory was confused.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Deb packaging claim we depend on patch, but I think we use git-apply
where it matters. When a patch does not apply with git-apply, using
GNU patch still is helpful sometimes. So demote it from "Depends" to
"Suggests".
Signed-off-by: Junio C Hamano <junkio@cox.net>
This is a backport so that maintenance branch can understand
diff output that uses C-style quoting produced by newer tools.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Following the list discussion, define two functions, quote_c_style and
unquote_c_style, to help adopting the proposed way for quoting funny
pathname letters for GNU patch. The rule is described in:
http://marc.theaimsgroup.com/?l=git&m=112927316408690&w=2
Currently we do not support the leading '!', but we probably should
barf upon seeing it. Rule B4. is interpreted to require always 3
octal digits in \XYZ notation.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Individual tests for hooks would want to have their own tests when
written. Also we should not pick up from random templates the user
happens to have.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This patch cleans out all sparse warnings from http-fetch.c
I'm a bit uncomfortable with adding extra #ifdefs to avoid either
'mixing declaration with code' or 'unused variable' warnings, but I
figured that since those functions are already littered with #ifdefs I
might just get away with it. Comments?
[jc: I adjusted Peter's patch to address uncomfortableness issues.]
Signed-off-by: Peter Hagervall <hager@cs.umu.se>
Signed-off-by: Junio C Hamano <junkio@cox.net>
The documentation for git-whatchanged is meant to describe only
the most frequently used options from git-diff-tree. Because "why
doesn't it show merges" was asked more than once, we'd better
describe '-m' option there.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Contains the following changes since v0.99.8c.
Johannes Schindelin:
Teach git-status about spaces in file names also on MacOSX
t5400-send-pack relies on a working cpio
Jonas Fonseca:
git.sh: quote all paths
Junio C Hamano:
Also force LC_ALL in test scripts.
OpenBSD needs the strcasestr replacement.
git-check-ref-format: reject funny ref names.
Refuse to create funny refs in clone-pack, git-fetch and receive-pack.
Ignore funny refname sent from remote
Introduce notation "ref^{type}".
Martin Langhoff:
cvsimport: don't pass --cvs-direct if user options contradict us
Ralf Baechle:
rsh.c: typo fix
Note that "funny ref" bits are not strictly fixes but rather
backport from the "master" branch. They will prevent refs and
heads with funny names from being created. In addition, what is
in the master branch will start feeding the clients unwrapped
tag information to help Martin's findtags and possibly later
Cogito. These backported "funny ref" changes are to prevent
clients on the "maint" branch from getting confused when talking
with newer git-upload-pack and when reading from info/refs file
prepared with newer git-update-server-info.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Existing "tagname^0" notation means "dereference tag zero or more
times until you cannot dereference it anymore, and make sure it is a
commit -- otherwise barf". But tags do not necessarily reference
commit objects.
This commit introduces a bit more generalized notation, "ref^{type}".
Existing "ref^0" is a shorthand for "ref^{commit}". If the type
is empty, it just dereferences tags until it hits a non-tag object.
With this, "git-rev-parse --verify 'junio-gpg-pub^{}'" shows the blob
object name -- there is no need to manually read the tag object and
find out the object name anymore.
"git-rev-parse --verify 'HEAD^{tree}'" can be used to find out the
tree object name of the HEAD commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows the remote side (most notably, upload-pack) to show
additional information without affecting the downloader. Peek-remote
does not ignore them -- this is to make it useful for Pasky's
automatic tag following.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using git-check-ref-format, make sure we do not create refs with
funny names when cloning from elsewhere (clone-pack), fast forwarding
local heads (git-fetch), or somebody pushes into us (receive-pack).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update check_ref_format() function to reject ref names that:
* has a path component that begins with a ".", or
* has a double dots "..", or
* has ASCII control character, "~", "^", ":" or SP, anywhere, or
* ends with a "/".
Use it in 'git-checkout -b', 'git-branch', and 'git-tag' to make sure
that newly created refs are well-formed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This updates git-ls-remote to show SHA1 names of objects that are
referred by tags, in the "ref^{}" notation.
This would make git-findtags (without -t flag) almost trivial.
git-peek-remote . |
sed -ne "s:^$target "'refs/tags/\(.*\)^{}$:\1:p'
Also Pasky could do:
git-ls-remote --tags $remote |
sed -ne 's:\( refs/tags/.*\)^{}$:\1:p'
to find out what object each of the remote tags refers to, and
if he has one locally, run "git-fetch $remote tag $tagname" to
automatically catch up with the upstream tags.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Existing "tagname^0" notation means "dereference tag zero or more
times until you cannot dereference it anymore, and make sure it is a
commit -- otherwise barf". But tags do not necessarily reference
commit objects.
This commit introduces a bit more generalized notation, "ref^{type}".
Existing "ref^0" is a shorthand for "ref^{commit}". If the type
is empty, it just dereferences tags until it hits a non-tag object.
With this, "git-rev-parse --verify 'junio-gpg-pub^{}'" shows the blob
object name -- there is no need to manually read the tag object and
find out the object name anymore.
"git-rev-parse --verify 'HEAD^{tree}'" can be used to find out the
tree object name of the HEAD commit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This allows the remote side (most notably, upload-pack) to show
additional information without affecting the downloader. Peek-remote
does not ignore them -- this is to make it useful for Pasky's
automatic tag following.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Using git-check-ref-format, make sure we do not create refs with
funny names when cloning from elsewhere (clone-pack), fast forwarding
local heads (git-fetch), or somebody pushes into us (receive-pack).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Update check_ref_format() function to reject ref names that:
* has a path component that begins with a ".", or
* has a double dots "..", or
* has ASCII control character, "~", "^", ":" or SP, anywhere, or
* ends with a "/".
Use it in 'git-checkout -b', 'git-branch', and 'git-tag' to make sure
that newly created refs are well-formed.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Hi,
On Fri, 14 Oct 2005, Junio C Hamano wrote:
> Johannes Schindelin <Johannes.Schindelin@gmx.de> writes:
>
> > This patch looks bigger than it really is: The code to get the
> > default handle was refactored into a function, and is called
> > instead of curl_easy_duphandle() if that does not exist.
>
> I'd like to take Nick's config file patch first, which
> unfortunately interferes with your patch. I'd hate to ask you
> this, but could you rebase it on top of Nick's patch, [...]
No need to hate it. Here comes the rebased patch, and this time, I
actually tested it a bit.
Signed-off-by: Junio C Hamano <junkio@cox.net>
Do our own ctype.h, just to get the sane semantics: we want
locale-independence, _and_ we want the right signed behaviour. Plus we
only use a very small subset of ctype.h anyway (isspace, isalpha,
isdigit and isalnum).
Signed-off-by: Junio C Hamano <junkio@cox.net>
Use "http." config file settings if they exist. Environment variables
still work, and they will override config file settings.
Signed-off-by: Nick Hengeveld <nickh@reactrix.com>
Signed-off-by: Junio C Hamano <junkio@cox.net>
git-http-fetch received objects/info/packs into a fixed-size buffer
and started to fail when this file became larger than the buffer.
Change it to grow the buffer dynamically, and do the same thing for
objects/info/alternates. Also add missing free() calls for these
buffers.
Signed-off-by: Sergey Vlasov <vsu@altlinux.ru>
Signed-off-by: Junio C Hamano <junkio@cox.net>
It seemed to be such a stupid syntax. It's both what "ssh://" means,
and it's what not specifying a protocol at _all_ means.
But hey, since we already have two ways of saying "use ssh with
pack-files", here's two more.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This enhances set of revs you can give format-patch.
Originally, format-patch took either one rev, or two revs:
format-patch rev1
format-patch rev1 rev2
The first format was a short-hand for "format-patch rev1 HEAD"
(i.e. rev2==HEAD). What this meant was to find commits that are
in branch rev2 that has not been merged to branch rev1.
The above notation is still supported, but now it takes sequence
of "from1..to1 from2..to2 ...". In short, the second format has
become a short-hand for "format-patch rev1..rev2". Commits in
to1 but not in from1, to2 but not in from2, ... are formatted as
emailable patches.
With this, cherry-picking from other branch can be written as:
git-format-patch -k --stdout master..branch1 master..branch2 |
git-am -k -3
which is generally faster than traditional cherry-pick (which
always did 3-way merge) if patches apply cleanly, and still
falls back on 3-way merge if some of them do not.
Signed-off-by: Junio C Hamano <junkio@cox.net>
This uses the new "--local" flag to git-pack-objects. It currently only
makes a difference together with "-a", since a normal incremental repack
won't pack any packed objects at all (whether local or remote).
Eventually, it might end up skipping any objects that aren't local to
the current object directory, but for now it only knows to skip packed
objects.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
This adds the "--local" flag to git-pack-objects, which acts like
"--incremental", except that instead of ignoring all packed objects, it
only ignores objects that are packed and in an alternate object tree.
As a result, it effectively only does a local re-pack: any remote-packed
objects will stay in the alternate object directories.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
If we want to re-pack just local packfiles, we need to know whether a
particular object is local or not.
Signed-off-by: Linus Torvalds <torvalds@osdl.org>
Signed-off-by: Junio C Hamano <junkio@cox.net>
Lacking reliable symlinks, the instructions in the tutorial did not work
in a cygwin setup. Also, a few outputs were not correct.
This patch fixes these, and adds a test case which follows the
instructions of the tutorial (except git-clone, -fetch and -push, which I
have not done yet).
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Junio C Hamano <junkio@cox.net>
