* [PATCH 03/24] Show usage string for 'git cherry -h'
From: Jonathan Nieder @ 2009-11-09 15:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091109150235.GA23871@progeny.tock>
Treat an "-h" option as a request for help, rather than an
"Unknown commit -h" error.
"cherry -h" could be asking to compare histories that leads to
our HEAD and a commit that can be named as "-h". Strictly
speaking, that may be a valid refname, but the user would have to
say something like "tags/-h" to name such a pathological ref
already, so it is not such a big deal.
The "-h" option keeps its meaning even if preceded by other
options or followed by other arguments. This keeps the
command-line syntax closer to what parse_options would give and
supports shell aliases like 'alias cherry="git cherry -v"' a
little better.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
builtin-log.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-log.c b/builtin-log.c
index 207a361..5248507 100644
--- a/builtin-log.c
+++ b/builtin-log.c
@@ -1237,6 +1237,9 @@ int cmd_cherry(int argc, const char **argv, const char *prefix)
argv++;
}
+ if (argc > 1 && !strcmp(argv[1], "-h"))
+ usage(cherry_usage);
+
switch (argc) {
case 4:
limit = argv[3];
--
1.6.5.2
^ permalink raw reply related
* [PATCH 07/24] check-ref-format: update usage string
From: Jonathan Nieder @ 2009-11-09 15:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091109150235.GA23871@progeny.tock>
'git check-ref-format' has learned --branch and --print options
since the usage string was last updated.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
builtin-check-ref-format.c | 6 +++++-
1 files changed, 5 insertions(+), 1 deletions(-)
diff --git a/builtin-check-ref-format.c b/builtin-check-ref-format.c
index e3e7bdf..513f134 100644
--- a/builtin-check-ref-format.c
+++ b/builtin-check-ref-format.c
@@ -7,6 +7,10 @@
#include "builtin.h"
#include "strbuf.h"
+static const char builtin_check_ref_format_usage[] =
+"git check-ref-format [--print] <refname>\n"
+" or: git check-ref-format --branch <branchname-shorthand>";
+
/*
* Replace each run of adjacent slashes in src with a single slash,
* and write the result to dst.
@@ -49,6 +53,6 @@ int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
exit(0);
}
if (argc != 2)
- usage("git check-ref-format refname");
+ usage(builtin_check_ref_format_usage);
return !!check_ref_format(argv[1]);
}
--
1.6.5.2
^ permalink raw reply related
* [PATCH/RFC 06/24] Show usage string for 'git show-ref -h'
From: Jonathan Nieder @ 2009-11-09 15:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091109150235.GA23871@progeny.tock>
This only changes the behavior of "git show-ref -h" without any
other options and arguments.
"show-ref -h" currently is short for "show-ref --head", which
shows all the refs/* and HEAD, as opposed to "show-ref" that
shows all the refs/* and not HEAD.
Does anybody use "show-ref -h"? It was in Linus's original, most
likely only because "it might be handy", not because "the command
should not show the HEAD by default for such and such reasons".
So I think it is okay if "show-ref -h" (but not "show-ref
--head") gives help and exits.
If a current script uses "git show-ref -h" without any other
arguments, it would have to be adapted by changing "-h" to
"--head".
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-show-ref.txt | 3 +--
builtin-show-ref.c | 10 ++++++++--
2 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-show-ref.txt b/Documentation/git-show-ref.txt
index f4429bd..70f400b 100644
--- a/Documentation/git-show-ref.txt
+++ b/Documentation/git-show-ref.txt
@@ -8,7 +8,7 @@ git-show-ref - List references in a local repository
SYNOPSIS
--------
[verse]
-'git show-ref' [-q|--quiet] [--verify] [-h|--head] [-d|--dereference]
+'git show-ref' [-q|--quiet] [--verify] [--head] [-d|--dereference]
[-s|--hash[=<n>]] [--abbrev[=<n>]] [--tags]
[--heads] [--] <pattern>...
'git show-ref' --exclude-existing[=<pattern>] < ref-list
@@ -30,7 +30,6 @@ the `.git` directory.
OPTIONS
-------
--h::
--head::
Show the HEAD reference.
diff --git a/builtin-show-ref.c b/builtin-show-ref.c
index c46550c..17ada88 100644
--- a/builtin-show-ref.c
+++ b/builtin-show-ref.c
@@ -7,7 +7,7 @@
#include "parse-options.h"
static const char * const show_ref_usage[] = {
- "git show-ref [-q|--quiet] [--verify] [-h|--head] [-d|--dereference] [-s|--hash[=<n>]] [--abbrev[=<n>]] [--tags] [--heads] [--] [pattern*] ",
+ "git show-ref [-q|--quiet] [--verify] [--head] [-d|--dereference] [-s|--hash[=<n>]] [--abbrev[=<n>]] [--tags] [--heads] [--] [pattern*] ",
"git show-ref --exclude-existing[=pattern] < ref-list",
NULL
};
@@ -183,7 +183,10 @@ static const struct option show_ref_options[] = {
OPT_BOOLEAN(0, "heads", &heads_only, "only show heads (can be combined with tags)"),
OPT_BOOLEAN(0, "verify", &verify, "stricter reference checking, "
"requires exact ref path"),
- OPT_BOOLEAN('h', "head", &show_head, "show the HEAD reference"),
+ { OPTION_BOOLEAN, 'h', NULL, &show_head, NULL,
+ "show the HEAD reference",
+ PARSE_OPT_NOARG | PARSE_OPT_HIDDEN },
+ OPT_BOOLEAN(0, "head", &show_head, "show the HEAD reference"),
OPT_BOOLEAN('d', "dereference", &deref_tags,
"dereference tags into object IDs"),
{ OPTION_CALLBACK, 's', "hash", &abbrev, "n",
@@ -201,6 +204,9 @@ static const struct option show_ref_options[] = {
int cmd_show_ref(int argc, const char **argv, const char *prefix)
{
+ if (argc == 2 && !strcmp(argv[1], "-h"))
+ usage_with_options(show_ref_usage, show_ref_options);
+
argc = parse_options(argc, argv, prefix, show_ref_options,
show_ref_usage, PARSE_OPT_NO_INTERNAL_HELP);
--
1.6.5.2
^ permalink raw reply related
* [PATCH 08/24] Show usage string for 'git check-ref-format -h'
From: Jonathan Nieder @ 2009-11-09 15:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091109150235.GA23871@progeny.tock>
This only changes the behavior of "git check-ref-format -h"
without any other options and arguments.
This change cannot be breaking backward compatibility, since any
valid refname must contain a /. Most existing scripts use
arguments such as "heads/$foo". If some script checks the
refname "-h" alone, git check-ref-format will still exit with
nonzero status, and the only detrimental side-effect will be a
usage string sent to stderr.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
builtin-check-ref-format.c | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/builtin-check-ref-format.c b/builtin-check-ref-format.c
index 513f134..b106c65 100644
--- a/builtin-check-ref-format.c
+++ b/builtin-check-ref-format.c
@@ -35,6 +35,9 @@ static void collapse_slashes(char *dst, const char *src)
int cmd_check_ref_format(int argc, const char **argv, const char *prefix)
{
+ if (argc == 2 && !strcmp(argv[1], "-h"))
+ usage(builtin_check_ref_format_usage);
+
if (argc == 3 && !strcmp(argv[1], "--branch")) {
struct strbuf sb = STRBUF_INIT;
--
1.6.5.2
^ permalink raw reply related
* [PATCH 17/24] Show usage string for 'git stripspace -h'
From: Jonathan Nieder @ 2009-11-09 15:04 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <20091109150235.GA23871@progeny.tock>
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
builtin-stripspace.c | 4 +++-
1 files changed, 3 insertions(+), 1 deletions(-)
diff --git a/builtin-stripspace.c b/builtin-stripspace.c
index 1fd2205..4d3b93f 100644
--- a/builtin-stripspace.c
+++ b/builtin-stripspace.c
@@ -73,9 +73,11 @@ int cmd_stripspace(int argc, const char **argv, const char *prefix)
struct strbuf buf = STRBUF_INIT;
int strip_comments = 0;
- if (argc > 1 && (!strcmp(argv[1], "-s") ||
+ if (argc == 2 && (!strcmp(argv[1], "-s") ||
!strcmp(argv[1], "--strip-comments")))
strip_comments = 1;
+ else if (argc > 1)
+ usage("git stripspace [-s | --strip-comments] < <stream>");
if (strbuf_read(&buf, 0, 1024) < 0)
die_errno("could not read the input");
--
1.6.5.2
^ permalink raw reply related
* Re: What's cooking in git.git (Nov 2009, #02; Sun, 08)
From: Shawn O. Pearce @ 2009-11-09 15:29 UTC (permalink / raw)
To: Tarmigan; +Cc: Junio C Hamano, git
In-Reply-To: <905315640911090008h34b55a37q439d02de37127039@mail.gmail.com>
Tarmigan <tarmigan+git@gmail.com> wrote:
> On Sun, Nov 8, 2009 at 9:18 PM, Junio C Hamano <gitster@pobox.com> wrote:
> > * sp/smart-http (2009-11-04) 30 commits
> > + test smart http fetch and push
>
> I am trying to test smart http, and have had to set
> DEFAULT_HTTPD_PATH='/usr/sbin/httpd'
> DEFAULT_HTTPD_MODULE_PATH='/usr/lib64/httpd/modules' on Centos.
> Perhaps this failing test is just a difference in the default Apache
> and curl configurations.
*sigh*
> --- exp 2009-11-09 07:33:19.000000000 +0000
> +++ act 2009-11-09 07:33:19.000000000 +0000
> @@ -6,15 +6,16 @@
> < Pragma: no-cache
> < Cache-Control: no-cache, max-age=0, must-revalidate
> < Content-Type: application/x-git-upload-pack-advertisement
> -<
> > POST /smart/repo.git/git-upload-pack HTTP/1.1
> +> Accept: */*
> > Accept-Encoding: deflate, gzip
> > Content-Type: application/x-git-upload-pack-request
> > Accept: application/x-git-upload-pack-response
The first delta is a missing blank line between requests. I probably
can work around that with some sort of sed hackery and its likely
caused by a different libcurl version.
The second delta is libcurl sending *two* Accept headers to the
server. The first was set by the library as "*/*", but the second
was set by git-remote-curl. Here your libcurl is just plain *wrong*.
The application has said "I only support one content type, this one"
and the library still went and told the server "I accept anything
you have, just give it to me!".
I'm not sure what to do about this breakage in curl. We may have
to relax how we use HTTP since at least one version of libcurl
can't get this minor detail right.
> > Content-Length: xxx
>
> +> 0073want 1937bb05802e1973cc2e437c13e9f1845941b785
> multi_ack_detailed side-band-64k thin-pack no-progress ofs-delta
> +> 00000009done
Hmmph. Your libcurl also included the POST body in the verbose
message.
--
Shawn.
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Potapov @ 2009-11-09 15:48 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091109T084539-720@post.gmane.org>
On Mon, Nov 09, 2009 at 07:53:24AM +0000, Dmitry Smirnov wrote:
> <david <at> lang.hm> writes:
>
> > going back to the initial poster's comments. if the android repo is 1G,
> > eliminating the history will probably have significantly less impact than
> > you expect it to.
>
> Do you have 2 or more copies of the same repository at the same time?
> If yes, can I skip cloning new copy from network?
> Or even skip cloning it at all?
> Is it possible with Git to chekout into two (few) working trees?
Jacob has already mentioned git-new-workdir from Git contrib, but
there are other ways to do the same or almost the same....
First of all, you can always copy your directory and thus creating
another clone. It is very simple and straightforward solution, but
it takes extra space due an extra copy of the repository. Usually,
it is not a big issue in practice, because your working tree tends
to be larger than the repository itself...
However, if you want to save disk space, you can use local clone. When
you clone your (like: git clone old_dir new_dir), git tries to use hard
links if it is possible. So, it may save disk space. However, if you
repack your original repo then a new pack will be created, and saving
from using the hard link will be lost. To prevent that from happening,
you can tell to the garbage collector to keep the main existing pack by
create a file that has the same name as the pack file plus the .keep
suffix:
touch .git/objects/pack-<SHA-1>.keep
then all changes will be put into a separate pack.
There is one more way to save disk space is to use git clone --shared.
It does not require hard links, but it has some caveats. If you want to
use it, then read the documentation carefully and make sure you understand
all implications.
Actually, in most use cases, there is no reason to have more than one
working tree. Git is designed to work well with plenty branches and one
working tree. So, switching between two branches and recompiling a few
changed files is much faster then going to another directory and try to
work there, because when you go to another directory, you may hit cold
cache and disk is *slow*... Another thing is that you can do a lot of
things without checking out some branch. You can grep any revision in
your repository, you can insect any file from it, etc and you do not
have to checkout this revision in your working tree.
Dmitry
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-09 15:59 UTC (permalink / raw)
To: git
In-Reply-To: <8c9a060911090634p4e036208mfb3160eb4c4430e9@mail.gmail.com>
Jacob Helwig <jacob.helwig <at> gmail.com> writes:
> It does have a few caveats, however. If you have the same branch
> checked out in two different working copies created using
>...
> place on your machine, you'll never notice, thuogh.
So, i cannot recover from this situation by upmerging to the new head?
^ permalink raw reply
* get git not to care about permissions
From: sconeman @ 2009-11-09 16:06 UTC (permalink / raw)
To: git
Hello,
I'm trying to set up git on a NetApp drive at my school, BU. The NetApp
shares are configured with Windows permissions, and I forget the specifics
(which I can figure out if needed) about why this is the case, but basically
the deal is that if true UNIX permissions were to be used, Windows wouldn't
be able to read the drive. As such, and because we use the Kerberos
ticketing system, the permissions for the drive are set up such that the
owners (myself and my team members) have full permissions, but nobody else
does. Git doesn't like this and won't even create a bare repository. Is
there any way I can get git to ignore permissions and just do what it needs
to do?
Thanks in advance for the help!
-Matt
--
View this message in context: http://old.nabble.com/get-git-not-to-care-about-permissions-tp26268938p26268938.html
Sent from the git mailing list archive at Nabble.com.
^ permalink raw reply
* Re: Git drawbacks?
From: Dmitry Smirnov @ 2009-11-09 16:11 UTC (permalink / raw)
To: git
In-Reply-To: <20091109154816.GH27126@dpotapov.dyndns.org>
Dmitry Potapov <dpotapov <at> gmail.com> writes:
> Actually, in most use cases, there is no reason to have more than one
> working tree. Git is designed to work well with plenty branches and one
> working tree. So, switching between two branches and recompiling a few
> changed files is much faster then going to another directory and try to
> work there, because when you go to another directory, you may hit cold
> cache and disk is *slow*... Another thing is that you can do a lot of
> things without checking out some branch. You can grep any revision in
> your repository, you can insect any file from it, etc and you do not
> have to checkout this revision in your working tree.
Shouldn't I even worry about my not yet commited changes before switching the
branch?
I would say that this approach does not work if the build and test could take
significant time. While in CR fix I don't want to wait for a build to complete
before I countinue with another bug/fix. That is why I'm curious about
few working trees...
^ permalink raw reply
* Re: Git drawbacks?
From: Jacob Helwig @ 2009-11-09 16:21 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091109T165620-587@post.gmane.org>
On Mon, Nov 9, 2009 at 07:59, Dmitry Smirnov <divis1969@gmail.com> wrote:
> Jacob Helwig <jacob.helwig <at> gmail.com> writes:
>
>> It does have a few caveats, however. If you have the same branch
>> checked out in two different working copies created using
>>...
>> place on your machine, you'll never notice, thuogh.
>
>
> So, i cannot recover from this situation by upmerging to the new head?
>
If you haven't actually made any changes in the second checkout of the
branch, then recovery is a simple reset --hard. If you have made any
changes in that working copy, then recovery is a bit more complicated,
and it's probably best if I leave that explanation up to someone else,
since I'm very careful to avoid this situation in the first place, and
have never actually had to recover from it.
^ permalink raw reply
* Re: [PATCH v3 08/12] Allow helper to map private ref names into normal names
From: Junio C Hamano @ 2009-11-09 16:44 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Daniel Barkalow, Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0911082242k5950d780i584a4714e384e007@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> writes:
> Heya,
>
> On Sat, Nov 7, 2009 at 00:19, Sverre Rabbelier <srabbelier@gmail.com> wrote:
>> On Sat, Nov 7, 2009 at 00:12, Daniel Barkalow <barkalow@iabervon.org> wrote:
>>> At the very least, it needs documentation and memory leaks fixed (the
>>> refspec strings read from the helper, and the refspec structs and array on
>>> freeing the helper data).
>>
>> Please send follow-ups against [0] and I will include them in the next round :).
>
> It's in next now, so please send follow-ups against sr/vcs-helper.
Do you mean 'pu' or 'next'?
^ permalink raw reply
* Re: [BUG] unpack-objects abnormal exit when pushing
From: Junio C Hamano @ 2009-11-09 16:56 UTC (permalink / raw)
To: Matthieu Moy; +Cc: git
In-Reply-To: <vpqhbt3ap3w.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> I just found a way to reproduce the problem using plain SSH, and not
> Git:
>
> $ ssh localhost cat < random.bin | wc
> 249 1460 65536
> $ cat < random.bin | wc
> 796 4545 204800
>
> So, sshd is broken on this machine, and I don't think Git is the one
> to blame.
Yuck; that sounds scary.
^ permalink raw reply
* Re: [PATCH RFC] builtin-push: add --delete as syntactic sugar for :foo
From: Junio C Hamano @ 2009-11-09 16:59 UTC (permalink / raw)
To: Jan Krüger; +Cc: Git ML
In-Reply-To: <20091109130935.2bea7771@perceptron>
Jan Krüger <jk@jk.gs> writes:
> Refspecs without a source side have been reported as confusing by many.
> As an alternative, this adds support for commands like:
>
> git push origin --delete somebranch
>
> Specifically, --delete will prepend a colon to all colon-less refspecs
> given on the command line.
Will it barf and error out if there is any colon-ful one? I think it
should. I was about to write "I guess it could be argued both ways", but
after thinking about it for 5 seconds I do not see a sane way to explain a
command line "push origin --delete one two:three".
I agree with you that it wouldn't make sense to mix this with --all and
friends.
^ permalink raw reply
* Re: [PATCH RFC] builtin-push: add --delete as syntactic sugar for :foo
From: Junio C Hamano @ 2009-11-09 17:08 UTC (permalink / raw)
To: Jan Krüger; +Cc: Junio C Hamano, Git ML
In-Reply-To: <7v8wefy6pi.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> Will it barf and error out if there is any colon-ful one? I think it
> should. I was about to write "I guess it could be argued both ways", but
> after thinking about it for 5 seconds I do not see a sane way to explain a
> command line "push origin --delete one two:three".
Actually the one I had in mind was
git push origin --delete one two:three four
If it were
git push origin --tags --delete=one --delete=four two:three
it would be perfectly understandable, though.
No, I am not saying that we should make --delete take a parameter, allow
multiple of them, and make them compatible with --tags. At least not yet.
^ permalink raw reply
* Re: [PATCH v3 08/12] Allow helper to map private ref names into normal names
From: Sverre Rabbelier @ 2009-11-09 17:10 UTC (permalink / raw)
To: Junio C Hamano
Cc: Daniel Barkalow, Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <7vhbt3y7fb.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Nov 9, 2009 at 17:44, Junio C Hamano <gitster@pobox.com> wrote:
> Sverre Rabbelier <srabbelier@gmail.com> writes:
>> It's in next now, so please send follow-ups against sr/vcs-helper.
>
> Do you mean 'pu' or 'next'?
Sorry, my hands did not type what my mind intended, I meant to say
'pu', apologies!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH RFC] builtin-push: add --delete as syntactic sugar for :foo
From: Sverre Rabbelier @ 2009-11-09 17:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Jan Krüger, Git ML
In-Reply-To: <7v8wefy6pi.fsf@alter.siamese.dyndns.org>
Heya,
On Mon, Nov 9, 2009 at 17:59, Junio C Hamano <gitster@pobox.com> wrote:
> Jan Krüger <jk@jk.gs> writes:
>> Specifically, --delete will prepend a colon to all colon-less refspecs
>> given on the command line.
>
> Will it barf and error out if there is any colon-ful one? I think it
> should. I was about to write "I guess it could be argued both ways", but
> after thinking about it for 5 seconds I do not see a sane way to explain a
> command line "push origin --delete one two:three".
Did we not have this discussion not 3 months ago and decided it was a bad idea?
http://thread.gmane.org/gmane.comp.version-control.git/125894
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH 1/3] http-backend: Fix symbol clash on AIX 5.3
From: Shawn O. Pearce @ 2009-11-09 18:10 UTC (permalink / raw)
To: git; +Cc: Mike Ralphson
Mike says:
> > +static void send_file(const char *the_type, const char *name)
> > +{
>
> I think a symbol clash here is responsible for a build breakage in
> next on AIX 5.3:
>
> CC http-backend.o
> http-backend.c:213: error: conflicting types for `send_file'
> /usr/include/sys/socket.h:676: error: previous declaration of `send_file'
> gmake: *** [http-backend.o] Error 1
So we rename the function send_local_file().
Reported-by: Mike Ralphson <mike.ralphson@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
http-backend.c | 10 +++++-----
1 files changed, 5 insertions(+), 5 deletions(-)
diff --git a/http-backend.c b/http-backend.c
index 9021266..646e910 100644
--- a/http-backend.c
+++ b/http-backend.c
@@ -209,7 +209,7 @@ static void send_strbuf(const char *type, struct strbuf *buf)
safe_write(1, buf->buf, buf->len);
}
-static void send_file(const char *the_type, const char *name)
+static void send_local_file(const char *the_type, const char *name)
{
const char *p = git_path("%s", name);
size_t buf_alloc = 8192;
@@ -247,28 +247,28 @@ static void get_text_file(char *name)
{
select_getanyfile();
hdr_nocache();
- send_file("text/plain", name);
+ send_local_file("text/plain", name);
}
static void get_loose_object(char *name)
{
select_getanyfile();
hdr_cache_forever();
- send_file("application/x-git-loose-object", name);
+ send_local_file("application/x-git-loose-object", name);
}
static void get_pack_file(char *name)
{
select_getanyfile();
hdr_cache_forever();
- send_file("application/x-git-packed-objects", name);
+ send_local_file("application/x-git-packed-objects", name);
}
static void get_idx_file(char *name)
{
select_getanyfile();
hdr_cache_forever();
- send_file("application/x-git-packed-objects-toc", name);
+ send_local_file("application/x-git-packed-objects-toc", name);
}
static int http_config(const char *var, const char *value, void *cb)
--
1.6.5.2.351.g09432
^ permalink raw reply related
* [PATCH 2/3] t5551-http-fetch: Work around some libcurl versions
From: Shawn O. Pearce @ 2009-11-09 18:10 UTC (permalink / raw)
To: git; +Cc: Tarmigan
In-Reply-To: <1257790237-30850-1-git-send-email-spearce@spearce.org>
Some versions of libcurl report their output when GIT_CURL_VERBOSE
is set differently than other versions do. At least one variant
(version unknown but likely pre-7.18.1) reports the POST payload to
stderr, and omits the blank line after each HTTP request/response.
We clip these lines out of the stderr output now before doing the
compare, so we aren't surprised by this trivial difference.
Reported-by: Tarmigan <tarmigan+git@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
t/t5551-http-fetch.sh | 8 ++++----
1 files changed, 4 insertions(+), 4 deletions(-)
diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index eb0c039..6b0165c 100755
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -31,23 +31,19 @@ cat >exp <<EOF
> GET /smart/repo.git/info/refs?service=git-upload-pack HTTP/1.1
> Accept: */*
> Pragma: no-cache
-
< HTTP/1.1 200 OK
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Content-Type: application/x-git-upload-pack-advertisement
-<
> POST /smart/repo.git/git-upload-pack HTTP/1.1
> Accept-Encoding: deflate, gzip
> Content-Type: application/x-git-upload-pack-request
> Accept: application/x-git-upload-pack-response
> Content-Length: xxx
-
< HTTP/1.1 200 OK
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Content-Type: application/x-git-upload-pack-result
-<
EOF
test_expect_success 'clone http repository' '
GIT_CURL_VERBOSE=1 git clone --quiet $HTTPD_URL/smart/repo.git clone 2>err &&
@@ -56,6 +52,8 @@ test_expect_success 'clone http repository' '
sed -e "
s/Q\$//
/^[*] /d
+ /^$/d
+ /^< $/d
/^[^><]/{
s/^/> /
@@ -64,6 +62,8 @@ test_expect_success 'clone http repository' '
/^> User-Agent: /d
/^> Host: /d
s/^> Content-Length: .*/> Content-Length: xxx/
+ /^00..want /d
+ /^00.*done/d
/^< Server: /d
/^< Expires: /d
--
1.6.5.2.351.g09432
^ permalink raw reply related
* [RFC PATCH 3/3] t5551-http-fetch: Work around broken Accept header in libcurl
From: Shawn O. Pearce @ 2009-11-09 18:10 UTC (permalink / raw)
To: git; +Cc: Tarmigan
In-Reply-To: <1257790237-30850-1-git-send-email-spearce@spearce.org>
Unfortunately at least one version of libcurl has a bug causing
it to include "Accept: */*" in the same POST request where we have
already asked for "Accept: application/x-git-upload-pack-response".
This is a bug in libcurl, not Git, or our test vector. The
application has explicitly asked the server for a single content
type, but libcurl has mistakenly also told the server the client
application will accept */*, which is any content type.
Based on the libcurl change log, this "Accept: */*" header bug
may have been fixed in version 7.18.1 released March 30, 2008:
http://curl.haxx.se/changes.html#7_18_1
Rather than require users to upgrade libcurl we change the test
vector to trim this line out of the 2nd request.
Reported-by: Tarmigan <tarmigan+git@gmail.com>
Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
---
Actually, I don't want to apply this.
Tarmigan, your libcurl is broken, it looks like a newer version
fixes the problem, so I would suggest upgrading it.
t/t5551-http-fetch.sh | 3 +++
1 files changed, 3 insertions(+), 0 deletions(-)
diff --git a/t/t5551-http-fetch.sh b/t/t5551-http-fetch.sh
index 6b0165c..9d59065 100755
--- a/t/t5551-http-fetch.sh
+++ b/t/t5551-http-fetch.sh
@@ -61,6 +61,9 @@ test_expect_success 'clone http repository' '
/^> User-Agent: /d
/^> Host: /d
+ /^> POST /,$ {
+ /^> Accept: [*]\\/[*]/d
+ }
s/^> Content-Length: .*/> Content-Length: xxx/
/^00..want /d
/^00.*done/d
--
1.6.5.2.351.g09432
^ permalink raw reply related
* [PATCH RFC v2] builtin-push: add --delete as syntactic sugar for :foo
From: Jan Krüger @ 2009-11-09 18:20 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git ML, Sverre Rabbelier
In-Reply-To: <7v8wefy6pi.fsf@alter.siamese.dyndns.org>
Refspecs without a source side have been reported as confusing by many.
As an alternative, this adds support for commands like:
git push origin --delete somebranch
Specifically, --delete will prepend a colon to all colon-less refspecs
given on the command line, and will refuse to accept refspecs with
colons to prevent undue confusion.
Signed-off-by: Jan Krüger <jk@jk.gs>
---
All good points, and I actually remembered to catch the colon-refspec
case a few minutes after sending the patch, but didn't have time to fix
it up. (Sorry for not considering the old thread; I had gotten
unsubscribed from the list back then).
I think with this change it becomes much saner. And no, I'm not
proposing to add --rename and --copy, too. ;)
The new error message is not completely technically correct since it's
still a refspec we're taking, we just force it to be without a colon.
On the other hand, this error message will hopefully make much more
sense to people who don't know all the background, and it's not too
horribly wrong either.
(Sverre added to Cc list from subthread)
builtin-push.c | 16 ++++++++++++++++
t/t5516-fetch-push.sh | 6 ++++++
2 files changed, 22 insertions(+), 0 deletions(-)
diff --git a/builtin-push.c b/builtin-push.c
index 8631c06..e40bfe8 100644
--- a/builtin-push.c
+++ b/builtin-push.c
@@ -15,6 +15,7 @@ static const char * const push_usage[] = {
};
static int thin;
+static int deleterefs;
static const char *receivepack;
static const char **refspec;
@@ -44,6 +45,15 @@ static void set_refspecs(const char **refs, int nr)
strcat(tag, refs[i]);
ref = tag;
}
+ if (deleterefs && !strchr(ref, ':')) {
+ char *delref;
+ int len = strlen(refs[i] + 1);
+ delref = xmalloc(len);
+ strcpy(delref, ":");
+ strcat(delref, refs[i]);
+ ref = delref;
+ } else if (deleterefs)
+ die("--delete only accepts plain target ref names");
add_refspec(ref);
}
}
@@ -181,6 +191,7 @@ int cmd_push(int argc, const char **argv, const char *prefix)
OPT_BIT( 0 , "all", &flags, "push all refs", TRANSPORT_PUSH_ALL),
OPT_BIT( 0 , "mirror", &flags, "mirror all refs",
(TRANSPORT_PUSH_MIRROR|TRANSPORT_PUSH_FORCE)),
+ OPT_BOOLEAN( 0, "delete", &deleterefs, "delete refs"),
OPT_BOOLEAN( 0 , "tags", &tags, "push tags (can't be used with --all or --mirror)"),
OPT_BIT('n' , "dry-run", &flags, "dry run", TRANSPORT_PUSH_DRY_RUN),
OPT_BIT( 0, "porcelain", &flags, "machine-readable output", TRANSPORT_PUSH_PORCELAIN),
@@ -193,6 +204,11 @@ int cmd_push(int argc, const char **argv, const char *prefix)
argc = parse_options(argc, argv, prefix, options, push_usage, 0);
+ if (deleterefs && (tags || (flags & (TRANSPORT_PUSH_ALL | TRANSPORT_PUSH_MIRROR))))
+ die("--delete is incompatible with --all, --mirror and --tags");
+ if (deleterefs && argc < 2)
+ die("--delete doesn't make sense without any refs");
+
if (tags)
add_refspec("refs/tags/*");
diff --git a/t/t5516-fetch-push.sh b/t/t5516-fetch-push.sh
index 6889a53..aa1450a 100755
--- a/t/t5516-fetch-push.sh
+++ b/t/t5516-fetch-push.sh
@@ -546,6 +546,12 @@ test_expect_success 'allow deleting an invalid remote ref' '
'
+test_expect_success 'allow deleting a ref using --delete' '
+ mk_test heads/master &&
+ git push testrepo --delete master &&
+ (cd testrepo && test_must_fail git rev-parse --verify refs/heads/master)
+'
+
test_expect_success 'warn on push to HEAD of non-bare repository' '
mk_test heads/master
(cd testrepo &&
--
1.6.5.2.155.gbb47.dirty
^ permalink raw reply related
* Re: Git drawbacks?
From: Dmitry Potapov @ 2009-11-09 18:34 UTC (permalink / raw)
To: Dmitry Smirnov; +Cc: git
In-Reply-To: <loom.20091109T170054-451@post.gmane.org>
On Mon, Nov 09, 2009 at 04:11:48PM +0000, Dmitry Smirnov wrote:
> Dmitry Potapov <dpotapov <at> gmail.com> writes:
>
>
> > Actually, in most use cases, there is no reason to have more than one
> > working tree. Git is designed to work well with plenty branches and one
> > working tree. So, switching between two branches and recompiling a few
> > changed files is much faster then going to another directory and try to
> > work there, because when you go to another directory, you may hit cold
> > cache and disk is *slow*... Another thing is that you can do a lot of
> > things without checking out some branch. You can grep any revision in
> > your repository, you can insect any file from it, etc and you do not
> > have to checkout this revision in your working tree.
>
> Shouldn't I even worry about my not yet commited changes before switching the
> branch?
You probably want to use 'git stash save' and when you return back you
just do 'git stash pop'. Also, keep in mind that you can amend any
previous commit using 'git commit --amend'.
>
> I would say that this approach does not work if the build and test could take
> significant time.
Yes, but then I do not see any reason to do any time consuming building
and testing in the working tree. I create a snapshot of the interesting
version using 'git archive' and then run build&test on it... In this
way, I can make sure that the archive I deliver is tested properly. If
you do your testing in the working tree, sometimes uncommitted or some
other files that are left over from previous builds may affect result.
So, if it takes considerable time anyhow, why do not do clean build and
test? And if you worry about compilation time, you can use ccache.
Dmitry
^ permalink raw reply
* Re: [PATCH 2/3] t5551-http-fetch: Work around some libcurl versions
From: Tarmigan @ 2009-11-09 18:36 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1257790237-30850-2-git-send-email-spearce@spearce.org>
On Mon, Nov 9, 2009 at 10:10 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Some versions of libcurl report their output when GIT_CURL_VERBOSE
> is set differently than other versions do. At least one variant
> (version unknown but likely pre-7.18.1) reports the POST payload to
> stderr, and omits the blank line after each HTTP request/response.
Yes, my curl is 7.15.5.
> @@ -56,6 +52,8 @@ test_expect_success 'clone http repository' '
> sed -e "
> s/Q\$//
> /^[*] /d
> + /^$/d
> + /^< $/d
>
> /^[^><]/{
> s/^/> /
> @@ -64,6 +62,8 @@ test_expect_success 'clone http repository' '
> /^> User-Agent: /d
> /^> Host: /d
> s/^> Content-Length: .*/> Content-Length: xxx/
> + /^00..want /d
> + /^00.*done/d
Almost. This still needs a
'> '
before both of the 00 additions. Changing this and applying 3/3 makes
the test pass for me.
Tested-with-modifications-by: Tarmigan <tarmigan+git@gmail.com>
^ permalink raw reply
* Re: [RFC PATCH 3/3] t5551-http-fetch: Work around broken Accept header in libcurl
From: Tarmigan @ 2009-11-09 18:37 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1257790237-30850-3-git-send-email-spearce@spearce.org>
On Mon, Nov 9, 2009 at 10:10 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> Unfortunately at least one version of libcurl has a bug causing
> it to include "Accept: */*" in the same POST request where we have
> already asked for "Accept: application/x-git-upload-pack-response".
>
> This is a bug in libcurl, not Git, or our test vector. The
> application has explicitly asked the server for a single content
> type, but libcurl has mistakenly also told the server the client
> application will accept */*, which is any content type.
>
> Based on the libcurl change log, this "Accept: */*" header bug
> may have been fixed in version 7.18.1 released March 30, 2008:
>
> http://curl.haxx.se/changes.html#7_18_1
>
> Rather than require users to upgrade libcurl we change the test
> vector to trim this line out of the 2nd request.
>
> Reported-by: Tarmigan <tarmigan+git@gmail.com>
Tested-by: Tarmigan <tarmigan+git@gmail.com>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
^ permalink raw reply
* Re: question: connecting to multiple remote svn projects
From: Avery Pennarun @ 2009-11-09 18:43 UTC (permalink / raw)
To: Dave Rodgman; +Cc: git
In-Reply-To: <hd8smd$79e$2@ger.gmane.org>
On Mon, Nov 9, 2009 at 5:59 AM, Dave Rodgman <dav1dr@eml.cc> wrote:
> As far as I can understand, git-submodule pulls in a specific commit,
> as does git subtree? I've experimented a little but with not much success.
Well, they both pull in a specific commit *and* all the history
leading up to it, although the two of them do it in slightly different
ways.
> I want "git svn rebase" (or some equivalent command, or series of
> commands) to update the contents of module1/work to the latest commit
> into this branch, and similarly "git svn dcommit" should also commit into
> module1, module2, etc. Basically, I want my working copy to have the same
> functionality as if moduleX/work was the actual layout in subversion. I'm
> using git as a client for a svn repository, rather than doing a one-time
> import. Is this possible?
Yes. Both tools will work for two-way svn import/export, although
submodules will probably be a bit more convenient.
Essentially, you create one branch (and one git-svn remote entry) for
each svn subproject, and one branch for the combined project. In the
combined project, your .gitmodules should use '.' as the submodule
repository path (since all your submodule objects are in the same
local repo).
Then you 'git svn fetch' to retrieve the latest from each svn project.
Then, in each submodule, you can 'git pull .. git-svn-branchname' to
get the latest stuff from git-svn for that branch.
Then, in the combined project, you 'git commit' to lock in those commits.
It's a little screwy, but it works :)
Avery
^ permalink raw reply
page: next (older) | prev (newer) | latest
- recent:[subjects (threaded)|topics (new)|topics (active)]
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox