* [REROLL PATCH v2 7/8] Support remote archive from all smart transports
From: Ilari Liusvaara @ 2009-12-09 15:26 UTC (permalink / raw)
To: git
In-Reply-To: <1260372394-16427-1-git-send-email-ilari.liusvaara@elisanet.fi>
Previously, remote archive required internal (non remote-helper)
smart transport. Extend the remote archive to also support smart
transports implemented by remote helpers.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
builtin-archive.c | 17 ++++++++++-------
transport-helper.c | 19 +++++++++++++++++++
transport.c | 21 +++++++++++++++++++++
transport.h | 5 +++++
4 files changed, 55 insertions(+), 7 deletions(-)
diff --git a/builtin-archive.c b/builtin-archive.c
index 12351e9..d34b3fd 100644
--- a/builtin-archive.c
+++ b/builtin-archive.c
@@ -5,6 +5,7 @@
#include "cache.h"
#include "builtin.h"
#include "archive.h"
+#include "transport.h"
#include "parse-options.h"
#include "pkt-line.h"
#include "sideband.h"
@@ -25,12 +26,16 @@ static void create_output_file(const char *output_file)
static int run_remote_archiver(int argc, const char **argv,
const char *remote, const char *exec)
{
- char *url, buf[LARGE_PACKET_MAX];
+ char buf[LARGE_PACKET_MAX];
int fd[2], i, len, rv;
- struct child_process *conn;
+ struct transport *transport;
+ struct remote *_remote;
- url = xstrdup(remote);
- conn = git_connect(fd, url, exec, 0);
+ _remote = remote_get(remote);
+ if (!_remote->url[0])
+ die("git archive: Remote with no URL");
+ transport = transport_get(_remote, _remote->url[0]);
+ transport_connect(transport, "git-upload-archive", exec, fd);
for (i = 1; i < argc; i++)
packet_write(fd[1], "argument %s\n", argv[i]);
@@ -53,9 +58,7 @@ static int run_remote_archiver(int argc, const char **argv,
/* Now, start reading from fd[0] and spit it out to stdout */
rv = recv_sideband("archive", fd[0], 1);
- close(fd[0]);
- close(fd[1]);
- rv |= finish_connect(conn);
+ rv |= transport_disconnect(transport);
return !!rv;
}
diff --git a/transport-helper.c b/transport-helper.c
index 216af87..2ce4ef5 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -469,6 +469,24 @@ static int process_connect(struct transport *transport,
return process_connect_service(transport, name, exec);
}
+static int connect_helper(struct transport *transport, const char *name,
+ const char *exec, int fd[2])
+{
+ struct helper_data *data = transport->data;
+
+ /* Get_helper so connect is inited. */
+ get_helper(transport);
+ if (!data->connect)
+ die("Operation not supported by protocol.");
+
+ if (!process_connect_service(transport, name, exec))
+ die("Can't connect to subservice %s.", name);
+
+ fd[0] = data->helper->out;
+ fd[1] = data->helper->in;
+ return 0;
+}
+
static int fetch(struct transport *transport,
int nr_heads, struct ref **to_fetch)
{
@@ -713,6 +731,7 @@ int transport_helper_init(struct transport *transport, const char *name)
transport->fetch = fetch;
transport->push_refs = push_refs;
transport->disconnect = release_helper;
+ transport->connect = connect_helper;
transport->smart_options = &(data->transport_options);
return 0;
}
diff --git a/transport.c b/transport.c
index ad25b98..a7d67eb 100644
--- a/transport.c
+++ b/transport.c
@@ -756,6 +756,17 @@ static int git_transport_push(struct transport *transport, struct ref *remote_re
return ret;
}
+static int connect_git(struct transport *transport, const char *name,
+ const char *executable, int fd[2])
+{
+ struct git_transport_data *data = transport->data;
+ data->conn = git_connect(data->fd, transport->url,
+ executable, 0);
+ fd[0] = data->fd[0];
+ fd[1] = data->fd[1];
+ return 0;
+}
+
static int disconnect_git(struct transport *transport)
{
struct git_transport_data *data = transport->data;
@@ -901,6 +912,7 @@ struct transport *transport_get(struct remote *remote, const char *url)
ret->get_refs_list = get_refs_via_connect;
ret->fetch = fetch_refs_via_pack;
ret->push_refs = git_transport_push;
+ ret->connect = connect_git;
ret->disconnect = disconnect_git;
ret->smart_options = &(data->options);
@@ -1061,6 +1073,15 @@ void transport_unlock_pack(struct transport *transport)
}
}
+int transport_connect(struct transport *transport, const char *name,
+ const char *exec, int fd[2])
+{
+ if (transport->connect)
+ return transport->connect(transport, name, exec, fd);
+ else
+ die("Operation not supported by protocol");
+}
+
int transport_disconnect(struct transport *transport)
{
int ret = 0;
diff --git a/transport.h b/transport.h
index 781db2e..97ba251 100644
--- a/transport.h
+++ b/transport.h
@@ -64,6 +64,8 @@ struct transport {
**/
int (*push_refs)(struct transport *transport, struct ref *refs, int flags);
int (*push)(struct transport *connection, int refspec_nr, const char **refspec, int flags);
+ int (*connect)(struct transport *connection, const char *name,
+ const char *executable, int fd[2]);
/** get_refs_list(), fetch(), and push_refs() can keep
* resources (such as a connection) reserved for futher
@@ -133,6 +135,9 @@ char *transport_anonymize_url(const char *url);
void transport_take_over(struct transport *transport,
struct child_process *child);
+int transport_connect(struct transport *transport, const char *name,
+ const char *exec, int fd[2]);
+
/* Transport methods defined outside transport.c */
int transport_helper_init(struct transport *transport, const char *name);
--
1.6.6.rc1.300.gfbc27
^ permalink raw reply related
* [REROLL PATCH v2 2/8] Support mandatory capabilities
From: Ilari Liusvaara @ 2009-12-09 15:26 UTC (permalink / raw)
To: git
In-Reply-To: <1260372394-16427-1-git-send-email-ilari.liusvaara@elisanet.fi>
Add support for marking capability as mandatory for hosting git version
to understand. This is useful for helpers which require various types
of assistance from main git binary.
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
Documentation/git-remote-helpers.txt | 5 ++++-
transport-helper.c | 25 +++++++++++++++++++------
2 files changed, 23 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 5cfdc0c..20a05fe 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -25,7 +25,10 @@ Commands are given by the caller on the helper's standard input, one per line.
'capabilities'::
Lists the capabilities of the helper, one per line, ending
- with a blank line.
+ with a blank line. Each capability may be preceeded with '*'.
+ This marks them mandatory for git version using the remote
+ helper to understand (unknown mandatory capability is fatal
+ error).
'list'::
Lists the refs, one per line, in the format "<value> <name>
diff --git a/transport-helper.c b/transport-helper.c
index a721dc2..4b17aaa 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -93,25 +93,38 @@ static struct child_process *get_helper(struct transport *transport)
data->out = xfdopen(helper->out, "r");
while (1) {
+ const char *capname;
+ int mandatory = 0;
recvline(data, &buf);
if (!*buf.buf)
break;
+
+ if (*buf.buf == '*') {
+ capname = buf.buf + 1;
+ mandatory = 1;
+ } else
+ capname = buf.buf;
+
if (debug)
- fprintf(stderr, "Debug: Got cap %s\n", buf.buf);
- if (!strcmp(buf.buf, "fetch"))
+ fprintf(stderr, "Debug: Got cap %s\n", capname);
+ if (!strcmp(capname, "fetch"))
data->fetch = 1;
- if (!strcmp(buf.buf, "option"))
+ else if (!strcmp(capname, "option"))
data->option = 1;
- if (!strcmp(buf.buf, "push"))
+ else if (!strcmp(capname, "push"))
data->push = 1;
- if (!strcmp(buf.buf, "import"))
+ else if (!strcmp(capname, "import"))
data->import = 1;
- if (!data->refspecs && !prefixcmp(buf.buf, "refspec ")) {
+ else if (!data->refspecs && !prefixcmp(capname, "refspec ")) {
ALLOC_GROW(refspecs,
refspec_nr + 1,
refspec_alloc);
refspecs[refspec_nr++] = strdup(buf.buf + strlen("refspec "));
+ } else if (mandatory) {
+ die("Unknown madatory capability %s. This remote "
+ "helper probably needs newer version of Git.\n",
+ capname);
}
}
if (refspecs) {
--
1.6.6.rc1.300.gfbc27
^ permalink raw reply related
* [REROLL PATCH v2 8/8] Remove special casing of http, https and ftp
From: Ilari Liusvaara @ 2009-12-09 15:26 UTC (permalink / raw)
To: git
In-Reply-To: <1260372394-16427-1-git-send-email-ilari.liusvaara@elisanet.fi>
HTTP, HTTPS and FTP are no longer special to transport code. Also
add support for FTPS (curl supports it so it is easy).
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
.gitignore | 4 ++++
Makefile | 27 +++++++++++++++++++++++++--
transport.c | 8 --------
3 files changed, 29 insertions(+), 10 deletions(-)
diff --git a/.gitignore b/.gitignore
index ac02a58..aa7a8ac 100644
--- a/.gitignore
+++ b/.gitignore
@@ -107,6 +107,10 @@
/git-relink
/git-remote
/git-remote-curl
+/git-remote-http
+/git-remote-https
+/git-remote-ftp
+/git-remote-ftps
/git-repack
/git-replace
/git-repo-config
diff --git a/Makefile b/Makefile
index 2ad7e36..87fc7ff 100644
--- a/Makefile
+++ b/Makefile
@@ -424,6 +424,16 @@ BUILT_INS += git-stage$X
BUILT_INS += git-status$X
BUILT_INS += git-whatchanged$X
+ifdef NO_CURL
+REMOTE_CURL_PRIMARY =
+REMOTE_CURL_ALIASES =
+REMOTE_CURL_NAMES =
+else
+REMOTE_CURL_PRIMARY = git-remote-http$X
+REMOTE_CURL_ALIASES = git-remote-https$X git-remote-ftp$X git-remote-ftps$X
+REMOTE_CURL_NAMES = $(REMOTE_CURL_PRIMARY) $(REMOTE_CURL_ALIASES)
+endif
+
# what 'all' will build and 'install' will install in gitexecdir,
# excluding programs for built-in commands
ALL_PROGRAMS = $(PROGRAMS) $(SCRIPTS)
@@ -1097,7 +1107,7 @@ else
else
CURL_LIBCURL = -lcurl
endif
- PROGRAMS += git-remote-curl$X git-http-fetch$X
+ PROGRAMS += $(REMOTE_CURL_NAMES) git-http-fetch$X
curl_check := $(shell (echo 070908; curl-config --vernum) | sort -r | sed -ne 2p)
ifeq "$(curl_check)" "070908"
ifndef NO_EXPAT
@@ -1676,7 +1686,13 @@ git-http-push$X: revision.o http.o http-push.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
-git-remote-curl$X: remote-curl.o http.o http-walker.o $(GITLIBS)
+$(REMOTE_CURL_ALIASES): $(REMOTE_CURL_PRIMARY)
+ $(QUIET_LNCP)$(RM) $@ && \
+ ln $< $@ 2>/dev/null || \
+ ln -s $< $@ 2>/dev/null || \
+ cp $< $@
+
+$(REMOTE_CURL_PRIMARY): remote-curl.o http.o http-walker.o $(GITLIBS)
$(QUIET_LINK)$(CC) $(ALL_CFLAGS) -o $@ $(ALL_LDFLAGS) $(filter %.o,$^) \
$(LIBS) $(CURL_LIBCURL) $(EXPAT_LIBEXPAT)
@@ -1852,6 +1868,7 @@ endif
ifneq (,$X)
$(foreach p,$(patsubst %$X,%,$(filter %$X,$(ALL_PROGRAMS) $(BUILT_INS) git$X)), test '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p' -ef '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p$X' || $(RM) '$(DESTDIR_SQ)$(gitexec_instdir_SQ)/$p';)
endif
+
bindir=$$(cd '$(DESTDIR_SQ)$(bindir_SQ)' && pwd) && \
execdir=$$(cd '$(DESTDIR_SQ)$(gitexec_instdir_SQ)' && pwd) && \
{ test "$$bindir/" = "$$execdir/" || \
@@ -1865,6 +1882,12 @@ endif
ln -s "git$X" "$$execdir/$$p" 2>/dev/null || \
cp "$$execdir/git$X" "$$execdir/$$p" || exit; \
done; } && \
+ { for p in $(REMOTE_CURL_ALIASES); do \
+ $(RM) "$$execdir/$$p" && \
+ ln "$$execdir/git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
+ ln -s "git-remote-http$X" "$$execdir/$$p" 2>/dev/null || \
+ cp "$$execdir/git-remote-http$X" "$$execdir/$$p" || exit; \
+ done; } && \
./check_bindir "z$$bindir" "z$$execdir" "$$bindir/git-add$X"
install-doc:
diff --git a/transport.c b/transport.c
index a7d67eb..652bf0b 100644
--- a/transport.c
+++ b/transport.c
@@ -918,14 +918,6 @@ struct transport *transport_get(struct remote *remote, const char *url)
data->conn = NULL;
data->got_remote_heads = 0;
- } else if (!prefixcmp(url, "http://")
- || !prefixcmp(url, "https://")
- || !prefixcmp(url, "ftp://")) {
- /* These three are just plain special. */
- transport_helper_init(ret, "curl");
-#ifdef NO_CURL
- error("git was compiled without libcurl support.");
-#endif
} else {
/* Unknown protocol in URL. Pass to external handler. */
int len = external_specification_len(url);
--
1.6.6.rc1.300.gfbc27
^ permalink raw reply related
* [REROLL PATCH v2 6/8] Support remote helpers implementing smart transports
From: Ilari Liusvaara @ 2009-12-09 15:26 UTC (permalink / raw)
To: git
In-Reply-To: <1260372394-16427-1-git-send-email-ilari.liusvaara@elisanet.fi>
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Ilari Liusvaara <ilari.liusvaara@elisanet.fi>
---
Documentation/git-remote-helpers.txt | 25 +++++++-
transport-helper.c | 126 ++++++++++++++++++++++++++++++++--
2 files changed, 144 insertions(+), 7 deletions(-)
diff --git a/Documentation/git-remote-helpers.txt b/Documentation/git-remote-helpers.txt
index 20a05fe..4685a89 100644
--- a/Documentation/git-remote-helpers.txt
+++ b/Documentation/git-remote-helpers.txt
@@ -93,6 +93,20 @@ Supported if the helper has the "push" capability.
+
Supported if the helper has the "import" capability.
+'connect' <service>::
+ Connects to given service. Standard input and standard output
+ of helper are connected to specified service (git prefix is
+ included in service name so e.g. fetching uses 'git-upload-pack'
+ as service) on remote side. Valid replies to this command are
+ empty line (connection established), 'fallback' (no smart
+ transport support, fall back to dumb transports) and just
+ exiting with error message printed (can't connect, don't
+ bother trying to fall back). After line feed terminating the
+ positive (empty) response, the output of service starts. After
+ the connection ends, the remote helper exits.
++
+Supported if the helper has the "connect" capability.
+
If a fatal error occurs, the program writes the error message to
stderr and exits. The caller should expect that a suitable error
message has been printed if the child closes the connection without
@@ -126,6 +140,9 @@ CAPABILITIES
all, it must cover all refs reported by the list command; if
it is not used, it is effectively "*:*"
+'connect'::
+ This helper supports the 'connect' command.
+
REF LIST ATTRIBUTES
-------------------
@@ -168,9 +185,15 @@ OPTIONS
but don't actually change any repository data. For most
helpers this only applies to the 'push', if supported.
+'option servpath <c-style-quoted-path>'::
+ Set service path (--upload-pack, --receive-pack etc.) for
+ next connect. Remote helper MAY support this option. Remote
+ helper MUST NOT rely on this option being set before
+ connect request occurs.
+
Documentation
-------------
-Documentation by Daniel Barkalow.
+Documentation by Daniel Barkalow and Ilari Liusvaara
GIT
---
diff --git a/transport-helper.c b/transport-helper.c
index 97eed6c..216af87 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -18,7 +18,9 @@ struct helper_data
unsigned fetch : 1,
import : 1,
option : 1,
- push : 1;
+ push : 1,
+ connect : 1,
+ no_disconnect_req : 1;
/* These go from remote name (as in "list") to private name */
struct refspec *refspecs;
int refspec_nr;
@@ -37,12 +39,12 @@ static void sendline(struct helper_data *helper, struct strbuf *buffer)
die_errno("Full write to remote helper failed");
}
-static int recvline(struct helper_data *helper, struct strbuf *buffer)
+static int recvline_fh(FILE *helper, struct strbuf *buffer)
{
strbuf_reset(buffer);
if (debug)
fprintf(stderr, "Debug: Remote helper: Waiting...\n");
- if (strbuf_getline(buffer, helper->out, '\n') == EOF) {
+ if (strbuf_getline(buffer, helper, '\n') == EOF) {
if (debug)
fprintf(stderr, "Debug: Remote helper quit.\n");
exit(128);
@@ -53,6 +55,11 @@ static int recvline(struct helper_data *helper, struct strbuf *buffer)
return 0;
}
+static int recvline(struct helper_data *helper, struct strbuf *buffer)
+{
+ return recvline_fh(helper->out, buffer);
+}
+
static void xchgline(struct helper_data *helper, struct strbuf *buffer)
{
sendline(helper, buffer);
@@ -77,6 +84,15 @@ const char *remove_ext_force(const char *url)
return url;
}
+static void do_take_over(struct transport *transport)
+{
+ struct helper_data *data;
+ data = (struct helper_data*)transport->data;
+ transport_take_over(transport, data->helper);
+ fclose(data->out);
+ free(data);
+}
+
static struct child_process *get_helper(struct transport *transport)
{
struct helper_data *data = transport->data;
@@ -103,12 +119,12 @@ static struct child_process *get_helper(struct transport *transport)
if (start_command(helper))
die("Unable to run helper: git %s", helper->argv[0]);
data->helper = helper;
+ data->no_disconnect_req = 0;
/*
* Open the output as FILE* so strbuf_getline() can be used.
* Do this with duped fd because fclose() will close the fd,
* and stuff like taking over will require the fd to remain.
- *
*/
duped = dup(helper->out);
if (duped < 0)
@@ -146,6 +162,8 @@ static struct child_process *get_helper(struct transport *transport)
refspec_nr + 1,
refspec_alloc);
refspecs[refspec_nr++] = strdup(buf.buf + strlen("refspec "));
+ } else if (!strcmp(capname, "connect")) {
+ data->connect = 1;
} else if (mandatory) {
die("Unknown madatory capability %s. This remote "
"helper probably needs newer version of Git.\n",
@@ -175,8 +193,10 @@ static int disconnect_helper(struct transport *transport)
if (data->helper) {
if (debug)
fprintf(stderr, "Debug: Disconnecting.\n");
- strbuf_addf(&buf, "\n");
- sendline(data, &buf);
+ if(!data->no_disconnect_req) {
+ strbuf_addf(&buf, "\n");
+ sendline(data, &buf);
+ }
close(data->helper->in);
close(data->helper->out);
fclose(data->out);
@@ -370,12 +390,96 @@ static int fetch_with_import(struct transport *transport,
return 0;
}
+static int process_connect_service(struct transport *transport,
+ const char *name, const char *exec)
+{
+ struct helper_data *data = transport->data;
+ struct strbuf cmdbuf = STRBUF_INIT;
+ struct child_process *helper;
+ int r, duped, ret = 0;
+ FILE *input;
+
+ helper = get_helper(transport);
+
+ /*
+ * Yes, dup the pipe another time, as we need unbuffered version
+ * of input pipe as FILE*. fclose() closes the underlying fd and
+ * stream buffering only can be changed before first I/O operation
+ * on it.
+ */
+ duped = dup(helper->out);
+ if (duped < 0)
+ die_errno("Can't dup helper output fd");
+ input = xfdopen(duped, "r");
+ setvbuf(input, NULL, _IONBF, 0);
+
+ /*
+ * Handle --upload-pack and friends. This is fire and forget...
+ * just warn if it fails.
+ */
+ if (strcmp(name, exec)) {
+ r = set_helper_option(transport, "servpath", exec);
+ if (r > 0)
+ fprintf(stderr, "Warning: Setting remote service path "
+ "not supported by protocol.\n");
+ else if (r < 0)
+ fprintf(stderr, "Warning: Invalid remote service "
+ "path.\n");
+ }
+
+ if (data->connect)
+ strbuf_addf(&cmdbuf, "connect %s\n", name);
+ else
+ goto exit;
+
+ sendline(data, &cmdbuf);
+ recvline_fh(input, &cmdbuf);
+ if (!strcmp(cmdbuf.buf, "")) {
+ data->no_disconnect_req = 1;
+ if (debug)
+ fprintf(stderr, "Debug: Smart transport connection "
+ "ready.\n");
+ ret = 1;
+ } else if (!strcmp(cmdbuf.buf, "fallback")) {
+ if (debug)
+ fprintf(stderr, "Debug: Falling back to dumb "
+ "transport.\n");
+ } else
+ die("Unknown response to connect: %s",
+ cmdbuf.buf);
+
+exit:
+ fclose(input);
+ return ret;
+}
+
+static int process_connect(struct transport *transport,
+ int for_push)
+{
+ struct helper_data *data = transport->data;
+ const char *name;
+ const char *exec;
+
+ name = for_push ? "git-receive-pack" : "git-upload-pack";
+ if (for_push)
+ exec = data->transport_options.receivepack;
+ else
+ exec = data->transport_options.uploadpack;
+
+ return process_connect_service(transport, name, exec);
+}
+
static int fetch(struct transport *transport,
int nr_heads, struct ref **to_fetch)
{
struct helper_data *data = transport->data;
int i, count;
+ if (process_connect(transport, 0)) {
+ do_take_over(transport);
+ return transport->fetch(transport, nr_heads, to_fetch);
+ }
+
count = 0;
for (i = 0; i < nr_heads; i++)
if (!(to_fetch[i]->status & REF_STATUS_UPTODATE))
@@ -403,6 +507,11 @@ static int push_refs(struct transport *transport,
struct child_process *helper;
struct ref *ref;
+ if (process_connect(transport, 1)) {
+ do_take_over(transport);
+ return transport->push_refs(transport, remote_refs, flags);
+ }
+
if (!remote_refs)
return 0;
@@ -543,6 +652,11 @@ static struct ref *get_refs_list(struct transport *transport, int for_push)
helper = get_helper(transport);
+ if (process_connect(transport, for_push)) {
+ do_take_over(transport);
+ return transport->get_refs_list(transport, for_push);
+ }
+
if (data->push && for_push)
write_str_in_full(helper->in, "list for-push\n");
else
--
1.6.6.rc1.300.gfbc27
^ permalink raw reply related
* cannot pread pack file
From: Steven A. Falco @ 2009-12-09 16:25 UTC (permalink / raw)
To: git
We have been using git for a year or two now, and suddenly, one
of our users got the error message:
fatal: cannot pread pack file: No such file or directory
fatal: index-pack failed
while doing a git-pull. We are using git version git-1.6.5.5.
I tried doing a "git fsck --full" on his repository and on the
one he is trying to pull from, and neither shows any error.
If I clone his repository, the clone also gets the error message
when trying to pull.
I can pull from him, but if he pulls from me, he gets the error
message.
This is worrying, because the fsck doesn't show an error, but
clearly something is wrong.
Is there anything further I can try to determine why his repo
is unable to pull?
Thanks,
Steve
--
A: Because it makes the logic of the discussion difficult to follow.
Q: Why shouldn't I top post?
A: No.
Q: Should I top post?
^ permalink raw reply
* Re: cannot pread pack file
From: Nicolas Pitre @ 2009-12-09 17:43 UTC (permalink / raw)
To: Steven A. Falco; +Cc: git
In-Reply-To: <4B1FCF81.2010807@harris.com>
On Wed, 9 Dec 2009, Steven A. Falco wrote:
> We have been using git for a year or two now, and suddenly, one
> of our users got the error message:
>
> fatal: cannot pread pack file: No such file or directory
> fatal: index-pack failed
>
> while doing a git-pull. We are using git version git-1.6.5.5.
>
> I tried doing a "git fsck --full" on his repository and on the
> one he is trying to pull from, and neither shows any error.
>
> If I clone his repository, the clone also gets the error message
> when trying to pull.
>
> I can pull from him, but if he pulls from me, he gets the error
> message.
>
> This is worrying, because the fsck doesn't show an error, but
> clearly something is wrong.
A few questions:
- What is the OS on which the failing Git is running?
- How long before the error occurs i.e. how many objects are received
(and the transfer size) before the error?
Nicolas
^ permalink raw reply
* Delete particular file contents from complete history
From: Patrick Grimard @ 2009-12-09 18:01 UTC (permalink / raw)
To: git
Is there some way to remove from the entire history a particular
file's content? So for example I did an initial commit which
contained a file I didn't want in the commit and since then I've
committed further changes to the project, even started a branch to
experiment with some additional features. I don't want to lose any of
my new commits or branch, just want to remove a particular file's
content from the entire history.
Thanks.
^ permalink raw reply
* git init respecting GIT_WORK_DIR
From: Tony Risinger @ 2009-12-09 18:37 UTC (permalink / raw)
To: git, Tony Risinger
should this be expected behavior?
-----DOC
core.bare
(snipped)
This setting is automatically guessed by git-clone(1) or
git-init(1) when the repository was created. By default a repository
that ends in "/.git" is assumed to be not bare (bare = false),
while all other repositories are assumed to be bare (bare = true).
-----PROBLEM
[cr@extOFme-d0 ~]$ export GIT_DIR=gitdir.git GIT_WORK_DIR=workdir.work
[cr@extOFme-d0 ~]$ git init
Initialized empty Git repository in /home/cr/gitdir.git/
[cr@extOFme-d0 ~]$ git config core.bare
true
[cr@extOFme-d0 ~]$ git config core.worktree
[cr@extOFme-d0 ~]$
-----SUMMARY
i think git should not be so restrictive in what it considers to be a
bare repository. when you use --work-tree:
[cr@extOFme-d0 ~]$ export GIT_DIR=gitdir.git GIT_WORK_DIR=workdir.work
[cr@extOFme-d0 ~]$ git --work-tree="$GIT_WORK_DIR" init
Initialized empty Git repository in /home/cr/gitdir.git/
[cr@extOFme-d0 ~]$ git config core.bare
false
[cr@extOFme-d0 ~]$ git config core.worktree
/home/cr/workdir.work
everything works as expected. "git init" should respect GIT_WORK_DIR
env variable and set core.bare and core.worktree appropriately.
^ permalink raw reply
* Re: cannot pread pack file
From: Steven A. Falco @ 2009-12-09 18:53 UTC (permalink / raw)
To: Nicolas Pitre; +Cc: git
In-Reply-To: <alpine.LFD.2.00.0912091237330.31174@xanadu.home>
Nicolas Pitre wrote:
> On Wed, 9 Dec 2009, Steven A. Falco wrote:
>
>> We have been using git for a year or two now, and suddenly, one
>> of our users got the error message:
>>
>> fatal: cannot pread pack file: No such file or directory
>> fatal: index-pack failed
>>
>> while doing a git-pull. We are using git version git-1.6.5.5.
>>
>> I tried doing a "git fsck --full" on his repository and on the
>> one he is trying to pull from, and neither shows any error.
>>
>> If I clone his repository, the clone also gets the error message
>> when trying to pull.
>>
>> I can pull from him, but if he pulls from me, he gets the error
>> message.
>>
>> This is worrying, because the fsck doesn't show an error, but
>> clearly something is wrong.
>
> A few questions:
>
> - What is the OS on which the failing Git is running?
>
I am running on Centos 5.2. I believe I've fixed the problem.
I thought we were running 1.6.5.5, but apparently our libexec was
pointing to an older version. Once I corrected that, the error
went away.
Our repositories are hosted on an NFS file server, and the repo
that had the problem has some large binary fpga images in it.
Looking on the net, it seems that there was a problem with pread
returning part of a file. I see that the new code does the pread
in a loop to work around this. So I'm guessing that the old version
we were running didn't have the pread workaround and was therefore
failing. Anyway, it is behaving now.
Thanks very much for replying,
Steve
> - How long before the error occurs i.e. how many objects are received
> (and the transfer size) before the error?
>
>
> Nicolas
>
--
A: Because it makes the logic of the discussion difficult to follow.
Q: Why shouldn't I top post?
A: No.
Q: Should I top post?
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Junio C Hamano @ 2009-12-09 19:46 UTC (permalink / raw)
To: Björn Steinbrink
Cc: Michael S. Tsirkin, Andreas Schwab, Peter Krefting,
Git Mailing List
In-Reply-To: <20091209130653.GA30218@atjola.homenet>
Björn Steinbrink <B.Steinbrink@gmx.de> writes:
> "merge --squash" is one of the things I really dislike, because it turns
> off the "history" part of the merge. You can say "Merging in git is about
> histories, merging in svn is about changes only" to describe the major
> difference for the merge commands in the two systems... "But then
> there's --squash which turns git into svn".
I agree with this to some degree, but I do not offhand think of a better
alternative.
At the first sight, it looks as if what "merge --squash" does was
implemented as a new option "--squash" to the "merge" command merely
because the way _how_ it internally needs to compute the result was
already available in the implementation of "merge" command, and not
necessarily because _what_ it does was conceptually consistent with the
way "merge" works.
But at the conceptual level, "merge --squash" is a short-hand for this
command sequence:
git rebase -i HEAD that-branch
... make everything except the first one into "squash"
git checkout - ;# come back to the original branch
git merge that-branch ;# fast forward to it
So after all, it is "merge it after squashing them".
^ permalink raw reply
* Re: Git documentation consistency
From: Greg A. Woods @ 2009-12-09 19:56 UTC (permalink / raw)
To: The Git Mailing List
In-Reply-To: <e51f66da0912030822ye1541b4gb1b8a3e07eb72484@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2174 bytes --]
At Thu, 3 Dec 2009 18:22:27 +0200, Marko Kreen <markokr@gmail.com> wrote:
Subject: Re: Git documentation consistency
>
> On 12/3/09, Greg A. Woods <woods@planix.com> wrote:
> > At Wed, 02 Dec 2009 17:34:01 -0800, Junio C Hamano <gitster@pobox.com> wrote:
> > Subject: Re: Git documentation consistency
> > > I think you are showing ignorance here, as -? is *not* even close to
> > > standard, nor even widely used practice at all.
> >
> > I think I should know something about Unix command line and option
> > parsers, having used them for some 25 years or so now. In fact I've
> > used most every kind of unix that ever was, and I've worked on the
> > source to more than a few.
>
> '?' is what getopt(3) is supposed to return for unknown options.
Indeed, which is why it cannot ever, in general, be used as a valid
option with some command-specific meaning, and so why the one-line form
of the usage message should always be displayed when the user explicitly
gives a '-?' option (i.e. in the same way as if any unknown option is
given).
If the one-line usage message is too terse to explain more complex
command line syntax then '-h' (and --help) should display a short
multi-line summary of the command's usage.
I guess what I should have suggested in the first place is that all Git
sub-commands should respond with a one-line[*] usage message when they
encounter an unknown option, such as '-?', and that they should (only)
display a more detailed multi-line help summary when given '-h' or
'--help' options.
I was most surprised when I didn't get a one-line usage summary from
"git log -?", just getopt(3)'s error message.
[*] commands which have multiple distinct modes of operation with
separate and unique command-line syntax for each mode, should of course
display a one-line summary for each command mode, such as in this
example:
void
usage(void)
{
fprintf(stderr, "Usage: %s [-abcdef]\n", getprogname());
fprintf(stderr, " %s [-l]\n", getprogname());
exit(2);
}
--
Greg A. Woods
Planix, Inc.
<woods@planix.com> +1 416 218 0099 http://www.planix.com/
[-- Attachment #2: Type: application/pgp-signature, Size: 186 bytes --]
^ permalink raw reply
* Help: approach for rebasing to older commits after merging more recent commits
From: Jay Soffian @ 2009-12-09 20:04 UTC (permalink / raw)
To: git
I have an interesting problem I'm not sure how best to tackle.
A small development team is basing its product on an upstream git repo that is
itself an svn clone. Currently the process looks like this:
r1--r2--r3--r4--r5 upstream trunk (git svn clone)
\ \ \
A---B---C---D---E local trunk (git clone of upstream)
\ /
F---G developerN trunk (git clones of local)
So local trunk has both daily merges from the local developers, as well as
less periodic (typically weekly) merges from upstream trunk. The reason being
that it is necessary to remain on top of the upstream bleeding edge.
This works out okay, but there is a minor problem and a major problem.
The minor problem is that the local trunk is cluttered with the developerN
merges. That is easy to solve by having local developers rebase before pushing
to local trunk. That would look like:
r1--r2--r3--r4--r5 upstream trunk
\ \ \
A---B---C---D---E---F'---G' local trunk
The major problem is that local trunk is also cluttered with merges from
upstream. The is a problem because at some point in the future, upstream
is going to declare some rN as being officially blessed. And we're going to
want to rewind any rN changes past that point.
So the question is, what's the best way to do this? Say r2 is blessed by
upstream. The obvious thing to do (I think...) is:
(local-trunk)$ git rebase -i r2
removing C and E from the pick list.
But, occassionally the merges from upstream require much conflict resolution.
Would enabling rerere during merges help with the rebasing? I would want to
reuse as much conflict resolution as possible.
Is there a better approach altogether? Should we be doing something other
than merging to stay atop upstream?
Suggestions/comments greatly appreciated.
j.
^ permalink raw reply
* Re: [PATCH RFC] rebase: add --revisions flag
From: Junio C Hamano @ 2009-12-09 20:10 UTC (permalink / raw)
To: Matthieu Moy; +Cc: Michael S. Tsirkin, git
In-Reply-To: <vpqiqcgp95t.fsf@bauges.imag.fr>
Matthieu Moy <Matthieu.Moy@grenoble-inp.fr> writes:
> Perhaps "git rebase --cherry-pick A..B" would be a better name. No
> objection for --opposite either.
As somebody mentioned, "--cherry-picking", similar to "am --rebasing" that
is also an unadvertised internal implementation detail, is a good name.
In the very old days, the original "rebase" command was a command to
"set-up and run 'am -3' command in order to transplant the current branch
onto somewhere else."
That was obviously too long for a command name and description, and I
shorten it to "rebase", to name the command after what it is _for_ (not
"what it does", nor "how it does it"). Because the command was to "set up
and run am-3", it was natural at the conceptual level that the way to
continue after a failed/conflicted patch application was "am --resolved".
But since then, the concept of "rebasing" got established more firmly and
how "rebase" can be done has become much less relevant. The original name
"rebase" stopped being short for "set up and run am-3 for rebasing", but
about what it _does_ (i.e. "it rebases"). And "rebase --continue" has
become a natural way to drive "am --continue" at that point, to accomodate
for the change in the end-user conception. These days, "set up and run
am-3 for rebasing" is not even _how_ it does the "rebase", as "rebase -i"
does not even use am-3. So "rebase --continue" was a logical conclusion
of the command's evolution.
The lesson to be learned from this history is that "cherry-pick A..B" that
internally runs "rebase --cherry-picking" will need a similar "--continue"
support that delegates to "rebase". "running am", which was originally
the whole point of "rebase", later became an implementation detail, and we
needed to teach "--continue" to "rebase" at that point.
Because from day one "running rebase -i" will be an implementation detail
of "cherry-pick A..B", we need to teach "cherry-pick" to pass "--abort",
"--continue", etc. to underlying "rebase" for the same reason.
^ permalink raw reply
* Re: [BUG] Bad msysgit/egit interaction over dotfiles
From: Marius Storm-Olsen @ 2009-12-09 20:56 UTC (permalink / raw)
To: Yann Dirson; +Cc: kusmabite, Ferry Huberts, GIT ml
In-Reply-To: <20091208143700.GC5425@linagora.com>
Yann Dirson said the following on 08.12.2009 15:37:
> On Tue, Dec 08, 2009 at 03:23:55PM +0100, Erik Faye-Lund wrote:
>> You can follow the discussion here:
>> http://code.google.com/p/msysgit/issues/detail?id=288
>>
>> I believe the reason is something like "because someone suggested
>> it, and no one disagreed". Do you have a good argument why it
>> shouldn't be the default (other than "it's a change", because
>> changing it back now would also be a change)?
>
> Depending on the opinion of the Eclipse guys on this issue about
> "writing to hidden files only says 'could not write'", which
> arguably could be seen as a bug on their side, we can see changing
> this behaviour back to the default on the msysgit side as either a
> (possibly temporary) workaround for a known eclipse bug, or as
> getting again interoperable with egit.
Dot-files on unix are considered hidden. It's the only way files are
hidden there. Not so on Windows. Dot-files are just like any normal
file, and you need to mark a file hidden.
So, the logic of egit, that *actually* hidden files should not be
written to, but dot-files should, seems to me to be a bug in egit.
There should be no reason why egit shouldn't be able to write to any
file, pending permissions. I'd say file a bug report with egit.
--
.marius
^ permalink raw reply
* Re: [REROLL PATCH 5/8] Support taking over transports
From: Junio C Hamano @ 2009-12-09 21:08 UTC (permalink / raw)
To: Ilari Liusvaara; +Cc: Junio C Hamano, git
In-Reply-To: <20091209151718.GE15673@Knoppix>
Ilari Liusvaara <ilari.liusvaara@elisanet.fi> writes:
>> Who guarantees that reading from the (FILE *)data->out by strbuf_getline()
>> that eventually calls into fgetc() does not cause more data be read in the
>> buffer assiciated with the (FILE *) than we will consume? The other FILE*
>> you will make out of helper->out won't be able to read what data->out has
>> already slurped in to its stdio buffer.
>
> Causality impiles this can happen only if buffered version gets its buffer
> filled after sending connect command. And looking at stdio operations that
> can occur after sending the command:
>
> - fprintfs on stderr (debug mode only).
> - fgetc()s on unbuffered version.
I was worried about the "capabilities" loop in get_helper() if it reads
too much from data->out (causing helper->out to lose the beginning of what
it should read), but as you said, by "Causality" it cannot happen. The
protocol during that phase works with the other end in lock-step, and the
other end wouldn't have written to the pipe what we shouldn't read in that
loop (e.g. remote-curl.c responds with "capabilities" with lines and ends
with fflush(), and after that it waits for us to talk to it --- it would
never start talking by itself without first being asked to talk).
Is data->out only used inside get_helper() to read the capabilities
response? I was confused by it being keft open until disconnect time.
^ permalink raw reply
* Re: [REROLL PATCH 5/8] Support taking over transports
From: Ilari Liusvaara @ 2009-12-09 21:42 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vein3onxf.fsf@alter.siamese.dyndns.org>
On Wed, Dec 09, 2009 at 01:08:44PM -0800, Junio C Hamano wrote:
>
> Is data->out only used inside get_helper() to read the capabilities
> response? I was confused by it being keft open until disconnect time.
Its used for all incoming communications from remote helper until connect
request (and even after it if falling back to dumb transport).
- In smart transport case, that includes possible servpath option.
- In non-smart case, it includes a lot more.
In fact, recvline uses exactly helper->out as stream to read.
-Ilari
^ permalink raw reply
* Re: Delete particular file contents from complete history
From: Miklos Vajna @ 2009-12-09 21:50 UTC (permalink / raw)
To: Patrick Grimard; +Cc: git
In-Reply-To: <9cdb17250912091001u362ce64fybe3d554304cbc445@mail.gmail.com>
[-- Attachment #1: Type: text/plain, Size: 257 bytes --]
On Wed, Dec 09, 2009 at 01:01:17PM -0500, Patrick Grimard <pgrimard@gmail.com> wrote:
> Is there some way to remove from the entire history a particular
> file's content?
Did you read man git-filter-branch? Looks like the first example does
what you need.
[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]
^ permalink raw reply
* Ready for 1.6.6-rc2?
From: Junio C Hamano @ 2009-12-09 21:54 UTC (permalink / raw)
To: git
I see many people have been actively adding commits to 'pu', but we are in
pre-release freeze and I'll be tagging 1.6.6-rc2 hopefully later today.
Depending on how fast the earth rotates, perhaps I'll do so tomorrow, as I
am expecting one order-to-pull from the other side of the globe.
If anybody, including those who are working on new topics, notices a bug
that didn't exist in 1.6.5 in the post-1.6.5 code, please give it a higher
priority than anything else. Bugs and glitches that we had in 1.6.5 are
what users have lived with, and unless fixes to them are really trivial,
they can stay in the upcoming release a bit longer.
But new bugs introduced after 1.6.5, iow, regressions, are something we
would really want to avoid.
Thanks.
^ permalink raw reply
* Re: [PATCH 2/2] t7508-status: test all modes with color
From: Junio C Hamano @ 2009-12-09 21:59 UTC (permalink / raw)
To: Michael J Gruber; +Cc: Jakub Narebski, git
In-Reply-To: <4B1F6B77.80108@drmicha.warpmail.net>
Michael J Gruber <git@drmicha.warpmail.net> writes:
> Regarding the larger part of your change: Is there a specific reason for
> ...
> ">output" rather than "> output" or just a style issue?
Yeah, I shouldn't have included these style fixes in there.
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add diffmerge as a pre-configured mergetool option
From: Charles Bailey @ 2009-12-09 22:34 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, David Aguilar, Junio C Hamano
In-Reply-To: <1260302477-49412-1-git-send-email-jaysoffian@gmail.com>
On Tue, Dec 08, 2009 at 12:01:17PM -0800, Jay Soffian wrote:
> Add SourceGear DiffMerge to the set of built-in diff/merge tools, and update
> bash completion and documentation.
> ---
> Documentation/git-difftool.txt | 2 +-
> Documentation/git-mergetool.txt | 2 +-
> Documentation/merge-config.txt | 4 ++--
> contrib/completion/git-completion.bash | 2 +-
> git-mergetool--lib.sh | 22 ++++++++++++++++++++--
> 5 files changed, 25 insertions(+), 7 deletions(-)
I'm not a diffmerge user but the patch looks fine to me.
Is diffmerge free but not Free?
Any reason for holding back on sign-off?
Charles.
^ permalink raw reply
* Re: Generic filters for git archive?
From: René Scharfe @ 2009-12-09 22:48 UTC (permalink / raw)
To: Russ Dill; +Cc: git
In-Reply-To: <f9d2a5e10912071706m10ed7112ob7db47cdfac510d6@mail.gmail.com>
Am 08.12.2009 02:06, schrieb Russ Dill:
> I'm trying to add copyright headers to my source files as they are
> exported via git archive. eg:
>
> * $Copyright$
>
> to
>
> * Copyright (c) 2003-2009 by Foo Bar
> *
> * This program is free software; you can redistribute it and/or modify it
> * under the terms of the GNU General Public License as published by the
> * Free Software Foundation; either version 2 of the License, or (at your
> * option) any later version.
> *
> * This program is distributed in the hope that it will be useful, but
> * WITHOUT ANY WARRANTY; without even the implied warranty of MERCHANTABILITY
> * or FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License
> * for more details.
> *
> * You should have received a copy of the GNU General Public License
> * along with this program; if not, write to the Free Software Foundation,
> * Inc., 675 Mass Ave, Cambridge, MA 02139, USA.
>
> And properly handling things like '# $Copyright$', '// $Copyright$',
> etc. I have a sed script that does this, but no way to apply it to the
> output of git archive. I tried setting up a smudge filter that would
> only smudge output on archive exports, but it doesn't appear that the
> smudge filters get run on git archive.
>
> I am currently running 1.6.3.3
Is the filter attribute contained in a .gitattribute file that's part of
the tree you are trying to export? If it's only in the worktree copy,
then you need to use the option --worktree-attributes to make git
archive use it.
René
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add diffmerge as a pre-configured mergetool option
From: Jay Soffian @ 2009-12-09 23:14 UTC (permalink / raw)
To: Charles Bailey; +Cc: git, David Aguilar, Junio C Hamano
In-Reply-To: <20091209223409.GA32744@hashpling.org>
On Wed, Dec 9, 2009 at 2:34 PM, Charles Bailey <charles@hashpling.org> wrote:
> Is diffmerge free but not Free?
Correct, it's free as in beer, not as in speech. It is multi-platform
though (Linux, Windows, OS X). I've tested only on MacOS X. If someone
else wants to give it a test on Linux, that would be good. Looks like
there's both a deb and an rpm:
http://www.sourcegear.com/diffmerge/downloads.html
> Any reason for holding back on sign-off?
Oversight:
Signed-off-by: Jay Soffian <jaysoffian@gmail.com>
j.
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add diffmerge as a pre-configured mergetool option
From: Junio C Hamano @ 2009-12-10 0:08 UTC (permalink / raw)
To: Jay Soffian; +Cc: git, David Aguilar
In-Reply-To: <1260302477-49412-1-git-send-email-jaysoffian@gmail.com>
Jay Soffian <jaysoffian@gmail.com> writes:
> diff --git a/git-mergetool--lib.sh b/git-mergetool--lib.sh
> index 5b62785..5b29fef 100644
> --- a/git-mergetool--lib.sh
> +++ b/git-mergetool--lib.sh
> @@ -46,7 +46,8 @@ check_unchanged () {
> valid_tool () {
> case "$1" in
> kdiff3 | tkdiff | xxdiff | meld | opendiff | \
> - emerge | vimdiff | gvimdiff | ecmerge | diffuse | araxis | p4merge)
> + emerge | vimdiff | gvimdiff | ecmerge | diffuse | araxis | p4merge | \
> + diffmerge)
> ;; # happy
> tortoisemerge)
> if ! merge_mode; then
As we are in pre-release feature freeze, it doesn't matter very much if I
take this patch now, so I'll let it sit in the list archive for now.
But I have to wonder about the maintainability of this file, if we have to
add every time somebody finds yet another diff/merge backends that could
be used, even a closed-source one.
There are only a handful of entry points that mergetool--lib defines, and
by overriding what should happen when these entry points are called, an end
user should be able to tell mergetool/difftool to use a new backend.
Perhaps it is a better approach to first eject bulk of code for the
backends we currently support under these case statements into separate
files, one per backend, move them to mergetool/ subdirectory in the source
tree, install them as "$(share)/git-core/mergetool/$toolname", and at
runtime source them? That way, a patch to add a new backend can be as
simple as adding a new file in mergetool/ and doing nothing else. Also an
end user can privately add support to a new backend much more easily.
Anybody want to try that approach?
^ permalink raw reply
* Re: [PATCH] mergetool--lib: add diffmerge as a pre-configured mergetool option
From: Jay Soffian @ 2009-12-10 0:16 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, David Aguilar
In-Reply-To: <7vaaxrn10o.fsf@alter.siamese.dyndns.org>
On Wed, Dec 9, 2009 at 4:08 PM, Junio C Hamano <gitster@pobox.com> wrote:
> Perhaps it is a better approach to first eject bulk of code for the
> backends we currently support under these case statements into separate
> files, one per backend, move them to mergetool/ subdirectory in the source
> tree, install them as "$(share)/git-core/mergetool/$toolname", and at
> runtime source them? That way, a patch to add a new backend can be as
> simple as adding a new file in mergetool/ and doing nothing else. Also an
> end user can privately add support to a new backend much more easily.
>
> Anybody want to try that approach?
Sure. There may also be value in emulating the mercurial approach:
http://mercurial.selenic.com/wiki/MergeToolConfiguration
I'll give both a shot.
j.
^ permalink raw reply
* [ANNOUNCE] Git 1.6.6.rc2
From: Junio C Hamano @ 2009-12-10 1:44 UTC (permalink / raw)
To: git
A release candidate Git 1.6.6.rc2 is available at the usual places
for testing:
http://www.kernel.org/pub/software/scm/git/
git-1.6.6.rc2.tar.{gz,bz2} (source tarball)
git-htmldocs-1.6.6.rc2.tar.{gz,bz2} (preformatted docs)
git-manpages-1.6.6.rc2.tar.{gz,bz2} (preformatted docs)
The RPM binary packages for a few architectures are found in:
testing/git-*-1.6.6.rc2-1.fc11.$arch.rpm (RPM)
The changes since rc1 are mostly updates to the subsystems.
The regression to "git pull" that made the command give annoying warning
message when there is no local commit has been fixed; it appeared in rc1.
----------------------------------------------------------------
Changes since v1.6.6-rc1 are as follows:
Alex Vandiver (3):
git-svn: sort svk merge tickets to account for minimal parents
git-svn: Set svn.authorsfile to an absolute path when cloning
git-svn: set svn.authorsfile earlier when cloning
Alexander Gavrilov (1):
git-gui: Increase blame viewer usability on MacOS.
Bernt Hansen (1):
gitk: Skip translation of "wrong Tcl version" message
Brandon Casey (2):
t4201: use ISO8859-1 rather than ISO-8859-1
t9001: use older Getopt::Long boolean prefix '--no' rather than '--no-'
Clemens Buchacher (1):
git-gui: search 4 directories to improve statistic of gc hint
Eric Wong (1):
git svn: log removals of empty directories
Greg Price (1):
git svn: Don't create empty directories whose parents were deleted
Guillermo S. Romero (1):
gitk: Add configuration for UI colour scheme
Heiko Voigt (1):
git gui: make current branch default in "remote delete branch" merge check
Jakub Narebski (1):
gitweb: Describe (possible) gitweb.js minification in gitweb/README
Jan Krüger (1):
pull: clarify advice for the unconfigured error case
Jeff King (3):
rerere: don't segfault on failure to open rr-cache
reset: improve worktree safety valves
add-interactive: fix deletion of non-empty files
Jens Lehmann (2):
gitk: Fix diffing committed -> staged (typo in diffcmd)
gitk: Use the --submodule option for displaying diffs when available
Jindrich Makovicka (1):
git-gui: suppress RenderBadPicture X error caused by Tk bug
Johan Herland (1):
Fix crasher on encountering SHA1-like non-note in notes tree
Junio C Hamano (9):
Documentation/Makefile: allow man.base.url.for.relative.link to be set from Make
Unconditionally set man.base.url.for.relative.links
Git 1.6.5.4
Documentation: xmlto 0.0.18 does not know --stringparam
Prepare for 1.6.5.5
Git 1.6.5.5
Revert recent "git merge <msg> HEAD <commit>..." deprecation
Update draft release notes to 1.6.6 before -rc2
Git 1.6.6-rc2
Linus Torvalds (1):
Fix diff -B/--dirstat miscounting of newly added contents
Markus Heidelberg (1):
gitk: Fix "git gui blame" invocation when called from top-level directory
Mizar (2):
gitk: Add Japanese translation
gitk: Update Japanese translation
Pat Thoyts (4):
gitk: Use themed tk widgets
gitk: Fix errors in the theme patch
gitk: Default to the system colours on Windows
gitk: Fix selection of tags
Paul Mackerras (5):
gitk: Restore scrolling position of diff pane on back/forward in history
gitk: Add a user preference to enable/disable use of themed widgets
gitk: Show diff of commits at end of compare-commits output
gitk: Don't compare fake children when comparing commits
gitk: Improve appearance of radiobuttons and checkbuttons
René Scharfe (1):
archive: clarify description of path parameter
SZEDER Gábor (1):
bash: update 'git commit' completion
Sitaram Chamarty (1):
gitk: Disable checkout of remote branches
Todd Zullinger (1):
Documentation: Avoid use of xmlto --stringparam
^ 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