On 22.05.16 01:17, Mike Hommey wrote:
> Signed-off-by: Mike Hommey
> ---
> connect.c | 6 ++
> 1 file changed, 6 insertions(+)
>
> diff --git a/connect.c b/connect.c
> index c53f3f1..caa2a3c 100644
> --- a/connect.c
> +++ b/connect.c
> @@ -742,6 +742,12 @@ struct child_process *git_connect(i
On 20.05.16 17:23, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>>>> What does
>>>> git diff
>>>> say ?
>>>
>>> Great question. For all the unexpected files it says the
>>> same thing:
>>>
>>
On 20.05.16 16:28, Jon Forrest wrote:
>
>
> On 5/20/2016 7:19 AM, Torsten Bögershausen wrote:
>
>>> Great question. For all the unexpected files it says the
>>> same thing:
>>>
>>> old mode 100755
>>> new mode 100644
>>
>> S
On 20.05.16 15:48, Jon Forrest wrote:
>
>
> On 5/20/2016 6:19 AM, Torsten Bögershausen wrote:
>> On 20.05.16 03:48, Jon Forrest wrote:
>>> I'm running Git version 2.8.2 built from source on Ubuntu 16.04.
>>> I'm using a repository that's stored on
On 20.05.16 03:48, Jon Forrest wrote:
> I'm running Git version 2.8.2 built from source on Ubuntu 16.04.
> I'm using a repository that's stored on Dropbox. I'm the only person
> accessing this repo. Everything works great.
>
> For reasons unrelated to Git, I decided to try Git for Windows,
> so I
On 18.05.16 06:26, Torsten Bögershausen wrote:
> On 05/17/2016 08:58 PM, Junio C Hamano wrote:
>> tbo...@web.de writes:
>>
>>> #define HASH_WRITE_OBJECT 1
>>> #define HASH_FORMAT_CHECK 2
>>> +#define HASH_CE_HAS_SHA1 4
>>
>> How does one
On 05/17/2016 08:58 PM, Junio C Hamano wrote:
tbo...@web.de writes:
#define HASH_WRITE_OBJECT 1
#define HASH_FORMAT_CHECK 2
+#define HASH_CE_HAS_SHA1 4
How does one pronounce the words in this constant? Does it make a
listener understand what this constant means?
How about
HASH_USE_SHA
>[PATCH 1/3] mv: free memory at the end if desired
s/desired/DEVELOPER/
--
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 05/16/2016 06:13 PM, Junio C Hamano wrote:
Wait a minute, please. I only asked the reason why you did it that
way and mentioned that the end result seemed equivalent. "The end
result seems equivalent" does not automatically mean "therefore you
must avoid changing the code."
If you still pre
On 14.05.16 20:45, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> Do we need to run diff_populate_filespec() twice when src==dst ?
>
> Of course we do.
>
> src and dst may have the same path, but are coming from different
> places (src may be an indexed b
On 14.05.16 20:45, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> Do we need to run diff_populate_filespec() twice when src==dst ?
>
> Of course we do.
>
> src and dst may have the same path, but are coming from different
> places (src may be an indexed b
On 14.05.16 13:17, Adam Dinwoodie wrote:
> Add failing test case showing CRLF -> LF rewrite warnings being printed
> multiple times when running "git commit".
>
The problem seems to come from this line:
index 5473493..59d4106 100644
--- a/diffcore-break.c
+++ b/diffcore-break.c
@@ -61,9 +61,18 @@
On 13.05.16 14:33, Michael Haggerty wrote:
> Torsten, thanks for the report. Peff, thanks for the analysis.
I didn't follow all the details.
The new "pu" passes with no errors on all of my test systems :-)
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a messa
On 13.05.16 22:41, Alexander Rinass wrote:
> When running diff commands, a pathspec containing decomposed
> unicode code points is not converted to precomposed unicode form
> under Mac OS X, but we normalize the paths in the index and the
> history to precomposed form on that platform. As a resu
On 13.05.16 18:43, Junio C Hamano wrote:
> Adam Dinwoodie writes:
>
>> If you use .gitattributes to enable CRLF->LF rewriting, then commit a
>> file that would have its line endings rewritten, the "CRLF will be
>> replaced by LF" warning is printed several times over; I'd expect it to
>> be print
On 12.05.16 05:16, Jeff King wrote:
> On Wed, May 11, 2016 at 10:03:45PM +0200, Torsten Bögershausen wrote:
>
>>> If you are, can you confirm that it's actually hanging, and not just
>>> slow? On my system, test 26 takes about a minute to run (which is why
On 11.05.16 19:31, Jeff King wrote:
> On Wed, May 11, 2016 at 07:13:56PM +0200, Torsten Bögershausen wrote:
>
>> On 10.05.16 09:08, Johannes Schindelin wrote:
>> - I'm not sure, if this is the right thread to report on -
>>
>> It seems as if t5551 is hanging
On 10.05.16 09:08, Johannes Schindelin wrote:
- I'm not sure, if this is the right thread to report on -
It seems as if t5551 is hanging ?
This is the last line from the log:
ok 25 - large fetch-pack requests can be split across POSTs
I have 7 such processes running:
/trash directory.t5551-http-f
On 09.05.16 22:29, Junio C Hamano wrote:
> tbo...@web.de writes:
>
>> +if (stats->stat_bits & earlyout)
>> +break; /* We found what we have been searching for */
>
> Are we sure if our callers are only interested in just one bit at a
> time? Otherwise, if we want
On 08.05.16 20:20, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> May a simple
>> printf "1\n2\n3\n4\n5\n6\n7\n8\n9\n10\n"
>>
>> be an option ?
> If you were to do that, at least have the decency to make it more
> readable by doing som
On 08.05.16 04:21, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> That's true, but the test passes anyway.
> You can also remove the body of the test and replace it with "true"
> and say "the test passes anyway". Changing the test to use a
On 2016-05-07 14.19, Andreas Schwab wrote:
> Torsten Bögershausen writes:
>
>> The "seq" is not understood by all shells,
>> using printf fixes this,
>>
>> index 20a3ffe..48d964e 100755
>> --- a/t/t6044-merge-unrelated-index-changes.sh
>
These tests fail here under Mac OS,
they pass under Linux:
commit ff3d9b660a4b6e9d3eeb664ce1febe717adff737
I haven't had a chance to dig further.
expecting success:
git for-each-ref --format="%(if)%(authorname)%(then)%(authorname):
%(refname)%(end)" >actual &&
cat >expect <<-\EOF
The "seq" is not understood by all shells,
using printf fixes this,
index 20a3ffe..48d964e 100755
--- a/t/t6044-merge-unrelated-index-changes.sh
+++ b/t/t6044-merge-unrelated-index-changes.sh
@@ -20,7 +20,7 @@ test_description="merges with unrelated index changes"
# Commit E: renames a->subdir/
On 2016-05-06 13.55, Li Peng wrote:
> Fix a typo in comment.
Thanks
--
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
> Let's separate 01-04/10 into a different topic and give it its own
> name; tb/convert-eol-autocrlf was the name I picked primarily for
> 07/10 but 01-04/10 are not about that fix. Both 02 and 04 are about
> autocrlf (the former is "core.eol is irrelevant when core.autocrlf
> is there", the latt
On 05.05.16 23:52, Mike Hommey wrote:
> On Wed, May 04, 2016 at 07:48:30AM +0900, Mike Hommey wrote:
>> On Tue, May 03, 2016 at 09:07:41AM -0700, Junio C Hamano wrote:
>>> Mike Hommey writes:
>>>
t5603-clone-dirname uses url patterns that are not tested with
fetch-pack --diag-url, and it
On 04.05.16 20:17, Armin Kunaschik wrote:
> Hi list,
>
> I'm trying to compile/test/use git 2.8.2 on AIX 6.1 with no bash available.
> /bin/sh is a hard link to /bin/ksh which is a ksh88, a posix shell.
> Is this supposed to work?
>
> As an example: make test fails on nearly every t34* test and o
On 05/03/2016 08:31 PM, Junio C Hamano wrote:
Torsten Bögershausen writes:
This will probably take some time, so that's why I asked if 1/10..4/10 could
proceed as is ?
Sure, I wasn't saying 1-4 looked wrong at all. I was wondering why
the ones in the middle, especially 7, shouldn&
On 2016-05-03 18.07, Junio C Hamano wrote:
> Mike Hommey writes:
>
>> t5603-clone-dirname uses url patterns that are not tested with
>> fetch-pack --diag-url, and it would be useful if they were.
>>
>> Interestingly, some of those tests, involving both a port and a
>> user:password pair, don't cu
On 2016-05-03 10.50, Mike Hommey wrote:
> While it is not strictly necessary, it makes the connect code simpler
> when there is user.
>
That commit message does't tell too much, I think.
Besides that, I'm sure it will break (at least) my ssh wrapper scripts,
which rely on user@host to be passed
On 2016-05-03 10.50, Mike Hommey wrote:
> Signed-off-by: Mike Hommey
> ---
> connect.c | 6 ++
> t/t5500-fetch-pack.sh | 14 --
> 2 files changed, 14 insertions(+), 6 deletions(-)
>
> diff --git a/connect.c b/connect.c
> index e95e385..2c5b722 100644
> --- a/connect.
On 2016-05-03 10.50, Mike Hommey wrote:
> diff --git a/t/t5500-fetch-pack.sh b/t/t5500-fetch-pack.sh
> index e5f83bf..1f0133f 100755
> --- a/t/t5500-fetch-pack.sh
> +++ b/t/t5500-fetch-pack.sh
> @@ -569,12 +569,27 @@ check_prot_host_port_path () {
> test_cmp expected actual
> }
>
> -for r
On 2016-05-02 21.33, Junio C Hamano wrote:
> Junio C Hamano writes:
> Let's step back a bit and make sure we are on the same page. I
> think this "series" conflates a bit too many things into a single
> topic.
>
> * The comparison between the index and the working tree, i.e. "git
>diff", sh
On 05/02/2016 10:31 AM, Mike Hommey wrote:
On Mon, May 02, 2016 at 06:56:54AM +0200, Torsten Bögershausen wrote:
On 05/01/2016 08:02 AM, Mike Hommey wrote:
+ if (flags & CONNECT_DIAG_URL) {
printf("Diag: url=%s\n", url ? url : "NULL");
On 05/01/2016 08:02 AM, Mike Hommey wrote:
+ if (flags & CONNECT_DIAG_URL) {
printf("Diag: url=%s\n", url ? url : "NULL");
printf("Diag: protocol=%s\n", prot_name(protocol));
printf("Diag: hostandport=%s\n", hostandport ? hostandport :
"NULL"
On 29.04.16 23:09, Junio C Hamano wrote:
> Well, didn't I do exactly the above much earlier and discarded it
> because that breaks the definition of "diff"? Or is this doing
> something differently?
Yes, and I try to sneak it in anyway ;-)
I spend some time debugging how to get t6038 passed, an
On 01.05.16 08:02, Mike Hommey wrote:
> The CONNECT_DIAG_URL code for PROTO_GIT and PROTO_SSH were different in
> subtle ways.
Yes, and there (historical) reasons for that.
The first implementation did support IPV6 with SSH:
commit 5ba884483fe1a5f9ce1ce5e3c5e1c37c0fd296c4
[PATCH] GIT: Try a
On 2016-05-01 08.02, Mike Hommey wrote:
> get_port() is only used as a fallback when get_host_and_port() does not
> return a port. But get_port() does the same search as
> get_host_and_port(), except get_host_and_port() starts from the end of
> the host, respecting square brackets for ipv6 addresse
On 29.04.16 02:43, Mike Hommey wrote:
> get_host_and_port(&ssh_host, &port);
> + if (!port)
> + port = get_port(ssh_host);
I'm not sure, if this is an improvement or not.
The original intention was, to check what the parser did, before
going out to
do we want UNDEFINED case to return EOL_CRLF here?
>
>> case CRLF_AUTO_INPUT:
>> +return EOL_LF;
One of the compilers claimed that UNDEFINED was not handled in switch-case.
A Warning may be better ?
>> case CRLF_TEXT:
>> case CRLF_AUTO:
>>
On 25.04.16 16:11, Kirill Likhodedov wrote:
> Hi,
>
> I wonder if it is possible both to have LFs in all and only text files in
> working trees, and keep Git’s binary files auto-detection?
>
> To be more precise:
> * we want all text files to be checked out in LF;
> * we don’t want force peopl
On 04/24/2016 07:14 PM, Ramsay Jones wrote:
Sparse complains thus:
SP convert.c
convert.c:178:24: warning: Using plain integer as NULL pointer
convert.c:239:28: warning: dubious: !x & y
Signed-off-by: Ramsay Jones
---
Hi Torsten,
When you next re-roll your 'tb/convert-eol-autocr
On 2016-04-23 00.03, Junio C Hamano wrote:
> tbo...@web.de writes:
>
>> From: Torsten Bögershausen
>> Subject: Re: [PATCH v6 01/10] t0027: Make more reliable
>
> "Make more reliable" does not sound very grammatical.
>
>> Make the commit_chk_wrnNNO t
* tb/convert-eol-autocrlf (2016-04-19) 4 commits
- convert.c: ident + core.autocrlf didn't work
- t0027: test cases for combined attributes
- convert: allow core.autocrlf=input and core.eol=crlf
- t0027: avoid false "unchanged" due to lstat() matching after a change
Setting core.autocrlf to
>> Currently "* text=auto eol=lf" does the same as "* text eol=lf",
>> as the eol attribute overrides "text=auto", this will change in
>> future.
> Will change in future in what way? In patch 5/4?
>
>
Yes, kind of.
I'm fighting to get the test passed under Windows,
and if this 4/4 could make it i
On 04/12/2016 06:55 AM, Stan Hu wrote:
In the stateless RPC case, the server should respond to the client's depth
request with the set of commits which are no deeper than the desired
depth. Once this finishes, the server should terminate and receive the reply
in another POST request.
Previously
On 04/11/2016 12:59 AM, Ramsay Jones wrote:
The header mentions cygwin, but changes it for linux, BSD and Mac OS as
well.
Is this intentional ?
Signed-off-by: Ramsay Jones
---
git-compat-util.h | 17 -
index-helper.c| 4 ++--
read-cache.c | 2 +-
3 files changed
On 04/11/2016 01:03 AM, Ramsay Jones wrote:
It took me a few minutes to convince myself that, if index-helper is
the only writer for the symlink, that the call to readlink would
result in a properly NULL terminated string. This relies on the
Minor nit:
s/NULL/NUL/
--
To unsubscribe from this l
On 10.04.16 15:18, Stephan Beyer wrote:
Some nit-comments inline
> ---
> t/t6030-bisect-porcelain.sh | 167
> ++--
> 1 file changed, 85 insertions(+), 82 deletions(-)
>
> diff --git a/t/t6030-bisect-porcelain.sh b/t/t6030-bisect-porcelain.sh
> index 05bc6
On 08.04.16 12:01, chenjinlei wrote:
>
> I’m encounter a problem due to my own stupidity…
> #1 I pushed a project named Android to my repository.
> #2 I `mv Android android`, cause I think it’s no good to use the uppercase as
> my project name.
> #3 I pushed it to my repository again…
>
> I foun
with the o, not
>> the g. Here is a correct line to copy-and-paste if you like:
>>
>> Thanks-to: Torsten Bögershausen
>>
>> -- Hannes
>
> Thanks for reviewing and catching the NFD encoding error.
>
> I will send in a patch v2 with the correct NFC
On 05.04.16 23:12, Junio C Hamano wrote:
> tbo...@web.de writes:
>
>> +git config core.autocrlf true &&
>> +mv crlfinrepo tmp &&
>> +git checkout crlfinrepo &&
>> +rm tmp &&
>
> Why not just "rm -f crlfinrepo" and "git checkout crlfinrepo"?
The intention was to get a new inode num
On 05.04.16 21:15, Johannes Sixt wrote:
> Am 05.04.2016 um 19:09 schrieb Junio C Hamano:
>>> Thanks-to: Torsten Bögershausen
>
> I sense NFD disease: The combining diaresis should combine with the o, not
> the g. Here is a correct line to copy-and-paste if you like:
&g
Thanks for all the comments.
I just reallized that t6038 is broken, which I didn't notice before :-(
Please feel free to kick out
tb/safe-crlf-output-fix from pu,
until I have looked into the breakage and found a fix.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body
On 01.04.16 12:44, Elia Pinto wrote:
> Implements the GIT_CURL_DEBUG environment variable to allow a greater
> degree of detail of GIT_CURL_VERBOSE, in particular the complete
> transport header and all the data payload exchanged.
> It might be useful if a particular situation could require a more
directory
$ git status# Show files that will be normalized
$ git add -u
$ git add .gitattributes
$ git commit -m "Introduce end-of-line normalization"
(or run "dos2unix" filename)
commit a604db36bb946000776514c220964f32979c8756
Author: Torsten Böger
On 29.03.16 19:21, Junio C Hamano wrote:
> tbo...@web.de writes:
>
>> From: Torsten Bögershausen
>>
>> git blame reports lines as not "Not Committed Yet" when they have
>> CRLF in the index, CRLF in the worktree and e.g. core.autocrlf is true.
>&
On 2016-03-09 19.36, David Turner wrote:
> This is a rebase and extension of Duy's work on git index-helper and
> watchman support.
>
Somewhere we need to tweak something:
t7900 do all fail under Mac OS, because the index-helper is not build.
The best would be to have a precondition when running t
On 2016-03-29 15.31, Duy Nguyen wrote:
> On Tue, Mar 29, 2016 at 8:28 PM, Duy Nguyen wrote:
>> On Tue, Mar 29, 2016 at 8:25 PM, wrote:
>>> From: Torsten Bögershausen
>>>
>>> Factor out the retrival of the sha1 for a given path in
>>>
On 2016-03-25 18.36, Chhatoi Pritam Baral wrote:
Thanks for working on Git.
Some comments inline.
> Previously a TODO, this patch adds a test for git-checkout skipping a
> file with the
> skip-worktree bit set.
Micro-nit: the "this patch ..." may be written shorter:
> Previously a TODO, add a test
This is copy-paste replacement for the last commit.
(Most probably it is white space damaged)
I'm not sure, is it's worth it ?
If yes, I can send a proper patch later.
git show HEAD
commit 3ac551127d51cd59b24f49729d9ce4dd011a09a1
Author: Junio C Hamano
Date: Wed Mar 23 15:57:42 2016 -0700
On 2016-03-24 19.22, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> Would it make sense to have
>> git log --tab-size=8
>> (or similar)
>>
>> and add a config variable like
>> git config ui.logtabsize
>> which is 0 by default to get th
> [5/5] adds a new option --no-expand-tabs that controls the bit 4/5
>introduces, so that "git log [--pretty] --no-expand-tabs"
>would show the log message indented by 4 spaces, without tab
>expansion.
Does this introduce an unnecessary regression out of the sudden ?
Woul
>
> Thanks; Torsten, sorry but could you do another round of check, please?
Thanks, v2 tested OK under Mac OS and Linux
--
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-
On 2016-03-23 16.56, Junio C Hamano wrote:
>> Thanks, I used a slightly different version, as I had crafted it before
>> reading this mail already.
>
> Thanks; Torsten, sorry but could you do another round of check, please?
Sure :-)
--
To unsubscribe from this list: send the line "unsubscribe git
to write file names which work under Linux or
CYGWIN, but are incompatible with file naming rules under mingw or HFS.
Signed-off-by: Johannes Schindelin
Signed-off-by: Torsten Bögershausen
Reviewed-by: Jonathan Nieder
Signed-off-by: Junio C Hamano
---
On 2016-03-22 21.44, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> On 2016-03-22 18.43, Johannes Schindelin wrote:
>>> These two tests wanted to write file names which are incompatible with
>>> Windows' file naming rules.
>>>
>>>
On 2016-03-22 18.43, Johannes Schindelin wrote:
> These two tests wanted to write file names which are incompatible with
> Windows' file naming rules.
>
> Signed-off-by: Johannes Schindelin
Is there a chance to squeeze in a precondition for HFS under Mac OS ?
> -test_expect_success UTF8 'svn.pat
On 2016-03-22 09.00, Boettger, Heiko wrote:
> Hi,
>
> I always thought git allows concurrent access to a repository and expected
> that this also is true when working with local repositories. The only problem
> I was aware of is that the use of NFS and windows shares might cause
> problems. How
On 2016-03-21 05.35, Eric Sunshine wrote:
> }
> -#define st_add3(a,b,c) st_add((a),st_add((b),(c)))
> -#define st_add4(a,b,c,d) st_add((a),st_add3((b),(c),(d)))
> +#define st_add3(a,b,c) st_add(st_add((a),(b)),(c))
> +#define st_add4(a,b,c,d) st_add(st_add3((a),(b),(c)),(d))
>
That fix comp
On 2016-03-17 06.16, Torsten Bögershausen wrote:
Oh Boy,
typo in the last patch and t9115#11,12 where skipped on Mac & Linux :-(
The "case" should look like this:
> + "$neq")
> + true ;;
> + *)
> + false ;;
> +
inf=$(printf "\303\226") &&
>>> + git config svn.pathnameencoding ISO8859-1 &&
>
> Ditto. (0x8187 in cp932 = U+221E, INFINITY)
>
Agreed with all your comments, thanks for that.
A better version is here:
<https://github.com/tboegi/git/commit
On 2016-03-19 02.19, David Turner wrote:
> Each write() has syscall overhead, and writing a large index entails
> many such calls. A larger write buffer reduces the overhead,
> leading to increased performance.
>
> On my repo, which has an index size of 30m, this saves about 10ms of
> time writin
On 2016-03-18 03.15, Kazutoshi Satoda wrote:
> On 2016/03/17 14:35 +0900, Torsten Bögershausen wrote:
>> On 2016-03-17 06.16, Torsten Bögershausen wrote:
> ...
>> And the pathch is here:
>> <https://github.com/tboegi/git/commit/866dfc192a0d4428aebfc7242f5134899b6dafd4&
> Git v2.7.4 Release Notes
>
>
> Fixes since v2.7.3
> --
>
> * Bugfix patches were backported from the 'master' front to plug heap
>corruption holes, to catch integer overflow in the computation of
>pathname lengths, and to get rid of the name_pat
>I created a test case but git diff exits with 0 if it does not recognize the
file >path so the test case always succeeds. Can you give me a hint or one
>example test case?
The most clean (?) is to compare "git diff" NFC and git diff NFD, they should
give the same result:
for "git diff" somet
On 03/15/2016 02:59 AM, Eric Wong wrote:
[]
I just edited locally and pushed those out to Junio:
http://mid.gmane.org/20160315015726.ga25...@dcvr.yhbt.net
The new TC 11/12 don't pass under cygwin.
Do we need cp932 ?
If not, we may use the paych from here:
https://github.com/tboegi/git/commi
On 09.03.16 21:26, Junio C Hamano wrote:
> Anders Kaseorg writes:
[]
> sane_grep () {
> - GREP_OPTIONS= LC_ALL=C grep "$@"
> + GREP_OPTIONS= LC_ALL=C grep @@SANE_TEXT_GREP@@ "$@"
> }
>
> sane_egrep () {
> - GREP_OPTIONS= LC_ALL=C egrep "$@"
> + GREP_OPTIONS= LC_ALL=C egrep @@S
And if not, I can put it on my TODO-stack.
I have read through the official contribution guidelines and I think I can
send an official patch.
In this case, would you prefer to have a single commit since the change
is related? Or would you prefer keeping it in separate commits, since
they are dif
On 03/08/2016 08:59 AM, Anders Kaseorg wrote:
The included test case, which uses rebase -p with non-ASCII commit
messages, was failing as follows:
Warning: the command isn't recognized in the following line:
- Binary file (standard input) matches
You can fix this with 'git rebase --ed
On 03/07/2016 09:51 AM, Junio C Hamano wrote:
Junio C Hamano writes:
Perhaps we can introduce a new function can_clobber() that has the
same function signature as ce_uptodate() and update the callers in
apply and unpack-trees (there may be others) to call it instead when
they want to see if th
On 03/07/2016 08:47 AM, Alexander Rinass wrote:
On 04 Mar 2016, at 19:49, Ramsay Jones wrote:
On 04/03/16 14:37, Alexander Rinass wrote:
On 04 Mar 2016, at 13:16, Torsten Bögershausen wrote:
On 03/04/2016 10:07 AM, Alexander Rinass wrote:
[snip]
Sticking a precompose_argv(argc, argv
> I do not think I can endorse this approach, as I cannot explain why
> it could possibly make sense to treat as if CRLF conversion is
> somehow special among all the convert_to_git()/convert_to_worktree()
> conversions, which your patch does to the diff code.
>
> Comparisons between contents from
On 11.02.16 19:49, Junio C Hamano wrote:
> tbo...@web.de writes:
>
>> From: Torsten Bögershausen
>>
>> We define the working tree file is clean if either:
>>
>> * the result of running convert_to_git() on the working tree
>> contents matches wha
On 03/04/2016 10:07 AM, Alexander Rinass wrote:
Hallo,
It appears that the git diff command does not precompose file path arguments,
even if the option core.precomposeunicode is set to true (which is the default
on OS X).
Passing the decomposed form of a file path to the git diff command will
Oh, . I am only half as incompetent as I thought, then.
I didn't even re-check what I sent, and just assumed Torsten was quoting
it exactly (I _did_ write something like that while making the fix, and
assumed I had just failed to properly commit).
So yes, what I sent both times is the right thi
That compiles OK, thanks.
Sorry for high-jacking this thread, but while compiling under CYGWIN,
found one warning:
LINK git-credential-store.exe
CC daemon.o
daemon.c: In function ‘drop_privileges’:
daemon.c:1136:15: warning: implicit declaration of function ‘initgroups’
[-Wimplicit-func
Thanks for the fast-patch.
I manually copied the patch, But there are more probles, it seems.
$ git diff
diff --git a/compat/mingw.c b/compat/mingw.c
index cfedcf9..b1163f2 100644
--- a/compat/mingw.c
+++ b/compat/mingw.c
@@ -1069,7 +1069,7 @@ static pid_t mingw_spawnve_fd(const char *cmd, const
I haven't digged further,
but trying to verify t9115 under Windows gave this:
compat/mingw.c: In function 'mingw_spawnve_fd':
compat/mingw.c:1072:10: warning: implicit declaration of function
'xmalloc_array' [-Wimplicit-function-declaration]
wargs = xmalloc_array(st_add(st_mult(2, args.len),
+ (
+ cd "$git" &&
+ git init . &&
+ git config --add git-p4.mapUser "mmax -> Max Mustermann
" &&
+ git config --add git-p4.mapUser "mo -> Moritz Untreu
" &&
Probably better to use more innocuous names. I'm not sure who these
peop
On 28.02.16 05:59, Eric Wong wrote:
> tbo...@web.de wrote:
> Please keep lines wrapped at 80 cols or less.
> (I need big fonts)
OK
>
>> @@ -105,10 +105,10 @@ test_expect_success UTF8 'svn.pathnameencoding=cp932
>> new file on dcommit' '
>> '
> Why the extra 'o'?
That shouldn't be there, sorry.
W
How about something like this as a workaround ?
(I can send a proper patch, if this is the way forward)
commit dcd7d5551d6931e47829c7febbee0877340eb17f
Author: Torsten Bögershausen
Date: Sat Feb 27 15:18:28 2016 +0100
config.mak.uname: Darwin: Use clang for Mac OS X 10.6
Commit
On 27.02.16 04:29, Jeff King wrote:
> On Fri, Feb 26, 2016 at 03:35:10PM -0800, Junio C Hamano wrote:
>
>>> Digging means:
>>> run git bisect and report the commit.
>>> And this makes the compiler happy:
>>> Revert "tree-diff: catch integer overflow in combine_diff_path allocation"
>> So?
>>
>>
On 2016-02-26 19.29, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> CC combine-diff.o
>> combine-diff.c: In function ‘diff_tree_combined’:
>> combine-diff.c:1391: internal compiler error: Segmentation fault
>> Please submit a full bug report,
>> wit
> * jk/tighten-alloc (2016-02-22) 22 commits
> (merged to 'next' on 2016-02-24 at 78b3251)
> + ewah: convert to REALLOC_ARRAY, etc
> + convert ewah/bitmap code to use xmalloc
> + diff_populate_gitlink: use a strbuf
> + transport_anonymize_url: use xstrfmt
> + git-compat-util: drop mempcpy c
On 02/22/2016 09:20 AM, Junio C Hamano wrote:
Thanks for all the comments,
I will send a new version the next days.
--
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
On 15/02/16 05:50, Junio C Hamano wrote:
Torsten Bögershausen writes:
* tb/conversion (2016-02-10) 6 commits
(merged to 'next' on 2016-02-12 at 6faf27b)
Could we keep it in next for a while ?
I found issues that needs to be fixed before going to master,
updates follow soonish
> * tb/conversion (2016-02-10) 6 commits
> (merged to 'next' on 2016-02-12 at 6faf27b)
Could we keep it in next for a while ?
I found issues that needs to be fixed before going to master,
updates follow soonish.
Thanks
--
To unsubscribe from this list: send the line "unsubscribe git" in
the bod
On 12.02.16 12:31, Eric Wong wrote:
> Eric Wong wrote:
>> (no rush to review this, unlikely to be around the next few days)
> Ping on v2. I will be online the next few days and likely
> working on some other git stuff anyways :)
Patch V2 looks OK for me.
--
To unsubscribe from this list: send t
401 - 500 of 1315 matches
Mail list logo
