[PATCH v7 0/6] convert: add "status=delayed" to filter process protocol

"count" => 1 }, + 'invalid-delay.a' => { "requested" => 0, "count" => 1 }, ); sub rot13 { @@ -135,7 +142,13 @@ while (1) { foreach my $pathname ( sort keys %DELAY ) { if ( $DELAY{$pathname}{"requested"} >=

[PATCH v7 4/6] convert: put the flags field before the flag itself for consistent style

Suggested-by: Jeff King <p...@peff.net> Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- convert.c | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/convert.c b/convert.c index f1e168bc30..9907e3b9ba 100644 --- a/convert.c +++ b/convert.

[PATCH v7 1/6] t0021: keep filter log files on comparison

tatus=delayed" to filter process protocol'. Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- t/t0021-conversion.sh | 12 ++-- 1 file changed, 6 insertions(+), 6 deletions(-) diff --git a/t/t0021-conversion.sh b/t/t0021-conversion.sh index 161f560446..ff2424225b 1007

Re: [PATCH v6 6/6] convert: add "status=delayed" to filter process protocol

> On 27 Jun 2017, at 00:13, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >> ... > >>> I am wondering whose responsibility it will be to deal with a path >>> "list-available" r

[PATCH v7 5/6] convert: move multiple file filter error handling to separate function

Refactoring the filter error handling is useful for the subsequent patch 'convert: add "status=delayed" to filter process protocol'. In addition, replace the parentheses around the empty "if" block with a single semicolon to adhere to the Git style guide. Signed-of

[PATCH v7 3/6] t0021: write "OUT " only on success

rite "OUT " for "abort" and "error" responses, too, as their size is always zero. Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- t/t0021-conversion.sh | 6 +++--- t/t0021/rot13-filter.pl | 6 +++--- 2 files changed, 6 insertions(+), 6 deleti

Re: What's cooking in git.git (Sep 2017, #03; Fri, 15)

On 15 Sep 2017, at 07:58, Junio C Hamano wrote: > 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

Re: [PATCH v1] travis-ci: fix "skip_branch_tip_with_tag()" string comparison

; function with >> a broken string comparison. Fix it! >> >> Reported-by: SZEDER Gábor <szeder@gmail.com> >> Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> >> --- > > Thanks for the fix. > > 09f5e97 appears to be for the ls/travis-scr

[PATCH v1 2/2] entry.c: check if file exists after checkout

From: Lars Schneider <larsxschnei...@gmail.com> If we are checking out a file and somebody else racily deletes our file, then we would write garbage to the cache entry. Fix that by checking the result of the lstat() call on that file. Print an error to the user if the file does not

[PATCH v1 1/2] entry.c: update cache entry only for existing files

From: Lars Schneider <larsxschnei...@gmail.com> In 2841e8f ("convert: add "status=delayed" to filter process protocol", 2017-06-30) we taught the filter process protocol to delay responses. That means an external filter might answer in the first write_entry() ca

[PATCH v1 0/2] fix temporary garbage in the cache entry

From: Lars Schneider <larsxschnei...@gmail.com> Hi, in [1] Peff noticed that the delayed filter mechanism causes garbage in the cache entry for a brief moment during a delayed checkout process. The first patch fixes this issue. The second patch ensures that we don't write garbage in th

Re: lstat-ing delayed-filter output, was Re: playing with MSan

> On 05 Oct 2017, at 05:46, Jeff King wrote: > > On Wed, Oct 04, 2017 at 08:30:05PM +0100, Thomas Gummerer wrote: > >>> So I dunno. This approach is a _lot_ more convenient than trying to >>> rebuild all the dependencies from scratch, and it runs way faster than >>> valgrind.

git send-email does not work with Google anymore?!

chainreplyto = false suppresscc = self Apparently that stopped working today. I get this error: (mbox) Adding cc: Lars Schneider <larsxschnei...@gmail.com> from line 'From: Lars Schneider <larsxschnei...@gmail.com>' Password for 'smtp://larsxschnei.

Re: [PATCH v1 1/2] entry.c: update cache entry only for existing files

> On 06 Oct 2017, at 06:54, Jeff King wrote: > > On Fri, Oct 06, 2017 at 08:01:48AM +0900, Junio C Hamano wrote: > >>> But >>> I think we'd want to protect the read_blob_entry() call at the top of >>> the case with a check for dco->state == CE_RETRY. >> >> Yeah, I think that

Re: [PATCH v1 2/2] entry.c: check if file exists after checkout

> On 06 Oct 2017, at 06:56, Jeff King <p...@peff.net> wrote: > > On Fri, Oct 06, 2017 at 01:26:48PM +0900, Junio C Hamano wrote: > > ... >> -- >8 -- >> From: Lars Schneider <larsxschnei...@gmail.com> >> Date: Thu, 5 Oct 2017 12:44:07 +0200 >>

Re: [PATCH v1] convert: display progress for filtered objects that have been delayed

> On 04 Oct 2017, at 12:52, Lars Schneider <larsxschnei...@gmail.com> wrote: > > >> On 24 Aug 2017, at 21:40, Junio C Hamano <gits...@pobox.com> wrote: >> >> Lars Schneider <larsxschnei...@gmail.com> writes: >> >>> In 2841e8

Re: [PATCH v1] convert: display progress for filtered objects that have been delayed

> On 24 Aug 2017, at 21:40, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >> In 2841e8f ("convert: add "status=delayed" to filter process protocol", >> 2017-06-30) we taught the filter p

Re: [PATCH v1] convert: display progress for filtered objects that have been delayed

> On 04 Oct 2017, at 13:55, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >>> The delayed progress API is being simplified so I'll probably do a >>> bit of evil merge while merging this to 'pu'. >&

Minor man page weirdness?

Hi, I just noticed that a space between "-f" and "git" is missing in `man git-branch`. The space is present in "Documentation/git-branch.txt", though. I am using `man` version 1.6c on macOS. -f, --force Reset to if exists already. Without -fgit branch refuses to change

Re: [ANNOUNCE] Git for Windows 2.14.2(3)

> On 16 Oct 2017, at 20:59, Steve Hoelzer wrote: > > Johannes, > > On Mon, Oct 16, 2017 at 5:57 AM, Johannes Schindelin > wrote: >> Hi Steve, >> >> On Sun, 15 Oct 2017, Johannes Schindelin wrote: >> >>> On Fri, 13 Oct 2017, Steve Hoelzer

Re: [PATCH] pkt-line: re-'static'-ify buffer in packet_write_fmt_1()

> On 28 Aug 2017, at 06:11, Martin Ågren <martin.ag...@gmail.com> wrote: > > On 28 August 2017 at 01:23, Jeff King <p...@peff.net> wrote: >> On Sun, Aug 27, 2017 at 10:04:55PM +0200, Lars Schneider wrote: >> >>> I did run all tests under

Re: [PATCH v5 00/40] Add initial experimental external ODB support

> On 03 Aug 2017, at 10:18, Christian Couder wrote: > > ... > > * The "helpers" (registered commands) > > Each helper manages access to one external ODB. > > There are 2 different modes for helper: > > - Helpers configured using "odb..scriptCommand" are >

Re: [PATCH v5 11/40] odb-helper: add odb_helper_init() to send 'init' instruction

> On 03 Aug 2017, at 10:18, Christian Couder wrote: > > Let's add an odb_helper_init() function to send an 'init' > instruction to the helpers. This 'init' instruction is > especially useful to get the capabilities that are supported > by the helpers. > > So while

Re: [PATCH v5 12/40] t0400: add 'put_raw_obj' instruction to odb-helper script

> On 03 Aug 2017, at 10:18, Christian Couder wrote: > > To properly test passing objects from Git to an external odb > we need an odb-helper script that supports a 'put' > capability/instruction. > > For now we will support only sending raw blobs, so the > supported

Re: [PATCH v1 2/2] travis-ci: skip a branch build if equal tag is present

e redundant. OK, will fix. >> slows the testing. >> >> Add a function to detect this situation and skip the build the branch > > s/skip the build/skip building/ ? OK, will fix. >> if appropriate. Invoke this function on every build. >> >> Helped-by: Jun

Re: [PATCH 00/12] Clean up notes-related code around `load_subtree()`

> On 10 Sep 2017, at 09:39, Jeff King wrote: > > On Sun, Sep 10, 2017 at 06:45:08AM +0200, Michael Haggerty wrote: > >>> So nothing to see here, but since I spent 20 minutes scratching my head >>> (and I know others look at Coverity output and may scratch their heads >>> too), I

Re: [PATCH v2] sub-process: print the cmd when a capability is unsupported

> On 11 Sep 2017, at 05:27, Junio C Hamano wrote: > > Junio C Hamano writes: > >> I still think we would want to turn warning() to die(), but it >> probably is better to do so in a separate follow-up patch. That >> will give us a good place to record the

Re: SHA1 collision in production repo?! (probably not)

> On 31 Mar 2017, at 19:45, Jeff King <p...@peff.net> wrote: > > On Fri, Mar 31, 2017 at 10:35:06AM -0700, Junio C Hamano wrote: > >> Lars Schneider <larsxschnei...@gmail.com> writes: >> >>> Hi, >>> >>> I just got a report with t

macOS Git installer on SourceForge

Hi, one of my colleagues made me aware today that the macOS Git installer is hosted on SourceForge and advertised on the official git-scm page: https://git-scm.com/download/mac SourceForge had some bad press as they apparently bundled junkware in their downloads:

Re: What's cooking in git.git (Aug 2017, #05; Tue, 22)

On 22 Aug 2017, at 21:56, Junio C Hamano wrote: > 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

Re: [PATCH] pkt-line: re-'static'-ify buffer in packet_write_fmt_1()

> On 27 Aug 2017, at 21:09, Martin Ågren <martin.ag...@gmail.com> wrote: > > On 27 August 2017 at 20:21, Lars Schneider <larsxschnei...@gmail.com> wrote: >> >>> On 27 Aug 2017, at 09:37, Martin Ågren <martin.ag...@gmail.com> wrote: >>>

Re: [PATCH] pkt-line: re-'static'-ify buffer in packet_write_fmt_1()

> On 27 Aug 2017, at 09:37, Martin Ågren wrote: > > The static-ness was silently dropped in commit 70428d1a5 ("pkt-line: add > packet_write_fmt_gently()", 2016-10-16). As a result, for each call to > packet_write_fmt_1, we allocate and leak a buffer. Oh :-( Thanks for

Automatically delete branches containing accepted patches?

Hi, I have lots of git/git branches and once in a while some patches make it into git/git master. If this happens I would like to delete my branch with the patch automatically. That's not easily possible as the hashes on my branches are, of course, not the same as the hashes on git/git. How do

Re: [PATCH] pull: respect submodule update configuration

> On 21 Aug 2017, at 18:55, Stefan Beller wrote: > > On Mon, Aug 21, 2017 at 9:20 AM, Heiko Voigt wrote: > >>> So I am a bit curious to learn which part of this change you dislike >>> and why. >> >> I am also curious. Isn't this the same strategy we are

git-scm pages deliver outdated Git docs

Hi, looks like the git-scm pages deliver outdated Git docs (v2.13.1): https://git-scm.com/docs/git Is this intentional? If not, who should be contacted? Cheers, Lars

Re: git-scm pages deliver outdated Git docs

> On 31 Aug 2017, at 19:37, Jeff King <p...@peff.net> wrote: > > On Thu, Aug 31, 2017 at 09:28:35AM +0100, Lars Schneider wrote: > >> looks like the git-scm pages deliver outdated Git docs (v2.13.1): >> https://git-scm.com/docs/git >> >> Is this in

Re: [git-for-windows] [ANNOUNCE] Git for Windows 2.14.2(2)

> On 05 Oct 2017, at 22:02, Johannes Schindelin > wrote: > > Dear Git users, > > It is my pleasure to announce that Git for Windows 2.14.2(2) is available > from: > > https://git-for-windows.github.io/ > > Changes since Git for Windows v2.14.2 (September

Re: [RFC] Indicate that Git waits for user input via editor

> On 15 Nov 2017, at 18:51, Stefan Beller <sbel...@google.com> wrote: > > On Wed, Nov 15, 2017 at 7:08 AM, Lars Schneider > <larsxschnei...@gmail.com> wrote: >> Hi, >> >> Git gathers user input via text editor in certain commands (e.g. "git >&

[PATCH v3] launch_editor(): indicate that Git waits for user input

dow without even realizing that s/he needs to interact with another window before Git can proceed. To this user Git appears hanging. Show a message in the original terminal and get rid of it when the editor returns. Signed-off-by: Junio C Hamano <gits...@pobox.com> Signed-off-by: Lars

Re: git-p4: cloning with a change number does not import all files

> On 25 Nov 2017, at 21:35, Patrick Rouleau wrote: > > Hi, > > I created a git repository with these commands: > git p4 clone //perforce/path@123456 repo > cd repo > git p4 rebase > > Some files created before the change 123456 do not exist in git > history. I do see

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

> On 28 Nov 2017, at 00:05, Jeff King wrote: > > On Mon, Nov 27, 2017 at 08:09:32PM +, brian m. carlson wrote: > >>> Show a message in the original terminal and get rid of it when the >>> editor returns. >> [...] >> >> Sorry for coming to the topic so late, but it occurred

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

> On 28 Nov 2017, at 00:18, Junio C Hamano wrote: > > lars.schnei...@autodesk.com writes: > >> diff to v2: >>- shortened and localized the "waiting" message >>- detect "emacsclient" and suppress "waiting" message > > Thanks for moving this forward. > > >> +

Re: [PATCH v3] launch_editor(): indicate that Git waits for user input

hanging. >> >> Show a message in the original terminal and get rid of it when the >> editor returns. >> >> Signed-off-by: Junio C Hamano <gits...@pobox.com> >> Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> >> --- >> diff --git a

RFC: Native clean/smudge filter for UTF-16 files

Hi, I am working with a team that owns a repository with lots of UTF-16 files. Converting these files to UTF-8 is no good option as downstream applications require the UTF-16 encoding. Keeping the files in UTF-16 is no good option either as Git and Git related tools (e.g. GitHub) consider the

Re: [PATCH v2] launch_editor(): indicate that Git waits for user input

> On 17 Nov 2017, at 20:41, Eric Sunshine wrote: > > On Fri, Nov 17, 2017 at 8:51 AM, wrote: > >> + char *term = getenv("TERM"); >> + >> + if (term && strcmp(term, "dumb")) >> +

Re: [PATCH v2] launch_editor(): indicate that Git waits for user input

> On 17 Nov 2017, at 19:40, Junio C Hamano wrote: > > lars.schnei...@autodesk.com writes: > >> Junio posted the original version of this patch [1] as response to my RFC >> [2]. >> I took Junio's patch and slightly changed the commit message as well as the >> message printed

Re: [PATCH v2] launch_editor(): indicate that Git waits for user input

> On 20 Nov 2017, at 01:11, Junio C Hamano wrote: > > Kaartic Sivaraam writes: > However, it's not clear how much benefit you gain from stashing this away in a static variable. Premature optimization? >>> >>> The variable being

Re: [ANNOUNCE] Git Rev News edition 33

> On 22 Nov 2017, at 15:00, Christian Couder wrote: > > Hi everyone, > > The 33rd edition of Git Rev News is now published: > > https://git.github.io/rev_news/2017/11/22/edition-33/ > > Thanks a lot to all the contributors and helpers! > > Enjoy, > Christian,

[PATCH v4 1/2] refactor "dumb" terminal determination

From: Lars Schneider <larsxschnei...@gmail.com> Move the code to detect "dumb" terminals into a single location. This avoids duplicating the terminal detection code yet again in a subsequent commit. Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- cache.h

[PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

From: Lars Schneider <larsxschnei...@gmail.com> When a graphical GIT_EDITOR is spawned by a Git command that opens and waits for user input (e.g. "git rebase -i"), then the editor window might be obscured by other windows. The user may be left staring at the original Git termina

[PATCH v4 0/2] launch_editor(): indicate that Git waits for user input

From: Lars Schneider <larsxschnei...@gmail.com> Hi, I simplified the code and enabled the "Git is waiting for editor input" message only for "intelligent" terminals. The rational is, that today's novice Git users are likely to have an "intelligent" terminal.

Re: [PATCH v4 0/2] launch_editor(): indicate that Git waits for user input

> On 29 Nov 2017, at 19:35, Thomas Adam wrote: > > On Wed, Nov 29, 2017 at 03:37:50PM +0100, lars.schnei...@autodesk.com wrote: >> +if (print_waiting_for_editor) { >> +fprintf(stderr, _("hint: Waiting for your editor >> input...")); >>

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

> On 04 Dec 2017, at 18:26, Jeff King <p...@peff.net> wrote: > > On Sun, Dec 03, 2017 at 05:39:10PM +0100, Lars Schneider wrote: > >>>>> + fprintf(stderr, _("hint: Waiting for your editor >>>>> input..."));

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

> On 04 Dec 2017, at 18:32, Jeff King <p...@peff.net> wrote: > > On Sun, Dec 03, 2017 at 01:47:04PM +0100, Lars Schneider wrote: > >> I am on the fence here. I like consistency but I don't want to >> bother Git users. >> >> @Peff: Do you lea

[PATCH v1] progress: print progress output for all operations taking longer than 2s

From: Lars Schneider <larsxschnei...@gmail.com> In 180a9f2 we implemented a progress API which suppresses the progress output if the progress has reached a specified percentage threshold within a given time frame. In 8aade10 we simplified the API and set the threshold to 0% and the time

Re: RFC: Native clean/smudge filter for UTF-16 files

> On 24 Nov 2017, at 19:04, Jeff King <p...@peff.net> wrote: > > On Thu, Nov 23, 2017 at 04:18:59PM +0100, Lars Schneider wrote: > >> Alternatively, I could add a native attribute to Git that translates UTF-16 >> to UTF-8 and back. A conversion function is already

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

> On 04 Dec 2017, at 22:42, Jeff King <p...@peff.net> wrote: > > On Mon, Dec 04, 2017 at 10:31:15PM +0100, Lars Schneider wrote: > >>>> I would like to add "for your input" or "for you" to convey >>>> that Git is not waiting for the

Re: [PATCH 2/2] progress: drop delay-threshold code

> On 04 Dec 2017, at 23:07, Jeff King <p...@peff.net> wrote: > > From: Lars Schneider <larsxschnei...@gmail.com> > > Since 180a9f2268 (provide a facility for "delayed" progress > reporting, 2007-04-20), the progress code has allowed > callers to

Re: [PATCH v1] convert: add support for 'encoding' attribute

> On 15 Dec 2017, at 10:58, Jeff King <p...@peff.net> wrote: > > On Mon, Dec 11, 2017 at 04:50:23PM +0100, lars.schnei...@autodesk.com wrote: > >> From: Lars Schneider <larsxschnei...@gmail.com> >> >> Git and its tools (e.g. git diff) expec

Re: [PATCH 1/4] travis-ci: use 'set -x' in 'ci/*' scripts for extra tracing output

> On 12 Dec 2017, at 00:34, SZEDER Gábor wrote: > > While the build logic was embedded in our '.travis.yml', Travis CI > used to produce a nice trace log including all commands executed in > those embedded scriptlets. Since 657343a60 (travis-ci: move Travis CI > code into

Re: [PATCH v2 1/8] travis-ci: use 'set -x' in select 'ci/*' scripts for extra tracing

> On 16 Dec 2017, at 13:54, SZEDER Gábor wrote: > > While the build logic was embedded in our '.travis.yml', Travis CI > used to produce a nice trace log including all commands executed in > those embedded scriptlets. Since 657343a60 (travis-ci: move Travis CI > code into

Re: [PATCH v2 0/8] Travis CI cleanups

> On 16 Dec 2017, at 13:54, SZEDER Gábor wrote: > > This is a reroll of 'sg/travis-fixes'. > > Changes since the previous round: > > - Patch 1 got updated following the discussion: > > - I went with enabling tracing executed commands everywhere, > including the

Re: [PATCH v2 6/8] travis-ci: don't install 'language-pack-is' package

> On 16 Dec 2017, at 13:57, SZEDER Gábor wrote: > > Ever since we have started to use Travis CI in 522354d70 (Add Travis > CI support, 2015-11-27), our 64 bit Linux build jobs install the > 'languate-pack-is' package. That commit doesn't discuss why it was > deemed

Re: [PATCH v2 6/8] travis-ci: don't install 'language-pack-is' package

> On 18 Dec 2017, at 23:04, SZEDER Gábor <szeder@gmail.com> wrote: > > On Mon, Dec 18, 2017 at 10:33 PM, Lars Schneider > <larsxschnei...@gmail.com> wrote: >> >>> On 16 Dec 2017, at 13:57, SZEDER Gábor <szeder@gmail.com> wrote: >>

Re: [PATCH 1/4] travis-ci: use 'set -x' in 'ci/*' scripts for extra tracing output

> On 12 Dec 2017, at 19:43, SZEDER Gábor <szeder@gmail.com> wrote: > > On Tue, Dec 12, 2017 at 7:00 PM, Lars Schneider > <larsxschnei...@gmail.com> wrote: >> >>> On 12 Dec 2017, at 00:34, SZEDER Gábor <szeder@gmail.com> wrote: >&

Re: [PATCH 3/3] travis: run tests with GIT_TEST_SPLIT_INDEX

> On 12 Dec 2017, at 20:15, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >>> You're right, it's my first time using travis CI and I got confused >>> about how the .travis.yml works, thanks for cat

Re: [PATCH 3/3] travis: run tests with GIT_TEST_SPLIT_INDEX

> On 13 Dec 2017, at 18:38, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >> I think your solution points into the right direction. >> Right now we have the following test matrix: >> >> 1. L

Re: [PATCH v1] convert: add support for 'encoding' attribute

> On 12 Dec 2017, at 20:31, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >> Our favorite is "treat-encoding-as". Do you consider this better >> or worse than "checkout-encoding"? >

Re: [PATCH v2 3/3] travis: run tests with GIT_TEST_SPLIT_INDEX

hey tend to be much faster to > complete. > > The linux gcc build was chosen over the linux clang build because the > linux clang build is the fastest build, so it can serve as an early > indicator if something is broken and we want to avoid spending the extra > cycles of runn

Re: [PATCH v1] convert: add support for 'encoding' attribute

> On 13 Dec 2017, at 19:11, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >> ... In a perfect world I think I would store >> the encoding of a file in the tree object. I didn't pursue that solution >&g

Re: [PATCH] launch_editor(): indicate that Git waits for user input

> On 16 Nov 2017, at 15:58, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >>> On 16 Nov 2017, at 07:04, Junio C Hamano <gits...@pobox.com> wrote: >> >> Wow. Thanks for the quick patch :

Re: git send-email does not work with Google anymore?!

> On 23 Oct 2017, at 18:27, Dennis Kaarsemaker <den...@kaarsemaker.net> wrote: > > On Thu, 2017-10-05 at 12:52 +0200, Lars Schneider wrote: >> Hi, >> >> I used to use the Google SMTP server to send my patches to the list with >> the following config: &g

[PATCH v2] launch_editor(): indicate that Git waits for user input

dow without even realizing that s/he needs to interact with another window before Git can proceed. To this user Git appears hanging. Show a message in the original terminal and get rid of it when the editor returns. Signed-off-by: Junio C Hamano <gits...@pobox.com> Signed-off-by: Lars

Re: [PATCH] launch_editor(): indicate that Git waits for user input

> On 16 Nov 2017, at 07:04, Junio C Hamano wrote: Wow. Thanks for the quick patch :-) > When a graphical GIT_EDITOR is spawned by a Git command that opens > and waits for it for the user input (e.g. "git rebase -i") pops its > window elsewhere that is obscure, the user may

[RFC] Indicate that Git waits for user input via editor

Hi, Git gathers user input via text editor in certain commands (e.g. "git commit"). If you configure a text based editor, such as vi, then this works great as the editor is opened in your terminal window in the foreground and in focus. However, if you configure an editor that runs outside your

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

> On 07 Dec 2017, at 21:50, Junio C Hamano wrote: > > Todd Zullinger writes: > >> Johannes Schindelin wrote: >>> That is not the only thing going wrong: >>> >>> https://travis-ci.org/git/git/builds/312551566 >>> >>> It would seem that t9001 is broken

Re: git-p4: cloning with a change number does not import all files

> On 29 Nov 2017, at 04:48, Patrick Rouleau <proulea...@gmail.com> wrote: > > Hi, > > On Mon, Nov 27, 2017 at 7:52 AM, Lars Schneider > <larsxschnei...@gmail.com> wrote: >> >> what is your goal here? Do you want to convert the repo to Git or do you >

Re: What's cooking in git.git (Nov 2017, #08; Tue, 28)

> On 29 Nov 2017, at 02:17, Junio C Hamano wrote: > > * jc/editor-waiting-message (2017-11-17) 1 commit > - launch_editor(): indicate that Git waits for user input > > Git shows a message to tell the user that it is waiting for the > user to finish editing when spawning an

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

> On 30 Nov 2017, at 21:51, Jeff King wrote: > > On Wed, Nov 29, 2017 at 03:37:52PM +0100, lars.schnei...@autodesk.com wrote: > ... >> The standard advise() function is not used here as it would always add >> a newline which would make deleting the message harder. > > I tried to

Re: jn/reproducible-build, was Re: What's cooking in git.git (Nov 2017, #08; Tue, 28)

> On 01 Dec 2017, at 15:32, Johannes Schindelin > wrote: > > Hi Junio & Jonathan (Nieder, there is another active Jonathan again), > > On Wed, 29 Nov 2017, Junio C Hamano wrote: > >> * jn/reproducible-build (2017-11-22) 3 commits >> (merged to 'next' on

[PATCH v5 0/2] launch_editor(): indicate that Git waits for user input

From: Lars Schneider <larsxschnei...@gmail.com> Hi, Patch 1/2: No change. The patch got "looks good to me" from Peff [1] Patch 2/2: I changed the waiting message to our bikeshedding result [2] and I enabled the waiting message on dumb terminals for consistency

[PATCH v5 1/2] refactor "dumb" terminal determination

From: Lars Schneider <larsxschnei...@gmail.com> Move the code to detect "dumb" terminals into a single location. This avoids duplicating the terminal detection code yet again in a subsequent commit. Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- cache.h

[PATCH v5 2/2] launch_editor(): indicate that Git waits for user input

From: Lars Schneider <larsxschnei...@gmail.com> When a graphical GIT_EDITOR is spawned by a Git command that opens and waits for user input (e.g. "git rebase -i"), then the editor window might be obscured by other windows. The user might be left staring at the original Git termina

Re: [PATCH v5 2/2] launch_editor(): indicate that Git waits for user input

> On 07 Dec 2017, at 17:30, Junio C Hamano <gits...@pobox.com> wrote: > > Lars Schneider <larsxschnei...@gmail.com> writes: > >>> Can you squash that if you like it? > > I thought you also had to update the log message that you forgot to? > >

Re: [PATCH v5 2/2] launch_editor(): indicate that Git waits for user input

> On 07 Dec 2017, at 16:48, Lars Schneider <larsxschnei...@gmail.com> wrote: > > >> On 07 Dec 2017, at 16:43, Junio C Hamano <gits...@pobox.com> wrote: >> >> lars.schnei...@autodesk.com writes: >> ... > > How ab

Re: [PATCH v5 2/2] launch_editor(): indicate that Git waits for user input

> On 07 Dec 2017, at 18:37, Kaartic Sivaraam wrote: > > On Thursday 07 December 2017 10:00 PM, Junio C Hamano wrote: >> + >> +if (print_waiting_for_editor) { >> +/* >> + * A dumb terminal cannot erase the line later

Re: [PATCH v5 2/2] launch_editor(): indicate that Git waits for user input

> On 07 Dec 2017, at 16:43, Junio C Hamano wrote: > > lars.schnei...@autodesk.com writes: > >> +if (print_waiting_for_editor) { >> +fprintf(stderr, >> +_("hint: Waiting for your editor to close the >> file... "));

How to begin an error/die string? Upper- or lower-case letter?

Hi, error() and die() messages seems to begin with upper-case and lower-case letters in the Git code base: git grep 'error(_' | perl -nE 'say /.*error\(_\("(.).*/' | sort | uniq -c git grep 'die(_' | perl -nE 'say /.*die\(_\("(.).*/' | sort | uniq -c Do we prefer one way over the other?

[PATCH v1] convert: add support for 'encoding' attribute

From: Lars Schneider <larsxschnei...@gmail.com> Git and its tools (e.g. git diff) expect all text files in UTF-8 encoding. Git will happily accept content in all other encodings, too, but it might not be able to process the text (e.g. viewing diffs or changing line endings). Add an att

Re: [PATCH 2/2] progress: drop delay-threshold code

> On 05 Dec 2017, at 12:10, Ævar Arnfjörð Bjarmason <ava...@gmail.com> wrote: > > On Tue, Dec 5, 2017 at 11:37 AM, Lars Schneider > <larsxschnei...@gmail.com> wrote: >> >>> On 04 Dec 2017, at 23:07, Jeff King <p...@peff.net> wrote: >>&g

Re: [PATCH v1] convert: add support for 'encoding' attribute

On 11 Dec 2017, at 19:39, Eric Sunshine <sunsh...@sunshineco.com> wrote: > On Mon, Dec 11, 2017 at 10:50 AM, <lars.schnei...@autodesk.com> wrote: >> From: Lars Schneider <larsxschnei...@gmail.com> >> >> Git and its tools (e.g. git diff) expect a

Re: [PATCH v1] convert: add support for 'encoding' attribute

On 11 Dec 2017, at 21:47, Johannes Sixt <j...@kdbg.org> wrote: > Am 11.12.2017 um 16:50 schrieb lars.schnei...@autodesk.com: >> From: Lars Schneider <larsxschnei...@gmail.com> >> Git and its tools (e.g. git diff) expect all text files in UTF-8 >> encoding. Git w

Re: [PATCH v1] convert: add support for 'encoding' attribute

> On 12 Dec 2017, at 08:15, Johannes Sixt wrote: > > Am 12.12.2017 um 01:59 schrieb Junio C Hamano: >> Stepping back a bit, what does this thing do you are introducing? >> And what does the other thing do that J6t is using, that would get >> confused with this new one? >> What

Re: [PATCH v1] convert: add support for 'encoding' attribute

> On 12 Dec 2017, at 00:58, Eric Sunshine <sunsh...@sunshineco.com> wrote: > > On Mon, Dec 11, 2017 at 6:47 PM, Lars Schneider > <larsxschnei...@gmail.com> wrote: >> On 11 Dec 2017, at 19:39, Eric Sunshine <sunsh...@sunshineco.com> wrote: >>> On

Re: [PATCH 3/3] travis: run tests with GIT_TEST_SPLIT_INDEX

> On 11 Dec 2017, at 22:42, Thomas Gummerer wrote: > > On 12/11, SZEDER Gábor wrote: >>> Make sure that split index doesn't get broken, by running it on travis >>> CI. >>> >>> Run the test suite with split index enabled in linux 64 bit mode, and >>> leave split index

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

> On 02 Dec 2017, at 04:45, Kaartic Sivaraam <kaartic.sivar...@gmail.com> wrote: > > On Friday 01 December 2017 11:59 PM, Jeff King wrote: >> On Fri, Dec 01, 2017 at 01:52:14PM +0100, Lars Schneider wrote: >>> >>> Thanks for the review :-) >> Actu

Re: [PATCH v4 2/2] launch_editor(): indicate that Git waits for user input

> On 03 Dec 2017, at 06:15, Junio C Hamano wrote: > > Jeff King writes: > >> I tried to think of ways this "show a message and then delete it" could >> go wrong. It should work OK with editors that just do curses-like >> things, taking over the terminal and

Re: What's cooking in git.git (Dec 2017, #01; Mon, 4)

> On 04 Dec 2017, at 22:46, Junio C Hamano wrote: > > > * tb/check-crlf-for-safe-crlf (2017-11-27) 1 commit > - convert: tighten the safe autocrlf handling > > The "safe crlf" check incorrectly triggered for contents that does > not use CRLF as line endings, which has been

Re: Consequences of CRLF in index?

> On 24 Oct 2017, at 20:14, Jonathan Nieder <jrnie...@gmail.com> wrote: > > Hi, > > Lars Schneider wrote: > >> I've migrated a large repo (110k+ files) with a lot of history (177k commits) >> and a lot of users (200+) to Git. Unfortunately, all text files i

Consequences of CRLF in index?

Hi, I've migrated a large repo (110k+ files) with a lot of history (177k commits) and a lot of users (200+) to Git. Unfortunately, all text files in the index of the repo have CRLF line endings. In general this seems not to be a problem as the project is developed exclusively on Windows.

<    3   4   5   6   7   8   9   10   11   >