Seems like a greylist problem ?
(I take the freedom to forward your mail to upstream git,
in the hope that somebody has has an idea)
On 03.08.15 13:13, Philip Oakley wrote:
> I'm scratching my head as to why patches I try to send upstream
> (git@vger.kernel.org) via my MSysGit install's send-em
On 2015-08-06 06.21, Chris Packham wrote:
> Hi All,
>
> A developer at $dayjob called me over to have a look at a git error he
> was getting (names changed to protect the innocent).
>
> $ git --version
> git version 2.5.0
> $ git clone ssh://example.com/repo.git
> Cloning into 'repo'...
>
On 2015-08-05 23.19, Jeff King wrote:
> On Wed, Aug 05, 2015 at 10:34:34AM -0700, Junio C Hamano wrote:
>
>>> As you can see, there is a lot of complexity in there and I'm not
>>> convinced this is better than just exposing
>>> 'parse_connect_url()', which already handles everything for us.
I try
orrect,
> i.e.
> the output has proper commit ids, Author names and dates.. With "git bisect"
> I
> tracked this down to the following commit:
>
> commit 4bf256d67a85bed1e175ecc2706322eafe4489ca (HEAD, refs/bisect/bad)
> Author: Torsten Bögershausen
> Dat
On 2015-08-06 09.50, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Torsten Bögershausen writes:
>>
>>> It looks as if
>>> static char *get_repo_path(const char *repo, int *is_bundle)
>>> in built/clone.c
>>> checks if there is a local
On 2015-08-08 07.58, Torsten Bögershausen wrote:
> On 2015-08-07 18.32, Benkstein, Frank wrote:
>> Hello,
>>
>> I am working working on Linux and am examining code in a git repository I do
>> not know much about. I am only looking at files, not changing anythin
On 2015-08-10 20.48, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> Actually I could reproduce the following:
>> CRLF in repo, CRLF in working tree, core.autocrlf= true.
>
> What should happen in such a case? Wouldn't autocrlf=true want to
> strip CRL
On 08/10/2015 05:48 PM, Patrick Steinhardt wrote:
Sorry for the late reply (and possible re-sending),
I just stumbled over this in transport.c:
/*
* Strip username (and password) from a URL and return
* it in a newly allocated string.
*/
char *transport_anonymize_url(const char *url)
Could
(need to drop Eric from cc-list, no DNS from web.de)
On 2015-08-13 17.28, Elia Pinto wrote:
> Teach git about a new option, "http.sslVersion", which permits one to
> specify the SSL version to use when negotiating SSL connections. The
> setting can be overridden by the GIT_SSL_VERSION environmen
On 2015-08-14 09.51, Jörg Schaible wrote:
I can't reproduce it here:
git svn clone http://websvn/svn/essvn/standard/java-commons/lang
Initialized empty Git repository in /home/xx/lang/.git/
RA layer request failed: OPTIONS of
'http://websvn/svn/essvn/standard/java-commons/lang': Could not resolve
On 2015-08-14 12.38, Jörg Schaible wrote:
> Any idea how to proceed?
Git itself doesn't version empty directories at all, only files
(and soft links, sub modules).
Git creates a directory as a "side effect" to be able to store files
there.
May be I am off-topic, but would it be possible to f
Some nit-picking below:
On 08/19/2015 10:04 PM, larsxschnei...@gmail.com wrote:
From: Lars Schneider
PROBLEM:
We run P4 servers on Linux and P4 clients on Windows. For an unknown
reason the file path for a number of files in P4 does not match the
directory path with respect to case sensitivity.
On 2015-08-20 09.16, Lars Schneider wrote:
> Thanks for your feedback! See my answers below.
>> Identify path names that are different with respect to case sensitivity.
> Agreed!
>
>>
>>
>>> If there are any then run `p4 dirs` to build up a dictionary
>>> containing the "correct" cases for each pa
On 08/25/2015 08:54 AM, Luke Diamand wrote:
On 24/08/15 22:30, larsxschnei...@gmail.com wrote:
From: Lars Schneider
Thanks to Luke Diamand I realized the core problem and propose here a
substiantially simpler fix to my PATCH v4.
The test cases remain and prove the problem. In particular
"8 -
On 2015-08-26 19.42, Junio C Hamano wrote:
> Jeff S writes:
>
>> Brian thanks for responding! I'm finally able to build git completely.
>> Would it be possible to add the OS X dependency to the git/INSTALL
>> file?
>>
>> OSX Yosemite 10.10.5
>> Xcode 6.4 (6E35b)
>> …
>> $ brew install autoconf
>>
On 29.08.15 16:12, Karthik Nayak wrote:
> diff --git a/utf8.h b/utf8.h
> index 5a9e94b..7930b44 100644
> --- a/utf8.h
> +++ b/utf8.h
> @@ -55,4 +55,19 @@ int mbs_chrlen(const char **text, size_t *remainder_p,
> const char *encoding);
> */
> int is_hfs_dotgit(const char *path);
>
> +typedef en
On 26.08.15 21:46, David Turner wrote:
> Instead of a linear search over common_list to check whether
> a path is common, use a trie. The trie search operates on
> path prefixes, and handles excludes.
>
> Signed-off-by: David Turner
> ---
> path.c| 226
> +++
On 2015-08-31 19.40, Junio C Hamano wrote:
> larsxschnei...@gmail.com writes:
>> +test_expect_success 'Create a repo containing cp1251 encoded paths' '
>> +cd "$cli" &&
>> +
>> +FILENAME="$(echo "a-¤_o-¶_u-¼.txt" | iconv -f utf-8 -t cp1252)" &&
>
> Hmm, we'd be better off not having a bar
On 01/09/15 00:10, larsxschnei...@gmail.com wrote:
From: Lars Schneider
Signed-off-by: Lars Schneider
---
Documentation/git-p4.txt| 5 +
git-p4.py | 6 ++
t/t9821-git-p4-path-encoding.sh | 38 ++
3 files changed
Sorry if this is possible re-sending
Forwarded Message
Subject:Re: [PATCH v3] git-p4: add "--path-encoding" option
Date: Tue, 1 Sep 2015 06:37:59 +0200
From: Torsten Bögershausen
To: larsxschnei...@gmail.com, git@vger.kernel.org
CC: l...@diamand
On 2015-09-01 14.47, Lars Schneider wrote:
>>> +test_expect_success 'Create a repo containing iso8859-1 encoded paths' '
>>> >> +cd "$cli" &&
>>> >> +
>>> >> +ISO8859="$(printf "$UTF8_ESCAPED" | iconv -f utf-8 -t
>>> >> iso8859-1)" &&
>>> >> +>"$ISO8859" &&
>>> >> +
On 09/14/2015 06:55 PM, larsxschnei...@gmail.com wrote:
From: Lars Schneider
A P4 repository can get into a state where it contains a file with
type UTF-16 that does not contain a valid UTF-16 BOM. If git-p4
attempts to retrieve the file then the process crashes with a
"Translation of file cont
On 09/21/2015 11:05 AM, Lars Schneider wrote:
I tried it on OS X 10.9.5 and on Ubuntu Linux 14.04.1 (sed version 4.2.2).
The “-i” option is mentioned in the GNU sed docs here:
https://www.gnu.org/software/sed/manual/sed.html
The OS X sed man page indeed lists “-i” as non-standard option:
https:
On 09/22/2015 01:55 AM, Junio C Hamano wrote:
Stefan Beller writes:
So if we get an EAGAIN or EWOULDBLOCK error the fd must be nonblocking.
As the intend of xread is to read as much as possible either until the
fd is EOF or an actual error occurs, we can ease the feeder of the fd
by not spinni
On 22.09.15 08:23, Jacob Keller wrote:
> On Mon, Sep 21, 2015 at 9:55 PM, Torsten Bögershausen wrote:
>> But in any case I suggest to xread() as it is, and not to change the
>> functionality
>> behind the back of the users.
>>
>>
>
> I don't thin
On 2015-09-27 13.19, René Scharfe wrote:
> Am 24.09.2015 um 23:08 schrieb Jeff King:
>> When we already know the length of a string (e.g., because
>> we just malloc'd to fit it), it's nicer to use memcpy than
>> strcpy, as it makes it more obvious that we are not going to
>> overflow the buffer (be
On 10/01/2015 04:51 AM, Jeff King wrote:
On Wed, Sep 30, 2015 at 01:00:56PM -0700, Junio C Hamano wrote:
Wow, my patch isn't even close to reasonable. I didn't realize because
we do not compile this code at all for non-Mac platforms. Sorry.
Perhaps the way we completely stub out the platform s
On 29.09.15 00:01, David Turner wrote:
>
(Not sure if this is the right thread to report on)
In file included from builtin/commit.c:20:
./refs.h:695:16: warning: redefinition of typedef 'ref_transaction_free_fn' is
a C11 feature
[-Wtypedef-redefinition]
typedef void (*ref_transaction_free_f
On 30.09.15 02:23, Jeff King wrote:
> On Tue, Sep 29, 2015 at 04:50:39PM -0700, Michael Blume wrote:
>
>> I see compile errors on my mac:
>>
This is my attempt, passing the test, but not fully polished.
diff --git a/builtin/init-db.c b/builtin/init-db.c
index 89f2c05..60b559c 100644
--- a/bui
On 03.10.15 18:50, David Turner wrote:
> On Sat, 2015-10-03 at 07:02 +0200, Torsten Bögershausen wrote:
>> On 29.09.15 00:01, David Turner wrote:
>>>
>> (Not sure if this is the right thread to report on)
>>
>> In file included from builtin/commit.c:20:
>>
On 03.10.15 18:54, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> On 30.09.15 02:23, Jeff King wrote:
>>> On Tue, Sep 29, 2015 at 04:50:39PM -0700, Michael Blume wrote:
>>>
>>>> I see compile errors on my mac:
>>>>
>>
>
On 2015-10-03 18.50, David Turner wrote:
> On Sat, 2015-10-03 at 07:02 +0200, Torsten Bögershausen wrote:
>> On 29.09.15 00:01, David Turner wrote:
>> (Not sure if this is the right thread to report on)
>>
>> In file included from builtin/commit.c:20:
>> ./refs.h
On 2015-10-04 05.37, Jeff King wrote:
> On Sat, Oct 03, 2015 at 11:12:13PM +0200, Torsten Bögershausen wrote:
>
>>> Hmph, Peff's quick-fix passed the original "CoNfIg" in &buf directly
>>> to probe_utf8_pathname_composition() without changing its si
On 04.10.15 20:06, larsxschnei...@gmail.com wrote:
> From: Lars Schneider
>
> The stats command works differently on OS X compared to Linux. Detect
> OS X and execute the appropriate assertions.
>
Is there a special need to use the stat() function at all ?
That's what I read in t1301-shared-rep
On 2015-10-06 00.59, Junio C Hamano wrote:
> * mr/worktree-list (2015-10-02) 7 commits
> - SQUASH???
> - worktree: add 'list' command
> - worktree: add details to the worktree struct
> - worktree: add a function to get worktree details
> - SQUASH???
> - worktree: refactor find_linked_symref f
On 2015-10-05 05.43, Jeff King wrote:
[]
The whole series looks good, cleans up my mess and passes t3910.
Thanks for that.
--
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/majord
On 06.10.15 00:59, Junio C Hamano wrote:
> * gr/rebase-i-drop-warn (2015-10-02) 2 commits
> - rebase-i: loosen over-eager check_bad_cmd check
> - rebase-i: explicitly accept tab as separator in commands
>
> "git rebase -i" had a minor regression recently, which stopped
> considering a line tha
On 06/02/2015 07:34 PM, Remi Lespinet wrote:
[]
Signed-off-by: Remi Lespinet
---
Documentation/git-am.txt | 16 +---
1 file changed, 13 insertions(+), 3 deletions(-)
diff --git a/Documentation/git-am.txt b/Documentation/git-am.txt
index 0d8ba48..d412f6b 100644
--- a/Documentation
On 2015-06-03 11.55, Ed Avis wrote:
> Jeff King peff.net> writes:
>
>> I would say the more "usual" way to use checkout like this
>> is to give specific paths. I.e., run "git status", say "oh, I need to
>> restore the contents of 'foo', but not 'bar'", and run "git checkout
>> foo". That works re
I checked the documentation of different commands. From what I've
seen, such indications either does not appear or are right after the
text. I agree that it's a good idea, but for the sake of consistency,
I'd rather use one of these two format as long as it's ok for you.
After re-checking: OK f
On 2015-06-04 13.00, Ed Avis wrote:
>
> >Updates files in the working tree to match...
I think that this had been written with
"git checkout " in mind, which is different
from "git checkout -- " (or "git checkout .")
Do you think you can write a patch to improve the documentation ?
--
To
git checkout can be used to revert changes in the working tree.
Signed-off-by: Torsten Bögershausen
---
My first attempt to improve the documentation
Documentation/git-checkout.txt | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/Documentation/git-checkout.txt b
On 2015-06-09 16.07, Sascha Ziemann wrote:
> I tried to compile git 2.4.3 on Solaris 10. I used the following
> configuration:
>
> $ ./configure --without-iconv
>
> $ grep -i iconv config.status
> ac_cs_config="'--without-iconv'"
> set X /bin/bash './configure' '--without-iconv'
> $ac_configu
On 2015-06-10 17.05, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
(Need to drop Eric from CC-list(
>> git checkout can be used to revert changes in the working tree.
>
> I somehow thought that concensus in the recent thread was that
> "restore", not &q
On 2015-06-12 06.49, Scott Schmit wrote:
> 'git checkout' with or `--patch` is used to restore modified or
> deleted paths to their original contents from the index or replace paths
> with the contents from a named (most often a commit-ish)
> instead of switching branches.
---
I w
On 2015-06-15 10.50, Jan-Philip Gehrcke wrote:
> Hello,
>
> I was surprised to see that the output of
>
> git log --encoding=utf-8 "--format=format:%b"
>
> can contain byte sequences that are invalid in UTF-8. Note: I am using git
> 2.1.4 and the %b format specifier represents the commit me
On 2015-06-16 11.38, Jan-Philip Gehrcke wrote:
> On 15.06.2015 18:21, Torsten Bögershausen wrote:
>> On 2015-06-15 10.50, Jan-Philip Gehrcke wrote:
>>> Let me describe what I think it currently does:
>>>
>>> The program attempts to re-code a log message, so i
git checkout can be used to reset changes in the working tree.
Signed-off-by: Torsten Bögershausen
---
Version 2: Try to summarize the suggestions from the mailing list
Documentation/git-checkout.txt | 6 +-
1 file changed, 5 insertions(+), 1 deletion(-)
diff --git a/Documentation/git
On 2015-06-17 17.29, Junio C Hamano wrote:
> Matthieu Moy writes:
>
>> Yes, but "Switch branchs or discard local changes" still does not
>> describe "git checkout HEAD^^^ -- file.txt" (restore to an old state,
>> but does not switch branch) or "git checkout -- file.txt" (get from the
>> index).
>
On 2015-06-17 18.19, Junio C Hamano wrote:
> Junio C Hamano writes:
>
>> Matthieu Moy writes:
>>
>>> Yes, but "Switch branchs or discard local changes" still does not
>>> describe "git checkout HEAD^^^ -- file.txt" (restore to an old state,
>>> but does not switch branch) or "git checkout -- fil
On 2015-06-17 21.23, Junio C Hamano wrote:
[]
>> Basically, I'm fine with anything starting with "Switch branches or",
>> but please do change the headline ;-).
>
> Likewise; I agree "switch branches or" part is good.
How about this:
git-checkout - Switch branches or restore changes to the worki
> * just make this more clear in the docs and/or
> * should we adjust the behavior of --encoding or
> * should we do something entirely different, like adding a new command line
> option or
The general spirit is to keep things backwards compatible, so that users which
expect the "raw" (and possible
On 06/21/2015 04:16 PM, Robert Dailey wrote:
On Sun, Jun 21, 2015 at 9:04 AM, Robert Dailey wrote:
Upon inspection of the gitattributes documentation page here:
https://git-scm.com/docs/gitattributes
When comparing the documentation for 'text' with 'eol', I see the
following missing explanatio
On 2015-06-22 18.11, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> eol=lf or eol=crlf are the only useful settings.
>> Everything else is ignored because it does not make sense.
>>
>> See convert.c:
>> static enum eol git_path_check_eol()
&
On 2015-06-25 16.50, Caio Marcelo de Oliveira Filho wrote:
> +test_expect_success 'commit.signoff config option' '
> + test_config commit.signoff true &&
> + echo "yet another content *narf*" >> foo &&
Minor nit:
The > or >> should be written without a space, like this:
>>foo
--
To unsub
;), path);
Implement a wrapper function xopen() that does the above so that we can
save a few lines of code, and make the die() messages consistent.
Helped-by: Torsten Bögershausen
Helped-by: Jeff King
Signed-off-by: Paul Tan
---
git-compat-util.h | 1 +
wrapper.c | 25
> * js/rebase-i-clean-up-upon-continue-to-skip (2015-06-23) 2 commits
> - rebase -i: do not leave a CHERRY_PICK_HEAD file behind
> - t3404: demonstrate CHERRY_PICK_HEAD bug
>
> Abandoning an already applied change in "git rebase -i" with
> "--continue" left CHERRY_PICK_HEAD and confused later
On 2015-06-30 16.12, Thomas Vieten wrote:
> We face a very inconvenient problem with end-of-line diffs which are not
> "real".
> We know the end-of-line problem very well as we thought.
> But now we found a new phenomenon and nobody mentioning it.
>
> Consider the following repository structure:
On 2015-06-30 16.34, Karsten Blees wrote:
> Renaming to an existing file doesn't work on Windows network shares if the
> target file is open.
>
> munmap() the old config file before commit_lock_file.
>
> Signed-off-by: Karsten Blees
> ---
>
> See https://github.com/git-for-windows/git/issues/22
On 07/01/2015 09:10 PM, Karsten Blees wrote:
Of course, it would be nice to hear other opinions as well - this
probably shouldn't be a discussion between the two of us :-)
Karsten
I like this paragraf from your previous mail, I think it can go
into i18n.txt "as is":
ISO-8859-x file names may
On 2015-07-02 16.00, Thomas Vieten wrote:
[]
> see the file attachend to the end of this message
Thanks for the info
>
>> It may be, that you need to "nornalize" your repo:
>>
> in principle we know all this.
> What is remarkable that we are able to checkout a version of master which is
> not consi
On 2015-07-06 21.25, Joey Hess wrote:
> joey@darkstar:~/tmp>git init --shared=world testrepo
> Initialized empty shared Git repository in /home/joey/tmp/testrepo/.git/
> joey@darkstar:~/tmp>grep shared testrepo/.git/config
> sharedrepository = 2
>
> This magic value of 2 seems to be undocum
On 07.07.15 08:40, saur...@stockal.com wrote:
> Hi,
>
> Please let me know whether Git supports directory level access or not.
>
> For example :- Consider the structure with one repository consisting of sub
> directories for each product.
> main_repo:
>dir1 dir
>dir2 dir
>shared-dir
#!/usr/bin/perl
Should we have hard-coded PATH to perl here ?
/usr/bin/perl --version
This is perl, v5.10.0 built for darwin-thread-multi-2level
(with 2 registered patches, see perl -V for more detail)
> +
> +my $is_passing = Test::More->builder->is_passing;
> +exit($is_passing ? 0 : 1);
>
Thi
(Thanks for the quick reply.
Sorry for the noise about
#!/usr/bin/perl
of course we call the right perl)
The new patch seems to be integrated in pu (I tested d08caa8e022f08d)
Test seems to pass, but some noise is on the channel:
Initialized empty Git repository in
/Users/tb/NoBackup/projects/gi
On 2015-07-07 18.06, Karthik Nayak wrote:
> Add a test suite for testing the ref-filter APIs used
> by for-each-ref. We just intialize the test suite for now.
> More tests will be added in the following patches as more
> options are added to for-each-ref.
>
> Based-on-patch-by: Jeff King
> Mentor
On 2015-07-08 12.38, Nguyễn Thái Ngọc Duy wrote:
> Side note, I almost added the third has_non_ascii() function. Maybe we
> should consider merging the two existing has_non_ascii() functions
> back, or rename one to something else.
>
Side question:
has_non_ascii can mean different things:
UTF-8,
(I haven't been able to do more debugging yet,
but this doesn't fully work on my Mac OS X box:)
Initialized empty Git repository in
/Users/tb/NoBackup/projects/git/tb.150714_Duy_grep_utf8/t/trash
directory.t7812-grep-icase-non-ascii/.git/
# lib-gettext: Found 'is_IS.UTF-8' as an is_IS UTF-8 locale
thing like this:
commit a1cdac0fc0df1dad20f4dc196688a73c11b00480
Author: Torsten Bögershausen
Date: Wed Jul 15 21:43:47 2015 +0200
t7812: More LIBPCRE preconditions
Some (e.g. BSD based) regex libraries are not able to handle
UTF-8 strings case-insensitive (if asked so)
Ex
There is a conflict in pu:
"jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index"
(And currently pu didn't compile)
(I will hopefully be able to do a separate review of the smudge/clean patch)
(And jo...@joeyh.name is not reachable from web.de)
--
To unsubscribe from t
On 06/21/2016 08:39 PM, Junio C Hamano wrote:
Armin Kunaschik writes:
On Tue, May 31, 2016 at 7:51 AM, Junio C Hamano wrote:
Torsten Bögershausen writes:
diff --git a/t/t7800-difftool.sh b/t/t7800-difftool.sh
index 7ce4cd7..905035c 100755
--- a/t/t7800-difftool.sh
+++ b/t/t7800
On 22/06/16 23:09, Joey Hess wrote:
Torsten Bögershausen wrote:
There is a conflict in pu:
"jh/clean-smudge-annex" does not work together with "tb/convert-peek-in-index"
(And currently pu didn't compile)
I'm sending a v4 of jh/clean-smudge-annex that is rebase
>On 03.06.16 14:19, Nguyễn Thái Ngọc Duy wrote:
Minor problem:
t2028 fails, when the test is run from a directory that is
a softlink.
(In my case
/Users/tb/projects/git/git.pu
is a softlink to
/Users/tb/NoBackup/projects/git/git.pu/
[master (root-commit) 2519212] init
Author: A U Thor
1 fil
On 29.06.16 18:14, Junio C Hamano wrote:
> tbo...@web.de writes:
>
>> From: Torsten Bögershausen
>>
>> The following didn't work as expected:
>
> Sorry for being slow (not in response but in understanding), but
> let's examine the expectation first.
T
On 2016-07-02 00.11, Junio C Hamano wrote:
[snip]
diff --git a/read-cache.c b/read-cache.c
index a3ef967..c109b6d 100644
--- a/read-cache.c
+++ b/read-cache.c
@@ -163,7 +163,9 @@ static int ce_compare_data(const struct cache_entry *ce,
struct stat *st)
if (fd >= 0) {
uns
On 2016-07-06 16.57, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> At some point inside the merge, Git calls read-cache.c/ce_compare_data(),
>> to check if the path named "file" is clean.
>> According to the tree information, the path &quo
On 07/07/16 20:43, Junio C Hamano wrote:
Torsten Bögershausen writes:
This is the callstack:
merge-recursive.c/add_cacheinfo(unsigned int mode, const unsigned char *sha1,
const char *path, int stage, int refresh, int options)
{
struct cache_entry *ce;
ce
On 07/07/16 20:43, Junio C Hamano wrote:
> Torsten Bögershausen writes:
>
>> This is the call stack:
>>
>> merge-recursive.c/add_cacheinfo(unsigned int mode, const unsigned
char *sha1,
>>const char *path, int stage, int refresh, int options)
>
On 07/08/2016 06:36 PM, Junio C Hamano wrote:
Torsten Bögershausen writes:
I dunno. I really do not like that extra sha1 argument added all
over the callchain by this patch.
Or did you mean other calls to add_cacheinfo()?
I didn't mean too much - the whole call chain touches code
" yet, so
right now both topics are stalled and waiting for an action from
you.
Yes, the code looks good to me.
And the commit message does explain what is going on.
For my taste, these 3 lines don't explain too much,may be remove them ?
> The test update was taken from a series by Torsten
On 07/13/2016 12:20 AM, Joey Hess wrote:
Torsten Bögershausen wrote re jh/clean-smudge-annex:
The thing is that we need to check the file system to find .gitatttibutes,
even if we just did it 1 nanosecond ago.
So the .gitattributes is done 3 times:
-1 would_convert_to_git_filter_fd(
-2
On 07/14/2016 06:48 PM, Johannes Sixt wrote:
Am 30.06.2016 um 11:09 schrieb Jeff King:
+/*
+ * This is the max value that a ustar size header can specify, as it
is fixed
+ * at 11 octal digits. POSIX specifies that we switch to extended
headers at
+ * this size.
+ */
+#define USTAR_MAX_SIZE 07
On 07/15/2016 12:38 AM, Jeff King wrote:
On Thu, Jul 14, 2016 at 03:30:58PM -0700, Junio C Hamano wrote:
If we move to time_t everywhere, I think we'll need an extra
TIME_T_IS_64BIT, but we can cross that bridge when we come to it.
Likewise I think we'll need SIZE_T_IS_64BIT eventually (for
On 07/20/2016 12:01 AM, Lars Schneider wrote:
On 19 Jul 2016, at 23:33, Junio C Hamano wrote:
Lars Schneider writes:
Git writes --> 4 byte filename length
Git writes --> filename string
Why limit to 32GB? Perhaps NUL termination is more appropriate
here?
OK, I will use NUL terminatio
On 07/20/2016 11:47 PM, Pranit Bauva wrote:
Reimplement the `get_terms` and `bisect_terms` shell function in C and
add `bisect-terms` subcommand to `git bisect--helper` to call it from
git-bisect.sh .
In the shell version, the terms were identified by strings but in C
version its done by bit m
On 07/22/2016 05:49 PM, larsxschnei...@gmail.com wrote:
From: Lars Schneider
Git's clean/smudge mechanism invokes an external filter process for every
single blob that is affected by a filter. If Git filters a lot of blobs
then the startup time of the external filter processes can become a
si
On 07/25/2016 06:53 PM, Junio C Hamano wrote:
Pranit Bauva writes:
>>> +enum terms_defined {
>>> + TERM_BAD = 1,
>>> + TERM_GOOD = 2,
>>> + TERM_NEW = 4,
>>> + TERM_OLD = 8
>>> +};
>>> +
>>
>> What does TERM stand for ?
The terms (words) used to denote the newer an
On 07/27/2016 02:06 AM, larsxschnei...@gmail.com wrote:
From: Lars Schneider
Generate a more interesting large test file with random characters in
between and reuse this test file in multiple tests. Run tests formerly
marked as EXPENSIVE every time but with a smaller test file.
Signed-off-by
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<
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
> >>
> >> packet_flush() would die in case of a write error ev
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 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 not
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-06 00.06, Junio C Hamano wrote:
> Torsten Bögershausen 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 and a flush packet at the end.
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 you, and I do not pa
Any idea about any possible races?
Just to double-check: I assume that you have this
commit ded2444ad8ab8128cae2b91b8efa57ea2dd8c7a5
Author: Torsten Bögershausen
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
a) Update the machine ?
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 o
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 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
> 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 l
1 - 100 of 1315 matches
Mail list logo
