Re: [PATCH v2 4/5] convert: add support for 'checkout-encoding' attribute

> On 29 Dec 2017, at 18:28, Torsten Bögershausen <tbo...@web.de> wrote: > > I probably need to look at convert.c more closer, some other comments inline. > > > On Fri, Dec 29, 2017 at 04:22:21PM +0100, lars.schnei...@autodesk.com wrote: >> From: Lars Schne

Re: [PATCH 2/2] travis-ci: record and skip successfully built trees

> On 29 Dec 2017, at 21:16, SZEDER Gábor wrote: > > On Fri, Dec 29, 2017 at 9:03 PM, SZEDER Gábor wrote: > > Or print it in a different color? Maybe red? > > See: https://travis-ci.org/szeder/git/jobs/322247836#L622-L625 I

Re: [PATCH v2 1/5] strbuf: add xstrdup_toupper()

> On 29 Dec 2017, at 16:56, Torsten Bögershausen <tbo...@web.de> wrote: > > On Fri, Dec 29, 2017 at 04:22:18PM +0100, lars.schnei...@autodesk.com wrote: >> From: Lars Schneider <larsxschnei...@gmail.com> >> >> Create a copy of an existing string and mak

[PATCH v2 1/5] strbuf: add xstrdup_toupper()

From: Lars Schneider <larsxschnei...@gmail.com> Create a copy of an existing string and make all characters upper case. Similar xstrdup_tolower(). This function is used in a subsequent commit. Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- strbuf.c | 13 +++

[PATCH v2 2/5] utf8: add function to detect prohibited UTF-16/32 BOM

From: Lars Schneider <larsxschnei...@gmail.com> Whenever a data stream is declared to be UTF-16BE, UTF-16LE, UTF-32BE or UTF-32LE a BOM must not be used [1]. The function returns true if this is the case. This function is used in a subsequent commit. [1] http://unicode.org/faq/utf_bo

[PATCH v2 5/5] convert: add tracing for checkout-encoding

From: Lars Schneider <larsxschnei...@gmail.com> Add the GIT_TRACE_CHECKOUT_ENCODING environment variable to enable tracing for content that is reencoded with the checkout-encoding attribute. Signed-off-by: Lars Schneider <larsxschnei...@gmail.com> --- convert.c

[PATCH v2 4/5] convert: add support for 'checkout-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

[PATCH v2 3/5] utf8: add function to detect a missing UTF-16/32 BOM

From: Lars Schneider <larsxschnei...@gmail.com> If the endianness is not defined in the encoding name, then let's be strict and require a BOM to avoid any encoding confusion. The has_missing_utf_bom() function returns true if a required BOM is missing. The Unicode standard instructs to

[PATCH v2 0/5] convert: add support for different encodings

From: Lars Schneider <larsxschnei...@gmail.com> Hi, notable changes since v1: * In [1] Peff described a situation where you "couldn't checkout _away_ from" problems because of "die() in convert_to_git()". I fixed this and tried to replicate the situation with t

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

> On 29 Dec 2017, at 13:59, Torsten Bögershausen <tbo...@web.de> wrote: > > On 2017-12-28 17:14, Lars Schneider wrote:> >>> On 17 Dec 2017, at 18:14, Torsten Bögershausen <tbo...@web.de> wrote: >>> >>> On Mon, Dec 11, 2017 at 04:50:23PM +0100,

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

> On 17 Dec 2017, at 18:14, Torsten Bögershausen <tbo...@web.de> wrote: > > On Mon, Dec 11, 2017 at 04:50:23PM +0100, lars.schnei...@autodesk.com wrote: >> From: Lars Schneider <larsxschnei...@gmail.com> >> >> +`encoding` >> +^^ >> +

Re: [PATCH v3 3/4] travis-ci: save prove state for the 32 bit Linux build

> On 27 Dec 2017, at 22:42, SZEDER Gábor <szeder@gmail.com> wrote: > > On Wed, Dec 27, 2017 at 7:46 PM, Lars Schneider > <larsxschnei...@gmail.com> wrote: >>> + --volume "${HOME}/travis-cache:/tmp/travis-cache" \ >> >> I as

Re: [PATCH 2/2] travis-ci: record and skip successfully built trees

> On 28 Dec 2017, at 00:00, SZEDER Gábor <szeder@gmail.com> wrote: > > On Wed, Dec 27, 2017 at 8:15 PM, Lars Schneider > <larsxschnei...@gmail.com> wrote: >> >>> On 27 Dec 2017, at 17:49, SZEDER Gábor <szeder@gmail.com> wrote: >>> +

Re: [PATCH 2/2] travis-ci: record and skip successfully built trees

> On 28 Dec 2017, at 11:31, SZEDER Gábor <szeder@gmail.com> wrote: > > On Wed, Dec 27, 2017 at 8:35 PM, Lars Schneider > <larsxschnei...@gmail.com> wrote: >> >>> On 27 Dec 2017, at 17:49, SZEDER Gábor <szeder@gmail.com> wrote: > >>

Re: [PATCH 2/2] travis-ci: record and skip successfully built trees

> On 27 Dec 2017, at 17:49, SZEDER Gábor wrote: > > Travis CI dutifully builds and tests each new branch tip, even if its > tree has previously been successfully built and tested. This happens > often enough in contributors' workflows, when a work-in-progress > branch is

Re: [PATCH 2/2] travis-ci: record and skip successfully built trees

> On 27 Dec 2017, at 17:49, SZEDER Gábor wrote: > > Travis CI dutifully builds and tests each new branch tip, even if its > tree has previously been successfully built and tested. This happens > often enough in contributors' workflows, when a work-in-progress > branch is

Re: [PATCH v3 4/4] travis-ci: only print test failures if there are test results available

> On 27 Dec 2017, at 17:36, SZEDER Gábor wrote: > > When a build job running the test suite fails, our > 'ci/print-test-failures.sh' script scans all 't/test-results/*.exit' > files to find failed tests and prints their verbose output. However, > if a build job were to

Re: [PATCH v3 3/4] travis-ci: save prove state for the 32 bit Linux build

> On 27 Dec 2017, at 17:36, SZEDER Gábor wrote: > > This change follows suit of 6272ed319 (travis-ci: run previously > failed tests first, then slowest to fastest, 2016-01-26), which did > this for the Linux and OSX build jobs. Travis CI build jobs run the > tests

Re: [PATCH v3 2/4] travis-ci: don't install default addon packages for the 32 bit Linux build

> On 27 Dec 2017, at 17:36, SZEDER Gábor wrote: > > The 32 bit Linux build job compiles Git and runs the test suite in a > Docker container, while the additional packages (apache2, git-svn, > language-pack-is) are installed on the host, therefore don't have > any effect

Re: [PATCH v3 1/4] travis-ci: fine tune the use of 'set -x' in 'ci/*' scripts

> On 27 Dec 2017, at 17:36, SZEDER Gábor wrote: > > The change in commit 4f2636667 (travis-ci: use 'set -x' in 'ci/*' > scripts for extra tracing output, 2017-12-12) left a couple of rough > edges: > > - 'ci/run-linux32-build.sh' is executed in a Docker container and >

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

[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

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?

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: [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... "));

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

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

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..."));

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

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: 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: [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...")); >>

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

[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

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

> 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

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

[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

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

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

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

[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: [git-for-windows] Git for Windows v2.15.0-rc prerelease, was Re: [ANNOUNCE] Git v2.15.0-rc2

> On 28 Oct 2017, at 18:40, Johannes Schindelin <johannes.schinde...@gmx.de> > wrote: > > Hi Lars, > > On Fri, 27 Oct 2017, Lars Schneider wrote: > >>> On 27 Oct 2017, at 14:11, Lars Schneider <larsxschnei...@gmail.com> wrote: >>>

Re: [PATCH 4/6] t0021/rot13-filter: add packet_initialize()

> On 27 Oct 2017, at 04:57, Junio C Hamano wrote: > > Junio C Hamano writes: > >> It is fine to leave the original code broken at this step while we >> purely move the lines around, and hopefully this will be corrected >> in a later step in the series (I

Re: [git-for-windows] Git for Windows v2.15.0-rc prerelease, was Re: [ANNOUNCE] Git v2.15.0-rc2

> On 27 Oct 2017, at 14:11, Lars Schneider <larsxschnei...@gmail.com> wrote: > > >> On 21 Oct 2017, at 00:22, Johannes Schindelin <johannes.schinde...@gmx.de> >> wrote: >> >> Hi team, >> >> [cutting linux-kernel] >> >> O

Re: [git-for-windows] Git for Windows v2.15.0-rc prerelease, was Re: [ANNOUNCE] Git v2.15.0-rc2

> On 21 Oct 2017, at 00:22, Johannes Schindelin > wrote: > > Hi team, > > [cutting linux-kernel] > > On Fri, 20 Oct 2017, Junio C Hamano wrote: > >> A release candidate Git v2.15.0-rc2 is now available for testing >> at the usual places. > > The Git for Windows

Re: Consequences of CRLF in index?

> On 25 Oct 2017, at 19:13, Jonathan Nieder <jrnie...@gmail.com> wrote: > > Hi again, > > Lars Schneider wrote: >>> On 24 Oct 2017, at 20:14, Jonathan Nieder <jrnie...@gmail.com> wrote: > >>> In any event, you also probably want to de

Re: Consequences of CRLF in index?

> On 26 Oct 2017, at 09:09, Johannes Sixt wrote: > > Am 25.10.2017 um 14:19 schrieb Johannes Schindelin: >> I envy you for the blessing of such a clean C++ source that you do not >> have any, say, Unix shell script in it. Try this, and weep: >> $ printf 'echo

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.

Re: Minor man page weirdness?

> On 18 Oct 2017, at 05:21, Jeff King wrote: > > On Wed, Oct 18, 2017 at 11:34:31AM +0900, Junio C Hamano wrote: > >> -- >8 -- >> branch doc: sprinkle a few commas for readability >> >> The "--force" option can also be used when the named branch does not >> yet exist, and the

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

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

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

[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

[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

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