Thanks for your review Thomas!
V3 fixes a couple of problems Thomas noticed.
Ralf Thielow (3):
l10n: de.po: switch from pure German to German+English (part 1)
l10n: de.po: switch from pure German to German+English (part 2)
l10n: de.po: switch from pure German to German+English (part 3)
po
I question the value of this warning. Initialization with '=
{0}' is a well-established idiom, and sparse should know about
it.
Thanks everyone for your feedback. But I really wanted to call only the
warning in the case of the '= {0}' idiom into question, not about 0 vs.
NULL in gen
I did as Andrew suggested and created two git repositories with one branch
using oldCM history and the second branch using having the svn history.
Then I checked out the svn branch and rebased onto oldCM. The head of the
combined branch is named master.
How do I manually set git/git-svn u
The docs seem to say that doing
git show-ref --head --tags
would show both the HEAD ref and all the tag refs. However, doing
both --head and either of --tags or --heads would filter out the HEAD
ref.
Also update the documentation to describe the new behavior and add
tests for the show-re
Added the test that Junio wrote, just need to take some more time to
understand it. Thanks for the tests!
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
On 07/16/2013 05:41 PM, Ramsay Jones wrote:
Mark Levedahl wrote:
Cygwin's regex library does not pass git's tests, so don't use it. This
fixes failures in t4018 and t4034.
Hmm, these tests have always passed for me on cygwin. So, this is
presumably a regression in the new-lib regex library vers
On 07/16/2013 05:20 PM, Ramsay Jones wrote:
Mark Levedahl wrote:
The supported Cygwin distribution on supported Windows versions provides
complete support for POSIX filemodes, so enable this by default. git as
distributed by the Cygwin project is configured this way.
This fixes one testsuite fa
On 07/16/2013 05:36 PM, Ramsay Jones wrote:
Caveats:
1) I don't find any speed improvement of the current patch over the
previous one (the tests actually ran faster with the earlier patch,
though the difference was less than 1%).
2) I still question this whole approach, especially having this
non
On 07/16/2013 11:42 AM, Dmitry Potapov wrote:
On Tue, Jul 16, 2013 at 7:54 AM, Mark Levedahl wrote:
I see no difference in the above. (Yes, I checked multiple times that I was
using different executables).
Are you sure that you set core.filemode to false before testing?
yes.
--
To unsubscri
On 16/07/13 22:18, Stefan Beller wrote:
On 07/16/2013 10:53 PM, Philip Oakley wrote:
From: "Jeff King"
Sent: Tuesday, July 16, 2013 7:21 AM
On Tue, Jul 16, 2013 at 07:57:20AM +0200, Johannes Sixt wrote:
Am 7/15/2013 19:31, schrieb Ramsay Jones:
Sparse issues three "Using plain integer as NU
On Tue, Jul 09, 2013 at 12:53:27PM -0700, Junio C Hamano wrote:
> diff --git a/remote.c b/remote.c
> index 81bc876..e9b423a 100644
> --- a/remote.c
> +++ b/remote.c
> @@ -1938,3 +1938,62 @@ struct ref *get_stale_heads(struct refspec *refs, int
> ref_count, struct ref *fet
> string_list_clear
On 07/16/2013 05:41 PM, Ramsay Jones wrote:
Mark Levedahl wrote:
Cygwin's regex library does not pass git's tests, so don't use it. This
fixes failures in t4018 and t4034.
Hmm, these tests have always passed for me on cygwin. So, this is
presumably a regression in the new-lib regex library vers
Thomas Gummerer wrote:
> Hi,
>
> previous rounds (without api) are at $gmane/202752, $gmane/202923,
> $gmane/203088 and $gmane/203517, the previous round with api was at
> $gmane/229732. Thanks to Junio, Duy and Eric for their comments on
> the previous round.
If I remember correctly, the origin
Mark Levedahl wrote:
> Cygwin's regex library does not pass git's tests, so don't use it. This
> fixes failures in t4018 and t4034.
Hmm, these tests have always passed for me on cygwin. So, this is
presumably a regression in the new-lib regex library versions used
by cygwin 1.5 and cygwin 1.7.
AT
Mark Levedahl wrote:
> The supported Cygwin distribution on supported Windows versions provides
> complete support for POSIX filemodes, so enable this by default. git as
> distributed by the Cygwin project is configured this way.
>
> This fixes one testsuite failure:
> t3300 test 17 (diff-index -M
Mark Levedahl wrote:
> On 07/10/2013 04:23 PM, Ramsay Jones wrote:
>> Commit adbc0b6b ("cygwin: Use native Win32 API for stat", 30-09-2008)
>> added a Win32 specific implementation of the stat functions. In order
>> to handle absolute paths, cygwin mount points and symbolic links, this
>> implement
On 07/16/2013 10:53 PM, Philip Oakley wrote:
> From: "Jeff King"
> Sent: Tuesday, July 16, 2013 7:21 AM
>> On Tue, Jul 16, 2013 at 07:57:20AM +0200, Johannes Sixt wrote:
>>
>>> Am 7/15/2013 19:31, schrieb Ramsay Jones:
>>> > Sparse issues three "Using plain integer as NULL pointer" warnings.
>>> >
Subtests 6, 7, and 9 rely test that merge-recursive correctly
ignores whitespace when so directed. These tests create and test for
lines ending in \r\n, but as this is a valid line separator on Windows,
convert such lines in the output to avoid confusion by line-oriented
grep.
Signed-off-by: Mark
From: "Jeff King"
Sent: Tuesday, July 16, 2013 7:21 AM
On Tue, Jul 16, 2013 at 07:57:20AM +0200, Johannes Sixt wrote:
Am 7/15/2013 19:31, schrieb Ramsay Jones:
> Sparse issues three "Using plain integer as NULL pointer" warnings.
> Each warning relates to the use of an '{0}' initialiser expres
Subtests 6, 7, and 9 rely test that merge-recursive correctly
ignores whitespace when so directed. These tests create and test for
lines ending in \r\n, but as this is a valid line separator on Windows,
convert such lines in the output to avoid confusion by line-oriented
grep.
Signed-off-by: Mark
Jonathan Nieder writes:
> Thomas Rast wrote:
>
>> The existing description reads as if it somehow applies a filter.
>> Change it to explain that it is merely about the ordering.
> [...]
>> OPT_SET_INT(0, "date-order", &sort_order,
>> -N_("show commits where no
Jens Lehmann writes:
> Am 16.07.2013 20:07, schrieb Jonathan Nieder:
>> Thomas Rast wrote:
>>
>>> There are only four (with some generous rounding) instances in the
>>> current source code where we speak of "subproject" instead of
>>> "submodule". They are as follows:
>> [...]
>>> Let's at leas
On 07/16/2013 02:59 PM, Jonathan Nieder wrote:
Mark Levedahl wrote:
Subtests 6, 7, and 9 rely test that merge-recursive correctly
ignores whitespace when so directed. Change the particular whitespace
sequences to be ones that are not known line endings so the whitespace
is not changed when bein
Am 16.07.2013 20:07, schrieb Jonathan Nieder:
> Thomas Rast wrote:
>
>> There are only four (with some generous rounding) instances in the
>> current source code where we speak of "subproject" instead of
>> "submodule". They are as follows:
> [...]
>> Let's at least change the error messages to c
Mark Levedahl wrote:
> Subtests 6, 7, and 9 rely test that merge-recursive correctly
> ignores whitespace when so directed. Change the particular whitespace
> sequences to be ones that are not known line endings so the whitespace
> is not changed when being extracted by line oriented grep.
merge-
Mark Levedahl wrote:
> Subtests 6,7, and 9 of t3032 fail on Cygwin, and I presume will fail
> on msysgit for similar reasons. Looking at test 6, the expected
> result is a line ending with \r\n in text.txt. This line is
> extracted with grep (grep 'justice and holiness' text.txt > actual),
> with
Subtests 6, 7, and 9 rely test that merge-recursive correctly
ignores whitespace when so directed. Change the particular whitespace
sequences to be ones that are not known line endings so the whitespace
is not changed when being extracted by line oriented grep.
Signed-off-by: Mark Levedahl
---
t
Those text files are installed as documentation (at least on my distribution).
That's probably a distribution bug (or a git makefile bug, depending
on how you look at it). It would be better to ship the HTML
documentation, converted to text, instead of keeping the version with
markup includin
On Tue, Jul 16, 2013 at 11:26:27AM -0700, Jonathan Nieder wrote:
> Dirk Wallenstein wrote:
>
> > Those text files are installed as documentation (at least on my
> > distribution).
>
> That's probably a distribution bug (or a git makefile bug, depending
> on how you look at it). It would be bett
Subtests 6,7, and 9 of t3032 fail on Cygwin, and I presume will fail on
msysgit for similar reasons. Looking at test 6, the expected result is a
line ending with \r\n in text.txt. This line is extracted with grep
(grep 'justice and holiness' text.txt > actual), with unavoidable result
that on C
Dirk Wallenstein wrote:
> Those text files are installed as documentation (at least on my distribution).
That's probably a distribution bug (or a git makefile bug, depending
on how you look at it). It would be better to ship the HTML
documentation, converted to text, instead of keeping the versi
Thomas Rast wrote:
> The existing description reads as if it somehow applies a filter.
> Change it to explain that it is merely about the ordering.
[...]
> OPT_SET_INT(0, "date-order", &sort_order,
> - N_("show commits where no parent comes before its "
> +
On 07/16/2013 07:46 PM, Jonathan Nieder wrote:
> Matthieu Moy wrote:
>
>> Matthieu Moy (6):
>> t4000-diff-format.sh: modernize style
>> diff: allow --no-patch as synonym for -s
>> diff: allow --patch & cie to override -s/--no-patch
>> Documentation/git-show.txt: include common diff options
Thomas Rast wrote:
> There are only four (with some generous rounding) instances in the
> current source code where we speak of "subproject" instead of
> "submodule". They are as follows:
[...]
> Let's at least change the error messages to consistently call them
> "submodule".
>
> Signed-off-by:
On Tue, Jul 16, 2013 at 10:13:28AM -0700, Junio C Hamano wrote:
> > Why would you want to limit those files to be source for HTML only?
> >
> > The HTML after this patch is still fine.
>
> Have you thought the reason why the formatted result _before_ the patch is
> good?
No, as I said, *.txt suff
Matthieu Moy wrote:
> Matthieu Moy (6):
> t4000-diff-format.sh: modernize style
> diff: allow --no-patch as synonym for -s
> diff: allow --patch & cie to override -s/--no-patch
> Documentation/git-show.txt: include common diff options, like
> git-log.txt
> Documentation: move descrip
> Why would you want to limit those files to be source for HTML only?
>
> The HTML after this patch is still fine.
Have you thought the reason why the formatted result _before_ the patch is good?
These *.txt files are asciidoc formatted source files. They are meant
to be easy to read and edit wit
On Tue, Jul 16, 2013 at 7:54 AM, Mark Levedahl wrote:
>
> I see no difference in the above. (Yes, I checked multiple times that I was
> using different executables).
Are you sure that you set core.filemode to false before testing?
If you have core.filemode set to true then you _always_ use Cygwi
When an invalid revision is specified, the error message is:
fatal: Needed a single revision
This is misleading because, you might think there is something wrong
with the command line as a whole.
Now the user gets a more meaningful error message, showing the invalid
revision.
Signed-off-by:
This feature was not tested in the test suite, hence we'd remove it for
now. It doesn't seem to be often used anyway.
A google search for "git diff -q" (match string exactly) only returned
http://stackoverflow.com/questions/11021287/git-detect-if-there-are-untracked-files-quickly
where "git diff -q
Before v1.5.6-rc1~41^2~2, the option parsing for diff --no-index
and "git diff-files" shared code. In "git diff-files", "-q" means
to be silent about removed files. In "git diff --no-index", in
various versions it has been an error, an infinite loop, or a no-op.
Simplify the code to clarify that
On 07/15/2013 12:07 AM, Jonathan Nieder wrote:
> This feature was obviously never tested with --no-index, so I agree it
> makes sense to remove it. Probably the commit message and a comment
> should say so, though. E.g.:
>
> diff --no-index: remove nonfunctional "-q" handling
>
> Befo
On Tue, Jul 16, 2013 at 5:53 AM, Kyle J. McKay wrote:
> On Jul 15, 2013, at 16:12, Eric Sunshine wrote:
>>
>> On Mon, Jul 15, 2013 at 5:51 AM, Kyle J. McKay wrote:
>>>
>>> +static int append_normalized_escapes(struct strbuf *buf,
>>> +const char *from,
>>> +
On Jul 15, 2013, at 16:12, Eric Sunshine wrote:
On Mon, Jul 15, 2013 at 5:51 AM, Kyle J. McKay
wrote:
+static int append_normalized_escapes(struct strbuf *buf,
+const char *from,
+size_t from_len,
+
Thomas Rast writes:
> From: "Dale R. Worley"
>
> open() returns -1 on failure, and indeed 0 is a possible success value
> if the user closed stdin in our process. Fix the test.
>
> Signed-off-by: Thomas Rast
I see you have this in 'pu' without Dale's signoff. I'm guessing
(IANAL) that it's t
Both daemon.c and shell.c contain logic to open FDs 0/1/2 from
/dev/null if they are not already open. Move the function in daemon.c
to setup.c and use it in shell.c, too.
While there, remove a 'not' that inverted the meaning of the comment.
The point is indeed to *avoid* messing up.
Signed-off-
Not having an open FD in the 0--2 range can lead to strange results,
for example, a subsequent open() may return 2 (stderr) and then a
die() would clobber this file.
git-daemon and git-shell already guarded against this, but apparently
users also manage to trip over it in other git commands. So w
Junio C Hamano writes:
> Thomas Rast writes:
>
>> I originally had a four-patch series to open 0/1/2 from /dev/null, but
>> then I noticed that this was shot down in 2008:
>>
>> http://thread.gmane.org/gmane.comp.version-control.git/93605/focus=93896
>
> The way I recall the thread was not "sh
Eric Sunshine writes:
> All surrounding examples are typeset as monospaced text. Follow suit.
>
> Signed-off-by: Eric Sunshine
> ---
> Documentation/git-log.txt | 2 +-
> 1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
> index
There are only four (with some generous rounding) instances in the
current source code where we speak of "subproject" instead of
"submodule". They are as follows:
* one error message in git-apply and two in entry.c
* the patch format for submodule changes
The latter was introduced in 0478675 (E
The existing description reads as if it somehow applies a filter.
Change it to explain that it is merely about the ordering.
Signed-off-by: Thomas Rast
---
builtin/show-branch.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/builtin/show-branch.c b/builtin/show-branch.c
inde
One real fix since v3: there was an incorrect file name in a test
(noticed by Jonathan). Now, all actual outputs are called "actual".
Other than that: extra tests, and style fixes in commit messages.
Matthieu Moy (6):
t4000-diff-format.sh: modernize style
diff: allow --no-patch as synonym for
Signed-off-by: Matthieu Moy
---
Documentation/git-show.txt | 9 +
1 file changed, 9 insertions(+)
diff --git a/Documentation/git-show.txt b/Documentation/git-show.txt
index ae4edcc..4e617e6 100644
--- a/Documentation/git-show.txt
+++ b/Documentation/git-show.txt
@@ -45,6 +45,15 @@ includ
Signed-off-by: Matthieu Moy
---
t/t4000-diff-format.sh | 18 +-
1 file changed, 9 insertions(+), 9 deletions(-)
diff --git a/t/t4000-diff-format.sh b/t/t4000-diff-format.sh
index 6ddd469..2b5dffc 100755
--- a/t/t4000-diff-format.sh
+++ b/t/t4000-diff-format.sh
@@ -15,17 +15,17 @@
All options that trigger a patch output now override --no-patch.
The case of --binary deserves extra attention: the name may suggest that
it turns a normal patch into a binary patch, but it actually already
enables patch output when normally disabled (e.g. "git log --binary"
displays a patch), hen
Technically, "-s, --no-patch" is implemented in diff.c ("git diff
--no-patch" is essentially useless, but valid). From the user point of
view, this allows the documentation to show up in "git show --help",
which is one of the most useful use of the option.
While we're there, add a sentence explain
On Mon, Jul 15, 2013 at 03:00:17PM -0700, Junio C Hamano wrote:
> Dirk Wallenstein writes:
>
> > Keep the sketch aligned independent of the tabstop width used.
>
> Thanks.
>
> This is a source text to be formatted into HTML, isn't it?
>
> In our sources, a HT indents to multiple of 8 columns.
This is the convention in most other files and even at the beginning of
git-log.txt
Signed-off-by: Matthieu Moy
---
Documentation/git-log.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/git-log.txt b/Documentation/git-log.txt
index 2ea79ba..2eda5e4 1
This follows the usual convention of having a --no-foo option to negate
--foo.
Signed-off-by: Matthieu Moy
---
Documentation/rev-list-options.txt | 1 +
diff.c | 2 +-
t/t4000-diff-format.sh | 12
3 files changed, 14 insertions(+), 1 deletio
59 matches
Mail list logo
