* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Anders Kaseorg @ 2009-10-13 14:29 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7vtyy3zo9m.fsf@alter.siamese.dyndns.org>
On Tue, 13 Oct 2009, Junio C Hamano wrote:
> I agree that "git bisect reset-and-detach-at-the-first-bad-one" would make
> a lot of sense.
Under my patch, that’s ‘git bisect reset bisect/bad’. Similar arguments
may be made as to whether that should or shouldn’t be a separate command
(although it’s less clear what to call it, in this case).
Anders
^ permalink raw reply
* Re: quote in help code example
From: bill lam @ 2009-10-13 14:06 UTC (permalink / raw)
To: Miklos Vajna; +Cc: git
In-Reply-To: <20091013101916.GV23777@genesis.frugalware.org>
On Tue, 13 Oct 2009, Miklos Vajna wrote:
> On Tue, Oct 13, 2009 at 10:16:17AM +0800, bill lam <cbill.lam@gmail.com> wrote:
> > > Just a guess: do you have docbook-xsl >=1.73.0 and you did not set
> > > ASCIIDOC_NO_ROFF?
> > >
> > > Try rebuilding the documentation using 'make ASCIIDOC_NO_ROFF=YesPlease'.
> >
> > I'm not familiar with how to twist git makefile. By adding a line to ./Makefile
> >
> > # Platform specific tweaks
> > #
> >
> > # We choose to avoid "if .. else if .. else .. endif endif"
> > # because maintaining the nesting to match is a pain. If
> > # we had "elif" things would have been much nicer...
> >
> > ASCIIDOC_NO_ROFF = YesPlease # <--- this line added
> > ifeq ($(uname_S),Linux)
> >
> > However, the man page still display the same
>
> Don't edit the Makefile, just use the command 'make
> ASCIIDOC_NO_ROFF=YesPlease'. Also make sure to do a 'make clean' in the
> Documentation dir to get the manpages rebuilt.
I run these commands
make ASCIIDOC_NO_ROFF=YesPlease prefix=/usr all doc info
sudo make ASCIIDOC_NO_ROFF=YesPlease prefix=/usr install install-doc install-html install-info
1. did I need to set ASCIIDOC_NO_ROFF in both lines?
2. now the .ft pair fixed but it still displayed incorrect quote.
git filter-branch --tree-filter ´rm filename´ HEAD
it should be 'rm filename' not ´rm filename´
--
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3
^ permalink raw reply
* Re: Changing branches in supermodule does not affect submodule?
From: Jens Lehmann @ 2009-10-13 13:11 UTC (permalink / raw)
To: Peter Krefting; +Cc: Git Mailing List
In-Reply-To: <alpine.DEB.2.00.0910131115160.14223@ds9.cixit.se>
Peter Krefting schrieb:
> If I have a repository with submodules that is in a clean state, and
> switch branches in the super repository, the submodules are left in the
> state they were in before I switched branches (with 1.6.4, at least). Is
> this the expected behaviour?
Yup, submodules have to be updated separatly.
When they are cloned from a remote with "git submodule add" followed by
a "git submodule init", just calling "git submodule update" every time
you want the submodule to be updated according to the state committed
in the superproject will do the trick (but keep in mind that all
referenced commits have to be accessible in the local clone of your
submodule, so you might have to do a fetch there once in a while).
Jens
^ permalink raw reply
* Re: gitweb atom feeds broken (on repo.or.cz only?)
From: Sebastian Pipping @ 2009-10-13 12:14 UTC (permalink / raw)
To: Petr Baudis; +Cc: git
In-Reply-To: <4AC0CBBE.7020603@hartwork.org>
Petr, any news on this one?
I just check and it still seems broken.
Sebastian
^ permalink raw reply
* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: Michael Wookey @ 2009-10-13 11:43 UTC (permalink / raw)
To: Johannes Sixt
Cc: Junio C Hamano, eduard stefan, Tay Ray Chuan, Git Mailing List,
msysgit
In-Reply-To: <4AD45C28.4080501@viscovery.net>
2009/10/13 Johannes Sixt <j.sixt@viscovery.net>:
> Michael Wookey schrieb:
>> Using the above repository, I see the same crash with msysGit at git
>> revision 1.6.5. Using windbg as the post-mortem debugger, the
>> following information is captured:
>> [ ... snip ... ]
> Wow, this is great work, thank you very much! The function is
> strip_path_suffix(). And here is a patch that fixes the crash.
>
> --- >8 ---
> From: Johannes Sixt <j6t@kdbg.org>
> Subject: [PATCH] remote-curl: add missing initialization of argv0_path
>
> All programs, in particular also the stand-alone programs (non-builtins)
> must call git_extract_argv0_path(argv[0]) in order to help builds that
> derive the installation prefix at runtime, such as the MinGW build.
> Without this call, the program segfaults (or raises an assertion
> failure).
>
> Signed-off-by: Johannes Sixt <j6t@kdbg.org>
> ---
> remote-curl.c | 1 +
> 1 files changed, 1 insertions(+), 0 deletions(-)
>
> diff --git a/remote-curl.c b/remote-curl.c
> index ad6a163..d8d276a 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -82,6 +82,7 @@ int main(int argc, const char **argv)
> const char *url;
> struct walker *walker = NULL;
>
> + git_extract_argv0_path(argv[0]);
> setup_git_directory();
> if (argc < 2) {
> fprintf(stderr, "Remote needed\n");
> --
> 1.6.5.1024.g31034.dirty
No more crashes for me :)
Tested-by: Michael Wookey <michaelwookey@gmail.com>
^ permalink raw reply
* [PATCH] NO_PERL_MAKEMAKER should behave more like ExtUtils::MakeMaker
From: Tom G. Christensen @ 2009-10-13 11:14 UTC (permalink / raw)
To: git
This change makes NO_PERL_MAKEMAKER behave more as ExtUtils::MakeMaker
by installing the modules into the perl libdir and not $(prefix)/lib.
It will default to sitelib but will allow the user to choose by setting
the INSTALLDIRS variable which is also honored by ExtUtils::MakeMaker.
Signed-off-by: Tom G. Christensen <tgc@statsbiblioteket.dk>
---
perl/Makefile | 7 ++++++-
1 files changed, 6 insertions(+), 1 deletions(-)
diff --git a/perl/Makefile b/perl/Makefile
index 4ab21d6..264cfc1 100644
--- a/perl/Makefile
+++ b/perl/Makefile
@@ -20,7 +20,12 @@ clean:
$(RM) $(makfile).old
ifdef NO_PERL_MAKEMAKER
-instdir_SQ = $(subst ','\'',$(prefix)/lib)
+perllib = site
+ifdef INSTALLDIRS
+perllib = $(INSTALLDIRS)
+endif
+perlinstdir := $(shell sh -c "$(PERL_PATH_SQ) -V:install$(perllib)lib | cut -d\' -f2")
+instdir_SQ = $(subst ','\'',$(perlinstdir))
$(makfile): ../GIT-CFLAGS Makefile
echo all: private-Error.pm Git.pm > $@
echo ' mkdir -p blib/lib' >> $@
--
1.6.4.4
^ permalink raw reply related
* Re: [RFC PATCH v2 14/16] Smart push over HTTP: client side
From: Felipe Contreras @ 2009-10-13 11:02 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Daniel Barkalow
In-Reply-To: <1255400715-10508-15-git-send-email-spearce@spearce.org>
On Tue, Oct 13, 2009 at 5:25 AM, Shawn O. Pearce <spearce@spearce.org> wrote:
> The git-remote-curl backend detects if the remote server supports
> the git-receive-pack service, and if so, runs git-send-pack in a
> pipe to dump the command and pack data as a single POST request.
>
> The advertisements from the server that were obtained during the
> discovery are passed into git-send-pack before the POST request
> starts. This permits git-send-pack to operate largely unmodified.
>
> For smaller packs (those under 1 MiB) a tranditional POST with a
Traditional?
> Content-Length is used, permitting interaction with any HTTP/1.0
> compliant server. The 1 MiB limit is arbitrary, but is sufficent
> to fit most deltas created by human authors against text sources
> with the occasional small binary file (e.g. few KiB icon image).
>
> For larger packs which cannot be spooled entirely into the
> helper's memory space, the POST request requires HTTP/1.1 and
> Transfer-Encoding: chunked. This permits the client to upload an
> unknown amount of data in one HTTP transaction without needing to
> pregenerate the entire pack file locally.
>
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
> CC: Daniel Barkalow <barkalow@iabervon.org>
> ---
> Documentation/config.txt | 8 ++
> builtin-send-pack.c | 116 ++++++++++++++++++++-
> remote-curl.c | 258 +++++++++++++++++++++++++++++++++++++++++++++-
> send-pack.h | 3 +-
> sideband.c | 11 ++-
> transport.c | 1 +
> 6 files changed, 384 insertions(+), 13 deletions(-)
>
> diff --git a/Documentation/config.txt b/Documentation/config.txt
> index cd17814..7130d07 100644
> --- a/Documentation/config.txt
> +++ b/Documentation/config.txt
> @@ -1089,6 +1089,14 @@ http.maxRequests::
> How many HTTP requests to launch in parallel. Can be overridden
> by the 'GIT_HTTP_MAX_REQUESTS' environment variable. Default is 5.
>
> +http.postBuffer::
> + Maximum size in bytes of the buffer used by smart HTTP
> + transports when POSTing data to the remote system.
> + For requests larger than this buffer size, HTTP/1.1 and
> + Transfer-Encoding: chunked is used to avoid creating a
> + massive pack file locally. Default is 1 MiB, which is
> + sufficient for most requests.
> +
> http.lowSpeedLimit, http.lowSpeedTime::
> If the HTTP transfer speed is less than 'http.lowSpeedLimit'
> for longer than 'http.lowSpeedTime' seconds, the transfer is aborted.
> diff --git a/builtin-send-pack.c b/builtin-send-pack.c
> index 37e528e..654c3d4 100644
> --- a/builtin-send-pack.c
> +++ b/builtin-send-pack.c
> @@ -2,9 +2,11 @@
> #include "commit.h"
> #include "refs.h"
> #include "pkt-line.h"
> +#include "sideband.h"
> #include "run-command.h"
> #include "remote.h"
> #include "send-pack.h"
> +#include "quote.h"
>
> static const char send_pack_usage[] =
> "git send-pack [--all | --mirror] [--dry-run] [--force] [--receive-pack=<git-receive-pack>] [--verbose] [--thin] [<host>:]<directory> [<ref>...]\n"
> @@ -59,7 +61,7 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
> memset(&po, 0, sizeof(po));
> po.argv = argv;
> po.in = -1;
> - po.out = fd;
> + po.out = args->one_shot_rpc ? -1 : fd;
> po.git_cmd = 1;
> if (start_command(&po))
> die_errno("git pack-objects failed");
> @@ -83,6 +85,20 @@ static int pack_objects(int fd, struct ref *refs, struct extra_have_objects *ext
> }
>
> close(po.in);
> +
> + if (args->one_shot_rpc) {
> + char *buf = xmalloc(LARGE_PACKET_MAX);
> + while (1) {
> + ssize_t n = xread(po.out, buf, LARGE_PACKET_MAX);
> + if (n <= 0)
> + break;
> + send_sideband(fd, -1, buf, n, LARGE_PACKET_MAX);
> + }
> + free(buf);
> + close(po.out);
> + po.out = -1;
> + }
> +
> if (finish_command(&po))
> return error("pack-objects died with strange error");
> return 0;
> @@ -303,6 +319,59 @@ static int refs_pushed(struct ref *ref)
> return 0;
> }
>
> +static void print_helper_status(struct ref *ref)
> +{
> + struct strbuf buf = STRBUF_INIT;
> +
> + for (; ref; ref = ref->next) {
> + const char *msg = NULL;
> + const char *res;
> +
> + switch(ref->status) {
> + case REF_STATUS_NONE:
> + res = "error";
> + msg = "no match";
> + break;
> +
> + case REF_STATUS_OK:
> + res = "ok";
> + break;
> +
> + case REF_STATUS_UPTODATE:
> + res = "ok";
> + msg = "up to date";
> + break;
> +
> + case REF_STATUS_REJECT_NONFASTFORWARD:
> + res = "error";
> + msg = "non-fast forward";
> + break;
> +
> + case REF_STATUS_REJECT_NODELETE:
> + case REF_STATUS_REMOTE_REJECT:
> + res = "error";
> + break;
> +
> + case REF_STATUS_EXPECTING_REPORT:
> + default:
> + continue;
> + }
> +
> + strbuf_reset(&buf);
> + strbuf_addf(&buf, "%s %s", res, ref->name);
> + if (ref->remote_status)
> + msg = ref->remote_status;
> + if (msg) {
> + strbuf_addch(&buf, ' ');
> + quote_two_c_style(&buf, "", msg, 0);
> + }
> + strbuf_addch(&buf, '\n');
> +
> + safe_write(1, buf.buf, buf.len);
> + }
> + strbuf_release(&buf);
> +}
> +
> int send_pack(struct send_pack_args *args,
> int fd[], struct child_process *conn,
> struct ref *remote_refs,
> @@ -310,6 +379,7 @@ int send_pack(struct send_pack_args *args,
> {
> int in = fd[0];
> int out = fd[1];
> + struct strbuf req_buf = STRBUF_INIT;
> struct ref *ref;
> int new_refs;
> int ask_for_status_report = 0;
> @@ -391,14 +461,14 @@ int send_pack(struct send_pack_args *args,
> char *new_hex = sha1_to_hex(ref->new_sha1);
>
> if (ask_for_status_report) {
> - packet_write(out, "%s %s %s%c%s",
> + packet_buf_write(&req_buf, "%s %s %s%c%s",
> old_hex, new_hex, ref->name, 0,
> "report-status");
> ask_for_status_report = 0;
> expect_status_report = 1;
> }
> else
> - packet_write(out, "%s %s %s",
> + packet_buf_write(&req_buf, "%s %s %s",
> old_hex, new_hex, ref->name);
> }
> ref->status = expect_status_report ?
> @@ -406,7 +476,17 @@ int send_pack(struct send_pack_args *args,
> REF_STATUS_OK;
> }
>
> - packet_flush(out);
> + if (args->one_shot_rpc) {
> + if (!args->dry_run) {
> + packet_buf_flush(&req_buf);
> + send_sideband(out, -1, req_buf.buf, req_buf.len, LARGE_PACKET_MAX);
> + }
> + } else {
> + safe_write(out, req_buf.buf, req_buf.len);
> + packet_flush(out);
> + }
> + strbuf_release(&req_buf);
> +
> if (new_refs && !args->dry_run) {
> if (pack_objects(out, remote_refs, extra_have, args) < 0) {
> for (ref = remote_refs; ref; ref = ref->next)
> @@ -414,11 +494,15 @@ int send_pack(struct send_pack_args *args,
> return -1;
> }
> }
> + if (args->one_shot_rpc && !args->dry_run)
> + packet_flush(out);
>
> if (expect_status_report)
> ret = receive_status(in, remote_refs);
> else
> ret = 0;
> + if (args->one_shot_rpc)
> + packet_flush(out);
>
> if (ret < 0)
> return ret;
> @@ -478,6 +562,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
> struct extra_have_objects extra_have;
> struct ref *remote_refs, *local_refs;
> int ret;
> + int helper_status = 0;
> int send_all = 0;
> const char *receivepack = "git-receive-pack";
> int flags;
> @@ -523,6 +608,14 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
> args.use_thin_pack = 1;
> continue;
> }
> + if (!strcmp(arg, "--one-shot-rpc")) {
> + args.one_shot_rpc = 1;
> + continue;
> + }
> + if (!strcmp(arg, "--helper-status")) {
> + helper_status = 1;
> + continue;
> + }
> usage(send_pack_usage);
> }
> if (!dest) {
> @@ -551,7 +644,14 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
> }
> }
>
> - conn = git_connect(fd, dest, receivepack, args.verbose ? CONNECT_VERBOSE : 0);
> + if (args.one_shot_rpc) {
> + conn = NULL;
> + fd[0] = 0;
> + fd[1] = 1;
> + } else {
> + conn = git_connect(fd, dest, receivepack,
> + args.verbose ? CONNECT_VERBOSE : 0);
> + }
>
> memset(&extra_have, 0, sizeof(extra_have));
>
> @@ -575,12 +675,16 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
>
> ret = send_pack(&args, fd, conn, remote_refs, &extra_have);
>
> + if (helper_status)
> + print_helper_status(remote_refs);
> +
> close(fd[1]);
> close(fd[0]);
>
> ret |= finish_connect(conn);
>
> - print_push_status(dest, remote_refs);
> + if (!helper_status)
> + print_push_status(dest, remote_refs);
>
> if (!args.dry_run && remote) {
> struct ref *ref;
> diff --git a/remote-curl.c b/remote-curl.c
> index 42fd06c..529df42 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -5,17 +5,33 @@
> #include "walker.h"
> #include "http.h"
> #include "pkt-line.h"
> +#include "sideband.h"
> #include "run-command.h"
>
>
> +static size_t post_buffer_size = 16 * LARGE_PACKET_MAX;
> static struct remote *remote;
> static const char *url;
> static struct walker *walker;
>
> +static int http_options(const char *var, const char *value, void *cb)
> +{
> + if (!strcmp("http.postbuffer", var)) {
> + post_buffer_size = git_config_int(var, value);
> + if (post_buffer_size < LARGE_PACKET_MAX)
> + post_buffer_size = LARGE_PACKET_MAX;
> + return 0;
> + }
> +
> + return 0;
> +}
> +
> static void init_walker(void)
> {
> - if (!walker)
> + if (!walker) {
> walker = get_http_walker(url, remote);
> + git_config(http_options, NULL);
> + }
> }
>
> struct discovery {
> @@ -200,6 +216,193 @@ static void output_refs(struct ref *refs)
> free_refs(refs);
> }
>
> +struct rpc_state {
> + const char *service_name;
> + char *service_url;
> + char *hdr_content_type;
> + char *hdr_accept;
> + char *buf;
> + size_t alloc;
> + size_t len;
> + size_t pos;
> + int in;
> + int out;
> + unsigned verbose : 1;
> +};
> +
> +static size_t rpc_out(void *ptr, size_t eltsize,
> + size_t nmemb, void *buffer_)
> +{
> + size_t max = eltsize * nmemb;
> + struct rpc_state *state = buffer_;
> + size_t avail = state->len - state->pos;
> +
> + if (!avail) {
> + avail = packet_read_line(state->out, state->buf, state->alloc);
> + if (!avail)
> + return 0;
> + state->pos = 0;
> + state->len = avail;
> + }
> +
> + if (max < avail);
> + avail = max;
> + memcpy(ptr, state->buf + state->pos, avail);
> + state->pos += avail;
> + return avail;
> +}
> +
> +static size_t rpc_in(const void *ptr, size_t eltsize,
> + size_t nmemb, void *buffer_)
> +{
> + size_t size = eltsize * nmemb;
> + struct rpc_state *state = buffer_;
> + write_or_die(state->in, ptr, size);
> + return size;
> +}
> +
> +static int post_rpc(struct rpc_state *state)
> +{
> + struct active_request_slot *slot;
> + struct slot_results results;
> + struct curl_slist *headers = NULL;
> + int err = 0, large_request = 0;
> +
> + /* Try to load the entire request, if we can fit it into the
> + * allocated buffer space we can use HTTP/1.0 and avoid the
> + * chunked encoding mess.
> + */
> + while (1) {
> + size_t left = state->alloc - state->len;
> + char *buf = state->buf + state->len;
> + int n;
> +
> + if (left < LARGE_PACKET_MAX) {
> + large_request = 1;
> + break;
> + }
> +
> + n = packet_read_line(state->out, buf, left);
> + if (!n)
> + break;
> + state->len += n;
> + }
> +
> + slot = get_active_slot();
> + slot->results = &results;
> +
> + curl_easy_setopt(slot->curl, CURLOPT_POST, 1);
> + curl_easy_setopt(slot->curl, CURLOPT_NOBODY, 0);
> + curl_easy_setopt(slot->curl, CURLOPT_URL, state->service_url);
> +
> + headers = curl_slist_append(headers, state->hdr_content_type);
> + headers = curl_slist_append(headers, state->hdr_accept);
> +
> + if (large_request) {
> + /* The request body is large and the size cannot be predicted.
> + * We must use chunked encoding to send it.
> + */
> + headers = curl_slist_append(headers, "Expect: 100-continue");
> + headers = curl_slist_append(headers, "Transfer-Encoding: chunked");
> + curl_easy_setopt(slot->curl, CURLOPT_READFUNCTION, rpc_out);
> + curl_easy_setopt(slot->curl, CURLOPT_INFILE, state);
> + if (state->verbose) {
> + fprintf(stderr, "POST %s (chunked)\n", state->service_name);
> + fflush(stderr);
> + }
> +
> + } else {
> + /* We know the complete request size in advance, use the
> + * more normal Content-Length approach.
> + */
> + curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDS, state->buf);
> + curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDSIZE, state->len);
> + if (state->verbose) {
> + fprintf(stderr, "POST %s (%lu bytes)\n",
> + state->service_name, (unsigned long)state->len);
> + fflush(stderr);
> + }
> + }
> +
> + curl_easy_setopt(slot->curl, CURLOPT_HTTPHEADER, headers);
> + curl_easy_setopt(slot->curl, CURLOPT_WRITEFUNCTION, rpc_in);
> + curl_easy_setopt(slot->curl, CURLOPT_FILE, state);
> +
> + if (start_active_slot(slot)) {
> + run_active_slot(slot);
> + if (results.curl_result != CURLE_OK) {
> + err |= error("RPC failed; result=%d, HTTP code = %ld",
> + results.curl_result, results.http_code);
> + }
> + }
> + curl_slist_free_all(headers);
> + return err;
> +}
> +
> +static int one_shot_rpc_service(const char *service,
> + int verbose,
> + const char **client_argv,
> + struct discovery *heads,
> + struct strbuf *result)
> +{
> + struct child_process client;
> + struct rpc_state state;
> + struct strbuf buf = STRBUF_INIT;
> + int err = 0;
> +
> + init_walker();
> + memset(&client, 0, sizeof(client));
> + client.in = -1;
> + client.out = -1;
> + client.git_cmd = 1;
> + client.argv = client_argv;
> + if (start_command(&client))
> + die("%s failed to execute", client_argv[0]);
> + if (heads)
> + write_or_die(client.in, heads->buf, heads->len);
> +
> + memset(&state, 0, sizeof(state));
> + state.alloc = post_buffer_size;
> + state.buf = xmalloc(state.alloc);
> + state.in = client.in;
> + state.out = client.out;
> + state.service_name = service;
> + state.verbose = !!verbose;
> +
> + strbuf_addf(&buf, "%s/%s", url, service);
> + state.service_url = strbuf_detach(&buf, NULL);
> +
> + strbuf_addf(&buf, "Content-Type: application/x-%s-request", service);
> + state.hdr_content_type = strbuf_detach(&buf, NULL);
> +
> + strbuf_addf(&buf, "Accept: application/x-%s-response", service);
> + state.hdr_accept = strbuf_detach(&buf, NULL);
> +
> + while (!err) {
> + int n = packet_read_line(state.out, state.buf, state.alloc);
> + if (!n)
> + break;
> + state.pos = 0;
> + state.len = n;
> + err |= post_rpc(&state);
> + }
> + if (result)
> + strbuf_read(result, client.out, 0);
> +
> + close(client.in);
> + close(client.out);
> + client.in = -1;
> + client.out = -1;
> +
> + err |= finish_command(&client);
> + free(state.service_url);
> + free(state.hdr_content_type);
> + free(state.hdr_accept);
> + free(state.buf);
> + strbuf_release(&buf);
> + return err;
> +}
> +
> struct fetch_args {
> unsigned verbose : 1;
> };
> @@ -289,7 +492,8 @@ static void parse_fetch(struct strbuf *buf, int multiple)
>
> struct push_args {
> unsigned dry_run : 1,
> - verbose : 1;
> + verbose : 1,
> + thin : 1;
> };
>
> static int push_dav(struct push_args *args, int nr_spec, char **specs)
> @@ -314,6 +518,51 @@ static int push_dav(struct push_args *args, int nr_spec, char **specs)
> return 0;
> }
>
> +static int push_git(struct discovery *heads,
> + struct push_args *args, int nr_spec, char **specs)
> +{
> + struct strbuf res = STRBUF_INIT;
> + const char **argv;
> + int argc = 0, i, err;
> +
> + argv = xmalloc((10 + nr_spec) * sizeof(char*));
> + argv[argc++] = "send-pack";
> + argv[argc++] = "--one-shot-rpc";
> + argv[argc++] = "--helper-status";
> + if (args->thin)
> + argv[argc++] = "--thin";
> + if (args->dry_run)
> + argv[argc++] = "--dry-run";
> + if (args->verbose)
> + argv[argc++] = "--verbose";
> + argv[argc++] = url;
> + for (i = 0; i < nr_spec; i++)
> + argv[argc++] = specs[i];
> + argv[argc++] = NULL;
> +
> + err = one_shot_rpc_service("git-receive-pack",
> + args->verbose,
> + argv, heads, &res);
> + if (res.len)
> + safe_write(1, res.buf, res.len);
> + strbuf_release(&res);
> + free(argv);
> + return err;
> +}
> +
> +static int push(struct push_args *args, int nr_spec, char **specs)
> +{
> + struct discovery *heads = discover_refs("git-receive-pack");
> + int ret;
> +
> + if (heads->proto_git)
> + ret = push_git(heads, args, nr_spec, specs);
> + else
> + ret = push_dav(args, nr_spec, specs);
> + free_discovery(heads);
> + return ret;
> +}
> +
> static void parse_push(struct strbuf *buf)
> {
> char **specs = NULL;
> @@ -330,6 +579,8 @@ static void parse_push(struct strbuf *buf)
> args.dry_run = 1;
> else if (!strcmp(buf->buf, "option verbose"))
> args.verbose = 1;
> + else if (!strcmp(buf->buf, "option thin"))
> + args.thin = 1;
> else
> die("http transport does not support %s", buf->buf);
>
> @@ -340,7 +591,7 @@ static void parse_push(struct strbuf *buf)
> break;
> } while (1);
>
> - if (push_dav(&args, nr_spec, specs))
> + if (push(&args, nr_spec, specs))
> exit(128); /* error already reported */
> for (i = 0; i < nr_spec; i++)
> free(specs[i]);
> @@ -395,6 +646,7 @@ int main(int argc, const char **argv)
> printf("fetch-multiple\n");
> printf("push\n");
> printf("option dry-run\n");
> + printf("option thin\n");
> printf("option verbose\n");
> printf("\n");
> fflush(stdout);
> diff --git a/send-pack.h b/send-pack.h
> index 8b3cf02..a7f4abf 100644
> --- a/send-pack.h
> +++ b/send-pack.h
> @@ -8,7 +8,8 @@ struct send_pack_args {
> force_update:1,
> use_thin_pack:1,
> use_ofs_delta:1,
> - dry_run:1;
> + dry_run:1,
> + one_shot_rpc:1;
> };
>
> int send_pack(struct send_pack_args *args,
> diff --git a/sideband.c b/sideband.c
> index 899b1ff..d5ffa1c 100644
> --- a/sideband.c
> +++ b/sideband.c
> @@ -135,9 +135,14 @@ ssize_t send_sideband(int fd, int band, const char *data, ssize_t sz, int packet
> n = sz;
> if (packet_max - 5 < n)
> n = packet_max - 5;
> - sprintf(hdr, "%04x", n + 5);
> - hdr[4] = band;
> - safe_write(fd, hdr, 5);
> + if (0 <= band) {
> + sprintf(hdr, "%04x", n + 5);
> + hdr[4] = band;
> + safe_write(fd, hdr, 5);
> + } else {
> + sprintf(hdr, "%04x", n + 4);
> + safe_write(fd, hdr, 4);
> + }
> safe_write(fd, p, n);
> p += n;
> sz -= n;
> diff --git a/transport.c b/transport.c
> index 6d9652d..2ff1650 100644
> --- a/transport.c
> +++ b/transport.c
> @@ -731,6 +731,7 @@ static int git_transport_push(struct transport *transport, struct ref *remote_re
> NULL);
> }
>
> + memset(&args, 0, sizeof(args));
> args.send_mirror = !!(flags & TRANSPORT_PUSH_MIRROR);
> args.force_update = !!(flags & TRANSPORT_PUSH_FORCE);
> args.use_thin_pack = data->thin;
> --
> 1.6.5.52.g0ff2e
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
--
Felipe Contreras
^ permalink raw reply
* Re: [RFC PATCH v2 10/16] Git-aware CGI to provide dumb HTTP transport
From: Johannes Sixt @ 2009-10-13 10:56 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1255400715-10508-11-git-send-email-spearce@spearce.org>
Shawn O. Pearce schrieb:
> +int main(int argc, char **argv)
> +{
> + char *dir = getenv("PATH_TRANSLATED");
> + char *input_method = getenv("REQUEST_METHOD");
> + struct service_cmd *cmd = NULL;
> + char *cmd_arg = NULL;
> + int i;
> +
Please insert here:
git_extract_argv0_path(argv[0]);
> + set_die_routine(die_webcgi);
> ...
-- Hannes
^ permalink raw reply
* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: Johannes Sixt @ 2009-10-13 10:53 UTC (permalink / raw)
To: Michael Wookey, Junio C Hamano
Cc: eduard stefan, Tay Ray Chuan, Git Mailing List, msysgit
In-Reply-To: <d2e97e800910130310wa9731a6j9b9bdd25047ade85@mail.gmail.com>
Michael Wookey schrieb:
> Using the above repository, I see the same crash with msysGit at git
> revision 1.6.5. Using windbg as the post-mortem debugger, the
> following information is captured:
>
> (a14.e8c): Access violation - code c0000005 (!!! second chance !!!)
> eax=00000000 ebx=00000000 ecx=ffffffff edx=0046cc00 esi=0046f98f edi=00000000
> eip=00420354 esp=0022fd80 ebp=0022fda8 iopl=0 nv up ei pl zr na pe nc
> cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
>
> ...and the faulting instruction is:
>
> git_remote_curl+0x20354:
> 00420354 f2ae repne scas byte ptr es:[edi]
>
> so, a NULL dereference. The initial disassembly of the function is this:
>
> 0:000> u 0042033C
> git_remote_curl+0x2033c:
> 0042033c 55 push ebp
> 0042033d 89e5 mov ebp,esp
> 0042033f 57 push edi
> 00420340 56 push esi
> 00420341 53 push ebx
> 00420342 83ec1c sub esp,1Ch
> 00420345 8b5d08 mov ebx,dword ptr [ebp+8]
> 00420348 8b750c mov esi,dword ptr [ebp+0Ch]
> 0042034b 31c0 xor eax,eax
> 0042034d b9ffffffff mov ecx,0FFFFFFFFh
> 00420352 89df mov edi,ebx
> 00420354 f2ae repne scas byte ptr es:[edi]
> 00420356 f7d1 not ecx
> 00420358 8d51ff lea edx,[ecx-1]
> 0042035b b9ffffffff mov ecx,0FFFFFFFFh
> 00420360 89f7 mov edi,esi
> 00420362 f2ae repne scas byte ptr es:[edi]
> 00420364 f7d1 not ecx
> 00420366 49 dec ecx
> 00420367 7466 je git_remote_curl+0x203cf (004203cf)
> 00420369 85d2 test edx,edx
> 0042036b 0f84b1000000 je git_remote_curl+0x20422 (00420422)
> 00420371 89f7 mov edi,esi
> 00420373 89de mov esi,ebx
> ...
>
> So its the first parameter that is NULL. The second parameter is:
>
> 0:000> da poi(ebp+c)
> 0046f98f "libexec/git-core"
>
> I don't know how to build msysGit so that symbols are generated so
> I've attempted to reconstruct the source code; which ends up looking
> something like the following:
>
> int some_unknown_func(char *arg1, char *arg2)
> {
> len1 = strlen(arg1) - 1; // <- crash here
> len2 = strlen(arg2);
> len3 = len2 - 1;
>
> if (len2 != 1) {
> if (!len1)
> return 0;
> for (;;) {
> x = arg1[len1 - 1];
>
> if (x != '/' && x != '\\') {
> --len1;
> --len3;
> if (arg1[len1] != arg2[len3])
> return 0;
> } else {
> ...
> }
> }
> }
> }
>
> Perhaps those more familiar with git's sources might recognise code
> that looks similar to the above sequence.
Wow, this is great work, thank you very much! The function is
strip_path_suffix(). And here is a patch that fixes the crash.
--- >8 ---
From: Johannes Sixt <j6t@kdbg.org>
Subject: [PATCH] remote-curl: add missing initialization of argv0_path
All programs, in particular also the stand-alone programs (non-builtins)
must call git_extract_argv0_path(argv[0]) in order to help builds that
derive the installation prefix at runtime, such as the MinGW build.
Without this call, the program segfaults (or raises an assertion
failure).
Signed-off-by: Johannes Sixt <j6t@kdbg.org>
---
remote-curl.c | 1 +
1 files changed, 1 insertions(+), 0 deletions(-)
diff --git a/remote-curl.c b/remote-curl.c
index ad6a163..d8d276a 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -82,6 +82,7 @@ int main(int argc, const char **argv)
const char *url;
struct walker *walker = NULL;
+ git_extract_argv0_path(argv[0]);
setup_git_directory();
if (argc < 2) {
fprintf(stderr, "Remote needed\n");
--
1.6.5.1024.g31034.dirty
^ permalink raw reply related
* Changing branches in supermodule does not affect submodule?
From: Peter Krefting @ 2009-10-13 10:29 UTC (permalink / raw)
To: Git Mailing List
Hi!
If I have a repository with submodules that is in a clean state, and switch
branches in the super repository, the submodules are left in the state they
were in before I switched branches (with 1.6.4, at least). Is this the
expected behaviour?
--->8--8<---
#!/bin/bash
# Create supermodule.
mkdir super-$$
cd super-$$
git init
# Create submodule with commit.
mkdir sub
cd sub
git init
echo C > c.txt
echo D > d.txt
git add c.txt d.txt
git commit -m Created.
cd ..
# Create commit and branch in supermodule.
echo A > a.txt
echo B > b.txt
git add a.txt b.txt sub
git commit -m Created.
git tag branchpoint
git checkout -b branch1
# Create branch1 in submodule and commit.
cd sub
git checkout -b branch1
echo E > c.txt
echo F > d.txt
git add c.txt d.txt
git commit -m Branched.
cd ..
# Commit to a branch in the supermodule.
git add sub
git commit -m Sub-update.
# Status should now be clean.
git status
# Create a new branch in supermodule, from the original commit.
git checkout -b branch2 branchpoint
# I now expect the submodule to be up-to-date and the state clean.
git status
--->8--8<---
--
\\// Peter - http://www.softwolves.pp.se/
^ permalink raw reply
* Re: [RFC/PATCH] gitweb: linkify author/committer names with search
From: Giuseppe Bilotta @ 2009-10-13 10:26 UTC (permalink / raw)
To: git; +Cc: Giuseppe Bilotta, Stephen Boyd, Jakub Narebski
In-Reply-To: <1255328340-28449-1-git-send-email-bebarino@gmail.com>
On Monday 12 October 2009 08:19, Stephen Boyd wrote:
> The problem is I can't get it to work with UTF-8 characters. I'm not sure
> if it's my system or not, so I'm just posting here to see if others
> experience the same problem and if there's interest.
Does it work if you use CGI::escape() on the author names when filling
the searchtext?
--
Giuseppe "Oblomov" Bilotta
^ permalink raw reply
* Re: quote in help code example
From: Miklos Vajna @ 2009-10-13 10:19 UTC (permalink / raw)
To: bill lam; +Cc: git
In-Reply-To: <20091013021616.GA10554@debian.b2j>
[-- Attachment #1: Type: text/plain, Size: 892 bytes --]
On Tue, Oct 13, 2009 at 10:16:17AM +0800, bill lam <cbill.lam@gmail.com> wrote:
> > Just a guess: do you have docbook-xsl >=1.73.0 and you did not set
> > ASCIIDOC_NO_ROFF?
> >
> > Try rebuilding the documentation using 'make ASCIIDOC_NO_ROFF=YesPlease'.
>
> I'm not familiar with how to twist git makefile. By adding a line to ./Makefile
>
> # Platform specific tweaks
> #
>
> # We choose to avoid "if .. else if .. else .. endif endif"
> # because maintaining the nesting to match is a pain. If
> # we had "elif" things would have been much nicer...
>
> ASCIIDOC_NO_ROFF = YesPlease # <--- this line added
> ifeq ($(uname_S),Linux)
>
> However, the man page still display the same
Don't edit the Makefile, just use the command 'make
ASCIIDOC_NO_ROFF=YesPlease'. Also make sure to do a 'make clean' in the
Documentation dir to get the manpages rebuilt.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Re: Git 1.6.5-rc git clone unhandled exception using http protocol
From: Michael Wookey @ 2009-10-13 10:10 UTC (permalink / raw)
To: eduard stefan; +Cc: Tay Ray Chuan, Git Mailing List, msysgit, Junio C Hamano
In-Reply-To: <4AD0BBCB.8000306@gmail.com>
2009/10/11 eduard stefan <eduard.stefan@gmail.com>:
> Tay Ray Chuan wrote:
>> I suspect, as you do, it's got to do with remote-curl.
>>
>> Could you try this command?
>>
>> echo list | git remote-curl http://github.com/loudej/spark.git
>
> Inside an empty repository it crashes the same way,
> without any additional information.
> "git remote-curl" crashes in the same way,
> but "git remote-curl --help" tries to launch the browser.
>
> Is there any way to obtain more information from this crash?
> Some debug mode?
Using the above repository, I see the same crash with msysGit at git
revision 1.6.5. Using windbg as the post-mortem debugger, the
following information is captured:
(a14.e8c): Access violation - code c0000005 (!!! second chance !!!)
eax=00000000 ebx=00000000 ecx=ffffffff edx=0046cc00 esi=0046f98f edi=00000000
eip=00420354 esp=0022fd80 ebp=0022fda8 iopl=0 nv up ei pl zr na pe nc
cs=001b ss=0023 ds=0023 es=0023 fs=003b gs=0000 efl=00010246
...and the faulting instruction is:
git_remote_curl+0x20354:
00420354 f2ae repne scas byte ptr es:[edi]
so, a NULL dereference. The initial disassembly of the function is this:
0:000> u 0042033C
git_remote_curl+0x2033c:
0042033c 55 push ebp
0042033d 89e5 mov ebp,esp
0042033f 57 push edi
00420340 56 push esi
00420341 53 push ebx
00420342 83ec1c sub esp,1Ch
00420345 8b5d08 mov ebx,dword ptr [ebp+8]
00420348 8b750c mov esi,dword ptr [ebp+0Ch]
0042034b 31c0 xor eax,eax
0042034d b9ffffffff mov ecx,0FFFFFFFFh
00420352 89df mov edi,ebx
00420354 f2ae repne scas byte ptr es:[edi]
00420356 f7d1 not ecx
00420358 8d51ff lea edx,[ecx-1]
0042035b b9ffffffff mov ecx,0FFFFFFFFh
00420360 89f7 mov edi,esi
00420362 f2ae repne scas byte ptr es:[edi]
00420364 f7d1 not ecx
00420366 49 dec ecx
00420367 7466 je git_remote_curl+0x203cf (004203cf)
00420369 85d2 test edx,edx
0042036b 0f84b1000000 je git_remote_curl+0x20422 (00420422)
00420371 89f7 mov edi,esi
00420373 89de mov esi,ebx
...
So its the first parameter that is NULL. The second parameter is:
0:000> da poi(ebp+c)
0046f98f "libexec/git-core"
I don't know how to build msysGit so that symbols are generated so
I've attempted to reconstruct the source code; which ends up looking
something like the following:
int some_unknown_func(char *arg1, char *arg2)
{
len1 = strlen(arg1) - 1; // <- crash here
len2 = strlen(arg2);
len3 = len2 - 1;
if (len2 != 1) {
if (!len1)
return 0;
for (;;) {
x = arg1[len1 - 1];
if (x != '/' && x != '\\') {
--len1;
--len3;
if (arg1[len1] != arg2[len3])
return 0;
} else {
...
}
}
}
}
Perhaps those more familiar with git's sources might recognise code
that looks similar to the above sequence.
^ permalink raw reply
* Re: [PATCH 2/3] git config: clarify bool types
From: Felipe Contreras @ 2009-10-13 10:02 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Junio C Hamano, git
In-Reply-To: <4AD427AD.3010701@drmicha.warpmail.net>
On Tue, Oct 13, 2009 at 10:09 AM, Michael J Gruber
<git@drmicha.warpmail.net> wrote:
> Felipe Contreras venit, vidit, dixit 12.10.2009 19:14:
>> On Mon, Oct 12, 2009 at 3:30 PM, Michael J Gruber
>> <git@drmicha.warpmail.net> wrote:
>>> Felipe Contreras venit, vidit, dixit 12.10.2009 12:03:
>>>> On Mon, Oct 12, 2009 at 8:01 AM, Junio C Hamano <gitster@pobox.com> wrote:
>>>>> Felipe Contreras <felipe.contreras@gmail.com> writes:
>>>>>
>>>>>> The value is what it is, the --bool and --bool-or-int options don't
>>>>>> specify the value type, just how it is interpreted. For example: a value
>>>>>> of '1' can be interpreted as 'true'.
>>>>>
>>>>> It is not really about "interpreting", but about showing, isn't it?
>>>>
>>>> Unless you are setting it, instead of reading it.
>>>>
>>>
>>> I'd still suggest fixing the typo ("interpreted") and spelling out
>>> "boolean".
>>
>> Oops! You mean s/intepreted/interpreted/?
>
> Yep :)
>
>>
>> If we spell 'boolean' we might as well spell 'integer'; I think bool
>> and int are fine.
>>
>
> "int" is at least a standard type name in C, whereas "bool" is not; but,
> yes, feel free to spell out "integer", or use "--int or --bool" as it
> is, which is a back reference to the corresponding entries for "--int"
> and "--bool", where things should be spelled out.
'bool' is also a standard type, in C99.
--
Felipe Contreras
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Johannes Sixt @ 2009-10-13 9:32 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Johannes Schindelin, Euguess, Mikael Magnusson,
Matthieu Moy, Jeff King, Jay Soffian, git
In-Reply-To: <7vljjf226t.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> #1. These used to detach, but will create a local branch
>
> $ git checkout origin/next ;# as if with -t
> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)
If I did 'git checkout origin/next' last week, I will already have a
branch next. What should happen if I do it again today?
I think that it should DWIM: If last week's next fast-fowards to this
week's origin/next (*and* next is the branch that tracks origin/next),
then the fast foward should happen. Otherwise 'git checkout origin/next'
should fail.
This way, if I built on last week's next, I will be notified; but if I
only want to browse history, then I won't be impeded by the existence of next.
-- Hannes
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-13 9:24 UTC (permalink / raw)
To: Thomas Rast
Cc: Johannes Schindelin, Euguess, Mikael Magnusson, Matthieu Moy,
Jeff King, Jay Soffian, git
In-Reply-To: <200910131051.47117.trast@student.ethz.ch>
Thomas Rast <trast@student.ethz.ch> writes:
>> #0. These will stay as is:
>>
>> $ git checkout mine ;# switches to the branch
>> $ git checkout $any_committish^0 ;# detaches
>>
>> #1. These used to detach, but will create a local branch
>>
>> $ git checkout origin/next ;# as if with -t
>> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)
>
> Agreed, though I'm still in favour of a cleaner syntax for explicit
> detaching. (Cleaner in the sense that ^0 is documented as having a
> completely different purpose and only works by accident.)
Oh, ^0 was just one way to make sure a committish is not a refname. If
you have an abbreviated hexadecimal commit object name, that would also
detach, which should fall into category #0. Sorry for the omission.
>> #2. These are allowed only when unambiguous and there is no local branch yet.
>>
>> $ git checkout next ;# ok
>> $ git checkout frotz ;# ok (origin is not special)
>> $ git checkout nitfol ;# not ok (ambiguous and origin is not special)
>
> I'm weakly leaning towards refusing all three, as the user should be
> required to explicitly say a remote branch should be involved.
>
> (Weakly because there's also a certain DWIM advantage to 'git checkout
> sometopic'...)
I thought this was the primary point of what Dscho has been advocating.
>> #3. These used to detach, but what should we do?
>>
>> $ git checkout v1.0.0 ;# detach, or refuse???
>
> Refuse, on the grounds that the main goal here is not detaching unless
> specifically told to. (Having a branch called v1.0.0 is worse, as it
> would just cause a lot of confusion and/or a refusal at the next
> checkout.)
>
>> $ git checkout origin/master ;# detach, or refuse???
>
> This seems to be the trickiest of them. Maybe check out 'master', to
> make the process repeatable. Imagine, in your setting,
>
> git checkout origin/next ;# creates 'next' as with -t
> git checkout - ;# back
> git checkout origin/next ;# should go to 'next' again
>
> Then again, that would trade the confusion of detaching for the
> confusion of not checking out the exact commit that the user
> specified. Worse, 'next' could conceivably be tracking (as per
> branch.next.merge) some entirely different branch, making the "Your
> branch is behind..." message misleading.
As I said already in the thread, I think that is a misguided attempt to
half-hide the fact that there are origin/next (tracking branch) and next
(a fork of it), that are two separate entities. It is misguided because
the user needs to understand and take advantage of the distinction to do
anything; in other words, it is not even an unnecessary complexity.
So I am very doubtful about the benefit of checking out 'master' when
the user explicitly tells us to check out 'origin/master', only because
the former forked from the latter.
> Some that come to mind:
>
> #3a. Other refs apart from tags that currently detach:
>
> git fetch origin master ;# or even sillier, 'git fetch . master'
> git checkout FETCH_HEAD ;# used to detach; refuse?
> #3b. Full specifiers that currently detach:
>
> git checkout refs/heads/master ;# could eventually attach
> git checkout heads/master ;# same
I'd throw both of these into category #3.
Anything that is valid "ref" (i.e. what dwim_ref() groks) that is not
a remote tracking branch (which creates a corresponding local branch)
can refuse to avoid unintended detachment by newbies.
> #0a. Should probably detach if the previous checkout was detached:
>
> git checkout - ;# detach if previous was detached?
> git checkout @{-1} ;# same
Perhaps.
So to recap, "git checkout $token" would:
* If dwim_ref() groks $token, and
- if it resolves to refs/heads/*, that is checking out a local branch;
- if it resolves to refs/remotes/*, and if there is no corresponding
local branch, create one forked from there, as if -t was given;
- everything else we used to detach, but we refuse in 1.7.0, to make it
harder for newbies to detach.
* If check_ref_format() is happy with $token, get_sha1() does not grok
$token, and there is only one ref of the form refs/remotes/$o/$token
then we pretend as if -t $o/$token was given and create a local branch
$token forked from it.
* Otherwise, we always detach.
Note that "checkout -" and "checkout @{-4}" are part of dwim_ref() family.
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Thomas Rast @ 2009-10-13 8:51 UTC (permalink / raw)
To: Junio C Hamano, Johannes Schindelin
Cc: Euguess, Mikael Magnusson, Matthieu Moy, Jeff King, Jay Soffian,
git
In-Reply-To: <7vljjf226t.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
>
> What it means is that -t was a broken attempt to help the users at the UI
> level, and I can surely see that.
>
> So we need the set of new rules, say, for 1.7.0 release. A strawman?
I feel somewhat uneasy commenting on this because I have a history of
writing just-barely-workable UIs. That being said:
> Assume that these are the only refs that exist:
>
> refs/remotes/origin/{master,next,nitfol}
> refs/remotes/xyzzy/{frotz,nitfol}
> refs/heads/master
> refs/tags/v1.0.0
>
> #0. These will stay as is:
>
> $ git checkout mine ;# switches to the branch
> $ git checkout $any_committish^0 ;# detaches
>
> #1. These used to detach, but will create a local branch
>
> $ git checkout origin/next ;# as if with -t
> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)
Agreed, though I'm still in favour of a cleaner syntax for explicit
detaching. (Cleaner in the sense that ^0 is documented as having a
completely different purpose and only works by accident.)
> #2. These are allowed only when unambiguous and there is no local branch yet.
>
> $ git checkout next ;# ok
> $ git checkout frotz ;# ok (origin is not special)
> $ git checkout nitfol ;# not ok (ambiguous and origin is not special)
I'm weakly leaning towards refusing all three, as the user should be
required to explicitly say a remote branch should be involved.
(Weakly because there's also a certain DWIM advantage to 'git checkout
sometopic'...)
> #3. These used to detach, but what should we do?
>
> $ git checkout v1.0.0 ;# detach, or refuse???
Refuse, on the grounds that the main goal here is not detaching unless
specifically told to. (Having a branch called v1.0.0 is worse, as it
would just cause a lot of confusion and/or a refusal at the next
checkout.)
> $ git checkout origin/master ;# detach, or refuse???
This seems to be the trickiest of them. Maybe check out 'master', to
make the process repeatable. Imagine, in your setting,
git checkout origin/next ;# creates 'next' as with -t
git checkout - ;# back
git checkout origin/next ;# should go to 'next' again
Then again, that would trade the confusion of detaching for the
confusion of not checking out the exact commit that the user
specified. Worse, 'next' could conceivably be tracking (as per
branch.next.merge) some entirely different branch, making the "Your
branch is behind..." message misleading.
> I can buy 0, 1, and 2, and I think it is a minor inconvenience if we
> started refusing to detach in case #3, as people who want to detach can
> always suffix ^0 or ~0 to make it a general committish.
>
> Did I cover all cases?
Some that come to mind:
#3a. Other refs apart from tags that currently detach:
git fetch origin master ;# or even sillier, 'git fetch . master'
git checkout FETCH_HEAD ;# used to detach; refuse?
#3b. Full specifiers that currently detach:
git checkout refs/heads/master ;# could eventually attach
git checkout heads/master ;# same
#0a. Should probably detach if the previous checkout was detached:
git checkout - ;# detach if previous was detached?
git checkout @{-1} ;# same
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* Re: [PATCH/RFC] builtin-checkout: suggest creating local branch when appropriate to do so
From: Junio C Hamano @ 2009-10-13 8:44 UTC (permalink / raw)
To: Junio C Hamano
Cc: Thomas Rast, Johannes Schindelin, Euguess, Mikael Magnusson,
Matthieu Moy, Jeff King, Jay Soffian, git
In-Reply-To: <7vljjf226t.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> So we need the set of new rules, say, for 1.7.0 release. A strawman?
>
> Assume that these are the only refs that exist:
>
> refs/remotes/origin/{master,next,nitfol}
> refs/remotes/xyzzy/{frotz,nitfol}
> refs/heads/master
Sorry, I had this as refs/heads/{master,mine} in my initial draft but
removed the 'mine' branch by mistake; the first item in #0 does not make
sense without it.
> refs/tags/v1.0.0
>
> #0. These will stay as is:
>
> $ git checkout mine ;# switches to the branch
> $ git checkout $any_committish^0 ;# detaches
>
> #1. These used to detach, but will create a local branch
>
> $ git checkout origin/next ;# as if with -t
> $ git checkout xyzzy/frotz ;# as if with -t (origin is not special)
>
> #2. These are allowed only when unambiguous and there is no local branch yet.
>
> $ git checkout next ;# ok
> $ git checkout frotz ;# ok (origin is not special)
> $ git checkout nitfol ;# not ok (ambiguous and origin is not special)
>
> #3. These used to detach, but what should we do?
>
> $ git checkout v1.0.0 ;# detach, or refuse???
> $ git checkout origin/master ;# detach, or refuse???
>
> I can buy 0, 1, and 2, and I think it is a minor inconvenience if we
> started refusing to detach in case #3, as people who want to detach can
> always suffix ^0 or ~0 to make it a general committish.
>
> Did I cover all cases?
^ permalink raw reply
* Re: [RFC PATCH v2 16/16] Smart HTTP fetch: gzip requests
From: Junio C Hamano @ 2009-10-13 8:38 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git, Daniel Barkalow
In-Reply-To: <1255400715-10508-17-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> diff --git a/remote-curl.c b/remote-curl.c
> index 31d1d34..d53215d 100644
> --- a/remote-curl.c
> +++ b/remote-curl.c
> @@ -261,11 +261,12 @@ static size_t rpc_in(const void *ptr, size_t eltsize,
> return size;
> }
>
> -static int post_rpc(struct rpc_state *state)
> +static int post_rpc(struct rpc_state *state, int use_gzip)
> {
> struct active_request_slot *slot;
> struct slot_results results;
> struct curl_slist *headers = NULL;
> + unsigned char *gzip_body = NULL;
> int err = 0, large_request = 0;
>
> /* Try to load the entire request, if we can fit it into the
> @@ -311,6 +313,48 @@ static int post_rpc(struct rpc_state *state)
> ...
> + curl_easy_setopt(slot->curl, CURLOPT_POSTFIELDS, gzip_body);
cc1: warnings being treated as errors
In function 'post_rpc',
inlined from 'one_shot_rpc_service' at remote-curl.c:433:
remote-curl.c:350: error: call to '_curl_easy_setopt_err_postfields' declared with attribute warning: curl_easy_setopt expects a void* or char* argument for this option
make: *** [remote-curl.o] Error 1
^ permalink raw reply
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Junio C Hamano @ 2009-10-13 8:33 UTC (permalink / raw)
To: Johannes Sixt; +Cc: Anders Kaseorg, git
In-Reply-To: <4AD43002.5080003@viscovery.net>
Johannes Sixt <j.sixt@viscovery.net> writes:
> Junio C Hamano schrieb:
>> Half of the time, the commit you test in your "git bisect" section would
>> be a "good" one, and immediately after you tell it "bisect good", it tells
>> you that some _other_ commit you marked "bad" is the first bad commit. In
>> such a case, you won't be on the commit that the bisect has found.
>
> Oh, yes, very true; but it is very close. But the commit that git bisect
> reset warps me to is perhaps 1000 steps in history away. I certainly do
> not want to go there, ever, because I want to go back near the bad commit
> right away. (Think of fewer files changed means less build time.) If git
> bisect reset would check out the bad commit, this would be *very* convenient.
I agree that "git bisect reset-and-detach-at-the-first-bad-one" would make
a lot of sense.
In my workflow, after I chased a bug in frotz, I often do
$ git name-rev $the_bad_one_that_was_found
to learn what was the first tagged release that has the bug, and create a
topic from there:
$ git checkout -b jc/maint-X.Y.Z-fix-frotz $the_bad_one_that_was_found
so that the fix I'd build on the commit can be merged initially to 'pu',
then 'next', then 'maint-X.Y.Z' and upwards to 'master', but all of that
is done after "git bisect reset" to switch back to the 'master' branch.
It is cumbersome to have to type (actually, I use the cut buffer in screen)
the commit object name of the first bad one twice.
It certainly sounds attractive if we can do:
$ git bisect reset-and-detach-at-the-first-bad-one
$ git name-rev HEAD
$ git checkout -b jc/maint-X.Y.Z-fix-frotz
$ hack hack hack
$ git commit
But at that point we are not talking about switching to arbitrary commit
anymore.
^ permalink raw reply
* Re: Questions about the new
From: Sergio Callegari @ 2009-10-13 7:49 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Johannes Sixt, git
In-Reply-To: <7v8wfge2zu.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Sergio Callegari <sergio.callegari@gmail.com> writes:
>
>
>> If I want to replace some commit X by some commit X' I merely need to
>> modify the
>> parent information of all the commits that are child of X so that they
>> pretend
>> to be child of X', or am I missing something?
>>
>
> You need to find all the commits that are child of X in the first place.
> What should happen if your colleague has such a commit in his repository
> (which you haven't fetched from yet), you enumerated all children of X
> known to you in your graft file and then you fetch from him? You need to
> enumerate all children of X again to keep the graft file up to date.
>
Ok, that is enlightening. When trying to sort out the differences,
advantages and disadvantages of
operating on arcs (grafts like) or on nodes (replacements like) I was
thinking local, rather than
distributed. Now the advantage of working on nodes is much clearer to me.
Thanks as usual for the very clear explanation.
Sergio
^ permalink raw reply
* Re: [PATCH] bisect reset: Allow resetting to any commit, not just a branch
From: Johannes Sixt @ 2009-10-13 7:45 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Anders Kaseorg, git
In-Reply-To: <7v3a5n3hgn.fsf@alter.siamese.dyndns.org>
Junio C Hamano schrieb:
> Half of the time, the commit you test in your "git bisect" section would
> be a "good" one, and immediately after you tell it "bisect good", it tells
> you that some _other_ commit you marked "bad" is the first bad commit. In
> such a case, you won't be on the commit that the bisect has found.
Oh, yes, very true; but it is very close. But the commit that git bisect
reset warps me to is perhaps 1000 steps in history away. I certainly do
not want to go there, ever, because I want to go back near the bad commit
right away. (Think of fewer files changed means less build time.) If git
bisect reset would check out the bad commit, this would be *very* convenient.
-- Hannes
^ permalink raw reply
* Bad URL passed to RA lay
From: m.skoric @ 2009-10-13 7:35 UTC (permalink / raw)
To: git
Hi List,
i have a problem with git-svn clone / fetch. I get following error while doing one of previous command -> "Bad URL passed to RA lay"
This happens because a branch doesn't exists in svn anymore and git wants to retrieve data from it. Here is the complete error message
Initializing parent: Abo-Uebernahme (Bug #994)@341
Found possible branch point: "quoted"..trunk => "quoted"...Abo-Uebernahme (Bug #994), 203
Found branch parent: (Abo-Uebernahme (Bug #994)@341) bb831869748c98bf97d105c5894ae65331c95c08
Bad URL passed to RA layer: Malformed URL for repository at /usr/bin/git-svn line 4311
git version 1.6.3.3
Aynone else has this Problem?
Can anyone help me?
Thanks in advance
Majk
______________________________________________________
GRATIS für alle WEB.DE-Nutzer: Die maxdome Movie-FLAT!
Jetzt freischalten unter http://movieflat.web.de
^ permalink raw reply
* [PATCH] gitk: Prevent garbage text at the end of the tag description
From: Björn Gustavsson @ 2009-10-13 7:34 UTC (permalink / raw)
To: Paul Mackerras, git
When first clicking on a commit with a huge diff (in 1000 files
or more), and then clicking on a tag, garbage text could appear
after the tag description.
The problem is that commits are shown incrementally using a
run queue (implemented by the runq() and filerun() procedures).
When the user requests a tag to be shown, there may still be
jobs in the run queue updating the previous commit.
Solve this problem by implementing a new procedure
empty_run_queue() that will empty the run queue and cancel all
outstanding file events. Call it from showtag().
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
This is more an annoyance than a real bug, but I was quite
surprised the first time I saw it happen and at first searched
for a bug in my own scripts that had created the tags.
This patch is a suggested correction.
Here is an example of a repository where the problem can be
reproduced quite easily:
git://github.com/mfoemmel/erlang-otp.git
gitk-git/gitk | 34 ++++++++++++++++++++++++++++++++--
1 files changed, 32 insertions(+), 2 deletions(-)
diff --git a/gitk-git/gitk b/gitk-git/gitk
index a0214b7..ee0d0c3 100644
--- a/gitk-git/gitk
+++ b/gitk-git/gitk
@@ -34,12 +34,16 @@ proc run args {
}
proc filerun {fd script} {
+ global pending_file_events
+
+ set pending_file_events($fd) $fd
fileevent $fd readable [list filereadable $fd $script]
}
proc filereadable {fd script} {
- global runq currunq
+ global runq currunq pending_file_events
+ unset pending_file_events($fd)
fileevent $fd readable {}
if {$runq eq {} && ![info exists currunq]} {
after idle dorunq
@@ -60,7 +64,7 @@ proc nukefile {fd} {
}
proc dorunq {} {
- global isonrunq runq currunq
+ global isonrunq runq currunq pending_file_events
set tstart [clock clicks -milliseconds]
set t0 $tstart
@@ -79,6 +83,7 @@ proc dorunq {} {
# file readers return 2 if they could do more straight away
lappend runq [list $fd $script]
} else {
+ set pending_file_events($fd) $fd
fileevent $fd readable [list filereadable $fd $script]
}
} elseif {$fd eq {}} {
@@ -92,6 +97,29 @@ proc dorunq {} {
}
}
+# Empty the run queue, cancel all outstanding file events,
+# and close all files associated with file events.
+proc empty_run_queue {} {
+ global isonrunq runq pending_file_events
+
+ foreach entry $runq {
+ set fd [lindex $entry 0]
+ set script [lindex $entry 1]
+ if {$fd eq {}} {
+ unset isonrunq($script)
+ } else {
+ catch {close $fd}
+ }
+ }
+ set runq {}
+
+ foreach fd [array names pending_file_events] {
+ fileevent $fd readable {}
+ unset pending_file_events($fd)
+ catch {close $fd}
+ }
+}
+
proc reg_instance {fd} {
global commfd leftover loginstance
@@ -10261,6 +10289,8 @@ proc listrefs {id} {
proc showtag {tag isnew} {
global ctext tagcontents tagids linknum tagobjid
+ empty_run_queue
+
if {$isnew} {
addtohistory [list showtag $tag 0]
}
--
1.6.5.2.gd6127
^ permalink raw reply related
* Re: [RFC PATCH v2 01/16] pkt-line: Add strbuf based functions
From: Johannes Sixt @ 2009-10-13 7:29 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1255400715-10508-2-git-send-email-spearce@spearce.org>
Shawn O. Pearce schrieb:
> -int packet_read_line(int fd, char *buffer, unsigned size)
> +static int packet_length(unsigned *ret_len, const char *linelen)
> {
> int n;
> - unsigned len;
> - char linelen[4];
> -
> - safe_read(fd, linelen, 4);
> + unsigned len = 0;
>
> - len = 0;
> for (n = 0; n < 4; n++) {
> unsigned char c = linelen[n];
> len <<= 4;
> @@ -96,8 +116,20 @@ int packet_read_line(int fd, char *buffer, unsigned size)
> len += c - 'A' + 10;
> continue;
> }
> - die("protocol error: bad line length character");
> + return -1;
> }
> + *ret_len = len;
> + return 0;
> +}
len can be signed: Valid lengths fit into a signed int. Then you can
'return len;' on success and 'return -1;' on failure and don't need return
the result by reference. packet_read_line() ultimately converts it to int
anyway:
> +int packet_read_line(int fd, char *buffer, unsigned size)
> +{
> + unsigned len;
> + char linelen[4];
> +
> + safe_read(fd, linelen, 4);
> + if (packet_length(&len, linelen))
> + die("protocol error: bad line length character");
> if (!len)
> return 0;
> len -= 4;
> @@ -107,3 +139,28 @@ int packet_read_line(int fd, char *buffer, unsigned size)
> buffer[len] = 0;
> return len;
> }
-- Hannes
^ 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