* [PATCH] bash: add support for 'git replace'
From: Björn Gustavsson @ 2009-10-09 20:49 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
Signed-off-by: Björn Gustavsson <bgustavsson@gmail.com>
---
contrib/completion/git-completion.bash | 6 ++++++
1 files changed, 6 insertions(+), 0 deletions(-)
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash
index 88b1b3c..60009c5 100755
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash
@@ -1794,6 +1794,11 @@ _git_remote ()
esac
}
+_git_replace ()
+{
+ __gitcomp "$(__git_refs)"
+}
+
_git_reset ()
{
__git_has_doubledash && return
@@ -2162,6 +2167,7 @@ _git ()
push) _git_push ;;
rebase) _git_rebase ;;
remote) _git_remote ;;
+ replace) _git_replace ;;
reset) _git_reset ;;
revert) _git_revert ;;
rm) _git_rm ;;
--
1.6.5.rc3.2.g9b675
^ permalink raw reply related
* Re: [RFC PATCH 1/4] Document the HTTP transport protocol
From: Junio C Hamano @ 2009-10-09 20:44 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1255065768-10428-2-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> Signed-off-by: Shawn O. Pearce <spearce@spearce.org>
Nice write-up.
> Documentation/technical/http-protocol.txt | 542 +++++++++++++++++++++++++++++
> 1 files changed, 542 insertions(+), 0 deletions(-)
> create mode 100644 Documentation/technical/http-protocol.txt
>
> diff --git a/Documentation/technical/http-protocol.txt b/Documentation/technical/http-protocol.txt
> new file mode 100644
> index 0000000..316d9b6
> --- /dev/null
> +++ b/Documentation/technical/http-protocol.txt
> @@ -0,0 +1,542 @@
> +HTTP transfer protocols
> +=======================
> ...
> +As a design feature smart clients can automatically upgrade "dumb"
> +protocol URLs to smart URLs. This permits all users to have the
> +same published URL, and the peers automatically select the most
> +efficient transport available to them.
The first sentence feels backwards although the conclusion in the second
sentence is true. It is more like smart ones trying smart protocol first,
and downgrading to "dumb" after noticing that the server is not smart.
> +Authentication
> +--------------
> ...
> +Clients SHOULD support Basic authentication as described by RFC 2616.
> +Servers SHOULD support Basic authentication by relying upon the
> +HTTP server placed in front of the Git server software.
It is perfectly fine to make it a requirement for a server to support the
Basic authentication, but should you make it a requirement that the
support is done by a specific implementation, i.e. "by relying upon..."?
> +Session State
> +-------------
> ...
> +retained and managed by the client process. This permits simple
> +round-robin load-balancing on the server side, without needing to
> +worry about state mangement.
s/mangement/management/;
> +pkt-line Format
> +---------------
> ...
> +Examples (as C-style strings):
> +
> + pkt-line actual value
> + ---------------------------------
> + "0006a\n" "a\n"
> + "0005a" "a"
> + "000bfoobar\n" "foobar\n"
> + "0004" ""
> +
> +A pkt-line with a length of 0 ("0000") is a special case and MUST
> +be treated as a message break or terminator in the payload.
Isn't this "MUST be" wrong?
It is not an advice to the implementors, but the protocol specification
itself defines what the flush packet means. IOW, "The author of this
specification, Shawn, MUST treat a flush packet as a message break or
terminator in the payload, when designing this protocol."
> +General Request Processing
> +--------------------------
> +
> +Except where noted, all standard HTTP behavior SHOULD be assumed
> +by both client and server. This includes (but is not necessarily
> +limited to):
> +
> +If there is no repository at $GIT_URL, the server MUST respond with
> +the '404 Not Found' HTTP status code.
We may also want to add
If there is no object at $GIT_URL/some/path, the server MUST respond
with the '404 Not Found' HTTP status code.
to help dumb clients.
> +Dumb Clients
> +~~~~~~~~~~~~
> +
> +HTTP clients that only support the "dumb" protocol MUST discover
> +references by making a request for the special info/refs file of
> +the repository.
> +
> +Dumb HTTP clients MUST NOT include search/query parameters when
> +fetching the info/refs file. (That is, '?' must not appear in the
> +requested URL.)
It is unclear if '?' can be part of $GIT_URL. E.g.
$ wget http://example.xz/serve.cgi?path=git.git/info/refs
$ git clone http://example.xz/serve.cgi?path=git.git
It might be clearer to just say
Dumb HTTP clients MUST make a GET request against $GIT_URL/info/refs,
without any search/query parameters. I.e.
C: GET $GIT_URL/info/refs HTTP/1.0
to also exclude methods other than GET.
> + C: GET $GIT_URL/info/refs HTTP/1.0
> +
> + S: 200 OK
> ...
> +When examining the response clients SHOULD only examine the HTTP
> +status code. Valid responses are '200 OK', or '304 Not Modified'.
Isn't 401 ("Ah, I was given a wrong URL") and 403 ("Ok, I do not have an
access to this repository") also valid?
> +The returned content is a UNIX formatted text file describing
> +each ref and its known value. The file SHOULD be sorted by name
> +according to the C locale ordering. The file SHOULD NOT include
> +the default ref named 'HEAD'.
I know you said "known" to imply "concurrent operations may change it
while the server is serving this client", but it feels rather awkward.
> +Smart Server Response
> +^^^^^^^^^^^^^^^^^^^^^
> +
> +Smart servers MUST respond with the smart server reply format.
> +If the server does not recognize the requested service name, or the
> +requested service name has been disabled by the server administrator,
> +the server MUST respond with the '403 Forbidden' HTTP status code.
This is a bit confusing.
If you as a server administrator want to disable the smart upload-pack for
one repository (but not for other repositories), you would not be able to
force smart clients to fall back to the dumb protocol by giving "403" for
that repository.
Maybe in 2 years somebody smarter than us will have invented a more
efficient git-upload-pack-2 service, which is the only fetch protocol his
server supports other than dumb. If your v1 smart client asks for the
original git-upload-pack service and gets a "403", you won't be able to
fall back to "dumb".
The solution for such cases likely is to pretend as if you are a dumb
server for the smart request. That unfortunately means that the first
sentence is misleading, and the second sentence is also an inappropriate
advice.
> +The Content-Type MUST be 'application/x-$servicename-advertisement'.
> +Clients SHOULD fall back to the dumb protocol if another content
> +type is returned. When falling back to the dumb protocol clients
> +SHOULD NOT make an additional request to $GIT_URL/info/refs, but
> +instead SHOULD use the response already in hand. Clients MUST NOT
> +continue if they do not support the dumb protocol.
The part I commented on (the beginning of Smart Server Response) was
written as a generic description, not specific to git-upload-pack service,
and the beginning of this paragraph also pretends to be a generic
description, but it is misleading. This is a specific instruction to the
clients that asked for git-upload-pack service and got a dumb server
response (if the above were talking about something other than upload-pack
service, there is no guarantee that "response already in hand" is useful
to talk to dumb servers).
> +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.
> +
> + smart_reply = PKT-LINE("# service=$servicename" LF)
> + ref_list
> + "0000"
> + ref_list = empty_list | populated_list
> +
> + empty_list = PKT-LINE(id SP "capabilities^{}" NUL cap_list LF)
> +
> + non_empty_list = PKT-LINE(id SP name NUL cap_list LF)
> + *ref_record
> +
> + cap_list = *(SP capability) SP
> + ref_record = any_ref | peeled_ref
> +
> + any_ref = PKT-LINE(id SP name LF)
> + peeled_ref = PKT-LINE(id SP name LF)
> + PKT-LINE(id SP name "^{}" LF
> + id = 40*HEX
> +
> + HEX = "0".."9" | "a".."f"
> + NL = <US-ASCII NUL, null (0)>
> + LF = <US-ASCII LF, linefeed (10)>
> + SP = <US-ASCII SP, horizontal-tab (9)>
Did you define what "populated_list" is?
> +Smart Service git-upload-pack
> +------------------------------
> +This service reads from the remote repository.
The wording "remote repository" felt confusing. I know it is "from the
repository served by the server", but if it were named without
"upload-pack", I might have mistaken that you are allowing to proxy a
request to access a third-party repository by this server. The same
comment applies to the git-receive-pack service.
> +Capability include-tag
> +~~~~~~~~~~~~~~~~~~~~~~
> +
> +When packing an object that an annotated tag points at, include the
> +tag object too. Clients can request this if they want to fetch
> +tags, but don't know which tags they will need until after they
> +receive the branch data. By enabling include-tag an entire call
> +to upload-pack can be avoided.
> +
I think you are avoiding an "extra" call; you would need one entire call
to upload-pack anyway for the primary transfer.
^ permalink raw reply
* Re: [PATCH] git-svn: Avoid spurious errors when rewriteRoot is used.
From: Junio C Hamano @ 2009-10-09 20:44 UTC (permalink / raw)
To: Eric Wong; +Cc: git, Alexander Gavrilov
In-Reply-To: <20091009083444.GA31594@dcvr.yhbt.net>
Eric Wong <normalperson@yhbt.net> writes:
> Thanks Alexander,
>
> Acked-by: Eric Wong <normalperson@yhbt.net>
>
> Fixed some line wrapping and pushed out to
> git://git.bogomips.org/git-svn
Thanks.
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: support Korn shell by converting GIT_EXIT_OK to GIT_EXIT_CODE
From: Jonathan Nieder @ 2009-10-09 20:01 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, drizzd, peff, Brandon Casey
In-Reply-To: <20091009192812.GA4122@progeny.tock>
Sorry to reply to self, just want to correct something I missed.
Jonathan Nieder wrote:
> Brandon Casey wrote:
>> diff --git a/t/test-lib.sh b/t/test-lib.sh
>> index f2ca536..64e793a 100644
>> --- a/t/test-lib.sh
>> +++ b/t/test-lib.sh
> [...]
>> @@ -183,16 +183,16 @@ test_success=0
>>
>> die () {
>> code=$?
>> - if test -n "$GIT_EXIT_OK"
>> + if test -n "$GIT_EXIT_CODE"
>> then
>> - exit $code
>> + exit $GIT_EXIT_CODE
>> else
>> echo >&5 "FATAL: Unexpected exit with code $code"
>> exit 1
>> fi
>> }
>
> $code can be removed now, right?
Sloppy reading on my part here: $code is still used in the error
message on unexpected exits. The $code will be inaccurate on Suns
in some cases, but this is only a cosmetic problem and the wrong
value should be better than nothing for debugging.
> lib-httpd.sh:96: trap 'code=$?; stop_httpd; (exit $code); die' EXIT
>
> It is probably worth changing that, too, unless GIT_TEST_HTTPD would not
> work on these platforms for some other reason.
This is used to support that error message, so it should not be
changed, either.
Your patch looks good. Maybe the commit message could explain this,
though?
Apologies for the noise,
Jonathan
^ permalink raw reply
* Re: [RFC PATCH 1/4] Document the HTTP transport protocol
From: Jeff King @ 2009-10-09 19:50 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1255065768-10428-2-git-send-email-spearce@spearce.org>
On Thu, Oct 08, 2009 at 10:22:45PM -0700, Shawn O. Pearce wrote:
> +Servers MUST NOT require HTTP cookies for the purposes of
> +authentication or access control.
> [...]
> +Servers MUST NOT require HTTP cookies in order to function correctly.
> +Clients MAY store and forward HTTP cookies during request processing
> +as described by RFC 2616 (HTTP/1.1). Servers SHOULD ignore any
> +cookies sent by a client.
Why not? I can grant that the current git implementation probably can't
handle it, but keep in mind this is talking about the protocol and not
the implementation. And I can see it being useful for sites like github
which already have a cookie-based login. Adapting the client to handle
this case would not be too difficult (it would just mean keeping cookie
state in a file between runs, or even just pulling it out of the normal
browser's cookie store). And people whose client didn't do this would
simply get an "access denied" response code.
Is there a technical reason not to allow it?
-Peff
^ permalink raw reply
* Re: [RFC PATCH 1/4] Document the HTTP transport protocol
From: Jakub Narebski @ 2009-10-09 19:27 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: git
In-Reply-To: <1255065768-10428-2-git-send-email-spearce@spearce.org>
"Shawn O. Pearce" <spearce@spearce.org> writes:
> + empty_list = PKT-LINE(id SP "capabilities^{}" NUL cap_list LF)
> +
> + non_empty_list = PKT-LINE(id SP name NUL cap_list LF)
> + *ref_record
> +
> + cap_list = *(SP capability) SP
Errr... are you sure? Because from examples it looks like cap_list
(capabilities list) is a list of space *separated* capabilities, while
the above requires also both leading and trailing space. Shouldn't it
be
cap_list = capability *(SP capability)
Also the format for capability is not defined; I guess only
a-z, 0-9, '-' and '_' are allowed in capability name.
BTW. is it possible to not have capability list?
> + HEX = "0".."9" | "a".."f"
Do you plan allowing also upper case letters, while server and client
SHOULD use lowercase? Because if you do, then RFC 5234 which defines
ABNF you seem to be using here has HEXDIG defined.
> + NL = <US-ASCII NUL, null (0)>
Why not NUL?
> + LF = <US-ASCII LF, linefeed (10)>
> + SP = <US-ASCII SP, horizontal-tab (9)>
^^^^^^^^^^^^^^-- o'rly?
Those are pre-defined in ABNF, e.g.
SP = %x20
> +References
> +----------
> +
> +link:http://www.ietf.org/rfc/rfc1738.txt[RFC 1738: Uniform Resource Locators (URL)]
> +link:http://www.ietf.org/rfc/rfc2616.txt[RFC 2616: Hypertext Transfer Protocol -- HTTP/1.1]
You should also reference the following RFCs:
* "RFC 5234: Augmented BNF for Syntax Specifications: ABNF"
* "RFC 2119: Key words for use in RFCs to Indicate Requirement Levels"
--
Jakub Narebski
Poland
ShadeHawk on #git
^ permalink raw reply
* Re: [PATCH 1/2] t/test-lib.sh: support Korn shell by converting GIT_EXIT_OK to GIT_EXIT_CODE
From: Jonathan Nieder @ 2009-10-09 19:28 UTC (permalink / raw)
To: Brandon Casey; +Cc: git, drizzd, peff, Brandon Casey
In-Reply-To: <1eweIwf5YoFwmLPWwEFN69a2f-EUnj_kgiagVJoVQYfNQeLjlpm12U84RKxhzjh0NJv36SqO12lAX2c_x0WSgA@cipher.nrlssc.navy.mil>
Brandon Casey wrote:
> So, rather than relying on the behavior of Bash in order to get the exit
> code from $? inside die(), change GIT_EXIT_OK into GIT_EXIT_CODE, and set
> it to the code that we want to exit with. This allows the test suite to
> be run with the Korn shell.
>
> Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
Sounds like a good idea. A few thoughts:
start_httpd() from lib-httpd.sh uses a similar pattern:
lib-httpd.sh:96: trap 'code=$?; stop_httpd; (exit $code); die' EXIT
It is probably worth changing that, too, unless GIT_TEST_HTTPD would not
work on these platforms for some other reason.
"GIT_EXIT_CODE=1; exit 1" sounds repetitive to my ear. It’s probably just
me, but if not, it might be worth adding a function like
expected_exit() {
GIT_EXIT_CODE=$1
exit "$1"
}
I’m not sure.
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index f2ca536..64e793a 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
[...]
> @@ -183,16 +183,16 @@ test_success=0
>
> die () {
> code=$?
> - if test -n "$GIT_EXIT_OK"
> + if test -n "$GIT_EXIT_CODE"
> then
> - exit $code
> + exit $GIT_EXIT_CODE
> else
> echo >&5 "FATAL: Unexpected exit with code $code"
> exit 1
> fi
> }
$code can be removed now, right?
Jonathan
^ permalink raw reply
* Re: [PATCH v2 (amend)] gitweb: Do not show 'patch' link for merge commits
From: Jeff King @ 2009-10-09 19:19 UTC (permalink / raw)
To: Jakub Narebski; +Cc: git, Junio Hamano
In-Reply-To: <200910091426.44976.jnareb@gmail.com>
On Fri, Oct 09, 2009 at 02:26:44PM +0200, Jakub Narebski wrote:
> Changes since v1:
> * Do not show 'patch' link for merge commits not only in 'commit'
> view, but also in 'commitdiff' view (more complete)
> * 'patch' link is shown also for root (parentless) commits; it
> works correctly thanks to passing '--root' option to git-format-patch
> (remove unnecessary restriction)
> * better commit message thanks to discussion with Jeff King
Thanks. I am not a gitweb expert, but those changes look good to me.
-Peff
^ permalink raw reply
* [PATCH 3-4/9 v2] Documentation: clarify mergeoptions description
From: Jonathan Nieder @ 2009-10-09 18:51 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: git
In-Reply-To: <20091009101743.GD16558@progeny.tock>
Sounds better this way, at least to my ears. ("The syntax and
supported options of git merge" is a plural noun. "the same"
instead of "equal" sounds less technical and seems to convey
the meaning better here.)
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Sean Estabrooks wrote:
> P.S. Patches 3 and 4 in this series would be better as a single patch.
Good idea. Here's a squashed version.
Documentation/config.txt | 2 +-
Documentation/git-merge.txt | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index be0b8ca..cd17814 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -539,7 +539,7 @@ branch.<name>.merge::
branch.<name>.mergeoptions::
Sets default options for merging into branch <name>. The syntax and
- supported options are equal to that of linkgit:git-merge[1], but
+ supported options are the same as those of linkgit:git-merge[1], but
option values containing whitespace characters are currently not
supported.
diff --git a/Documentation/git-merge.txt b/Documentation/git-merge.txt
index 354e9d9..6ffd4b0 100644
--- a/Documentation/git-merge.txt
+++ b/Documentation/git-merge.txt
@@ -50,8 +50,8 @@ include::merge-config.txt[]
branch.<name>.mergeoptions::
Sets default options for merging into branch <name>. The syntax and
- supported options are equal to that of 'git-merge', but option values
- containing whitespace characters are currently not supported.
+ supported options are the same as those of 'git-merge', but option
+ values containing whitespace characters are currently not supported.
HOW MERGE WORKS
---------------
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* [PATCH 2/2] Makefile: use the native (Korn) shell on SunOS and IRIX/IRIX64
From: Brandon Casey @ 2009-10-09 18:39 UTC (permalink / raw)
To: git; +Cc: drizzd, peff, Brandon Casey
In-Reply-To: <1eweIwf5YoFwmLPWwEFN69a2f-EUnj_kgiagVJoVQYfNQeLjlpm12U84RKxhzjh0NJv36SqO12lAX2c_x0WSgA@cipher.nrlssc.navy.mil>
From: Brandon Casey <drafnel@gmail.com>
Now that the test suite supports the Korn shell, we can use it as the
default on platforms that do not ship with Bash.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
Makefile | 6 +++---
1 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/Makefile b/Makefile
index 629ab35..9ada196 100644
--- a/Makefile
+++ b/Makefile
@@ -726,7 +726,7 @@ endif
ifeq ($(uname_S),SunOS)
NEEDS_SOCKET = YesPlease
NEEDS_NSL = YesPlease
- SHELL_PATH = /bin/bash
+ SHELL_PATH = /usr/xpg4/bin/sh
SANE_TOOL_PATH = /usr/xpg6/bin:/usr/xpg4/bin
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
@@ -850,7 +850,7 @@ ifeq ($(uname_S),IRIX)
NO_MMAP = YesPlease
NO_EXTERNAL_GREP = UnfortunatelyYes
SNPRINTF_RETURNS_BOGUS = YesPlease
- SHELL_PATH = /usr/gnu/bin/bash
+ SHELL_PATH = /bin/ksh
NEEDS_LIBGEN = YesPlease
THREADED_DELTA_SEARCH = YesPlease
endif
@@ -870,7 +870,7 @@ ifeq ($(uname_S),IRIX64)
NO_MMAP = YesPlease
NO_EXTERNAL_GREP = UnfortunatelyYes
SNPRINTF_RETURNS_BOGUS = YesPlease
- SHELL_PATH=/usr/gnu/bin/bash
+ SHELL_PATH=/bin/ksh
NEEDS_LIBGEN = YesPlease
THREADED_DELTA_SEARCH = YesPlease
endif
--
1.6.5.rc3
^ permalink raw reply related
* [PATCH 1/2] t/test-lib.sh: support Korn shell by converting GIT_EXIT_OK to GIT_EXIT_CODE
From: Brandon Casey @ 2009-10-09 18:39 UTC (permalink / raw)
To: git; +Cc: drizzd, peff, Brandon Casey
From: Brandon Casey <drafnel@gmail.com>
Commit 6e7b5aaf introduced the concept of GIT_EXIT_OK as a way to indicate
to die(), the exit handler, whether the exit was initiated by the test
harness, or whether it was unexpected. die() expects $? to contain the
value passed to exit(), and when GIT_EXIT_OK is set, die() calls exit with
the value in $?. This works as expected when using the Bash shell. For
the Korn shell, $? has the value of the last executed statement _before_
the call to exit. If that statement completed successfully, then die()
would incorrectly exit with a successful status when GIT_EXIT_OK is set.
So, rather than relying on the behavior of Bash in order to get the exit
code from $? inside die(), change GIT_EXIT_OK into GIT_EXIT_CODE, and set
it to the code that we want to exit with. This allows the test suite to
be run with the Korn shell.
Signed-off-by: Brandon Casey <casey@nrlssc.navy.mil>
---
t/test-lib.sh | 15 ++++++++-------
1 files changed, 8 insertions(+), 7 deletions(-)
diff --git a/t/test-lib.sh b/t/test-lib.sh
index f2ca536..64e793a 100644
--- a/t/test-lib.sh
+++ b/t/test-lib.sh
@@ -150,7 +150,7 @@ fi
error () {
say_color error "error: $*"
- GIT_EXIT_OK=t
+ GIT_EXIT_CODE=1
exit 1
}
@@ -183,16 +183,16 @@ test_success=0
die () {
code=$?
- if test -n "$GIT_EXIT_OK"
+ if test -n "$GIT_EXIT_CODE"
then
- exit $code
+ exit $GIT_EXIT_CODE
else
echo >&5 "FATAL: Unexpected exit with code $code"
exit 1
fi
}
-GIT_EXIT_OK=
+GIT_EXIT_CODE=
trap 'die' EXIT
# The semantics of the editor variables are that of invoking
@@ -295,7 +295,7 @@ test_failure_ () {
say_color error "FAIL $test_count: $1"
shift
echo "$@" | sed -e 's/^/ /'
- test "$immediate" = "" || { GIT_EXIT_OK=t; exit 1; }
+ test "$immediate" = "" || { GIT_EXIT_CODE=1; exit 1; }
}
test_known_broken_ok_ () {
@@ -508,7 +508,6 @@ test_create_repo () {
}
test_done () {
- GIT_EXIT_OK=t
test_results_dir="$TEST_DIRECTORY/test-results"
mkdir -p "$test_results_dir"
test_results_path="$test_results_dir/${0%.sh}-$$"
@@ -539,9 +538,11 @@ test_done () {
cd "$(dirname "$remove_trash")" &&
rm -rf "$(basename "$remove_trash")"
+ GIT_EXIT_CODE=0
exit 0 ;;
*)
+ GIT_EXIT_CODE=1
say_color error "failed $test_failure among $msg"
exit 1 ;;
@@ -655,7 +656,7 @@ case "$test" in
esac
test ! -z "$debug" || remove_trash=$TRASH_DIRECTORY
rm -fr "$test" || {
- GIT_EXIT_OK=t
+ GIT_EXIT_CODE=1
echo >&5 "FATAL: Cannot prepare test area"
exit 1
}
--
1.6.5.rc3
^ permalink raw reply related
* Re: [PATCH 7/9] Documentation: clarify branch creation
From: Jonathan Nieder @ 2009-10-09 18:34 UTC (permalink / raw)
To: Sean Estabrooks; +Cc: git
In-Reply-To: <BLU0-SMTP425A9541141B09D790814EAECB0@phx.gbl>
Sean Estabrooks wrote:
> On Fri, 9 Oct 2009 05:19:40 -0500
> Jonathan Nieder <jrnieder@gmail.com> wrote:
>
> > +In the command's second form, creates a new branch named <branchname>.
> > +The branch will start out with head pointing to the commit
> > +<start-point>. If no <start-point> is given, the branch will start
> > +out with head pointing to the tip of the currently checked out branch,
> > +or the currently checked out commit if no branch is checked out.
>
> The first sentence here doesn't quite work, perhaps drop the "In". But
> the whole thing is a bit verbose, what about just:
>
> The command's second form creates a new branch named <branchname> which
> points to the current HEAD or <start-point> if given.
Makes sense. I modified this slightly to “new branch head” since the
branch itself does not point to anything.
> > <start-point>::
> > - The new branch will be created with a HEAD equal to this. It may
> > - be given as a branch name, a commit-id, or a tag. If this option
> > - is omitted, the current branch is assumed.
> > + The new branch head will point to this commit. It may be
> > + given as a branch name, a commit-id, or a tag. If this
> > + option is omitted, the currently checked out branch head
> > + is used, or the current commit if no branch is checked
> > + out.
>
> Maybe it's not worth worrying about, but couldn't the last sentence
> be just:
>
> If this option is omitted, the current HEAD will be used instead.
That sounds better, thanks. The reader that does not know what HEAD is
probably needs to read the relevant section of the user manual for other
reasons anyway.
So this page should probably point to the what-is-a-branch section of
the User's Manual. Maybe something like this?
-- %< --
Subject: Documentation: clarify branch creation
The documentation seems to assume that the starting point for a new
branch is the tip of an existing (ordinary) branch, but that is not
the most common case. More often, "git branch" is used to begin
a branch from a remote-tracking branch, a tag, or an interesting
commit (e.g. origin/pu^2). Clarify the language so it can apply
to these cases. Thanks to Sean Estabrooks for the wording.
Also add a pointer to the user's manual for the bewildered.
Signed-off-by: Jonathan Nieder <jrnieder@gmail.com>
---
Documentation/git-branch.txt | 16 ++++++++--------
1 files changed, 8 insertions(+), 8 deletions(-)
diff --git a/Documentation/git-branch.txt b/Documentation/git-branch.txt
index e8b32a2..f766b4d 100644
--- a/Documentation/git-branch.txt
+++ b/Documentation/git-branch.txt
@@ -30,10 +30,8 @@ commit) will be listed. With `--no-merged` only branches not merged into
the named commit will be listed. If the <commit> argument is missing it
defaults to 'HEAD' (i.e. the tip of the current branch).
-In the command's second form, a new branch named <branchname> will be created.
-It will start out with a head equal to the one given as <start-point>.
-If no <start-point> is given, the branch will be created with a head
-equal to that of the currently checked out branch.
+The command's second form creates a new branch head named <branchname>
+which points to the current 'HEAD', or <start-point> if given.
Note that this will create the new branch, but it will not switch the
working tree to it; use "git checkout <newbranch>" to switch to the
@@ -149,9 +147,9 @@ start-point is either a local or remote branch.
may restrict the characters allowed in a branch name.
<start-point>::
- The new branch will be created with a HEAD equal to this. It may
- be given as a branch name, a commit-id, or a tag. If this option
- is omitted, the current branch is assumed.
+ The new branch head will point to this commit. It may be
+ given as a branch name, a commit-id, or a tag. If this
+ option is omitted, the current HEAD will be used instead.
<oldbranch>::
The name of an existing branch to rename.
@@ -216,7 +214,9 @@ SEE ALSO
--------
linkgit:git-check-ref-format[1],
linkgit:git-fetch[1],
-linkgit:git-remote[1].
+linkgit:git-remote[1],
+link:user-manual.html#what-is-a-branch[``Understanding history: What is
+a branch?''] in the Git User's Manual.
Author
------
--
1.6.5.rc1.199.g596ec
^ permalink raw reply related
* feature request/proposal - clone --bare, init and init --bare with descrition
From: Eugene Sajine @ 2009-10-09 18:24 UTC (permalink / raw)
To: git; +Cc: Eugene Sajine
Hi,
here is the use case:
I'm migrating a project from CVS. I'm geting a git repo from git
cvsimport. Now I have to create a bare copy of it and put it on the
server so gitweb will see it.
Currently i have to do:
$ git clone --bare repo repo.git
I would like to be able to do
$ git clone --bare repo repo.git -d "this is my super-duper project"
So, the message goes directly to the description file.
Same thing with init or init --bare
I should have a possibility to do
$ git init --bare -d "this is my super-duper project"
What do you think?
Thanks,
Eugene
^ permalink raw reply
* Re: Smart HTTP Protocol
From: Shawn O. Pearce @ 2009-10-09 18:09 UTC (permalink / raw)
To: Michael Gaffney; +Cc: git
In-Reply-To: <4ACF79E0.5000606@gmail.com>
Michael Gaffney <mr.gaffo@gmail.com> wrote:
> What ended up being the status on this? From the last I saw, the
> protocol and the fallover smart to dumb had all been worked out. It was
> just that people were waiting on an implementation server side of the
> protocol before the client was implemented?
Uh, did you read my thread from last night at 10:30 pm called
"Return of smart HTTP" ?
Previous to this week we did not have a working server, OR a working
client, OR even a final spec.
I've started working on smart HTTP full time, and am not touching
any other project until the patches are being carried in Junio's
"next". I'm not going to rush the reviews on the list, but so long
as there is code for me to write/fix or documentation to write/fix
I'm refusing to touch another task.
I have it full implemented in JGit (client and server). I have
most of the server implemented in C Git. I'm working on the C Git
client today.
--
Shawn.
^ permalink raw reply
* Smart HTTP Protocol
From: Michael Gaffney @ 2009-10-09 17:58 UTC (permalink / raw)
To: git
What ended up being the status on this? From the last I saw, the
protocol and the fallover smart to dumb had all been worked out. It was
just that people were waiting on an implementation server side of the
protocol before the client was implemented?
-Mike
^ permalink raw reply
* Git 1.6.5-rc git clone unhandled exception using http protocol
From: eduard stefan @ 2009-10-09 17:27 UTC (permalink / raw)
To: Git Mailing List
I've tried Git 1.6.5 release candidates (rc1, rc2, rc3) with msysGit,
and "git clone git://github.com/loudej/spark.git" it's working,
but "git clone http://github.com/loudej/spark.git" crashes
with an Win32 unhandled exception.
I have tried to create an empty repository and run both
"git remote-curl http://github.com/loudej/spark.git"
and "git remote-curl" , but it crashes with the same error.
How can I obtain more information about the error?
BTW, Git 1.6.4.4 is working over both protocols,
on Windows Server 2008 SP2 x86, using the same msysGit
(msysGit-fullinstall-1.6.4-preview20090729.exe).
Have a nice day,
A.
^ permalink raw reply
* Re: [PATCH 7/9] Documentation: clarify branch creation
From: Sean Estabrooks @ 2009-10-09 16:21 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: git
In-Reply-To: <20091009101940.GG16558@progeny.tock>
On Fri, 9 Oct 2009 05:19:40 -0500
Jonathan Nieder <jrnieder@gmail.com> wrote:
> +In the command's second form, creates a new branch named <branchname>.
> +The branch will start out with head pointing to the commit
> +<start-point>. If no <start-point> is given, the branch will start
> +out with head pointing to the tip of the currently checked out branch,
> +or the currently checked out commit if no branch is checked out.
The first sentence here doesn't quite work, perhaps drop the "In". But
the whole thing is a bit verbose, what about just:
The command's second form creates a new branch named <branchname> which
points to the current HEAD or <start-point> if given.
> <start-point>::
> - The new branch will be created with a HEAD equal to this. It may
> - be given as a branch name, a commit-id, or a tag. If this option
> - is omitted, the current branch is assumed.
> + The new branch head will point to this commit. It may be
> + given as a branch name, a commit-id, or a tag. If this
> + option is omitted, the currently checked out branch head
> + is used, or the current commit if no branch is checked
> + out.
Maybe it's not worth worrying about, but couldn't the last sentence
be just:
If this option is omitted, the current HEAD will be used instead.
Sean
P.S. Patches 3 and 4 in this series would be better as a single patch.
^ permalink raw reply
* Re: [PATCH] Speedup bash completion loading
From: Shawn O. Pearce @ 2009-10-09 16:14 UTC (permalink / raw)
To: Kirill Smelkov, Junio C Hamano; +Cc: Ted Pavlic, git
In-Reply-To: <20091009160856.GA26833@tugrik.mns.mnsspb.ru>
Kirill Smelkov <kirr@mns.spb.ru> wrote:
> Now I see, OK. Here is the patch which should be applied on top of
> Stephen's 1/2:
>
> ---- 8< ----
> From: Kirill Smelkov <kirr@mns.spb.ru>
> Date: Mon, 5 Oct 2009 13:36:15 +0400
> Subject: [PATCH v4] Speedup bash completion loading
Acked-by: Shawn O. Pearce <spearce@spearce.org>
> contrib/completion/.gitignore | 1 +
> contrib/completion/Makefile | 11 ++
> contrib/completion/git-completion.bash.generate | 128 ++++++++++++++++
> ...{git-completion.bash => git-completion.bash.in} | 161 +++-----------------
> 4 files changed, 162 insertions(+), 139 deletions(-)
> create mode 100644 contrib/completion/.gitignore
> create mode 100644 contrib/completion/Makefile
> create mode 100755 contrib/completion/git-completion.bash.generate
> rename contrib/completion/{git-completion.bash => git-completion.bash.in} (90%)
> mode change 100755 => 100644
--
Shawn.
^ permalink raw reply
* Re: [PATCH 1/8] imap-send: remove useless uid code
From: Erik Faye-Lund @ 2009-10-09 16:12 UTC (permalink / raw)
To: Sverre Rabbelier; +Cc: git, gitster, Jeff King, Erik Faye-Lund
In-Reply-To: <fabb9a1e0910090821n67c86d0kb4eef1b9ff4bdff1@mail.gmail.com>
On Fri, Oct 9, 2009 at 5:21 PM, Sverre Rabbelier <srabbelier@gmail.com> wrote:
> Heya,
>
> On Fri, Oct 9, 2009 at 17:04, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
>
> Please include a cover letter for series as long as these (anything
> larger than 4 should have a cover letter IMHO). Doing so makes it
> easier for those that follow the series to see what changed (assuming
> you write down what changed in the cover letter). Also, it makes it
> easier for those that were not following the series to drop in at the
> current version (assuming you provide a short summary of what the
> series is about in the cover letter)..
Doh, I'm sorry about this. Here's an added cover-letter, I hope it helps:
--->8---
Here's the 2nd iteration of my patches for Windows-compatibility in imap-send.
Patch 1-3 is about getting rid of or rewriting code with portability issues.
Patch 4 fixes a compilation error on Windows
Patch 5 enables compilation of imap-send
Patch 6-7 enables SSL-suport for mingw
Patch 8 enables imap-send and SSL for msvc
Changes in this iteration compared to the previous are as follows:
- Patch 7 has been replaced with patch 1 in the current series. All
other patches from the previous iteration has been shifted up a number
due to this.
- Patch 2 (previously 1) now has a short comment that declares it's intent.
- Patch 8 has been included
--
Erik "kusma" Faye-Lund
kusmabite@gmail.com
(+47) 986 59 656
^ permalink raw reply
* Re: [PATCH] Speedup bash completion loading
From: Kirill Smelkov @ 2009-10-09 16:08 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Ted Pavlic, git
In-Reply-To: <20091009153936.GV9261@spearce.org>
On Fri, Oct 09, 2009 at 08:39:36AM -0700, Shawn O. Pearce wrote:
> Kirill Smelkov <kirr@mns.spb.ru> wrote:
> > On Fri, Oct 09, 2009 at 07:46:06AM -0700, Shawn O. Pearce wrote:
> > >
> > > Squash this into the first patch and add the egrep change made by
> > > Stephen Boyd "[PATCH 1/2] completion: fix completion of git <TAB><TAB>".
> >
> > While it is technically easy to do so, isn't this a bad idea to squash
> > semantic changes and fixes into something which should be as close as
> > code movement?
>
> The ejection forces the code to build with /bin/bash, unless you
> apply the trivial fixes related to IFS to make it work with dash.
> As they are trivial the tiny semantic change during the code move
> is just cleaner.
>
> > Especially Stephen's fix?
>
> I expect Junio to apply his patch first, and then yours. Since he
> is changing a region you are moving, you need to account for it in
> your patch, otherwise we have a conflict and/or a regression.
Now I see, OK. Here is the patch which should be applied on top of
Stephen's 1/2:
---- 8< ----
From: Kirill Smelkov <kirr@mns.spb.ru>
Date: Mon, 5 Oct 2009 13:36:15 +0400
Subject: [PATCH v4] Speedup bash completion loading
On my slow laptop (P3 700MHz), system-wide bash completions take too
much time to load (> 1s), and significant fraction of this time is spent
loading git-completion.bash:
$ time bash -c '. git-completion.bash' # before this patch
real 0m0.317s
user 0m0.250s
sys 0m0.060s
I've tracked down that the most time is spent warming up merge_strategy,
all_command & porcelain_command caches.
Initially I thought that since git is not used in each and every
interactive xterm, it would be perfectly ok to load completion support
with cold caches, and then load needed thing lazily.
But for me this strategy turned out to be difficult to implement in
simple and maintainable way -- bash does not provide a way to return values
from inside functions, so one will have to use e.g.
${__git_all_commandlist:=$(__git_all_commands)}
everywhere in place where $(__git_all_commands) we used before, so as
also Ted Pavlic suggested let's pregenerate everything at build time so
that we have nothing to compute at runtime when git-completion.bash
script is loaded.
The result is that loading completion is significantly faster now:
$ time bash -c '. git-completion.bash' # after this patch
real 0m0.068s
user 0m0.060s
sys 0m0.010s
NOTE
----
As Shawn O. Pearce suggested, git-completion.bash.generate code is now
used at compile time, so we shouldn't assume bash is avalable there.
Hence, IFS tweak (not needed in the first place) in __git_all_commands()
was removed, for compile-time code to be bashism free.
Cc: Ted Pavlic <ted@tedpavlic.com>
Signed-off-by: Kirill Smelkov <kirr@mns.spb.ru>
---
contrib/completion/.gitignore | 1 +
contrib/completion/Makefile | 11 ++
contrib/completion/git-completion.bash.generate | 128 ++++++++++++++++
...{git-completion.bash => git-completion.bash.in} | 161 +++-----------------
4 files changed, 162 insertions(+), 139 deletions(-)
create mode 100644 contrib/completion/.gitignore
create mode 100644 contrib/completion/Makefile
create mode 100755 contrib/completion/git-completion.bash.generate
rename contrib/completion/{git-completion.bash => git-completion.bash.in} (90%)
mode change 100755 => 100644
diff --git a/contrib/completion/.gitignore b/contrib/completion/.gitignore
new file mode 100644
index 0000000..578e6a8
--- /dev/null
+++ b/contrib/completion/.gitignore
@@ -0,0 +1 @@
+git-completion.bash
diff --git a/contrib/completion/Makefile b/contrib/completion/Makefile
new file mode 100644
index 0000000..90aa225
--- /dev/null
+++ b/contrib/completion/Makefile
@@ -0,0 +1,11 @@
+all : git-completion.bash
+
+
+git-completion.bash: git-completion.bash.in git-completion.bash.generate
+ # Generate completions for binaries we have just built
+ PATH="$(shell pwd)/../..:$$PATH" ./git-completion.bash.generate
+
+
+clean:
+ rm -f git-completion.bash
+
diff --git a/contrib/completion/git-completion.bash.generate b/contrib/completion/git-completion.bash.generate
new file mode 100755
index 0000000..ff64202
--- /dev/null
+++ b/contrib/completion/git-completion.bash.generate
@@ -0,0 +1,128 @@
+#!/bin/sh
+#
+# Generate bash completion for git.
+#
+# Precompute everything that can be known in advance at build time, so that
+# actual bash completion script is loaded faster.
+
+__git_merge_strategies ()
+{
+ git merge -s help 2>&1 |
+ sed -n -e '/[Aa]vailable strategies are: /,/^$/{
+ s/\.$//
+ s/.*://
+ s/^[ ]*//
+ s/[ ]*$//
+ p
+ }'
+}
+
+__git_all_commands ()
+{
+ local i
+ for i in $(git help -a|egrep '^ [a-zA-Z0-9]')
+ do
+ case $i in
+ *--*) : helper pattern;;
+ *) echo $i;;
+ esac
+ done
+}
+
+
+__git_porcelain_commands ()
+{
+ local i
+ for i in "help" $(__git_all_commands)
+ do
+ case $i in
+ *--*) : helper pattern;;
+ applymbox) : ask gittus;;
+ applypatch) : ask gittus;;
+ archimport) : import;;
+ cat-file) : plumbing;;
+ check-attr) : plumbing;;
+ check-ref-format) : plumbing;;
+ checkout-index) : plumbing;;
+ commit-tree) : plumbing;;
+ count-objects) : infrequent;;
+ cvsexportcommit) : export;;
+ cvsimport) : import;;
+ cvsserver) : daemon;;
+ daemon) : daemon;;
+ diff-files) : plumbing;;
+ diff-index) : plumbing;;
+ diff-tree) : plumbing;;
+ fast-import) : import;;
+ fast-export) : export;;
+ fsck-objects) : plumbing;;
+ fetch-pack) : plumbing;;
+ fmt-merge-msg) : plumbing;;
+ for-each-ref) : plumbing;;
+ hash-object) : plumbing;;
+ http-*) : transport;;
+ index-pack) : plumbing;;
+ init-db) : deprecated;;
+ local-fetch) : plumbing;;
+ lost-found) : infrequent;;
+ ls-files) : plumbing;;
+ ls-remote) : plumbing;;
+ ls-tree) : plumbing;;
+ mailinfo) : plumbing;;
+ mailsplit) : plumbing;;
+ merge-*) : plumbing;;
+ mktree) : plumbing;;
+ mktag) : plumbing;;
+ pack-objects) : plumbing;;
+ pack-redundant) : plumbing;;
+ pack-refs) : plumbing;;
+ parse-remote) : plumbing;;
+ patch-id) : plumbing;;
+ peek-remote) : plumbing;;
+ prune) : plumbing;;
+ prune-packed) : plumbing;;
+ quiltimport) : import;;
+ read-tree) : plumbing;;
+ receive-pack) : plumbing;;
+ reflog) : plumbing;;
+ repo-config) : deprecated;;
+ rerere) : plumbing;;
+ rev-list) : plumbing;;
+ rev-parse) : plumbing;;
+ runstatus) : plumbing;;
+ sh-setup) : internal;;
+ shell) : daemon;;
+ show-ref) : plumbing;;
+ send-pack) : plumbing;;
+ show-index) : plumbing;;
+ ssh-*) : transport;;
+ stripspace) : plumbing;;
+ symbolic-ref) : plumbing;;
+ tar-tree) : deprecated;;
+ unpack-file) : plumbing;;
+ unpack-objects) : plumbing;;
+ update-index) : plumbing;;
+ update-ref) : plumbing;;
+ update-server-info) : daemon;;
+ upload-archive) : plumbing;;
+ upload-pack) : plumbing;;
+ write-tree) : plumbing;;
+ var) : infrequent;;
+ verify-pack) : infrequent;;
+ verify-tag) : plumbing;;
+ *) echo $i;;
+ esac
+ done
+}
+
+
+__git_merge_strategylist=$(__git_merge_strategies | tr '\n' ' ')
+__git_all_commandlist="$(__git_all_commands | tr '\n' ' ')"
+__git_porcelain_commandlist="$(__git_porcelain_commands | tr '\n' ' ')"
+
+
+sed -e "s/__GIT_MERGE_STRATEGYLIST/\"$__git_merge_strategylist\"/" \
+ -e "s/__GIT_ALL_COMMANDLIST/\"$__git_all_commandlist\"/" \
+ -e "s/__GIT_PORCELAIN_COMMANDLIST/\"$__git_porcelain_commandlist\"/" \
+ git-completion.bash.in > git-completion.bash
+
diff --git a/contrib/completion/git-completion.bash b/contrib/completion/git-completion.bash.in
old mode 100755
new mode 100644
similarity index 90%
rename from contrib/completion/git-completion.bash
rename to contrib/completion/git-completion.bash.in
index 652a47c..67d03c3
--- a/contrib/completion/git-completion.bash
+++ b/contrib/completion/git-completion.bash.in
@@ -21,13 +21,7 @@
# 2) Added the following line to your .bashrc:
# source ~/.git-completion.sh
#
-# 3) You may want to make sure the git executable is available
-# in your PATH before this script is sourced, as some caching
-# is performed while the script loads. If git isn't found
-# at source time then all lookups will be done on demand,
-# which may be slightly slower.
-#
-# 4) Consider changing your PS1 to also show the current branch:
+# 3) Consider changing your PS1 to also show the current branch:
# PS1='[\u@\h \W$(__git_ps1 " (%s)")]\$ '
#
# The argument to __git_ps1 will be displayed only if you
@@ -60,6 +54,21 @@
# git@vger.kernel.org
#
+
+# pregenerated stuff (to save load time)
+__git_merge_strategylist=__GIT_MERGE_STRATEGYLIST
+__git_all_commandlist=__GIT_ALL_COMMANDLIST
+__git_porcelain_commandlist=__GIT_PORCELAIN_COMMANDLIST
+
+# remind folks that git-completion.bash.in can't be sourced
+case "$__git_merge_strategylist" in
+__GIT*)
+ echo "E: git-completion.bash.in can't be sourced"
+ return 1 ;;
+esac
+
+
+
case "$COMP_WORDBREAKS" in
*:*) : great ;;
*) COMP_WORDBREAKS="$COMP_WORDBREAKS:"
@@ -324,23 +333,6 @@ __git_remotes ()
done
}
-__git_merge_strategies ()
-{
- if [ -n "${__git_merge_strategylist-}" ]; then
- echo "$__git_merge_strategylist"
- return
- fi
- git merge -s help 2>&1 |
- sed -n -e '/[Aa]vailable strategies are: /,/^$/{
- s/\.$//
- s/.*://
- s/^[ ]*//
- s/[ ]*$//
- p
- }'
-}
-__git_merge_strategylist=
-__git_merge_strategylist=$(__git_merge_strategies 2>/dev/null)
__git_complete_file ()
{
@@ -476,128 +468,19 @@ __git_complete_strategy ()
{
case "${COMP_WORDS[COMP_CWORD-1]}" in
-s|--strategy)
- __gitcomp "$(__git_merge_strategies)"
+ __gitcomp "$__git_merge_strategylist"
return 0
esac
local cur="${COMP_WORDS[COMP_CWORD]}"
case "$cur" in
--strategy=*)
- __gitcomp "$(__git_merge_strategies)" "" "${cur##--strategy=}"
+ __gitcomp "$__git_merge_strategylist" "" "${cur##--strategy=}"
return 0
;;
esac
return 1
}
-__git_all_commands ()
-{
- if [ -n "${__git_all_commandlist-}" ]; then
- echo "$__git_all_commandlist"
- return
- fi
- 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_commandlist=
-__git_all_commandlist="$(__git_all_commands 2>/dev/null)"
-
-__git_porcelain_commands ()
-{
- if [ -n "${__git_porcelain_commandlist-}" ]; then
- echo "$__git_porcelain_commandlist"
- return
- fi
- local i IFS=" "$'\n'
- for i in "help" $(__git_all_commands)
- do
- case $i in
- *--*) : helper pattern;;
- applymbox) : ask gittus;;
- applypatch) : ask gittus;;
- archimport) : import;;
- cat-file) : plumbing;;
- check-attr) : plumbing;;
- check-ref-format) : plumbing;;
- checkout-index) : plumbing;;
- commit-tree) : plumbing;;
- count-objects) : infrequent;;
- cvsexportcommit) : export;;
- cvsimport) : import;;
- cvsserver) : daemon;;
- daemon) : daemon;;
- diff-files) : plumbing;;
- diff-index) : plumbing;;
- diff-tree) : plumbing;;
- fast-import) : import;;
- fast-export) : export;;
- fsck-objects) : plumbing;;
- fetch-pack) : plumbing;;
- fmt-merge-msg) : plumbing;;
- for-each-ref) : plumbing;;
- hash-object) : plumbing;;
- http-*) : transport;;
- index-pack) : plumbing;;
- init-db) : deprecated;;
- local-fetch) : plumbing;;
- lost-found) : infrequent;;
- ls-files) : plumbing;;
- ls-remote) : plumbing;;
- ls-tree) : plumbing;;
- mailinfo) : plumbing;;
- mailsplit) : plumbing;;
- merge-*) : plumbing;;
- mktree) : plumbing;;
- mktag) : plumbing;;
- pack-objects) : plumbing;;
- pack-redundant) : plumbing;;
- pack-refs) : plumbing;;
- parse-remote) : plumbing;;
- patch-id) : plumbing;;
- peek-remote) : plumbing;;
- prune) : plumbing;;
- prune-packed) : plumbing;;
- quiltimport) : import;;
- read-tree) : plumbing;;
- receive-pack) : plumbing;;
- reflog) : plumbing;;
- repo-config) : deprecated;;
- rerere) : plumbing;;
- rev-list) : plumbing;;
- rev-parse) : plumbing;;
- runstatus) : plumbing;;
- sh-setup) : internal;;
- shell) : daemon;;
- show-ref) : plumbing;;
- send-pack) : plumbing;;
- show-index) : plumbing;;
- ssh-*) : transport;;
- stripspace) : plumbing;;
- symbolic-ref) : plumbing;;
- tar-tree) : deprecated;;
- unpack-file) : plumbing;;
- unpack-objects) : plumbing;;
- update-index) : plumbing;;
- update-ref) : plumbing;;
- update-server-info) : daemon;;
- upload-archive) : plumbing;;
- upload-pack) : plumbing;;
- write-tree) : plumbing;;
- var) : infrequent;;
- verify-pack) : infrequent;;
- verify-tag) : plumbing;;
- *) echo $i;;
- esac
- done
-}
-__git_porcelain_commandlist=
-__git_porcelain_commandlist="$(__git_porcelain_commands 2>/dev/null)"
-
__git_aliases ()
{
local i IFS=$'\n'
@@ -1077,7 +960,7 @@ _git_help ()
return
;;
esac
- __gitcomp "$(__git_all_commands)
+ __gitcomp "$__git_all_commandlist
attributes cli core-tutorial cvs-migration
diffcore gitk glossary hooks ignore modules
repository-layout tutorial tutorial-2
@@ -1423,7 +1306,7 @@ _git_config ()
return
;;
pull.twohead|pull.octopus)
- __gitcomp "$(__git_merge_strategies)"
+ __gitcomp "$__git_merge_strategylist"
return
;;
color.branch|color.diff|color.interactive|\
@@ -1524,7 +1407,7 @@ _git_config ()
pager.*)
local pfx="${cur%.*}."
cur="${cur#*.}"
- __gitcomp "$(__git_all_commands)" "$pfx" "$cur"
+ __gitcomp "$__git_all_commandlist" "$pfx" "$cur"
return
;;
remote.*.*)
@@ -2116,7 +1999,7 @@ _git ()
--help
"
;;
- *) __gitcomp "$(__git_porcelain_commands) $(__git_aliases)" ;;
+ *) __gitcomp "$__git_porcelain_commandlist $(__git_aliases)" ;;
esac
return
fi
--
1.6.5.rc2.18.g84f98.dirty
^ permalink raw reply related
* Re: [PATCH 4/8] imap-send: fix compilation-error on Windows
From: Matt Kraai @ 2009-10-09 15:42 UTC (permalink / raw)
To: git
In-Reply-To: <1255100682-13952-4-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund <kusmabite <at> googlemail.com> writes:
> +#ifdef DRV_OK
> +#undef DRV_OK
> +#endif
> +
It shouldn't be necessary to check whether DRV_OK is defined before undefining
it; if it's not defined, undefining it will be a NOP.
^ permalink raw reply
* Re: [PATCH 1/8] imap-send: remove useless uid code
From: Matt Kraai @ 2009-10-09 15:46 UTC (permalink / raw)
To: git
In-Reply-To: <1255100682-13952-1-git-send-email-kusmabite@gmail.com>
Erik Faye-Lund <kusmabite <at> googlemail.com> writes:
> Presumably this is used in isync to be able to synchronize
> mailstores multiple times without duplication. But for
> imap-send, it the values are useless; we never do anything
> with them and simply forget them at the end of the program.
On the third line of this paragraph, "it" should be removed.
^ permalink raw reply
* Re: [PATCH] Speedup bash completion loading
From: Shawn O. Pearce @ 2009-10-09 15:39 UTC (permalink / raw)
To: Kirill Smelkov; +Cc: Ted Pavlic, git
In-Reply-To: <20091009152149.GA26171@tugrik.mns.mnsspb.ru>
Kirill Smelkov <kirr@mns.spb.ru> wrote:
> On Fri, Oct 09, 2009 at 07:46:06AM -0700, Shawn O. Pearce wrote:
> >
> > Squash this into the first patch and add the egrep change made by
> > Stephen Boyd "[PATCH 1/2] completion: fix completion of git <TAB><TAB>".
>
> While it is technically easy to do so, isn't this a bad idea to squash
> semantic changes and fixes into something which should be as close as
> code movement?
The ejection forces the code to build with /bin/bash, unless you
apply the trivial fixes related to IFS to make it work with dash.
As they are trivial the tiny semantic change during the code move
is just cleaner.
> Especially Stephen's fix?
I expect Junio to apply his patch first, and then yours. Since he
is changing a region you are moving, you need to account for it in
your patch, otherwise we have a conflict and/or a regression.
--
Shawn.
^ permalink raw reply
* Re: [PATCH] Speedup bash completion loading
From: Kirill Smelkov @ 2009-10-09 15:21 UTC (permalink / raw)
To: Shawn O. Pearce; +Cc: Ted Pavlic, git
In-Reply-To: <20091009144606.GT9261@spearce.org>
On Fri, Oct 09, 2009 at 07:46:06AM -0700, Shawn O. Pearce wrote:
> Kirill Smelkov <kirr@mns.spb.ru> wrote:
> > On Thu, Oct 08, 2009 at 08:02:06AM -0700, Shawn O. Pearce wrote:
> > > We probably should place a quick comment here to remind folks that
> > > they need to build the script in order to test it properly.
> >
> > I've added some sort of protection, so that git-completion.bash.in can't
> > be sourced at all. Is it ok?
>
> Yes, looks fine.
Thanks.
> > Subject: [PATCH 2/2] bash: make git-completion.bash.generate bash agnostic
>
> Squash this into the first patch and add the egrep change made by
> Stephen Boyd "[PATCH 1/2] completion: fix completion of git <TAB><TAB>".
While it is technically easy to do so, isn't this a bad idea to squash
semantic changes and fixes into something which should be as close as
code movement? Especially Stephen's fix?
Sure you are the maintainer, but maybe let's apply this 3 patches as
separate ones? I don't insist - this is just my 1коп.
Kirill
^ permalink raw reply
* Re: [PATCH 1/8] imap-send: remove useless uid code
From: Sverre Rabbelier @ 2009-10-09 15:21 UTC (permalink / raw)
To: Erik Faye-Lund; +Cc: git, gitster, Jeff King, Erik Faye-Lund
In-Reply-To: <1255100682-13952-1-git-send-email-kusmabite@gmail.com>
Heya,
On Fri, Oct 9, 2009 at 17:04, Erik Faye-Lund <kusmabite@googlemail.com> wrote:
Please include a cover letter for series as long as these (anything
larger than 4 should have a cover letter IMHO). Doing so makes it
easier for those that follow the series to see what changed (assuming
you write down what changed in the cover letter). Also, it makes it
easier for those that were not following the series to drop in at the
current version (assuming you provide a short summary of what the
series is about in the cover letter)..
--
Cheers,
Sverre Rabbelier
^ 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