Re: Git for Windows v2.20.0-rc0

Just a quick note: I installed v2.20.0-rc0 with these options: $ cat /etc/install-options.txt Editor Option: VIM Custom Editor Path: Path Option: Cmd SSH Option: OpenSSH CURL Option: OpenSSL CRLF Option: CRLFCommitAsIs Bash Terminal Option: MinTTY Performance Tweaks FSCache: Enabled Use

Re: Strange bug with "git log" - pdftotext?

Am 30.07.2018 um 14:49 schrieb Jeremy Morton: > I'm trying to search my git log history for a particular term - "unobtrusive" > - so I run this command: > > git log -S unobtrusive --oneline > > When I do this, this is displayed and I'm in an interactive less terminal or > something: > >

Re: [ANNOUNCE] Git for Windows 2.15.1(2), was Re:Git for Windows 2.15.1

Am 30.11.2017 um 02:50 schrieb Johannes Schindelin: > Hi all, > > unfortunately, a last-minute bug slipped in: MSYS2 updated vim (including > its defaults.vim, in a way that interacted badly with Git for Windows' > configuration). The result was that an ugly warning is shown every time a > user

Bug or feature: format-patch breaks long subject lines

Hello list, git format-patch breaks (or better: word-wraps) long subject lines. This is on Windows 7 with $ git --version git version 2.14.2.windows.2 Reproduce with (some output omitted): -- $ git init

Re: [PATCH 0/2] Fix warnings on access of a remote with Windows paths

Am 20.05.2017 um 08:28 schrieb Johannes Sixt: > This small series fixes these warnings on Windows: > > C:\Temp\gittest>git fetch C:\Temp\gittest > warning: unable to access '.git/remotes/C:\Temp\gittest': Invalid argument > warning: unable to access '.git/branches/C:\Temp\gittest': Invalid

Re: [PATCH v2] perl: regenerate perl.mak if perl -V changes

Am 29.03.2017 um 15:33 schrieb Ævar Arnfjörð Bjarmason: > Change the perl/perl.mak build process so that the file is re-made if > the output of "perl -V" changes. > > Before this change updating e.g. /usr/bin/perl to a new major version > would cause the next "make" command to fail, since

Re: Viewing untracked+stashed files in git stash show

Am 16.03.2017 um 17:34 schrieb Okash Khawaja: > Hi, > > If you have some untracked files and your run `git stash -u`. Then > `git stash show` doesn't show the untracked files. Is there a flag > that can be passed to git stash show to report untracked files? Not for 'git stash' but you can use

Re: [RFC/PATCH] Makefile: add cppcheck target

Am 13.12.2016 um 10:32 schrieb Chris Packham: > On Tue, Dec 13, 2016 at 10:22 PM, Chris Packham > wrote: >> Add cppcheck target to Makefile. Cppcheck is a static >> analysis tool for C/C++ code. Cppcheck primarily detects >> the types of bugs that the compilers normally

Re: [ANNOUNCE] Git for Windows 2.11.0

Am 01.12.2016 um 13:31 schrieb Johannes Schindelin: > MIME-Version: 1.0 > > Fcc: Sent > > Dear Git users, > > It is my pleasure to announce that Git for Windows 2.11.0 is available from: > > https://git-for-windows.github.io/ > > Changes since Git for Windows v2.10.2 (November 2nd 2016)

Re: [ANNOUNCE] Prerelease: Git for Windows v2.11.0-rc0

Am 11.11.2016 um 19:33 schrieb Johannes Schindelin: > Hi Stefan, > > On Fri, 11 Nov 2016, Johannes Schindelin wrote: > >> Will keep you posted, > > I published the prerelease: > > https://github.com/git-for-windows/git/releases/tag/v2.11.0-rc0.windows.2 That version brings all my PATH entries

Re: [ANNOUNCE] Prerelease: Git for Windows v2.11.0-rc0

Am 05.11.2016 um 10:50 schrieb Johannes Schindelin: > Dear Git users, > > I finally got around to rebase the Windows-specific patches (which seem to > not make it upstream as fast as we get new ones) on top of upstream Git > v2.11.0-rc0, and to bundle installers, portable Git and MinGit [*1*]: >

Re: [PATCH v1] travis-ci: ask homebrew for the its path instead of hardcoding it

In the Subject: s/the // Am 21.09.2016 um 10:45 schrieb larsxschnei...@gmail.com: > From: Lars Schneider > > The TravisCI macOS build is broken because homebrew (a macOS depedency s/depedency/dependency/ > manager) changed its internal directory structure [1]. This

Re: [ANNOUNCE] Git for Windows 2.10.0

Am 03.09.2016 um 15:17 schrieb Johannes Schindelin: > Dear Git users, > > It is my pleasure to announce that Git for Windows 2.10.0 is available. > This time, I even blogged about it, primarily because I am so excited > about the speed improvements of rebase -i: > >

Re: Context Menu is missing

(and s/he did it againhitting "reply all" seems really complicated) Am 06.09.2016 um 10:07 schrieb Idan Shimoni: > it is part of git cheetah plugin not tortoise. > But it was part of the git installer for windows, I did not installed > anything else before. > > On Tue, Sep 6, 2016 at 10:54

Re: Context Menu is missing

(Please, please, please, use "reply all" in your mail reader i.e. make sure you don't remove 'git@vger.kernel.org' from the "To:" or "CC:" field. Thank you!) Am 06.09.2016 um 09:47 schrieb Idan Shimoni: > On Tue, Sep 6, 2016 at 10:33 AM, wrote: >> (Please

Re: Context Menu is missing

(Please don't top post and do "reply all") Am 06.09.2016 um 09:28 schrieb Idan Shimoni: > > On Tue, Sep 6, 2016 at 10:23 AM, wrote: >> Am 06.09.2016 um 09:12 schrieb Idan Shimoni: >>> Hi, >>> >>> The last install removed the old good context menu I used to

Re: Context Menu is missing

Am 06.09.2016 um 09:12 schrieb Idan Shimoni: > Hi, > > The last install removed the old good context menu I used to work with. > > Is that on purpose or is it a bug? is there any way to get it back? > You're working on a Cray system using git 1.3.2, right ? SCNR --

Re: [PATCH v11 28/40] builtin/apply: rename option parsing functions

Am 11.08.2016 um 10:52 schrieb Christian Couder: > As these functions are going to be part of the libified > apply api, let's give them a name that is more specific s/api/API/ ;-) > to the apply API. > > Signed-off-by: Christian Couder > --- > builtin/apply.c | 40

Re: [PATCH v10 01/40] apply: make some names more specific

Am 11.08.2016 um 10:40 schrieb Christian Couder: > On Tue, Aug 9, 2016 at 4:51 PM, wrote: >> Am 08.08.2016 um 23:02 schrieb Christian Couder: >>> To prepare for some structs and constants being moved from >>> builtin/apply.c to apply.h, we should give them some

Re: [PATCH v10 01/40] apply: make some names more specific

Am 08.08.2016 um 23:02 schrieb Christian Couder: > To prepare for some structs and constants being moved from > builtin/apply.c to apply.h, we should give them some more > specific names to avoid possible name collisions in th global s/th/the/ > namespace. > > Signed-off-by: Christian Couder

Re: [PATCH v10 28/40] builtin/apply: rename option parsing functions

Am 08.08.2016 um 23:03 schrieb Christian Couder: > As these functions are going to be part of the libified > apply api, let's give them a name that is more specific > to the apply api. s/api/API/ > > Signed-off-by: Christian Couder > --- > builtin/apply.c | 40

Re: [BUG] gitk

+cc: Paul Mackerras Am 08.06.2016 um 14:31 schrieb Eric Frederich: > Thanks for confirming. I do a similar workaround too. > The issue is when new Git users don't even have a ~/.config/git/gitk to > modify. > They first have to run it natively where lime exists, then they can > edit it and use

Re: [BUG] gitk

Am 08.06.2016 um 11:40 schrieb stefan.na...@atlas-elektronik.com: > Am 07.06.2016 um 21:20 schrieb Eric Frederich: >> Hello, >> >> I couldn’t find any documentation on submitting patches for gitk. >> I saw in Documentation/SubmittingPatches that gitk is maintained in >> its own repo. >> I can’t

Re: [BUG] gitk

Am 07.06.2016 um 21:20 schrieb Eric Frederich: > Hello, > > I couldn’t find any documentation on submitting patches for gitk. > I saw in Documentation/SubmittingPatches that gitk is maintained in > its own repo. > I can’t clone repo’s unless they’re http while on my corporate proxy. > I’m hoping

Re: [PATCH 1/4] diff.h: extend "flags" field to 64 bits because we're out of bits

Am 06.06.2016 um 13:16 schrieb Nguyễn Thái Ngọc Duy: > Current flags field is 32-bits, all used except one bit and we need one > more bit is needed for to toggle i-t-a behavior. The 9th bit could be Something's wrong here. Either drop the "is needed" or the "we need". > reused for this, but we

Re: [PATCH v1] travis-ci: build documentation

Am 22.04.2016 um 10:34 schrieb larsxschnei...@gmail.com: > From: Lars Schneider > > Run "make doc" to check if all documentation can be build without errors. s/build/built/ > Since the documentation is the same on every platform/compiler, the check > is only

Fwd: Re: Git config not working correctly with included configurations

Sorry, I thought this list has 'reply to all' set by default... Stefan Weitergeleitete Nachricht Betreff: Re: Git config not working correctly with included configurations Datum: Tue, 12 Apr 2016 13:56:57 +0200 Von: Näwe, Stefan An: Rudinei

Re: support block comments in gitconfig

Am 05.04.2016 um 04:19 schrieb Timothee Cour: > Could we have block comments in gitconfig? > It's a nice-to-have supported in most languages. > eg: > > #{ > commented out block > #} > > or other intuitive syntax Maybe not what you're looking for, but couldn't you use the include functionality

Re: [PATCH v2] Mark win32's pthread_exit() as NORETURN

Am 01.03.2016 um 15:13 schrieb Johannes Schindelin: > The pthread_exit() function is not expected to return. Ever. On Windows, > we call ExitThread() whose documentation claims: "This function does not > return a value.": Does this really mean that ExitThread() does not return ? Just

Zombie tag

I'm having trouble to get rid of a deleted tag. Here's what I did: - push master branch from a non-bare repo (R1) into a bare repo (B1) - push a tag (tag-a) from R1 into the same B1 - force-push master from another non-bare repo (R2) into B1 - do 'git push B1 :tag-a' from R2 to delete the tag

Re: Zombie tag

Am 21.01.2016 um 09:17 schrieb stefan.na...@atlas-elektronik.com: > I'm having trouble to get rid of a deleted tag. > Here's what I did: > > - push master branch from a non-bare repo (R1) into a bare repo (B1) > - push a tag (tag-a) from R1 into the same B1 > - force-push master from another

Re: Bug: Incorrect stripping of the [PATCH] prefix in git-am

Am 25.11.2015 um 16:29 schrieb huebbe: > Description: > > When applying a patch created via `git format-patch` with `git am`, > any prefix of the commit message that's within square brackets is stripped > from the commit message. As advertised in the man page of 'git am' (or 'git mailinfo' that

Re: opening an editor from git-gui on a file

Am 16.11.2015 um 08:58 schrieb Adam GROSZER: > Hi there, > > Hopefully sending the question/idea to the right list... > > I'm missing the feature to open a (configurable) editor with the > currently selected file in git gui. > > E.g. Looking at > >

about rev-parse's quietness

Hello there. I'm using a bash function that does a combination of 'ls -l', 'git status', and 'git branch' to give me a quick overview of where I stand in the current git repo. I planned to extend that function to also list the to-be-pushed commits in the current branch, something like $ git

[PATCH] gittutorial: fix output of 'git status'

From: Stefan Naewe stefan.na...@gmail.com 'git status' doesn't output leading '#'s these days. Signed-off-by: Stefan Naewe stefan.na...@gmail.com --- Documentation/gittutorial-2.txt | 23 --- Documentation/gittutorial.txt | 17 + 2 files changed, 21