Re: [PATCH 5/8] pathspec: convert strip_submodule_slash to take an index

Brandon Williams writes: > Signed-off-by: Brandon Williams > --- > pathspec.c | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) This conversion is not wrong per-se, but I wonder if there is a practical situation where we want to validate a

Re: [PATCH 4/8] pathspec: rename PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP

Brandon Williams writes: > Now that there is only a single flag which strips a submodule slash, > rename PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP to > PATHSPEC_STRIP_SUBMODULE_SLASH. This is a logical follow-up to the previous step.

Re: [PATCH 3/8] pathspec: change PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE flag

Brandon Williams writes: > It's confusing to have two different 'strip submodule slash' flags which > do subtly different things. Both > PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE and > PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP will accomplish the same task of > striping a slash

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

On Wed, May 10, 2017 at 12:33:44AM -0400, Jeff King wrote: > On Tue, May 09, 2017 at 09:22:11PM -0700, Shawn Pearce wrote: > > > > Hmm. That makes sense generally, as the request should succeed. But it > > > seems like we're creating a client that will sometimes succeed and > > > sometimes fail,

What's cooking in git.git (May 2017, #03; Wed, 10)

Here are the topics that have been cooking. Commits prefixed with '-' are only in 'pu' (proposed updates) while commits prefixed with '+' are in 'next'. The ones marked with '.' do not appear in any of the integration branches, but I am still holding onto them. Git 2.13, together with

[PATCH] config.mak.uname: set FREAD_READS_DIRECTORIES for Darwin, too

Let's do the same for Macs, as it is BSD variant after all. Signed-off-by: Junio C Hamano --- config.mak.uname | 1 + 1 file changed, 1 insertion(+) diff --git a/config.mak.uname b/config.mak.uname index a25ffddb3e..1743890164 100644 --- a/config.mak.uname +++

Re: [PATCH v2] add DEVELOPER makefile knob to check for acknowledged warnings

On Tue, May 02, 2017 at 03:22:23PM +0200, Ævar Arnfjörð Bjarmason wrote: > Is there any way with this to both supply CFLAGS & DEVELOPER=1 on the > command-line, to get my custom -O & these -W flags? I.e.: > > $ make DEVELOPER=1 V=1 > [...] -g -O2 -Wall -Werror -Wdeclaration-after-statement >

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

On Tue, May 9, 2017 at 9:33 PM, Jeff King wrote: > On Tue, May 09, 2017 at 09:22:11PM -0700, Shawn Pearce wrote: > >> > Hmm. That makes sense generally, as the request should succeed. But it >> > seems like we're creating a client that will sometimes succeed and >> > sometimes

Re: Script to rebase branches

On Tue, May 09, 2017 at 02:32:37PM +0200, Johannes Schindelin wrote: > > I didn't really expect anybody to use it verbatim, though. I was > > providing it more for inspiration. > > I deem it part of Git's mission is to avoid forcing everybody to write > scripts so specific to their own needs

Re: Script to rebase branches

On Wed, May 10, 2017 at 07:47:26AM +0900, Junio C Hamano wrote: > > Yes, the script predates the invention of worktrees by several years. I > > have occasionally played with worktrees, but don't use them extensively > > (I'd usually use them for a one-off change, and then remove the > >

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

On Tue, May 09, 2017 at 09:22:11PM -0700, Shawn Pearce wrote: > > Hmm. That makes sense generally, as the request should succeed. But it > > seems like we're creating a client that will sometimes succeed and > > sometimes fail, and the reasoning will be somewhat opaque to the user. > > I have a

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

On Tue, May 9, 2017 at 3:16 PM, Jeff King wrote: > On Tue, May 09, 2017 at 11:20:42AM -0700, Jonathan Tan wrote: > >> fetch-pack, when fetching a literal SHA-1 from a server that is not >> configured with uploadpack.allowtipsha1inwant (or similar), always >> returns an error

Schönen Tag

Hallo Ich bin Frau Victoria. G.Harry, ein Finanz-Manager für eine private Kreditvergabe Agentur, Uni Kredit Darlehen UK. Ich bin hier, um ein Darlehen Programm, das Ihnen helfen, Ihre finanzielle und wirtschaftliche Situation zu verbessern und entlasten Sie alle finanziellen Krise /

Re: [BUG] :(attr) pathspecs can die("BUG") in the tree-walker

On Tue, May 09, 2017 at 03:52:19PM -0700, Brandon Williams wrote: > > $ git log HEAD -- ':(attr:-diff)' > > fatal: BUG:tree-walk.c:947: unsupported magic 40 > > > > Whoops. This is presumably ls-tree is protected, but I think we are > > missing a GUARD_PATHSPEC call somewhere. > > > > This

Re: [ANNOUNCE] Git v2.12.3 and others

Junio C Hamano wrote: > Maintenance releases Git v2.4.12, v2.5.6, v2.6.7, v2.7.5, v2.8.5, > v2.9.4, v2.10.3, v2.11.2, and v2.12.3 have been tagged and are now > available at the usual places. > > These are primarily to fix a recently disclosed problem with "git > shell", which may allow a user

[ANNOUNCE] Git v2.12.3 and others

Maintenance releases Git v2.4.12, v2.5.6, v2.6.7, v2.7.5, v2.8.5, v2.9.4, v2.10.3, v2.11.2, and v2.12.3 have been tagged and are now available at the usual places. These are primarily to fix a recently disclosed problem with "git shell", which may allow a user who comes over SSH to run an

[ANNOUNCE] Git v2.13.0

The latest feature release Git v2.13.0 is now available at the usual places. It is comprised of 729 non-merge commits since v2.12.0, contributed by 65 people, 15 of which are new faces. This release also contains the security patch in v2.12.3 and others to fix CVE-2017-8386. The tarballs are

Re: [PATCH v2] travis-ci: retry if Git for Windows CI returns HTTP error 502 or 503

Lars Schneider writes: >>> It would be great if we could test this is a little bit in pu. >> >> This has been in 'pu' for a while. >> >> As the patch simply discards 502 (and others), it is unclear if the >> failing test on 'next' is now gone, or the attempt to run

Re: [PATCH] fixup! use perl instead of sed

On Wed, May 10, 2017 at 12:38 AM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > >> On Tue, May 9, 2017 at 6:45 PM, Jonathan Tan >> wrote: >> ... >>> # Tweak the push output to make the push option outside the

Re: [PATCH v2] archive-tar: fix a sparse 'constant too large' warning

Ramsay Jones writes: > Yeah, I had a similar comment in the commit message (but much more > verbose than your concise addition above), but I edited it several > times, without finding a wording that I liked. I eventually removed > it, because it didn't really add any

Re: [PATCH v2] archive-tar: fix a sparse 'constant too large' warning

Ramsay Jones writes: > In a similar vein, on systems which use a 64-bit representation of the > 'unsigned long' type, the USTAR_MAX_SIZE constant macro is defined with > the value 0777ULL. Although this does not cause any warning > messages to be issued, it

Re: [PATCH v2 00/21]

Duy Nguyen writes: > On Sun, May 7, 2017 at 11:20 AM, Junio C Hamano wrote: >> On Thu, May 4, 2017 at 2:45 PM, Junio C Hamano wrote: >>> >>> Nguyễn Thái Ngọc Duy writes: >>> >>> > Changes since v1: >>> > >>> > -

Re: [BUG] :(attr) pathspecs can die("BUG") in the tree-walker

On 05/09, Jeff King wrote: > I was playing with the new :(attr) pathspecs in the upcoming v2.13 > today, and noticed: > > $ git ls-files -- ':(attr:-diff)' > t/t0110/url-1 > t/t0110/url-10 > [etc] > > So far so good. > > $ git ls-tree HEAD -- ':(attr:-diff)' > fatal: :(attr:-diff):

Re: [PATCH v4 11/25] checkout: fix memory leak

Johannes Schindelin writes: >> > A leak is better than a use after free, so >> > let's be extra careful here. Would it leave the index inconsistent? Or >> > perhaps freeing it has become safe in the meantime? >> > >> > @Junio: Do you remember the reason for the

Re: Script to rebase branches

Jeff King writes: >> That requires Meta/ to be checked out and up-to-date. I'd bet there are >> exactly two people who fall into that category. > > Actually, it is not Junio's Meta that needs checked out, but rather the > "meta" branch where you will find that "rebase" script. If

Re: [PATCH] fixup! use perl instead of sed

Ævar Arnfjörð Bjarmason writes: > On Tue, May 9, 2017 at 6:45 PM, Jonathan Tan wrote: > ... >> # Tweak the push output to make the push option outside the cert >> # different, then replay it on a fresh dst, checking that ff is not >>

[BUG] :(attr) pathspecs can die("BUG") in the tree-walker

I was playing with the new :(attr) pathspecs in the upcoming v2.13 today, and noticed: $ git ls-files -- ':(attr:-diff)' t/t0110/url-1 t/t0110/url-10 [etc] So far so good. $ git ls-tree HEAD -- ':(attr:-diff)' fatal: :(attr:-diff): pathspec magic not supported by this command:

Re: [PATCH] fetch-pack: always allow fetching of literal SHA1s

On Tue, May 09, 2017 at 11:20:42AM -0700, Jonathan Tan wrote: > fetch-pack, when fetching a literal SHA-1 from a server that is not > configured with uploadpack.allowtipsha1inwant (or similar), always > returns an error message of the form "Server does not allow request for > unadvertised object

Re: [PATCH v3 00/53] object_id part 8

On 05/06, brian m. carlson wrote: > This is the eighth series of patches to convert unsigned char [20] to > struct object_id. This series converts lookup_commit, lookup_blob, > lookup_tree, lookup_tag, and finally parse_object to struct object_id. > > A small number of functions have temporaries

RE: git client debug with customer ssh client

On May 5, 2017 7:50 AM Pierre J. Ludwick wrote: > How can we get more info from git client? Any helps suggestions welcomed? It might be helpful to put a full trace in OpenSSH. Running ssh with -vvv should give you a lot of noise. I have used

Re: [PATCH] fixup! use perl instead of sed

On Tue, May 9, 2017 at 10:43 PM, Johannes Sixt wrote: > Am 09.05.2017 um 19:00 schrieb Ævar Arnfjörð Bjarmason: >> >> Finally, you can just use -i like you did with sed, no need for the >> tempfile: > > > Nope. Some implementations of perl attempt to remove the file that it has >

Re: [PATCH] fixup! use perl instead of sed

On 05/09/2017 01:43 PM, Johannes Sixt wrote: Am 09.05.2017 um 19:00 schrieb Ævar Arnfjörð Bjarmason: Finally, you can just use -i like you did with sed, no need for the tempfile: Nope. Some implementations of perl attempt to remove the file that it has just opened. That doesn't work on

[PATCH v3] fixup! don't use perl -i because it's not portable

Signed-off-by: Jonathan Tan --- Ah...thanks, Johannes, for spotting this. Here's a fixup. t/t5534-push-signed.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/t/t5534-push-signed.sh b/t/t5534-push-signed.sh index 177b933a7..807267b7f 100755

Re: [PATCH] fixup! use perl instead of sed

Am 09.05.2017 um 19:00 schrieb Ævar Arnfjörð Bjarmason: Finally, you can just use -i like you did with sed, no need for the tempfile: Nope. Some implementations of perl attempt to remove the file that it has just opened. That doesn't work on Windows. You have to supply a backup file name as

Re: [noob] is this normal behavior

Hi Harry, Both behaviours you report are normal, specifically: On 09/05/2017 15:02, Harry Putnam wrote: > Shouldn't files that changed but are already being tracked just show > up as modified and not need adding? > ... > Since that file is already being tracked; shouldn't `git status' show >

Re: [PATCH v2] archive-tar: fix a sparse 'constant too large' warning

On 09/05/17 11:24, Johannes Schindelin wrote: > Hi Ramsay, > > On Mon, 8 May 2017, Ramsay Jones wrote: > >> Commit dddbad728c ("timestamp_t: a new data type for timestamps", >> 26-04-2017) introduced a new typedef 'timestamp_t', as a synonym for an >> unsigned long, which was used at the time

Re: How to `git status' without scrambling modified with new, etc

Samuel Lijin writes: > You can use `git status -s` and match on the modification type (M > corresponds to modified, A to new files). See the man page for more > details on the interface. ahh yes. Just the ticket thanks

[PATCH v3 2/2] receive-pack: verify push options in cert

In commit f6a4e61 ("push: accept push options", 2016-07-14), send-pack was taught to include push options both within the signed cert (if the push is a signed push) and outside the signed cert; however, receive-pack ignores push options within the cert, only handling push options outside the cert.

[PATCH v3 0/2] Clarify interaction between signed pushes and push options

Changes from v2: - incorporated Junio's suggestions - incorporated Ævar's suggestions Jonathan Tan (2): docs: correct receive.advertisePushOptions default receive-pack: verify push options in cert Documentation/config.txt | 5 ++-

[PATCH v3 1/2] docs: correct receive.advertisePushOptions default

In commit c714e45 ("receive-pack: implement advertising and receiving push options", 2016-07-14), receive-pack was taught to (among other things) advertise that it understood push options, depending on configuration. It was documented that it advertised such ability by default; however, it

[PATCH 3/8] pathspec: change PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE flag

It's confusing to have two different 'strip submodule slash' flags which do subtly different things. Both PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE and PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP will accomplish the same task of striping a slash from a pathspec which matches a submodule entry in the

[PATCH 5/8] pathspec: convert strip_submodule_slash to take an index

Signed-off-by: Brandon Williams --- pathspec.c | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/pathspec.c b/pathspec.c index a1297ca02..cff069536 100644 --- a/pathspec.c +++ b/pathspec.c @@ -386,12 +386,13 @@ static const char

[PATCH 6/8] pathspec: convert find_pathspecs_matching_against_index to take an index

Signed-off-by: Brandon Williams --- builtin/add.c | 4 ++-- builtin/check-ignore.c | 2 +- pathspec.c | 10 ++ pathspec.h | 7 +-- 4 files changed, 14 insertions(+), 9 deletions(-) diff --git a/builtin/add.c b/builtin/add.c

[PATCH 7/8] pathspec: convert init_pathspec_item to take an index

Signed-off-by: Brandon Williams --- pathspec.c | 11 +++ 1 file changed, 7 insertions(+), 4 deletions(-) diff --git a/pathspec.c b/pathspec.c index bbd71b48b..c7ed8b3fb 100644 --- a/pathspec.c +++ b/pathspec.c @@ -430,7 +430,9 @@ static void

[PATCH 2/8] submodule: add die_in_unpopulated_submodule function

Currently 'git add' is the only command which dies when launched from an unpopulated submodule (the place-holder directory for a submodule which hasn't been checked out). This is triggered implicitly by passing the PATHSPEC_STRIP_SUBMODULE_SLASH_EXPENSIVE flag to 'parse_pathspec()'. Instead make

[PATCH 8/8] pathspec: convert parse_pathspec to take an index

Convert 'parse_pathspec()' to take an index parameter. Since the index is only needed when the PATHSPEC_SUBMODULE_LEADING_PATH and PATHSPEC_STRIP_SUBMODULE_SLASH flags are given, add a check requiring a non-NULL index when either of these flags are given. Convert callers which use these two flags

[PATCH 1/8] pathspec: provide a more descriptive die message

The current message displayed upon an internal error in 'init_pathspec_item()' isn't very descriptive and doesn't provide much context to where the error occurred. Update the error message to provide more context to where the error occured. Signed-off-by: Brandon Williams ---

[PATCH 0/8] convert pathspec.c to take an index parameter

This is another conversion series to convert the pathspec library code to take in an index parameter instead of relying on cache macros or on the global variable 'the_index'. While I was working in the pathspec code I thought it would be good to do a little more cleanup and make the API cleaner.

[PATCH 4/8] pathspec: rename PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP

Now that there is only a single flag which strips a submodule slash, rename PATHSPEC_STRIP_SUBMODULE_SLASH_CHEAP to PATHSPEC_STRIP_SUBMODULE_SLASH. Signed-off-by: Brandon Williams --- builtin/add.c | 2 +- builtin/check-ignore.c | 2 +- builtin/ls-files.c

[PATCH] fetch-pack: always allow fetching of literal SHA1s

fetch-pack, when fetching a literal SHA-1 from a server that is not configured with uploadpack.allowtipsha1inwant (or similar), always returns an error message of the form "Server does not allow request for unadvertised object %s". However, it is sometimes the case that such object is advertised.

Re: [PATCH v2] travis-ci: retry if Git for Windows CI returns HTTP error 502 or 503

> On 09 May 2017, at 07:31, Junio C Hamano wrote: > > Lars Schneider writes: > >> The Git for Windows CI web app sometimes returns HTTP errors of >> "502 bad gateway" or "503 service unavailable" [1]. We also need to >> check the HTTP content

Re: [PATCH] fixup! use perl instead of sed

On Tue, May 9, 2017 at 6:45 PM, Jonathan Tan wrote: > Signed-off-by: Jonathan Tan > --- > > Thanks - I didn't realize the existence of the test lint. Here's a > fixup. Let me know if you prefer a full reroll. > > I had to use perl because

[PATCH] fixup! use perl instead of sed

Signed-off-by: Jonathan Tan --- Thanks - I didn't realize the existence of the test lint. Here's a fixup. Let me know if you prefer a full reroll. I had to use perl because "push" is a binary file (the first line contains a NUL). t/t5534-push-signed.sh | 4 ++-- 1

Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #01; Mon, 1)

On Tue, May 9, 2017 at 4:22 PM, demerphq wrote: > On 9 May 2017 at 13:12, Ævar Arnfjörð Bjarmason wrote: >> On Tue, May 9, 2017 at 2:37 AM, brian m. carlson >> wrote: >>> On Tue, May 09, 2017 at 02:00:18AM +0200, Ævar Arnfjörð

Re: [GIT PULL] l10n updates for 2.13.0 round 2.1

Jiang Xin writes: > Merged another l10n contribution, please pull the new tag > l10n-2.13.0-rnd2.1 (old tag is deleted): Yeah, I see our mails crossed. Will pull. Thanks!

Re: [GIT PULL] l10n updates for 2.13.0 round 2

Jiang Xin writes: > Hi Junio, > > I can not send email outside at work, but now I am back home. Here is > the pull request: > > The following changes since commit 4fa66c85f11bc5a541462ca5ae3246aa0ce02e74: > > Git 2.13-rc2 (2017-05-04 16:27:19 +0900) > > are available

Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #01; Mon, 1)

On 9 May 2017 at 13:12, Ævar Arnfjörð Bjarmason wrote: > On Tue, May 9, 2017 at 2:37 AM, brian m. carlson > wrote: >> On Tue, May 09, 2017 at 02:00:18AM +0200, Ævar Arnfjörð Bjarmason wrote: > * gitweb is vulnerable to CPU DoS now in its default

Re: [GIT PULL] l10n updates for 2.13.0 round 2.1

Hi Junio, Merged another l10n contribution, please pull the new tag l10n-2.13.0-rnd2.1 (old tag is deleted): The following changes since commit 4fa66c85f11bc5a541462ca5ae3246aa0ce02e74: Git 2.13-rc2 (2017-05-04 16:27:19 +0900) are available in the git repository at:

[GIT PULL] l10n updates for 2.13.0 round 2

Hi Junio, I can not send email outside at work, but now I am back home. Here is the pull request: The following changes since commit 4fa66c85f11bc5a541462ca5ae3246aa0ce02e74: Git 2.13-rc2 (2017-05-04 16:27:19 +0900) are available in the git repository at: git://github.com/git-l10n/git-po

Re: [PATCH v4 11/25] checkout: fix memory leak

Hi Junio & René, On Mon, 8 May 2017, Junio C Hamano wrote: > René Scharfe writes: > > >>/* > >> * NEEDSWORK: > >> * There is absolutely no reason to write this as a blob object > >> - * and create a phony cache entry just to leak. This hack is > >> - * primarily

Re: Would this tool be useful - encoding repository data into single URL

On Tue, May 9, 2017 at 2:48 PM, Sebastian Gniazdowski wrote: > Hello > I wonder about usability of following tool. Quick-start: > > giturl https://github.com/zdharma/giturl -r devel -p > lib/coding_functions.cpp > > Protocol: https > Site: github.com >

Re: [PATCH v3 12/25] split_commit_in_progress(): fix memory leak

Hi René, On Sat, 6 May 2017, René Scharfe wrote: > Am 04.05.2017 um 12:59 schrieb Johannes Schindelin: > > > diff --git a/wt-status.c b/wt-status.c > > index 1f3f6bcb980..117ac8cfb01 100644 > > --- a/wt-status.c > > +++ b/wt-status.c > > @@ -1082,34 +1082,29 @@ static char

[noob] is this normal behavior

Setup: Running openindiana (hipster) a solaris 11 open source branch git 2.12.2 I've recently moved from mercurial to git mainly because git appears to receive the most development and the heaviest use. I'm using git with hold over behavior developed from my time using cvs long

RE: Add an option to automatically submodule update on checkout

On May 8, 2017 10:58 PM, Junio C Hamano wrote: >"Randall S. Becker" writes: >> I have to admit that I just assumed it would have to work that way >> this would not be particularly useful. However, in thinking about it, >> we might want to limit the depth of how far -b

Re: [PATCH v2 13/21] remote.c: report error on failure to fopen()

Hi Duy, On Tue, 9 May 2017, Duy Nguyen wrote: > Sorry for super late reply. I'm slowly catching up. > > On Wed, May 3, 2017 at 10:22 PM, Johannes Schindelin > wrote: > > Hi Duy, > > > > > > On Wed, 3 May 2017, Nguyễn Thái Ngọc Duy wrote: > > > >> There's plenty of

[PATCH v3 4/6] t3901: move supporting files into t/t3901/

The current convention is to either generate files on the fly in tests, or to use supporting files taken from a t/t/ directory (where matches the test's number, or the number of the test from which we borrow supporting files). The test t3901-i18n-patch.sh was obviously introduced before

[PATCH v3 3/6] completion: mark bash script as LF-only

Without this change, the completion script does not work, as Bash expects its scripts to have line feeds as end-of-line markers (this is particularly prominent in quoted multi-line strings, where carriage returns would slip into the strings as verbatim characters otherwise). This change is

[PATCH v3 5/6] Fix the remaining tests that failed with core.autocrlf=true

The test suite is mainly developed on Linux and MacOSX, which is the reason that nobody thought to mark files as LF-only as needed. The symptom is a test suite that fails left and right when being checked out using Git for Windows (which defaults to core.autocrlf=true). Mostly, the problems stem

[PATCH v3 6/6] t4051: mark supporting files as requiring LF-only line endings

The test t4051-diff-function-context.sh passes on Linux when core.autocrlf=true even without marking its support files as LF-only, but they fail when core.autocrlf=true in Git for Windows' SDK. The reason is that `grep ... >file.c.new` will keep CR/LF line endings on Linux (obviously treating CRs

Would this tool be useful - encoding repository data into single URL

Hello I wonder about usability of following tool. Quick-start:     giturl https://github.com/zdharma/giturl -r devel -p lib/coding_functions.cpp     Protocol: https     Site:     github.com     Repo:     zdharma/giturl     Revision: devel     File:     lib/coding_functions.cpp    

[PATCH v3 1/6] Fix build with core.autocrlf=true

On Windows, the default line endings are denoted by a Carriage Return byte followed by a Line Feed byte, while Linux and MacOSX use a single Line Feed byte to denote a line ending. To help with this situation, Git introduced several mechanisms over the last decade, most prominently the

[PATCH v3 2/6] git-new-workdir: mark script as LF-only

Bash does not handle scripts with CR/LF line endings correctly, therefore they *have* to be forced to LF-only line endings. Funnily enough, this fixes t3000-ls-files-others and t1021-rerere-in-workdir when git.git was checked out with core.autocrlf=true, as these test still use git-new-workdir

[PATCH v3 0/6] Abide by our own rules regarding line endings

Over the past decade, there have been a couple of attempts to remedy the situation regarding line endings (Windows/DOS line endings are traditionally CR/LF even if many current applications can handle LF, too, Linux/MacOSX/*BSD/Unix uses LF-only line handlings, and old MacOS software used to use

Re: [PATCH 0/1] Preserve the untracked cache across checkout, reset --hard, etc

On 5/9/2017 1:02 AM, Junio C Hamano wrote: David Turner writes: Can you actually keep the email address as my Twopensource one? I want to make sure that Twitter, my employer at the time, gets credit for this work (just as I want to make sure that my current

Re: Script to rebase branches

Hi Peff, On Tue, 9 May 2017, Jeff King wrote: > On Tue, May 09, 2017 at 12:50:22PM +0200, Johannes Schindelin wrote: > > > > This is what I use: > > > > > > https://github.com/peff/git/blob/meta/rebase > > > > > > There's no documentation in the script, but the commit message in its > > >

Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #01; Mon, 1)

On Tue, May 9, 2017 at 12:40 PM, Johannes Schindelin wrote: > Hi, > > On Tue, 9 May 2017, brian m. carlson wrote: > >> On Tue, May 09, 2017 at 02:00:18AM +0200, Ævar Arnfjörð Bjarmason wrote: >> > On Tue, May 9, 2017 at 1:32 AM, brian m. carlson >> >

Re: [PATCH v2 7/7] t4051: mark supporting files as requiring LF-only line endings

Hi Junio, On Mon, 8 May 2017, Junio C Hamano wrote: > Johannes Schindelin writes: > > > The test t4051-diff-function-context.sh passes on Linux when > > core.autocrlf=true even without marking its support files as LF-only, > > but they fail when core.autocrlf=true

Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #01; Mon, 1)

On Tue, May 9, 2017 at 2:37 AM, brian m. carlson wrote: > On Tue, May 09, 2017 at 02:00:18AM +0200, Ævar Arnfjörð Bjarmason wrote: >> On Tue, May 9, 2017 at 1:32 AM, brian m. carlson >> wrote: >> > PCRE and PCRE2 also tend to have a lot

Re: Script to rebase branches

On Tue, May 09, 2017 at 12:50:22PM +0200, Johannes Schindelin wrote: > > This is what I use: > > > > https://github.com/peff/git/blob/meta/rebase > > > > There's no documentation in the script, but the commit message in its > > history should give a good sense of what each part does. > >

Re: Script to rebase branches

Hi Peff, On Tue, 9 May 2017, Jeff King wrote: > On Sat, May 06, 2017 at 12:23:32PM +0200, Lars Schneider wrote: > > > I am about to write a bash/sh script that helps me to rebase a bunch of > > branches (e.g. select branches based on prefix, conflict resolution/ > > rerere support, ...). > >

Re: PCRE v2 compile error, was Re: What's cooking in git.git (May 2017, #01; Mon, 1)

Hi, On Tue, 9 May 2017, brian m. carlson wrote: > On Tue, May 09, 2017 at 02:00:18AM +0200, Ævar Arnfjörð Bjarmason wrote: > > On Tue, May 9, 2017 at 1:32 AM, brian m. carlson > > wrote: > > > PCRE and PCRE2 also tend to have a lot of security updates, so I > > >

Re: [PATCH v2] archive-tar: fix a sparse 'constant too large' warning

Hi Ramsay, On Mon, 8 May 2017, Ramsay Jones wrote: > Commit dddbad728c ("timestamp_t: a new data type for timestamps", > 26-04-2017) introduced a new typedef 'timestamp_t', as a synonym for an > unsigned long, which was used at the time to represent timestamps in > git. A later commit 28f4aee3fb

Re: [PATCH v2 00/21]

On Sun, May 7, 2017 at 11:20 AM, Junio C Hamano wrote: > On Thu, May 4, 2017 at 2:45 PM, Junio C Hamano wrote: >> >> Nguyễn Thái Ngọc Duy writes: >> >> > Changes since v1: >> > >> > - fopen_or_warn() and warn_on_fopen_errors() are

Re: [PATCH v2 13/21] remote.c: report error on failure to fopen()

Sorry for super late reply. I'm slowly catching up. On Wed, May 3, 2017 at 10:22 PM, Johannes Schindelin wrote: > Hi Duy, > > > On Wed, 3 May 2017, Nguyễn Thái Ngọc Duy wrote: > >> There's plenty of error() in this code to safely assume --quiet is not a >> concern. >>

Re: vger not relaying some of Junio's messages today?

Hi Brandon, On Mon, 8 May 2017, Brandon Williams wrote: > On 05/08, Johannes Schindelin wrote: > > > On Sat, 6 May 2017, Ævar Arnfjörð Bjarmason wrote: > > > > > I have one [script] to git am a patch from a msgid, thought I should > > > write something to handle a series in some DWIM fashion

Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required

On Tue, May 9, 2017 at 10:18 AM, Jean-Noël AVILA wrote: > Le jeudi 4 mai 2017, 10:14:58 CEST Kerry, Richard a écrit : >> >> My point was to ensure that where English is used on-screen it should make >> sense, which in this particular case it didn't (a French idiom which, on >>

Re: [PATCH v2 1/3] usability: don't ask questions if no reply is required

Le jeudi 4 mai 2017, 10:14:58 CEST Kerry, Richard a écrit : > > My point was to ensure that where English is used on-screen it should make > sense, which in this particular case it didn't (a French idiom which, on > using an automatic translator, didn't make sense in English). The same of >

Re: [PATCH 0/2] Make diff plumbing commands respect the indentHeuristic.

On Tue, May 09, 2017 at 09:58:28AM +0200, Ævar Arnfjörð Bjarmason wrote: > > Out of curiosity, how do you generate the patch-ids? Is it with > > something like diff-tree piped to patch-id? > > This: > > my $cmd = qq[git --git-dir="$repository_path" log --since="$since" > --until="$until"

Re: [PATCH 0/2] Make diff plumbing commands respect the indentHeuristic.

On Tue, May 9, 2017 at 5:16 AM, Jeff King wrote: > On Mon, May 01, 2017 at 12:34:38PM +0200, Ævar Arnfjörð Bjarmason wrote: > >> > I don't know if we would want to be extra paranoid about patch-ids. >> > There is no helping: >> > >> > git rev-list HEAD | git diff-tree --stdin -p

Re: [PATCH v2] travis-ci: retry if Git for Windows CI returns HTTP error 502 or 503

Lars Schneider writes: > The Git for Windows CI web app sometimes returns HTTP errors of > "502 bad gateway" or "503 service unavailable" [1]. We also need to > check the HTTP content because the GfW web app seems to pass through > (error) results from other Azure calls