Junio C Hamano writes:
> Subject: [PATCH] apply: refuse touching a file beyond symlink
>
> Because Git tracks symbolic links as symbolic links, a path that has
> a symbolic link in its leading part (e.g. path/to/dir being a
> symbolic link to somewhere else, be it inside or outside the working
>
Jeff King writes:
> This is not the first time I've seen this chomp/trim distinction come
> up. However, the thing that has prevented me from writing strbuf_chomp
> is that the trim is almost always a more reasonable choice.
> ...
> End mini-rant. :)
Thanks.
--
To unsubscribe from this list: sen
Mike Hommey writes:
> On Wed, Jan 28, 2015 at 01:17:19PM -0800, Junio C Hamano wrote:
>> diff --git a/Documentation/diff-format.txt b/Documentation/diff-format.txt
>> index 15c7e79..e6cfc9b 100644
>> --- a/Documentation/diff-format.txt
>> +++ b/Documentation/diff-format.txt
>> @@ -66,7 +66,8 @@ b
Thanks; queued. Let's run with this and try to make it graduate
early next cycle.
--
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
Olaf Hering writes:
> On Tue, Jan 27, Junio C Hamano wrote:
>
>> > What file timestamp should be used for them? Likely "../version"?
>>
>> I tend to think the "Last updated" timestamp taken from the
>> filesystem timestamp is a bad practice inherited by these tools from
>> the days back when nob
Junio C Hamano writes:
> Junio C Hamano writes:
>
>> If the user wants to apply a patch that touches ../etc/shadow, is
>> the tool in the place to complain?"
>
> Let me take this part back.
>
> I think "git apply" should behave closely to "git apply --index"
> (which is used by "git am" unless t
On Mon, Jan 26, 2015 at 7:22 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> I can redo the atomic-push-fix series with this cleanup merged
>> into the appropriate patches or you could just queue it on top
>> of said series.
>
> Yeah, I do not think we are expecting to fast tra
On Wed, Jan 28, 2015 at 12:42:26PM -0800, Junio C Hamano wrote:
> > This is the most minimal fix, but I kind of wonder if it should just be
> > using strbuf_rtrim (or even strbuf_trim) in the first place.
>
> Yeah. Or strbuf_chomp(), which does not exist ;-)
This is not the first time I've seen
On Tue, Jan 27, 2015 at 06:35:41PM +0100, Jens Lehmann wrote:
> > One way to do so might be to move the bits it stores in the config
> > file to somewhere else that is more closely tied to the checkout
> > state and handle that similar to .git/index and .git/HEAD when it
> > comes to multiple work-
On Wed, Jan 28, 2015 at 5:50 PM, Duy Nguyen wrote:
> For git-new-workdir.sh, perhaps we can teach include.path to make
> config.local path relative to where the config symlink is, not where
> the symlink target is.
Ignore this part. I originally wanted to use include.path to load
config.local, bu
On 27.01.15 23:20, Junio C Hamano wrote:
> How about extending it like this (not tested)?
Thanks, this looks good: the test is more extensive,
I can test this next week.
>
> -- >8 --
> From: Torsten Bögershausen
> Date: Tue, 27 Jan 2015 16:39:01 +0100
> Subject: [PATCH] test-lib.sh: set prerequ
On Tue, Jan 27, Junio C Hamano wrote:
> Olaf Hering writes:
>
> > Several files in Documentation have an unstable 'Last updated' timestamp.
> > The
> > reason is that their mtime changes every time, which prevents reproducible
> > builds.
> >
> > 341 technical/api-index.txt: technical/api-index
From: Yi EungJun
Change since v8
Apply Junio's patch: Use an array of char* instead of strbuf for language_tags.
Yi EungJun (1):
http: Add Accept-Language header if possible
http.c | 147 +
remote-curl.c | 2 +
t
I agree that a list of char* is enough for language_tags.
Thanks for your review and patch. I'll apply your patch and send v9.
On Wed, Jan 28, 2015 at 3:15 PM, Junio C Hamano wrote:
> On Tue, Jan 27, 2015 at 3:34 PM, Junio C Hamano wrote:
>> Yi EungJun writes:
>>
>>> +
>>> + sprint
On Wed, Jan 28, 2015 at 11:44 AM, Michael Blume wrote:
> Test 3 is failing on my mac:
>
> expecting success:
> test_config color.ls.file red &&
> test_config color.ls.directory green &&
> test_config color.ls.submodule yellow &&
> git list-files --color=always >actual &&
> test_cmp "$TEST_DIRECTOR
On Wed, Jan 28, 2015 at 01:17:19PM -0800, Junio C Hamano wrote:
> Michael J Gruber writes:
>
> > I'd say it depends on the definition of "so". The documentation is
> > correct if you read "so" as "*always* followed by a score". I guess you
> > read it as "followed by a score".
>
> I read it so a
We may want to say something about command line option names in the
new section as well, but for now, let's make sure everybody is clear
on how to structure and name their configuration variables.
The text for the rules are partly taken from the log message of
Jonathan's 6b3020a2 (add: introduce a
The old text gave an impression that even in a new repository using
old form might be safer. Only Git from pre 1.7.0 days choke on the
correctly named variable, which is ancient by today's standard.
We have no intention to remove the support for deprecated ones, but
let's make sure that we do not
Signed-off-by: Junio C Hamano
---
Documentation/config.txt | 8
1 file changed, 4 insertions(+), 4 deletions(-)
diff --git a/Documentation/config.txt b/Documentation/config.txt
index 69f30d6..8a76d1d 100644
--- a/Documentation/config.txt
+++ b/Documentation/config.txt
@@ -665,7 +665,7 @
So here is a rewrite of the same but split into three patches,
after seeing "add.ignore-errors" not marked exactly as deprecated.
The update to CodingGuidelines goes a bit beyond how to name things
(i.e. bumpyCase vs dashed-words, the latter of which is strongly
discouraged) but how the names shou
Michael J Gruber writes:
> I'd say it depends on the definition of "so". The documentation is
> correct if you read "so" as "*always* followed by a score". I guess you
> read it as "followed by a score".
I read it so as well ;-)
> Percentages with M are not mentioned in diff-format, but they ar
From: Yi EungJun
Add an Accept-Language header which indicates the user's preferred
languages defined by $LANGUAGE, $LC_ALL, $LC_MESSAGES and $LANG.
Examples:
LANGUAGE= -> ""
LANGUAGE=ko:en -> "Accept-Language: ko, en;q=0.9, *;q=0.1"
LANGUAGE=ko LANG=en_US.UTF-8 -> "Accept-Language: ko, *;
Hi all,
I've encountered a problem with the Dictator and Lieutenants Workflow. I've
configured remote origin so it pulls from the "blessed repository" and
pushes to the "developer public" repository.
When the "blessed repository" has the same branch name as the "developer
public" repository gi
Michael Blume writes:
> Test 3 is failing on my mac:
>
> expecting success:
> test_config color.ls.file red &&
> test_config color.ls.directory green &&
> test_config color.ls.submodule yellow &&
> git list-files --color=always >actual &&
> test_cmp "$TEST_DIRECTORY"/t3080/color_ls actual
>
> ---
There is no point in checking "!ref->name" when ref is a
"struct ref". The name field is a flex-array, and there
always has a non-zero address. This is almost certainly not
hurting anything, but it does cause clang-3.6 to complain.
Signed-off-by: Jeff King
---
Note that even if "ref" is NULL, thi
Luke Diamand writes:
> My previous change for adding support for "exclude" to git-p4 "sync"
> was incorrect, missing out a comma, which stopped git-p4 from working.
> This change fixes that.
>
> I've also noticed that t9814-git-p4-rename.sh has stopped working; I'm
> going to follow up with a fix
Eric Sunshine writes:
> On Wed, Jan 28, 2015 at 3:12 PM, Junio C Hamano wrote:
>> Eric Sunshine writes:
>>
+ This option is equivalent to the argument; the latter
+ wins if both are specified.
>>>
>>> To what does "latter" refer in this case? (I presume it means the
>>> s
Torsten Bögershausen writes:
>> OK, but MacOS X does not have SANITY problem; "is the / writable?" test
>> was misdetecting and declaring a system with SANITY does not have one.
>>
>> Perhaps roll Cygwin and Mingw into a single Windows category? I dunno.
> The whole discussion actually started wi
When we are chomping newlines from the end of a strbuf, we
must check "sb.len != 0" before accessing "sb.buf[sb.len - 1]".
However, this code mistakenly checks "&sb.len", which is
always true (it is a part of an auto struct, so the address
is always non-zero). This could lead to us accessing memory
Jeff King writes:
> When we are chomping newlines from the end of a strbuf, we
> must check "sb.len != 0" before accessing "sb.buf[sb.len - 1]".
> However, this code mistakenly checks "&sb.len", which is
> always true (it is a part of an auto struct, so the address
> is always non-zero). This cou
I was fooling around with clang-3.6 today (as opposed to 3.5, which is
the stock "clang" shipped with Debian), and noticed two new warnings.
The first one is a real bug, and the second is just a cleanup (though I
agree with clang on it).
[1/2]: read_and_strip_branch: fix typo'd address-of operat
On Wed, Jan 28, 2015 at 12:28 AM, Torsten Bögershausen wrote:
> On 27.01.15 23:20, Junio C Hamano wrote:
>
>> How about extending it like this (not tested)?
> Thanks, this looks good: the test is more extensive,
> I can test this next week.
>
>>
>> -- >8 --
>> From: Torsten Bögershausen
>> Date:
Mike Hommey schrieb am 28.01.2015 um 07:23:
> Hi,
>
> diff-format.txt says this:
>
> An output line is formatted this way:
> (snip)
>
> That is, from the left to the right:
>
> (snip)
> . status, followed by optional "score" number.
>
> (snip)
> Status letters C and R are always
On Wed, Jan 28, 2015 at 3:12 PM, Junio C Hamano wrote:
> Eric Sunshine writes:
>
>>> + This option is equivalent to the argument; the latter
>>> + wins if both are specified.
>>
>> To what does "latter" refer in this case? (I presume it means the
>> standalone argument, though the t
Hello Junio, Michael -- thanks much for clearing this up for me.
Appreciate your time.
If the --repo option works just like the argument to git
push, then I would suggest -- just as Junio has done -- that you
deprecate this option. Otherwise, it would confuse users.
There is also a minor typo
On 28.01.15 18:38, Junio C Hamano wrote:
> On Wed, Jan 28, 2015 at 12:28 AM, Torsten Bögershausen wrote:
>> On 27.01.15 23:20, Junio C Hamano wrote:
>>
>>> How about extending it like this (not tested)?
>> Thanks, this looks good: the test is more extensive,
>> I can test this next week.
>>
>>> -
On Wed, Jan 28, 2015 at 2:19 AM, Duy Nguyen wrote:
> On Wed, Jan 28, 2015 at 11:44 AM, Michael Blume wrote:
>> Test 3 is failing on my mac:
>>
>> expecting success:
>> test_config color.ls.file red &&
>> test_config color.ls.directory green &&
>> test_config color.ls.submodule yellow &&
>> git li
Mike Hommey writes:
> (snip)
> Status letters C and R are always followed by a score (denoting the
> percentage of similarity between the source and target of the move or
> copy), and are the only ones to be so.
Good eyes. I _think_ what happened was that break-and-then-merge
(aka compl
Duy Nguyen writes:
> On Wed, Jan 28, 2015 at 5:50 PM, Duy Nguyen wrote:
>> For git-new-workdir.sh, perhaps we can teach include.path to make
>> config.local path relative to where the config symlink is, not where
>> the symlink target is.
>
> Ignore this part. I originally wanted to use include.
Eric Sunshine writes:
>> + This option is equivalent to the argument; the latter
>> + wins if both are specified.
>
> To what does "latter" refer in this case? (I presume it means the
> standalone argument, though the text feels ambiguous.)
>
> Also, both the standalone argument and
40 matches
Mail list logo
