On 03.04.17 19:30, David Turner wrote:
> Unfortunately, in order to push some large repos, the http postbuffer
> must sometimes exceed two gigabytes. On a 64-bit system, this is OK:
> we just malloc a larger buffer.
>
> This means that we need to use CURLOPT_POSTFIELDSIZE_LARGE to set the
>
[]
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -319,6 +319,8 @@ extern char *gitdirname(char *);
#define PRIo32 "o"
#endif
+#define parse_timestamp strtoul
+
Would
#define parse_timestamp(a,b,c) strtoul((a),(b),(c))
be more strict ?
On 02/04/17 21:06, Johannes Schindelin wrote:
In its `atom_value` struct, the ref-filter source code wants to store
different values in a field called `ul` (for `unsigned long`), e.g.
timestamps.
However, as we are about to switch the data type of timestamps away from
`unsigned long` (because
On 2017-03-31 21:44, Jakub Narębski wrote:
> W dniu 31.03.2017 o 14:38, Torsten Bögershausen pisze:
>> On 30.03.17 21:35, Jakub Narębski wrote:
>>> Hello,
>>>
>>> Recently I had to work on a project which uses legacy 8-bit encoding
>>> (namely cp1
On 30.03.17 21:35, Jakub Narębski wrote:
> Hello,
>
> Recently I had to work on a project which uses legacy 8-bit encoding
> (namely cp1250 encoding) instead of utf-8 for text files (LaTeX
> documents). My terminal, that is Git Bash from Git for Windows is set
> up for utf-8.
>
> I wanted for
On 30/03/17 22:29, David Turner wrote:
Unfortunately, in order to push some large repos, the http postbuffer
must sometimes exceed two gigabytes. On a 64-bit system, this is OK:
we just malloc a larger buffer.
Signed-off-by: David Turner
---
cache.h | 1 +
config.c
On 30.03.17 18:01, Ben Peart wrote:
>> From: Torsten Bögershausen [mailto:tbo...@web.de]
>>
>>
>> Does this work ?
>> I would have expected
>> packet_writel(fd, "line one", "line two", "line n"), NULL;
Typo.
Should h
[snip]
Would packet_write_lines make more sense ?
Just goes to prove that there are two hard things in computer science: cache
invalidation, naming things, and off-by-one errors. :) The feedback on V1 was:
"I am hesitant to take a function that does not take any "list"
type argument and
On 03/25/2017 02:05 PM, Duy Nguyen wrote:
On Sat, Mar 25, 2017 at 07:26:14PM +0700, Duy Nguyen wrote:
On Sat, Mar 25, 2017 at 6:46 PM, Duy Nguyen <pclo...@gmail.com> wrote:
On Sat, Mar 25, 2017 at 5:46 PM, Torsten Bögershausen <tbo...@web.de> wrote:
./t1305-config-incl
./t1305-config-include.sh
seems to be broken:
not ok 19 - conditional include, $HOME expansion
not ok 21 - conditional include, relative path
Both Mac and Linux.
The problem seems to be the line
git config test.two >actual &&
and
git config test.four >actual &&
In both cases the config
On 2017-03-24 16:27, Ben Peart wrote:
> Add packet_writel() which writes multiple lines in a single call and
> then calls packet_flush_gently(). Add packet_read_line_gently() to
> enable reading a line without dying on EOF.
>
> Signed-off-by: Ben Peart
> ---
> pkt-line.c
On 24/03/17 09:27, Prathamesh Chavan wrote:
From: Prathamesh
Welcome to Git.
The name in the "From:" must match the name in the sign-off:
git config --global user.name "Prathamesh Chavan"
Signed-off-by: Prathamesh Chavan
The patch looks good
On 17/03/17 10:28, Vish Gite wrote:
Hello,
Git 2.10.1 on Apple mac is treating different(uppercase/lowercase)
files as same name(e.g ABCD.py and abcd.py)
In a project where file name is same but case is different, either
ABCD.py or abcd.py. There is always one of these files is modified.
On 15/03/17 22:29, Junio C Hamano wrote:
Torsten Bögershausen <tbo...@web.de> writes:
The real "show stopper" is at the end.
...
==
And it seams as if zlib is the limitation here.
Unless we include the zlib source code into Git and redefine uLong,
is
On 2017-03-15 17:13, Jeff King wrote:
> On Wed, Mar 15, 2017 at 11:59:52AM -0400, Jeff King wrote:
>
>> I agree that detecting the situation in the meantime is a good idea.
>> The patch above probably handles the bulk-checkin code path, I'd guess.
>> It might be nice to have similar checks in
On 03/05/2017 09:26 PM, Cory Kilpatrick wrote:
I have downloaded Git and cannot find the application on my Mac. Should I try
to download it again?
I don't think so.
It could be helpful if we can get some more information:
- Could you open the terminal application and type
which git
git
On 2017-03-03 18:47, Junio C Hamano wrote:
> Torsten Bögershausen <tbo...@web.de> writes:
>
>> Understood, thanks for the explanation.
>>
>> quiet is not quite any more..
>>
>> Does the following fix help ?
>>
>> --- a/diff.c
>> +++
Understood, thanks for the explanation.
quiet is not quite any more..
Does the following fix help ?
--- a/diff.c
+++ b/diff.c
@@ -2826,6 +2826,8 @@ int diff_populate_filespec(struct diff_filespec *s,
unsigned int flags)
enum safe_crlf crlf_warn = (safe_crlf == SAFE_CRLF_FAIL
On 2017-03-02 15:20, Mike Crowe wrote:
> ll the solutions presented so far do cause a small change in behaviour
> when using git diff --quiet: they may now cause warning messages like:
>
> warning: CRLF will be replaced by LF in crlf.txt.
> The file will have its original line endings in your
d" will not do any changes to the index, and
>> "git diff -quiet" should exit 0.
>>
>> Add calls to would_convert_to_git() before blindly saying that a different
>> size means different content.
>>
>> Reported-By: Mike Crowe <m...@mcrowe.com>
&g
On 2017-02-27 21:17, Junio C Hamano wrote:
> Torsten, you've been quite active in fixing various glitches around
> the EOL conversion in the latter half of last year. Have any
> thoughts to share on this topic?
>
> Thanks.
Sorry for the delay, being too busy with other things.
I followed the
On Sun, Jan 08, 2017 at 08:17:36PM +0100, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
>
> Some `clean` / `smudge` filters might require a significant amount of
> time to process a single blob. During this process the Git checkout
> operation is blocked and
On Fri, Jan 06, 2017 at 01:56:36PM -0800, Steven Robertson wrote:
> Hello,
>
> I was doing development on a linux box on AWS, when we found a code
> bug that had me switching to running the code on a Mac instead. We
> discovered that we had accidentally named two files the same when
> looked at
On 04.01.17 01:48, Jeff King wrote:
> On Tue, Jan 03, 2017 at 11:09:18AM -0800, Brandon Williams wrote:
>
>> Only change with v4 is in [1/5] renaming the #define MAXSYMLINKS back to
>> MAXDEPTH due to a naming conflict brought up by Lars Schneider.
>
> Hmm. Isn't MAXSYMLINKS basically what you
On 01.01.17 05:59, A. Wilcox wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
>
> Hello!
>
> I'm attempting to package Git for our new Linux distribution and I
> have run in to a failure on our PowerPC builder while running the test
> suite.
>
> The PowerPC builder runs a tiny version
On 14/12/16 20:37, Johannes Sixt wrote:
normalize_path_copy() is not prepared to keep the double-slash of a
//server/share/dir kind of path, but treats it like a regular POSIX
style path and transforms it to /server/share/dir.
The bug manifests when 'git push //server/share/dir master' is
Sure, and I'd rather see the update-unicode.sh script moved
somewhere in contrib/ while at it. Those who are interested in
keeping up with the unicode standard are tiny minority of the
developer population, and most of us would treat the built width
table as the source (after all, that is what
>> Minor question, especially to the next commit:
>> Should we make sure to checkout the exact version, which has been tested?
>> In this case cb97792880625e24a9f581412d03659091a0e54f
>>
>> And this is for both a fresh clone and the git pull
>> needs to be replaced by
>> git fetch && git
On 2016-12-12 00:34, Beat Bolli wrote:
> We need to track the new commits in uniset, otherwise their and our code
> get out of sync.
>
> Signed-off-by: Beat Bolli
> ---
>
> Junio, these go on top of my bb/unicode-9.0 branch, please.
>
> Thanks!
>
> update_unicode.sh | 5
On Wed, Dec 07, 2016 at 02:13:35PM -0800, Brandon Williams wrote:
> On 12/07, Junio C Hamano wrote:
> > Torsten Bögershausen <tbo...@web.de> writes:
> >
> > > But in any case it seems that e.g.
> > > //SEFVER/SHARE/DIR1/DIR2/..
> > >
On Wed, Dec 07, 2016 at 01:12:25AM +, Ramsay Jones wrote:
>
>
> On 07/12/16 00:10, Brandon Williams wrote:
> > On 12/06, Junio C Hamano wrote:
> >> POSIX cares about treating "//" at the very beginning of the path
> >> specially. Is that supposed to be handled here, or by a lot higher
> >>
On 2016-12-05 12:05, thomas.attw...@stfc.ac.uk wrote:
> On Sun, 4 Dec 2016 08:09:14 +, Torsten Bögershausen wrote:
>> There seems to be another issue, which may or may not being related:
>> https://github.com/git-for-windows/git/issues/979
>
> I think this is the same issue. I've posted my
On Fri, Dec 02, 2016 at 05:37:50PM -0500, Jeff King wrote:
> On Fri, Dec 02, 2016 at 06:02:16PM +, thomas.attw...@stfc.ac.uk wrote:
>
> > After updating git from 2.10.0 to 2.11.0 when trying to push any
> > changes to a repo located in a windows share, the following error
> > occurs:
> >
> >
On Sat, Dec 03, 2016 at 10:00:47PM +0100, Beat Bolli wrote:
> Checking just for the unicode data files' existence is not sufficient;
> we should also download them if a newer version exists on the Unicode
> consortium's servers. Option -N of wget does this nicely for us.
>
> Reviewed-by: Torsten
Yup, this is what I queued.
Looks good, thanks you all.
On Tue, Nov 29, 2016 at 10:42:18AM -0800, Junio C Hamano wrote:
> tbo...@web.de writes:
>
> > From: Torsten Bögershausen <tbo...@web.de>
> >
> > Working with a repo that used to be all CRLF. At some point it
> > was changed to all LF, with `text=auto` in .gita
On Sun, Nov 27, 2016 at 10:19:35PM -0800, Eevee (Lexy Munroe) wrote:
> I'm working with a repo that used to be all CRLF. At some point it
> was changed to all LF, with `text=auto` in .gitattributes for the
> sake of Windows devs. I'm on Linux and have never touched any
> twiddles relating to
RFH, the normalization as descrived in Documentation/gitattributes.txt
does not work anymore:
>From a clean working directory:
-
$ echo "* text=auto" >.gitattributes
$ rm .git/index # Remove the index to force Git to
$ git reset #
On 20/11/16 22:18, Mike Fisher wrote:
Thanks for contributing to Git.
One comment on the head line:
>Refactor send_message() to remove dependency on deprecated
Net::SMTP::SSL
The word "refactor" may be used in other way: Re-structure the code,
and use the same API.
"Remove dependency on
On 17/11/16 18:10, Junio C Hamano wrote:
Mike Rappazzo writes:
(Please reply inline)
Indeed ;-)
On Wed, Nov 16, 2016 at 10:48 AM, Vanderhoof, Tzadik
wrote:
I am running:git version 2.10.1.windows.1
I typed: git merge -h
and got:
On 16.11.16 15:39, Heiko Voigt wrote:
> On Tue, Nov 15, 2016 at 10:31:59AM -0500, Jeff King wrote:
>> On Tue, Nov 15, 2016 at 01:07:18PM +0100, Heiko Voigt wrote:
>>
>>> On Fri, Nov 11, 2016 at 09:22:51AM +0100, Lars Schneider wrote:
To all macOS users on the list:
Does anyone execute
On 14.11.16 10:11, Lars Schneider wrote:
>
>> On 13 Nov 2016, at 02:13, Junio C Hamano wrote:
>>
>> Johannes Schindelin writes:
>>
Thanks. Dscho, does this fix both of these issues to you?
>>>
>>> Apparently it does because the CI jobs for
On 10/11/16 00:39, Junio C Hamano wrote:
I've followed what was available at the public-inbox archive, but it
is unclear what the conclusion was.
For the first one your "how about" non-patch, to which Peff said
"that's simple and good", looked good to me as well, but is it
available as a
On 09.11.16 10:29, Lars Schneider wrote:
>
>> On 09 Nov 2016, at 09:18, Torsten Bögershausen <tbo...@web.de> wrote:
>>
>> On 07.11.16 18:26, Jeff King wrote:
>>> On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote:
>>>
>>>>
On 07.11.16 18:26, Jeff King wrote:
> On Sun, Nov 06, 2016 at 08:35:04PM +0100, Lars Schneider wrote:
>
>> Good point. I think I found an even easier way to achieve the same.
>> What do you think about the patch below?
>>
>> [...]
>>
>> diff --git a/Makefile b/Makefile
>> index 9d6c245..f53fcc9
> * st/verify-tag (2016-10-10) 7 commits
> - t/t7004-tag: Add --format specifier tests
> - t/t7030-verify-tag: Add --format specifier tests
> - builtin/tag: add --format argument for tag -v
> - builtin/verify-tag: add --format to verify-tag
> - tag: add format specifier to gpg_verify_tag
> -
On Thu, Nov 03, 2016 at 09:30:44AM -0400, Martin-Louis Bright wrote:
> I will see if I can find a OSX 10.6 system to test with, and I'll try with
> perl 5.10.
>
> --Martin
No need to worry too much:
I have tested Peffs patch applied on next OK-
And the integration into pu that came the 2nd
> +use IO::File;
That did the trick (the J6T version work as well)
Thanks for the fast responses.
> * ls/filter-process (2016-10-17) 14 commits
> (merged to 'next' on 2016-10-19 at ffd0de042c)
Some (late, as I recently got a new battery for the Mac OS 10.6 test system)
comments:
t0021 failes here:
Can't locate object method "flush" via package "IO::Handle" at
>
> * tb/convert-stream-check (2016-10-27) 2 commits
> - convert.c: stream and fast search for binary
> - read-cache: factor out get_sha1_from_index() helper
>
> End-of-line conversion sometimes needs to see if the current blob
> in the index has NULs and CRs to base its decision. We used
[]
> This probably should be done as four more patches to become
> reviewable.
>
> - One to use the CONVERT_STAT_BITS a lot more for the conversion
>decision than before,
>
> - another to allow the caller to tell gather_stats() to give up
>early with the "search_only" bits,
>
> -
diff --git a/t/t6000-rev-list-misc.sh b/t/t6000-rev-list-misc.sh
index 3e752ce..a2acff3 100755
--- a/t/t6000-rev-list-misc.sh
+++ b/t/t6000-rev-list-misc.sh
@@ -100,4 +100,11 @@ test_expect_success '--bisect and --first-parent can not
be combined' '
test_must_fail git rev-list --bisect
On 17/10/16 05:07, Stefan Beller wrote:
On Sun, Oct 16, 2016 at 6:04 PM, Lars Schneider
wrote:
Hi,
Git attributes for path names are generally case sensitive. However, on
a case insensitive file system (e.g. macOS/Windows) they appear to be
case insensitive
On 15.10.16 19:19, Jeff King wrote:
> On Sat, Oct 15, 2016 at 07:03:46PM +0200, Torsten Bögershausen wrote:
>
>> sequencer.c:633:14: warning: comparison of constant 2 with expression of
>> type 'const enum todo_command' is always true
>> [-Wtautological-const
Not sure is this has been reported before:
sequencer.c:633:14: warning: comparison of constant 2 with expression of type
'const enum todo_command' is always true
[-Wtautological-constant-out-of-range-compare]
if (command < ARRAY_SIZE(todo_command_strings))
~~~ ^
On 12.10.16 18:05, David Brown wrote:
> Howdy git gurus,
>
> I have the dubious distinction of working with a remote repo (master) that
> has a class loader run-time error when cloned, built and executed.
>
> The reason for the runtime issue is a directory hierarchical path has to
>
On Tue, Oct 11, 2016 at 10:11:22AM +0200, Lars Schneider wrote:
>
> > On 10 Oct 2016, at 21:58, Junio C Hamano wrote:
> >
> > larsxschnei...@gmail.com writes:
> >
> > [...]
> >> +# Count unique lines except clean invocations in two files and compare
> >> +# them. Clean
On 09/10/16 08:48, Jason Pyeron wrote:
The whole .gitattributes needs to be adopted, I think
Git 2.10 or higher has "git ls-files --eol":
git ls-files --eol | grep "i/crlf.*auto"
i/crlf w/crlf attr/text=auto src/site/xdoc/upgradeto2_3.xml
i/crlf w/crlf attr/text=auto
On 08.10.16 13:25, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
>
> Add a simple pass-thru filter as example implementation for the Git
> filter protocol version 2. See Documentation/gitattributes.txt, section
> "Filter Protocol" for more info.
>
Nothing
On 09.10.16 01:06, Jakub Narębski wrote:
>> +
>> > +packet: git< status=abort
>> > +packet: git<
>> > +
>> > +
>> > +After the filter has processed a blob it is expected to wait for
>> > +the next "key=value" list containing a
>I am not suggesting that you apply this exact patch (stdin_ is not a good
choice
How about fd_stdin ?
On 29.09.16 21:30, Sebastian Feldmann wrote:
> Hi there,
>
> I have a problem executing a pre-commit hook.
> The hook script has to change the working directory to work and if I use plain
>
> git commit
>
> it works as expected, the script executes without errors, but if I use
>
> git commit —only
On 29/09/16 19:57, Lars Schneider wrote:
On 29 Sep 2016, at 18:57, Junio C Hamano <gits...@pobox.com> wrote:
Torsten Bögershausen <tbo...@web.de> writes:
1) Git exits
2) The filter process receives EOF and prints "STOP" to the log
3) t0021 checks the content of the log
On 29/09/16 12:28, Lars Schneider wrote:
On 28 Sep 2016, at 23:49, Junio C Hamano wrote:
I suspect that you are preparing a reroll already, but the one that
is sitting in 'pu' seems to be flaky in t/t0021 and I seem to see
occasional failures from it.
I didn't trace where
On 15.09.16 22:04, Junio C Hamano wrote:
> Lars Schneider writes:
>
>> Wouldn't that complicate the pathname parsing on the filter side?
>> Can't we just define in our filter protocol documentation that our
>> "pathname" packet _always_ has a trailing "\n"? That would
On 16.09.16 08:51, Виталий Ищенко wrote:
> Sorry for delay.
>
No problem about the delay.
(And please no top-posting)
If you say
> ".gitattributes" indeed is not present in "master", but this is intentionally
then nobody has (to my knowledge) thought about this situation/workflow yet.
The
On 12.09.16 11:49, Lars Schneider wrote:
>> How do we send pathnames the have '\n' ?
>> Not really recommended, but allowed.
>> And here I am a little bit lost, is each of the lines packed into
>> a pkt-line ?
>> command=smudge is packet as pkt-line and pathname= is packed into
>> another one ?
On 12.09.16 21:35, Torsten Bögershausen wrote:
> On 12.09.16 14:55, Виталий Ищенко wrote:
>> Good day
>>
>> I faced following issue with gitattributes file (at least eol setting)
>> when was trying to force `lf` mode on windows.
>>
>> We have 2 branches
On 12.09.16 14:55, Виталий Ищенко wrote:
> Good day
>
> I faced following issue with gitattributes file (at least eol setting)
> when was trying to force `lf` mode on windows.
>
> We have 2 branches: master & dev. With master set as HEAD in repository
>
> I've added `.gitattributes` with following
[]
One general question up here, more comments inline.
The current order for a clean-filter is like this, I removed the error handling:
int convert_to_git()
{
ret |= apply_filter(path, src, len, -1, dst, filter);
if (ret && dst) {
src = dst->buf;
On Thu, Sep 08, 2016 at 08:21:32PM +0200, larsxschnei...@gmail.com wrote:
[]
> +packet: git> git-filter-client
> +packet: git> version=2
> +packet: git> version=42
> +packet: git>
> +packet: git< git-filter-server
> +packet: git< version=2
On Fri, Sep 09, 2016 at 10:36:28AM -0700, Jonathan Tan wrote:
[]
> diff --git a/t/test-lib.sh b/t/test-lib.sh
> index d731d66..c9c1037 100644
> --- a/t/test-lib.sh
> +++ b/t/test-lib.sh
> @@ -1072,6 +1072,10 @@ test_lazy_prereq NOT_ROOT '
> test "$uid" != 0
> '
>
> +test_lazy_prereq JGIT
On 06.09.16 19:47, john smith wrote:
> I am looking for a way to force smudge filter to run by simulating a
> real life checkout. Let's say I just created a new branch and did not
> modify any files but want to test my new smudge filter. According to
> some answers such as
>
On Tue, Aug 30, 2016 at 03:23:10PM -0700, Junio C Hamano wrote:
> Lars Schneider writes:
>
> > On 30 Aug 2016, at 20:59, Junio C Hamano wrote:
> >>
> >>> "abort" could be ambiguous because it could be read as "abort only
> >>> this file".
>
> diff --git a/sha1_file.c b/sha1_file.c
> index d5e1121..759991e 100644
> --- a/sha1_file.c
> +++ b/sha1_file.c
> @@ -1485,7 +1485,7 @@ int check_sha1_signature(const unsigned char *sha1,
> void *map,
>
> int git_open_noatime(const char *name)
Hm, should the function then be renamed into
On 25/08/16 22:31, Junio C Hamano wrote:
[]
This [0/3] is meant to be a cover for [1/2] and [2/2]?
I am trying to see if we broke format-patch recently, or it is a
manual editing error. The latter I do not care about; the former I
do.
No worry, 0/3 is patched by me by hand, sorry for
I was not talking about the cost of correcting mistakes. Running --filters
is potentially very costly. Just so you understand what I am talking
about: I have a report that says that checking out a sizeable worktree
with core.autocrlf=true is 58% slower than with core.autocrlf=false. That
is
On 23.08.16 19:50, Lucian Smith wrote:
> On Tue, Aug 23, 2016 at 10:36 AM, Julian Phillips
> wrote:
>> On 23/08/2016 17:14, Lucian Smith wrote:
>>>
>>> Thanks for the quick responses!
>>>
>>> My situation is that the git side is entirely whatever github.org is
>>>
On Mon, Aug 22, 2016 at 05:04:47PM -0700, Lucian Smith wrote:
> I'm attempting to use the git-svn bridge, and am having problems with
> line endings on Windows.
>
> The setup is that we have a git repository on github, and I've checked
> out a branch on my Windows machine using Tortoise svn. I
On 19.08.16 17:00, Johannes Schindelin wrote:
> Hi Torsten,
>
> On Fri, 19 Aug 2016, Torsten Bögershausen wrote:
>
>> On Thu, Aug 18, 2016 at 02:46:17PM +0200, Johannes Schindelin wrote:
>>
>>> +--filters::
>>> + Show the content as transformed by the fi
[]
On Thu, Aug 18, 2016 at 02:46:17PM +0200, Johannes Schindelin wrote:
> diff --git a/Documentation/git-cat-file.txt b/Documentation/git-cat-file.txt
> index 071029b..7d48735 100644
> --- a/Documentation/git-cat-file.txt
> +++ b/Documentation/git-cat-file.txt
> @@ -9,15 +9,15 @@ git-cat-file -
On Thu, Aug 18, 2016 at 02:46:28PM +0200, Johannes Schindelin wrote:
> With this patch, --batch can be combined with --textconv or --filters.
> For this to work, the input needs to have the form
>
>
>
> so that the filters can be chosen appropriately.
>
> Signed-off-by: Johannes
On Thu, Aug 18, 2016 at 02:46:17PM +0200, Johannes Schindelin wrote:
> As suggested by its name, the --filters option applies the filters
[]
> diff --git a/t/t8010-cat-file-filters.sh b/t/t8010-cat-file-filters.sh
Does it make sense to integrate tests into t1006-cat-file ?
> new file mode 100755
On 17.08.16 19:38, Junio C Hamano wrote:
> Junio C Hamano <gits...@pobox.com> writes:
>
>> Torsten Bögershausen <tbo...@web.de> writes:
>>
>>> Is this `text=auto` correct ?
>>
>> Thanks for spotting a typo. Definitely.
>>
>>
On Mon, Aug 15, 2016 at 08:42:48AM -0700, Junio C Hamano wrote:
> Torsten Bögershausen <tbo...@web.de> writes:
>
> > On 15.08.16 00:47, Junio C Hamano wrote:
> >> Torsten Bögershausen (1):
> >> convert: unify the "auto" handling of CRLF
> &
On 15.08.16 00:47, Junio C Hamano wrote:
> Torsten Bögershausen (1):
> convert: unify the "auto" handling of CRLF
Should we mention this change in the release notes?
The handling of "*.text = auto" was changed, and now
$ echo "* text=auto eol=crlf&qu
On Sat, Aug 13, 2016 at 06:50:19PM +0200, Johannes Sixt wrote:
> Am 12.08.2016 um 18:51 schrieb tbo...@web.de:
> >From: Torsten Bögershausen <tbo...@web.de>
> >
> >When a non-reversible CRLF conversion is done in "git add",
> >a warning is printed on
code paths)
Good ideas, I will work on a series that fixes bugs first, and then we
can see if there is room for optimization.
What do you think about this as a starting point,
more things will follow.
I like to here comments about the commit msg first ;-)
commit 3754404d3d1ea4a0cbbed4986cc4ac1b5fe6
> git -c core.autocrlf=$crlf add $fname >"${pfx}_$f.err" 2>&1
>
> would make more sense. We _know_ that we have to do convert_to_git() in
> that step because the content is changed. And then you can ignore the
> warnings from "git commit" (which are racy), or you can simply commit as
> a whole
On Tue, Aug 09, 2016 at 07:49:38AM -0400, Jeff King wrote:
> On Tue, Aug 09, 2016 at 11:33:37AM +0000, Torsten Bögershausen wrote:
>
> > > The second one seems plausible, given the history of issues with
> > > changing CRLF settings for an existing checkout. I'm no
On Tue, Aug 09, 2016 at 02:51:10AM -0400, Jeff King wrote:
> On Mon, Aug 08, 2016 at 08:32:24PM +0000, Torsten Bögershausen wrote:
>
> > > The verbose output is not very exciting, though:
> > >
> > > expecting success:
> > >
On Mon, Aug 08, 2016 at 11:29:26AM -0400, Jeff King wrote:
> On Mon, Aug 08, 2016 at 05:05:07PM +0200, Johannes Schindelin wrote:
>
> > I remember that you did a ton of work on t0027. Now I see problems, and
> > not only that the entire script now takes a whopping 4 minutes 20 seconds
> > to run
Any idea about any possible races?
Just to double-check: I assume that you have this
commit ded2444ad8ab8128cae2b91b8efa57ea2dd8c7a5
Author: Torsten Bögershausen <tbo...@web.de>
Date: Mon Apr 25 18:56:27 2016 +0200
t0027: make commit_chk_wrnNNO() reliable
in your tree ?
Is there a special pattern ?
Did you
On 2016-08-05 01.32, Junio C Hamano wrote:
> Mike Hommey writes:
[]
>> What kind of support are you expecting?
>
> The only rationale I recall you justifying this series was that this
> makes the resulting code easier to read, but I do not recall other
> people agreeing with
On 2016-08-06 00.06, Junio C Hamano wrote:
> Torsten Bögershausen <tbo...@web.de> writes:
>
>> On 2016-08-03 18.42, larsxschnei...@gmail.com wrote:
>>> The filter is expected to respond with the result content in zero
>>> or more pkt-line packets an
On 2016-08-03 18.42, larsxschnei...@gmail.com wrote:
> The filter is expected to respond with the result content in zero
> or more pkt-line packets and a flush packet at the end. Finally, a
> "result=success" packet is expected if everything went well.
>
> packet:
On 2016-08-05 15.08, Lars Schneider wrote:
[]
> Yeah it could do that. But then the filter cannot do things like
> modifying the index after the fact... however, that might be considered
> nasty by the Git community anyways... I am thinking about dropping
> this patch in the next roll as it is
On Wed, Aug 03, 2016 at 09:46:06AM -0400, jonsm...@gmail.com wrote:
> I'm working with some Windows programmers that don't believe in file
> permissions They keep sending me zip files of their source tree. I
> have my copy of the tree in git on Linux with all of the correct file
> permissions.
>
On Sun, Jul 31, 2016 at 11:45:08PM +0200, Lars Schneider wrote:
>
> > On 31 Jul 2016, at 22:36, Torstem Bögershausen wrote:
> >
> >
> >
> >> Am 29.07.2016 um 20:37 schrieb larsxschnei...@gmail.com:
> >>
> >> From: Lars Schneider
> >>
> >>
On 07/27/2016 02:06 AM, larsxschnei...@gmail.com wrote:
Some comments inline
[]
> The filter is expected to respond with the result content size as
> ASCII number in bytes and the result content in packet format with
> a flush packet at the end:
>
> packet: git<
201 - 300 of 1221 matches
Mail list logo