* [PATCH] diff: Fix rename pretty-print when suffix and prefix overlap
From: Antoine Pelisse @ 2013-02-23 16:48 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
When considering a rename for two files that have a suffix and a prefix
that can overlap, a confusing line is shown. As an example, renaming
"a/b/b/c" to "a/b/c" shows "a/b/{ => }/b/c".
Currently, what we do is calculate the common prefix ("a/b/"), and the
common suffix ("/b/c"), but the same "/b/" is actually counted both in
prefix and suffix. Then when calculating the size of the non-common part,
we end-up with a negative value which is reset to 0, thus the "{ => }".
Do not allow the common suffix to overlap the common prefix and stop
when reaching a "/" that would be in both.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
diff.c | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)
diff --git a/diff.c b/diff.c
index 156fec4..80f4752 100644
--- a/diff.c
+++ b/diff.c
@@ -1290,7 +1290,16 @@ static char *pprint_rename(const char *a, const char *b)
old = a + len_a;
new = b + len_b;
sfx_length = 0;
- while (a <= old && b <= new && *old == *new) {
+ /*
+ * Note:
+ * if pfx_length is 0, old/new will never reach a - 1 because it
+ * would mean the whole string is common suffix. But then, the
+ * whole string would also be a common prefix, and we would not
+ * have pfx_length equals 0.
+ */
+ while (a + pfx_length - 1 <= old &&
+ b + pfx_length - 1 <= new &&
+ *old == *new) {
if (*old == '/')
sfx_length = len_a - (old - a);
old--;
--
1.7.9.5
^ permalink raw reply related
* [PATCH] l10n: de.po: correct translation of "bisect" messages
From: Ralf Thielow @ 2013-02-23 17:04 UTC (permalink / raw)
To: trast, jk, stimming; +Cc: git, Ralf Thielow
The term "bisect" was translated as "halbieren", we should
translate it as "binäre Suche" (binary search). While at
there, we should leave "bisect run" untranslated since it's
a subcommand of "git bisect".
Suggested-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
po/de.po | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/po/de.po b/po/de.po
index c0e5398..58a1a46 100644
--- a/po/de.po
+++ b/po/de.po
@@ -1349,11 +1349,11 @@ msgstr " (alle Konflikte behoben: führen Sie \"git commit\" aus)"
#: wt-status.c:958
#, c-format
msgid "You are currently bisecting branch '%s'."
-msgstr "Sie sind gerade beim Halbieren in Zweig '%s'."
+msgstr "Sie sind gerade bei einer binären Suche in Zweig '%s'."
#: wt-status.c:962
msgid "You are currently bisecting."
-msgstr "Sie sind gerade beim Halbieren."
+msgstr "Sie sind gerade bei einer binären Suche."
#: wt-status.c:965
msgid " (use \"git bisect reset\" to get back to the original branch)"
@@ -9247,7 +9247,7 @@ msgstr ""
#: git-bisect.sh:140
msgid "won't bisect on seeked tree"
-msgstr "\"bisect\" auf gesuchtem Zweig nicht möglich"
+msgstr "binäre Suche auf gesuchtem Zweig nicht möglich"
#: git-bisect.sh:144
msgid "Bad HEAD - strange symbolic ref"
@@ -9280,7 +9280,7 @@ msgstr "'git bisect bad' kann nur ein Argument entgegennehmen."
#. this is less optimum.
#: git-bisect.sh:273
msgid "Warning: bisecting only with a bad commit."
-msgstr "Warnung: halbiere nur mit einer fehlerhaften Version"
+msgstr "Warnung: binäre Suche nur mit einer fehlerhaften Version"
#. TRANSLATORS: Make sure to include [Y] and [n] in your
#. translation. The program will only accept English input
@@ -9310,7 +9310,7 @@ msgstr ""
#: git-bisect.sh:347 git-bisect.sh:474
msgid "We are not bisecting."
-msgstr "Wir sind nicht beim Halbieren."
+msgstr "keine binären Suche im Gange"
#: git-bisect.sh:354
#, sh-format
@@ -9350,12 +9350,12 @@ msgid ""
"bisect run failed:\n"
"exit code $res from '$command' is < 0 or >= 128"
msgstr ""
-"Ausführung der Halbierung fehlgeschlagen:\n"
+"'bisect run' fehlgeschlagen:\n"
"Rückkehrwert $res von '$command' ist < 0 oder >= 128"
#: git-bisect.sh:453
msgid "bisect run cannot continue any more"
-msgstr "Ausführung der Halbierung kann nicht mehr fortgesetzt werden"
+msgstr "'bisect run' kann nicht mehr fortgesetzt werden"
#: git-bisect.sh:459
#, sh-format
@@ -9363,12 +9363,12 @@ msgid ""
"bisect run failed:\n"
"'bisect_state $state' exited with error code $res"
msgstr ""
-"Ausführung der Halbierung fehlgeschlagen:\n"
+"'bisect run' fehlgeschlagen:\n"
"'bisect_state $state' wurde mit Fehlerwert $res beendet"
#: git-bisect.sh:466
msgid "bisect run success"
-msgstr "Halbierung erfolgreich ausgeführt"
+msgstr "'bisect run' erfolgreich ausgeführt"
#: git-pull.sh:21
msgid ""
--
1.8.2.rc0.22.gb3600c3
^ permalink raw reply related
* Re: [PATCH] l10n: de.po: correct translation of "bisect" messages
From: Thomas Rast @ 2013-02-23 17:25 UTC (permalink / raw)
To: Ralf Thielow; +Cc: trast, jk, stimming, git
In-Reply-To: <1361639092-6564-1-git-send-email-ralf.thielow@gmail.com>
Ralf Thielow <ralf.thielow@gmail.com> writes:
> diff --git a/po/de.po b/po/de.po
> index c0e5398..58a1a46 100644
> --- a/po/de.po
> +++ b/po/de.po
> @@ -1349,11 +1349,11 @@ msgstr " (alle Konflikte behoben: führen Sie
> \"git commit\" aus)"
> #: wt-status.c:958
> #, c-format
> msgid "You are currently bisecting branch '%s'."
> -msgstr "Sie sind gerade beim Halbieren in Zweig '%s'."
> +msgstr "Sie sind gerade bei einer binären Suche in Zweig '%s'."
^^^
"an"? Or is that again my Swiss non-German interfering?
> #: wt-status.c:962
> msgid "You are currently bisecting."
> -msgstr "Sie sind gerade beim Halbieren."
> +msgstr "Sie sind gerade bei einer binären Suche."
Same here.
> #: git-bisect.sh:140
> msgid "won't bisect on seeked tree"
> -msgstr "\"bisect\" auf gesuchtem Zweig nicht möglich"
> +msgstr "binäre Suche auf gesuchtem Zweig nicht möglich"
Does cogito actually have a German translation? The comment right above
this message says it's only for cogito users.
Then again cogito has been deprecated since 2006. Maybe the English
message should instead be rewritten to say "stop using cg!". ;-)
> #. TRANSLATORS: Make sure to include [Y] and [n] in your
> #. translation. The program will only accept English input
> @@ -9310,7 +9310,7 @@ msgstr ""
>
> #: git-bisect.sh:347 git-bisect.sh:474
> msgid "We are not bisecting."
> -msgstr "Wir sind nicht beim Halbieren."
> +msgstr "keine binären Suche im Gange"
^
s/n / /
--
Thomas Rast
trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCH] update-index: allow "-h" to also display options
From: Antoine Pelisse @ 2013-02-23 18:10 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
Currently, when running "git update-index -h", you only have usage
displayed, but no options. That is not consistent with the behavior of
other commands. It also means that the only way to display options is to
use an unknown argument (or use the man page).
Display usage with options when "git update-index -h" is invoked.
Signed-off-by: Antoine Pelisse <apelisse@gmail.com>
---
builtin/update-index.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/update-index.c b/builtin/update-index.c
index ada1dff..3071ee6 100644
--- a/builtin/update-index.c
+++ b/builtin/update-index.c
@@ -796,7 +796,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
};
if (argc == 2 && !strcmp(argv[1], "-h"))
- usage(update_index_usage[0]);
+ usage_with_options(&update_index_usage[0], options);
git_config(git_default_config, NULL);
--
1.7.9.5
^ permalink raw reply related
* Re: [PATCH] update-index: allow "-h" to also display options
From: Antoine Pelisse @ 2013-02-23 18:13 UTC (permalink / raw)
To: git; +Cc: Antoine Pelisse
In-Reply-To: <1361643041-19036-1-git-send-email-apelisse@gmail.com>
> diff --git a/builtin/update-index.c b/builtin/update-index.c
> index ada1dff..3071ee6 100644
> --- a/builtin/update-index.c
> +++ b/builtin/update-index.c
> @@ -796,7 +796,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
> };
>
> if (argc == 2 && !strcmp(argv[1], "-h"))
> - usage(update_index_usage[0]);
> + usage_with_options(&update_index_usage[0], options);
>
> git_config(git_default_config, NULL);
>
Ok I just realized that
usage_with_options(update_index_usage, options);
would be better...
Antoine,
^ permalink raw reply
* Re: [PATCH] l10n: de.po: correct translation of "bisect" messages
From: Ralf Thielow @ 2013-02-23 18:16 UTC (permalink / raw)
To: Thomas Rast; +Cc: trast, jk, stimming, git
In-Reply-To: <87ehg76iy9.fsf@pctrast.inf.ethz.ch>
2013/2/23 Thomas Rast <trast@inf.ethz.ch>:
> Ralf Thielow <ralf.thielow@gmail.com> writes:
>
>> diff --git a/po/de.po b/po/de.po
>> index c0e5398..58a1a46 100644
>> --- a/po/de.po
>> +++ b/po/de.po
>> @@ -1349,11 +1349,11 @@ msgstr " (alle Konflikte behoben: führen Sie
>> \"git commit\" aus)"
>> #: wt-status.c:958
>> #, c-format
>> msgid "You are currently bisecting branch '%s'."
>> -msgstr "Sie sind gerade beim Halbieren in Zweig '%s'."
>> +msgstr "Sie sind gerade bei einer binären Suche in Zweig '%s'."
> ^^^
>
> "an"? Or is that again my Swiss non-German interfering?
>
I think "bei" is correct when a search is in progress.
"bei einer Suche sein", "an einer Suche beteiligen" but not
"an einer Suche sein", IMO
Unfortunately, I haven't found a serious proof on the internet.
There is a picture with a subheading on
http://www.duden.de/rechtschreibung/Suche
which says "...bei der Suche nach...", though.
>> #: wt-status.c:962
>> msgid "You are currently bisecting."
>> -msgstr "Sie sind gerade beim Halbieren."
>> +msgstr "Sie sind gerade bei einer binären Suche."
>
> Same here.
>
>> #: git-bisect.sh:140
>> msgid "won't bisect on seeked tree"
>> -msgstr "\"bisect\" auf gesuchtem Zweig nicht möglich"
>> +msgstr "binäre Suche auf gesuchtem Zweig nicht möglich"
>
> Does cogito actually have a German translation? The comment right above
> this message says it's only for cogito users.
>
> Then again cogito has been deprecated since 2006. Maybe the English
> message should instead be rewritten to say "stop using cg!". ;-)
>
>> #. TRANSLATORS: Make sure to include [Y] and [n] in your
>> #. translation. The program will only accept English input
>> @@ -9310,7 +9310,7 @@ msgstr ""
>>
>> #: git-bisect.sh:347 git-bisect.sh:474
>> msgid "We are not bisecting."
>> -msgstr "Wir sind nicht beim Halbieren."
>> +msgstr "keine binären Suche im Gange"
> ^
>
> s/n / /
>
Thanks.
> --
> Thomas Rast
> trast@{inf,student}.ethz.ch
^ permalink raw reply
* [PATCHv2] l10n: de.po: correct translation of "bisect" messages
From: Ralf Thielow @ 2013-02-23 18:17 UTC (permalink / raw)
To: trast, jk, stimming; +Cc: git, Ralf Thielow
In-Reply-To: <1361639092-6564-1-git-send-email-ralf.thielow@gmail.com>
The term "bisect" was translated as "halbieren", we should
translate it as "binäre Suche" (binary search). While at
there, we should leave "bisect run" untranslated since it's
a subcommand of "git bisect".
Suggested-by: Thomas Rast <trast@inf.ethz.ch>
Signed-off-by: Ralf Thielow <ralf.thielow@gmail.com>
---
po/de.po | 18 +++++++++---------
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/po/de.po b/po/de.po
index c0e5398..4df53e4 100644
--- a/po/de.po
+++ b/po/de.po
@@ -1349,11 +1349,11 @@ msgstr " (alle Konflikte behoben: führen Sie \"git commit\" aus)"
#: wt-status.c:958
#, c-format
msgid "You are currently bisecting branch '%s'."
-msgstr "Sie sind gerade beim Halbieren in Zweig '%s'."
+msgstr "Sie sind gerade bei einer binären Suche in Zweig '%s'."
#: wt-status.c:962
msgid "You are currently bisecting."
-msgstr "Sie sind gerade beim Halbieren."
+msgstr "Sie sind gerade bei einer binären Suche."
#: wt-status.c:965
msgid " (use \"git bisect reset\" to get back to the original branch)"
@@ -9247,7 +9247,7 @@ msgstr ""
#: git-bisect.sh:140
msgid "won't bisect on seeked tree"
-msgstr "\"bisect\" auf gesuchtem Zweig nicht möglich"
+msgstr "binäre Suche auf gesuchtem Zweig nicht möglich"
#: git-bisect.sh:144
msgid "Bad HEAD - strange symbolic ref"
@@ -9280,7 +9280,7 @@ msgstr "'git bisect bad' kann nur ein Argument entgegennehmen."
#. this is less optimum.
#: git-bisect.sh:273
msgid "Warning: bisecting only with a bad commit."
-msgstr "Warnung: halbiere nur mit einer fehlerhaften Version"
+msgstr "Warnung: binäre Suche nur mit einer fehlerhaften Version"
#. TRANSLATORS: Make sure to include [Y] and [n] in your
#. translation. The program will only accept English input
@@ -9310,7 +9310,7 @@ msgstr ""
#: git-bisect.sh:347 git-bisect.sh:474
msgid "We are not bisecting."
-msgstr "Wir sind nicht beim Halbieren."
+msgstr "keine binäre Suche im Gange"
#: git-bisect.sh:354
#, sh-format
@@ -9350,12 +9350,12 @@ msgid ""
"bisect run failed:\n"
"exit code $res from '$command' is < 0 or >= 128"
msgstr ""
-"Ausführung der Halbierung fehlgeschlagen:\n"
+"'bisect run' fehlgeschlagen:\n"
"Rückkehrwert $res von '$command' ist < 0 oder >= 128"
#: git-bisect.sh:453
msgid "bisect run cannot continue any more"
-msgstr "Ausführung der Halbierung kann nicht mehr fortgesetzt werden"
+msgstr "'bisect run' kann nicht mehr fortgesetzt werden"
#: git-bisect.sh:459
#, sh-format
@@ -9363,12 +9363,12 @@ msgid ""
"bisect run failed:\n"
"'bisect_state $state' exited with error code $res"
msgstr ""
-"Ausführung der Halbierung fehlgeschlagen:\n"
+"'bisect run' fehlgeschlagen:\n"
"'bisect_state $state' wurde mit Fehlerwert $res beendet"
#: git-bisect.sh:466
msgid "bisect run success"
-msgstr "Halbierung erfolgreich ausgeführt"
+msgstr "'bisect run' erfolgreich ausgeführt"
#: git-pull.sh:21
msgid ""
--
1.8.2.rc0.22.gb3600c3
^ permalink raw reply related
* Re: [PATCH] Spelling fixes.
From: René Scharfe @ 2013-02-23 18:23 UTC (permalink / raw)
To: Ville Skyttä; +Cc: git
In-Reply-To: <1361629899-8346-1-git-send-email-ville.skytta@iki.fi>
Am 23.02.2013 15:31, schrieb Ville Skyttä:
>
> Signed-off-by: Ville Skyttä <ville.skytta@iki.fi>
> ---
> Documentation/RelNotes/1.7.5.4.txt | 2 +-
> Documentation/RelNotes/1.7.8.txt | 2 +-
Retroactively changing release notes for older versions is not worth it,
I think.
> Documentation/RelNotes/1.8.2.txt | 2 +-
Fixing typos in this draft for the next release is a good idea, though.
> kwset.c | 4 ++--
> xdiff/xdiffi.c | 2 +-
These files come from external sources and it would be nice to push
fixes (not just for typos) upstream as well.
René
^ permalink raw reply
* [PATCH] pkt-line: Fix sparse errors and warnings
From: Ramsay Jones @ 2013-02-23 18:44 UTC (permalink / raw)
To: Jeff King; +Cc: Junio C Hamano, GIT Mailing-list
Sparse issues the following error and warnings:
pkt-line.c:209:51: warning: Using plain integer as NULL pointer
sideband.c:41:52: warning: Using plain integer as NULL pointer
daemon.c:615:39: warning: Using plain integer as NULL pointer
remote-curl.c:220:75: error: incompatible types for operation (>)
remote-curl.c:220:75: left side has type char *
remote-curl.c:220:75: right side has type int
remote-curl.c:291:53: warning: Using plain integer as NULL pointer
remote-curl.c:408:43: warning: Using plain integer as NULL pointer
remote-curl.c:562:47: warning: Using plain integer as NULL pointer
All of these complaints "blame" to commit 17243606 ("pkt-line: share
buffer/descriptor reading implementation", 20-02-2013).
In order to suppress the warnings, we simply replace the integer
constant 0 with NULL.
In order to suppress the error message, we simply remove the "> 0" from
the while loop controlling expression.
Signed-off-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
---
Hi Jeff,
When you next re-roll your 'jk/pkt-line-cleanup' patches, could you
please squash this (or something like it) into commit 17243606
("pkt-line: share buffer/descriptor reading implementation", 20-02-2013).
Please check the resolution of the sparse error, remote-curl.c:220, since
I didn't think too deeply about it, making some assumptions ... ;-)
Note: the commit message mentions an strbuf_get_line() function, but
that is supposed to be packet_get_line(), right?
In addition, that commit adds the following code as part of function
get_packet_data():
+ /* Read up to "size" bytes from our source, whatever it is. */
+ if (src_buf && *src_buf) {
+ ret = size < *src_size ? size : *src_size;
+ memcpy(dst, *src_buf, ret);
+ *src_buf += size;
............................^^^^^
+ *src_size -= size;
+ } else {
+
This could lead to the source buffer pointer being incremented past the
"one past the end" of the buffer; ie to undefined behaviour. That use
of 'size', along with the one on the following line, should be 'ret' no?
ATB,
Ramsay Jones
daemon.c | 2 +-
pkt-line.c | 2 +-
remote-curl.c | 8 ++++----
sideband.c | 2 +-
4 files changed, 7 insertions(+), 7 deletions(-)
diff --git a/daemon.c b/daemon.c
index 9a241d9..82d5bf5 100644
--- a/daemon.c
+++ b/daemon.c
@@ -612,7 +612,7 @@ static int execute(void)
loginfo("Connection from %s:%s", addr, port);
alarm(init_timeout ? init_timeout : timeout);
- pktlen = packet_read(0, NULL, 0, packet_buffer, sizeof(packet_buffer), 0);
+ pktlen = packet_read(0, NULL, NULL, packet_buffer, sizeof(packet_buffer), 0);
alarm(0);
len = strlen(line);
diff --git a/pkt-line.c b/pkt-line.c
index 116d5f1..2793ecb 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -206,7 +206,7 @@ static char *packet_read_line_generic(int fd,
char *packet_read_line(int fd, int *len_p)
{
- return packet_read_line_generic(fd, NULL, 0, len_p);
+ return packet_read_line_generic(fd, NULL, NULL, len_p);
}
char *packet_read_line_buf(char **src, size_t *src_len, int *dst_len)
diff --git a/remote-curl.c b/remote-curl.c
index 3d2b194..93a09a6 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -217,7 +217,7 @@ static struct discovery* discover_refs(const char *service, int for_push)
* until a packet flush marker. Ignore these now, but
* in the future we might start to scan them.
*/
- while (packet_read_line_buf(&last->buf, &last->len, NULL) > 0)
+ while (packet_read_line_buf(&last->buf, &last->len, NULL))
;
last->proto_git = 1;
@@ -288,7 +288,7 @@ static size_t rpc_out(void *ptr, size_t eltsize,
if (!avail) {
rpc->initial_buffer = 0;
- avail = packet_read(rpc->out, NULL, 0, rpc->buf, rpc->alloc, 0);
+ avail = packet_read(rpc->out, NULL, NULL, rpc->buf, rpc->alloc, 0);
if (!avail)
return 0;
rpc->pos = 0;
@@ -405,7 +405,7 @@ static int post_rpc(struct rpc_state *rpc)
break;
}
- n = packet_read(rpc->out, 0, NULL, buf, left, 0);
+ n = packet_read(rpc->out, NULL, NULL, buf, left, 0);
if (!n)
break;
rpc->len += n;
@@ -559,7 +559,7 @@ static int rpc_service(struct rpc_state *rpc, struct discovery *heads)
rpc->hdr_accept = strbuf_detach(&buf, NULL);
while (!err) {
- int n = packet_read(rpc->out, 0, NULL, rpc->buf, rpc->alloc, 0);
+ int n = packet_read(rpc->out, NULL, NULL, rpc->buf, rpc->alloc, 0);
if (!n)
break;
rpc->pos = 0;
diff --git a/sideband.c b/sideband.c
index 857954c..d1125f5 100644
--- a/sideband.c
+++ b/sideband.c
@@ -38,7 +38,7 @@ int recv_sideband(const char *me, int in_stream, int out)
while (1) {
int band, len;
- len = packet_read(in_stream, NULL, 0, buf + pf, LARGE_PACKET_MAX, 0);
+ len = packet_read(in_stream, NULL, NULL, buf + pf, LARGE_PACKET_MAX, 0);
if (len == 0)
break;
if (len < 1) {
--
1.8.1
^ permalink raw reply related
* Re: Suggested improvements to the git-p4 documentation (branch-related)
From: Junio C Hamano @ 2013-02-23 19:11 UTC (permalink / raw)
To: Pete Wyckoff; +Cc: Olivier Delalleau, git
In-Reply-To: <20130223144803.GA5444@padd.com>
Pete Wyckoff <pw@padd.com> writes:
> All of it is in master now, via 801cbd7 (Merge branch
> 'pw/p4-branch-fixes', 2013-01-21).
>
> I should have commented on this thread too. Thanks for following
> up!
Thanks.
^ permalink raw reply
* Re: [PATCH v3] branch: segfault fixes and validation
From: Junio C Hamano @ 2013-02-23 20:01 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Per Cederqvist
In-Reply-To: <1361622147-20921-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy <pclouds@gmail.com> writes:
> > What you can do is to have a single helper function that can explain
> > why branch_get() returned NULL (or extend branch_get() to serve that
> > purpose as well); then you do not have to duplicate the logic twice
> > on the caller's side (and there may be other callers that want to do
> > the same).
>
> The explanation mentions about the failed operation, which makes a
> helper less useful. We could still do the helper, but it may lead to
> i18n legos. So no helper in this version.
Who said explanation has to be conveyed in human language to the
caller of the helper? Since there are only two possible cases, at
least for now, and I do not think there will be countless many in
the future, for the branch_get() function to fail, you can still do:
int explain_error;
struct branch *branch = branch_get(argv[0], &explain_error);
switch (explain_error) {
case DEFAULT_HEAD_DETACHED:
case GIVEN_HEAD_DETACHED:
die(_("could not make %s upstream of the current branch "
"because you do not have one"), new_upstream);
break;
default:
break;
}
and we could even fold the !ref_exists() check that is there for
typo-detection purposes into the framework, e.g.
case GIVEN_BRANCH_DOES_NOT_EXIST:
die(_("you told me to make %s upstream of %s "
"but the latter does not exist yet"),
new_upstream, argv[0]);
if we wanted to preserve what the current test does, no?
> > The existing test might be wrong, by the way. Your HEAD may point
> > at a branch Y but you may not have any commit on it yet, and you may
> > want to allow setting the upstream of that to-be-born branch to
> > another branch X with "branch --set-upstream-to=X [Y|HEAD]".
>
> It sounds complicated. I think we can revisit it when a user actually
> complains about it.
Yeah, will replace the previous one and queue this version.
Thanks.
^ permalink raw reply
* Re: patch for fix build git on Haiku
From: Jonathan Nieder @ 2013-02-23 20:42 UTC (permalink / raw)
To: diger; +Cc: git, Andreas Färber
In-Reply-To: <254e4f8fb172cec1e547413e2828b642@freenet59.ru>
Hi,
diger wrote:
> This patch fixes build git on Haiku
Lovely. May we have your sign-off? (See
Documentation/SubmittingPatches for what this means.) Does "make
test" pass? (Just curious --- it's fine if it doesn't, though in that
case a list of test failures would be helpful.)
Thanks,
Jonathan
(patch left unsnipped for reference)
> --- Makefile.orig 2012-10-21 21:32:15.000000000 +0000
> +++ Makefile
> @@ -1211,6 +1204,16 @@ ifeq ($(uname_S),HP-UX)
> endif
> GIT_TEST_CMP = cmp
> endif
> +ifeq ($(uname_S),Haiku)
> + NO_R_TO_GCC_LINKER = YesPlease
> + NO_LIBGEN_H = YesPlease
> + NO_MEMMEM = YesPlease
> + NO_MKSTEMPS = YesPlease
> + NEEDS_LIBICONV = YesPlease
> + DEFAULT_EDITOR = nano
> + PTHREAD_LIBS = -lroot
> + NO_CROSS_DIRECTORY_HARDLINKS = YesPlease
> +endif
> ifeq ($(uname_S),Windows)
> GIT_VERSION := $(GIT_VERSION).MSVC
> pathsep = ;
^ permalink raw reply
* Re: [PATCH 3/2] update-index: list supported idx versions and their features
From: Jonathan Nieder @ 2013-02-23 20:53 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1361584468-11820-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy wrote:
> --- a/Documentation/git-update-index.txt
> +++ b/Documentation/git-update-index.txt
> @@ -145,7 +145,15 @@ you will need to handle the situation manually.
>
> --index-version <n>::
> Write the resulting index out in the named on-disk format version.
> - The current default version is 2.
> + Supported versions are 2, 3 and 4. The current default version is 2
> + or 3, depending on whether extra features are used, such as
> + `git add -N`.
> ++
> + Version 4 performs a simple pathname compression that could
> + reduce index size by 30%-50% on large repositories, which
> + results in faster load time. Version 4 is relatively young
> + (first released in 1.8.0 in October 2012). Other Git
> + implementations may not support it yet.
Markup nit: the second paragraph needs to be unindented, or asciidoc
will treat it as literal text, including line breaks.
Usage nit: s/could/can/
Clarity nit: something like "such as JGit and libgit2" after "Other
Git implementations" would make it clearer, at least to my eyes.
Aside from that, this looks like a good change.
Thanks,
Jonathan
^ permalink raw reply
* Re: [PATCH v2 3/2] update-index: list supported idx versions and their features
From: Jonathan Nieder @ 2013-02-23 20:55 UTC (permalink / raw)
To: Nguyễn Thái Ngọc Duy; +Cc: git, Junio C Hamano
In-Reply-To: <1361586571-12917-1-git-send-email-pclouds@gmail.com>
Nguyễn Thái Ngọc Duy wrote:
> Oops, bogus indentation in the first 3/2
Oops, I missed this. Ok, ignore the comment on indentation on v1. :)
With or without the other changes I suggested,
Reviewed-by: Jonathan Nieder <jrnieder@gmail.com>
^ permalink raw reply
* Re: [PATCH v2] Documentation/githooks: Explain pre-rebase parameters
From: Junio C Hamano @ 2013-02-23 21:21 UTC (permalink / raw)
To: W. Trevor King; +Cc: Git, Thomas Rast
In-Reply-To: <c8b19dc074a81b009399ff1011102737761658ec.1361633106.git.wking@tremily.us>
"W. Trevor King" <wking@tremily.us> writes:
> +This hook is called by 'git rebase' and can be used to prevent a
> +branch from getting rebased. The hook takes two parameters: the
> +upstream the series was forked from and the branch being rebased. The
> +second parameter will be missing when rebasing the current branch.
takes one or two parameters?
Other than that, looks good to me, but it took me two readings to
notice where these two parameters are described. I have a feeling
that a comma s/forked from and/forked from, and/; might make them a
bit more spottable, but others may have better suggestions to make
them stand out more.
Thanks, will queue.
>
> post-checkout
> ~~~~~~~~~~~~~
^ permalink raw reply
* Re: [PATCH 3/2] update-index: list supported idx versions and their features
From: Junio C Hamano @ 2013-02-23 21:23 UTC (permalink / raw)
To: Jonathan Nieder; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <20130223205356.GC3222@elie.Belkin>
Thanks, both.
Jonathan Nieder <jrnieder@gmail.com> writes:
> Nguyễn Thái Ngọc Duy wrote:
> ...
>> + Version 4 performs a simple pathname compression that could
>> + reduce index size by 30%-50% on large repositories, which
>> + results in faster load time. Version 4 is relatively young
>> + (first released in 1.8.0 in October 2012). Other Git
>> + implementations may not support it yet.
>
> Usage nit: s/could/can/
I think s/could reduce/reduces/ is even simpler.
^ permalink raw reply
* Re: [PATCH] update-index: allow "-h" to also display options
From: Junio C Hamano @ 2013-02-23 21:25 UTC (permalink / raw)
To: Antoine Pelisse; +Cc: git
In-Reply-To: <CALWbr2x4En9qof7hFL+Onh1M1080=-OaJtAsNYY01qRj5R1a1w@mail.gmail.com>
Antoine Pelisse <apelisse@gmail.com> writes:
>> diff --git a/builtin/update-index.c b/builtin/update-index.c
>> index ada1dff..3071ee6 100644
>> --- a/builtin/update-index.c
>> +++ b/builtin/update-index.c
>> @@ -796,7 +796,7 @@ int cmd_update_index(int argc, const char **argv, const char *prefix)
>> };
>>
>> if (argc == 2 && !strcmp(argv[1], "-h"))
>> - usage(update_index_usage[0]);
>> + usage_with_options(&update_index_usage[0], options);
>>
>> git_config(git_default_config, NULL);
>>
>
> Ok I just realized that
>
> usage_with_options(update_index_usage, options);
>
> would be better...
Yeah, that probably is easier on the eyes, even though they are
equivalent.
Thanks, will queue.
^ permalink raw reply
* Re: [PATCH v2] Documentation/githooks: Explain pre-rebase parameters
From: W. Trevor King @ 2013-02-23 21:35 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Git, Thomas Rast
In-Reply-To: <7vobfa7mko.fsf@alter.siamese.dyndns.org>
[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]
On Sat, Feb 23, 2013 at 01:21:59PM -0800, Junio C Hamano wrote:
> "W. Trevor King" <wking@tremily.us> writes:
>
> > +This hook is called by 'git rebase' and can be used to prevent a
> > +branch from getting rebased. The hook takes two parameters: the
> > +upstream the series was forked from and the branch being rebased. The
> > +second parameter will be missing when rebasing the current branch.
>
> takes one or two parameters?
>
> Other than that, looks good to me, but it took me two readings to
> notice where these two parameters are described. I have a feeling
> that a comma s/forked from and/forked from, and/; might make them a
> bit more spottable, but others may have better suggestions to make
> them stand out more.
How about:
The hook may be called with one or two parameters. The first
parameter is the upstream from which the series was forked. The
second parameter is the branch being rebased, and is not set when
rebasing the current branch.
--
This email may be signed or encrypted with GnuPG (http://www.gnupg.org).
For more information, see http://en.wikipedia.org/wiki/Pretty_Good_Privacy
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]
^ permalink raw reply
* Re: [PATCH 3/2] update-index: list supported idx versions and their features
From: Jonathan Nieder @ 2013-02-23 21:53 UTC (permalink / raw)
To: Junio C Hamano; +Cc: Nguyễn Thái Ngọc Duy, git
In-Reply-To: <7vk3py7mi5.fsf@alter.siamese.dyndns.org>
Junio C Hamano wrote:
> Jonathan Nieder <jrnieder@gmail.com> writes:
>> Nguyễn Thái Ngọc Duy wrote:
>>> + Version 4 performs a simple pathname compression that could
>>> + reduce index size by 30%-50% on large repositories, which
>>> + results in faster load time. Version 4 is relatively young
>>> + (first released in 1.8.0 in October 2012). Other Git
>>> + implementations may not support it yet.
>>
>> Usage nit: s/could/can/
>
> I think s/could reduce/reduces/ is even simpler.
Yes, true. Thanks.
^ permalink raw reply
* [PATCH] Improve QNX support in GIT
From: Mike Gorchak @ 2013-02-23 22:02 UTC (permalink / raw)
To: git
[-- Attachment #1: Type: text/plain, Size: 978 bytes --]
Hi,
Here is a small patch with QNX build improvements:
1) Rename tar.h to tar_git.h. Latest QNX versions have system tar.h
header according to
http://pubs.opengroup.org/onlinepubs/009696699/basedefs/tar.h.html ,
to avoid inclusion of another tar.h, original header was renamed.
2) Rename fnmatch.h to fnmatch_gnu.h and fnmatch.c to fnmatch_gnu.c to
avoid inclusion of system fnmatch.h header in case if -I/usr/include
path is specified before -Icompat/fnmatch. Which is common situation.
3) pager.c - default "less" invocation flags were changed for QNX 6,x
platform, since QNX has incompatible with GNU coreutils version of
"less" utility.
4) config.mak.uname - a) do not override mkdtemp/mkstemps/strcasestr
detection, since newer QNX version could contain such functions. Let
to configure decide what is present in the system. b) getpagesize()
function is existing under QNX, c) QNX has pthread functions in the
libc, so do not define NO_PTHREAD macro.
Thanks in advance!
[-- Attachment #2: git-qnx.diff --]
[-- Type: application/octet-stream, Size: 3742 bytes --]
diff --git a/Makefile b/Makefile
index ba8e243..f6dd2eb 100644
--- a/Makefile
+++ b/Makefile
@@ -726,7 +726,7 @@ LIB_H += streaming.h
LIB_H += string-list.h
LIB_H += submodule.h
LIB_H += tag.h
-LIB_H += tar.h
+LIB_H += tar_git.h
LIB_H += thread-utils.h
LIB_H += transport.h
LIB_H += tree-walk.h
@@ -1256,12 +1256,12 @@ endif
ifdef NO_FNMATCH
COMPAT_CFLAGS += -Icompat/fnmatch
COMPAT_CFLAGS += -DNO_FNMATCH
- COMPAT_OBJS += compat/fnmatch/fnmatch.o
+ COMPAT_OBJS += compat/fnmatch/fnmatch_gnu.o
else
ifdef NO_FNMATCH_CASEFOLD
COMPAT_CFLAGS += -Icompat/fnmatch
COMPAT_CFLAGS += -DNO_FNMATCH_CASEFOLD
- COMPAT_OBJS += compat/fnmatch/fnmatch.o
+ COMPAT_OBJS += compat/fnmatch/fnmatch_gnu.o
endif
endif
ifdef USE_WILDMATCH
diff --git a/archive-tar.c b/archive-tar.c
index 719b629..8e24336 100644
--- a/archive-tar.c
+++ b/archive-tar.c
@@ -2,7 +2,7 @@
* Copyright (c) 2005, 2006 Rene Scharfe
*/
#include "cache.h"
-#include "tar.h"
+#include "tar_git.h"
#include "archive.h"
#include "streaming.h"
#include "run-command.h"
diff --git a/builtin/tar-tree.c b/builtin/tar-tree.c
index 3f1e701..b0e4551 100644
--- a/builtin/tar-tree.c
+++ b/builtin/tar-tree.c
@@ -3,7 +3,7 @@
*/
#include "cache.h"
#include "commit.h"
-#include "tar.h"
+#include "tar_git.h"
#include "builtin.h"
#include "quote.h"
diff --git a/compat/fnmatch/fnmatch.c b/compat/fnmatch/fnmatch_gnu.c
similarity index 99%
rename from compat/fnmatch/fnmatch.c
rename to compat/fnmatch/fnmatch_gnu.c
index 5ef0685..f9a5e5b 100644
--- a/compat/fnmatch/fnmatch.c
+++ b/compat/fnmatch/fnmatch_gnu.c
@@ -26,7 +26,7 @@
#endif
#include <errno.h>
-#include <fnmatch.h>
+#include <fnmatch_gnu.h>
#include <ctype.h>
#if HAVE_STRING_H || defined _LIBC
diff --git a/compat/fnmatch/fnmatch.h b/compat/fnmatch/fnmatch_gnu.h
similarity index 100%
rename from compat/fnmatch/fnmatch.h
rename to compat/fnmatch/fnmatch_gnu.h
diff --git a/config.mak.uname b/config.mak.uname
index 8743a6d..2d42ffe 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -527,14 +527,21 @@ ifeq ($(uname_S),QNX)
HAVE_STRINGS_H = YesPlease
NEEDS_SOCKET = YesPlease
NO_FNMATCH_CASEFOLD = YesPlease
- NO_GETPAGESIZE = YesPlease
NO_ICONV = YesPlease
NO_MEMMEM = YesPlease
- NO_MKDTEMP = YesPlease
- NO_MKSTEMPS = YesPlease
NO_NSEC = YesPlease
- NO_PTHREADS = YesPlease
NO_R_TO_GCC_LINKER = YesPlease
- NO_STRCASESTR = YesPlease
NO_STRLCPY = YesPlease
+ # All QNX 6.x versions have pthread functions in libc
+ # and getpagesize. Leave mkstemps/mkdtemp/strcasestr for
+ # autodetection.
+ ifeq ($(shell expr "$(uname_R)" : '6\.[0-9]\.[0-9]'),5)
+ PTHREAD_LIBS = ""
+ else
+ NO_PTHREADS = YesPlease
+ NO_GETPAGESIZE = YesPlease
+ NO_STRCASESTR = YesPlease
+ NO_MKSTEMPS = YesPlease
+ NO_MKDTEMP = YesPlease
+ endif
endif
diff --git a/git-compat-util.h b/git-compat-util.h
index b7eaaa9..f59d696 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -113,7 +113,11 @@
#include <time.h>
#include <signal.h>
#ifndef USE_WILDMATCH
+#if defined(NO_FNMATCH) || defined(NO_FNMATCH_CASEFOLD)
+#include <fnmatch_gnu.h>
+#else
#include <fnmatch.h>
+#endif /* NO_FNMATCH */
#endif
#include <assert.h>
#include <regex.h>
diff --git a/pager.c b/pager.c
index c1ecf65..bed627a 100644
--- a/pager.c
+++ b/pager.c
@@ -81,7 +81,11 @@ void setup_pager(void)
pager_process.argv = pager_argv;
pager_process.in = -1;
if (!getenv("LESS")) {
+ #if !defined(__QNXNTO__)
static const char *env[] = { "LESS=FRSX", NULL };
+ #else
+ static const char *env[] = { "LESS=rS", NULL };
+ #endif /* __QNXNTO__ */
pager_process.env = env;
}
if (start_command(&pager_process))
diff --git a/tar.h b/tar_git.h
similarity index 100%
rename from tar.h
rename to tar_git.h
^ permalink raw reply related
* Re: [PATCH] pkt-line: Fix sparse errors and warnings
From: Jeff King @ 2013-02-23 22:31 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <51290DF4.4040309@ramsay1.demon.co.uk>
On Sat, Feb 23, 2013 at 06:44:04PM +0000, Ramsay Jones wrote:
> Sparse issues the following error and warnings:
>
> pkt-line.c:209:51: warning: Using plain integer as NULL pointer
> sideband.c:41:52: warning: Using plain integer as NULL pointer
> daemon.c:615:39: warning: Using plain integer as NULL pointer
> remote-curl.c:220:75: error: incompatible types for operation (>)
> remote-curl.c:220:75: left side has type char *
> remote-curl.c:220:75: right side has type int
> remote-curl.c:291:53: warning: Using plain integer as NULL pointer
> remote-curl.c:408:43: warning: Using plain integer as NULL pointer
> remote-curl.c:562:47: warning: Using plain integer as NULL pointer
>
> All of these complaints "blame" to commit 17243606 ("pkt-line: share
> buffer/descriptor reading implementation", 20-02-2013).
>
> In order to suppress the warnings, we simply replace the integer
> constant 0 with NULL.
Thanks for catching. This was just a think-o on my part; we want to pass
(NULL, 0) as the (buf, len) pair, but of course we are passing pointers
to them, so it is actually (NULL, NULL). And yes, I made sure the
function correctly handles both a NULL pointer-to-buf and a NULL
pointer-to-pointer-to-buf (and we do not even care about the
pointer-to-len unless the buf pointer is valid).
So no bug, but definitely a reasonable cleanup.
Oddly, you seemed to miss the one in connect.c (which my sparse does
detect).
> In order to suppress the error message, we simply remove the "> 0" from
> the while loop controlling expression.
Yeah, that is the right thing to do. The code that's there isn't wrong,
but I agree that checking "ptr != NULL" (i.e., just "ptr") is much more
sane than "ptr > 0" (and is just a leftover that I missed during
refactoring the patch).
> When you next re-roll your 'jk/pkt-line-cleanup' patches, could you
> please squash this (or something like it) into commit 17243606
> ("pkt-line: share buffer/descriptor reading implementation", 20-02-2013).
I don't think we otherwise need a re-roll. Junio hasn't merged the
series to next yet, so I've included an updated patch 15 below with your
changes (your patch, the missing connect.c fix, the commit message fix,
and the size/ret thing below).
> In addition, that commit adds the following code as part of function
> get_packet_data():
>
> + /* Read up to "size" bytes from our source, whatever it is. */
> + if (src_buf && *src_buf) {
> + ret = size < *src_size ? size : *src_size;
> + memcpy(dst, *src_buf, ret);
> + *src_buf += size;
> ............................^^^^^
> + *src_size -= size;
> + } else {
> +
>
> This could lead to the source buffer pointer being incremented past the
> "one past the end" of the buffer; ie to undefined behaviour. That use
> of 'size', along with the one on the following line, should be 'ret' no?
Yeah, thanks for catching. We just die immediately afterwards anyway,
and sane systems do not care what kind of junk you put into a pointer
unless you dereference. But clearly it is supposed to be "ret".
Thanks for the report. Clearly I should start running "make sparse" more
often (the reason I don't is that it produces dozens of complaints about
constants in /usr/include/bits/xopen_lim.h, which I could obviously care
less about; I should look into suppressing that).
Updated patch 15/19 is below.
-- >8 --
Subject: [PATCH] pkt-line: share buffer/descriptor reading implementation
The packet_read function reads from a descriptor. The
packet_get_line function is similar, but reads from an
in-memory buffer, and uses a completely separate
implementation. This patch teaches the generic packet_read
function to accept either source, and we can do away with
packet_get_line's implementation.
There are two other differences to account for between the
old and new functions. The first is that we used to read
into a strbuf, but now read into a fixed size buffer. The
only two callers are fine with that, and in fact it
simplifies their code, since they can use the same
static-buffer interface as the rest of the packet_read_line
callers (and we provide a similar convenience wrapper for
reading from a buffer rather than a descriptor).
This is technically an externally-visible behavior change in
that we used to accept arbitrary sized packets up to 65532
bytes, and now cap out at LARGE_PACKET_MAX, 65520. In
practice this doesn't matter, as we use it only for parsing
smart-http headers (of which there is exactly one defined,
and it is small and fixed-size). And any extension headers
would be breaking the protocol to go over LARGE_PACKET_MAX
anyway.
The other difference is that packet_get_line would return
on error rather than dying. However, both callers of
packet_get_line are actually improved by dying.
The first caller does its own error checking, but we can
drop that; as a result, we'll actually get more specific
reporting about protocol breakage when packet_read dies
internally. The only downside is that packet_read will not
print the smart-http URL that failed, but that's not a big
deal; anybody not debugging can already see the remote's URL
already, and anybody debugging would want to run with
GIT_CURL_VERBOSE anyway to see way more information.
The second caller, which is just trying to skip past any
extra smart-http headers (of which there are none defined,
but which we allow to keep room for future expansion), did
not error check at all. As a result, it would treat an error
just like a flush packet. The resulting mess would generally
cause an error later in get_remote_heads, but now we get
error reporting much closer to the source of the problem.
Brown-paper-bag-fixes-by: Ramsay Jones <ramsay@ramsay1.demon.co.uk>
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
connect.c | 3 ++-
daemon.c | 2 +-
pkt-line.c | 76 +++++++++++++++++++++++++++++------------------------------
pkt-line.h | 23 +++++++++++++-----
remote-curl.c | 22 ++++++++---------
sideband.c | 2 +-
6 files changed, 69 insertions(+), 59 deletions(-)
diff --git a/connect.c b/connect.c
index 611ffb4..3d99999 100644
--- a/connect.c
+++ b/connect.c
@@ -76,7 +76,8 @@ struct ref **get_remote_heads(int in, struct ref **list,
int len, name_len;
char *buffer = packet_buffer;
- len = packet_read(in, packet_buffer, sizeof(packet_buffer),
+ len = packet_read(in, NULL, NULL,
+ packet_buffer, sizeof(packet_buffer),
PACKET_READ_GENTLE_ON_EOF |
PACKET_READ_CHOMP_NEWLINE);
if (len < 0)
diff --git a/daemon.c b/daemon.c
index 3f70e79..82d5bf5 100644
--- a/daemon.c
+++ b/daemon.c
@@ -612,7 +612,7 @@ static int execute(void)
loginfo("Connection from %s:%s", addr, port);
alarm(init_timeout ? init_timeout : timeout);
- pktlen = packet_read(0, packet_buffer, sizeof(packet_buffer), 0);
+ pktlen = packet_read(0, NULL, NULL, packet_buffer, sizeof(packet_buffer), 0);
alarm(0);
len = strlen(line);
diff --git a/pkt-line.c b/pkt-line.c
index 55fb688..70f1950 100644
--- a/pkt-line.c
+++ b/pkt-line.c
@@ -104,12 +104,28 @@ static int safe_read(int fd, void *buffer, unsigned size, int options)
strbuf_add(buf, buffer, n);
}
-static int safe_read(int fd, void *buffer, unsigned size, int options)
+static int get_packet_data(int fd, char **src_buf, size_t *src_size,
+ void *dst, unsigned size, int options)
{
- ssize_t ret = read_in_full(fd, buffer, size);
- if (ret < 0)
- die_errno("read error");
- else if (ret < size) {
+ ssize_t ret;
+
+ if (fd >= 0 && src_buf && *src_buf)
+ die("BUG: multiple sources given to packet_read");
+
+ /* Read up to "size" bytes from our source, whatever it is. */
+ if (src_buf && *src_buf) {
+ ret = size < *src_size ? size : *src_size;
+ memcpy(dst, *src_buf, ret);
+ *src_buf += ret;
+ *src_size -= ret;
+ } else {
+ ret = read_in_full(fd, dst, size);
+ if (ret < 0)
+ die_errno("read error");
+ }
+
+ /* And complain if we didn't get enough bytes to satisfy the read. */
+ if (ret < size) {
if (options & PACKET_READ_GENTLE_ON_EOF)
return -1;
@@ -144,12 +160,13 @@ int packet_read(int fd, char *buffer, unsigned size, int options)
return len;
}
-int packet_read(int fd, char *buffer, unsigned size, int options)
+int packet_read(int fd, char **src_buf, size_t *src_len,
+ char *buffer, unsigned size, int options)
{
int len, ret;
char linelen[4];
- ret = safe_read(fd, linelen, 4, options);
+ ret = get_packet_data(fd, src_buf, src_len, linelen, 4, options);
if (ret < 0)
return ret;
len = packet_length(linelen);
@@ -162,7 +179,7 @@ int packet_read(int fd, char *buffer, unsigned size, int options)
len -= 4;
if (len >= size)
die("protocol error: bad line length %d", len);
- ret = safe_read(fd, buffer, len, options);
+ ret = get_packet_data(fd, src_buf, src_len, buffer, len, options);
if (ret < 0)
return ret;
@@ -175,41 +192,24 @@ int packet_get_line(struct strbuf *out,
return len;
}
-char *packet_read_line(int fd, int *len_p)
+static char *packet_read_line_generic(int fd,
+ char **src, size_t *src_len,
+ int *dst_len)
{
- int len = packet_read(fd, packet_buffer, sizeof(packet_buffer),
+ int len = packet_read(fd, src, src_len,
+ packet_buffer, sizeof(packet_buffer),
PACKET_READ_CHOMP_NEWLINE);
- if (len_p)
- *len_p = len;
+ if (dst_len)
+ *dst_len = len;
return len ? packet_buffer : NULL;
}
-int packet_get_line(struct strbuf *out,
- char **src_buf, size_t *src_len)
+char *packet_read_line(int fd, int *len_p)
{
- int len;
-
- if (*src_len < 4)
- return -1;
- len = packet_length(*src_buf);
- if (len < 0)
- return -1;
- if (!len) {
- *src_buf += 4;
- *src_len -= 4;
- packet_trace("0000", 4, 0);
- return 0;
- }
- if (*src_len < len)
- return -2;
-
- *src_buf += 4;
- *src_len -= 4;
- len -= 4;
+ return packet_read_line_generic(fd, NULL, NULL, len_p);
+}
- strbuf_add(out, *src_buf, len);
- *src_buf += len;
- *src_len -= len;
- packet_trace(out->buf, out->len, 0);
- return len;
+char *packet_read_line_buf(char **src, size_t *src_len, int *dst_len)
+{
+ return packet_read_line_generic(-1, src, src_len, dst_len);
}
diff --git a/pkt-line.h b/pkt-line.h
index fa93e32..0a838d1 100644
--- a/pkt-line.h
+++ b/pkt-line.h
@@ -25,9 +25,16 @@ void packet_buf_write(struct strbuf *buf, const char *fmt, ...) __attribute__((f
void packet_buf_write(struct strbuf *buf, const char *fmt, ...) __attribute__((format (printf, 2, 3)));
/*
- * Read a packetized line from the descriptor into the buffer, which must be at
- * least size bytes long. The return value specifies the number of bytes read
- * into the buffer.
+ * Read a packetized line into the buffer, which must be at least size bytes
+ * long. The return value specifies the number of bytes read into the buffer.
+ *
+ * If src_buffer is not NULL (and nor is *src_buffer), it should point to a
+ * buffer containing the packet data to parse, of at least *src_len bytes.
+ * After the function returns, src_buf will be incremented and src_len
+ * decremented by the number of bytes consumed.
+ *
+ * If src_buffer (or *src_buffer) is NULL, then data is read from the
+ * descriptor "fd".
*
* If options does not contain PACKET_READ_GENTLE_ON_EOF, we will die under any
* of the following conditions:
@@ -50,7 +57,8 @@ void packet_buf_write(struct strbuf *buf, const char *fmt, ...) __attribute__((f
*/
#define PACKET_READ_GENTLE_ON_EOF (1u<<0)
#define PACKET_READ_CHOMP_NEWLINE (1u<<1)
-int packet_read(int fd, char *buffer, unsigned size, int options);
+int packet_read(int fd, char **src_buffer, size_t *src_len, char
+ *buffer, unsigned size, int options);
/*
* Convenience wrapper for packet_read that is not gentle, and sets the
@@ -61,11 +69,14 @@ extern char packet_buffer[LARGE_PACKET_MAX];
*/
char *packet_read_line(int fd, int *size);
+/*
+ * Same as packet_read_line, but read from a buf rather than a descriptor;
+ * see packet_read for details on how src_* is used.
+ */
+char *packet_read_line_buf(char **src_buf, size_t *src_len, int *size);
#define DEFAULT_PACKET_MAX 1000
#define LARGE_PACKET_MAX 65520
extern char packet_buffer[LARGE_PACKET_MAX];
-int packet_get_line(struct strbuf *out, char **src_buf, size_t *src_len);
-
#endif
diff --git a/remote-curl.c b/remote-curl.c
index b28f965..c8379a5 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -138,28 +138,26 @@ static struct discovery* discover_refs(const char *service)
if (maybe_smart &&
(5 <= last->len && last->buf[4] == '#') &&
!strbuf_cmp(&exp, &type)) {
+ char *line;
+
/*
* smart HTTP response; validate that the service
* pkt-line matches our request.
*/
- if (packet_get_line(&buffer, &last->buf, &last->len) <= 0)
- die("%s has invalid packet header", refs_url);
- if (buffer.len && buffer.buf[buffer.len - 1] == '\n')
- strbuf_setlen(&buffer, buffer.len - 1);
+ line = packet_read_line_buf(&last->buf, &last->len, NULL);
strbuf_reset(&exp);
strbuf_addf(&exp, "# service=%s", service);
- if (strbuf_cmp(&exp, &buffer))
- die("invalid server response; got '%s'", buffer.buf);
+ if (strcmp(line, exp.buf))
+ die("invalid server response; got '%s'", line);
strbuf_release(&exp);
/* The header can include additional metadata lines, up
* until a packet flush marker. Ignore these now, but
* in the future we might start to scan them.
*/
- strbuf_reset(&buffer);
- while (packet_get_line(&buffer, &last->buf, &last->len) > 0)
- strbuf_reset(&buffer);
+ while (packet_read_line_buf(&last->buf, &last->len, NULL))
+ ;
last->proto_git = 1;
}
@@ -308,7 +306,7 @@ static size_t rpc_out(void *ptr, size_t eltsize,
if (!avail) {
rpc->initial_buffer = 0;
- avail = packet_read(rpc->out, rpc->buf, rpc->alloc, 0);
+ avail = packet_read(rpc->out, NULL, NULL, rpc->buf, rpc->alloc, 0);
if (!avail)
return 0;
rpc->pos = 0;
@@ -425,7 +423,7 @@ static int post_rpc(struct rpc_state *rpc)
break;
}
- n = packet_read(rpc->out, buf, left, 0);
+ n = packet_read(rpc->out, NULL, NULL, buf, left, 0);
if (!n)
break;
rpc->len += n;
@@ -579,7 +577,7 @@ static int rpc_service(struct rpc_state *rpc, struct discovery *heads)
rpc->hdr_accept = strbuf_detach(&buf, NULL);
while (!err) {
- int n = packet_read(rpc->out, rpc->buf, rpc->alloc, 0);
+ int n = packet_read(rpc->out, NULL, NULL, rpc->buf, rpc->alloc, 0);
if (!n)
break;
rpc->pos = 0;
diff --git a/sideband.c b/sideband.c
index 15cc1ae..d1125f5 100644
--- a/sideband.c
+++ b/sideband.c
@@ -38,7 +38,7 @@ int recv_sideband(const char *me, int in_stream, int out)
while (1) {
int band, len;
- len = packet_read(in_stream, buf + pf, LARGE_PACKET_MAX, 0);
+ len = packet_read(in_stream, NULL, NULL, buf + pf, LARGE_PACKET_MAX, 0);
if (len == 0)
break;
if (len < 1) {
--
1.8.1.4.4.g265d2fa
^ permalink raw reply related
* Re: [PATCH] pkt-line: Fix sparse errors and warnings
From: Jeff King @ 2013-02-23 22:37 UTC (permalink / raw)
To: Ramsay Jones; +Cc: Junio C Hamano, GIT Mailing-list
In-Reply-To: <20130223223134.GA2504@sigill.intra.peff.net>
On Sat, Feb 23, 2013 at 05:31:34PM -0500, Jeff King wrote:
> On Sat, Feb 23, 2013 at 06:44:04PM +0000, Ramsay Jones wrote:
>
> > Sparse issues the following error and warnings:
> >
> > pkt-line.c:209:51: warning: Using plain integer as NULL pointer
> > sideband.c:41:52: warning: Using plain integer as NULL pointer
> > daemon.c:615:39: warning: Using plain integer as NULL pointer
> > remote-curl.c:220:75: error: incompatible types for operation (>)
> > remote-curl.c:220:75: left side has type char *
> > remote-curl.c:220:75: right side has type int
> > remote-curl.c:291:53: warning: Using plain integer as NULL pointer
> > remote-curl.c:408:43: warning: Using plain integer as NULL pointer
> > remote-curl.c:562:47: warning: Using plain integer as NULL pointer
> >
> > All of these complaints "blame" to commit 17243606 ("pkt-line: share
> > buffer/descriptor reading implementation", 20-02-2013).
> >
> > In order to suppress the warnings, we simply replace the integer
> > constant 0 with NULL.
> [...]
> Oddly, you seemed to miss the one in connect.c (which my sparse does
> detect).
Ah, I saw why as soon as I finished off the rebase: that (NULL, 0) goes
away in the very next patch, and you probably ran sparse just on the tip
of the topic (via pu). I still think it's worth fixing since we are
squashing anyway. Junio, it will give you a trivial conflict on patch
16, but you can just resolve in favor of what patch 16 does. If it's
easier, here's the revised patch 16:
-- >8 --
Subject: [PATCH] teach get_remote_heads to read from a memory buffer
Now that we can read packet data from memory as easily as a
descriptor, get_remote_heads can take either one as a
source. This will allow further refactoring in remote-curl.
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
---
builtin/fetch-pack.c | 2 +-
builtin/send-pack.c | 2 +-
cache.h | 4 +++-
connect.c | 6 +++---
remote-curl.c | 2 +-
transport.c | 6 +++---
6 files changed, 12 insertions(+), 10 deletions(-)
diff --git a/builtin/fetch-pack.c b/builtin/fetch-pack.c
index c21cc2c..03ed2ca 100644
--- a/builtin/fetch-pack.c
+++ b/builtin/fetch-pack.c
@@ -125,7 +125,7 @@ int cmd_fetch_pack(int argc, const char **argv, const char *prefix)
args.verbose ? CONNECT_VERBOSE : 0);
}
- get_remote_heads(fd[0], &ref, 0, NULL);
+ get_remote_heads(fd[0], NULL, 0, &ref, 0, NULL);
ref = fetch_pack(&args, fd, conn, ref, dest,
&sought, pack_lockfile_ptr);
diff --git a/builtin/send-pack.c b/builtin/send-pack.c
index 8778519..152c4ea 100644
--- a/builtin/send-pack.c
+++ b/builtin/send-pack.c
@@ -207,7 +207,7 @@ int cmd_send_pack(int argc, const char **argv, const char *prefix)
memset(&extra_have, 0, sizeof(extra_have));
- get_remote_heads(fd[0], &remote_refs, REF_NORMAL, &extra_have);
+ get_remote_heads(fd[0], NULL, 0, &remote_refs, REF_NORMAL, &extra_have);
transport_verify_remote_names(nr_refspecs, refspecs);
diff --git a/cache.h b/cache.h
index e493563..db646a2 100644
--- a/cache.h
+++ b/cache.h
@@ -1049,7 +1049,9 @@ struct extra_have_objects {
int nr, alloc;
unsigned char (*array)[20];
};
-extern struct ref **get_remote_heads(int in, struct ref **list, unsigned int flags, struct extra_have_objects *);
+extern struct ref **get_remote_heads(int in, char *src_buf, size_t src_len,
+ struct ref **list, unsigned int flags,
+ struct extra_have_objects *);
extern int server_supports(const char *feature);
extern int parse_feature_request(const char *features, const char *feature);
extern const char *server_feature_value(const char *feature, int *len_ret);
diff --git a/connect.c b/connect.c
index 3d99999..f57efd0 100644
--- a/connect.c
+++ b/connect.c
@@ -62,8 +62,8 @@ static void die_initial_contact(int got_at_least_one_head)
/*
* Read all the refs from the other end
*/
-struct ref **get_remote_heads(int in, struct ref **list,
- unsigned int flags,
+struct ref **get_remote_heads(int in, char *src_buf, size_t src_len,
+ struct ref **list, unsigned int flags,
struct extra_have_objects *extra_have)
{
int got_at_least_one_head = 0;
@@ -76,7 +76,7 @@ struct ref **get_remote_heads(int in, struct ref **list,
int len, name_len;
char *buffer = packet_buffer;
- len = packet_read(in, NULL, NULL,
+ len = packet_read(in, &src_buf, &src_len,
packet_buffer, sizeof(packet_buffer),
PACKET_READ_GENTLE_ON_EOF |
PACKET_READ_CHOMP_NEWLINE);
diff --git a/remote-curl.c b/remote-curl.c
index c8379a5..24c8626 100644
--- a/remote-curl.c
+++ b/remote-curl.c
@@ -192,7 +192,7 @@ static struct ref *parse_git_refs(struct discovery *heads, int for_push)
if (start_async(&async))
die("cannot start thread to parse advertised refs");
- get_remote_heads(async.out, &list,
+ get_remote_heads(async.out, NULL, 0, &list,
for_push ? REF_NORMAL : 0, NULL);
close(async.out);
if (finish_async(&async))
diff --git a/transport.c b/transport.c
index 886ffd8..62df466 100644
--- a/transport.c
+++ b/transport.c
@@ -507,7 +507,7 @@ static struct ref *get_refs_via_connect(struct transport *transport, int for_pus
struct ref *refs;
connect_setup(transport, for_push, 0);
- get_remote_heads(data->fd[0], &refs,
+ get_remote_heads(data->fd[0], NULL, 0, &refs,
for_push ? REF_NORMAL : 0, &data->extra_have);
data->got_remote_heads = 1;
@@ -541,7 +541,7 @@ static int fetch_refs_via_pack(struct transport *transport,
if (!data->got_remote_heads) {
connect_setup(transport, 0, 0);
- get_remote_heads(data->fd[0], &refs_tmp, 0, NULL);
+ get_remote_heads(data->fd[0], NULL, 0, &refs_tmp, 0, NULL);
data->got_remote_heads = 1;
}
@@ -799,7 +799,7 @@ static int git_transport_push(struct transport *transport, struct ref *remote_re
struct ref *tmp_refs;
connect_setup(transport, 1, 0);
- get_remote_heads(data->fd[0], &tmp_refs, REF_NORMAL, NULL);
+ get_remote_heads(data->fd[0], NULL, 0, &tmp_refs, REF_NORMAL, NULL);
data->got_remote_heads = 1;
}
--
1.8.1.4.4.g265d2fa
^ permalink raw reply related
* [PATCH 00/13] Git help option to list user guides
From: Philip Oakley @ 2013-02-23 23:05 UTC (permalink / raw)
To: GitList
The git help system will list common commands, and all commands
if asked. However it is difficult for newer users to discover the
guides that are available. This series seeks to add such an option
to 'git help', and allow the user-manual and [git]everyday to be
accessed in the same way.
Patch 1 to 7 update the codebase and look to work correctly.
Patch 1 & 3 are tidy ups.
The code is very strongly based on the existing common-commands
list so could be refactored and joined if the series is accepted.
Patch 8 onward get into areas of the documentation Makefile that I
need help on so that the user-manual and [git]everyday can
follow the naming convention for guides and be picked up by the code.
The intent is shown, but the Documentation/Makefile fails for the
renamed gituser-manual and giteveryday - advice needed.
I'm minded to make them have a man page format to simplify changes to
the make file but haven't managed to get that format right. The
alternative is to tweak the make file to cope with these 'pretty'
documents yet still move them to their new names. (I'm unfamiliar
with make files)
Holding pages have been created for the vacated page locations in
the same vein as used for Rename {git- => git}remote-helpers.txt
The patches are built upon V1.8.2-rc0 which includes the recent
user-manual changes.
Initial discussion was at $gmane/215814/focus=216146
Philip Oakley (13):
Use 'Git' in help messages
Show 'git help <guide>' usage, with examples
Help.c use OPT_COUNTUP
Help.c add --guide option
Help.c: add list_common_guides_help() function
Add guide-list.txt and extraction shell
Extend name string for longer names
Rename user-manual to gituser-manual
Rename everyday to giteveryday
Update Git(1) links to guides
Add missing guides to list and regenerate
Documentation/Makefile: update git guide links
Fixup! doc: giteveryday and user-manual man format
Documentation/Makefile | 4 +
Documentation/everyday.txt | 424 +---
Documentation/git.txt | 12 +-
Documentation/giteveryday.txt | 419 ++++
Documentation/gituser-manual.txt | 4639 +++++++++++++++++++++++++++++++++++++
Documentation/user-manual.txt | 4643 +-------------------------------------
builtin/help.c | 11 +-
common-guides.h | 15 +
generate-cmdlist.sh | 2 +-
generate-guidelist.sh | 23 +
git.c | 4 +-
guide-list.txt | 30 +
help.c | 30 +-
help.h | 1 +
14 files changed, 5208 insertions(+), 5049 deletions(-)
create mode 100644 Documentation/giteveryday.txt
create mode 100644 Documentation/gituser-manual.txt
create mode 100644 common-guides.h
create mode 100644 generate-guidelist.sh
create mode 100644 guide-list.txt
--
1.8.1.msysgit.1
^ permalink raw reply
* [PATCH 01/13] Use 'Git' in help messages
From: Philip Oakley @ 2013-02-23 23:05 UTC (permalink / raw)
To: GitList
In-Reply-To: <1361660761-1932-1-git-send-email-philipoakley@iee.org>
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
help.c | 12 ++++++------
1 file changed, 6 insertions(+), 6 deletions(-)
diff --git a/help.c b/help.c
index 1dfa0b0..1c0e17d 100644
--- a/help.c
+++ b/help.c
@@ -209,14 +209,14 @@ void list_commands(unsigned int colopts,
{
if (main_cmds->cnt) {
const char *exec_path = git_exec_path();
- printf_ln(_("available git commands in '%s'"), exec_path);
+ printf_ln(_("available Git commands in '%s'"), exec_path);
putchar('\n');
pretty_print_string_list(main_cmds, colopts);
putchar('\n');
}
if (other_cmds->cnt) {
- printf_ln(_("git commands available from elsewhere on your $PATH"));
+ printf_ln(_("Git commands available from elsewhere on your $PATH"));
putchar('\n');
pretty_print_string_list(other_cmds, colopts);
putchar('\n');
@@ -232,7 +232,7 @@ void list_common_cmds_help(void)
longest = strlen(common_cmds[i].name);
}
- puts(_("The most commonly used git commands are:"));
+ 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));
@@ -289,7 +289,7 @@ static void add_cmd_list(struct cmdnames *cmds, struct cmdnames *old)
#define SIMILAR_ENOUGH(x) ((x) < SIMILARITY_FLOOR)
static const char bad_interpreter_advice[] =
- N_("'%s' appears to be a git command, but we were not\n"
+ N_("'%s' appears to be a Git command, but we were not\n"
"able to execute it. Maybe git-%s is broken?");
const char *help_unknown_cmd(const char *cmd)
@@ -380,7 +380,7 @@ const char *help_unknown_cmd(const char *cmd)
return assumed;
}
- fprintf_ln(stderr, _("git: '%s' is not a git command. See 'git --help'."), cmd);
+ fprintf_ln(stderr, _("git: '%s' is not a Git command. See 'git --help'."), cmd);
if (SIMILAR_ENOUGH(best_similarity)) {
fprintf_ln(stderr,
@@ -397,6 +397,6 @@ const char *help_unknown_cmd(const char *cmd)
int cmd_version(int argc, const char **argv, const char *prefix)
{
- printf("git version %s\n", git_version_string);
+ printf("Git version %s\n", git_version_string);
return 0;
}
--
1.8.1.msysgit.1
^ permalink raw reply related
* [PATCH 02/13] Show 'git help <guide>' usage, with examples
From: Philip Oakley @ 2013-02-23 23:05 UTC (permalink / raw)
To: GitList
In-Reply-To: <1361660761-1932-1-git-send-email-philipoakley@iee.org>
The git(1) man page must be accessed via 'git help git' on Git for Windows
as it has no 'man' command. And it prompts users to read the git(1) page,
rather than hoping they follow a subsidiary link within another documentation
page. The 'tutorial' is an obvious guide to suggest.
Signed-off-by: Philip Oakley <philipoakley@iee.org>
---
git.c | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/git.c b/git.c
index b10c18b..bf0e0de 100644
--- a/git.c
+++ b/git.c
@@ -13,7 +13,9 @@ const char git_usage_string[] =
" <command> [<args>]";
const char git_more_info_string[] =
- N_("See 'git help <command>' for more information on a specific command.");
+ N_("See 'git help <command>' for more information on a specific command.\n"
+ "While 'git help <guide>', will show the selected Git concept guide.\n"
+ "Examples: 'git help git', 'git help branch', 'git help tutorial'..");
static struct startup_info git_startup_info;
static int use_pager = -1;
--
1.8.1.msysgit.1
^ permalink raw reply related
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