* [PATCH 04/19] Add a config option for remotes to specify a foreign vcs
From: Sverre Rabbelier @ 2009-10-29 18:01 UTC (permalink / raw)
To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
Cc: Daniel Barkalow, Sverre Rabbelier
In-Reply-To: <1256839287-19016-1-git-send-email-srabbelier@gmail.com>
From: Daniel Barkalow <barkalow@iabervon.org>
If this is set, the url is not required, and the transport always uses
a helper named "git-remote-<value>".
It is a separate configuration option in order to allow a sensible
configuration for foreign systems which either have no meaningful urls
for repositories or which require urls that do not specify the system
used by the repository at that location. However, this only affects
how the name of the helper is determined, not anything about the
interaction with the helper, and the contruction is such that, if the
foreign scm does happen to use a co-named url method, a url with that
method may be used directly.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
This has my patch to fix valid_remote to allow for both url
vcs squashed in.
Documentation/config.txt | 4 ++++
remote.c | 4 +++-
remote.h | 2 ++
transport.c | 5 +++++
4 files changed, 14 insertions(+), 1 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index d1e2120..0d9d369 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -1408,6 +1408,10 @@ remote.<name>.tagopt::
Setting this value to \--no-tags disables automatic tag following when
fetching from remote <name>
+remote.<name>.vcs::
+ Setting this to a value <vcs> will cause git to interact with
+ the remote with the git-remote-<vcs> helper.
+
remotes.<group>::
The list of remotes which are fetched by "git remote update
<group>". See linkgit:git-remote[1].
diff --git a/remote.c b/remote.c
index 15c9cec..09bb79c 100644
--- a/remote.c
+++ b/remote.c
@@ -54,7 +54,7 @@ static char buffer[BUF_SIZE];
static int valid_remote(const struct remote *remote)
{
- return !!remote->url;
+ return (!!remote->url) || (!!remote->foreign_vcs);
}
static const char *alias_url(const char *url, struct rewrites *r)
@@ -444,6 +444,8 @@ static int handle_config(const char *key, const char *value, void *cb)
} else if (!strcmp(subkey, ".proxy")) {
return git_config_string((const char **)&remote->http_proxy,
key, value);
+ } else if (!strcmp(subkey, ".vcs")) {
+ return git_config_string(&remote->foreign_vcs, key, value);
}
return 0;
}
diff --git a/remote.h b/remote.h
index 5db8420..ac0ce2f 100644
--- a/remote.h
+++ b/remote.h
@@ -11,6 +11,8 @@ struct remote {
const char *name;
int origin;
+ const char *foreign_vcs;
+
const char **url;
int url_nr;
int url_alloc;
diff --git a/transport.c b/transport.c
index 5ae8db6..13bab4e 100644
--- a/transport.c
+++ b/transport.c
@@ -818,6 +818,11 @@ struct transport *transport_get(struct remote *remote, const char *url)
url = remote->url[0];
ret->url = url;
+ if (remote && remote->foreign_vcs) {
+ transport_helper_init(ret, remote->foreign_vcs);
+ return ret;
+ }
+
if (!prefixcmp(url, "rsync:")) {
ret->get_refs_list = get_refs_via_rsync;
ret->fetch = fetch_objs_via_rsync;
--
1.6.5.2.291.gf76a3
^ permalink raw reply related
* [PATCH 02/19] Allow fetch to modify refs
From: Sverre Rabbelier @ 2009-10-29 18:01 UTC (permalink / raw)
To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
Cc: Daniel Barkalow, Sverre Rabbelier
In-Reply-To: <1256839287-19016-1-git-send-email-srabbelier@gmail.com>
From: Daniel Barkalow <barkalow@iabervon.org>
This allows the transport to use the null sha1 for a ref reported to
be present in the remote repository to indicate that a ref exists but
its actual value is presently unknown and will be set if the objects
are fetched.
Also adds documentation to the API to specify exactly what the methods
should do and how they should interpret arguments.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Signed off by me because I rebased it on master and fixed the
conflicts with nico's patch.
builtin-clone.c | 5 +++--
transport-helper.c | 4 ++--
transport.c | 13 +++++++------
transport.h | 41 +++++++++++++++++++++++++++++++++++++++--
4 files changed, 51 insertions(+), 12 deletions(-)
diff --git a/builtin-clone.c b/builtin-clone.c
index 5762a6f..0042bee 100644
--- a/builtin-clone.c
+++ b/builtin-clone.c
@@ -526,8 +526,9 @@ int cmd_clone(int argc, const char **argv, const char *prefix)
refs = transport_get_remote_refs(transport);
if (refs) {
- mapped_refs = wanted_peer_refs(refs, refspec);
- transport_fetch_refs(transport, mapped_refs);
+ struct ref *ref_cpy = wanted_peer_refs(refs, refspec);
+ mapped_refs = ref_cpy;
+ transport_fetch_refs(transport, ref_cpy);
}
}
diff --git a/transport-helper.c b/transport-helper.c
index f57e84c..a0e4219 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -68,7 +68,7 @@ static int disconnect_helper(struct transport *transport)
}
static int fetch_with_fetch(struct transport *transport,
- int nr_heads, const struct ref **to_fetch)
+ int nr_heads, struct ref **to_fetch)
{
struct child_process *helper = get_helper(transport);
FILE *file = xfdopen(helper->out, "r");
@@ -92,7 +92,7 @@ static int fetch_with_fetch(struct transport *transport,
}
static int fetch(struct transport *transport,
- int nr_heads, const struct ref **to_fetch)
+ int nr_heads, struct ref **to_fetch)
{
struct helper_data *data = transport->data;
int i, count;
diff --git a/transport.c b/transport.c
index 644a30a..3822fc7 100644
--- a/transport.c
+++ b/transport.c
@@ -204,7 +204,7 @@ static struct ref *get_refs_via_rsync(struct transport *transport, int for_push)
}
static int fetch_objs_via_rsync(struct transport *transport,
- int nr_objs, const struct ref **to_fetch)
+ int nr_objs, struct ref **to_fetch)
{
struct strbuf buf = STRBUF_INIT;
struct child_process rsync;
@@ -408,7 +408,7 @@ static struct ref *get_refs_from_bundle(struct transport *transport, int for_pus
}
static int fetch_refs_from_bundle(struct transport *transport,
- int nr_heads, const struct ref **to_fetch)
+ int nr_heads, struct ref **to_fetch)
{
struct bundle_transport_data *data = transport->data;
return unbundle(&data->header, data->fd);
@@ -486,7 +486,7 @@ static struct ref *get_refs_via_connect(struct transport *transport, int for_pus
}
static int fetch_refs_via_pack(struct transport *transport,
- int nr_heads, const struct ref **to_fetch)
+ int nr_heads, struct ref **to_fetch)
{
struct git_transport_data *data = transport->data;
char **heads = xmalloc(nr_heads * sizeof(*heads));
@@ -923,16 +923,17 @@ const struct ref *transport_get_remote_refs(struct transport *transport)
return transport->remote_refs;
}
-int transport_fetch_refs(struct transport *transport, const struct ref *refs)
+int transport_fetch_refs(struct transport *transport, struct ref *refs)
{
int rc;
int nr_heads = 0, nr_alloc = 0, nr_refs = 0;
- const struct ref **heads = NULL;
- const struct ref *rm;
+ struct ref **heads = NULL;
+ struct ref *rm;
for (rm = refs; rm; rm = rm->next) {
nr_refs++;
if (rm->peer_ref &&
+ !is_null_sha1(rm->old_sha1) &&
!hashcmp(rm->peer_ref->old_sha1, rm->old_sha1))
continue;
ALLOC_GROW(heads, nr_heads + 1, nr_alloc);
diff --git a/transport.h b/transport.h
index c14da6f..503db11 100644
--- a/transport.h
+++ b/transport.h
@@ -18,11 +18,48 @@ struct transport {
int (*set_option)(struct transport *connection, const char *name,
const char *value);
+ /**
+ * Returns a list of the remote side's refs. In order to allow
+ * the transport to try to share connections, for_push is a
+ * hint as to whether the ultimate operation is a push or a fetch.
+ *
+ * If the transport is able to determine the remote hash for
+ * the ref without a huge amount of effort, it should store it
+ * in the ref's old_sha1 field; otherwise it should be all 0.
+ **/
struct ref *(*get_refs_list)(struct transport *transport, int for_push);
- int (*fetch)(struct transport *transport, int refs_nr, const struct ref **refs);
+
+ /**
+ * Fetch the objects for the given refs. Note that this gets
+ * an array, and should ignore the list structure.
+ *
+ * If the transport did not get hashes for refs in
+ * get_refs_list(), it should set the old_sha1 fields in the
+ * provided refs now.
+ **/
+ int (*fetch)(struct transport *transport, int refs_nr, struct ref **refs);
+
+ /**
+ * Push the objects and refs. Send the necessary objects, and
+ * then, for any refs where peer_ref is set and
+ * peer_ref->new_sha1 is different from old_sha1, tell the
+ * remote side to update each ref in the list from old_sha1 to
+ * peer_ref->new_sha1.
+ *
+ * Where possible, set the status for each ref appropriately.
+ *
+ * The transport must modify new_sha1 in the ref to the new
+ * value if the remote accepted the change. Note that this
+ * could be a different value from peer_ref->new_sha1 if the
+ * process involved generating new commits.
+ **/
int (*push_refs)(struct transport *transport, struct ref *refs, int flags);
int (*push)(struct transport *connection, int refspec_nr, const char **refspec, int flags);
+ /** get_refs_list(), fetch(), and push_refs() can keep
+ * resources (such as a connection) reserved for futher
+ * use. disconnect() releases these resources.
+ **/
int (*disconnect)(struct transport *connection);
char *pack_lockfile;
signed verbose : 2;
@@ -74,7 +111,7 @@ int transport_push(struct transport *connection,
const struct ref *transport_get_remote_refs(struct transport *transport);
-int transport_fetch_refs(struct transport *transport, const struct ref *refs);
+int transport_fetch_refs(struct transport *transport, struct ref *refs);
void transport_unlock_pack(struct transport *transport);
int transport_disconnect(struct transport *transport);
char *transport_anonymize_url(const char *url);
--
1.6.5.2.291.gf76a3
^ permalink raw reply related
* [PATCH 01/19] Use a function to determine whether a remote is valid
From: Sverre Rabbelier @ 2009-10-29 18:01 UTC (permalink / raw)
To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
Cc: Daniel Barkalow, Sverre Rabbelier
In-Reply-To: <1256839287-19016-1-git-send-email-srabbelier@gmail.com>
From: Daniel Barkalow <barkalow@iabervon.org>
Currently, it only checks url, but it will allow other things in the future.
Signed-off-by: Daniel Barkalow <barkalow@iabervon.org>
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
---
Signed off by me because I fixed the conflict with alias_url.
remote.c | 13 +++++++++----
1 files changed, 9 insertions(+), 4 deletions(-)
diff --git a/remote.c b/remote.c
index 73d33f2..15c9cec 100644
--- a/remote.c
+++ b/remote.c
@@ -52,6 +52,11 @@ static struct rewrites rewrites_push;
#define BUF_SIZE (2048)
static char buffer[BUF_SIZE];
+static int valid_remote(const struct remote *remote)
+{
+ return !!remote->url;
+}
+
static const char *alias_url(const char *url, struct rewrites *r)
{
int i, j;
@@ -688,14 +693,14 @@ struct remote *remote_get(const char *name)
ret = make_remote(name, 0);
if (valid_remote_nick(name)) {
- if (!ret->url)
+ if (!valid_remote(ret))
read_remotes_file(ret);
- if (!ret->url)
+ if (!valid_remote(ret))
read_branches_file(ret);
}
- if (name_given && !ret->url)
+ if (name_given && !valid_remote(ret))
add_url_alias(ret, name);
- if (!ret->url)
+ if (!valid_remote(ret))
return NULL;
ret->fetch = parse_fetch_refspec(ret->fetch_refspec_nr, ret->fetch_refspec);
ret->push = parse_push_refspec(ret->push_refspec_nr, ret->push_refspec);
--
1.6.5.2.291.gf76a3
^ permalink raw reply related
* [PATCH 0/19] Reroll of the remote-vcs-helper series
From: Sverre Rabbelier @ 2009-10-29 18:01 UTC (permalink / raw)
To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
Reroll of the entire series that is currently in pu, rebased on
current master.
I did not squash the cvs makefile fixes since my Makefile foo is not
that great.
Daniel, please have a close look at the UNSTABLE patch, as I am not
sure at all that I rebased it properly.
I did not have time to work on my git-remote-hg patches yet, but I
might send those two out later today before I get on my flight back
home. If not it'll be tomorrow somewhere :).
Daniel Barkalow (7):
Use a function to determine whether a remote is valid
Allow fetch to modify refs
Allow programs to not depend on remotes having urls
Add a config option for remotes to specify a foreign vcs
Add support for "import" helper command
Allow helpers to report in "list" command that the ref is unchanged
Fix memory leak in helper method for disconnect
Johan Herland (8):
Allow helpers to request marks for fast-import
Basic build infrastructure for Python scripts
1/2: Add Python support library for CVS remote helper
2/2: Add Python support library for CVS remote helper
git-remote-cvs: Remote helper program for CVS repositories
Add simple selftests of git-remote-cvs functionality
Fix the Makefile-generated path to the git_remote_cvs package in git-remote-cvs
More fixes to the git-remote-cvs installation procedure
Johannes Schindelin (1):
Finally make remote helper support useful
Sverre Rabbelier (3):
Factor ref updating out of fetch_with_import
Refactor git_remote_cvs to a more generic git_remote_helpers
.gitignore: add git-remote-cvs
.gitignore | 1 +
Documentation/config.txt | 4 +
Documentation/git-remote-cvs.txt | 85 +++
Documentation/git-remote-helpers.txt | 22 +-
Makefile | 53 ++
builtin-clone.c | 12 +-
builtin-fetch.c | 10 +-
builtin-ls-remote.c | 4 +-
builtin-push.c | 68 ++-
configure.ac | 3 +
git-remote-cvs.py | 683 +++++++++++++++++++++
git_remote_helpers/.gitignore | 2 +
git_remote_helpers/Makefile | 35 ++
git_remote_helpers/__init__.py | 27 +
git_remote_helpers/cvs/changeset.py | 126 ++++
git_remote_helpers/cvs/commit_states.py | 62 ++
git_remote_helpers/cvs/cvs.py | 998 +++++++++++++++++++++++++++++++
git_remote_helpers/cvs/revision_map.py | 418 +++++++++++++
git_remote_helpers/cvs/symbol_cache.py | 313 ++++++++++
git_remote_helpers/git/git.py | 680 +++++++++++++++++++++
git_remote_helpers/setup.py | 17 +
git_remote_helpers/util.py | 194 ++++++
remote.c | 15 +-
remote.h | 2 +
t/t9800-remote-cvs-basic.sh | 524 ++++++++++++++++
t/t9801-remote-cvs-fetch.sh | 291 +++++++++
t/test-lib.sh | 10 +
transport-helper.c | 117 ++++-
transport.c | 37 +-
transport.h | 45 ++-
30 files changed, 4810 insertions(+), 48 deletions(-)
^ permalink raw reply
* [PATCH] Explicitly truncate bswap operand to uint32_t
From: Benjamin Kramer @ 2009-10-29 17:43 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
There are some places in git where a long is passed to htonl/ntohl. llvm
doesn't support matching operands of different bitwidths intentionally.
This patch fixes the build with llvm-gcc (and clang) on x86_64.
Signed-off-by: Benjamin Kramer <benny.kra@googlemail.com>
---
See also:
* http://llvm.org/bugs/show_bug.cgi?id=3373
* http://lkml.org/lkml/2009/1/23/261
compat/bswap.h | 2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/compat/bswap.h b/compat/bswap.h
index 5cc4acb..52fc7b6 100644
--- a/compat/bswap.h
+++ b/compat/bswap.h
@@ -24,7 +24,7 @@ static inline uint32_t default_swab32(uint32_t val)
if (__builtin_constant_p(x)) { \
__res = default_swab32(x); \
} else { \
- __asm__("bswap %0" : "=r" (__res) : "0" (x)); \
+ __asm__("bswap %0" : "=r" (__res) : "0" ((uint32_t)(x))); \
} \
__res; })
--
1.6.5.2.102.g442a9
^ permalink raw reply related
* Re: [PATCH 7/7] Factor ref updating out of fetch_with_import
From: Sverre Rabbelier @ 2009-10-29 17:39 UTC (permalink / raw)
To: Daniel Barkalow
Cc: Shawn O. Pearce, Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <alpine.LNX.2.00.0910291311570.14365@iabervon.org>
Heya,
On Thu, Oct 29, 2009 at 10:22, Daniel Barkalow <barkalow@iabervon.org> wrote:
> (a) if HEAD is determined to be a symref, and we care about HEAD, we care
> about whatever HEAD is a symref to; wanted_peer_refs() shouldn't be
> filtering such things out.
It seems that wanted_peer_refs filters out HEAD no matter what though?
> (b) we don't want to make a whole bunch of copies of the ref list to avoid
> updating the mutable ref list that we will look for updated values in; the
> merge of my series with Nico's should replace my copy_ref_list with his
> wanted_peer_refs, not include the copy afterwards. Correcting this should
> lead to the value that matters in the list that will be used having been
> updated directly by transport_fetch_refs().
This I can and will fix. Patch-bomb incoming.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH] Update packfile transfer protocol documentation
From: Scott Chacon @ 2009-10-29 17:35 UTC (permalink / raw)
To: git list; +Cc: Shawn O. Pearce
The technical documentation for the packfile protocol is both sparse and
incorrect. This documents the fetch-pack/upload-pack and send-pack/
receive-pack protocols much more fully.
Add documentation from Shawn's upcoming http-protocol docs that is shared
by the packfile protocol. protocol-common.txt describes ABNF notation
amendments, refname rules and the packet line format.
Add documentation on the various capabilities supported by the
upload-pack and receive-pack protocols. protocol-capabilities.txt describes
multi-ack, thin-pack, side-band[-64k], ofs-delta, shallow, no-progress
and include-tag.
Signed-Off-By: Scott Chacon <schacon@gmail.com>
---
Some of this documentation is in RFC style and some of it is really
not - I apologize for that. However, I think it's a good starting
point - certainly better than the docs in there now. Some of this was
taken from the gitserver-rfc stuff I did several months ago, and I've
tried to include updates I got from Jakub and others on issues with
that document. The protocol-common.txt is taken from Shawns
http-protocol.txt that was in common with packfile protocol. Shawn,
is that the best way to share that info?
Documentation/technical/pack-protocol.txt | 502 +++++++++++++++++++--
Documentation/technical/protocol-capabilities.txt | 146 ++++++
Documentation/technical/protocol-common.txt | 97 ++++
3 files changed, 704 insertions(+), 41 deletions(-)
create mode 100644 Documentation/technical/protocol-capabilities.txt
create mode 100644 Documentation/technical/protocol-common.txt
diff --git a/Documentation/technical/pack-protocol.txt
b/Documentation/technical/pack-protocol.txt
index 9cd48b4..9222a10 100644
--- a/Documentation/technical/pack-protocol.txt
+++ b/Documentation/technical/pack-protocol.txt
@@ -1,41 +1,461 @@
-Pack transfer protocols
-=======================
-
-There are two Pack push-pull protocols.
-
-upload-pack (S) | fetch/clone-pack (C) protocol:
-
- # Tell the puller what commits we have and what their names are
- S: SHA1 name
- S: ...
- S: SHA1 name
- S: # flush -- it's your turn
- # Tell the pusher what commits we want, and what we have
- C: want name
- C: ..
- C: want name
- C: have SHA1
- C: have SHA1
- C: ...
- C: # flush -- occasionally ask "had enough?"
- S: NAK
- C: have SHA1
- C: ...
- C: have SHA1
- S: ACK
- C: done
- S: XXXXXXX -- packfile contents.
-
-send-pack | receive-pack protocol.
-
- # Tell the pusher what commits we have and what their names are
- C: SHA1 name
- C: ...
- C: SHA1 name
- C: # flush -- it's your turn
- # Tell the puller what the pusher has
- S: old-SHA1 new-SHA1 name
- S: old-SHA1 new-SHA1 name
- S: ...
- S: # flush -- done with the list
- S: XXXXXXX --- packfile contents.
+Packfile transfer protocols
+===========================
+
+Git supports transferring data in packfiles over the ssh://, git:// and
+file:// transports. There exist two sets of protocols, one for pushing
+data from a client to a server and another for fetching data from a
+server to a client. All three transports (ssh, git, file) use the same
+protocol to transfer data.
+
+The processes invoked in the canonical Git implementation are 'upload-pack'
+on the server side and 'fetch-pack' on the client side for fetching data;
+then 'receive-pack' on the server and 'send-pack' on the client for pushing
+data. The protocol functions to have a server tell a client what is
+currently on the server, then for the two to negotiate the smallest amount
+of data to send in order to fully update one or the other.
+
+Transports
+----------
+There are three transports over which the packfile protocol is
+initiated. The Git transport is a simple, unauthenticated server that
+simply takes the command (almost always 'upload-pack', though Git
+servers can be configured to be globally writable, in which 'receive-
+pack' initiation is also allowed) with which the client wishes to
+communicate and executes it and connects it to the requesting
+process.
+
+In the SSH transport, the client basically just runs the 'upload-pack'
+or 'receive-pack' process on the server over the SSH protocol and then
+communicates with that invoked process over the SSH connection.
+
+The file:// transport simply runs the 'upload-pack' or 'receive-pack'
+process locally.
+
+Git Protocol
+------------
+
+The Git protocol starts off by sending "git-receive-pack 'repo.git'"
+on the wire using the pkt-line format, followed by a null byte and a
+hostname paramater, terminated by a null byte.
+
+ 0032git-upload-pack /project.git\0host=myserver.com\0
+
+--
+ git-proto-request = request-command SP pathname NUL [ host-parameter NUL ]
+ request-command = 'git-upload-pack' / 'git-receive-pack' /
+ 'git-upload-archive' ; case sensitive
+ pathname = *( %x01-ff ) ; exclude NUL
+ host-parameter = 'host' "=" hostname [ ":" port ]
+--
+
+Currently only 'host' is allowed in the extra information. It's
+for the git-daemon name based virtual hosting. See --interpolated-
+path option to git daemon, with the %H/%CH format characters.
+
+Basically what the Git client is doing to connect to an 'upload-pack'
+process on the server side over the Git protocol is this:
+
+ $ echo -e -n \
+ "0039git-upload-pack /schacon/gitbook.git\0host=github.com\0" |
+ nc -v github.com 9418
+
+
+SSH Protocol
+------------
+
+Initiating the upload-pack or receive-pack processes over SSH is
+simply executing the binary on the server via SSH remote execution.
+It is basically equivalent to running this:
+
+ $ ssh git.example.com 'git-upload-pack /project.git'
+
+For a server to support Git pushing and pulling for a given user over
+SSH, that user needs to be able to execute one or both of those
+commands via the SSH shell that they are provided on login. On some
+systems, that shell access is limited to only being able to run those
+two commands, or even just one of them.
+
+In an ssh:// format URI, it's absolute in the URI, so the '/' after
+the host name (or port number) is sent as an argument, which is then
+read by the remote git-upload-pack exactly as is, so it's effectively
+an absolute path in the remote filesystem.
+
+ git clone ssh://user@example.com/project.git
+ |
+ v
+ ssh user@example.com 'git-upload-pack /project.git'
+
+In a "user@host:path" format URI, its relative to the user's home
+directory, because the Git client will run:
+
+ git clone user@example.com:project.git
+ |
+ v
+ ssh user@example.com 'git-upload-pack project.git'
+
+
+
+Fetching Data From a Server
+===========================
+
+When one Git repository wants to get all the data that a second
+repository has, the first can 'fetch' from the second. This
+operation determines what data the server has that the client does
+not then streams that data down to the client in packfile format.
+
+The server side binaries need to be executable as 'git-upload-pack'
+for fetching and 'git-receive-pack' for pushing over SSH, since the
+Git clients will connect to the server and attempt to run that command
+directly. Over the Git protocol, one could write their own daemon
+that sees that the client is trying to invoke those commands and
+simply handle the requests.
+
+
+Reference Discovery
+-------------------
+
+When the client initially connects the server will immediately respond
+with a listing of each reference it has (all branches and tags) along
+with the commit SHA that each reference currently points to.
+
+ $ echo -e -n \
+ "0039git-upload-pack /schacon/gitbook.git\0host=github.com\0" |
+ nc -v github.com 9418
+ 00887217a7c7e582c46cec22a130adf4b9d7d950fba0 HEAD\0multi_ack \
+ thin-pack side-band side-band-64k ofs-delta shallow no-progress \
+ include-tag
+ 00441d3fcd5ced445d1abc402225c0b8a1299641f497 refs/heads/integration
+ 003f7217a7c7e582c46cec22a130adf4b9d7d950fba0 refs/heads/master
+ 003cb88d2441cac0977faf98efc80305012112238d9d refs/tags/v0.9
+ 003c525128480b96c89e6418b1e40909bf6c5b2d580f refs/tags/v1.0
+ 003fe92df48743b7bc7d26bcaabfddde0a1e20cae47c refs/tags/v1.0^{}
+ 0000
+
+Server SHOULD terminate each non-flush line
+using LF ("\n") terminator; client MUST NOT complain if there is no
+terminator.
+
+The returned response is a pkt-line stream describing each ref and
+its known value. The stream SHOULD be sorted by name according to
+the C locale ordering. The stream SHOULD include the default ref
+named 'HEAD' as the first ref. The stream MUST include capability
+declarations behind a NUL on the first ref.
+
+HEAD is not included if its detached - that is, if HEAD is not a
+symbolic reference, a pointer to another branch, it is not included
+in the initial server response. The client pattern matches the
+advertisements against the fetch refspec, which is "refs/heads/
+*:refs/remotes/origin/*" by default. HEAD doesn't match the LHS, so
+it doesn't get wanted by the client.
+
+----
+ advertised-refs = (no-refs / list-of-refs)
+ flush-pkt
+
+ no-refs = PKT-LINE(zero-id SP "capabilities^{}"
+ NUL capability-list LF)
+
+ list-of-refs = first-ref *other-ref
+ first-ref = PKT-LINE(obj-id SP refname
+ NUL capability-list LF)
+
+ other-ref = PKT-LINE(other-tip / other-peeled)
+ other-tip = obj-id SP refname LF
+ other-peeled = obj-id SP refname "^{}" LF
+
+ capability-list = capability *(SP capability)
+ capability = 1*(ALPHA / DIGIT / "-" / "_")
+----
+
+Server and client SHOULD use lowercase for SHA1, both MUST treat SHA1
+as case-insensitive.
+
+See protocol-capabilities.txt for a list of allowed server capabilities
+and descriptions.
+
+Packfile Negotiation
+--------------------
+After reference and capabilities discovery, the client can decide
+to terminate the connection (as happens with the ls-remote command)
+or it can enter the negotiation phase, where the client and server
+determine what the minimal packfile necessary for transport is.
+
+Once the client has the initial list of references that the server
+has, as well as the list of capabilities, it will begin telling the
+server what objects it wants and what objects it has, so the server
+can make a packfile that only has the objects that the client needs.
+The client will also send a list of the capabilities it supports out
+of what the server said it could do with the first 'want' statement.
+
+----
+ upload-request = want-list
+ have-list
+ compute-end
+
+ want-list = first-want
+ *additional-want
+ flush-pkt
+
+ first-want = PKT-LINE("want" SP obj-id SP capability-list LF)
+ additional-want = PKT-LINE("want" SP obj-id LF)
+
+ have-list = *have-line
+ have-line = PKT-LINE("have" SP obj-id LF)
+ compute-end = flush-pkt / PKT-LINE("done")
+----
+
+Clients MUST send all the SHAs it wants from the reference
+discovery phase as 'want' lines. Clients MUST send at least one
+'want' command in the request body. Clients MUST NOT mention an
+obj-id in a 'want' command which did not appear in the response
+obtained through ref discovery.
+
+If client is requesting a shallow clone, it will now send a 'deepen'
+command with the depth it is requesting.
+
+Once all the "want"s (and optional 'deepen') are transferred,
+clients MUST send a flush. If the client has all the references on
+the server, client simply flushes and disconnects.
+
+TODO: shallow/unshallow response
+
+Now the client will send a list of the obj-ids it has. In multi-ack
+mode, the canonical implementation will send up to 32 of these at a
+time, then will flush and wait for the server to respond. If the
+client has no objects (as in the case of a non-referencing clone),
+it will skip this phase, just send it's 'done' and wait for the
+packfile.
+
+If the server reads 'have' lines, it then will respond by ACKing any
+of the obj-ids the client said it had that the server also has. Or,
+once the server has found an acceptable common base commit and is
+ready to make a packfile, it will blindly ACK all 'have' obj-ids back
+to the client. Then it will send a 'NACK' and then wait for
+another response from the client - either a 'done' or another list of
+'have' lines.
+
+In multi-ack mode, the server will respond with 'ACK obj-id continue'
+for common commits, otherwise it will just respond with 'ACK obj-id'
+lines. In multi-ack-detailed mode, it will differentiate the ACKs
+where it is simply signaling that it is ready to send data with
+'ACK obj-id ready' lines, and signals the identified common commits
+with 'ACK obj-id common' lines.
+
+After the client has gotten 'ACK obj-id' responses for all it's
+references, or has sent more than 256 references and decides to give
+up, it will send a 'done' command, which signals to the server that it
+is ready to receive it's packfile data.
+
+Once the 'done' line is read from the client, the server will either
+send a final 'ACK obj-id' line if it is in multi-ack mode and has found
+a common base, or it will send a 'NAK' if it has still not found a common
+base; then the server will start sending it's packfile data.
+
+----
+ server-response = *acks
+ nack
+
+ acks = *ack
+ ack = PKT-LINE("ACK" SP obj-id continue LF)
+ nack = PKT-LINE("NACK" LF)
+----
+
+A simple clone may look like this (with no 'have' statements):
+
+----
+ C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\0multi_ack \
+ side-band-64k ofs-delta\n
+ C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n
+ C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n
+ C: 0032want 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01\n
+ C: 0032want 74730d410fcb6603ace96f1dc55ea6196122532d\n
+ C: 0000
+ C: 0009done\n
+
+ S: 0008NAK\n
+ S: [PACKFILE]
+----
+
+An incremental update (fetch) response might look like this:
+
+----
+ C: 0054want 74730d410fcb6603ace96f1dc55ea6196122532d\0multi_ack \
+ side-band-64k ofs-delta\n
+ C: 0032want 7d1665144a3a975c05f1f43902ddaf084e784dbe\n
+ C: 0032want 5a3f6be755bbb7deae50065988cbfa1ffa9ab68a\n
+ C: 0000
+ C: 0032have 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01\n
+ C: [30 more have lines]
+ C: 0032have 74730d410fcb6603ace96f1dc55ea6196122532d\n
+ C: 0000
+
+ S: 003aACK 7e47fe2bd8d01d481f44d7af0531bd93d3b21c01 continue\n
+ S: 003aACK 74730d410fcb6603ace96f1dc55ea6196122532d continue\n
+ S: 0008NAK\n
+
+ C: 0009done\n
+
+ S: 003aACK 74730d410fcb6603ace96f1dc55ea6196122532d\n
+ S: [PACKFILE]
+----
+
+
+Packfile Data
+-------------
+
+Now that the client and server have done some negotiation about what
+the minimal amount of data that can be sent to the client is, the server
+will construct and send the required data in packfile format.
+
+See pack-format.txt for what the packfile itself actually looks like.
+
+If 'side-band' or 'side-band-64k' capabilities have been specified by
+the client, the server will send the packfile data multiplexed - it
+will be sent in packets of either 1000 bytes or 64k, depending on which
+sideband type was specified, with each packet starting with the packet-line
+format of the amount of data that follows, followed by a single byte
+specifying the sideband the following data is coming in on.
+
+The sideband byte will be either a '1' or a '2'. Sideband '1' will contain
+packfile data, sideband '2' will be used for progress information that the
+client will generally print to stderr.
+
+If no 'side-band' capability was specified, the server will simply
+stream the entire packfile.
+
+
+Pushing Data To a Server
+========================
+
+Pushing data to a server will invoke the 'receive-pack' process on the
+server, which will allow the client to tell it which references it should
+update and then send all the data the server will need for those new
+references to be complete. Once all the data is received and validated,
+the server will then update it's references to what the client specified.
+
+Authentication
+--------------
+
+The protocol itself contains no authentication mechanisms. That is to be
+handled by the transport, such as SSH, before the 'receive-pack' process is
+invoked. If 'receive-pack' is configured over the Git transport, those
+repositories will be writable by anyone who can access that port (9418) as
+that transport is unauthenticated.
+
+Reference Discovery
+-------------------
+
+The reference discovery phase is done nearly the same way as it is in the
+fetching protocol. Each reference obj-id and name on the server is sent
+in packet-line format to the client, followed by a flush packet. The only
+real difference is that the capability listing is different - the only
+possible values are 'report-status', 'delete-refs' and 'ofs-delta', and
+instead of following a null byte, the capabilities follow a space.
+
+----
+ advertised-refs = (no-refs / list-of-refs)
+ flush-pkt
+
+ no-refs = PKT-LINE(zero-id SP "capabilities^{}"
+ NUL capability-list LF)
+
+ list-of-refs = first-ref *other-ref
+ first-ref = PKT-LINE(obj-id SP refname
+ SP capability-list LF)
+
+ other-ref = PKT-LINE(other-tip / other-peeled)
+ other-tip = obj-id SP refname LF
+ other-peeled = obj-id SP refname "^{}" LF
+
+ capability-list = capability *(SP capability)
+ capability = 1*(ALPHA / DIGIT / "-" / "_")
+----
+
+Reference Update Request and Packfile Transfer
+----------------------------------------------
+
+Once the client knows what references the server is at, it can send a
+list of reference update requests. For each reference on the server
+that it wants to update, it sends a line listing the obj-id currently on
+the server, the obj-id the client would like to update it to and the name
+of the reference.
+
+This list is followed by a flush packet and then the packfile that should
+contain all the objects that the server will need to complete the new
+references.
+
+----
+ update-request = command-list pack-file
+
+ command-list = PKT-LINE(command NUL capability-list LF)
+ *PKT-LINE(command LF)
+ flush-pkt
+
+ command = create / delete / update
+ create = zero-id SP new-id SP name
+ delete = old-id SP zero-id SP name
+ update = old-id SP new-id SP name
+
+ old-id = obj-id
+ new-id = obj-id
+
+ pack-file = "PACK" 24*(OCTET)
+----
+
+The server will receive the packfile, unpack it, then validate each
+reference that is being updated that it hasn't changed while the request
+was being processed (the obj-id is still the same as the old-id), and
+it will run any update hooks to make sure that the update is acceptable.
+If all of that is fine, the server will then update the references.
+
+Report Status
+-------------
+
+If the 'report-status' capability is sent by the client, then the server
+will send a short report of what happened in that update. It will first
+list the status of the packfile unpacking as either 'unpack ok' or
+'unpack [error]'. Then it will list the status for each of the references
+that it tried to update. Each line be either 'ok [refname]' if the
+update was successful, or 'ng [refname] [error]' if the update was not.
+
+----
+ report-status = unpack-status
+ 1*(command-status)
+ flush-pkt
+
+ unpack-status = PKT-LINE("unpack" SP unpack-result LF)
+ unpack-result = "ok" / error-msg
+
+ command-status = command-ok / command-fail
+ command-ok = PKT-LINE("ok" SP refname LF)
+ command-fail = PKT-LINE("ng" SP refname SP error-msg LF)
+
+ error-msg = 1*(OCTECT) ; where not "ok"
+----
+
+Updates can be unsuccessful for a number of reasons. The reference can have
+changed since the reference discovery phase was originally sent, meaning
+someone pushed in the meantime. The reference being pushed could be a
+non-fast-forward reference and the update hooks or configuration could be
+set to not allow that, etc. Also, some references can be updated while others
+can be rejected.
+
+An example client/server communication might look like this:
+
+----
+ S: 007c74730d410fcb6603ace96f1dc55ea6196122532d HEAD report-status
delete-refs ofs-delta\n
+ S: 003e7d1665144a3a975c05f1f43902ddaf084e784dbe refs/heads/debug\n
+ S: 003f74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/master\n
+ S: 003f74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/team\n
+ S: 0000
+
+ C: 003e7d1665144a3a975c05f1f43902ddaf084e784dbe
74730d410fcb6603ace96f1dc55ea6196122532d refs/heads/debug\n
+ C: 003e74730d410fcb6603ace96f1dc55ea6196122532d
5a3f6be755bbb7deae50065988cbfa1ffa9ab68a refs/heads/master\n
+ C: 0000
+ C: [PACKDATA]
+
+ S: 000aunpack ok\n
+ S: 000aok refs/heads/debug\n
+ S: 000ang refs/heads/master non-fast-forward\n
+----
+
diff --git a/Documentation/technical/protocol-capabilities.txt
b/Documentation/technical/protocol-capabilities.txt
new file mode 100644
index 0000000..dad7d16
--- /dev/null
+++ b/Documentation/technical/protocol-capabilities.txt
@@ -0,0 +1,146 @@
+Git Protocol Capabilities
+=========================
+
+On the very first line of the initial server response, the first
+reference is followed by a null byte and then a list of space
+delimited server capabilities. These allow the server to declare
+what it can and cannot do to the client.
+
+Client sends space separated list of capabilities it wants. It
+SHOULD send a subset of server capabilities, i.e do not send
+capabilities served does not advertise. The client SHOULD NOT ask
+for capabilities the server did not say it supports.
+
+Server MUST ignore capabilities it does not understand. Server MUST
+NOT ignore capabilities that client requested and server advertised.
+
+multi-ack
+---------
+
+The 'multi-ack' capability allows the server to return "ACK $SHA1
+continue" as soon as it finds a commit that it can use as a common
+base, between the client's wants and the client's have set.
+
+By sending this early, the server can potentially head off the client
+from walking any further down that particular branch of the client's
+repository history. The client may still need to walk down other
+branches, sending have lines for those, until the server has a
+complete cut across the DAG, or the client has said "done".
+
+Without multi_ack, a client sends have lines in --date-order until
+the server has found a common base. That means the client will send
+have lines that are already known by the server to be common, because
+they overlap in time with another branch that the server hasn't found
+a common base on yet.
+
+The client has things in caps that the server doesn't; server has
+things in lower case.
+
+ +---- u ---------------------- x
+ / +----- y
+ / /
+ a -- b -- c -- d -- E -- F
+ \
+ +--- Q -- R -- S
+
+If the client wants x,y and starts out by saying have F,S, the server
+doesn't know what F,S is. Eventually the client says "have d" and
+the server sends "ACK d continue" to let the client know to stop
+walking down that line (so don't send c-b-a), but its not done yet,
+it needs a base for X. The client keeps going with S-R-Q, until a
+gets reached, at which point the server has a clear base and it all
+ends.
+
+Without multi_ack the client would have sent that c-b-a chain anyway,
+interleaved with S-R-Q.
+
+thin-pack
+---------
+
+Server can send thin packs, i.e. packs which do not contain base
+elements, if those base elements are available on clients side.
+Client requests thin-pack capability when it understands how to "thicken"
+them adding required delta bases making them independent.
+
+Client MUST NOT request 'thin-pack' capability if it
+cannot turn thin packs into proper independent packs.
+
+
+side-band, side-band-64k
+------------------------
+
+This means that server can send, and client understand multiplexed
+(muxed) progress reports and error info interleaved with the packfile
+itself.
+
+These two options are mutually exclusive. A client should ask for
+only one of them, and a modern client always favors side-band-64k.
+
+The 'side-band' capability allows up to 1000 bytes per packet. But
+the packet length field is 4 bytes, in hex, so 16 bits worth of
+information space. Limiting it to only 1000 bytes for a large 800
+MiB binary pack file on initial clone is really quite poor usage of
+the data stream space.
+
+The "side-band-64k" capability came about as a way for newer clients
+that can handle much larger packets to request packets that are
+actually crammed nearly full (65520 bytes), while maintaining
+backward compatibility for the older clients.
+
+The client MUST send only maximum of one of "side-band" and "side-
+band-64k". Server MUST favor side-band-64k if client requests both.
+
+ofs-delta
+---------
+
+Server can send, and client understand PACKv2 with delta refering to
+its base by position in pack rather than by SHA-1. Its that they can
+send/read OBJ_OFS_DELTA, aka type 6 in a pack file.
+
+shallow
+-------
+
+Server can send shallow clone (git clone --depth ...).
+
+no-progress
+-----------
+
+The client was started with "git clone -q" or something, and doesn't
+want that side brand 2. Basically the client just says "I do not
+wish to receive stream 2 on sideband, so do not send it to me, and if
+you did, I will drop it on the floor anyway". However, the sideband
+channel 3 is still used for error responses.
+
+include-tag
+-----------
+
+The 'include-tag' capability is about sending tags if we are sending
+objects they point to. If we pack an object to the client, and a tag
+points exactly at that object, we pack the tag too. In general this
+allows a client to get all new tags when it fetches a branch, in a
+single network connection.
+
+Clients MAY always send include-tag, hardcoding it into a request.
+The decision for a client to request include-tag only has to do with
+the client's desires for tag data, whether or not a server had
+advertised objects in the refs/tags/* namespace.
+
+Clients SHOULD NOT send include-tag if remote.name.tagopt was set to
+--no-tags, as the client doesn't want tag data.
+
+Servers MUST accept include-tag without error or warning, even if the
+server does not understand or support the option.
+
+Servers SHOULD pack the tags if their referrant is packed and the
+client has requested include-tag.
+
+Clients MUST be prepared for the case where a server has ignored
+include-tag and has not actually sent tags in the pack. In such
+cases the client SHOULD issue a subsequent fetch to acquire the tags
+that include-tag would have otherwise given the client.
+
+The server SHOULD send include-tag, if it supports it, irregardless
+of whether or not there are tags available.
+
+Servers SHOULD support all capabilities defined in this document.
+
diff --git a/Documentation/technical/protocol-common.txt
b/Documentation/technical/protocol-common.txt
new file mode 100644
index 0000000..d28ad98
--- /dev/null
+++ b/Documentation/technical/protocol-common.txt
@@ -0,0 +1,97 @@
+Documentation Common to Pack and Http Protocols
+===============================================
+
+ABNF Notation
+-------------
+
+ABNF notation as described by RFC 5234 is used within the protocol documents,
+except the following replacement core rules are used:
+----
+ HEXDIG = DIGIT / "a" / "b" / "c" / "d" / "e" / "f"
+----
+
+We also define the following common rules:
+----
+ NUL = %x00
+ zero-id = 40*"0"
+ obj-id = 40*(HEXDIGIT)
+
+ refname = "HEAD"
+ refname /= "refs/" <see discussion below>
+----
+
+A refname is a hierarichal octet string beginning with "refs/" and
+not violating the 'git-check-ref-format' command's validation rules.
+More generally, they:
+
+. They can include slash `/` for hierarchical (directory)
+ grouping, but no slash-separated component can begin with a
+ dot `.`.
+
+. They must contain at least one `/`. This enforces the presence of a
+ category like `heads/`, `tags/` etc. but the actual names are not
+ restricted.
+
+. They cannot have two consecutive dots `..` anywhere.
+
+. They cannot have ASCII control characters (i.e. bytes whose
+ values are lower than \040, or \177 `DEL`), space, tilde `~`,
+ caret `{caret}`, colon `:`, question-mark `?`, asterisk `*`,
+ or open bracket `[` anywhere.
+
+. They cannot end with a slash `/` nor a dot `.`.
+
+. They cannot end with the sequence `.lock`.
+
+. They cannot contain a sequence `@{`.
+
+. They cannot contain a `\\`.
+
+
+pkt-line Format
+---------------
+
+Much (but not all) of the payload is described around pkt-lines.
+
+A pkt-line is a variable length binary string. The first four bytes
+of the line, the pkt-len, indicates the total length of the line,
+in hexadecimal. The pkt-len includes the 4 bytes used to contain
+the length's hexadecimal representation.
+
+A pkt-line MAY contain binary data, so implementors MUST ensure
+pkt-line parsing/formatting routines are 8-bit clean.
+
+A non-binary line SHOULD BE terminated by an LF, which if present
+MUST be included in the total length.
+
+The maximum length of a pkt-line's data component is 65520 bytes.
+Implementations MUST NOT send pkt-line whose length exceeds 65524
+(65520 bytes of payload + 4 bytes of length data).
+
+Implementations SHOULD NOT send an empty pkt-line ("0004").
+
+A pkt-line with a length field of 0 ("0000"), called a flush-pkt,
+is a special case and MUST be handled differently than an empty
+pkt-line ("0004").
+
+----
+ pkt-line = data-pkt / flush-pkt
+
+ data-pkt = pkt-len pkt-payload
+ pkt-len = 4*(HEXDIG)
+ pkt-payload = (pkt-len - 4)*(OCTET)
+
+ flush-pkt = "0000"
+----
+
+Examples (as C-style strings):
+
+----
+ pkt-line actual value
+ ---------------------------------
+ "0006a\n" "a\n"
+ "0005a" "a"
+ "000bfoobar\n" "foobar\n"
+ "0004" ""
+----
+
--
1.6.5.2.75.gad2f8
^ permalink raw reply related
* Re: [PATCH 7/7] Factor ref updating out of fetch_with_import
From: Daniel Barkalow @ 2009-10-29 17:22 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Shawn O. Pearce, Git List, Johannes Schindelin, Johan Herland
In-Reply-To: <fabb9a1e0910290932u45c9c416m4d0ba0a8b2f5b01d@mail.gmail.com>
[-- Attachment #1: Type: TEXT/PLAIN, Size: 2196 bytes --]
On Thu, 29 Oct 2009, Sverre Rabbelier wrote:
> Heya,
>
> On Thu, Oct 29, 2009 at 08:56, Shawn O. Pearce <spearce@spearce.org> wrote:
> >> > I certainly have to wonder... if this is done in both fetch and
> >> > clone, why isn't it just part of fetch_refs?
> >>
> >> Because clone does not use fetch_refs, or am I missing something?
> >
> > Hmmph. Weird. Its been a while since I last looked at this code,
> > maybe I misunderstood it.
>
> Unless you mean transport_fetch_refs? It can't be done in
> transport_fetch_refs because the foreign helper transport needs to
> update all refs, including those that wanted_peer_refs decided not to
> fetch. Otherwise the 'HEAD' ref will not be updated, and it is left at
> all zeros. It is not as obvious that that is a problem in this patch,
> but when Junio merges with Nico's [5bdc32d3e "make 'git clone' ask the
> remote only for objects it cares about"] the code looks like this:
>
> if (refs) {
> struct ref *ref_cpy;
> mapped_refs = wanted_peer_refs(refs, refspec);
> ref_cpy = copy_ref_list(mapped_refs);
> transport_fetch_refs(transport, ref_cpy);
> if (transport->update_refs)
> {
> ref_cpy = copy_ref_list(refs);
> transport->update_refs(transport, ref_cpy);
> refs = ref_cpy;
> mapped_refs = wanted_peer_refs(refs, refspec);
> }
> }
>
> Does it make more sense now? transport_fetch_refs gets only a limited
> view of the refs, so it cannot pass all the refs to
> transport_update_refs as needed.
I think there are a bunch of bugs that you're working around:
(a) if HEAD is determined to be a symref, and we care about HEAD, we care
about whatever HEAD is a symref to; wanted_peer_refs() shouldn't be
filtering such things out.
(b) we don't want to make a whole bunch of copies of the ref list to avoid
updating the mutable ref list that we will look for updated values in; the
merge of my series with Nico's should replace my copy_ref_list with his
wanted_peer_refs, not include the copy afterwards. Correcting this should
lead to the value that matters in the list that will be used having been
updated directly by transport_fetch_refs().
-Daniel
*This .sig left intentionally blank*
^ permalink raw reply
* [PATCH] Documentation/gitk.txt: order options alphabetically
From: jari.aalto @ 2009-10-29 16:59 UTC (permalink / raw)
To: git; +Cc: Jari Aalto
From: Jari Aalto <jari.aalto@cante.net>
Signed-off-by: Jari Aalto <jari.aalto@cante.net>
---
Documentation/gitk.txt | 38 +++++++++++++++++++-------------------
1 files changed, 19 insertions(+), 19 deletions(-)
diff --git a/Documentation/gitk.txt b/Documentation/gitk.txt
index cf465cb..08ff926 100644
--- a/Documentation/gitk.txt
+++ b/Documentation/gitk.txt
@@ -26,23 +26,17 @@ the 'git-rev-list' command (see linkgit:git-rev-list[1]).
This manual page describes only the most
frequently used options.
--n <number>::
---max-count=<number>::
-
- Limits the number of commits to show.
-
---since=<date>::
-
- Show commits more recent than a specific date.
-
---until=<date>::
-
- Show commits older than a specific date.
-
--all::
Show all branches.
+--argscmd=<command>::
+ Command to be run each time gitk has to determine the list of
+ <revs> to show. The command is expected to print on its standard
+ output a list of additional revs to be shown, one per line.
+ Use this instead of explicitly specifying <revs> if the set of
+ commits to show may vary between refreshes.
+
--merge::
After an attempt to merge stops with conflicts, show the commits on
@@ -50,18 +44,24 @@ frequently used options.
that modify the conflicted files and do not exist on all the heads
being merged.
---argscmd=<command>::
- Command to be run each time gitk has to determine the list of
- <revs> to show. The command is expected to print on its standard
- output a list of additional revs to be shown, one per line.
- Use this instead of explicitly specifying <revs> if the set of
- commits to show may vary between refreshes.
+-n <number>::
+--max-count=<number>::
+
+ Limits the number of commits to show.
--select-commit=<ref>::
Automatically select the specified commit after loading the graph.
Default behavior is equivalent to specifying '--select-commit=HEAD'.
+--since=<date>::
+
+ Show commits more recent than a specific date.
+
+--until=<date>::
+
+ Show commits older than a specific date.
+
<revs>::
Limit the revisions to show. This can be either a single revision
--
1.6.5
^ permalink raw reply related
* Re: date change of commit?
From: Thomas Rast @ 2009-10-29 16:43 UTC (permalink / raw)
To: Rogan Dawes; +Cc: Alex K, Miklos Vajna, Matthieu Moy, git
In-Reply-To: <4AE9AAE7.2080404@dawes.za.net>
Rogan Dawes wrote:
> Alex K wrote:
> > And how do you actually set those variables? Sorry to ask such a
> > trivial question but it's been an hour that i'm going through the doc
> > for such a simple feature. I thought those were environment variables
>
> As you suspected, they are environment variables.
>
> i.e. :
>
> $ GIT_AUTHOR_DATE="1112911993 -0700" git commit x
Since this was in the context of git-filter-branch, I should point out
that you'll have to use the variables with --env-filter and (like the
manpage says) make sure you export them.
So to change the date of a single commit with SHA1 <sha1>, you could
say
git filter-branch --env-filter '
if [ $GIT_COMMIT = <sha1> ]; then
export GIT_AUTHOR_DATE="1112911993 -0700"
export GIT_COMMITTER_DATE="1112911993 -0700"
fi
' <other_arguments>
Alex K wrote:
> for such a simple feature
I'm not sure if you're referring to setting the variables or actually
rewriting the commits here, but anyway:
The reason why the latter is so hard is that rewriting "old" history
is a _huge_ hassle for people who already have the previous version of
that history.
That being said, _why_? The dates are never a guarantee that
something happened earlier or later precisely because they can easily
be modified at commit time. So nobody should take them as more than a
hint, and there's little use in faking hints.
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH 1/2] Provide a build time default-pager setting
From: Ben Walton @ 2009-10-29 16:42 UTC (permalink / raw)
To: gitster, jrnieder, git; +Cc: Ben Walton
In-Reply-To: <1256834565-19443-1-git-send-email-bwalton@artsci.utoronto.ca>
From: Junio C Hamano <gitster@pobox.com>
On (old) solaris systems, /usr/bin/less (typically the first less
found) doesn't understand the default arguments (FXRS), which
forces users to alter their environment (PATH, GIT_PAGER, LESS,
etc) or have a local or global gitconfig before paging works as
expected.
On Debian systems, by policy packages must fall back to the
'pager' command, so that changing the target of the
/usr/bin/pager symlink changes the default pager for all packages
at once.
Provide a DEFAULT_PAGER knob so packagers can set the fallback
pager to something appropriate during the build.
This puts the "less" default in the Makefile instead of pager.c, since
it is needed for git-svn and git-am, too. This means that the
DEFAULT_PAGER preprocessor token _has_ to be defined on the command
line for git to build. I was worried about this for a moment, but
GIT_VERSION already works this way without trouble.
Probably the DEFAULT_PAGER setting should be added to something
like TRACK_CFLAGS as well. Actually, some other settings that
can change without forcing files to be rebuilt (e.g. SHELL_PATH),
too. This should be probably be addressed separately.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
Signed-off-by: Ben Walton <bwalton@artsci.utoronto.ca>
---
Makefile | 9 +++++++++
git-am.sh | 2 +-
git-svn.perl | 5 +++--
| 2 +-
4 files changed, 14 insertions(+), 4 deletions(-)
diff --git a/Makefile b/Makefile
index 42b7d60..1d26800 100644
--- a/Makefile
+++ b/Makefile
@@ -200,6 +200,9 @@ all::
# memory allocators with the nedmalloc allocator written by Niall Douglas.
#
# Define NO_REGEX if you have no or inferior regex support in your C library.
+#
+# Define DEFAULT_PAGER to the path of a sensible pager (defaults to "less") if
+# you want to use something different.
GIT-VERSION-FILE: .FORCE-GIT-VERSION-FILE
@$(SHELL_PATH) ./GIT-VERSION-GEN
@@ -1294,6 +1297,10 @@ ifdef NO_REGEX
COMPAT_CFLAGS += -Icompat/regex
COMPAT_OBJS += compat/regex/regex.o
endif
+ifndef DEFAULT_PAGER
+ DEFAULT_PAGER = less
+endif
+BASIC_CFLAGS += -DDEFAULT_PAGER='"$(DEFAULT_PAGER)"'
ifdef USE_NED_ALLOCATOR
COMPAT_CFLAGS += -DUSE_NED_ALLOCATOR -DOVERRIDE_STRDUP -DNDEBUG -DREPLACE_SYSTEM_ALLOCATOR -Icompat/nedmalloc
@@ -1428,6 +1435,7 @@ $(patsubst %.sh,%,$(SCRIPT_SH)) : % : %.sh
-e 's|@SHELL_PATH@|$(SHELL_PATH_SQ)|' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
-e 's/@@NO_CURL@@/$(NO_CURL)/g' \
+ -e 's|@@DEFAULT_PAGER@@|$(DEFAULT_PAGER)|g' \
-e $(BROKEN_PATH_FIX) \
$@.sh >$@+ && \
chmod +x $@+ && \
@@ -1451,6 +1459,7 @@ $(patsubst %.perl,%,$(SCRIPT_PERL)): % : %.perl
-e '}' \
-e 's|@@INSTLIBDIR@@|'"$$INSTLIBDIR"'|g' \
-e 's/@@GIT_VERSION@@/$(GIT_VERSION)/g' \
+ -e 's|@@DEFAULT_PAGER@@|$(DEFAULT_PAGER)|g' \
$@.perl >$@+ && \
chmod +x $@+ && \
mv $@+ $@
diff --git a/git-am.sh b/git-am.sh
index c132f50..a194a4e 100755
--- a/git-am.sh
+++ b/git-am.sh
@@ -649,7 +649,7 @@ do
[eE]*) git_editor "$dotest/final-commit"
action=again ;;
[vV]*) action=again
- LESS=-S ${PAGER:-less} "$dotest/patch" ;;
+ LESS=-S ${PAGER:-@@DEFAULT_PAGER@@} "$dotest/patch" ;;
*) action=again ;;
esac
done
diff --git a/git-svn.perl b/git-svn.perl
index eb4b75a..a61ec55 100755
--- a/git-svn.perl
+++ b/git-svn.perl
@@ -3,11 +3,12 @@
# License: GPL v2 or later
use warnings;
use strict;
-use vars qw/ $AUTHOR $VERSION
+use vars qw/ $AUTHOR $VERSION $DEFAULT_PAGER
$sha1 $sha1_short $_revision $_repository
$_q $_authors $_authors_prog %users/;
$AUTHOR = 'Eric Wong <normalperson@yhbt.net>';
$VERSION = '@@GIT_VERSION@@';
+$DEFAULT_PAGER = '@@DEFAULT_PAGER@@';
# From which subdir have we been invoked?
my $cmd_dir_prefix = eval {
@@ -5031,7 +5032,7 @@ sub git_svn_log_cmd {
sub config_pager {
$pager ||= $ENV{GIT_PAGER} || $ENV{PAGER};
if (!defined $pager) {
- $pager = 'less';
+ $pager = $DEFAULT_PAGER;
} elsif (length $pager == 0 || $pager eq 'cat') {
$pager = undef;
}
--git a/pager.c b/pager.c
index 86facec..416a796 100644
--- a/pager.c
+++ b/pager.c
@@ -58,7 +58,7 @@ void setup_pager(void)
if (!pager)
pager = getenv("PAGER");
if (!pager)
- pager = "less";
+ pager = DEFAULT_PAGER;
else if (!*pager || !strcmp(pager, "cat"))
return;
--
1.6.5
^ permalink raw reply related
* [PATCH 0/2] Default Pager and Editor at build-time
From: Ben Walton @ 2009-10-29 16:42 UTC (permalink / raw)
To: gitster, jrnieder, git; +Cc: Ben Walton
In-Reply-To: <20091029073224.GA15403@progeny.tock>
The two patches look ok to me (not withstanding the comments already
made about the test and possible future changes required).
I did make a few small tweaks to use | instead of / as the sed
substitution separator (since we're presumably working with full
paths). The substitution was also extended into the .sh scripts
(git-am, explicitly).
Jonathan Nieder (1):
Provide a build time default-editor setting
Junio C Hamano (1):
Provide a build time default-pager setting
Makefile | 19 +++++++++++++++++++
editor.c | 2 +-
git-add--interactive.perl | 3 ++-
git-am.sh | 2 +-
git-sh-setup.sh | 6 ++++--
git-svn.perl | 8 +++++---
pager.c | 2 +-
t/Makefile | 2 ++
t/t7005-editor.sh | 29 ++++++++++++++++++++++-------
9 files changed, 57 insertions(+), 16 deletions(-)
^ permalink raw reply
* Re: [PATCH 7/7] Factor ref updating out of fetch_with_import
From: Sverre Rabbelier @ 2009-10-29 16:32 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
In-Reply-To: <20091029155607.GA10505@spearce.org>
Heya,
On Thu, Oct 29, 2009 at 08:56, Shawn O. Pearce <spearce@spearce.org> wrote:
>> > I certainly have to wonder... if this is done in both fetch and
>> > clone, why isn't it just part of fetch_refs?
>>
>> Because clone does not use fetch_refs, or am I missing something?
>
> Hmmph. Weird. Its been a while since I last looked at this code,
> maybe I misunderstood it.
Unless you mean transport_fetch_refs? It can't be done in
transport_fetch_refs because the foreign helper transport needs to
update all refs, including those that wanted_peer_refs decided not to
fetch. Otherwise the 'HEAD' ref will not be updated, and it is left at
all zeros. It is not as obvious that that is a problem in this patch,
but when Junio merges with Nico's [5bdc32d3e "make 'git clone' ask the
remote only for objects it cares about"] the code looks like this:
if (refs) {
struct ref *ref_cpy;
mapped_refs = wanted_peer_refs(refs, refspec);
ref_cpy = copy_ref_list(mapped_refs);
transport_fetch_refs(transport, ref_cpy);
if (transport->update_refs)
{
ref_cpy = copy_ref_list(refs);
transport->update_refs(transport, ref_cpy);
refs = ref_cpy;
mapped_refs = wanted_peer_refs(refs, refspec);
}
}
Does it make more sense now? transport_fetch_refs gets only a limited
view of the refs, so it cannot pass all the refs to
transport_update_refs as needed.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH] diff --color-words -U0: fix the location of hunk headers
From: Markus Heidelberg @ 2009-10-29 16:29 UTC (permalink / raw)
To: Johannes Schindelin; +Cc: Junio C Hamano, git
In-Reply-To: <alpine.DEB.1.00.0910291425010.3687@felix-maschine>
Johannes Schindelin, 29.10.2009:
> Hi,
>
> On Thu, 29 Oct 2009, Markus Heidelberg wrote:
>
> > Indeed my initial fix was in the same fashion:
> >
> > @@ -772,6 +772,15 @@ static void fn_out_consume(void *priv, char *line, unsigned long len)
> > }
> >
> > if (line[0] == '@') {
> > + if (ecbdata->diff_words) {
> > + /*
> > + * The content of the previous hunk, necessary for
> > + * 0-context.
> > + */
> > + if (ecbdata->diff_words->minus.text.size ||
> > + ecbdata->diff_words->plus.text.size)
> > + diff_words_show(ecbdata->diff_words);
> > + }
> > len = sane_truncate_line(ecbdata, line, len);
> > find_lno(line, ecbdata);
> > emit_line(ecbdata->file,
> >
> > But then I thought I should not put the diff output from --color-words
> > into the block that deals with the hunk header, but save another place
> > where diff_words_show() is called.
>
> I found this paragraph, as well as the patches 2/3 and 3/3, hard to
> follow.
I try to reword:
With 2/3 and 3/3 I wanted to keep --color-words specific code in the
block starting with
if (ecbdata->diff_words) {
and didn't want to contaminate the block starting with
if (line[0] == '@') {
with non-hunk-header content.
But I'm not sure what's the better way and am content with either.
> And besides, flushing in that block is the correct thing to do. The
> function diff_words_show() is a function for that exact purpose.
Yes, 2/3 and 3/3 just don't introduce a new invocation of this function
at another place in the code.
Markus
^ permalink raw reply
* Re: [PATCH] gitk: Add Japanese translation
From: Mizar @ 2009-10-29 16:22 UTC (permalink / raw)
To: git, Paul Mackerras, Junio C Hamano
In-Reply-To: <d092a4360910280514l3658ebd9od0b0169ddba67056@mail.gmail.com>
The following is a change from last time.
==== patch0.patch
diff --git a/po/ja.po b/po/ja.po
index dbc83b9..53b379d 100644
--- a/po/ja.po
+++ b/po/ja.po
@@ -245,11 +245,11 @@ msgstr "ツリー"
#: gitk:2361 gitk:2378
msgid "Diff this -> selected"
-msgstr "diff これ -> 選択"
+msgstr "これと選択したコミットのdiffを見る"
#: gitk:2362 gitk:2379
msgid "Diff selected -> this"
-msgstr "diff 選択 -> これ"
+msgstr "選択したコミットとこれのdiffを見る"
#: gitk:2363 gitk:2380
msgid "Make patch"
@@ -788,7 +788,7 @@ msgstr "SHA1 ID:"
#: gitk:7915
#, tcl-format
msgid "Short SHA1 id %s is ambiguous"
-msgstr "短縮 SHA1 ID %s は曖昧です"
+msgstr "%s を含む SHA1 ID は複数存在します"
#: gitk:7922
#, tcl-format
@@ -1040,7 +1040,7 @@ msgid ""
"The commits on branch %s aren't on any other branch.\n"
"Really delete branch %s?"
msgstr ""
-"ブランチ %s 上のコミットは他のブランチに存在しません。\n"
+"ブランチ %s には他のブランチに存在しないコミットがあります。\n"
"本当にブランチ %s を削除しますか？"
#: gitk:8983
@@ -1220,7 +1220,7 @@ msgid ""
" Gitk requires at least Tcl/Tk 8.4."
msgstr ""
"申し訳ありませんが、このバージョンの Tcl/Tk では gitk を実行できません。\n"
-" Gitk は少なくとも Tcl/Tk 8.4 を必要とします。"
+" Gitk は最低でも Tcl/Tk 8.4 を必要とします。"
#: gitk:11137
msgid "Cannot find a git repository here."
==== cut
The following are all the changes.
==== patch1.patch
diff --git a/po/ja.po b/po/ja.po
new file mode 100644
index 0000000..53b379d
--- /dev/null
+++ b/po/ja.po
@@ -0,0 +1,1245 @@
+# Japanese translations for gitk package.
+# Copyright (C) 2005-2009 Paul Mackerras
+# This file is distributed under the same license as the gitk package.
+#
+# Mizar <mizar.jp@gmail.com>, 2009.
+# Junio C Hamano <gitster@pobox.com>, 2009.
+msgid ""
+msgstr ""
+"Project-Id-Version: gitk\n"
+"Report-Msgid-Bugs-To: \n"
+"POT-Creation-Date: 2009-10-19 02:45+0900\n"
+"PO-Revision-Date: 2009-10-19 17:03+0900\n"
+"Last-Translator: Mizar <mizar.jp@gmail.com>\n"
+"Language-Team: Japanese\n"
+"MIME-Version: 1.0\n"
+"Content-Type: text/plain; charset=UTF-8\n"
+"Content-Transfer-Encoding: 8bit\n"
+"Plural-Forms: nplurals=1; plural=0;\n"
+
+#: gitk:113
+msgid "Couldn't get list of unmerged files:"
+msgstr "マージされていないファイルのリストを取得できません:"
+
+#: gitk:269
+msgid "Error parsing revisions:"
+msgstr "リビジョン解析エラー:"
+
+#: gitk:324
+msgid "Error executing --argscmd command:"
+msgstr "--argscmd コマンド実行エラー:"
+
+#: gitk:337
+msgid "No files selected: --merge specified but no files are unmerged."
+msgstr "ファイル未選択: --merge が指定されましたが、マージされていないファイルはありません。"
+
+#: gitk:340
+msgid ""
+"No files selected: --merge specified but no unmerged files are within file "
+"limit."
+msgstr "ファイル未選択: --merge が指定されましたが、"
+"ファイル制限内にマージされていないファイルはありません。"
+
+#: gitk:362 gitk:509
+msgid "Error executing git log:"
+msgstr "git log 実行エラー:"
+
+#: gitk:380 gitk:525
+msgid "Reading"
+msgstr "読み込み中"
+
+#: gitk:440 gitk:4131
+msgid "Reading commits..."
+msgstr "コミット読み込み中..."
+
+#: gitk:443 gitk:1561 gitk:4134
+msgid "No commits selected"
+msgstr "コミットが選択されていません"
+
+#: gitk:1437
+msgid "Can't parse git log output:"
+msgstr "git log の出力を解析できません:"
+
+#: gitk:1657
+msgid "No commit information available"
+msgstr "有効なコミットの情報がありません"
+
+#: gitk:1793 gitk:1817 gitk:3924 gitk:8822 gitk:10358 gitk:10534
+msgid "OK"
+msgstr "OK"
+
+#: gitk:1819 gitk:3926 gitk:8419 gitk:8493 gitk:8603 gitk:8652 gitk:8824
+#: gitk:10359 gitk:10535
+msgid "Cancel"
+msgstr "キャンセル"
+
+#: gitk:1919
+msgid "Update"
+msgstr "更新"
+
+#: gitk:1920
+msgid "Reload"
+msgstr "リロード"
+
+#: gitk:1921
+msgid "Reread references"
+msgstr "リファレンスを再読み込み"
+
+#: gitk:1922
+msgid "List references"
+msgstr "リファレンスリストを表示"
+
+#: gitk:1924
+msgid "Start git gui"
+msgstr "git gui の開始"
+
+#: gitk:1926
+msgid "Quit"
+msgstr "終了"
+
+#: gitk:1918
+msgid "File"
+msgstr "ファイル"
+
+#: gitk:1930
+msgid "Preferences"
+msgstr "設定"
+
+#: gitk:1929
+msgid "Edit"
+msgstr "編集"
+
+#: gitk:1934
+msgid "New view..."
+msgstr "新規ビュー..."
+
+#: gitk:1935
+msgid "Edit view..."
+msgstr "ビュー編集..."
+
+#: gitk:1936
+msgid "Delete view"
+msgstr "ビュー削除"
+
+#: gitk:1938
+msgid "All files"
+msgstr "全てのファイル"
+
+#: gitk:1933 gitk:3678
+msgid "View"
+msgstr "ビュー"
+
+#: gitk:1943 gitk:1953 gitk:2655
+msgid "About gitk"
+msgstr "gitk について"
+
+#: gitk:1944 gitk:1958
+msgid "Key bindings"
+msgstr "キーバインディング"
+
+#: gitk:1942 gitk:1957
+msgid "Help"
+msgstr "ヘルプ"
+
+#: gitk:2018
+msgid "SHA1 ID: "
+msgstr "SHA1 ID: "
+
+#: gitk:2049
+msgid "Row"
+msgstr "行"
+
+#: gitk:2080
+msgid "Find"
+msgstr "検索"
+
+#: gitk:2081
+msgid "next"
+msgstr "次"
+
+#: gitk:2082
+msgid "prev"
+msgstr "前"
+
+#: gitk:2083
+msgid "commit"
+msgstr "コミット"
+
+#: gitk:2086 gitk:2088 gitk:4292 gitk:4315 gitk:4339 gitk:6280 gitk:6352
+#: gitk:6436
+msgid "containing:"
+msgstr "含む:"
+
+#: gitk:2089 gitk:3163 gitk:3168 gitk:4367
+msgid "touching paths:"
+msgstr "パスの一部:"
+
+#: gitk:2090 gitk:4372
+msgid "adding/removing string:"
+msgstr "追加/除去する文字列:"
+
+#: gitk:2099 gitk:2101
+msgid "Exact"
+msgstr "英字の大小を区別する"
+
+#: gitk:2101 gitk:4447 gitk:6248
+msgid "IgnCase"
+msgstr "英字の大小を区別しない"
+
+#: gitk:2101 gitk:4341 gitk:4445 gitk:6244
+msgid "Regexp"
+msgstr "正規表現"
+
+#: gitk:2103 gitk:2104 gitk:4466 gitk:4496 gitk:4503 gitk:6372 gitk:6440
+msgid "All fields"
+msgstr "全ての項目"
+
+#: gitk:2104 gitk:4464 gitk:4496 gitk:6311
+msgid "Headline"
+msgstr "ヘッドライン"
+
+#: gitk:2105 gitk:4464 gitk:6311 gitk:6440 gitk:6874
+msgid "Comments"
+msgstr "コメント"
+
+#: gitk:2105 gitk:4464 gitk:4468 gitk:4503 gitk:6311 gitk:6809 gitk:8071
+#: gitk:8086
+msgid "Author"
+msgstr "作成者"
+
+#: gitk:2105 gitk:4464 gitk:6311 gitk:6811
+msgid "Committer"
+msgstr "コミットした人"
+
+#: gitk:2134
+msgid "Search"
+msgstr "検索"
+
+#: gitk:2141
+msgid "Diff"
+msgstr "Diff"
+
+#: gitk:2143
+msgid "Old version"
+msgstr "旧バージョン"
+
+#: gitk:2145
+msgid "New version"
+msgstr "新バージョン"
+
+#: gitk:2147
+msgid "Lines of context"
+msgstr "文脈行数"
+
+#: gitk:2157
+msgid "Ignore space change"
+msgstr "空白の違いを無視"
+
+#: gitk:2215
+msgid "Patch"
+msgstr "パッチ"
+
+#: gitk:2217
+msgid "Tree"
+msgstr "ツリー"
+
+#: gitk:2361 gitk:2378
+msgid "Diff this -> selected"
+msgstr "これと選択したコミットのdiffを見る"
+
+#: gitk:2362 gitk:2379
+msgid "Diff selected -> this"
+msgstr "選択したコミットとこれのdiffを見る"
+
+#: gitk:2363 gitk:2380
+msgid "Make patch"
+msgstr "パッチ作成"
+
+#: gitk:2364 gitk:8477
+msgid "Create tag"
+msgstr "タグ生成"
+
+#: gitk:2365 gitk:8583
+msgid "Write commit to file"
+msgstr "コミットをファイルに書き込む"
+
+#: gitk:2366 gitk:8640
+msgid "Create new branch"
+msgstr "新規ブランチ生成"
+
+#: gitk:2367
+msgid "Cherry-pick this commit"
+msgstr "このコミットをチェリーピックする"
+
+#: gitk:2368
+msgid "Reset HEAD branch to here"
+msgstr "ブランチのHEADをここにリセットする"
+
+#: gitk:2369
+msgid "Mark this commit"
+msgstr "このコミットにマークをつける"
+
+#: gitk:2370
+msgid "Return to mark"
+msgstr "マークを付けた所に戻る"
+
+#: gitk:2371
+msgid "Find descendant of this and mark"
+msgstr "この子孫を見つけてマークする"
+
+#: gitk:2372
+msgid "Compare with marked commit"
+msgstr "マークを付けたコミットと比較する"
+
+#: gitk:2386
+msgid "Check out this branch"
+msgstr "このブランチをチェックアウトする"
+
+#: gitk:2387
+msgid "Remove this branch"
+msgstr "このブランチを除去する"
+
+#: gitk:2394
+msgid "Highlight this too"
+msgstr "これもハイライトさせる"
+
+#: gitk:2395
+msgid "Highlight this only"
+msgstr "これだけをハイライトさせる"
+
+#: gitk:2396
+msgid "External diff"
+msgstr "外部diffツール"
+
+#: gitk:2397
+msgid "Blame parent commit"
+msgstr "親コミットから blame をかける"
+
+#: gitk:2404
+msgid "Show origin of this line"
+msgstr "この行の出自を表示する"
+
+#: gitk:2405
+msgid "Run git gui blame on this line"
+msgstr "この行に git gui で blame をかける"
+
+#: gitk:2657
+msgid ""
+"\n"
+"Gitk - a commit viewer for git\n"
+"\n"
+"Copyright c 2005-2008 Paul Mackerras\n"
+"\n"
+"Use and redistribute under the terms of the GNU General Public License"
+msgstr ""
+"\n"
+"Gitk - gitコミットビューア\n"
+"\n"
+"Copyright c 2005-2008 Paul Mackerras\n"
+"\n"
+"使用および再配布は GNU General Public License に従ってください"
+
+#: gitk:2665 gitk:2727 gitk:9005
+msgid "Close"
+msgstr "閉じる"
+
+#: gitk:2684
+msgid "Gitk key bindings"
+msgstr "Gitk キーバインディング"
+
+#: gitk:2687
+msgid "Gitk key bindings:"
+msgstr "Gitk キーバインディング:"
+
+#: gitk:2689
+#, tcl-format
+msgid "<%s-Q>\t\tQuit"
+msgstr "<%s-Q>\t\t終了"
+
+#: gitk:2690
+msgid "<Home>\t\tMove to first commit"
+msgstr "<Home>\t\t最初のコミットに移動"
+
+#: gitk:2691
+msgid "<End>\t\tMove to last commit"
+msgstr "<End>\t\t最後のコミットに移動"
+
+#: gitk:2692
+msgid "<Up>, p, i\tMove up one commit"
+msgstr "<Up>, p, i\t一つ上のコミットに移動"
+
+#: gitk:2693
+msgid "<Down>, n, k\tMove down one commit"
+msgstr "<Down>, n, k\t一つ下のコミットに移動"
+
+#: gitk:2694
+msgid "<Left>, z, j\tGo back in history list"
+msgstr "<Left>, z, j\t履歴の前に戻る"
+
+#: gitk:2695
+msgid "<Right>, x, l\tGo forward in history list"
+msgstr "<Right>, x, l\t履歴の次へ進む"
+
+#: gitk:2696
+msgid "<PageUp>\tMove up one page in commit list"
+msgstr "<PageUp>\tコミットリストの一つ上のページに移動"
+
+#: gitk:2697
+msgid "<PageDown>\tMove down one page in commit list"
+msgstr "<PageDown>\tコミットリストの一つ下のページに移動"
+
+#: gitk:2698
+#, tcl-format
+msgid "<%s-Home>\tScroll to top of commit list"
+msgstr "<%s-Home>\tコミットリストの一番上にスクロールする"
+
+#: gitk:2699
+#, tcl-format
+msgid "<%s-End>\tScroll to bottom of commit list"
+msgstr "<%s-End>\tコミットリストの一番下にスクロールする"
+
+#: gitk:2700
+#, tcl-format
+msgid "<%s-Up>\tScroll commit list up one line"
+msgstr "<%s-Up>\tコミットリストの一つ下の行にスクロールする"
+
+#: gitk:2701
+#, tcl-format
+msgid "<%s-Down>\tScroll commit list down one line"
+msgstr "<%s-Down>\tコミットリストの一つ下の行にスクロールする"
+
+#: gitk:2702
+#, tcl-format
+msgid "<%s-PageUp>\tScroll commit list up one page"
+msgstr "<%s-PageUp>\tコミットリストの上のページにスクロールする"
+
+#: gitk:2703
+#, tcl-format
+msgid "<%s-PageDown>\tScroll commit list down one page"
+msgstr "<%s-PageDown>\tコミットリストの下のページにスクロールする"
+
+#: gitk:2704
+msgid "<Shift-Up>\tFind backwards (upwards, later commits)"
+msgstr "<Shift-Up>\t後ろを検索 (上方・後のコミット)"
+
+#: gitk:2705
+msgid "<Shift-Down>\tFind forwards (downwards, earlier commits)"
+msgstr "<Shift-Down>\t前を検索（下方・前のコミット）"
+
+#: gitk:2706
+msgid "<Delete>, b\tScroll diff view up one page"
+msgstr "<Delete>, b\tdiff画面を上のページにスクロールする"
+
+#: gitk:2707
+msgid "<Backspace>\tScroll diff view up one page"
+msgstr "<Backspace>\tdiff画面を上のページにスクロールする"
+
+#: gitk:2708
+msgid "<Space>\t\tScroll diff view down one page"
+msgstr "<Space>\t\tdiff画面を下のページにスクロールする"
+
+#: gitk:2709
+msgid "u\t\tScroll diff view up 18 lines"
+msgstr "u\t\tdiff画面を上に18行スクロールする"
+
+#: gitk:2710
+msgid "d\t\tScroll diff view down 18 lines"
+msgstr "d\t\tdiff画面を下に18行スクロールする"
+
+#: gitk:2711
+#, tcl-format
+msgid "<%s-F>\t\tFind"
+msgstr "<%s-F>\t\t検索"
+
+#: gitk:2712
+#, tcl-format
+msgid "<%s-G>\t\tMove to next find hit"
+msgstr "<%s-G>\t\t次を検索して移動"
+
+#: gitk:2713
+msgid "<Return>\tMove to next find hit"
+msgstr "<Return>\t次を検索して移動"
+
+#: gitk:2714
+msgid "/\t\tFocus the search box"
+msgstr "/\t\t検索ボックスにフォーカス"
+
+#: gitk:2715
+msgid "?\t\tMove to previous find hit"
+msgstr "?\t\t前を検索して移動"
+
+#: gitk:2716
+msgid "f\t\tScroll diff view to next file"
+msgstr "f\t\t次のファイルにdiff画面をスクロールする"
+
+#: gitk:2717
+#, tcl-format
+msgid "<%s-S>\t\tSearch for next hit in diff view"
+msgstr "<%s-S>\t\tdiff画面の次を検索"
+
+#: gitk:2718
+#, tcl-format
+msgid "<%s-R>\t\tSearch for previous hit in diff view"
+msgstr "<%s-R>\t\tdiff画面の前を検索"
+
+#: gitk:2719
+#, tcl-format
+msgid "<%s-KP+>\tIncrease font size"
+msgstr "<%s-KP+>\t文字サイズを拡大"
+
+#: gitk:2720
+#, tcl-format
+msgid "<%s-plus>\tIncrease font size"
+msgstr "<%s-plus>\t文字サイズを拡大"
+
+#: gitk:2721
+#, tcl-format
+msgid "<%s-KP->\tDecrease font size"
+msgstr "<%s-KP->\t文字サイズを縮小"
+
+#: gitk:2722
+#, tcl-format
+msgid "<%s-minus>\tDecrease font size"
+msgstr "<%s-minus>\t文字サイズを縮小"
+
+#: gitk:2723
+msgid "<F5>\t\tUpdate"
+msgstr "<F5>\t\t更新"
+
+#: gitk:3178 gitk:3187
+#, tcl-format
+msgid "Error creating temporary directory %s:"
+msgstr "一時ディレクトリ %s 生成時エラー:"
+
+#: gitk:3200
+#, tcl-format
+msgid "Error getting \"%s\" from %s:"
+msgstr "\"%s\" のエラーが %s に発生:"
+
+#: gitk:3263
+msgid "command failed:"
+msgstr "コマンド失敗:"
+
+#: gitk:3409
+msgid "No such commit"
+msgstr "そのようなコミットはありません"
+
+#: gitk:3423
+msgid "git gui blame: command failed:"
+msgstr "git gui blame: コマンド失敗:"
+
+#: gitk:3454
+#, tcl-format
+msgid "Couldn't read merge head: %s"
+msgstr "マージする HEAD を読み込めません: %s"
+
+#: gitk:3462
+#, tcl-format
+msgid "Error reading index: %s"
+msgstr "インデックス読み込みエラー: %s"
+
+#: gitk:3487
+#, tcl-format
+msgid "Couldn't start git blame: %s"
+msgstr "git blame を始められません: %s"
+
+#: gitk:3490 gitk:6279
+msgid "Searching"
+msgstr "検索中"
+
+#: gitk:3522
+#, tcl-format
+msgid "Error running git blame: %s"
+msgstr "git blame 実行エラー: %s"
+
+#: gitk:3550
+#, tcl-format
+msgid "That line comes from commit %s, which is not in this view"
+msgstr "コミット %s に由来するその行は、このビューに表示されていません"
+
+#: gitk:3564
+msgid "External diff viewer failed:"
+msgstr "外部diffビューアが失敗:"
+
+#: gitk:3682
+msgid "Gitk view definition"
+msgstr "Gitk ビュー定義"
+
+#: gitk:3686
+msgid "Remember this view"
+msgstr "このビューを記憶する"
+
+#: gitk:3687
+msgid "References (space separated list):"
+msgstr "リファレンス（スペース区切りのリスト）:"
+
+#: gitk:3688
+msgid "Branches & tags:"
+msgstr "ブランチ＆タグ:"
+
+#: gitk:3689
+msgid "All refs"
+msgstr "全てのリファレンス"
+
+#: gitk:3690
+msgid "All (local) branches"
+msgstr "全ての（ローカルな）ブランチ"
+
+#: gitk:3691
+msgid "All tags"
+msgstr "全てのタグ"
+
+#: gitk:3692
+msgid "All remote-tracking branches"
+msgstr "全てのリモート追跡ブランチ"
+
+#: gitk:3693
+msgid "Commit Info (regular expressions):"
+msgstr "コミット情報（正規表現）:"
+
+#: gitk:3694
+msgid "Author:"
+msgstr "作成者:"
+
+#: gitk:3695
+msgid "Committer:"
+msgstr "コミットした人:"
+
+#: gitk:3696
+msgid "Commit Message:"
+msgstr "コミットメッセージ:"
+
+#: gitk:3697
+msgid "Matches all Commit Info criteria"
+msgstr "コミット情報の全ての条件に一致"
+
+#: gitk:3698
+msgid "Changes to Files:"
+msgstr "変更したファイル:"
+
+#: gitk:3699
+msgid "Fixed String"
+msgstr "固定文字列"
+
+#: gitk:3700
+msgid "Regular Expression"
+msgstr "正規表現"
+
+#: gitk:3701
+msgid "Search string:"
+msgstr "検索文字列:"
+
+#: gitk:3702
+msgid ""
+"Commit Dates (\"2 weeks ago\", \"2009-03-17 15:27:38\", \"March 17, 2009 "
+"15:27:38\"):"
+msgstr "コミット日時 (\"2 weeks ago\", \"2009-03-17 15:27:38\", \"March 17, 2009 "
+"15:27:38\"):"
+
+#: gitk:3703
+msgid "Since:"
+msgstr "期間の始め:"
+
+#: gitk:3704
+msgid "Until:"
+msgstr "期間の終わり:"
+
+#: gitk:3705
+msgid "Limit and/or skip a number of revisions (positive integer):"
+msgstr "制限・省略するリビジョンの数（正の整数）:"
+
+#: gitk:3706
+msgid "Number to show:"
+msgstr "表示する数:"
+
+#: gitk:3707
+msgid "Number to skip:"
+msgstr "省略する数:"
+
+#: gitk:3708
+msgid "Miscellaneous options:"
+msgstr "その他のオプション:"
+
+#: gitk:3709
+msgid "Strictly sort by date"
+msgstr "厳密に日付順で並び替え"
+
+#: gitk:3710
+msgid "Mark branch sides"
+msgstr "側枝マーク"
+
+#: gitk:3711
+msgid "Limit to first parent"
+msgstr "最初の親に制限"
+
+#: gitk:3712
+msgid "Simple history"
+msgstr "簡易な履歴"
+
+#: gitk:3713
+msgid "Additional arguments to git log:"
+msgstr "git log への追加の引数:"
+
+#: gitk:3714
+msgid "Enter files and directories to include, one per line:"
+msgstr "含まれるファイル・ディレクトリを一行ごとに入力:"
+
+#: gitk:3715
+msgid "Command to generate more commits to include:"
+msgstr "コミット追加コマンド:"
+
+#: gitk:3837
+msgid "Gitk: edit view"
+msgstr "Gitk: ビュー編集"
+
+#: gitk:3845
+msgid "-- criteria for selecting revisions"
+msgstr "― リビジョンの選択条件"
+
+#: gitk:3850
+msgid "View Name:"
+msgstr "ビュー名:"
+
+#: gitk:3925
+msgid "Apply (F5)"
+msgstr "適用 (F5)"
+
+#: gitk:3963
+msgid "Error in commit selection arguments:"
+msgstr "コミット選択引数のエラー:"
+
+#: gitk:4016 gitk:4068 gitk:4516 gitk:4530 gitk:5791 gitk:11232 gitk:11233
+msgid "None"
+msgstr "無し"
+
+#: gitk:4464 gitk:6311 gitk:8073 gitk:8088
+msgid "Date"
+msgstr "日付"
+
+#: gitk:4464 gitk:6311
+msgid "CDate"
+msgstr "作成日"
+
+#: gitk:4613 gitk:4618
+msgid "Descendant"
+msgstr "子孫"
+
+#: gitk:4614
+msgid "Not descendant"
+msgstr "非子孫"
+
+#: gitk:4621 gitk:4626
+msgid "Ancestor"
+msgstr "祖先"
+
+#: gitk:4622
+msgid "Not ancestor"
+msgstr "非祖先"
+
+#: gitk:4912
+msgid "Local changes checked in to index but not committed"
+msgstr "ステージされた、コミット前のローカルな変更"
+
+#: gitk:4948
+msgid "Local uncommitted changes, not checked in to index"
+msgstr "ステージされていない、コミット前のローカルな変更"
+
+#: gitk:6629
+msgid "many"
+msgstr "多数"
+
+#: gitk:6813
+msgid "Tags:"
+msgstr "タグ:"
+
+#: gitk:6830 gitk:6836 gitk:8066
+msgid "Parent"
+msgstr "親"
+
+#: gitk:6841
+msgid "Child"
+msgstr "子"
+
+#: gitk:6850
+msgid "Branch"
+msgstr "ブランチ"
+
+#: gitk:6853
+msgid "Follows"
+msgstr "下位"
+
+#: gitk:6856
+msgid "Precedes"
+msgstr "上位"
+
+#: gitk:7354
+#, tcl-format
+msgid "Error getting diffs: %s"
+msgstr "diff取得エラー: %s"
+
+#: gitk:7894
+msgid "Goto:"
+msgstr "Goto:"
+
+#: gitk:7896
+msgid "SHA1 ID:"
+msgstr "SHA1 ID:"
+
+#: gitk:7915
+#, tcl-format
+msgid "Short SHA1 id %s is ambiguous"
+msgstr "%s を含む SHA1 ID は複数存在します"
+
+#: gitk:7922
+#, tcl-format
+msgid "Revision %s is not known"
+msgstr "リビジョン %s は不明です"
+
+#: gitk:7932
+#, tcl-format
+msgid "SHA1 id %s is not known"
+msgstr "SHA1 id %s は不明です"
+
+#: gitk:7934
+#, tcl-format
+msgid "Revision %s is not in the current view"
+msgstr "リビジョン %s は現在のビューにはありません"
+
+#: gitk:8076
+msgid "Children"
+msgstr "子供達"
+
+#: gitk:8133
+#, tcl-format
+msgid "Reset %s branch to here"
+msgstr "%s ブランチをここにリセットする"
+
+#: gitk:8135
+msgid "Detached head: can't reset"
+msgstr "切り離されたHEAD: リセットできません"
+
+#: gitk:8244 gitk:8250
+msgid "Skipping merge commit "
+msgstr "コミットマージをスキップ: "
+
+#: gitk:8259 gitk:8264
+msgid "Error getting patch ID for "
+msgstr "パッチ取得エラー: ID "
+
+#: gitk:8260 gitk:8265
+msgid " - stopping\n"
+msgstr " - 停止\n"
+
+#: gitk:8270 gitk:8273 gitk:8281 gitk:8294 gitk:8303
+msgid "Commit "
+msgstr "コミット "
+
+#: gitk:8274
+msgid ""
+" is the same patch as\n"
+" "
+msgstr ""
+" は下記のパッチと同等\n"
+" "
+
+#: gitk:8282
+msgid ""
+" differs from\n"
+" "
+msgstr ""
+" 下記からのdiff\n"
+" "
+
+#: gitk:8284
+msgid ""
+"Diff of commits:\n"
+"\n"
+msgstr ""
+"コミットのdiff:\n"
+"\n"
+
+#: gitk:8295 gitk:8304
+#, tcl-format
+msgid " has %s children - stopping\n"
+msgstr " には %s の子があります - 停止\n"
+
+#: gitk:8324
+#, tcl-format
+msgid "Error writing commit to file: %s"
+msgstr "ファイルへのコミット書き込みエラー: %s"
+
+#: gitk:8330
+#, tcl-format
+msgid "Error diffing commits: %s"
+msgstr "コミットのdiff実行エラー: %s"
+
+#: gitk:8360
+msgid "Top"
+msgstr "Top"
+
+#: gitk:8361
+msgid "From"
+msgstr "From"
+
+#: gitk:8366
+msgid "To"
+msgstr "To"
+
+#: gitk:8390
+msgid "Generate patch"
+msgstr "パッチ生成"
+
+#: gitk:8392
+msgid "From:"
+msgstr "From:"
+
+#: gitk:8401
+msgid "To:"
+msgstr "To:"
+
+#: gitk:8410
+msgid "Reverse"
+msgstr "逆"
+
+#: gitk:8412 gitk:8597
+msgid "Output file:"
+msgstr "出力ファイル:"
+
+#: gitk:8418
+msgid "Generate"
+msgstr "生成"
+
+#: gitk:8456
+msgid "Error creating patch:"
+msgstr "パッチ生成エラー:"
+
+#: gitk:8479 gitk:8585 gitk:8642
+msgid "ID:"
+msgstr "ID:"
+
+#: gitk:8488
+msgid "Tag name:"
+msgstr "タグ名:"
+
+#: gitk:8492 gitk:8651
+msgid "Create"
+msgstr "生成"
+
+#: gitk:8509
+msgid "No tag name specified"
+msgstr "タグの名称が指定されていません"
+
+#: gitk:8513
+#, tcl-format
+msgid "Tag \"%s\" already exists"
+msgstr "タグ \"%s\" は既に存在します"
+
+#: gitk:8519
+msgid "Error creating tag:"
+msgstr "タグ生成エラー:"
+
+#: gitk:8594
+msgid "Command:"
+msgstr "コマンド:"
+
+#: gitk:8602
+msgid "Write"
+msgstr "書き込み"
+
+#: gitk:8620
+msgid "Error writing commit:"
+msgstr "コミット書き込みエラー:"
+
+#: gitk:8647
+msgid "Name:"
+msgstr "名前:"
+
+#: gitk:8670
+msgid "Please specify a name for the new branch"
+msgstr "新しいブランチの名前を指定してください"
+
+#: gitk:8675
+#, tcl-format
+msgid "Branch '%s' already exists. Overwrite?"
+msgstr "ブランチ '%s' は既に存在します。上書きしますか？"
+
+#: gitk:8741
+#, tcl-format
+msgid "Commit %s is already included in branch %s -- really re-apply it?"
+msgstr "コミット %s は既にブランチ %s に含まれています ― 本当にこれを再適用しますか？"
+
+#: gitk:8746
+msgid "Cherry-picking"
+msgstr "チェリーピック中"
+
+#: gitk:8755
+#, tcl-format
+msgid ""
+"Cherry-pick failed because of local changes to file '%s'.\n"
+"Please commit, reset or stash your changes and try again."
+msgstr ""
+"ファイル '%s' のローカルな変更のためにチェリーピックは失敗しました。\n"
+"あなたの変更に commit, reset, stash のいずれかを行ってからやり直してください。"
+
+#: gitk:8761
+msgid ""
+"Cherry-pick failed because of merge conflict.\n"
+"Do you wish to run git citool to resolve it?"
+msgstr ""
+"マージの衝突によってチェリーピックは失敗しました。\n"
+"この解決のために git citool を実行したいですか？"
+
+#: gitk:8777
+msgid "No changes committed"
+msgstr "何の変更もコミットされていません"
+
+#: gitk:8803
+msgid "Confirm reset"
+msgstr "確認を取り消す"
+
+#: gitk:8805
+#, tcl-format
+msgid "Reset branch %s to %s?"
+msgstr "ブランチ %s を %s にリセットしますか？"
+
+#: gitk:8809
+msgid "Reset type:"
+msgstr "Reset タイプ:"
+
+#: gitk:8813
+msgid "Soft: Leave working tree and index untouched"
+msgstr "Soft: 作業ツリーもインデックスもそのままにする"
+
+#: gitk:8816
+msgid "Mixed: Leave working tree untouched, reset index"
+msgstr "Mixed: 作業ツリーをそのままにして、インデックスをリセット"
+
+#: gitk:8819
+msgid ""
+"Hard: Reset working tree and index\n"
+"(discard ALL local changes)"
+msgstr ""
+"Hard: 作業ツリーやインデックスをリセット\n"
+"（「全ての」ローカルな変更を破棄）"
+
+#: gitk:8836
+msgid "Resetting"
+msgstr "リセット中"
+
+#: gitk:8893
+msgid "Checking out"
+msgstr "チェックアウト"
+
+#: gitk:8946
+msgid "Cannot delete the currently checked-out branch"
+msgstr "現在チェックアウトされているブランチを削除することはできません"
+
+#: gitk:8952
+#, tcl-format
+msgid ""
+"The commits on branch %s aren't on any other branch.\n"
+"Really delete branch %s?"
+msgstr ""
+"ブランチ %s には他のブランチに存在しないコミットがあります。\n"
+"本当にブランチ %s を削除しますか？"
+
+#: gitk:8983
+#, tcl-format
+msgid "Tags and heads: %s"
+msgstr "タグとHEAD: %s"
+
+#: gitk:8998
+msgid "Filter"
+msgstr "フィルター"
+
+#: gitk:9293
+msgid ""
+"Error reading commit topology information; branch and preceding/following "
+"tag information will be incomplete."
+msgstr ""
+"コミット構造情報読み込みエラー; ブランチ及び上位/下位の"
+"タグ情報が不完全であるようです。"
+
+#: gitk:10279
+msgid "Tag"
+msgstr "タグ"
+
+#: gitk:10279
+msgid "Id"
+msgstr "ID"
+
+#: gitk:10327
+msgid "Gitk font chooser"
+msgstr "Gitk フォント選択"
+
+#: gitk:10344
+msgid "B"
+msgstr "B"
+
+#: gitk:10347
+msgid "I"
+msgstr "I"
+
+#: gitk:10443
+msgid "Gitk preferences"
+msgstr "Gitk 設定"
+
+#: gitk:10445
+msgid "Commit list display options"
+msgstr "コミットリスト表示オプション"
+
+#: gitk:10448
+msgid "Maximum graph width (lines)"
+msgstr "最大グラフ幅（線の本数）"
+
+#: gitk:10452
+#, tcl-format
+msgid "Maximum graph width (% of pane)"
+msgstr "最大グラフ幅（ペインに対する％）"
+
+#: gitk:10456
+msgid "Show local changes"
+msgstr "ローカルな変更を表示"
+
+#: gitk:10459
+msgid "Auto-select SHA1"
+msgstr "SHA1 の自動選択"
+
+#: gitk:10463
+msgid "Diff display options"
+msgstr "diff表示オプション"
+
+#: gitk:10465
+msgid "Tab spacing"
+msgstr "タブ空白幅"
+
+#: gitk:10468
+msgid "Display nearby tags"
+msgstr "近くのタグを表示する"
+
+#: gitk:10471
+msgid "Hide remote refs"
+msgstr "リモートリファレンスを隠す"
+
+#: gitk:10474
+msgid "Limit diffs to listed paths"
+msgstr "diff をリストのパスに制限"
+
+#: gitk:10477
+msgid "Support per-file encodings"
+msgstr "ファイルごとのエンコーディングのサポート"
+
+#: gitk:10483 gitk:10548
+msgid "External diff tool"
+msgstr "外部diffツール"
+
+#: gitk:10485
+msgid "Choose..."
+msgstr "選択..."
+
+#: gitk:10490
+msgid "Colors: press to choose"
+msgstr "色: ボタンを押して選択"
+
+#: gitk:10493
+msgid "Background"
+msgstr "背景"
+
+#: gitk:10494 gitk:10524
+msgid "background"
+msgstr "背景"
+
+#: gitk:10497
+msgid "Foreground"
+msgstr "前景"
+
+#: gitk:10498
+msgid "foreground"
+msgstr "前景"
+
+#: gitk:10501
+msgid "Diff: old lines"
+msgstr "Diff: 旧バージョン"
+
+#: gitk:10502
+msgid "diff old lines"
+msgstr "diff 旧バージョン"
+
+#: gitk:10506
+msgid "Diff: new lines"
+msgstr "Diff: 新バージョン"
+
+#: gitk:10507
+msgid "diff new lines"
+msgstr "diff 新バージョン"
+
+#: gitk:10511
+msgid "Diff: hunk header"
+msgstr "Diff: hunkヘッダ"
+
+#: gitk:10513
+msgid "diff hunk header"
+msgstr "diff hunkヘッダ"
+
+#: gitk:10517
+msgid "Marked line bg"
+msgstr "マーク行の背景"
+
+#: gitk:10519
+msgid "marked line background"
+msgstr "マーク行の背景"
+
+#: gitk:10523
+msgid "Select bg"
+msgstr "選択の背景"
+
+#: gitk:10527
+msgid "Fonts: press to choose"
+msgstr "フォント: ボタンを押して選択"
+
+#: gitk:10529
+msgid "Main font"
+msgstr "主フォント"
+
+#: gitk:10530
+msgid "Diff display font"
+msgstr "Diff表示用フォント"
+
+#: gitk:10531
+msgid "User interface font"
+msgstr "UI用フォント"
+
+#: gitk:10558
+#, tcl-format
+msgid "Gitk: choose color for %s"
+msgstr "Gitk: 「%s」 の色を選択"
+
+#: gitk:11009
+msgid ""
+"Sorry, gitk cannot run with this version of Tcl/Tk.\n"
+" Gitk requires at least Tcl/Tk 8.4."
+msgstr ""
+"申し訳ありませんが、このバージョンの Tcl/Tk では gitk を実行できません。\n"
+" Gitk は最低でも Tcl/Tk 8.4 を必要とします。"
+
+#: gitk:11137
+msgid "Cannot find a git repository here."
+msgstr "ここにはgitリポジトリがありません。"
+
+#: gitk:11141
+#, tcl-format
+msgid "Cannot find the git directory \"%s\"."
+msgstr "gitディレクトリ \"%s\" を見つけられません。"
+
+#: gitk:11188
+#, tcl-format
+msgid "Ambiguous argument '%s': both revision and filename"
+msgstr "あいまいな引数 '%s': リビジョンとファイル名の両方に解釈できます"
+
+#: gitk:11200
+msgid "Bad arguments to gitk:"
+msgstr "gitkへの不正な引数:"
+
+#: gitk:11285
+msgid "Command line"
+msgstr "コマンド行"
==== cut
^ permalink raw reply related
* Re: [RFC PATCH v4 06/26] Add multi_ack_detailed capability to fetch-pack/upload-pack
From: Shawn O. Pearce @ 2009-10-29 16:17 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7v4opibv4i.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > ACK %s
> > -----------------------------------
> > * no multi_ack or multi_ack_detailed:
> >
> > Sent in response to "have" when the object exists on the remote
> > side and is therefore an object in common between the peers.
> > The argument is the SHA-1 of the common object.
>
> Do you mean by "exists" something a bit stronger than that, namely, it
> exists and everything reachable from it also exists, right?
No, I mean "object exists". The upload-pack code makes no check that
the object is in fact complete, just that it has the object in the
object database. The object could be a dangling commit whose parents
aren't present, and we'd still (currently) return an "ACK %s" for it.
I specifically didn't get into completeness here because we don't
actually check for it.
> > ACK %s common
> > -----------------------------------
> > * multi_ack_detailed only:
> >
> > Sent in response to "have". Both sides have this object.
> > Like with "ACK %s continue" above the client should stop
> > sending have lines reachable for objects from the argument.
> >
> > ACK %s ready
> > -----------------------------------
> > * multi_ack_detailed only:
> >
> > Sent in response to "have".
> >
> > The client should stop transmitting objects which are reachable
> > from the argument, and send "done" soon to get the objects.
> >
> > If the remote side has the specified object, it should
> > first send an "ACK %s common" message prior to sending
> > "ACK %s ready".
> >
> > Clients may still submit additional "have" lines if there are
> > more side branches for the client to explore that might be added
> > to the common set and reduce the number of objects to transfer.
>
> I do not understand this after reading it three times. The remote side
> says "ACK $it common", allow the requestor to feed more "have", then
> eventually send an "ACK $it ready" for the same object it earlier sent
> "common" for? The first one tells the requestor not to go down the path
> from $it further, so presumably all the "have"s that come after it will be
> about different ancestry paths.
>
> What is the advantage of using this? In other words, how, in what
> situation and why would the remote side choose to use "ready" --- it looks
> to me that it could always say "common" whenever it hits a "have" that it
> can determine to be common.
"ACK $it ready" should be used when ok_to_give_up() returns true.
The "ACK $it ready" message is trying to say "don't talk any more
about things reachable from $it, and by the way, if you say 'done'
now I will give you a pack".
The "ACK $it common" message is trying to say "$it is a common base,
don't talk any more about things reachable from $it, but there
may be other branches you should explore before I send you a pack,
so talk about those if you can".
A client only wants to store $it into its request state vector for
replay on the next RPC if $it is truely common.
The "ACK $it common" before "ACK $it ready" is because clients can't
assume that "ACK $it ready" means $it is really common. Servers send
"ACK $it ready" if they don't have $it but are ok_to_give_up().
But if it is common, *and* ok_to_give_up() is true, a server can
send both messages, but it must send "ACK $it common" first.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] clone: detect extra arguments
From: Jeff King @ 2009-10-29 16:06 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Junio C Hamano, git
In-Reply-To: <20091029081030.GA11213@progeny.tock>
On Thu, Oct 29, 2009 at 03:10:30AM -0500, Jonathan Nieder wrote:
> If git clone is given more than two non-option arguments, it
> silently throws away all but the first one. Complain instead.
> [...]
> + if (argc > 2)
> + die("Too many arguments.");
> +
Should we maybe be showing the usage in this case?
> if (argc == 0)
> die("You must specify a repository to clone.");
Probably we should do the same here, too.
-Peff
^ permalink raw reply
* Re: Insertions/Deletions summary for a contributor
From: Jeff King @ 2009-10-29 16:01 UTC (permalink / raw)
To: Laszlo Papp; +Cc: git
In-Reply-To: <a362e8010910282344vad53b7ck1b7ae04ff3c499ed@mail.gmail.com>
On Thu, Oct 29, 2009 at 07:44:40AM +0100, Laszlo Papp wrote:
> It would be nice to see summary for a contributor in insertions/deletions
> lines, changed files regard, in the life of the whole project.
>
> So the output would be the summary of the following output lines:
> git log --author="Laszlo Papp" --pretty=tformat: --numstat
>
> Can I deal with it, does it make sense, what do you think about it ?
Try piping the output of the command above through:
perl -ane '
$add{$F[2]} += $F[0];
$del{$F[2]} += $F[1];
END { print "$add{$_} $del{$_} $_\n" foreach sort keys(%add) }
'
but keep in mind that such a summary is not necessarily a useful value.
Modified lines are represented as deletion and add, and you may simply
be deleting and adding the same lines over and over again. :)
A more interesting summary is to "git blame" files and count
contributor lines. This shows content by that contributor which has
survived to the current tree.
-Peff
^ permalink raw reply
* Re: [PATCH 7/7] Factor ref updating out of fetch_with_import
From: Shawn O. Pearce @ 2009-10-29 15:56 UTC (permalink / raw)
To: Sverre Rabbelier
Cc: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
In-Reply-To: <fabb9a1e0910290853p49070443v6d6bf2bf75faf80@mail.gmail.com>
Sverre Rabbelier <srabbelier@gmail.com> wrote:
> On Thu, Oct 29, 2009 at 07:22, Shawn O. Pearce <spearce@spearce.org> wrote:
> > Please define a transport_update_refs wrapper function to implement
> > this method invocation on the transport instance. ?Callers should
> > not be reaching into the struct transport directly.
>
> With pleasure, should the transport_update_refs wrapper simply 'return
> 1' without doing anything if transport->update_refs is not set?
If the function isn't defined, it should behave as though it were
defined and successfully completed.
> > I certainly have to wonder... if this is done in both fetch and
> > clone, why isn't it just part of fetch_refs?
>
> Because clone does not use fetch_refs, or am I missing something?
Hmmph. Weird. Its been a while since I last looked at this code,
maybe I misunderstood it.
--
Shawn.
^ permalink raw reply
* Re: [PATCH 7/7] Factor ref updating out of fetch_with_import
From: Sverre Rabbelier @ 2009-10-29 15:53 UTC (permalink / raw)
To: Shawn O. Pearce
Cc: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
In-Reply-To: <20091029142232.GS10505@spearce.org>
Heya,
On Thu, Oct 29, 2009 at 07:22, Shawn O. Pearce <spearce@spearce.org> wrote:
> Please define a transport_update_refs wrapper function to implement
> this method invocation on the transport instance. Callers should
> not be reaching into the struct transport directly.
With pleasure, should the transport_update_refs wrapper simply 'return
1' without doing anything if transport->update_refs is not set?
> I certainly have to wonder... if this is done in both fetch and
> clone, why isn't it just part of fetch_refs?
Because clone does not use fetch_refs, or am I missing something?
> Please set this before the disconnect method (move it up one line).
Will do.
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* Re: [PATCH 1/7] Refactor git_remote_cvs to a more generic git_remote_helpers
From: Sverre Rabbelier @ 2009-10-29 15:48 UTC (permalink / raw)
To: Johan Herland; +Cc: Git List, Johannes Schindelin, Daniel Barkalow
In-Reply-To: <200910291305.26523.johan@herland.net>
Heya,
On Thu, Oct 29, 2009 at 05:05, Johan Herland <johan@herland.net> wrote:
> Fortunately, you can easily solve both problems by rerolling the patch with
> the -M flag to git-format-patch.
Whow, I feel really silly now, thanks for pointing that out, proper patch sent!
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH 1/7] Refactor git_remote_cvs to a more generic git_remote_helpers
From: Sverre Rabbelier @ 2009-10-29 15:47 UTC (permalink / raw)
To: Git List, Johannes Schindelin, Daniel Barkalow, Johan Herland
Cc: Sverre Rabbelier, Johan Herland
This in an effort to allow future remote helpers written in python to
re-use the non-cvs-specific code.
Signed-off-by: Sverre Rabbelier <srabbelier@gmail.com>
CC: Johan Herland <johan@herland.net>
---
As discussed with Johan Herland, refactored git_remote_cvs into a
more reusable git_remote_helpers module.
Resent as apparently I forgot to include '-C -M' in my
'git format-patch' alias.
Makefile | 8 +++---
git-remote-cvs.py | 14 +++++-----
git_remote_cvs/__init__.py | 27 --------------------
git_remote_cvs/setup.py | 17 ------------
{git_remote_cvs => git_remote_helpers}/.gitignore | 0
{git_remote_cvs => git_remote_helpers}/Makefile | 2 +-
git_remote_helpers/__init__.py | 27 ++++++++++++++++++++
.../cvs}/changeset.py | 2 +-
.../cvs}/commit_states.py | 4 +-
{git_remote_cvs => git_remote_helpers/cvs}/cvs.py | 6 ++--
.../cvs/revision_map.py | 6 ++--
.../cvs/symbol_cache.py | 4 +-
{git_remote_cvs => git_remote_helpers/git}/git.py | 4 +-
git_remote_helpers/setup.py | 17 ++++++++++++
{git_remote_cvs => git_remote_helpers}/util.py | 0
t/test-lib.sh | 4 +-
16 files changed, 71 insertions(+), 71 deletions(-)
delete mode 100644 git_remote_cvs/__init__.py
delete mode 100644 git_remote_cvs/setup.py
rename {git_remote_cvs => git_remote_helpers}/.gitignore (100%)
rename {git_remote_cvs => git_remote_helpers}/Makefile (92%)
create mode 100644 git_remote_helpers/__init__.py
create mode 100644 git_remote_helpers/cvs/__init__.py
rename {git_remote_cvs => git_remote_helpers/cvs}/changeset.py (98%)
rename {git_remote_cvs => git_remote_helpers/cvs}/commit_states.py (95%)
rename {git_remote_cvs => git_remote_helpers/cvs}/cvs.py (99%)
rename git_remote_cvs/cvs_revision_map.py => git_remote_helpers/cvs/revision_map.py (98%)
rename git_remote_cvs/cvs_symbol_cache.py => git_remote_helpers/cvs/symbol_cache.py (98%)
create mode 100644 git_remote_helpers/git/__init__.py
rename {git_remote_cvs => git_remote_helpers/git}/git.py (99%)
create mode 100644 git_remote_helpers/setup.py
rename {git_remote_cvs => git_remote_helpers}/util.py (100%)
diff --git a/Makefile b/Makefile
index 21da297..fa3f768 100644
--- a/Makefile
+++ b/Makefile
@@ -1335,7 +1335,7 @@ ifndef NO_PERL
$(QUIET_SUBDIR0)perl $(QUIET_SUBDIR1) PERL_PATH='$(PERL_PATH_SQ)' prefix='$(prefix_SQ)' all
endif
ifndef NO_PYTHON
- $(QUIET_SUBDIR0)git_remote_cvs $(QUIET_SUBDIR1) PYTHON_PATH='$(PYTHON_PATH_SQ)' prefix='$(prefix_SQ)' all
+ $(QUIET_SUBDIR0)git_remote_helpers $(QUIET_SUBDIR1) PYTHON_PATH='$(PYTHON_PATH_SQ)' prefix='$(prefix_SQ)' all
endif
$(QUIET_SUBDIR0)templates $(QUIET_SUBDIR1)
@@ -1459,7 +1459,7 @@ ifndef NO_PYTHON
$(patsubst %.py,%,$(SCRIPT_PYTHON)): GIT-CFLAGS
$(patsubst %.py,%,$(SCRIPT_PYTHON)): % : %.py
$(QUIET_GEN)$(RM) $@ $@+ && \
- INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_cvs -s \
+ INSTLIBDIR=`MAKEFLAGS= $(MAKE) -C git_remote_helpers -s \
--no-print-directory prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' \
instlibdir` && \
sed -e '1{' \
@@ -1709,7 +1709,7 @@ ifndef NO_PERL
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
endif
ifndef NO_PYTHON
- $(MAKE) -C git_remote_cvs prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
+ $(MAKE) -C git_remote_helpers prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
endif
ifndef NO_TCLTK
$(MAKE) -C gitk-git install
@@ -1826,7 +1826,7 @@ ifndef NO_PERL
$(MAKE) -C perl clean
endif
ifndef NO_PYTHON
- $(MAKE) -C git_remote_cvs clean
+ $(MAKE) -C git_remote_helpers clean
endif
$(MAKE) -C templates/ clean
$(MAKE) -C t/ clean
diff --git a/git-remote-cvs.py b/git-remote-cvs.py
index 94b61e7..f322f96 100755
--- a/git-remote-cvs.py
+++ b/git-remote-cvs.py
@@ -36,16 +36,16 @@ configuration details of this remote helper.
import sys
import os
-from git_remote_cvs.util import (debug, error, die, ProgressIndicator,
+from git_remote_helpers.util import (debug, error, die, ProgressIndicator,
run_command)
-from git_remote_cvs.cvs import CVSState, CVSWorkDir, fetch_revs
-from git_remote_cvs.git import (get_git_dir, parse_git_config, git_config_bool,
+from git_remote_helpers.cvs.cvs import CVSState, CVSWorkDir, fetch_revs
+from git_remote_helpers.git.git import (get_git_dir, parse_git_config, git_config_bool,
valid_git_ref, GitObjectFetcher, GitRefMap,
GitFICommit, GitFastImport, GitNotes)
-from git_remote_cvs.cvs_symbol_cache import CVSSymbolCache
-from git_remote_cvs.commit_states import CommitStates
-from git_remote_cvs.cvs_revision_map import CVSRevisionMap, CVSStateMap
-from git_remote_cvs.changeset import build_changesets_from_revs
+from git_remote_helpers.cvs.symbol_cache import CVSSymbolCache
+from git_remote_helpers.cvs.commit_states import CommitStates
+from git_remote_helpers.cvs.revision_map import CVSRevisionMap, CVSStateMap
+from git_remote_helpers.cvs.changeset import build_changesets_from_revs
class Config(object):
diff --git a/git_remote_cvs/__init__.py b/git_remote_cvs/__init__.py
deleted file mode 100644
index 4956d2d..0000000
--- a/git_remote_cvs/__init__.py
+++ /dev/null
@@ -1,27 +0,0 @@
-#!/usr/bin/env python
-
-"""Support library package for git-remote-cvs.
-
-git-remote-cvs is a Git remote helper command that interfaces with a
-CVS repository to provide automatic import of CVS history into a Git
-repository.
-
-This package provides the support library needed by git-remote-cvs.
-The following modules are included:
-
-- cvs - Interaction with CVS repositories
-
-- cvs_symbol_cache - Local CVS symbol cache
-
-- changeset - Collect individual CVS revisions into commits
-
-- git - Interaction with Git repositories
-
-- commit_states - Map Git commits to CVS states
-
-- cvs_revision_map - Map CVS revisions to various metainformation
-
-- util - General utility functionality use by the other modules in
- this package, and also used directly by git-remote-cvs.
-
-"""
diff --git a/git_remote_cvs/setup.py b/git_remote_cvs/setup.py
deleted file mode 100644
index 21f521a..0000000
--- a/git_remote_cvs/setup.py
+++ /dev/null
@@ -1,17 +0,0 @@
-#!/usr/bin/env python
-
-"""Distutils build/install script for the git_remote_cvs package."""
-
-from distutils.core import setup
-
-setup(
- name = 'git_remote_cvs',
- version = '0.1.0',
- description = 'Git remote helper program for CVS repositories',
- license = 'GPLv2',
- author = 'The Git Community',
- author_email = 'git@vger.kernel.org',
- url = 'http://www.git-scm.com/',
- package_dir = {'git_remote_cvs': ''},
- packages = ['git_remote_cvs'],
-)
diff --git a/git_remote_cvs/.gitignore b/git_remote_helpers/.gitignore
similarity index 100%
rename from git_remote_cvs/.gitignore
rename to git_remote_helpers/.gitignore
diff --git a/git_remote_cvs/Makefile b/git_remote_helpers/Makefile
similarity index 92%
rename from git_remote_cvs/Makefile
rename to git_remote_helpers/Makefile
index 0d9eb31..c62dfd0 100644
--- a/git_remote_cvs/Makefile
+++ b/git_remote_helpers/Makefile
@@ -1,5 +1,5 @@
#
-# Makefile for the git_remote_cvs python support modules
+# Makefile for the git_remote_helpers python support modules
#
pysetupfile:=setup.py
diff --git a/git_remote_helpers/__init__.py b/git_remote_helpers/__init__.py
new file mode 100644
index 0000000..38c7b5f
--- /dev/null
+++ b/git_remote_helpers/__init__.py
@@ -0,0 +1,27 @@
+#!/usr/bin/env python
+
+"""Support library package for git remote helpers.
+
+Git remote helpers are helper commands that interfaces with a non-git
+repository to provide automatic import of non-git history into a Git
+repository.
+
+This package provides the support library needed by these helpers..
+The following modules are included:
+
+- cvs/cvs - Interaction with CVS repositories
+
+- cvs/symbol_cache - Local CVS symbol cache
+
+- cvs/changeset - Collect individual CVS revisions into commits
+
+- cvs/commit_states - Map Git commits to CVS states
+
+- cvs/revision_map - Map CVS revisions to various metainformation
+
+- git/git - Interaction with Git repositories
+
+- util - General utility functionality use by the other modules in
+ this package, and also used directly by git-remote-cvs.
+
+"""
diff --git a/git_remote_helpers/cvs/__init__.py b/git_remote_helpers/cvs/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/git_remote_cvs/changeset.py b/git_remote_helpers/cvs/changeset.py
similarity index 98%
rename from git_remote_cvs/changeset.py
rename to git_remote_helpers/cvs/changeset.py
index 9eea9d2..4865c37 100644
--- a/git_remote_cvs/changeset.py
+++ b/git_remote_helpers/cvs/changeset.py
@@ -11,7 +11,7 @@ module tries to reconstruct this notion of related revisions.
"""
-from git_remote_cvs.util import debug, error, die
+from git_remote_helpers.util import debug, error, die
class Changeset(object):
diff --git a/git_remote_cvs/commit_states.py b/git_remote_helpers/cvs/commit_states.py
similarity index 95%
rename from git_remote_cvs/commit_states.py
rename to git_remote_helpers/cvs/commit_states.py
index 2e0af6c..a796bb1 100644
--- a/git_remote_cvs/commit_states.py
+++ b/git_remote_helpers/cvs/commit_states.py
@@ -2,8 +2,8 @@
"""Code for relating Git commits to corresponding CVSState objects."""
-from git_remote_cvs.util import debug, error, die
-from git_remote_cvs.cvs import CVSState
+from git_remote_helpers.util import debug, error, die
+from git_remote_helpers.cvs.cvs import CVSState
class CommitStates(object):
diff --git a/git_remote_cvs/cvs.py b/git_remote_helpers/cvs/cvs.py
similarity index 99%
rename from git_remote_cvs/cvs.py
rename to git_remote_helpers/cvs/cvs.py
index f870ae0..a1a02be 100644
--- a/git_remote_cvs/cvs.py
+++ b/git_remote_helpers/cvs/cvs.py
@@ -17,9 +17,9 @@ import time
from calendar import timegm
import unittest
-from git_remote_cvs.util import (debug, error, die, ProgressIndicator,
- start_command, run_command,
- file_reader_method, file_writer_method)
+from git_remote_helpers.util import (debug, error, die, ProgressIndicator,
+ start_command, run_command,
+ file_reader_method, file_writer_method)
class CVSNum(object):
diff --git a/git_remote_cvs/cvs_revision_map.py b/git_remote_helpers/cvs/revision_map.py
similarity index 98%
rename from git_remote_cvs/cvs_revision_map.py
rename to git_remote_helpers/cvs/revision_map.py
index 0e65ba6..b7b17bc 100644
--- a/git_remote_cvs/cvs_revision_map.py
+++ b/git_remote_helpers/cvs/revision_map.py
@@ -18,9 +18,9 @@ CVSStateMap - provides a mapping from CVS states to corresponding
import os
-from git_remote_cvs.util import debug, error, die, file_reader_method
-from git_remote_cvs.cvs import CVSNum, CVSDate
-from git_remote_cvs.git import GitFICommit
+from git_remote_helpers.util import debug, error, die, file_reader_method
+from git_remote_helpers.cvs.cvs import CVSNum, CVSDate
+from git_remote_helpers.git.git import GitFICommit
class _CVSPathInfo(object):
diff --git a/git_remote_cvs/cvs_symbol_cache.py b/git_remote_helpers/cvs/symbol_cache.py
similarity index 98%
rename from git_remote_cvs/cvs_symbol_cache.py
rename to git_remote_helpers/cvs/symbol_cache.py
index cc8d88b..6bd1715 100644
--- a/git_remote_cvs/cvs_symbol_cache.py
+++ b/git_remote_helpers/cvs/symbol_cache.py
@@ -23,8 +23,8 @@ synchronizing _all_ CVS symbols in one operation (by executing
import sys
import os
-from git_remote_cvs.util import debug, error, die, ProgressIndicator
-from git_remote_cvs.cvs import CVSNum, CVSState, CVSLogParser
+from git_remote_helpers.util import debug, error, die, ProgressIndicator
+from git_remote_helpers.cvs.cvs import CVSNum, CVSState, CVSLogParser
class CVSSymbolStateLister(CVSLogParser):
diff --git a/git_remote_helpers/git/__init__.py b/git_remote_helpers/git/__init__.py
new file mode 100644
index 0000000..e69de29
diff --git a/git_remote_cvs/git.py b/git_remote_helpers/git/git.py
similarity index 99%
rename from git_remote_cvs/git.py
rename to git_remote_helpers/git/git.py
index cf037e3..8e1bc77 100644
--- a/git_remote_cvs/git.py
+++ b/git_remote_helpers/git/git.py
@@ -12,8 +12,8 @@ from binascii import hexlify
from cStringIO import StringIO
import unittest
-from git_remote_cvs.util import debug, error, die, start_command, run_command
-from git_remote_cvs.cvs import CVSDate
+from git_remote_helpers.util import debug, error, die, start_command, run_command
+from git_remote_helpers.cvs.cvs import CVSDate
def get_git_dir ():
diff --git a/git_remote_helpers/setup.py b/git_remote_helpers/setup.py
new file mode 100644
index 0000000..327f0ff
--- /dev/null
+++ b/git_remote_helpers/setup.py
@@ -0,0 +1,17 @@
+#!/usr/bin/env python
+
+"""Distutils build/install script for the git_remote_helpers package."""
+
+from distutils.core import setup
+
+setup(
+ name = 'git_remote_helpers',
+ version = '0.1.0',
+ description = 'Git remote helper program for non-git repositories',
+ license = 'GPLv2',
+ author = 'The Git Community',
+ author_email = 'git@vger.kernel.org',
+ url = 'http://www.git-scm.com/',
+ package_dir = {'git_remote_helpers': ''},
+ packages = ['git_remote_helpers', 'git_remote_helpers.git', 'git_remote_helpers.cvs'],
+)
diff --git a/git_remote_cvs/util.py b/git_remote_helpers/util.py
similarity index 100%
rename from git_remote_cvs/util.py
rename to git_remote_helpers/util.py
diff --git a/t/test-lib.sh b/t/test-lib.sh
index 5cd2b1c..20216a5 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -637,9 +637,9 @@ test -d ../templates/blt || {
if test -z "$GIT_TEST_INSTALLED"
then
- GITPYTHONLIB="$(pwd)/../git_remote_cvs/build/lib"
+ GITPYTHONLIB="$(pwd)/../git_remote_helpers/build/lib"
export GITPYTHONLIB
- test -d ../git_remote_cvs/build || {
+ test -d ../git_remote_helpers/build || {
error "You haven't built git_remote_cvs yet, have you?"
}
fi
--
1.6.5.2.291.gf76a3
^ permalink raw reply related
* Re: [RFC PATCH v4 00/26] Return of smart HTTP
From: Shawn O. Pearce @ 2009-10-29 15:28 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git
In-Reply-To: <m3my3ad3gp.fsf@localhost.localdomain>
Jakub Narebski <jnareb@gmail.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > I think this is the final spin of the smart HTTP series.
>
> If it is a final spin, then what of missing RFC-like documentation of
> Git HTTP protocol in Documentation/technical/http-protocol.txt
> (it was present only in first version of new series)?
Its still incomplete. I want to get the code cooking while I work
on the documentation. Its a separate patch anyway, whether or not
its in the middle of the code series or after it is doesn't matter.
--
Shawn.
^ permalink raw reply
* Re: [RFC PATCH v4 14/26] Add stateless RPC options to upload-pack, receive-pack
From: Shawn O. Pearce @ 2009-10-29 15:26 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git
In-Reply-To: <7vd446dfx4.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> wrote:
> "Shawn O. Pearce" <spearce@spearce.org> writes:
>
> > When --stateless-rpc is passed [...]
> > When --advertise-refs is passed [...]
>
> Is the idea to first run with --advertise-refs to get the set of refs, and
> then doing another, separate run with --stateless-rpc, assuming that the
> refs the other end advertised does not change in the meantime, to conclude
> the business?
Yes.
> I suspect that two separate invocations on a (supposedly) single
> repository made back-to-back can produce an inconsistent response in
> verious situations (e.g. somebody pushing in the middle, or the same
> hostname served by more than one mirrors) and the other end can get
> confused.
Yes, that can happen.
> I do not think there is any way to avoid it, short of adding to the second
> request some "cookie" that allows the second requestee to verify that the
> request is based on what he would give to the requester if this request
> were the first step of the request made to him, iow, his state did not
> change in the middle since the first request was made (either to him or to
> the equivalent mirror sitting next to himm).
There isn't a lot we can do, you are right.
One approach is to use an HMAC and sign each advertised SHA-1
during the initial --advertise-refs phase. Requesters then present
the SHA-1 and the HAMC signature in each "want" line, and the
--stateless-rpc phase validates the signatures to ensure they came
from a trusted party.
The major problem with this approach is the private key management.
All mirrors of that repository need to have a common private key
so they can generate and later verify that HMAC signature. This is
additional complexity, for perhaps not much gain.
A different approach is to have the --stateless-rpc phase validate
the want lines against its refs (like we do now), but if the validate
fails (no ref exactly matches) support walking backwards through the
last few records in the reflog, or through that ref's own history
for a few hundred commits, to see if the want SHA-1 appears in the
recent prior past.
Obviously when walking the reflog we would need to use a time bound,
e.g. "only examine last record if more recent than 5 minutes ago".
This way a force push to erase something will still erase it, but
a client who had just recently observed the prior SHA-1 can still
complete their fetch request, just as with native git:// they could
do that due to the prior SHA-1 being held in the git-upload-pack's
private memory.
Also, obviously when walking the commit history of a ref (to see
if the want'd SHA-1 is merged into one or more reachable refs)
we don't want to walk backwards too far, as it costs CPU time on
the server side, but we also don't want to walk too few commits.
E.g. pushes for me tend to be in the 20 commit range, while Linus
probably pushes a thousand commits or more in a single merge.
Finding the right balance may be tricky.
> I wouldn't worry too much about this if the only negative effect could be
> that the requestor's second request may result in an error, but I am
> wondering if this can be used to attack the requestee.
I don't think it can be used to attack the server. The only impact
I can see is the client gets confused and gets an error response
from the server when the server aborts due to the invalid "want"
line sent during that 2nd (or any subsequent) request.
--
Shawn.
^ permalink raw reply
* [PATCH] Make t9150 and t9151 test scripts executable
From: Michael J Gruber @ 2009-10-29 15:26 UTC (permalink / raw)
To: git; +Cc: Junio C Hamano
so that they can be run individually as
(cd t && ./t9150-svk-mergetickets.sh)
etc. just like all other test scripts.
Signed-off-by: Michael J Gruber <git@drmicha.warpmail.net>
---
Not much more to say. Wanted to be a good boy and run the new tests.
One can use sh, of course, but there's a reason all other tests are executable.
0 files changed, 0 insertions(+), 0 deletions(-)
mode change 100644 => 100755 t/t9150-svk-mergetickets.sh
mode change 100644 => 100755 t/t9151-svn-mergeinfo.sh
diff --git a/t/t9150-svk-mergetickets.sh b/t/t9150-svk-mergetickets.sh
old mode 100644
new mode 100755
diff --git a/t/t9151-svn-mergeinfo.sh b/t/t9151-svn-mergeinfo.sh
old mode 100644
new mode 100755
--
1.6.5.86.g0056e
^ 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