Johannes Schindelin writes:
>> > expecting success:
>> > actual=$(git submodule--helper resolve-relative-url-test
>> > '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' '../.') &&
>> > test "$actual" = 'C:/git-sdk-64/usr/src/git/wip/t/trash
>> > di
Hi Peff,
On Sun, 16 Oct 2016, Jeff King wrote:
> On Sun, Oct 16, 2016 at 10:09:12AM +0200, Johannes Schindelin wrote:
>
> > > Good catch. It technically needs to check the lower bound, too. In
> > > theory, if somebody wanted to add an enum value that is negative, you'd
> > > use a signed cast a
Hi Lars,
On Sun, 16 Oct 2016, Lars Schneider wrote:
> One idea could be to add an attribute "case-sensitive" (or
> "caseSensitive") and set it to false (if desired) for all files in
> .gitattributes for a given repo.
>
> ### .gitattributes example ###
>
> * case-sensitive=false
> *.bar somethin
Hi Stefan,
On Sun, 16 Oct 2016, Stefan Beller wrote:
> Conceptually I would prefer if we had a single switch that indicates a
> case insensitive FS.
AFAIU Lars' use case is where the FS is *case sensitive*, but he still
needs the .gitattributes to be *case insensitive* because that file
originat
Hi Ramsay & Peff,
On Sun, 16 Oct 2016, Jeff King wrote:
> On Mon, Oct 17, 2016 at 02:37:58AM +0100, Ramsay Jones wrote:
>
> > Hmm, well, you have to remember that 'make clean' sometimes doesn't
> > make clean. Ever since the Makefile was changed to only remove
> > $(OBJECTS), rather than *.o xdi
On Mon, Oct 17, 2016 at 3:57 PM, Johannes Schindelin
wrote:
> Hi Stefan,
>
> On Sun, 16 Oct 2016, Stefan Beller wrote:
>
>> Conceptually I would prefer if we had a single switch that indicates a
>> case insensitive FS.
>
> AFAIU Lars' use case is where the FS is *case sensitive*, but he still
> ne
On Fri, Oct 14, 2016 at 09:48:16AM -0700, Junio C Hamano wrote:
> Kevin Daudt writes:
>
> > On Thu, Oct 13, 2016 at 06:10:17PM +0200, Heiko Voigt wrote:
> >> On Fri, Oct 07, 2016 at 06:17:05PM +, David Turner wrote:
> >> > Presently, uninitialized submodules are materialized in the working
>
[tl;dr: the version in your repo is fine, and there's a trivial fix
below if we want to silence the warning in the meantime]
On Mon, Oct 17, 2016 at 10:37:52AM +0200, Johannes Schindelin wrote:
> > I'm not sure I agree. IIRC, Assigning values outside the range of an enum
> > has
> > always been
On Mon, Oct 17, 2016 at 11:04:19AM +0200, Johannes Schindelin wrote:
> > Gross. I would not be opposed to a Makefile rule that outputs the
> > correct set of OBJECTS so this (or other) scripts could build on it.
>
> You could also use the method I use in Git for Windows to "extend" the
> Makefile
On Sat, Oct 8, 2016 at 2:59 AM, David Turner wrote:
>
>
>> -Original Message-
>> From: Stefan Beller [mailto:sbel...@google.com]
>> Sent: Friday, October 07, 2016 2:56 PM
>> To: David Turner
>> Cc: git@vger.kernel.org
>> Subject: Re: Uninitialized submodules as symlinks
>>
>> On Fri, Oct 7
On Sun, Oct 16, 2016 at 05:25:49PM -0700, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
>
> Apple removed the OpenSSL header files in macOS 10.11 and above. OpenSSL
> was deprecated since macOS 10.7.
>
> Set `NO_OPENSSL` and `APPLE_COMMON_CRYPTO` to `YesPlease` as default for
> macOS.
Hi Duy,
On Mon, 17 Oct 2016, Duy Nguyen wrote:
> On Mon, Oct 17, 2016 at 3:57 PM, Johannes Schindelin
> wrote:
> > Hi Stefan,
> >
> > On Sun, 16 Oct 2016, Stefan Beller wrote:
> >
> >> Conceptually I would prefer if we had a single switch that indicates a
> >> case insensitive FS.
> >
> > AFAIU
On Mon, Oct 17, 2016 at 5:46 PM, Johannes Schindelin
wrote:
> Hi Duy,
>
> On Mon, 17 Oct 2016, Duy Nguyen wrote:
>
>> On Mon, Oct 17, 2016 at 3:57 PM, Johannes Schindelin
>> wrote:
>> > Hi Stefan,
>> >
>> > On Sun, 16 Oct 2016, Stefan Beller wrote:
>> >
>> >> Conceptually I would prefer if we had
On Sat, Oct 15, 2016 at 4:06 AM, Martin Langhoff
wrote:
> On Fri, Oct 14, 2016 at 4:58 PM, Kevin Daudt wrote:
>> Correct, this only works when it's unambiguous what branch you actually
>> mean.
>
> That's not surprising, but there isn't a warning. IMHO, finding
> several branch matches is a stron
Update test to reflect changes.
Signed-off-by: Vasco Almeida
---
apply.c | 4 ++--
t/t4254-am-corrupt.sh | 2 +-
2 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/apply.c b/apply.c
index 8215874..705cf56 100644
--- a/apply.c
+++ b/apply.c
@@ -1586,8 +1586,8 @@ static i
Mark error messages about CRLF for translation.
Update test to reflect changes.
Signed-off-by: Vasco Almeida
---
convert.c | 12
t/t0020-crlf.sh | 6 +-
2 files changed, 13 insertions(+), 5 deletions(-)
diff --git a/convert.c b/convert.c
index 077f5e6..0ad39b1 100644
--
Mark rename_limit_warning and degrade_cc_to_c_warning and
rename_limit_warning for translation.
Signed-off-by: Vasco Almeida
---
diff.c | 14 +++---
1 file changed, 7 insertions(+), 7 deletions(-)
diff --git a/diff.c b/diff.c
index 1d304e0..1687317 100644
--- a/diff.c
+++ b/diff.c
@@ -4
Mark permissions_advice for translation.
Signed-off-by: Vasco Almeida
---
credential-cache--daemon.c | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)
diff --git a/credential-cache--daemon.c b/credential-cache--daemon.c
index 1e5f16a..46c5937 100644
--- a/credential-cache--daemon.c
++
> -Original Message-
> From: Heiko Voigt [mailto:hvo...@hvoigt.net]
> Sent: Thursday, October 13, 2016 12:10 PM
> To: David Turner
> Cc: git@vger.kernel.org
> Subject: Re: Uninitialized submodules as symlinks
>
> On Fri, Oct 07, 2016 at 06:17:05PM +, David Turner wrote:
> > Presently
> -Original Message-
> From: Duy Nguyen [mailto:pclo...@gmail.com]
> Sent: Monday, October 17, 2016 5:46 AM
> To: David Turner
> Cc: Stefan Beller; git@vger.kernel.org
> Subject: Re: Uninitialized submodules as symlinks
>
> On Sat, Oct 8, 2016 at 2:59 AM, David Turner
> wrote:
> >
> >
> >
Hi Lars,
On Tue, 4 Oct 2016, Lars Schneider wrote:
> If there is a conflict in the .gitattributes during a merge then it looks
> like as if the attributes are not applied
I tried to replicate this behavior, to the point where I wrote a patch
that demonstrates the breakage so I could single-step
Ævar Arnfjörð Bjarmason writes:
> As far as I can tell the only outstanding "change this" is your
> s/SHA1/SHA-1/ in , do
> you want to fix that up or should I submit another series?
I think I did that already myself while queuing. Could you fetch
what I queued on 'pu' to double check?
I think
Torsten Bögershausen writes:
>> +test_cmp_count () {
>> +expect=$1 actual=$2
>
> That could be
> expect="$1"
> actual="$2"
Yes, but it does not have to ;-).
Johannes Schindelin writes:
>> I'll mark it as "wait for follow-up fix" in whats-cooking.txt (on
>> 'todo' branch) to remind myself not to merge it yet.
>
> May I request your guidance as to your preference how to proceed?
> ...
I guess I didn't see this before I sent my response to the review
t
On 17/10/16 03:18, Jeff King wrote:
> On Mon, Oct 17, 2016 at 02:37:58AM +0100, Ramsay Jones wrote:
>
>> Hmm, well, you have to remember that 'make clean' sometimes
>> doesn't make clean. Ever since the Makefile was changed to only
>> remove $(OBJECTS), rather than *.o xdiff/*.o etc., you have t
Johannes Schindelin writes:
> In the upcoming commits, we will implement more and more of rebase -i's
> functionality inside the sequencer. One particular feature of the
> commands to come is that some of them allow editing the commit message
> while others don't, i.e. we cannot define in the rep
Johannes Schindelin writes:
> +/*
> + * Reads a file that was presumably written by a shell script, i.e.
> + * with an end-of-line marker that needs to be stripped.
> + *
> + * Returns 1 if the file was read, 0 if it could not be read or does not
> exist.
> + */
> +static int read_oneliner(struc
Johannes Schindelin writes:
> This teaches the run_git_commit() function to take an argument that will
> allow us to implement "todo" commands that need to amend the commit
> messages ("fixup", "squash" and "reword").
Likewise to 15/25, i.e. Good, though the growth by these two steps
starts to m
On 17/10/16 10:37, Jeff King wrote:
> On Mon, Oct 17, 2016 at 11:04:19AM +0200, Johannes Schindelin wrote:
>
>>> Gross. I would not be opposed to a Makefile rule that outputs the
>>> correct set of OBJECTS so this (or other) scripts could build on it.
>>
>> You could also use the method I use in
Jeff King writes:
> Still an impressive speedup as a percentage, but negligible in absolute
> terms. But that's on a local filesystem on a Linux machine. I'd worry
> much more about a system with a slow readdir(), e.g., due to NFS.
> Somebody's real-world NFS case[1] was what prompted us to do 0e
Jeff King writes:
> I like the general idea, but I'm not sure how this would interact with
> the tests in t that test the test suite.
I tried but gave up adding a new test for this to t ;-)
>> test_expect_failure () {
>> +if test "$test_in_progress" = 1
>> +then
>> +
Duy Nguyen writes:
> I agree. Which is why I wrote "we probably want something in the same
> spirit but limited to .gitattributes and .gitignore only". In other
> words we could have core.someName that makes .gitattributes and
> .gitignore patterns case-insensitive (or core-sensitive). If it's
>
Johannes Schindelin writes:
> I would vote for:
>
> 4. We keep letting Git read in the *current* version of .gitattributes
>*before* the merge, and apply those attributes while performing the
>merge.
Even though this needs a major surgery to the way the attr subsystem
reads from these fi
On Mon, Oct 17, 2016 at 12:10 AM, Junio C Hamano wrote:
> Johannes Schindelin writes:
>
>>> > expecting success:
>>> > actual=$(git submodule--helper resolve-relative-url-test
>>> > '(null)' '/usr/src/git/wip/t/trash directory.t0060-path-utils/.' '../.')
>>> > &&
>>> >
"brian m. carlson" writes:
> On Sat, Oct 15, 2016 at 10:25:34AM +0200, René Scharfe wrote:
>> The object_id functions oid_to_hex, oid_to_hex_r, oidclr, oidcmp, and
>> oidcpy are defined as wrappers of their legacy counterparts sha1_to_hex,
>> sha1_to_hex_r, hashclr, hashcmp, and hashcpy, respecti
Stefan Beller writes:
>> In any case, I find it more disturbing that we somehow ended up with
>> a system where these three things are expected to behave differently:
>>
>> A - path/to/dir
>> B - path/to/dir/
>> C - path/to/dir/.
>>
>> Is that something we can fix?
>
> Wel
larsxschnei...@gmail.com writes:
> The goal of this series is to avoid launching a new clean/smudge filter
> process for each file that is filtered.
>
> A short summary about v1 to v5 can be found here:
> https://git.github.io/rev_news/2016/08/17/edition-18/
>
> This series is also published on we
On Mon, Oct 17, 2016 at 11:28 AM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>>> In any case, I find it more disturbing that we somehow ended up with
>>> a system where these three things are expected to behave differently:
>>>
>>> A - path/to/dir
>>> B - path/to/dir/
>>>
Johannes Schindelin writes:
> The sequencer is our attempt to lib-ify cherry-pick. Yet it behaves
> like a one-shot command when it reads its configuration: memory is
> allocated and released only when the command exits.
>
> This is kind of okay for git-cherry-pick, which *is* a one-shot
> comman
Johannes Schindelin writes:
> This patch series marks the '4' in the countdown to speed up rebase -i
> by implementing large parts in C (read: there will be three more patch
> series after that before the full benefit hits git.git: sequencer-i,
> rebase--helper and rebase-i-extra). It is based on
Stefan Beller writes:
>> Where at the end-user facing level does this trailing "/." surface
>> and how does the difference appear to them? I think that is the
>> crucial question.
>>
>> Unless there is some convincing argument why "." is not special
>> (i.e. counter-argument to the above "bus vs
Am 17.10.2016 um 09:10 schrieb Junio C Hamano:
And I agree from that point of view that having to spell both sides
as $(pwd) would mean you are not testing that "Unixy input to
Windowsy output" expectation, but at the same time, I think you
would want "Windowsy input to Windowsy output" combinati
On Mon, Oct 17, 2016 at 6:54 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason writes:
>
>> As far as I can tell the only outstanding "change this" is your
>> s/SHA1/SHA-1/ in , do
>> you want to fix that up or should I submit another series?
>
> I think I did that already myself while queuing.
Am 17.10.2016 um 20:08 schrieb Junio C Hamano:
> ... oops. Totally unrelated to this patch, but I see these in
> strbuf.cocci.patch (this is at the tip of 'pu'), which are total
> nonsense. Perhaps I am running a way-stale spatch? It claims to be
> "spatch version 1.0.0-rc19 with Python support
Ramsay Jones writes:
> Heh, I actually have the following in my config.mak already:
>
> extra-clean: clean
> find . -iname '*.o' -exec rm {} \;
>
> But for some reason I _always_ type 'make clean' and then, to top
> it off, I _always_ type the 'find' command by hand (I have no idea
> why) :
Johannes Sixt writes:
>> "../." taken relative to "$(pwd)/." must be "$(pwd)/."
>> "../." taken relative to "$PWD/." must be "$(pwd)/."
>>
>> test, because of the limitation of your bash, cannot have the latter
>> half of the pair, so you'd need to comment it out with in-code
>> explanati
Jiang Xin writes:
> Hi Junio,
>
> Please pull the following l10n updates for Git 2.10 to the maint branch.
>
> The following changes since commit 9a4b694c539fead26833c2104c1a93d3a2b4c50a:
>
> l10n: zh_CN: review for git v2.10.0 l10n (2016-09-11 21:34:23 +0800)
Thanks.
> Dimitriy Ryazantcev (1
Am 17.10.2016 um 22:07 schrieb Junio C Hamano:
Ramsay Jones writes:
Heh, I actually have the following in my config.mak already:
extra-clean: clean
find . -iname '*.o' -exec rm {} \;
But for some reason I _always_ type 'make clean' and then, to top
it off, I _always_ type the 'find'
On Mon, Oct 17, 2016 at 1:07 PM, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> Heh, I actually have the following in my config.mak already:
>>
>> extra-clean: clean
>> find . -iname '*.o' -exec rm {} \;
>>
>> But for some reason I _always_ type 'make clean' and then, to top
>> it off, I
René Scharfe writes:
> I get these instead with 6513eabcbcbcfa684d4bb2d57f61c662b870b5ca on
> Debian testing with its "spatch version 1.0.4 with Python support and
> with PCRE support", which look legit:
They do look good. So I'd stop worrying about it and see how
painful to update my copy of s
I'm trying to create a git-svn repository with:
git svn clone --username=pixleyr --stdlayout --branches branches --branches
branches2 svn://mumble.com/mumble/mumble
but the command dies about 11seconds in with:
A
src/kernel/ppc/2.4.26-pre5-moto-pq3-2004_06_04-0/drivers/usb/seria
On 17/10/16 21:07, Junio C Hamano wrote:
> Ramsay Jones writes:
>
>> Heh, I actually have the following in my config.mak already:
>>
>> extra-clean: clean
>> find . -iname '*.o' -exec rm {} \;
>>
>> But for some reason I _always_ type 'make clean' and then, to top
>> it off, I _always_ typ
Pranit Bauva writes:
> Use "test-parse-options --expect" to rewrite the tests to avoid checking
> the whole variable dump by just testing what is required. This commit is
> based on 8ca65aeb (t0040: convert a few tests to use test-parse-options;
> Junio C Hamano; May 6, 2016).
>
> Signed-off-by:
Currently a URL for the superproject ending in
(A).../path/to/dir
(B).../path/to/dir/
(C).../path/to/dir/.
(D).../path/to/dir/./.
(E).../path/to/dir/.///.//.
is treated the same in (A) and (B), but (C, D, E) are different.
We never produce the URLs in (C,D,E) ourselves, they
Here are the topics that have been cooking. Commits prefixed with
'-' are only in 'pu' (proposed updates) while commits prefixed with
'+' are in 'next'. The ones marked with '.' do not appear in any of
the integration branches, but I am still holding onto them.
We may have to start thinking abou
People can see how fast the usual merges I see everyday are by
looking at output from
$ git log --first-parent --format='%ct %s' master..pu
and noticing the seconds since epoch. Most of the days, these are
recreated directly on top of 'master' from scratch, and they get
timestamps that are v
Johannes Schindelin writes:
> - for (i = 1; *p; i++) {
> + for (i = 1; *p; i++, p = next_p) {
> char *eol = strchrnul(p, '\n');
> - commit = parse_insn_line(p, eol, opts);
> - if (!commit)
> - return error(_("Could not parse line %
Hey Junio,
On Tue, Oct 18, 2016 at 3:58 AM, Junio C Hamano wrote:
> * pb/bisect (2016-10-14) 28 commits
> - SQUASH???
> - bisect--helper: remove the dequote in bisect_start()
> - bisect--helper: retire `--bisect-auto-next` subcommand
> - bisect--helper: retire `--bisect-autostart` subcommand
Stefan Beller writes:
> +static void strip_url_ending(char *url, size_t *_len)
> +{
> + int check_url_stripping = 1;
> + size_t len = _len ? *_len : strlen(url);
> +
> + while (check_url_stripping) {
> + check_url_stripping = 0;
> + if (is_dir_sep(url[len-2]) &
On Fri, Oct 14, 2016 at 10:37 AM, Jonathan Tan wrote:
> Change "const char *" to "char *" in struct trailer_item and in the
> return value of apply_command (since those strings are owned strings).
>
> Change "struct conf_info *" to "const struct conf_info *" (since that
> struct is not modified).
On Mon, Oct 17, 2016 at 3:49 PM, Junio C Hamano wrote:
> Stefan Beller writes:
>
>> +static void strip_url_ending(char *url, size_t *_len)
>> +{
>> + int check_url_stripping = 1;
>> + size_t len = _len ? *_len : strlen(url);
>> +
>> + while (check_url_stripping) {
>> + che
On Fri, Oct 14, 2016 at 10:38 AM, Jonathan Tan wrote:
> Currently, creation and addition (to a list) of trailer items are spread
> across multiple functions. Streamline this by only having 2 functions:
> one to parse the user-supplied string, and one to add the parsed
> information to a list.
>
>
On Fri, Oct 14, 2016 at 10:38 AM, Jonathan Tan wrote:
> Improve type safety by making arguments (whether from configuration or
> from the command line) have their own "struct arg_item" type, separate
> from the "struct trailer_item" type used to represent the trailers in
> the buffer being manipul
On Fri, Oct 14, 2016 at 10:38 AM, Jonathan Tan wrote:
>
> Existing trailers are extracted from the input message by looking for
> -a group of one or more lines that contain a colon (by default), where
> +a group of one or more lines in which at least one line contains a
> +colon (by default), whe
On Fri, Oct 14, 2016 at 10:38 AM, Jonathan Tan wrote:
> Currently, interpret-trailers requires that a trailer be only on 1 line.
> For example:
>
> a: first line
> second line
>
> would be interpreted as one trailer line followed by one non-trailer line.
>
> Make interpret-trailers support
Stefan Beller writes:
> On Fri, Oct 14, 2016 at 10:38 AM, Jonathan Tan
> wrote:
>>
>> Existing trailers are extracted from the input message by looking for
>> -a group of one or more lines that contain a colon (by default), where
>> +a group of one or more lines in which at least one line cont
On 10/17/2016 06:42 PM, Junio C Hamano wrote:
Stefan Beller writes:
On Fri, Oct 14, 2016 at 10:38 AM, Jonathan Tan wrote:
Existing trailers are extracted from the input message by looking for
-a group of one or more lines that contain a colon (by default), where
+a group of one or more lin
Good Day,
Financing shouldn't be a mystery for you, contact us for help today. Easy
Funding Service is here to help you solve out all your outstanding debts and be
free for good..We have come to conclusion that its high time a person can buy
his own house, good cars, established good business,
68 matches
Mail list logo