Re: [PATCHv2] run-command: detect finished children by closed pipe rather than waitpid

On 2015-11-20 22.08, Stefan Beller wrote: The patch looks good at first glance, one minor remark below: > > diff --git a/run-command.c b/run-command.c > @@ -1071,70 +1089,31 @@ static void pp_output(struct parallel_processes *pp) > > static int pp_collect_finished(struct parallel_processes

Re: [PATCH] http: fix some printf format warnings on 32-bit builds

On 2015-11-13 09.57, Eric Sunshine wrote: > On Fri, Nov 13, 2015 at 3:46 AM, Lars Schneider > wrote: >> On 11 Nov 2015, at 18:49, Ramsay Jones wrote: >>> On 11/11/15 02:00, Stefan Beller wrote: On Tue, Nov 10, 2015 at 5:22 PM, Eric

Re: [PATCH] http: fix some printf format warnings on 32-bit builds

>Ah. OK, so %ld for long and %lld for long long, I suppose. Only if you have a system that's support it. Linux does, Windows not. Hmm, not that it matters, but I wonder what the PRId64 macro is. ;-) It's "I64d" for Windows, and "lld" for all Gnu based systems and others, When you do

Re: Bug: t5813 failing on Cygwin

>> >> diff --git a/connect.c b/connect.c >> index 108f5ab..fc73cf9 100644 >> --- a/connect.c >> +++ b/connect.c >> @@ -636,6 +636,8 @@ static enum protocol parse_connect_url(const char >> *url_orig, char **ret_host, >> end = path; /* Need to \0 terminate host here */ >> if (separator ==

Re: [PATCH] run-command: detect finished children by closed pipe rather than waitpid

On 07.11.15 00:48, Stefan Beller wrote: > > +enum child_state { > + FREE, > + WORKING, > + WAIT_CLEANUP, > +}; This kind of "generic names" feels are begging for name clash, some day, may be in the future. How about something like this: > + GIT_CP_FREE, > + GIT_CP_WORKING,

Re: [PATCH 1/2] run-parallel: rename set_nonblocking to set_nonblocking_or_die

On 11/04/2015 11:43 PM, Stefan Beller wrote: Discussion turned out a warning is not enough, but we need to die in case of blocking output as we can lockup the child processes. Junio wrote: Imagine that we are running two things A and B at the same time. We ask poll(2) and it says both A and B

Re: O_NONBLOCK under Windows (was: git.git as of tonight)

On 11/04/2015 12:00 AM, Stefan Beller wrote: > On Tue, Nov 3, 2015 at 1:03 PM, Johannes Sixt wrote: > The #ifdef assumes that Windows never will have O_NONBLOCK/F_GETFL) Does the following make more sense ? #if defined (O_NONBLOCK) && defined (F_GETFL) Or may be: #ifndef

Re: [PATCH 1/2] Limit the size of the data block passed to SHA1_Update()

On 11/03/2015 07:58 AM, atous...@gmail.com wrote: From: Atousa Pahlevan Duprat Minor comments inline diff --git a/block-sha1/sha1.h b/block-sha1/sha1.h index b864df6..d085412 100644 --- a/block-sha1/sha1.h +++ b/block-sha1/sha1.h @@ -18,5 +18,5 @@ void

[PATCH v2] ls-files: Add eol diagnostics

-lf locale/XX.po Note that the output is meant to be human-readable and may change. When e.g. a file is deleted from the working tree and another file is a soft link, the output may look like this: ca:text-lf wt:text-lf Documentation/RelNotes/2.6.1.txt ca:text-lf Documentation/RelN

Re: [PATCH] ident.c: add support for IPv6

On 2015-10-30 15.48, Elia Pinto wrote: > Add IPv6 support by implementing name resolution with the Minor question: How is this related to IPV6? Could the header line be written something like "ident.c: Use getaddrinfo() instead of gethostbyname() if available" On which systems has the patch been

Re: t7063-status-untracked-cache.sh test failure on next

On 21.10.15 16:37, Ramsay Jones wrote: > Hi Junio, > > While testing the next branch today, I had a test failure, viz: > > $ tail ntest-out-fail > Test Summary Report > --- > t7063-status-untracked-cache.sh (Wstat: 256 Tests: 32 > Failed: 22)

Re: [PATCH] fix flaky untracked-cache test

On 19.10.15 21:48, David Turner wrote: > + echo test >base && #we need to ensure that the root dir is touched > + rm base > ' Thanks for working on this, (I can run the test as soon as I have access to a Mac with SSD) Minor remark, the echo test can be removed (and may be the comment ?)

Re: [PATCH] Add ls-files --eol-staged, --eol-worktree

On 18/10/15 21:00, Junio C Hamano wrote: Torsten Bögershausen <tbo...@web.de> writes: Make it possible to show the line endings of files. Files which are staged and/or files in the working tree: git ls-files --eol-staged git ls-files --eol-worktree Two unrelated (to the issues

[PATCH] Add ls-files --eol-staged, --eol-worktree

-files --eol-staged will give a line like this: Signed-off-by: Torsten Bögershausen <tbo...@web.de> --- This needs to go on top of tb/t0027-crlf builtin/ls-files.c | 21 + convert.c | 51 +-- convert.h

Re: [BUG] t7063-status-untracked-cache flaky?

I can't reproduce it here. Do you want to give us some info about your setup ? OS ? Harddisk, SSD, Fusion ? Does "debug=t verbose=t ./t7063-status-untracked-cache.sh >xx.txt 2>&1" give any more information ? On 15.10.15 09:52, Lars Schneider wrote: > Hi, > > I noticed that

Re: [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails

On 09.10.15 12:11, Johannes Schindelin wrote: > Me again, > > On 2015-10-09 11:50, Johannes Schindelin wrote: >> >> On 2015-10-09 03:40, Paul Tan wrote: >>> On Fri, Oct 9, 2015 at 8:52 AM, Junio C Hamano wrote: Johannes Schindelin writes:

[PATCH v2] t0027: Improve test for not-normalized files

eckout, so a warning NL->CRLF is given. Files with CRLF are not converted at all (so no warning will be given), unless they are marked as "text" or "auto". Remove repoMIX introduced in commit 8eeab92f02, and replace it with a combination of NNO tests. Signed-off-by: To

Re: [PATCH 0/2] Reinstate the helpful message when `git pull --rebase` fails

On 2015-10-09 12.11, Johannes Schindelin wrote: > Me again, > > On 2015-10-09 11:50, Johannes Schindelin wrote: >> >> On 2015-10-09 03:40, Paul Tan wrote: >>> On Fri, Oct 9, 2015 at 8:52 AM, Junio C Hamano wrote: Johannes Schindelin writes:

[PATCH] t0027: Improve test for not-normalized files

eckout, so a warning NL->CRLF is given. Files with CRLF are not converted at all (so no warning will be given), unless they are marked as "text" or "auto". Remove repoMIX introduced in commit 8eeab92f02, and replace it with a combination of NNO tests. Signed-off-by: Torsten Bö

Re: What's cooking in git.git (Oct 2015, #01; Mon, 5)

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

Re: What's cooking in git.git (Oct 2015, #01; Mon, 5)

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

Re: [PATCH 1/3] precompose_utf8: drop unused variable

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

Re: [PATCH v2 3/4] git-p4: Fix t9815 git-p4-submit-fail test case on OS X

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

Re: [PATCH v2 01/43] refs.c: create a public version of verify_refname_available

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: >> ./ref

Re: [PATCH 41/68] init: use strbufs to store paths

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 directly >>> to probe_utf8_pathname_composition() without changing its signature. >&

Re: [PATCH 41/68] init: use strbufs to store paths

On 03.10.15 18:54, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> 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:

Re: [PATCH v2 01/43] refs.c: create a public version of verify_refname_available

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: >&

Re: [PATCH 41/68] init: use strbufs to store paths

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

Re: [PATCH v2 01/43] refs.c: create a public version of verify_refname_available

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

Re: [PATCH 41/68] init: use strbufs to store paths

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 ---

Re: [PATCH 60/68] prefer memcpy to strcpy

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

Re: [PATCHv3 02/13] xread: poll on non blocking fds

On 22.09.15 08:23, Jacob Keller wrote: > On Mon, Sep 21, 2015 at 9:55 PM, Torsten Bögershausen <tbo...@web.de> wrote: >> But in any case I suggest to xread() as it is, and not to change the >> functionality >> behind the back of the users. >> >> > &

Re: [PATCHv3 02/13] xread: poll on non blocking fds

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

Re: [PATCH v3 1/2] git-p4: add test case for "Translation of file content failed" error

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:

Re: [PATCH v2 1/2] git-p4: add test case for "Translation of file content failed" error

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

Fwd: Re: [PATCH v3] git-p4: add "--path-encoding" option

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 <tbo...@web.de> To: larsxschnei...@gmail.com, git@vger.kern

Re: [PATCH v3] git-p4: add "--path-encoding" option

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" && >>> >> +

Re: [PATCH] git-p4: add "--path-encoding" option

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

Re: [PATCH v3] git-p4: add "--path-encoding" option

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

Re: [PATCH v4 2/4] path: optimize common dir checking

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 dtur...@twopensource.com --- path.c| 226

Re: [PATCH v14 03/13] utf8: add function to align a string into given strbuf

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 enum { +

Re: Re* OS X Yosemite make all doc fails

On 2015-08-26 19.42, Junio C Hamano wrote: Jeff S acornb...@gmail.com 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

Re: [PATCH v5] git-p4: Obey core.ignorecase when using P4 client specs.

On 08/25/2015 08:54 AM, Luke Diamand wrote: On 24/08/15 22:30, larsxschnei...@gmail.com wrote: From: Lars Schneider larsxschnei...@gmail.com 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

Re: [PATCH v2] git-p4: fix faulty paths for case insensitive systems

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 path. It looks

Re: git svn clone fails

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

Re: git svn clone fails

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

Re: [PATCH v3] http: add support for specifying the SSL version

(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 environment

Fwd: Re: [PATCH v5 3/5] clone: do not include authentication data in guessed dir

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)

Re: git blame breaking on repository with CRLF files

On 2015-08-10 20.48, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de 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 CRLF down to LF? Shouldn't

Re: git blame breaking on repository with CRLF files

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 anything. On some files in the repository I get

Re: Error when cloning with weird local directory

On 2015-08-06 09.50, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Torsten Bögershausen tbo...@web.de 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 directory structure looking like a .git

Re: git blame breaking on repository with CRLF files

tracked this down to the following commit: commit 4bf256d67a85bed1e175ecc2706322eafe4489ca (HEAD, refs/bisect/bad) Author: Torsten Bögershausen tbo...@web.de Date: Sun May 3 18:38:01 2015 +0200 blame: CRLF in the working tree and LF in the repo Digging further, it seems

Re: [PATCH v3 0/6] fix repo name when cloning a server's root

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 expose and

Re: Error when cloning with weird local directory

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'... fatal:

Re: [msysGit] Difficulties senting patches to Git list using msmpt (send-email)

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

Re: [PATCH v3 0/9] icase match on non-ascii

a1cdac0fc0df1dad20f4dc196688a73c11b00480 Author: Torsten Bögershausen tbo...@web.de 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) Exclude some test

Re: [PATCH v3 0/9] icase match on non-ascii

(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

Re: [PATCH v2 0/9] icase match on non-ascii

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,

Re: [PATCH v8 01/11] t6302: for-each-ref tests for ref-filter APIs

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 p...@peff.net

Re: [PATCH v8 07/10] send-email: reduce dependencies impact on parse_address_line

(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

Re: undocumented core.sharedRepository=2 set by git init --shared=world

On 2015-07-06 21.25, Joey Hess wrote: joey@darkstar:~/tmpgit init --shared=world testrepo Initialized empty shared Git repository in /home/joey/tmp/testrepo/.git/ joey@darkstar:~/tmpgrep shared testrepo/.git/config sharedrepository = 2 This magic value of 2 seems to be undocumented,

Re: Whether Git supports directory level access or not?

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 dir

Re: [PATCH v7 07/10] send-email: reduce dependencies impact on parse_address_line

#!/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); This

Re: end-of-line diff checkout direction dependence problem

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 consistent with

Re: [PATCH v2] Documentation/i18n.txt: clarify character encoding support

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

Re: [PATCH] config.c: fix writing config files on Windows network shares

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 bl...@dcon.de --- See

Re: end-of-line diff checkout direction dependence problem

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:

Re: What's cooking in git.git (Jun 2015, #06; Wed, 24)

* 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 steps.

Re: [PATCH v4 01/44] wrapper: implement xopen()

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 tbo...@web.de Helped-by: Jeff King p...@peff.net Signed-off-by: Paul Tan pyoka...@gmail.com --- git-compat-util.h | 1 + wrapper.c | 25

Re: 'eol' documentation confusion

On 2015-06-22 18.11, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de 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() That makes me wonder... The original

Re: [PATCH v2] commit: add commit.signoff config option

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 unsubscribe from

Re: 'eol' documentation confusion

On 06/21/2015 04:16 PM, Robert Dailey wrote: On Sun, Jun 21, 2015 at 9:04 AM, Robert Dailey rcdailey.li...@gmail.com 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

Re: [PATCH v2] git-checkout.txt: Document git checkout pathspec better

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 working tree

Re: Should the --encoding argument to log/show commands make any guarantees about their output?

* 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

[PATCH v2] git-checkout.txt: Document git checkout pathspec better

git checkout pathspec can be used to reset changes in the working tree. Signed-off-by: Torsten Bögershausen tbo...@web.de --- 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

Re: [PATCH v2] git-checkout.txt: Document git checkout pathspec better

On 2015-06-17 18.19, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: Matthieu Moy matthieu@grenoble-inp.fr 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

Re: [PATCH v2] git-checkout.txt: Document git checkout pathspec better

On 2015-06-17 17.29, Junio C Hamano wrote: Matthieu Moy matthieu@grenoble-inp.fr 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

Re: Should the --encoding argument to log/show commands make any guarantees about their output?

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 it follows the chain raw input - unicode

Re: Should the --encoding argument to log/show commands make any guarantees about their output?

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 message

Re: [PATCH] git-checkout.txt: Document git checkout pathspec better

On 2015-06-12 06.49, Scott Schmit wrote: 'git checkout' with paths 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 tree-ish (most often a commit-ish) instead of switching branches.

Re: [PATCH] git-checkout.txt: Document git checkout pathspec better

On 2015-06-10 17.05, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: (Need to drop Eric from CC-list( git checkout pathspec can be used to revert changes in the working tree. I somehow thought that concensus in the recent thread was that restore, not revert, is the more

[PATCH] git-checkout.txt: Document git checkout pathspec better

git checkout pathspec can be used to revert changes in the working tree. Signed-off-by: Torsten Bögershausen tbo...@web.de --- My first attempt to improve the documentation Documentation/git-checkout.txt | 5 +++-- 1 file changed, 3 insertions(+), 2 deletions(-) diff --git a/Documentation/git

Re: Suggestion: make git checkout safer

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 branch in mind, which is different from git checkout -- paths (or git checkout .) Do you think you can write a patch to improve the documentation ? --

Re: Suggestion: make git checkout safer

On 2015-06-03 11.55, Ed Avis wrote: Jeff King peff at 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 regardless of

Re: [PATCH/RFC v3 2/4] git-am.txt: add configuration section in git am documentation

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

Re: [PATCH/RFC v3 2/4] git-am.txt: add configuration section in git am documentation

On 06/02/2015 07:34 PM, Remi Lespinet wrote: [] Signed-off-by: Remi Lespinet remi.lespi...@ensimag.grenoble-inp.fr --- 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

Re: [PATCH/WIP 1/8] wrapper: implement xopen()

On 2015-05-27 15.33, Paul Tan wrote: A common usage pattern of open() is to check if it was successful, and die() if it was not: int fd = open(path, O_WRONLY | O_CREAT, 0777); if (fd 0) die_errno(_(Could not open '%s' for writing.), path); Implement a wrapper

[PATCH v2] blame: CRLF in the working tree and LF in the repo

-By: Stepan Kasal ka...@ucw.cz Signed-off-by: Torsten Bögershausen tbo...@web.de --- What happened to the test cases ? They where improved, but it turned out that they failed from time to time, both Windows and Mac OS. Spicing them with test_tick or other things didn't help, if they are run in a tight

Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo

On 28/04/15 09:28, Junio C Hamano wrote: Torsten Bögershausentbo...@web.de writes: What do you think about the following test cases for a V2 patch ? test_expect_success 'create blamerepo' ' test_create_repo blamerepo ( cd blamerepo printf testcase\r\n crlffile

Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo

On 04/27/2015 07:47 PM, Junio C Hamano wrote: Junio C Hamano gits...@pobox.com writes: I suspect (I haven't looked very carefully for this round yet to be sure, though) that it may turn out that the commit you are proposing to revert was a misguided attempt to fix a non issue, or to break

Re: [PATCH/RFC] blame: CRLF in the working tree and LF in the repo

On 04/27/2015 08:58 PM, Johannes Sixt wrote: Am 27.04.2015 um 08:11 schrieb Stepan Kasal: Git does not support CRLF as the internal line separator. If you commit file in binary mode with CRLF, you are on your own. When I commit my C source code files with CRLF into the repository (because I

Re: [PATCH v3 0/3] Improve robustness of putty detection

On 04/27/2015 12:04 AM, Junio C Hamano wrote: brian m. carlson sand...@crustytoothpaste.net writes: While I was adding tests, I noticed that we had a broken test due to the use of single quotes within a test, which resulted in the test always being skipped. Good eyes. While fixing the

[PATCH/RFC] blame: CRLF in the working tree and LF in the repo

Signed-off-by: Torsten Bögershausen tbo...@web.de --- Reference: https://github.com/git-for-windows/git/issues/105 Although the intention of 4d4813a5 is good, it breaks the usual EOL-handling for Windows. Until we have a better solution, we suggest to revert it. builtin/blame.c | 1

Re: bug report : 2.3.5 ssh repo not found

On 2015-04-25 07.57, Chris wrote: Hello, Using git version 2.3.5 with kernel 3.19.3-3-ARCH #1 SMP PREEMPT x86_64 I see the following error message when pulling or cloning a repo over ssh: git clone ssh://user@mydomain:/home/user/path/to/project.git Cloning into 'project'... ssh: Could

Re: [PATCH v2] t0027: Add repoMIX and LF_nul

On 2015-04-25 18.41, Junio C Hamano wrote: Torsten Bögershausen tbo...@web.de writes: new safer autocrlf handling: Check if eols in a file are converted at commit, when the file has CR (or CLLF) in the repo (technically speaking in the index). s/CLLF/CRLF/? (no need to resend

[PATCH v2] t0027: Add repoMIX and LF_nul

(): Checking out CRLF_nul and checking for eol coversion does not make much sense (CRLF will stay CRLF). Use the file LF_nul instead: It is handled a binary in auto modes, and when declared as text the LF may be replaced with CRLF, depending on the configuration Signed-off-by: Torsten Bögershausen tbo

Re: [PATCH v2 2/2] connect: improve check for plink to reduce false positives

On 2015-04-25 00.28, brian m. carlson wrote: The git_connect function has code to handle plink and tortoiseplink specially, as they require different command line arguments from OpenSSH. However, the match was done by checking for plink case-insensitively in the string, which led to false

[PATCH] t0027: Add repoMIX and LF_nul

(): Checking out CRLF_nul and checking for eol coversion does not make much sense (CRLF will stay CRLF). Use the file LF_nul instead: It is handled a binary in auto modes, and when declared as text the LF may be replaced with CRLF, depending on the configuration Signed-off-by: Torsten Bögershausen tbo

Re: [BUG] having 'plink' anywhere in the GIT_SSH environment variables sets putty = true

On 04/22/2015 09:12 PM, Patrick Sharp wrote: Johannes, You’re correct, looking back over it, I was pretty vague. In truth, we are not using Windows OR putty at all. Running git on an Ubuntu system, but we are setting the GIT_SSH environment variable to point to a shell script to use. Upon

Re: [BUG] Git does not convert CRLF=LF on files with \r not before \n

On 2015-04-21 15.51, Alexandre Garnier wrote: Here is a test: git init -q crlf-test cd crlf-test echo '* text=auto' .gitattributes git add .gitattributes git commit -q -m Normalize EOL echo -ne 'some content\r\nother \rcontent with CR\r\ncontent\r\nagain content with\r\r\n'

<    1   2   3   4   5   6   7   8   9   10   >