* Re: t9902 fails
From: Jean-Noël AVILA @ 2013-01-18 22:23 UTC (permalink / raw)
To: Junio C Hamano
Cc: Jonathan Nieder, Torsten Bögershausen, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <7vmww6qmck.fsf@alter.siamese.dyndns.org>
Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
> Junio C Hamano <gitster@pobox.com> writes:
> > How about doing something like this and set that variable in the
> > test instead? If STD_ONLY is not set, you will get everything, but
> > when STD_ONLY is set, we will stop reading from "help -a" when it
> > starts listing additional stuff.
I tried both of your propositions but none made test 10 of t9902 pass.
Am I supposed to run "make install" before running the test?
^ permalink raw reply
* Re: [RFC/PATCH] CodingGuidelines: add Python code guidelines
From: Junio C Hamano @ 2013-01-18 22:26 UTC (permalink / raw)
To: John Keeping
Cc: git, Eric S. Raymond, Felipe Contreras, Pete Wyckoff,
Michael Haggerty
In-Reply-To: <20130118220552.GF31172@serenity.lan>
John Keeping <john@keeping.me.uk> writes:
> On Fri, Jan 18, 2013 at 12:25:34PM -0800, Junio C Hamano wrote:
>> John Keeping <john@keeping.me.uk> writes:
>>> As more people have started trying to support Python 3 in the wild, it
>>> has become clear that it is often easier to have a single codebase that
>>> works with both Python 2 and Python 3, and not use 2to3.
>>>
>>> It is for this reason that the Unicode literal prefix was reintroduced.
>>
>> Yes, and from that perspective, placing floor on earlier 3.x makes
>> tons of sense, no?
>>
>> These early versions may not be unstable in the "this does not
>> behave as specified in the language specification for 3.x" sense,
>> but for the purpose of running scripts meant to be executable by
>> both 2.x and 3.x series, the early 3.x versions are not as good as
>> later versions where Python folks started making deliberate effort
>> to support them.
>
> As far as I'm aware (and having reviewed the release notes for 3.1, 3.2
> and 3.3 as well as the planned features for 3.4), Unicode literals are
> the only feature to have been added that was intended to make it easier
> to support Python 2 and 3 in the same codebase.
So there may be some other incompatibility lurking that we may run
into later?
> Given that no code currently on pu uses Unicode literals, I don't see a
> reason to specify a minimum version of Python 3 since we're already
> restricting ourselves to features in 2.6.
OK, at least that reasoning need to be kept somewhere, either in the
documentation of in the log message.
Thanks.
^ permalink raw reply
* Re: t9902 fails
From: Junio C Hamano @ 2013-01-18 22:37 UTC (permalink / raw)
To: Jean-Noël AVILA
Cc: Jonathan Nieder, Torsten Bögershausen, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <201301182323.55378.avila.jn@gmail.com>
"Jean-Noël AVILA" <avila.jn@gmail.com> writes:
> Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
>> Junio C Hamano <gitster@pobox.com> writes:
>> > How about doing something like this and set that variable in the
>> > test instead? If STD_ONLY is not set, you will get everything, but
>> > when STD_ONLY is set, we will stop reading from "help -a" when it
>> > starts listing additional stuff.
>
> I tried both of your propositions but none made test 10 of t9902 pass.
Do you have a leftover git-check-ignore or something from a previous
build that is *not* known to "git" you just built?
Neither will help in such a case. The test pretty much runs with
GIT_EXEC_PATH set to the build area, and we do want to be able to
test what we have in the build area before we decide to install
them, so that is nothing new.
^ permalink raw reply
* Re: t9902 fails
From: Junio C Hamano @ 2013-01-18 22:57 UTC (permalink / raw)
To: Jean-Noël AVILA
Cc: Jonathan Nieder, Torsten Bögershausen, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <7vpq12p17l.fsf@alter.siamese.dyndns.org>
Junio C Hamano <gitster@pobox.com> writes:
> "Jean-Noël AVILA" <avila.jn@gmail.com> writes:
>
>> Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
>>> Junio C Hamano <gitster@pobox.com> writes:
>>> > How about doing something like this and set that variable in the
>>> > test instead? If STD_ONLY is not set, you will get everything, but
>>> > when STD_ONLY is set, we will stop reading from "help -a" when it
>>> > starts listing additional stuff.
>>
>> I tried both of your propositions but none made test 10 of t9902 pass.
>
> Do you have a leftover git-check-ignore or something from a previous
> build that is *not* known to "git" you just built?
"... in the build directory" was missing from the sentence. Sorry
about noise.
> Neither will help in such a case. The test pretty much runs with
> GIT_EXEC_PATH set to the build area, and we do want to be able to
> test what we have in the build area before we decide to install
> them, so that is nothing new.
^ permalink raw reply
* Re: [RFC/PATCH] CodingGuidelines: add Python code guidelines
From: John Keeping @ 2013-01-18 23:05 UTC (permalink / raw)
To: Junio C Hamano
Cc: git, Eric S. Raymond, Felipe Contreras, Pete Wyckoff,
Michael Haggerty
In-Reply-To: <7vwqvap1q9.fsf@alter.siamese.dyndns.org>
On Fri, Jan 18, 2013 at 02:26:06PM -0800, Junio C Hamano wrote:
> John Keeping <john@keeping.me.uk> writes:
>> On Fri, Jan 18, 2013 at 12:25:34PM -0800, Junio C Hamano wrote:
>>> These early versions may not be unstable in the "this does not
>>> behave as specified in the language specification for 3.x" sense,
>>> but for the purpose of running scripts meant to be executable by
>>> both 2.x and 3.x series, the early 3.x versions are not as good as
>>> later versions where Python folks started making deliberate effort
>>> to support them.
>>
>> As far as I'm aware (and having reviewed the release notes for 3.1, 3.2
>> and 3.3 as well as the planned features for 3.4), Unicode literals are
>> the only feature to have been added that was intended to make it easier
>> to support Python 2 and 3 in the same codebase.
>
> So there may be some other incompatibility lurking that we may run
> into later?
I doubt it - enough projects are running on Python 2 and 3 now that I
doubt there's anything unexpected left to hit.
>> Given that no code currently on pu uses Unicode literals, I don't see a
>> reason to specify a minimum version of Python 3 since we're already
>> restricting ourselves to features in 2.6.
>
> OK, at least that reasoning need to be kept somewhere, either in the
> documentation of in the log message.
I'll put it in the log message when I send this as a proper patch.
John
^ permalink raw reply
* Re: Question re. git remote repository
From: Philip Oakley @ 2013-01-18 23:10 UTC (permalink / raw)
To: David Lang; +Cc: Lang, David, 'Matt Seitz', git, Junio C Hamano
In-Reply-To: <alpine.DEB.2.02.1301181320070.21503@nftneq.ynat.uz>
From: "David Lang" <david@lang.hm>
Sent: Friday, January 18, 2013 9:27 PM
> On Fri, 18 Jan 2013, Junio C Hamano wrote:
>
>> David Lang <david@lang.hm> writes:
>>
>>> What I would do is to have each developer have their own local copy
>>> that they are working on.
>>>
If you have a third machine to host the bare 'master' repo that would
provide additional security/backup to touy local machines.
[...]
>
> Junio, is there a really good place we should be pointing David where
> the different workflows are described and explained?
`git help workflows` perhaps.
Philip
^ permalink raw reply
* Re: [PATCH 1/2] upload-pack: avoid parsing objects during ref advertisement
From: Junio C Hamano @ 2013-01-18 23:12 UTC (permalink / raw)
To: Jeff King; +Cc: git, git-dev
In-Reply-To: <20120106191740.GA12903@sigill.intra.peff.net>
Jeff King <peff@peff.net> writes:
> When we advertise a ref, the first thing we do is parse the
> pointed-to object. This gives us two things:
>
> 1. a "struct object" we can use to store flags
>
> 2. the type of the object, so we know whether we need to
> dereference it as a tag
>
> Instead, we can just use lookup_unknown_object to get an
> object struct, and then fill in just the type field using
> sha1_object_info (which, in the case of packed files, can
> find the information without actually inflating the object
> data).
>
> This can save time if you have a large number of refs, and
> the client isn't actually going to request those refs (e.g.,
> because most of them are already up-to-date).
>
> The downside is that we are no longer verifying objects that
> we advertise by fully parsing them (however, we do still
> know we actually have them, because sha1_object_info must
> find them to get the type). While we might fail to detect a
> corrupt object here, if the client actually fetches the
> object, we will parse (and verify) it then.
>...
This is an old news, but do you recall why this patch did not update
the code in mark_our_ref() that gets "struct object *o" from parse_object()
the same way and mark them with OUR_REF flag?
I was wondering about code consolidation like this.
upload-pack.c | 11 +++++------
1 file changed, 5 insertions(+), 6 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 95d8313..609cd6c 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -722,15 +722,18 @@ static void receive_needs(void)
free(shallows.objects);
}
+static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data);
+
static int send_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
static const char *capabilities = "multi_ack thin-pack side-band"
" side-band-64k ofs-delta shallow no-progress"
" include-tag multi_ack_detailed";
- struct object *o = lookup_unknown_object(sha1);
const char *refname_nons = strip_namespace(refname);
unsigned char peeled[20];
+ mark_our_ref(refname, sha1, flag, cb_data);
+
if (capabilities)
packet_write(1, "%s %s%c%s%s agent=%s\n",
sha1_to_hex(sha1), refname_nons,
@@ -740,10 +743,6 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
else
packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname_nons);
capabilities = NULL;
- if (!(o->flags & OUR_REF)) {
- o->flags |= OUR_REF;
- nr_our_refs++;
- }
if (!peel_ref(refname, peeled))
packet_write(1, "%s %s^{}\n", sha1_to_hex(peeled), refname_nons);
return 0;
@@ -751,7 +750,7 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
- struct object *o = parse_object(sha1);
+ struct object *o = parse_object(sha1); /* lookup-unknown??? */
if (!o)
die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
if (!(o->flags & OUR_REF)) {
^ permalink raw reply related
* Re: [PATCH] git-svn: teach find-rev to find near matches
From: Junio C Hamano @ 2013-01-18 23:14 UTC (permalink / raw)
To: Eric Wong; +Cc: John Keeping, git
In-Reply-To: <20130118004917.GA27106@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> I've pushed this out to git://bogomips.org/git-svn along with a few
> other things I seem to have forgotten about :x
>
> John Keeping (1):
> git-svn: teach find-rev to find near matches
>
> Jonathan Nieder (2):
> Git::SVN::Editor::T: pass $deletions to ->A and ->D
> git svn: do not overescape URLs (fallback case)
Thanks; pulled and pushed out.
^ permalink raw reply
* [PATCH 0/2] Hiding some refs in ls-remote
From: Junio C Hamano @ 2013-01-19 0:37 UTC (permalink / raw)
To: git; +Cc: spearce, mfick
This is an early preview of reducing the network cost while talking
with a repository with tons of refs, most of which are of use by
very narrow audiences (e.g. refs under Gerrit's refs/changes/ are
useful only for people who are interested in the changes under
review). As long as these narrow audiences have a way to learn the
names of refs or objects pointed at by the refs out-of-band, it is
not necessary to advertise these refs.
On the server end, you tell upload-pack that some refs do not have
to be advertised with the uploadPack.hiderefs multi-valued
configuration variable:
[uploadPack]
hiderefs = refs/changes
The changes necessary on the client side to allow fetching objects
at the tip of a ref in hidden hierarchies are much more involved and
not part of this early preview, but the end user UI is expected to
be like these:
$ git fetch $there refs/changes/72/41672/1
$ git fetch $there 9598d59cdc098c5d9094d68024475e2430343182
That is, you ask for a refname as usual even though it is not part
of ls-remote response, or you ask for the commit object that is at
the tip of whatever hidden ref you are interested in.
Junio C Hamano (2):
upload-pack: share more code
upload-pack: allow hiding ref hiearchies
t/t5512-ls-remote.sh | 9 ++++++
upload-pack.c | 86 ++++++++++++++++++++++++++++++++++++++++++----------
2 files changed, 79 insertions(+), 16 deletions(-)
--
1.8.1.1.454.g48d39c0
^ permalink raw reply
* [PATCH 1/2] upload-pack: share more code
From: Junio C Hamano @ 2013-01-19 0:37 UTC (permalink / raw)
To: git; +Cc: spearce, mfick
In-Reply-To: <1358555826-11883-1-git-send-email-gitster@pobox.com>
We mark the objects pointed at our refs with "OUR_REF" flag in two
functions (mark_our_ref() and send_ref()), but we can just use the
former as a helper for the latter.
Update the way mark_our_ref() prepares in-core object to use
lookup_unknown_object() to delay reading the actual object data,
just like we did in 435c833 (upload-pack: use peel_ref for ref
advertisements, 2012-10-04).
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
upload-pack.c | 31 ++++++++++++++-----------------
1 file changed, 14 insertions(+), 17 deletions(-)
diff --git a/upload-pack.c b/upload-pack.c
index 95d8313..3dd220d 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -722,15 +722,28 @@ static void receive_needs(void)
free(shallows.objects);
}
+static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ struct object *o = lookup_unknown_object(sha1);
+ if (!o)
+ die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
+ if (!(o->flags & OUR_REF)) {
+ o->flags |= OUR_REF;
+ nr_our_refs++;
+ }
+ return 0;
+}
+
static int send_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
static const char *capabilities = "multi_ack thin-pack side-band"
" side-band-64k ofs-delta shallow no-progress"
" include-tag multi_ack_detailed";
- struct object *o = lookup_unknown_object(sha1);
const char *refname_nons = strip_namespace(refname);
unsigned char peeled[20];
+ mark_our_ref(refname, sha1, flag, cb_data);
+
if (capabilities)
packet_write(1, "%s %s%c%s%s agent=%s\n",
sha1_to_hex(sha1), refname_nons,
@@ -740,27 +753,11 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
else
packet_write(1, "%s %s\n", sha1_to_hex(sha1), refname_nons);
capabilities = NULL;
- if (!(o->flags & OUR_REF)) {
- o->flags |= OUR_REF;
- nr_our_refs++;
- }
if (!peel_ref(refname, peeled))
packet_write(1, "%s %s^{}\n", sha1_to_hex(peeled), refname_nons);
return 0;
}
-static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
-{
- struct object *o = parse_object(sha1);
- if (!o)
- die("git upload-pack: cannot find object %s:", sha1_to_hex(sha1));
- if (!(o->flags & OUR_REF)) {
- o->flags |= OUR_REF;
- nr_our_refs++;
- }
- return 0;
-}
-
static void upload_pack(void)
{
if (advertise_refs || !stateless_rpc) {
--
1.8.1.1.454.g48d39c0
^ permalink raw reply related
* [PATCH 2/2] upload-pack: allow hiding ref hiearchies
From: Junio C Hamano @ 2013-01-19 0:37 UTC (permalink / raw)
To: git; +Cc: spearce, mfick
In-Reply-To: <1358555826-11883-1-git-send-email-gitster@pobox.com>
Teach upload-pack to omit some refs from the initial advertisement
by introducing the uploadPack.hiderefs multivalued configuration
variable. Any ref that is under the hierarchies listed on the value
of this variable is excluded from responses to "ls-remote", "fetch"
or "clone" requests. One typical use case may be
[uploadPack]
hiderefs = refs/changes
Note that the underlying protocol allows a request to fetch objects
at the tip of any ref, including the hidden ones, but on the client
side (e.g. fetch-pack), the requests are checked against the
ls-remote response, so it cannot ask for refs/changes/72/41672/1, or
for the object name (which is what eventually goes over the wire on
"want" line) the user may obtain out of band (e.g. Gerrit
dashboard). A new capability "allow-tip-sha1-in-want" is returned
by upload-pack to signal updated clients that it may be OK to ask
for objects that were not advertised.
If we want to allow fetching refname that is hidden, e.g.
$ git fetch $there refs/changes/72/41672/1
we need to further update the server side to understand a message
that has the refname instead of object name on "want" line. The
necessary change to the server side to support that is not in this
step.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
t/t5512-ls-remote.sh | 9 ++++++++
upload-pack.c | 61 ++++++++++++++++++++++++++++++++++++++++++++++++++--
2 files changed, 68 insertions(+), 2 deletions(-)
diff --git a/t/t5512-ls-remote.sh b/t/t5512-ls-remote.sh
index d16e5d3..9ee3d2a 100755
--- a/t/t5512-ls-remote.sh
+++ b/t/t5512-ls-remote.sh
@@ -126,4 +126,13 @@ test_expect_success 'Report match with --exit-code' '
test_cmp expect actual
'
+test_expect_success 'Hide some refs' '
+ test_config uploadPack.hiderefs refs/tags &&
+ git ls-remote . >actual &&
+ test_unconfig uploadPack.hiderefs &&
+ git ls-remote . |
+ sed -e "/ refs\/tags\//d" >expect &&
+ test_cmp expect actual
+'
+
test_done
diff --git a/upload-pack.c b/upload-pack.c
index 3dd220d..54c304d 100644
--- a/upload-pack.c
+++ b/upload-pack.c
@@ -12,6 +12,7 @@
#include "run-command.h"
#include "sigchain.h"
#include "version.h"
+#include "string-list.h"
static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=<n>] <dir>";
@@ -28,10 +29,13 @@ static const char upload_pack_usage[] = "git upload-pack [--strict] [--timeout=<
static unsigned long oldest_have;
-static int multi_ack, nr_our_refs;
+static int multi_ack;
+static int nr_our_refs; /* This counts both advertised and unadvertised */
static int no_done;
static int use_thin_pack, use_ofs_delta, use_include_tag;
static int no_progress, daemon_mode;
+static struct string_list *hide_refs;
+static int allow_tip_sha1_in_want;
static int shallow_nr;
static struct object_array have_obj;
static struct object_array want_obj;
@@ -722,6 +726,23 @@ static void receive_needs(void)
free(shallows.objects);
}
+static int ref_is_hidden(const char *refname)
+{
+ struct string_list_item *item;
+
+ if (!hide_refs)
+ return 0;
+ for_each_string_list_item(item, hide_refs) {
+ int len;
+ if (prefixcmp(refname, item->string))
+ continue;
+ len = strlen(item->string);
+ if (!refname[len] || refname[len] == '/')
+ return 1;
+ }
+ return 0;
+}
+
static int mark_our_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
{
struct object *o = lookup_unknown_object(sha1);
@@ -743,11 +764,14 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
unsigned char peeled[20];
mark_our_ref(refname, sha1, flag, cb_data);
+ if (allow_tip_sha1_in_want && ref_is_hidden(refname))
+ return 0;
if (capabilities)
- packet_write(1, "%s %s%c%s%s agent=%s\n",
+ packet_write(1, "%s %s%c%s%s%s agent=%s\n",
sha1_to_hex(sha1), refname_nons,
0, capabilities,
+ allow_tip_sha1_in_want ? " allow-tip-sha1-in-want" : "",
stateless_rpc ? " no-done" : "",
git_user_agent_sanitized());
else
@@ -758,11 +782,21 @@ static int send_ref(const char *refname, const unsigned char *sha1, int flag, vo
return 0;
}
+static int check_hidden_ref(const char *refname, const unsigned char *sha1, int flag, void *cb_data)
+{
+ if (!ref_is_hidden(refname))
+ return 0;
+ allow_tip_sha1_in_want = 1;
+ return 1; /* terminate iteration over refs early */
+}
+
static void upload_pack(void)
{
if (advertise_refs || !stateless_rpc) {
reset_timeout();
head_ref_namespaced(send_ref, NULL);
+ if (hide_refs)
+ for_each_namespaced_ref(check_hidden_ref, NULL);
for_each_namespaced_ref(send_ref, NULL);
packet_flush(1);
} else {
@@ -779,6 +813,28 @@ static void upload_pack(void)
}
}
+static int upload_pack_config(const char *var, const char *value, void *unused)
+{
+ if (!strcmp("uploadpack.hiderefs", var)) {
+ char *ref;
+ int len;
+
+ if (!value)
+ return config_error_nonbool(var);
+ ref = xstrdup(value);
+ len = strlen(ref);
+ while (len && ref[len - 1] == '/')
+ ref[--len] = '\0';
+ if (!hide_refs) {
+ hide_refs = xcalloc(1, sizeof(*hide_refs));
+ hide_refs->strdup_strings = 1;
+ }
+ string_list_append(hide_refs, ref);
+ return 0;
+ }
+ return 0;
+}
+
int main(int argc, char **argv)
{
char *dir;
@@ -830,6 +886,7 @@ int main(int argc, char **argv)
die("'%s' does not appear to be a git repository", dir);
if (is_repository_shallow())
die("attempt to fetch/clone from a shallow repository");
+ git_config(upload_pack_config, NULL);
if (getenv("GIT_DEBUG_SEND_PACK"))
debug_fd = atoi(getenv("GIT_DEBUG_SEND_PACK"));
upload_pack();
--
1.8.1.1.454.g48d39c0
^ permalink raw reply related
* Re: t9902 fails
From: Torsten Bögershausen @ 2013-01-19 5:38 UTC (permalink / raw)
To: Jean-Noël AVILA
Cc: Junio C Hamano, Jonathan Nieder, Torsten Bögershausen,
Jeff King, git, Nguyễn Thái Ngọc Duy,
Felipe Contreras
In-Reply-To: <201301182323.55378.avila.jn@gmail.com>
On 18.01.13 23:23, Jean-Noël AVILA wrote:
> Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
>> Junio C Hamano <gitster@pobox.com> writes:
>>> How about doing something like this and set that variable in the
>>> test instead? If STD_ONLY is not set, you will get everything, but
>>> when STD_ONLY is set, we will stop reading from "help -a" when it
>>> starts listing additional stuff.
>
> I tried both of your propositions but none made test 10 of t9902 pass.
>
> Am I supposed to run "make install" before running the test?
No. The test suite could (and should) be run before you make install.
So a typical sequence could be:
Run test suite, and if that passes, install the binaries on my system.
This could look like this on the command line:
make test && sudo make install
Jean-Noël,
would it be possible to run
"git status"
and share the result with us?
And did you try Jonathans patch?
/Torsten
^ permalink raw reply
* Re: [DOCBUG] git subtree synopsis needs updating
From: Techlive Zheng @ 2013-01-19 5:48 UTC (permalink / raw)
To: Herman van Rink; +Cc: Yann Dirson, git list
In-Reply-To: <5082FE13.2000003@initfour.nl>
On 12-10-20, Herman van Rink wrote:
> On 10/19/2012 03:21 PM, Yann Dirson wrote:
> > As the examples in git-subtree.txt show, the synopsis in the same file should
> > surely get a patch along the lines of:
> >
> > -'git subtree' add -P <prefix> <commit>
> > +'git subtree' add -P <prefix> <repository> <commit>
> >
> > Failure to specify the repository (by just specifying a local commit) fails with
> > the cryptic:
> >
> > warning: read-tree: emptying the index with no arguments is deprecated; use --empty
> > fatal: just how do you expect me to merge 0 trees?
> >
> >
> > Furthermore, the doc paragraph for add, aside from mentionning <repository>, also
> > mentions a <refspec> which the synopsis does not show either.
> >
> >
> > As a sidenote it someone wants to do some maintainance, using "." as repository when
> > the branch to subtree-add is already locally available does not work well either
> > (fails with "could not find ref myremote/myhead").
> >
>
> The version of subtree in contrib is rather out-dated unfortunately.
You should really submit these patches here for reviewing, David is
actively maintaining this tool here.
>
> I've collected a bunch of patches in
> https://github.com/helmo/git/tree/subtree-updates
>
> The documentation issue is also fixed in there.
>
> --
>
> Met vriendelijke groet / Regards,
>
> Herman van Rink
> Initfour websolutions
>
> --
> To unsubscribe from this list: send the line "unsubscribe git" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Duy Nguyen @ 2013-01-19 5:50 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce, mfick
In-Reply-To: <1358555826-11883-1-git-send-email-gitster@pobox.com>
On Sat, Jan 19, 2013 at 7:37 AM, Junio C Hamano <gitster@pobox.com> wrote:
> This is an early preview of reducing the network cost while talking
> with a repository with tons of refs, most of which are of use by
> very narrow audiences (e.g. refs under Gerrit's refs/changes/ are
> useful only for people who are interested in the changes under
> review). As long as these narrow audiences have a way to learn the
> names of refs or objects pointed at by the refs out-of-band, it is
> not necessary to advertise these refs.
>
> On the server end, you tell upload-pack that some refs do not have
> to be advertised with the uploadPack.hiderefs multi-valued
> configuration variable:
>
> [uploadPack]
> hiderefs = refs/changes
>
> The changes necessary on the client side to allow fetching objects
> at the tip of a ref in hidden hierarchies are much more involved and
> not part of this early preview, but the end user UI is expected to
> be like these:
>
> $ git fetch $there refs/changes/72/41672/1
> $ git fetch $there 9598d59cdc098c5d9094d68024475e2430343182
>
> That is, you ask for a refname as usual even though it is not part
> of ls-remote response, or you ask for the commit object that is at
> the tip of whatever hidden ref you are interested in.
Should the client side learn how to list hidden refs too? I'm thinking
of an extreme case where upload-pack advertises nothing (or maybe just
refs/heads/master) and it's up to the client to ask for the ref
selection it's interested in. upload-pack may need more updates to do
that, I think.
--
Duy
^ permalink raw reply
* Re: [PATCH 0/2] Hiding some refs in ls-remote
From: Michael Haggerty @ 2013-01-19 6:18 UTC (permalink / raw)
To: Junio C Hamano; +Cc: git, spearce, mfick
In-Reply-To: <1358555826-11883-1-git-send-email-gitster@pobox.com>
On 01/19/2013 01:37 AM, Junio C Hamano wrote:
> This is an early preview of reducing the network cost while talking
> with a repository with tons of refs, most of which are of use by
> very narrow audiences (e.g. refs under Gerrit's refs/changes/ are
> useful only for people who are interested in the changes under
> review). As long as these narrow audiences have a way to learn the
> names of refs or objects pointed at by the refs out-of-band, it is
> not necessary to advertise these refs.
>
> On the server end, you tell upload-pack that some refs do not have
> to be advertised with the uploadPack.hiderefs multi-valued
> configuration variable:
>
> [uploadPack]
> hiderefs = refs/changes
>
> The changes necessary on the client side to allow fetching objects
> at the tip of a ref in hidden hierarchies are much more involved and
> not part of this early preview, but the end user UI is expected to
> be like these:
>
> $ git fetch $there refs/changes/72/41672/1
> $ git fetch $there 9598d59cdc098c5d9094d68024475e2430343182
>
> That is, you ask for a refname as usual even though it is not part
> of ls-remote response, or you ask for the commit object that is at
> the tip of whatever hidden ref you are interested in.
Although I can understand the pain of slow network performance, somehow
this proposal gives me the feeling of being expeditious rather than elegant.
Could the problem be solved in some other way? Maybe such references
could be stored in a second repository or in a separate namespace (in
the sense of gitnamespaces(7)) to prevent their creating overhead when
they are unneeded?
And *if* reference hiding makes sense, it seems to me that the client,
not the server, should be the one who decides which server references it
is interested in (though I understand that would require a protocol
change). Otherwise the git repository *relies* on out-of-band channels
for its functionality. If I understand correctly, a user would have *no
way* to discover, via git, what hidden references are contained in a
remote repository, or indeed even that the repo contains a hidden
namespace. For example this would make it impossible to clean up
obsolete "hidden" references on a remote repository without the
supplementary information stored elsewhere. And if anybody accidentally
creates a reference in a hidden namespace by hand, it will just sit
there undetectably, forever.
I assume (though I've never checked) that a server does not let a client
ask for a SHA1 that is not currently reachable from a server-side
reference, and I assume that that you are not proposing to change this
policy. But allowing objects to be fetched from a hidden reference
opens up some "interesting" possibilities:
* A pusher could upload arbitrary content to a public git server under a
cryptic hidden reference name. Most people would be completely unable
to see this content, unless given the SHA1 or the reference name by the
pusher. Thus this mechanism could be used as a dark channel to exchange
arbitrary data relatively secretly.
* Somebody could push a trojan version of code to a hidden reference in
a project, then pass the SHA1 to a victim. The victim might trust the
code because it comes from a known project website, even though the code
would be invisible to other project developers and thus impossible for
them to audit. And even if they learned about the trojan's SHA1 they
would be unable to remove it from their repository because they have no
way to find out the name of the hidden reference!
Obviously these hacks would only be possible for a bad guy with push
privileges to a repository that has turned on hidden references, but I
think they are sobering nevertheless.
These worries would go away if reference hiding were configured on the
client rather than on the server.
A second point: currently, the output of "git show-ref -d" and "git
ls-remote ." are almost identical. Under your proposal, I believe that
the hiderefs would only be omitted from the latter. Would it be useful
to add an option to "git show-ref" to make it omit the "hiderefs" refs?
And maybe another option to make it display *only* the hideref refs?
And in the bikeshedding department, I wonder if "hiderefs" is the best
name for the config setting. "hiderefs", implies to me that the refs
are actively hidden and not available to the client in any way. But in
fact they are just not advertised; they can be fetched normally. Maybe
another name would be more suggestive of its true effect, for example
"quietrefs" or "noadvertiserefs".
Michael
--
Michael Haggerty
mhagger@alum.mit.edu
http://softwareswirl.blogspot.com/
^ permalink raw reply
* [PATCH 1/3] t0050: known breakage vanished in merge (case change)
From: Torsten Bögershausen @ 2013-01-19 7:19 UTC (permalink / raw)
To: git; +Cc: tboegi
This test case has passed ever since:
commit 0047dd2fd1fc1980913901c5fa098357482c2842
Author: Steffen Prohaska <prohaska@zib.de>
Date: Thu May 15 07:19:54 2008 +0200
t0050: Fix merge test on case sensitive file systems
Demand it to pass by using test_expect_success
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t0050-filesystem.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index 78816d9..ccd685d 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -77,7 +77,7 @@ $test_case 'rename (case change)' '
'
-$test_case 'merge (case change)' '
+test_expect_success 'merge (case change)' '
rm -f CamelCase &&
rm -f camelcase &&
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [PATCH 2/3] t0050: honor CASE_INSENSITIVE_FS in add (with different case)
From: Torsten Bögershausen @ 2013-01-19 7:19 UTC (permalink / raw)
To: git; +Cc: tboegi
The test case "add (with different case)" indicates a
known breakage when run on a case sensitive file system.
The test is invalid for case sensitive file system,
check the precondition CASE_INSENSITIVE_FS before running it.
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t0050-filesystem.sh | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index ccd685d..a6fa3c5 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -88,7 +88,7 @@ test_expect_success 'merge (case change)' '
-test_expect_failure 'add (with different case)' '
+test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' '
git reset --hard initial &&
rm camelcase &&
--
1.8.0.197.g5a90748
^ permalink raw reply related
* [PATCH 3/3] t0050: Use TAB for indentation
From: Torsten Bögershausen @ 2013-01-19 7:19 UTC (permalink / raw)
To: git; +Cc: tboegi
Use one TAB for indentation and remove empty lines
Signed-off-by: Torsten Bögershausen <tboegi@web.de>
---
t/t0050-filesystem.sh | 48 +++++++++++++++---------------------------------
1 file changed, 15 insertions(+), 33 deletions(-)
diff --git a/t/t0050-filesystem.sh b/t/t0050-filesystem.sh
index a6fa3c5..05d78d2 100755
--- a/t/t0050-filesystem.sh
+++ b/t/t0050-filesystem.sh
@@ -29,12 +29,10 @@ test_have_prereq SYMLINKS ||
if test_have_prereq CASE_INSENSITIVE_FS
then
test_expect_success "detection of case insensitive filesystem during repo init" '
-
test $(git config --bool core.ignorecase) = true
'
else
test_expect_success "detection of case insensitive filesystem during repo init" '
-
test_must_fail git config --bool core.ignorecase >/dev/null ||
test $(git config --bool core.ignorecase) = false
'
@@ -43,20 +41,17 @@ fi
if test_have_prereq SYMLINKS
then
test_expect_success "detection of filesystem w/o symlink support during repo init" '
-
test_must_fail git config --bool core.symlinks ||
test "$(git config --bool core.symlinks)" = true
'
else
test_expect_success "detection of filesystem w/o symlink support during repo init" '
-
v=$(git config --bool core.symlinks) &&
test "$v" = false
'
fi
test_expect_success "setup case tests" '
-
git config core.ignorecase true &&
touch camelcase &&
git add camelcase &&
@@ -67,29 +62,23 @@ test_expect_success "setup case tests" '
git mv tmp CamelCase &&
git commit -m "rename" &&
git checkout -f master
-
'
$test_case 'rename (case change)' '
-
git mv camelcase CamelCase &&
git commit -m "rename"
-
'
test_expect_success 'merge (case change)' '
-
rm -f CamelCase &&
rm -f camelcase &&
git reset --hard initial &&
git merge topic
-
'
test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' '
-
git reset --hard initial &&
rm camelcase &&
echo 1 >CamelCase &&
@@ -97,37 +86,30 @@ test_expect_failure CASE_INSENSITIVE_FS 'add (with different case)' '
camel=$(git ls-files | grep -i camelcase) &&
test $(echo "$camel" | wc -l) = 1 &&
test "z$(git cat-file blob :$camel)" = z1
-
'
test_expect_success "setup unicode normalization tests" '
-
- test_create_repo unicode &&
- cd unicode &&
- touch "$aumlcdiar" &&
- git add "$aumlcdiar" &&
- git commit -m initial &&
- git tag initial &&
- git checkout -b topic &&
- git mv $aumlcdiar tmp &&
- git mv tmp "$auml" &&
- git commit -m rename &&
- git checkout -f master
-
+ test_create_repo unicode &&
+ cd unicode &&
+ touch "$aumlcdiar" &&
+ git add "$aumlcdiar" &&
+ git commit -m initial &&
+ git tag initial &&
+ git checkout -b topic &&
+ git mv $aumlcdiar tmp &&
+ git mv tmp "$auml" &&
+ git commit -m rename &&
+ git checkout -f master
'
$test_unicode 'rename (silent unicode normalization)' '
-
- git mv "$aumlcdiar" "$auml" &&
- git commit -m rename
-
+ git mv "$aumlcdiar" "$auml" &&
+ git commit -m rename
'
$test_unicode 'merge (silent unicode normalization)' '
-
- git reset --hard initial &&
- git merge topic
-
+ git reset --hard initial &&
+ git merge topic
'
test_done
--
1.8.0.197.g5a90748
^ permalink raw reply related
* Re* t9902 fails
From: Junio C Hamano @ 2013-01-19 7:52 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Jean-Noël AVILA, Jonathan Nieder, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <50FA316E.8060807@web.de>
Torsten Bögershausen <tboegi@web.de> writes:
> would it be possible to run
> "git status"
> and share the result with us?
>
> And did you try Jonathans patch?
It may hide the immediate issue, but I am afraid Jonathan's patch
does not fix anything fundamental. If you do this:
git checkout next
make
git checkout master ;# without 'make clean'
make && cd t && sh ./t9902-*.sh
then the completion machinery will see the leftover git-check-ignore
at the top of the working tree (which is the $GIT_EXEC_PATH) and the
test that expects "check" to expand only to "checkout" will fail,
because 'master' does not have exclusion definition for check-ignore,
even though it knows check-attr, check-ref-format and checkout-index
are to be excluded as "plumbing".
So if you come up with a brilliant idea to add "git cherry-pack"
command and did this:
git checkout -b tb/cherry-pack
edit Makefile builtin/cherry-pack.c builtin.h git.c ...
git add builtin/cherry-pack.c
make test
git commit -a -m "cherry-pack: new command"
git checkout master ;# without 'make clean'
make && cd t && sh ./t9902-*.sh
the test will break exactly the same way.
If we really wanted to exclude random build artifacts that the
current checkout did not build, you have to do one of these things:
(1) at the beginning of t9902, "rm -fr" a temporary location,
install the built product with a custom DESTDIR set to that
temporary location that we now know is empty, and point
GIT_EXEC_PATH to the libexec/git-core directory in that
temporary location, so that "git help -a" run in the completion
script will find _only_ the executable we would install; or
(2) instead of being inclusive, collecting all executable in
GIT_EXEC_PATH that happens to be named "git-", add a mode to
"git help" that lists those that we know to be standard
commands that the users may want to complete from the command
line.
An outline to do (2) would look like this patch, but I didn't check
other consumers of command-list.txt, so this may be breaking them in
unplanned ways.
builtin/help.c | 35 ++++++++++---------------
command-list.txt | 4 +--
contrib/completion/git-completion.bash | 14 +---------
generate-cmdlist.sh | 13 +++++++++-
help.c | 47 ++++++++++++++++++++++++++++++++--
help.h | 1 +
6 files changed, 75 insertions(+), 39 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index bd86253..32e7d64 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -6,7 +6,6 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
-#include "common-cmds.h"
#include "parse-options.h"
#include "run-command.h"
#include "column.h"
@@ -36,11 +35,16 @@ enum help_format {
static const char *html_path;
-static int show_all = 0;
+#define HELP_SHOW_ALL 1
+#define HELP_SHOW_STANDARD 2
+static int show_what;
static unsigned int colopts;
static enum help_format help_format = HELP_FORMAT_NONE;
static struct option builtin_help_options[] = {
- OPT_BOOLEAN('a', "all", &show_all, N_("print all available commands")),
+ OPT_SET_INT('a', "all", &show_what, N_("print all available commands"),
+ HELP_SHOW_ALL),
+ OPT_SET_INT(0, "standard", &show_what, N_("print all available commands"),
+ HELP_SHOW_STANDARD),
OPT_SET_INT('m', "man", &help_format, N_("show man page"), HELP_FORMAT_MAN),
OPT_SET_INT('w', "web", &help_format, N_("show manual in web browser"),
HELP_FORMAT_WEB),
@@ -287,23 +291,6 @@ static int git_help_config(const char *var, const char *value, void *cb)
static struct cmdnames main_cmds, other_cmds;
-void list_common_cmds_help(void)
-{
- int i, longest = 0;
-
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- if (longest < strlen(common_cmds[i].name))
- longest = strlen(common_cmds[i].name);
- }
-
- puts(_("The most commonly used git commands are:"));
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- printf(" %s ", common_cmds[i].name);
- mput_char(' ', longest - strlen(common_cmds[i].name));
- puts(_(common_cmds[i].help));
- }
-}
-
static int is_git_command(const char *s)
{
return is_in_cmdlist(&main_cmds, s) ||
@@ -442,12 +429,18 @@ int cmd_help(int argc, const char **argv, const char *prefix)
builtin_help_usage, 0);
parsed_help_format = help_format;
- if (show_all) {
+ if (show_what == HELP_SHOW_ALL) {
git_config(git_help_config, NULL);
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
list_commands(colopts, &main_cmds, &other_cmds);
printf("%s\n", _(git_more_info_string));
return 0;
+ } else if (show_what == HELP_SHOW_STANDARD) {
+ int i;
+ limit_to_standard(&main_cmds);
+ for (i = 0; i < main_cmds.cnt; i++)
+ printf("%s\n", main_cmds.names[i]->name);
+ return 0;
}
if (!argv[0]) {
diff --git a/command-list.txt b/command-list.txt
index 7e8cfec..94ce8ec 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -116,8 +116,8 @@ git-show mainporcelain common
git-show-branch ancillaryinterrogators
git-show-index plumbinginterrogators
git-show-ref plumbinginterrogators
-git-sh-i18n purehelpers
-git-sh-setup purehelpers
+git-sh-i18n purehelpers nocomplete
+git-sh-setup purehelpers nocomplete
git-stash mainporcelain
git-status mainporcelain common
git-stripspace purehelpers
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a4c48e1..46f22af 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -531,23 +531,11 @@ __git_complete_strategy ()
return 1
}
-__git_list_all_commands ()
-{
- local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
- do
- case $i in
- *--*) : helper pattern;;
- *) echo $i;;
- esac
- done
-}
-
__git_all_commands=
__git_compute_all_commands ()
{
test -n "$__git_all_commands" ||
- __git_all_commands=$(__git_list_all_commands)
+ __git_all_commands=$(git help --standard)
}
__git_list_porcelain_commands ()
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 9a4c9b9..7800af3 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -9,7 +9,7 @@ struct cmdname_help {
static struct cmdname_help common_cmds[] = {"
sed -n -e 's/^git-\([^ ]*\)[ ].* common.*/\1/p' command-list.txt |
-sort |
+LC_ALL=C LANG=C sort |
while read cmd
do
sed -n '
@@ -20,4 +20,15 @@ do
p
}' "Documentation/git-$cmd.txt"
done
+echo "};
+
+static const char *standard_cmd[] = {"
+
+LC_ALL=C LANG=C sort command-list.txt |
+sed -n -e '
+ /^git-[^ ]*[ ].* deprecated.*/d
+ /^git-[^ ]*[ ].* nocomplete.*/d
+ s/^git-\([^ ]*\)[ ].*/ "\1",/p
+'
+
echo "};"
diff --git a/help.c b/help.c
index 2a42ec6..2ad10db 100644
--- a/help.c
+++ b/help.c
@@ -182,7 +182,7 @@ void load_command_list(const char *prefix,
uniq(main_cmds);
}
- if (env_path) {
+ if (env_path && other_cmds) {
char *paths, *path, *colon;
path = paths = xstrdup(env_path);
while (1) {
@@ -201,7 +201,33 @@ void load_command_list(const char *prefix,
sizeof(*other_cmds->names), cmdname_compare);
uniq(other_cmds);
}
- exclude_cmds(other_cmds, main_cmds);
+
+ if (other_cmds)
+ exclude_cmds(other_cmds, main_cmds);
+}
+
+void limit_to_standard(struct cmdnames *cmds)
+{
+ int src = 0, dst = 0, ref = 0;
+
+ while (src < cmds->cnt && ref < ARRAY_SIZE(standard_cmd)) {
+ int cmp = strcmp(cmds->names[src]->name, standard_cmd[ref]);
+ if (cmp < 0) {
+ src++; /* not a standard command */
+ } else if (!cmp) {
+ if (dst != src) {
+ free(cmds->names[dst]);
+ cmds->names[dst] = cmds->names[src];
+ }
+ ref++;
+ dst++;
+ } else {
+ ref++; /* uninstalled standard command */
+ }
+ }
+ for (src = dst; src < cmds->cnt; src++)
+ free(cmds->names[src]);
+ cmds->cnt = dst;
}
void list_commands(unsigned int colopts,
@@ -223,6 +249,23 @@ void list_commands(unsigned int colopts,
}
}
+void list_common_cmds_help(void)
+{
+ int i, longest = 0;
+
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
+ if (longest < strlen(common_cmds[i].name))
+ longest = strlen(common_cmds[i].name);
+ }
+
+ puts(_("The most commonly used git commands are:"));
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
+ printf(" %s ", common_cmds[i].name);
+ mput_char(' ', longest - strlen(common_cmds[i].name));
+ puts(_(common_cmds[i].help));
+ }
+}
+
int is_in_cmdlist(struct cmdnames *c, const char *s)
{
int i;
diff --git a/help.h b/help.h
index 0ae5a12..ce0d2a5 100644
--- a/help.h
+++ b/help.h
@@ -21,6 +21,7 @@ extern const char *help_unknown_cmd(const char *cmd);
extern void load_command_list(const char *prefix,
struct cmdnames *main_cmds,
struct cmdnames *other_cmds);
+extern void limit_to_standard(struct cmdnames *);
extern void add_cmdname(struct cmdnames *cmds, const char *name, int len);
/* Here we require that excludes is a sorted list. */
extern void exclude_cmds(struct cmdnames *cmds, struct cmdnames *excludes);
^ permalink raw reply related
* Re: [PATCH v2 4/8] git_remote_helpers: use 2to3 if building with Python 3
From: Sverre Rabbelier @ 2013-01-19 7:52 UTC (permalink / raw)
To: John Keeping; +Cc: Junio C Hamano, Michael Haggerty, Git List, Pete Wyckoff
In-Reply-To: <20130118103241.GM4574@serenity.lan>
Assuming you tried this out on both 2.x and 3.x:
Acked-by: Sverre Rabbelier <srabbelier@gmail.com>
On Fri, Jan 18, 2013 at 2:32 AM, John Keeping <john@keeping.me.uk> wrote:
> On Thu, Jan 17, 2013 at 09:15:08PM -0800, Sverre Rabbelier wrote:
>> On Thu, Jan 17, 2013 at 10:53 AM, John Keeping <john@keeping.me.uk> wrote:
>> > [1] http://wiki.python.org/moin/PortingPythonToPy3k
>>
>> This link seems dead.
>
> Looks like the Python wiki is down [1].
>
> I'll replace it with [2] since the content is similar and it should be
> easier to find a mirror of the Python documentation than of the wiki.
>
> [1] http://pyfound.blogspot.co.uk/2013/01/wikipythonorg-compromised.html
> [2] http://docs.python.org/3.3/howto/pyporting.html#during-installation
>
>
> John
--
Cheers,
Sverre Rabbelier
^ permalink raw reply
* [PATCH 1/2] help: include <common-cmds.h> only in one file
From: Junio C Hamano @ 2013-01-19 8:00 UTC (permalink / raw)
To: git
Cc: Torsten Bögershausen, Jean-Noël AVILA, Jonathan Nieder,
Jeff King, Nguyễn Thái Ngọc Duy,
Felipe Contreras
In-Reply-To: <7vwqv9obie.fsf_-_@alter.siamese.dyndns.org>
This header not only declares but also defines the contents of the
array that holds the list of command names and help text. Do not
include it in multiple places to waste text space.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is a real "cleanup" patch.
builtin/help.c | 18 ------------------
help.c | 17 +++++++++++++++++
2 files changed, 17 insertions(+), 18 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index bd86253..6067a61 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -6,7 +6,6 @@
#include "cache.h"
#include "builtin.h"
#include "exec_cmd.h"
-#include "common-cmds.h"
#include "parse-options.h"
#include "run-command.h"
#include "column.h"
@@ -287,23 +286,6 @@ static int git_help_config(const char *var, const char *value, void *cb)
static struct cmdnames main_cmds, other_cmds;
-void list_common_cmds_help(void)
-{
- int i, longest = 0;
-
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- if (longest < strlen(common_cmds[i].name))
- longest = strlen(common_cmds[i].name);
- }
-
- puts(_("The most commonly used git commands are:"));
- for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
- printf(" %s ", common_cmds[i].name);
- mput_char(' ', longest - strlen(common_cmds[i].name));
- puts(_(common_cmds[i].help));
- }
-}
-
static int is_git_command(const char *s)
{
return is_in_cmdlist(&main_cmds, s) ||
diff --git a/help.c b/help.c
index 2a42ec6..1dfa0b0 100644
--- a/help.c
+++ b/help.c
@@ -223,6 +223,23 @@ void list_commands(unsigned int colopts,
}
}
+void list_common_cmds_help(void)
+{
+ int i, longest = 0;
+
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
+ if (longest < strlen(common_cmds[i].name))
+ longest = strlen(common_cmds[i].name);
+ }
+
+ puts(_("The most commonly used git commands are:"));
+ for (i = 0; i < ARRAY_SIZE(common_cmds); i++) {
+ printf(" %s ", common_cmds[i].name);
+ mput_char(' ', longest - strlen(common_cmds[i].name));
+ puts(_(common_cmds[i].help));
+ }
+}
+
int is_in_cmdlist(struct cmdnames *c, const char *s)
{
int i;
--
1.8.1.1.454.g48d39c0
^ permalink raw reply related
* [PATCH 2/2] help --standard: list standard commands
From: Junio C Hamano @ 2013-01-19 8:02 UTC (permalink / raw)
To: git
Cc: Torsten Bögershausen, Jean-Noël AVILA, Jonathan Nieder,
Jeff King, Nguyễn Thái Ngọc Duy,
Felipe Contreras
In-Reply-To: <7vpq11ob4w.fsf_-_@alter.siamese.dyndns.org>
If you run "make" on a branch that adds "git check-ignore", checkout
an older branch that did not know about the command without "make clean",
and the run t9902 test, the completion script fails to exclude the
"check-ignore" command from candidates to complete "check".
This is because the completion script asks "git help -a" to show
every executable that begins with "git-" in the GIT_EXEC_PATH, and
because we run tests with GIT_EXEC_PATH set to the top of the
working tree, that has the executable we just built, in order to
test these before installing. Leftover "git check-ignore" that we
did not build for the current version gets in the way.
One way to solve this is to restrict the completion to only the
commands we know about.
Note that this will make the completion useless in real life for
some people, as they do want to get their custom commands on their
$PATH to be included in the completion.
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
* This is not a real patch, for the reasons stated.
builtin/help.c | 17 ++++++++++++++---
command-list.txt | 4 ++--
contrib/completion/git-completion.bash | 14 +-------------
generate-cmdlist.sh | 13 ++++++++++++-
help.c | 30 ++++++++++++++++++++++++++++--
help.h | 1 +
6 files changed, 58 insertions(+), 21 deletions(-)
diff --git a/builtin/help.c b/builtin/help.c
index 6067a61..32e7d64 100644
--- a/builtin/help.c
+++ b/builtin/help.c
@@ -35,11 +35,16 @@ enum help_format {
static const char *html_path;
-static int show_all = 0;
+#define HELP_SHOW_ALL 1
+#define HELP_SHOW_STANDARD 2
+static int show_what;
static unsigned int colopts;
static enum help_format help_format = HELP_FORMAT_NONE;
static struct option builtin_help_options[] = {
- OPT_BOOLEAN('a', "all", &show_all, N_("print all available commands")),
+ OPT_SET_INT('a', "all", &show_what, N_("print all available commands"),
+ HELP_SHOW_ALL),
+ OPT_SET_INT(0, "standard", &show_what, N_("print all available commands"),
+ HELP_SHOW_STANDARD),
OPT_SET_INT('m', "man", &help_format, N_("show man page"), HELP_FORMAT_MAN),
OPT_SET_INT('w', "web", &help_format, N_("show manual in web browser"),
HELP_FORMAT_WEB),
@@ -424,12 +429,18 @@ int cmd_help(int argc, const char **argv, const char *prefix)
builtin_help_usage, 0);
parsed_help_format = help_format;
- if (show_all) {
+ if (show_what == HELP_SHOW_ALL) {
git_config(git_help_config, NULL);
printf(_("usage: %s%s"), _(git_usage_string), "\n\n");
list_commands(colopts, &main_cmds, &other_cmds);
printf("%s\n", _(git_more_info_string));
return 0;
+ } else if (show_what == HELP_SHOW_STANDARD) {
+ int i;
+ limit_to_standard(&main_cmds);
+ for (i = 0; i < main_cmds.cnt; i++)
+ printf("%s\n", main_cmds.names[i]->name);
+ return 0;
}
if (!argv[0]) {
diff --git a/command-list.txt b/command-list.txt
index 7e8cfec..94ce8ec 100644
--- a/command-list.txt
+++ b/command-list.txt
@@ -116,8 +116,8 @@ git-show mainporcelain common
git-show-branch ancillaryinterrogators
git-show-index plumbinginterrogators
git-show-ref plumbinginterrogators
-git-sh-i18n purehelpers
-git-sh-setup purehelpers
+git-sh-i18n purehelpers nocomplete
+git-sh-setup purehelpers nocomplete
git-stash mainporcelain
git-status mainporcelain common
git-stripspace purehelpers
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index a4c48e1..46f22af 100644
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -531,23 +531,11 @@ __git_complete_strategy ()
return 1
}
-__git_list_all_commands ()
-{
- local i IFS=" "$'\n'
- for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
- do
- case $i in
- *--*) : helper pattern;;
- *) echo $i;;
- esac
- done
-}
-
__git_all_commands=
__git_compute_all_commands ()
{
test -n "$__git_all_commands" ||
- __git_all_commands=$(__git_list_all_commands)
+ __git_all_commands=$(git help --standard)
}
__git_list_porcelain_commands ()
diff --git a/generate-cmdlist.sh b/generate-cmdlist.sh
index 9a4c9b9..7800af3 100755
--- a/generate-cmdlist.sh
+++ b/generate-cmdlist.sh
@@ -9,7 +9,7 @@ struct cmdname_help {
static struct cmdname_help common_cmds[] = {"
sed -n -e 's/^git-\([^ ]*\)[ ].* common.*/\1/p' command-list.txt |
-sort |
+LC_ALL=C LANG=C sort |
while read cmd
do
sed -n '
@@ -20,4 +20,15 @@ do
p
}' "Documentation/git-$cmd.txt"
done
+echo "};
+
+static const char *standard_cmd[] = {"
+
+LC_ALL=C LANG=C sort command-list.txt |
+sed -n -e '
+ /^git-[^ ]*[ ].* deprecated.*/d
+ /^git-[^ ]*[ ].* nocomplete.*/d
+ s/^git-\([^ ]*\)[ ].*/ "\1",/p
+'
+
echo "};"
diff --git a/help.c b/help.c
index 1dfa0b0..2ad10db 100644
--- a/help.c
+++ b/help.c
@@ -182,7 +182,7 @@ void load_command_list(const char *prefix,
uniq(main_cmds);
}
- if (env_path) {
+ if (env_path && other_cmds) {
char *paths, *path, *colon;
path = paths = xstrdup(env_path);
while (1) {
@@ -201,7 +201,33 @@ void load_command_list(const char *prefix,
sizeof(*other_cmds->names), cmdname_compare);
uniq(other_cmds);
}
- exclude_cmds(other_cmds, main_cmds);
+
+ if (other_cmds)
+ exclude_cmds(other_cmds, main_cmds);
+}
+
+void limit_to_standard(struct cmdnames *cmds)
+{
+ int src = 0, dst = 0, ref = 0;
+
+ while (src < cmds->cnt && ref < ARRAY_SIZE(standard_cmd)) {
+ int cmp = strcmp(cmds->names[src]->name, standard_cmd[ref]);
+ if (cmp < 0) {
+ src++; /* not a standard command */
+ } else if (!cmp) {
+ if (dst != src) {
+ free(cmds->names[dst]);
+ cmds->names[dst] = cmds->names[src];
+ }
+ ref++;
+ dst++;
+ } else {
+ ref++; /* uninstalled standard command */
+ }
+ }
+ for (src = dst; src < cmds->cnt; src++)
+ free(cmds->names[src]);
+ cmds->cnt = dst;
}
void list_commands(unsigned int colopts,
diff --git a/help.h b/help.h
index 0ae5a12..ce0d2a5 100644
--- a/help.h
+++ b/help.h
@@ -21,6 +21,7 @@ extern const char *help_unknown_cmd(const char *cmd);
extern void load_command_list(const char *prefix,
struct cmdnames *main_cmds,
struct cmdnames *other_cmds);
+extern void limit_to_standard(struct cmdnames *);
extern void add_cmdname(struct cmdnames *cmds, const char *name, int len);
/* Here we require that excludes is a sorted list. */
extern void exclude_cmds(struct cmdnames *cmds, struct cmdnames *excludes);
--
1.8.1.1.454.g48d39c0
^ permalink raw reply related
* [PATCH 0/2] GIT, Git, git
From: Thomas Ackermann @ 2013-01-19 9:57 UTC (permalink / raw)
To: th.acker, git
Git changed its 'official' system name from 'GIT' to 'Git' in v1.6.5.3
(as can be seen in the corresponding release note where 'GIT' was
changed to 'Git' in the header line).
Alas the documention uses 'GIT', 'Git' or even 'git' to refer to the
Git system. So change every occurrence of 'GIT" and 'git' to 'Git'
whenever Git as a system is referred to (but don't do this change
in the release notes because they constitute a history orthogonal
to the history versioned by Git).
[PATCH 1/2] Change old system name 'GIT' to 'Git'
[PATCH 2/2] Change 'git' to 'Git' whenever the whole system is referred to
Documentation/CodingGuidelines | 14 +-
Documentation/SubmittingPatches | 12 +-
Documentation/asciidoc.conf | 2 +-
Documentation/blame-options.txt | 4 +-
Documentation/config.txt | 106 +++++------
Documentation/diff-config.txt | 2 +-
Documentation/diff-options.txt | 4 +-
Documentation/everyday.txt | 10 +-
Documentation/git-apply.txt | 2 +-
Documentation/git-archimport.txt | 14 +-
Documentation/git-archive.txt | 2 +-
Documentation/git-bisect-lk2009.txt | 22 +--
Documentation/git-bisect.txt | 4 +-
Documentation/git-blame.txt | 2 +-
Documentation/git-branch.txt | 2 +-
Documentation/git-bundle.txt | 2 +-
Documentation/git-check-ref-format.txt | 4 +-
Documentation/git-checkout.txt | 4 +-
Documentation/git-clean.txt | 6 +-
Documentation/git-clone.txt | 12 +-
Documentation/git-commit-tree.txt | 2 +-
Documentation/git-commit.txt | 6 +-
Documentation/git-credential-cache.txt | 4 +-
Documentation/git-credential-store.txt | 6 +-
Documentation/git-credential.txt | 6 +-
Documentation/git-cvsexportcommit.txt | 6 +-
Documentation/git-cvsimport.txt | 10 +-
Documentation/git-cvsserver.txt | 20 +-
Documentation/git-daemon.txt | 10 +-
Documentation/git-describe.txt | 2 +-
Documentation/git-diff.txt | 2 +-
Documentation/git-difftool.txt | 2 +-
Documentation/git-fetch.txt | 2 +-
Documentation/git-filter-branch.txt | 4 +-
Documentation/git-format-patch.txt | 10 +-
Documentation/git-fsck.txt | 6 +-
Documentation/git-grep.txt | 2 +-
Documentation/git-hash-object.txt | 2 +-
Documentation/git-help.txt | 2 +-
Documentation/git-http-backend.txt | 2 +-
Documentation/git-index-pack.txt | 6 +-
Documentation/git-init.txt | 16 +-
Documentation/git-log.txt | 2 +-
Documentation/git-ls-files.txt | 2 +-
Documentation/git-merge-index.txt | 4 +-
Documentation/git-merge.txt | 4 +-
Documentation/git-mergetool--lib.txt | 2 +-
Documentation/git-mktag.txt | 4 +-
Documentation/git-mv.txt | 2 +-
Documentation/git-p4.txt | 66 +++----
Documentation/git-pack-objects.txt | 12 +-
Documentation/git-pull.txt | 8 +-
Documentation/git-push.txt | 8 +-
Documentation/git-quiltimport.txt | 4 +-
Documentation/git-rebase.txt | 2 +-
Documentation/git-reflog.txt | 2 +-
Documentation/git-remote-ext.txt | 14 +-
Documentation/git-remote-fd.txt | 10 +-
Documentation/git-remote-helpers.txt | 46 ++---
Documentation/git-replace.txt | 2 +-
Documentation/git-rev-list.txt | 2 +-
Documentation/git-rev-parse.txt | 4 +-
Documentation/git-rm.txt | 8 +-
Documentation/git-send-email.txt | 2 +-
Documentation/git-send-pack.txt | 2 +-
Documentation/git-sh-setup.txt | 4 +-
Documentation/git-show-index.txt | 2 +-
Documentation/git-status.txt | 8 +-
Documentation/git-stripspace.txt | 2 +-
Documentation/git-submodule.txt | 2 +-
Documentation/git-svn.txt | 88 ++++-----
Documentation/git-tag.txt | 2 +-
Documentation/git-tools.txt | 40 ++--
Documentation/git-update-index.txt | 16 +-
Documentation/git-update-ref.txt | 2 +-
Documentation/git-upload-archive.txt | 2 +-
Documentation/git-upload-pack.txt | 2 +-
Documentation/git-var.txt | 12 +-
Documentation/git-verify-pack.txt | 2 +-
Documentation/git-verify-tag.txt | 2 +-
Documentation/git-web--browse.txt | 4 +-
Documentation/git-whatchanged.txt | 4 +-
Documentation/git.txt | 90 ++++-----
Documentation/gitattributes.txt | 68 +++----
Documentation/gitcli.txt | 14 +-
Documentation/gitcore-tutorial.txt | 150 +++++++--------
Documentation/gitcredentials.txt | 24 +--
Documentation/gitcvs-migration.txt | 20 +-
Documentation/gitdiffcore.txt | 2 +-
Documentation/gitglossary.txt | 4 +-
Documentation/githooks.txt | 8 +-
Documentation/gitignore.txt | 22 +--
Documentation/gitk.txt | 8 +-
Documentation/gitmodules.txt | 4 +-
Documentation/gitnamespaces.txt | 2 +-
Documentation/gitrepository-layout.txt | 10 +-
Documentation/gitrevisions.txt | 2 +-
Documentation/gittutorial-2.txt | 38 ++--
Documentation/gittutorial.txt | 48 ++---
Documentation/gitweb.conf.txt | 32 ++--
Documentation/gitweb.txt | 22 +--
Documentation/gitworkflows.txt | 6 +-
Documentation/glossary-content.txt | 58 +++---
Documentation/howto-index.sh | 4 +-
Documentation/howto/maintain-git.txt | 6 +-
Documentation/howto/new-command.txt | 20 +-
.../howto/rebase-from-internal-branch.txt | 6 +-
Documentation/howto/rebuild-from-update-hook.txt | 8 +-
.../howto/recover-corrupted-blob-object.txt | 4 +-
Documentation/howto/revert-a-faulty-merge.txt | 2 +-
Documentation/howto/revert-branch-rebase.txt | 4 +-
Documentation/howto/setup-git-server-over-http.txt | 18 +-
Documentation/howto/use-git-daemon.txt | 2 +-
.../howto/using-signed-tag-in-pull-request.txt | 4 +-
Documentation/i18n.txt | 8 +-
Documentation/merge-config.txt | 8 +-
Documentation/rev-list-options.txt | 4 +-
Documentation/revisions.txt | 2 +-
Documentation/technical/api-builtin.txt | 2 +-
Documentation/technical/api-config.txt | 10 +-
Documentation/technical/api-credentials.txt | 16 +-
Documentation/technical/api-directory-listing.txt | 2 +-
Documentation/technical/api-index-skel.txt | 4 +-
Documentation/technical/api-parse-options.txt | 2 +-
Documentation/technical/api-remote.txt | 2 +-
Documentation/technical/index-format.txt | 8 +-
Documentation/technical/pack-format.txt | 4 +-
Documentation/technical/pack-heuristics.txt | 20 +-
Documentation/technical/racy-git.txt | 26 +--
Documentation/urls-remotes.txt | 2 +-
Documentation/urls.txt | 2 +-
Documentation/user-manual.txt | 212 ++++++++++-----------
132 files changed, 904 insertions(+), 904 deletions(-)
---
Thomas
^ permalink raw reply
* [PATCH 1/2] Change old system name 'GIT' to 'Git'
From: Thomas Ackermann @ 2013-01-19 9:59 UTC (permalink / raw)
To: th.acker, git
In-Reply-To: <732444561.1327663.1358589465467.JavaMail.ngmail@webmail24.arcor-online.net>
Signed-off-by: Thomas Ackermann <th.acker@arcor.de>
---
Documentation/asciidoc.conf | 2 +-
Documentation/everyday.txt | 4 ++--
Documentation/git-clone.txt | 2 +-
Documentation/git-cvsexportcommit.txt | 2 +-
Documentation/git-cvsserver.txt | 8 ++++----
Documentation/git-daemon.txt | 4 ++--
Documentation/git-mv.txt | 2 +-
Documentation/git-send-email.txt | 2 +-
Documentation/git-tools.txt | 14 +++++++-------
Documentation/git-update-ref.txt | 2 +-
Documentation/git.txt | 2 +-
Documentation/gitcore-tutorial.txt | 4 ++--
Documentation/gitglossary.txt | 2 +-
Documentation/gittutorial.txt | 2 +-
Documentation/gitweb.txt | 2 +-
Documentation/gitworkflows.txt | 2 +-
Documentation/glossary-content.txt | 2 +-
Documentation/howto-index.sh | 2 +-
Documentation/howto/rebase-from-internal-branch.txt | 6 +++---
Documentation/howto/revert-branch-rebase.txt | 4 ++--
Documentation/howto/setup-git-server-over-http.txt | 4 ++--
Documentation/technical/api-index-skel.txt | 4 ++--
Documentation/technical/index-format.txt | 6 +++---
Documentation/technical/pack-format.txt | 4 ++--
Documentation/user-manual.txt | 4 ++--
25 files changed, 46 insertions(+), 46 deletions(-)
diff --git a/Documentation/asciidoc.conf b/Documentation/asciidoc.conf
index 1273a85..2c16c53 100644
--- a/Documentation/asciidoc.conf
+++ b/Documentation/asciidoc.conf
@@ -4,7 +4,7 @@
#
# Note, {0} is the manpage section, while {target} is the command.
#
-# Show GIT link as: <command>(<section>); if section is defined, else just show
+# Show Git link as: <command>(<section>); if section is defined, else just show
# the command.
[macros]
diff --git a/Documentation/everyday.txt b/Documentation/everyday.txt
index 048337b..6acfd33 100644
--- a/Documentation/everyday.txt
+++ b/Documentation/everyday.txt
@@ -1,4 +1,4 @@
-Everyday GIT With 20 Commands Or So
+Everyday Git With 20 Commands Or So
===================================
<<Individual Developer (Standalone)>> commands are essential for
@@ -229,7 +229,7 @@ commands in addition to the ones needed by participants.
Examples
~~~~~~~~
-My typical GIT day.::
+My typical Git day.::
+
------------
$ git status <1>
diff --git a/Documentation/git-clone.txt b/Documentation/git-clone.txt
index 7fefdb0..597048b 100644
--- a/Documentation/git-clone.txt
+++ b/Documentation/git-clone.txt
@@ -125,7 +125,7 @@ objects from the source repository into a pack in the cloned repository.
No checkout of HEAD is performed after the clone is complete.
--bare::
- Make a 'bare' GIT repository. That is, instead of
+ Make a 'bare' Git repository. That is, instead of
creating `<directory>` and placing the administrative
files in `<directory>/.git`, make the `<directory>`
itself the `$GIT_DIR`. This obviously implies the `-n`
diff --git a/Documentation/git-cvsexportcommit.txt b/Documentation/git-cvsexportcommit.txt
index 7f79cec..a671e22 100644
--- a/Documentation/git-cvsexportcommit.txt
+++ b/Documentation/git-cvsexportcommit.txt
@@ -15,7 +15,7 @@ SYNOPSIS
DESCRIPTION
-----------
-Exports a commit from GIT to a CVS checkout, making it easier
+Exports a commit from Git to a CVS checkout, making it easier
to merge patches from a git repository into a CVS repository.
Specify the name of a CVS checkout using the -w switch or execute it
diff --git a/Documentation/git-cvsserver.txt b/Documentation/git-cvsserver.txt
index 88d814a..36d069b 100644
--- a/Documentation/git-cvsserver.txt
+++ b/Documentation/git-cvsserver.txt
@@ -72,9 +72,9 @@ plugin. Most functionality works fine with both of these clients.
LIMITATIONS
-----------
-CVS clients cannot tag, branch or perform GIT merges.
+CVS clients cannot tag, branch or perform Git merges.
-'git-cvsserver' maps GIT branches to CVS modules. This is very different
+'git-cvsserver' maps Git branches to CVS modules. This is very different
from what most CVS users would expect since in CVS modules usually represent
one or more directories.
@@ -130,7 +130,7 @@ Then provide your password via the pserver method, for example:
------
cvs -d:pserver:someuser:somepassword <at> server/path/repo.git co <HEAD_name>
------
-No special setup is needed for SSH access, other than having GIT tools
+No special setup is needed for SSH access, other than having Git tools
in the PATH. If you have clients that do not accept the CVS_SERVER
environment variable, you can rename 'git-cvsserver' to `cvs`.
@@ -197,7 +197,7 @@ allowing access over SSH.
shell is bash, .bashrc may be a reasonable alternative.
5. Clients should now be able to check out the project. Use the CVS 'module'
- name to indicate what GIT 'head' you want to check out. This also sets the
+ name to indicate what Git 'head' you want to check out. This also sets the
name of your newly checked-out directory, unless you tell it otherwise with
`-d <dir_name>`. For example, this checks out 'master' branch to the
`project-master` directory:
diff --git a/Documentation/git-daemon.txt b/Documentation/git-daemon.txt
index 7e5098a..80de4f6 100644
--- a/Documentation/git-daemon.txt
+++ b/Documentation/git-daemon.txt
@@ -51,7 +51,7 @@ OPTIONS
--base-path=<path>::
Remap all the path requests as relative to the given path.
- This is sort of "GIT root" - if you run 'git daemon' with
+ This is sort of "Git root" - if you run 'git daemon' with
'--base-path=/srv/git' on example.com, then if you later try to pull
'git://example.com/hello.git', 'git daemon' will interpret the path
as '/srv/git/hello.git'.
@@ -73,7 +73,7 @@ OPTIONS
whitelist.
--export-all::
- Allow pulling from all directories that look like GIT repositories
+ Allow pulling from all directories that look like Git repositories
(have the 'objects' and 'refs' subdirectories), even if they
do not have the 'git-daemon-export-ok' file.
diff --git a/Documentation/git-mv.txt b/Documentation/git-mv.txt
index e3c8448..bcb79c9 100644
--- a/Documentation/git-mv.txt
+++ b/Documentation/git-mv.txt
@@ -34,7 +34,7 @@ OPTIONS
-k::
Skip move or rename actions which would lead to an error
condition. An error happens when a source is neither existing nor
- controlled by GIT, or when it would overwrite an existing
+ controlled by Git, or when it would overwrite an existing
file unless '-f' is given.
-n::
--dry-run::
diff --git a/Documentation/git-send-email.txt b/Documentation/git-send-email.txt
index eeb561c..44a1f7c 100644
--- a/Documentation/git-send-email.txt
+++ b/Documentation/git-send-email.txt
@@ -67,7 +67,7 @@ The --cc option must be repeated for each user you want on the cc list.
When '--compose' is used, git send-email will use the From, Subject, and
In-Reply-To headers specified in the message. If the body of the message
(what you type after the headers and a blank line) only contains blank
-(or GIT: prefixed) lines the summary won't be sent, but From, Subject,
+(or Git: prefixed) lines the summary won't be sent, but From, Subject,
and In-Reply-To headers will be used unless they are removed.
+
Missing From or In-Reply-To headers will be prompted for.
diff --git a/Documentation/git-tools.txt b/Documentation/git-tools.txt
index a96403c..8428827 100644
--- a/Documentation/git-tools.txt
+++ b/Documentation/git-tools.txt
@@ -19,24 +19,24 @@ Alternative/Augmentative Porcelains
Cogito is a version control system layered on top of the git tree history
storage system. It aims at seamless user interface and ease of use,
- providing generally smoother user experience than the "raw" Core GIT
+ providing generally smoother user experience than the "raw" Core Git
itself and indeed many other version control systems.
Cogito is no longer maintained as most of its functionality
- is now in core GIT.
+ is now in core Git.
- *pg* (http://www.spearce.org/category/projects/scm/pg/)
- pg is a shell script wrapper around GIT to help the user manage a set of
+ pg is a shell script wrapper around Git to help the user manage a set of
patches to files. pg is somewhat like quilt or StGIT, but it does have a
slightly different feature set.
- *StGit* (http://www.procode.org/stgit/)
- Stacked GIT provides a quilt-like patch management functionality in the
- GIT environment. You can easily manage your patches in the scope of GIT
+ Stacked Git provides a quilt-like patch management functionality in the
+ Git environment. You can easily manage your patches in the scope of Git
until they get merged upstream.
@@ -45,7 +45,7 @@ History Viewers
- *gitk* (shipped with git-core)
- gitk is a simple Tk GUI for browsing history of GIT repositories easily.
+ gitk is a simple Tk GUI for browsing history of Git repositories easily.
- *gitview* (contrib/)
@@ -55,7 +55,7 @@ History Viewers
- *gitweb* (shipped with git-core)
- GITweb provides full-fledged web interface for GIT repositories.
+ GITweb provides full-fledged web interface for Git repositories.
- *qgit* (http://digilander.libero.it/mcostalba/)
diff --git a/Documentation/git-update-ref.txt b/Documentation/git-update-ref.txt
index d377a35..0df13ff 100644
--- a/Documentation/git-update-ref.txt
+++ b/Documentation/git-update-ref.txt
@@ -73,7 +73,7 @@ in ref value. Log lines are formatted as:
Where "oldsha1" is the 40 character hexadecimal value previously
stored in <ref>, "newsha1" is the 40 character hexadecimal value of
<newvalue> and "committer" is the committer's name, email address
-and date in the standard GIT committer ident format.
+and date in the standard Git committer ident format.
Optionally with -m:
diff --git a/Documentation/git.txt b/Documentation/git.txt
index 555250d..1aac71e 100644
--- a/Documentation/git.txt
+++ b/Documentation/git.txt
@@ -890,7 +890,7 @@ See also the link:howto-index.html[howto] documents for some useful
examples.
The internals are documented in the
-link:technical/api-index.html[GIT API documentation].
+link:technical/api-index.html[Git API documentation].
Users migrating from CVS may also want to
read linkgit:gitcvs-migration[7].
diff --git a/Documentation/gitcore-tutorial.txt b/Documentation/gitcore-tutorial.txt
index 5325c5a..6a701dd 100644
--- a/Documentation/gitcore-tutorial.txt
+++ b/Documentation/gitcore-tutorial.txt
@@ -16,8 +16,8 @@ This tutorial explains how to use the "core" git commands to set up and
work with a git repository.
If you just need to use git as a revision control system you may prefer
-to start with "A Tutorial Introduction to GIT" (linkgit:gittutorial[7]) or
-link:user-manual.html[the GIT User Manual].
+to start with "A Tutorial Introduction to Git" (linkgit:gittutorial[7]) or
+link:user-manual.html[the Git User Manual].
However, an understanding of these low-level tools can be helpful if
you want to understand git's internals.
diff --git a/Documentation/gitglossary.txt b/Documentation/gitglossary.txt
index d77a45a..6d7b195 100644
--- a/Documentation/gitglossary.txt
+++ b/Documentation/gitglossary.txt
@@ -3,7 +3,7 @@ gitglossary(7)
NAME
----
-gitglossary - A GIT Glossary
+gitglossary - A Git Glossary
SYNOPSIS
--------
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index f1cb6f3..9dd45c4 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -656,7 +656,7 @@ digressions that may be interesting at this point are:
* linkgit:gitworkflows[7]: Gives an overview of recommended
workflows.
- * link:everyday.html[Everyday GIT with 20 Commands Or So]
+ * link:everyday.html[Everyday Git with 20 Commands Or So]
* linkgit:gitcvs-migration[7]: Git for CVS users.
diff --git a/Documentation/gitweb.txt b/Documentation/gitweb.txt
index 168e8bf..d364c3a 100644
--- a/Documentation/gitweb.txt
+++ b/Documentation/gitweb.txt
@@ -504,7 +504,7 @@ repositories, you can configure Apache like this:
The above configuration expects your public repositories to live under
'/pub/git' and will serve them as `http://git.domain.org/dir-under-pub-git`,
-both as cloneable GIT URL and as browseable gitweb interface. If you then
+both as cloneable Git URL and as browseable gitweb interface. If you then
start your linkgit:git-daemon[1] with `--base-path=/pub/git --export-all`
then you can even use the `git://` URL with exactly the same path.
diff --git a/Documentation/gitworkflows.txt b/Documentation/gitworkflows.txt
index 8b8c6ae..e2e7d65 100644
--- a/Documentation/gitworkflows.txt
+++ b/Documentation/gitworkflows.txt
@@ -242,7 +242,7 @@ tag to the tip of 'master' indicating the release version:
.Release tagging
[caption="Recipe: "]
=====================================
-`git tag -s -m "GIT X.Y.Z" vX.Y.Z master`
+`git tag -s -m "Git X.Y.Z" vX.Y.Z master`
=====================================
You need to push the new tag to a public git server (see
diff --git a/Documentation/glossary-content.txt b/Documentation/glossary-content.txt
index f928b57..7c28aef 100644
--- a/Documentation/glossary-content.txt
+++ b/Documentation/glossary-content.txt
@@ -52,7 +52,7 @@
[[def_cherry-picking]]cherry-picking::
In <<def_SCM,SCM>> jargon, "cherry pick" means to choose a subset of
changes out of a series of changes (typically commits) and record them
- as a new series of changes on top of a different codebase. In GIT, this is
+ as a new series of changes on top of a different codebase. In Git, this is
performed by the "git cherry-pick" command to extract the change introduced
by an existing <<def_commit,commit>> and to record it based on the tip
of the current <<def_branch,branch>> as a new commit.
diff --git a/Documentation/howto-index.sh b/Documentation/howto-index.sh
index 34aa30c..8e82e52 100755
--- a/Documentation/howto-index.sh
+++ b/Documentation/howto-index.sh
@@ -1,7 +1,7 @@
#!/bin/sh
cat <<\EOF
-GIT Howto Index
+Git Howto Index
===============
Here is a collection of mailing list postings made by various
diff --git a/Documentation/howto/rebase-from-internal-branch.txt b/Documentation/howto/rebase-from-internal-branch.txt
index 4627ee4..19ab604 100644
--- a/Documentation/howto/rebase-from-internal-branch.txt
+++ b/Documentation/howto/rebase-from-internal-branch.txt
@@ -4,7 +4,7 @@ Cc: Petr Baudis <pasky@suse.cz>, Linus Torvalds <torvalds@osdl.org>
Subject: Re: sending changesets from the middle of a git tree
Date: Sun, 14 Aug 2005 18:37:39 -0700
Abstract: In this article, JC talks about how he rebases the
- public "pu" branch using the core GIT tools when he updates
+ public "pu" branch using the core Git tools when he updates
the "master" branch, and how "rebase" works. Also discussed
is how this applies to individual developers who sends patches
upstream.
@@ -31,7 +31,7 @@ up. With its basing philosophical ancestry on quilt, this is
the kind of task StGIT is designed to do.
I just have done a simpler one, this time using only the core
-GIT tools.
+Git tools.
I had a handful of commits that were ahead of master in pu, and I
wanted to add some documentation bypassing my usual habit of
@@ -96,7 +96,7 @@ you ran fsck-cache, which is normal. After testing "pu", you
can run "git prune" to get rid of those original three commits.
While I am talking about "git rebase", I should talk about how
-to do cherrypicking using only the core GIT tools.
+to do cherrypicking using only the core Git tools.
Let's go back to the earlier picture, with different labels.
diff --git a/Documentation/howto/revert-branch-rebase.txt b/Documentation/howto/revert-branch-rebase.txt
index a59ced8..84dd839 100644
--- a/Documentation/howto/revert-branch-rebase.txt
+++ b/Documentation/howto/revert-branch-rebase.txt
@@ -12,10 +12,10 @@ How to revert an existing commit
================================
One of the changes I pulled into the 'master' branch turns out to
-break building GIT with GCC 2.95. While they were well intentioned
+break building Git with GCC 2.95. While they were well intentioned
portability fixes, keeping things working with gcc-2.95 was also
important. Here is what I did to revert the change in the 'master'
-branch and to adjust the 'pu' branch, using core GIT tools and
+branch and to adjust the 'pu' branch, using core Git tools and
barebone Porcelain.
First, prepare a throw-away branch in case I screw things up.
diff --git a/Documentation/howto/setup-git-server-over-http.txt b/Documentation/howto/setup-git-server-over-http.txt
index a695f01..e49d785 100644
--- a/Documentation/howto/setup-git-server-over-http.txt
+++ b/Documentation/howto/setup-git-server-over-http.txt
@@ -53,10 +53,10 @@ In effect, this means you're going to be root, or that you're using a
preconfigured WebDAV server.
-Step 1: setup a bare GIT repository
+Step 1: setup a bare Git repository
-----------------------------------
-At the time of writing, git-http-push cannot remotely create a GIT
+At the time of writing, git-http-push cannot remotely create a Git
repository. So we have to do that at the server side with git. Another
option is to generate an empty bare repository at the client and copy
it to the server with a WebDAV client (which is the only option if Git
diff --git a/Documentation/technical/api-index-skel.txt b/Documentation/technical/api-index-skel.txt
index 730cfac..eda8c19 100644
--- a/Documentation/technical/api-index-skel.txt
+++ b/Documentation/technical/api-index-skel.txt
@@ -1,7 +1,7 @@
-GIT API Documents
+Git API Documents
=================
-GIT has grown a set of internal API over time. This collection
+Git has grown a set of internal API over time. This collection
documents them.
////////////////////////////////////////////////////////////////
diff --git a/Documentation/technical/index-format.txt b/Documentation/technical/index-format.txt
index 7324154..6a05ee2 100644
--- a/Documentation/technical/index-format.txt
+++ b/Documentation/technical/index-format.txt
@@ -1,4 +1,4 @@
-GIT index format
+Git index format
================
== The git index file has the following format
@@ -21,9 +21,9 @@ GIT index format
- Extensions
Extensions are identified by signature. Optional extensions can
- be ignored if GIT does not understand them.
+ be ignored if Git does not understand them.
- GIT currently supports cached tree and resolve undo extensions.
+ Git currently supports cached tree and resolve undo extensions.
4-byte extension signature. If the first byte is 'A'..'Z' the
extension is optional and can be ignored.
diff --git a/Documentation/technical/pack-format.txt b/Documentation/technical/pack-format.txt
index a7871fb..e7d07bc 100644
--- a/Documentation/technical/pack-format.txt
+++ b/Documentation/technical/pack-format.txt
@@ -1,4 +1,4 @@
-GIT pack format
+Git pack format
===============
== pack-*.pack files have the following format:
@@ -9,7 +9,7 @@ GIT pack format
The signature is: {'P', 'A', 'C', 'K'}
4-byte version number (network byte order):
- GIT currently accepts version number 2 or 3 but
+ Git currently accepts version number 2 or 3 but
generates version 2 only.
4-byte number of objects contained in the pack (network byte order)
diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
index 1b377dc..c93e1a8 100644
--- a/Documentation/user-manual.txt
+++ b/Documentation/user-manual.txt
@@ -2299,7 +2299,7 @@ Here are some of the scripts that simplify all this even further.
-------------------------------------------------
==== update script ====
-# Update a branch in my GIT tree. If the branch to be updated
+# Update a branch in my Git tree. If the branch to be updated
# is origin, then pull from kernel.org. Otherwise merge
# origin/master branch into test|release branch
@@ -2357,7 +2357,7 @@ esac
-------------------------------------------------
==== status script ====
-# report on status of my ia64 GIT tree
+# report on status of my ia64 Git tree
gb=$(tput setab 2)
rb=$(tput setab 1)
--
1.8.0.msysgit.0
---
Thomas
^ permalink raw reply related
* Re: t9902 fails
From: Jean-Noël AVILA @ 2013-01-19 10:23 UTC (permalink / raw)
To: Torsten Bögershausen
Cc: Junio C Hamano, Jonathan Nieder, Jeff King, git,
Nguyễn Thái Ngọc Duy, Felipe Contreras
In-Reply-To: <50FA316E.8060807@web.de>
Le samedi 19 janvier 2013 06:38:54, Torsten Bögershausen a écrit :
> On 18.01.13 23:23, Jean-Noël AVILA wrote:
> > Le vendredi 18 janvier 2013 21:15:23, Junio C Hamano a écrit :
> >> Junio C Hamano <gitster@pobox.com> writes:
> >>> How about doing something like this and set that variable in the
> >>> test instead? If STD_ONLY is not set, you will get everything, but
> >>> when STD_ONLY is set, we will stop reading from "help -a" when it
> >>> starts listing additional stuff.
> >
> > I tried both of your propositions but none made test 10 of t9902 pass.
> >
> > Am I supposed to run "make install" before running the test?
>
> No. The test suite could (and should) be run before you make install.
> So a typical sequence could be:
> Run test suite, and if that passes, install the binaries on my system.
> This could look like this on the command line:
> make test && sudo make install
>
> Jean-Noël,
> would it be possible to run
> "git status"
> and share the result with us?
>
> And did you try Jonathans patch?
>
> /Torsten
Hi all,
My workdir is clean.
jnavila@cayenne git (master)]$ make
GEN perl/PM.stamp
SUBDIR gitweb
SUBDIR ../
make[2]: « GIT-VERSION-FILE » est à jour.
GEN git-instaweb
SUBDIR git-gui
SUBDIR gitk-git
make[1]: Rien à faire pour « all ».
SUBDIR perl
SUBDIR git_remote_helpers
SUBDIR templates
[jnavila@cayenne git (master)]$ git branch -vv
attr_pattern 3cb6a4c Add directory pattern matching to attributes
fix_test_t9902 02f55e6 Merge git://bogomips.org/git-svn
maint 611fa18 Add directory pattern matching to attributes
* master 02f55e6 [origin/master] Merge git://bogomips.org/git-svn
next 82c5000 [origin/next: ahead 157, behind 550] Merge branch
'jc/doc-diff-blobs' into next
pu 25f269c [origin/pu: ahead 68, behind 137] Merge branch
'mp/diff-algo-config' into pu
todo 70e0e3e [origin/todo: behind 1] What's cooking (2013/01 #06)
[jnavila@cayenne git (master)]$ git status
# On branch master
# Untracked files:
# (use "git add <file>..." to include in what will be committed)
#
# gitk-git/gitk-wish
nothing added to commit but untracked files present (use "git add" to track)
[jnavila@cayenne git (master)]$ ls -l | grep git-check
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-check-attr
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-checkout
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-checkout-index
-rwxr-xr-x 108 jnavila jnavila 7677476 janv. 19 10:30 git-check-ref-format
If I move git-checkout-branches out of /usr/bin, the test passes. So somehow
GIT_EXEC_PATH is not what is expected.
^ 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