Elia Pinto writes:
> This is version 2 of the patch to git-submodule of the
> patch series "convert test -a/-o to && and ||".
> It contains the fixes identified by Johannes and
> Matthieu.
This version of the patch (not the whole series) is
Reviewed-by: Matthieu Moy
Some comments for next
On Wed, May 21, 2014 at 05:07:40PM -0700, Kyle J. McKay wrote:
> >+/* default charset from rfc2616 */
> >+if (!*charset)
> >+*charset = xstrdup("iso8859-1");
>
> Actually the name should be "ISO-8859-1". See RFC 2616 section 3.7.1.
> Since it's case insensitive "iso-8859-1" w
On Wed, May 21, 2014 at 05:07:38PM -0700, Kyle J. McKay wrote:
> >+p = skip_prefix(type->buf, "text/plain");
> >+if (!p || (*p && *p != ';'))
> >+return 0;
> >+
> >+return 1;
> >+}
> >+
>
> I think that a strict reading of RFC 2616 allows "text/plain ;
> charset=utf-8" as
On Wed, May 21, 2014 at 05:07:36PM -0700, Kyle J. McKay wrote:
> >+void strbuf_tolower(struct strbuf *sb)
> >+{
> >+size_t i;
> >+for (i = 0; i < sb->len; i++)
> >+sb->buf[i] = tolower(sb->buf[i]);
> >+}
> >+
>
> Wouldn't a direct transfer of the lowercase function be somethin
Good day,
We are Christian organization, we give loan to those who are dedicated
Christians, contact us at mercantilefinanceloanserv...@yahoo.com
Regard
Mercantile
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More maj
Junio C Hamano wrote:
> Felipe Contreras writes:
>
> > Junio C Hamano wrote:
> >
> >> * The remote-helper interface to fast-import/fast-export via the
> >>transport-helper has been tightened to avoid leaving the import
> >>marks file from a failed/crashed run, as such a file that is out-
Added option that allows a signature file to be used with format-patch
so that signatures with newlines and other special characters can be
easily included.
$ git format-patch --signature-file ~/.signature -1
The config variable format.signaturefile is also provided so that it
can be added by d
From: Jeff King
When we print an email signature, we print the divider "--
\n", then the signature string, then two newlines.
Traditionally the signature is a one-liner (and the default
is just the git version), so the extra newline makes sense.
But one could easily specify a longer, multi-line
v8 of patch to add format-patch --signature-file option.
This revision includes more suggestions from Jeff King and Junio C Hamano.
- Renamed variable which stores the signature to 'mail-signature'
which better describes what is being stored.
- Fixed a declaration after code (forbid
Ronnie Sahlberg wrote:
> --- a/refs.c
> +++ b/refs.c
> @@ -2044,6 +2044,9 @@ static struct ref_lock *lock_ref_sha1_basic(const char
> *refname,
> int missing = 0;
> int attempts_remaining = 3;
>
> + if (check_refname_format(refname, REFNAME_ALLOW_ONELEVEL))
> + return
Am 22.05.2014 00:14, schrieb Richard Hansen:
> On 2014-05-20 15:11, Karsten Blees wrote:
>> Add a getnanotime() function that returns nanoseconds since 01/01/1970 as
>> unsigned 64-bit integer (i.e. overflows in july 2554).
>
> Must it be relative to epoch? If it was relative to system boot (like
Am 21.05.2014 18:55, schrieb Jeff King:
> On Tue, May 20, 2014 at 09:11:24PM +0200, Karsten Blees wrote:
>
>> Add performance tracing to identify which git commands are called and how
>> long they execute. This is particularly useful to debug performance issues
>> of scripted commands.
>>
>> Usage
On May 21, 2014, at 03:27, Jeff King wrote:
This makes config's lowercase() function public.
Note that we could continue to offer a pure-string
lowercase, but there would be no callers (in most
pure-string cases, we actually duplicate and lowercase the
duplicate).
Signed-off-by: Jeff King
---
On May 21, 2014, at 03:33, Jeff King wrote:
Commit 426e70d (remote-curl: show server content on http
errors, 2013-04-05) tried to recognize text/plain content
types, but fails to do so if they have any parameters.
This patches makes our parsing more liberal, though we still
do not do anything u
On May 21, 2014, at 03:33, Jeff King wrote:
As of the last commit, we now recognize an error message
with a content-type "text/plain; charset=utf-16" as text,
but we ignore the charset parameter entirely. Let's encode
it to log_output_encoding, which is presumably something the
user's terminal c
Ronnie Sahlberg wrote:
> This means that most loose refs will no longer be present after the rename
Is this to handle the "git branch -m foo/bar foo" case or for some other
purpose?
[...]
> --- a/t/t3200-branch.sh
> +++ b/t/t3200-branch.sh
> @@ -289,7 +289,7 @@ test_expect_success 'renaming a sy
Ronnie Sahlberg wrote:
> Signed-off-by: Ronnie Sahlberg
> ---
> refs.c | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
Reviewed-by: Jonathan Nieder
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo inf
Ronnie Sahlberg wrote:
> Change the reference transactions so that we pass the reflog message
> through to the create/delete/update function instead of the commit message.
Nice.
[...]
> --- a/builtin/fetch.c
> +++ b/builtin/fetch.c
> @@ -673,7 +673,6 @@ static int store_updated_refs(const char *
Ronnie Sahlberg wrote:
> --- a/refs.c
> +++ b/refs.c
[...]
> @@ -2515,24 +2510,18 @@ static int delete_ref_loose(struct ref_lock *lock,
> int flag, struct strbuf *err)
>
> int delete_ref(const char *refname, const unsigned char *sha1, int delopt)
> {
> - struct ref_lock *lock;
> - int
On Wed, May 21, 2014 at 03:37:11PM -0700, Junio C Hamano wrote:
> Jeremiah Mahler writes:
>
> > Below is one of the updated test cases.
> >
> > test_expect_success 'format-patch --signature-file=mail-signature' '
> > cat >mail-signature <<-\EOF
> >
> > Test User
> > http://git.kernel
Ronnie Sahlberg wrote:
> Change prune_ref to delete the ref using a ref transaction. To do this we also
> need to add a new flag REF_ISPRUNING that will tell the transaction that we
> do not want to delete this ref from the packed refs.
Interesting. Since the flag is per ref update, it even woul
Jeremiah Mahler writes:
> On Wed, May 21, 2014 at 03:15:55PM -0700, Junio C Hamano wrote:
>> Jeff King writes:
>>
>> Yeah, placing it in its own setup may be the best. There are quite
>> a many set-ups outside the tests in this script from the olden days,
>> so I am OK if left it as-is and hav
Jeremiah Mahler writes:
> Below is one of the updated test cases.
>
> test_expect_success 'format-patch --signature-file=mail-signature' '
> cat >mail-signature <<-\EOF
>
> Test User
> http://git.kernel.org/cgit/git/git.git
>
> git.kernel.org/?p=git/git.git;a=summary
>
>
On Wed, May 21, 2014 at 03:15:55PM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> Yeah, placing it in its own setup may be the best. There are quite
> a many set-ups outside the tests in this script from the olden days,
> so I am OK if left it as-is and have a separate clean-up patch after
Ronnie Sahlberg wrote:
> Please pull my ref-transactions branch.
I'm at bd5736cb (2014-05-21 13:46) now.
> On Wed, May 21, 2014 at 3:00 PM, Jonathan Nieder wrote:
>> Ronnie Sahlberg wrote:
>>> --- a/refs.c
>>> +++ b/refs.c
>>> @@ -3308,6 +3308,12 @@ struct ref_update {
>>> const char ref
On 2014-05-21 18:14, Richard Hansen wrote:
> On 2014-05-20 15:11, Karsten Blees wrote:
>> Add a getnanotime() function that returns nanoseconds since 01/01/1970 as
>> unsigned 64-bit integer (i.e. overflows in july 2554).
>
> Must it be relative to epoch? If it was relative to system boot (like
>
Jeff King writes:
> I think he is responding to my earlier request to use test_must_fail
> instead of "!". But there is a subtlety there he does not know, which
> is that we typically only use the former for git programs, and rely on
> "!" for normal Unix commands.
Ok, that explains it. Thanks
On 2014-05-20 15:11, Karsten Blees wrote:
> Add a getnanotime() function that returns nanoseconds since 01/01/1970 as
> unsigned 64-bit integer (i.e. overflows in july 2554).
Must it be relative to epoch? If it was relative to system boot (like
the NetBSD kernel's nanouptime() function), then you
On Wed, May 21, 2014 at 02:58:42PM -0700, Junio C Hamano wrote:
> Jeremiah Mahler writes:
>
...
> The problem is a "cat" you added outside test_expect_*; the recent
> push is to have as little executable outside them, especially the
> "set-up" code to prepare for the real tests.
>
> i.e. we have
Please pull my ref-transactions branch.
On Wed, May 21, 2014 at 3:00 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> --- a/refs.c
>> +++ b/refs.c
>> @@ -3308,6 +3308,12 @@ struct ref_update {
>> const char refname[FLEX_ARRAY];
>> };
>>
>> +enum ref_transaction_status {
>> + RE
Ronnie Sahlberg wrote:
> Signed-off-by: Ronnie Sahlberg
> ---
> refs.c | 15 +--
> 1 file changed, 5 insertions(+), 10 deletions(-)
Heh. :)
Reviewed-by: Jonathan Nieder
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.ker
Ronnie Sahlberg wrote:
> +++ b/refs.c
[...]
> @@ -3518,14 +3499,16 @@ int ref_transaction_commit(struct ref_transaction
> *transaction,
> struct ref_update *update = updates[i];
>
> if (!is_null_sha1(update->new_sha1)) {
> - ret = update_ref_write
On Wed, May 21, 2014 at 02:58:42PM -0700, Junio C Hamano wrote:
> >> > ! grep "^-- \$" output
> > ...
> >>
> >> We have been trying not to do the above in recent test updates. It
> >> would be nice if this set-up did not have to be outside of the usual
> >> test_expect_success structure
Ronnie Sahlberg wrote:
> Signed-off-by: Ronnie Sahlberg
> ---
> refs.c | 30 ++
> 1 file changed, 6 insertions(+), 24 deletions(-)
Reviewed-by: Jonathan Nieder
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vg
Ronnie Sahlberg wrote:
> --- a/refs.c
> +++ b/refs.c
> @@ -3308,6 +3308,12 @@ struct ref_update {
> const char refname[FLEX_ARRAY];
> };
>
> +enum ref_transaction_status {
> + REF_TRANSACTION_OPEN = 0,
> + REF_TRANSACTION_CLOSED = 1,
> + REF_TRANSACTION_ERROR = 2,
What is
Jeremiah Mahler writes:
> + if (signature_file) {
> + if (signature && signature != git_version_string)
> + die(_("cannot specify both signature and
> signature-file"));
> +
> + struct strbuf buf = STRBUF_INIT;
builtin/log.c:1460:3: error: ISO C90
Jeremiah Mahler writes:
> On Wed, May 21, 2014 at 02:13:06PM -0700, Junio C Hamano wrote:
>> Jeremiah Mahler writes:
>>
> ...
>> >! grep "^-- \$" output
> ...
>>
>> We have been trying not to do the above in recent test updates. It
>> would be nice if this set-up did not have to be outsid
On Wed, May 21, 2014 at 02:13:06PM -0700, Junio C Hamano wrote:
> Jeremiah Mahler writes:
>
...
> > ! grep "^-- \$" output
...
>
> We have been trying not to do the above in recent test updates. It
> would be nice if this set-up did not have to be outside of the usual
> test_expect_success
Richard Hansen writes:
>> * The shell prompt script (in contrib/), when using the PROMPT_COMMAND
>>interface, used an unsafe construct when showing the branch name in
>>$PS1.
>>(merge 8976500 rh/prompt-pcmode-avoid-eval-on-refname later to maint).
>
> That commit has been merged to m
On Wed, May 21, 2014 at 6:13 PM, Henning Sprang
wrote:
>
> You'd say, can happen, when some developers work against the remote
> git repo, others with svn. But I'm the only developer on the project,
> and no one ever commits to the remote svn nor the remote git repo. So,
> I'm clueless.
>
> How ca
On Wed, May 21, 2014 at 02:24:27PM -0700, Junio C Hamano wrote:
> Junio C Hamano writes:
>
...
>
> It seems you sent v7 before I had a chance to comment on this one.
> The above was merely "it would be nicer..." and I am OK as-is. The
> comments on the rest are a bit more serious, though.
>
>
On 2014-05-20 20:24, Junio C Hamano wrote:
> Fixes since v1.9 series
> ---
>
> Unless otherwise noted, all the fixes since v1.9 in the maintenance
> track are contained in this release (see the maintenance releases'
> notes for details).
[...]
>
> * The shell prompt script (in
Junio C Hamano writes:
> Jeremiah Mahler writes:
>
>> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
>> index 9c80633..049493d 100755
>> --- a/t/t4014-format-patch.sh
>> +++ b/t/t4014-format-patch.sh
>> @@ -762,6 +762,38 @@ test_expect_success 'format-patch --signature=""
>> sup
Jeremiah Mahler writes:
> From: Jeff King
>
> When we print an email signature, we print the divider "--
> \n", then the signature string, then two newlines.
> Traditionally the signature is a one-liner (and the default
> is just the git version), so the extra newline makes sense.
>
> But one co
On Wed, May 21, 2014 at 04:47:39PM -0400, Jeff King wrote:
> On Wed, May 21, 2014 at 11:26:18AM -0700, Junio C Hamano wrote:
>
...
> I think the ratio of usefulness to number of words in this sub-thread is
> getting off. I'd be OK with any of:
...
>
> -Peff
I think this has become a discussion a
Jeremiah Mahler writes:
> diff --git a/t/t4014-format-patch.sh b/t/t4014-format-patch.sh
> index 9c80633..049493d 100755
> --- a/t/t4014-format-patch.sh
> +++ b/t/t4014-format-patch.sh
> @@ -762,6 +762,38 @@ test_expect_success 'format-patch --signature=""
> suppresses signatures' '
> ! gr
From: Jeff King
When we print an email signature, we print the divider "--
\n", then the signature string, then two newlines.
Traditionally the signature is a one-liner (and the default
is just the git version), so the extra newline makes sense.
But one could easily specify a longer, multi-line
Added option that allows a signature file to be used with format-patch
so that signatures with newlines and other special characters can be
easily included.
$ git format-patch --signature-file ~/.signature -1
The config variable format.signaturefile is also provided so that it
can be added by d
v7 of patch to add format-patch --signature-file option.
This revision includes a patch from Jeff King to fix the odd number
spaces produced by print_signature().
Jeff King (1):
format-patch: make newline after signature conditional
Jeremiah Mahler (1):
format-patch --signature-file
Docu
On Wed, May 21, 2014 at 08:34:47PM +0200, Karsten Blees wrote:
> Macros are mainly used to supply __FILE__ and __LINE__, so that lazy
> people don't need to think of a unique message for each use of
> trace_performance_*. Without __FILE__, __LINE__ and message, the
> output would be pretty useless
On Wed, May 21, 2014 at 11:26:18AM -0700, Junio C Hamano wrote:
> Yeah, I agree with the last sentence. My mention of "cleansing"
> took into account your "do we want to omit the leading blank as
> well?" as well. In any case, wouldn't reusing stripspace() make the
> fix-up shorter?
Not really.
"Jason St. John" writes:
>> int main(int argc, char **argv)
>> {
>> - char *sha1_dir = getenv(DB_ENVIRONMENT), *path;
>> + char *sha1_dir, *path;
>> int len, i;
>> -
>> +
>> if (mkdir(".git", 0755) < 0) {
>>
>>
>
>
"Jason St. John" writes:
> diff --git a/Documentation/user-manual.txt b/Documentation/user-manual.txt
> index 022e74e..01200ed 100644
> --- a/Documentation/user-manual.txt
> +++ b/Documentation/user-manual.txt
> @@ -173,13 +173,13 @@ index 65898fa..b002dc6 100644
> --- a/init-db.c
> +++ b/init-
On Wed, May 21, 2014 at 2:52 PM, Jason St. John wrote:
>
> Signed-off-by: Jason St. John
> ---
> Junio pointed out in the link below that there are a number of instances of
> e.g.
> "command line option" (without a hyphen) in the documentation. This patch
> fixes
> all of them that I was able t
Signed-off-by: Jason St. John
---
Junio pointed out in the link below that there are a number of instances of e.g.
"command line option" (without a hyphen) in the documentation. This patch fixes
all of them that I was able to find. The other minor grammatical improvements
were
noticed while worki
On Tue, May 20, 2014 at 1:37 PM, Ronnie Sahlberg wrote:
> On Tue, May 20, 2014 at 12:42 PM, Jonathan Nieder wrote:
>> Ronnie Sahlberg wrote:
>>
>>> Wrap all the ref updates inside a transaction to make the update atomic.
>>
>> Interesting.
>>
>> [...]
>>> --- a/builtin/receive-pack.c
>>> +++ b/bu
Am 21.05.2014 18:58, schrieb Jeff King:
> On Tue, May 20, 2014 at 09:11:19PM +0200, Karsten Blees wrote:
>
>> Add trace_performance and trace_performance_since macros that print file
>> name, line number, time and an optional printf-formatted text to the file
>> specified in environment variable G
"Michael S. Tsirkin" writes:
> On Wed, May 21, 2014 at 09:54:47AM -0700, Junio C Hamano wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > On Tue, May 20, 2014 at 08:13:27AM -0700, Junio C Hamano wrote:
>> >> "Michael S. Tsirkin" writes:
>> >>
>> >> > Just to clarify I can post v2 of 4/4 without
Jeff King writes:
> On Wed, May 21, 2014 at 10:37:05AM -0700, Junio C Hamano wrote:
>
>> > I wasn't planning on anything as drastic as stripspace. I really just
>> > wanted to suppress the one newline, which is almost certainly the right
>> > thing to include for "--signature", but the wrong thin
Ramsay Jones writes:
> On 21/05/14 14:20, Alexey Shumkin wrote:
>> Pretty format string %<(N,[ml]trunc)>%s truncates subject to a given
>> length with an appropriate padding. This works for non-ASCII texts when
>> i18n.logOutputEncoding is UTF-8 only (independently of a printed commit
>> message
On Wed, May 21, 2014 at 10:37:05AM -0700, Junio C Hamano wrote:
> > I wasn't planning on anything as drastic as stripspace. I really just
> > wanted to suppress the one newline, which is almost certainly the right
> > thing to include for "--signature", but the wrong thing for
> > "--signature-fil
On Wed, May 21, 2014 at 09:54:47AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > On Tue, May 20, 2014 at 08:13:27AM -0700, Junio C Hamano wrote:
> >> "Michael S. Tsirkin" writes:
> >>
> >> > Just to clarify I can post v2 of 4/4 without reposting 1-3 since they
> >> > are que
Jeff King writes:
> On Tue, May 20, 2014 at 09:11:24PM +0200, Karsten Blees wrote:
>
>> Add performance tracing to identify which git commands are called and how
>> long they execute. This is particularly useful to debug performance issues
>> of scripted commands.
>>
>> Usage example: > GIT_TRAC
Jeff King writes:
> On Tue, May 20, 2014 at 11:46:51AM -0700, Junio C Hamano wrote:
>
>> Jeff King writes:
>>
>> > If it were just "--signature", I'd agree. After all, nobody is even
>> > complaining. But this is also in preparation for --signature-file.
>> > Should the user create a file witho
On Tue, May 20, 2014 at 5:46 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> This changes the locking slightly for walker_fetch. Previously the code would
>> lock all refs before writing them but now we do not lock the refs until the
>> commit stage. There is thus a very short window wher
Felipe Contreras writes:
> Junio C Hamano wrote:
>
>> * The remote-helper interface to fast-import/fast-export via the
>>transport-helper has been tightened to avoid leaving the import
>>marks file from a failed/crashed run, as such a file that is out-of-
>>sync with reality confuses
Martin Erik Werner writes:
>> * Commands that take pathspecs on the command line misbehaved when
>>the pathspec is given as an absolute pathname (which is a
>>practice not particularly encouraged) that points at a symbolic
>>link in the working tree.
>>(merge later 655ee9e mw/sym
On Wed, May 21, 2014 at 09:55:43AM -0700, Jeremiah Mahler wrote:
> I am fine with including your previous patch.
I think that would be my preference, but we'll see what Junio says.
> Would like me to test it out and create another patch set?
Yeah, that would be the logical next step. I think th
On Tue, May 20, 2014 at 09:11:19PM +0200, Karsten Blees wrote:
> Add trace_performance and trace_performance_since macros that print file
> name, line number, time and an optional printf-formatted text to the file
> specified in environment variable GIT_TRACE_PERFORMANCE.
>
> Unless enabled via G
On Tue, May 20, 2014 at 09:11:24PM +0200, Karsten Blees wrote:
> Add performance tracing to identify which git commands are called and how
> long they execute. This is particularly useful to debug performance issues
> of scripted commands.
>
> Usage example: > GIT_TRACE_PERFORMANCE=~/git-trace.lo
On Wed, May 21, 2014 at 12:42:55PM -0400, Jeff King wrote:
> On Tue, May 20, 2014 at 11:46:51AM -0700, Junio C Hamano wrote:
>
> > Jeff King writes:
> >
> > > If it were just "--signature", I'd agree. After all, nobody is even
> > > complaining. But this is also in preparation for --signature-fi
"Michael S. Tsirkin" writes:
> On Tue, May 20, 2014 at 08:13:27AM -0700, Junio C Hamano wrote:
>> "Michael S. Tsirkin" writes:
>>
>> > Just to clarify I can post v2 of 4/4 without reposting 1-3 since they
>> > are queued?
>>
>> If you need to update anything queued only on 'pu' but not yet in
On Wed, May 21, 2014 at 02:35:46PM +0400, Sergei Organov wrote:
> Was writing conversion script from CVS to git for my repo and noticed
> slight inconsistency in git-tag, git-branch, and git-update-ref behavior:
>
> $ git --version
> git version 1.9.3
> $ git tag -d && echo success
> success
Thi
On Tue, May 20, 2014 at 11:46:51AM -0700, Junio C Hamano wrote:
> Jeff King writes:
>
> > If it were just "--signature", I'd agree. After all, nobody is even
> > complaining. But this is also in preparation for --signature-file.
> > Should the user create a file without a trailing newline?
>
>
Hi,
I have a client that still uses svn, but I decided to version my work
on the project with git locally - using git svn to sync the svn and my
local git repo.
To have a backup , I additionally push my changes to a remote git repository.
Now, many(maybe every) times when doing the git push to t
On 21/05/14 14:20, Alexey Shumkin wrote:
> Pretty format string %<(N,[ml]trunc)>%s truncates subject to a given
> length with an appropriate padding. This works for non-ASCII texts when
> i18n.logOutputEncoding is UTF-8 only (independently of a printed commit
> message encoding) but does not work w
Thanks!
On Tue, May 20, 2014 at 5:51 PM, Jonathan Nieder wrote:
> Ronnie Sahlberg wrote:
>
>> No external users call write_ref_sha1 any more so lets declare it static.
>
> Yay!
>
> [...]
>> +++ b/refs.c
>> @@ -251,6 +251,8 @@ struct ref_entry {
> [...]
>> static void read_loose_refs(const char *
The interaction with unary operators and operator precedence
for && and || are better known than -a and -o, and for that
reason we prefer them. Replace all existing instances
of -a and -o to save readers from the burden of thinking
about such things.
---
This is version 2 of the patch to git-submod
Pretty format string %<(N,[ml]trunc)>%s truncates subject to a given
length with an appropriate padding. This works for non-ASCII texts when
i18n.logOutputEncoding is UTF-8 only (independently of a printed commit
message encoding) but does not work when i18n.logOutputEncoding is NOT
UTF-8.
In 7e77
The tested encoding is always available in a variable. Use it instead of
hardcoding. Also, to be in line with other tests use ISO8859-1
(uppercase) rather then iso8859-1.
Signed-off-by: Alexey Shumkin
---
t/t4041-diff-submodule-option.sh | 7 +--
t/t4205-log-pretty-formats.sh| 11 ++
Use `tformat` to avoid using of `echo` to complete end of line.
Signed-off-by: Alexey Shumkin
---
t/t4205-log-pretty-formats.sh | 52 +++
1 file changed, 13 insertions(+), 39 deletions(-)
diff --git a/t/t4205-log-pretty-formats.sh b/t/t4205-log-pretty-for
Pretty format string %<(N,[ml]trunc)>%s truncates subject to a given
length with an appropriate padding. This works for non-ASCII texts when
i18n.logOutputEncoding is UTF-8 only (independently of a printed commit
message encoding) but does not work when i18n.logOutputEncoding is NOT
UTF-8.
There w
This version (v4) differs from the previuos (v3):
1. Fixed typo ISO8895-1 (vs ISO8859-1)
2. Fixed t4205 test: tested format strings are double-quoted
Alexey Shumkin (5):
t4205 (log-pretty-formats): don't hardcode SHA-1 in expected outputs
t4041, t4205, t6006, t7102: Don't hardcode tested encod
The expected SHA-1 digests are always available in variables. Use
them instead of hardcoding.
That was introduced in a742f2a (t4205 (log-pretty-formats): don't
hardcode SHA-1 in expected outputs, 2013-06-26) but unfortunately was
not followed in 5e1361c (log: properly handle decorations with chain
This patch is redundant then.
It will be squashed into next patch series.
On Tue, May 20, 2014 at 06:48:43PM +0400, Alexey Shumkin wrote:
> Added in 0a144b3 (t4205, t6006: add failing tests for the case when
> i18n.logOutputEncoding is set, 2014-05-19) tests give no error
> (somehow) with Bash as
On Tue, May 20, 2014 at 08:13:27AM -0700, Junio C Hamano wrote:
> "Michael S. Tsirkin" writes:
>
> > Just to clarify I can post v2 of 4/4 without reposting 1-3 since they
> > are queued?
>
> If you need to update anything queued only on 'pu' but not yet in
> 'next', it is customary to resend the
Hello,
Was writing conversion script from CVS to git for my repo and noticed
slight inconsistency in git-tag, git-branch, and git-update-ref behavior:
$ git --version
git version 1.9.3
$ git tag -d && echo success
success
$ git branch -d && echo success
fatal: branch name required
$ git update-re
As of the last commit, we now recognize an error message
with a content-type "text/plain; charset=utf-16" as text,
but we ignore the charset parameter entirely. Let's encode
it to log_output_encoding, which is presumably something the
user's terminal can handle.
Signed-off-by: Jeff King
---
remo
This is a convenience wrapper around `reencode_string_len`
and `strbuf_attach`.
Signed-off-by: Jeff King
---
Documentation/technical/api-strbuf.txt | 5 +
strbuf.c | 17 +
strbuf.h | 1 +
3 files changed, 23 insert
Commit 426e70d (remote-curl: show server content on http
errors, 2013-04-05) tried to recognize text/plain content
types, but fails to do so if they have any parameters.
This patches makes our parsing more liberal, though we still
do not do anything useful with a charset parameter.
Signed-off-by:
Arup Rakshit writes:
[...]
> Now you can see, that I have created, a new file called *file.txt*, in the
> *master branch*.
And here is your basic misunderstanding. You've created file.txt indeed,
but not in the *master branch* (or any branch). You've created it in the
working directory. Only
Since commit 426e70d (remote-curl: show server content on
http errors, 2013-04-05), we relay any text/plain error
messages from the remote server to the user. However, we
never tested it.
Signed-off-by: Jeff King
---
t/lib-httpd.sh | 1 +
t/lib-httpd/apache.conf| 4
t/lib-
Using write_script will set our shebang line appropriately
with $SHELL_PATH. The script that is there now is quite
simple and likely to succeed even with a non-POSIX /bin/sh,
but it does not hurt to be defensive.
Signed-off-by: Jeff King
---
t/lib-httpd.sh | 6 +-
t/lib-htt
The content-type string curl hands us comes straight from
the server, and may have odd capitalization. RFC 2616 states
that content-types are case-insensitive. We already handle
this when checking for text/plain (by using strcasecmp), but
do not when checking for a smart-http content-type.
We coul
We have two implementations of the same function; let's drop
that to one. We take the name from daemon.c, but the
implementation (which is just slightly more efficient) from
the config code.
Signed-off-by: Jeff King
---
Unlike the last patch, this one does _not_ get used elsewhere in this
series.
This makes config's lowercase() function public.
Note that we could continue to offer a pure-string
lowercase, but there would be no callers (in most
pure-string cases, we actually duplicate and lowercase the
duplicate).
Signed-off-by: Jeff King
---
This ones gets used later on...
Documentatio
Turning on this variable can be useful when debugging http
tests. It does break a few tests in t5541, but it is not
a variable that the user is likely to have enabled
accidentally.
Signed-off-by: Jeff King
---
Not necessary for this series, but I found it helpful.
I took a look at making the tes
As of commit 426e70d (remote-curl: show server content on http errors,
2013-04-05), we relay any text/plain errors shown by the remote http
server to the user. However, we were lazy back then and left this TODO
in place:
/*
* We only show text/plain parts, as other types are likely
On Tue, May 20, 2014 at 05:24:50PM -0700, Junio C Hamano wrote:
(...)
> * "git reset" learned the "-N" option, which does not reset the index
>fully for paths the index knows about but the tree-ish the command
>resets to does not (these paths are kept as intend-to-add entries).
I find it
As-salam Sir,
Regarding to possible investment, I wish to bring to your notice my interest to
partner with you on any great business investment opportunity.
Please kindly furnish me with any business details and a proposal for a Joint
venture partnership with you. Looking forward to going i
1 - 100 of 102 matches
Mail list logo
