Re: Git for Windows v2.20.0-rc0

[stefan.naewe]

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 Credential Manager: Enabled
Enable Symlinks: Disabled
Enable Builtin Rebase: Enabled
Enable Builtin Stash: Enabled



When starting the git bash two windows pop up instead of one.
One that's "empty" and the other one containing the real git bash.

Thanks,
  Stefan

Am 20.11.2018 um 21:56 schrieb Johannes Schindelin:
> Team,
> 
> On Sun, 18 Nov 2018, Junio C Hamano wrote:
> 
>> An early preview release Git v2.20.0-rc0 is now available for
>> testing at the usual places.  It is comprised of 887 non-merge
>> commits since v2.19.0, contributed by 71 people, 23 of which are
>> new faces.
> 
> The "for Windows" flavor of Git v2.20.0-rc0 is available here:
> 
> https://github.com/git-for-windows/git/releases/tag/v2.20.0-rc0.windows.1
> 
> The current change log for v2.20.0 reads like this:
> 
> Changes since Git for Windows v2.19.1 (Oct 5th 2018)
> 
> Please note: Git CMD is deprecated as of this Git for Windows version. The
> default is to have git.exe in the PATH anyway, so there is no noticeable
> difference between CMD and Git CMD. It is impossible to turn off CMD's
> behavior where it picks up any git.exe in the current directory, so let's
> discourage the use of Git CMD. Users who dislike Git Bash should switch to
> Powershell instead.
> 
> New Features
> 
>   • Comes with OpenSSH v7.9p1.
>   • The description of the editor option to choose Vim has been clarified
> to state that this unsets core.editor.
>   • Comes with cURL v7.62.0.
>   • The type of symlinks to create (directory or file) can now be
> specified via the .gitattributes.
>   • The FSCache feature now uses a faster method to enumerate files,
> making e.g. git status faster in large repositories.
>   • Comes with Git Credential Manager v1.18.3.
>   • Comes with Git LFS v2.6.0.
>   • Comes with MSYS2 runtime (Git for Windows flavor) based on Cygwin
> 2.11.2.
>   • The FSCache feature was optimized to become faster.
> 
> Bug Fixes
> 
>   • The 64-bit Portable Git no longer sets pack.packSizeLimit.
> 
> Thanks,
> Johannes
> 


-- 

/dev/random says: To save trouble later, Joe named his cat Roadkill Fred
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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:
> 
> pdftotext version 4.00
> Copyright 1996-2017 Glyph & Cog, LLC
> Usage: pdftotext [options]  []
>  -f  : first page to convert
>  -l  : last page to convert
>  -layout  : maintain original physical layout
>  -simple  : simple one-column page layout
>  -table   : similar to -layout, but optimized for tables
>  -lineprinter : use strict fixed-pitch/height layout
>  -raw : keep strings in content stream order
>  -fixed   : assume fixed-pitch (or tabular) text
>  -linespacing : fixed line spacing for LinePrinter mode
>  -clip    : separate clipped text
>  -nodiag  : discard diagonal text
>  -enc     : output text encoding name
>  -eol     : output end-of-line convention (unix, dos, or mac)
>  -nopgbrk : don't insert page breaks between pages
>  -bom : insert a Unicode BOM at the start of the text file
>  -opw     : owner password (for encrypted files)
>  -upw     : user password (for encrypted files)
>  -q   : don't print any messages or errors
>  -cfg     : configuration file to use in place of .xpdfrc
>  -v   : print copyright and version info
> :
> 
> When I hit the down arrow, it scrolls down, repeating this output infinitely 
> until I hit 'q'.  What is going on here??
> 

Wild guess: You're using "Git for Windows" on a version less than 
"2.18.0.windows.1" ?

Try upgrading (at least) to that version. IIRC that's one of the issues it 
fixes.

HTH
Stefan
-- 

/dev/random says: Never underestimate the power of human stupidity.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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

But only if the user doesn't have a ~/.vimrc file!

> (which is still the default editor of Git for Windows, for
> historical reasons).> 
> Git for Windows v2.15.1(2) fixes just this one bug, and can be downloaded
> here:
> 
>   https://github.com/git-for-windows/git/releases/tag/v2.15.1.windows.2
> 
> Ciao,
> Johannes

Stefan
-- 

/dev/random says: Ignorance can be cured. Stupid is forever.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

Bug or feature: format-patch breaks long subject lines

[stefan.naewe]

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 test-format-patch
$ cd test-format-patch
$ touch file
$ git add file
$ git commit 
-m"0123456789012345678901234567890123456789012345678901234567890123456789"
$ git format-patch -1 --stdout
From ec711cca330f1032d286114932a90488542f1da2 Mon Sep 17 00:00:00 2001
From: Stefan Naewe 
Date: Thu, 12 Oct 2017 10:36:52 +0200
Subject: [PATCH]
 0123456789012345678901234567890123456789012345678901234567890123456789

---
 file | 0
 1 file changed, 0 insertions(+), 0 deletions(-)
 create mode 100644 file

diff --git a/file b/file
new file mode 100644
index 000..e69de29
--
2.14.2.windows.2
--

Is this the expected behaviour?

Thanks,
  Stefan
-- 

/dev/random says: I Have To Stop Now, My Fingers Are Getting Hoarse!
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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 argument
> From C:\Temp\gittest
>  * branchHEAD   -> FETCH_HEAD

What is the exact precondition to get such a warning ?

Just wondering, because I'm not able to reproduce that warning
(with Git4win version 2.13.0.windows.1).

Stefan
-- 

/dev/random says: Spock, you are such a putz!
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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 perl.mak has
> hardcoded paths to perl library paths retrieved from its first run.
> 
> Now the logic added in commit ee9be06770 ("perl: detect new files in
> MakeMaker builds", 2012-07-27) is extended to regeneratio

s/regeneratio/regenerate/

> [...]


/S
-- 

/dev/random says: HELP! I need a tagline. HELP! Not just any tagline.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

Re: Viewing untracked+stashed files in git stash show

[stefan.naewe]

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 'git show stash@{0}^3

(Or, of course, 'gitk stash@{0}' )

HTH

Stefan
-- 

/dev/random says: I keep my .BAT files in D:\BELFRY
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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 do not detect.
>> It is an useful target for doing QA analysis.
>>
>> Based-on-patch-by: Elia Pinto 
>> Signed-off-by: Chris Packham 
>> ---
>> I had been playing with cppcheck for some other projects and happened to
>> notice [1] in the archives. This is my attempt to resolve the feedback
>> that Junio made at the time.
>>
>> In terms of errors that are actually reported there are only a few
>>
>> $ make cppcheck
>> cppcheck --force --quiet --inline-suppr  .
>> [compat/nedmalloc/malloc.c.h:4093]: (error) Possible null pointer 
>> dereference: sp
>> [compat/nedmalloc/malloc.c.h:4106]: (error) Possible null pointer 
>> dereference: sp
>> [compat/nedmalloc/nedmalloc.c:551]: (error) Expression 
>> '*()=TlsAlloc(),TLS_OUT_OF_INDEXES==*()' depends on 
>> order of evaluation of side effects
>> [compat/regex/regcomp.c:3086]: (error) Memory leak: sbcset
>> [compat/regex/regcomp.c:3634]: (error) Memory leak: sbcset
>> [compat/regex/regcomp.c:3086]: (error) Memory leak: mbcset
>> [compat/regex/regcomp.c:3634]: (error) Memory leak: mbcset
>> [compat/regex/regcomp.c:2802]: (error) Uninitialized variable: table_size
>> [compat/regex/regcomp.c:2805]: (error) Uninitialized variable: table_size
>> [compat/regex/regcomp.c:532]: (error) Memory leak: fastmap
>> [t/t4051/appended1.c:3]: (error) Invalid number of character '{' when these 
>> macros are defined: ''.
>> [t/t4051/appended2.c:35]: (error) Invalid number of character '{' when these 
>> macros are defined: ''.
>>
>> The last 2 are just false positives from test data. I haven't looked
>> into any of the others.
>>
>> I've also provisioned for enabling extra checks by passing CPPCHECK_ADD
>> in the make invocation.
>>
>> $ make cppcheck CPPCHECK_ADD=--enable=all
>> ... lots of output
>>
>> [1] - 
>> http://public-inbox.org/git/1390993371-2431-1-git-send-email-gitter.spi...@gmail.com/#t
>>
>>  Makefile | 4 
>>  1 file changed, 4 insertions(+)
>>
>> diff --git a/Makefile b/Makefile
>> index f53fcc90d..8b5976d88 100644
>> --- a/Makefile
>> +++ b/Makefile
>> @@ -2635,3 +2635,7 @@ cover_db: coverage-report
>>  cover_db_html: cover_db
>> cover -report html -outputdir cover_db_html cover_db
>>
>> +.PHONY: cppcheck
>> +
>> +cppcheck:
>> +   cppcheck --force --quiet --inline-suppr $(CPPCHECK_ADD) .
> 
> If I'm permitted a little GNU make-ism the following might make
> CPPCHECK_ADD a bit more usable
> 
> +   cppcheck --force --quiet --inline-suppr $(if
> $(CPPCHECK_ADD),--enable=$(CPPCHECK_ADD)) .
> 
> Which would take us from
> 
> $ make cppcheck CPPCHECK_ADD=--enable=all
> 
> to
> 
> $ make cppcheck CPPCHECK_ADD=all

Hhhmmmbut this allows for only specifying options to '--enable'.
The other version is much more flexible (i.e. allows for other complete options 
as well).

Just my 0,02€

Stefan
-- 

/dev/random says: I'd love to, but I prefer to remain an enigma.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

Re: [ANNOUNCE] Git for Windows 2.11.0

[stefan.naewe]

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)
> 
> New Features
> 
>   * Comes with Git v2.11.0.
>   * Performance of git add in large worktrees was improved.
>   * A new, experimental, builtin version of the difftool is available
> as an opt-in feature.
>   * Support has been added to generate project files for Visual Studio
> 2010 and later.

That's not really a new feature of Git-for-Windows, is it ?

Just wondering...

Stefan
-- 

/dev/random says: Money is the root of all evil; everyone needs roots!
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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

Tanks a lot!

Stefan
-- 

/dev/random says: Catholic (n.) A cat with a drinking problem.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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*]:
> 
> https://github.com/git-for-windows/git/releases/tag/v2.11.0-rc0.windows.1
> 
> It would be really nice if those of you who have access to Windows [*2*]
> could try it out and report bugs before v2.11.0 final.

I tried that version on 64bit Win7.
Somehow the PATH env. variable does no longer get set correctly.

On git-for-windows 2.10.2 my PATH (inside git bash) contains ~75 Entries.
With the above installer I only get ~17 !
(Inside cmd.exe I get 61 entries. I set some more entries with by ~/.bashrc)

It seems that all entries that contain a path with whitespace (e.g. 'c:\program 
files (x86)' )
are no longer there.

Any ideas ?

Thanks,
  Stefan
-- 

/dev/random says: Oxymoron: Stuck in traffic.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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 is a problem
> because we modify the Perforce dependencies in the homebrew repository
> before installing them.
> 
> Fix it by asking homebrew for its path instead of hardcoding it.
> 
> [1] 
> https://github.com/Homebrew/brew/commit/0a09ae30f8b6117ad699b4a0439010738989c547
> 
> Signed-off-by: Lars Schneider 
> ---
> 
> Hi Junio,
> 
> the problem affects all branches (pu, next, master, maint):
> https://travis-ci.org/git/git/branches
> 
> Is it possible for this fix to graduate more quickly?
> 
> Thanks,
> Lars
> 
>  .travis.yml | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index 477c3d2..37a1e1f 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -78,7 +78,7 @@ before_install:
>  FORMULA=$1
>  SHA=$(brew fetch --force $FORMULA 2>&1 | grep ^SHA256: | cut -d ' ' 
> -f 2)
>  sed -E -i.bak "s/sha256 \"[0-9a-f]{64}\"/sha256 \"$SHA\"/g" \
> -  /usr/local/Library/Taps/homebrew/homebrew-binary/$FORMULA.rb
> +  "$(brew --repository homebrew/homebrew-binary)/$FORMULA.rb"
>}
>brew update --quiet
>brew tap homebrew/binary --quiet
> --
> 2.10.0
> 
> 


-- 

/dev/random says: If winning isn't important then why keep score?
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

Re: [ANNOUNCE] Git for Windows 2.10.0

[stefan.naewe]

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:
> 
> https://blogs.msdn.microsoft.com/visualstudioalm/2016/09/03/whats-new-in-git-for-windows-2-10/
> 
> As always, you can download it from: https://git-for-windows.github.io/
> 
> Changes since Git for Windows v2.9.3(2) (August 25th 2016)
> 
> New Features
> 
>   • Comes with Git v2.10.0.
>   • The git rebase -i command was made faster by reimplementing large
> parts in C.

I finally had the chance to do a "bigger" rebase and what shall I say...
F***k, has this thing become fast, or what!

Thank you so much for doing this

Stefan
-- 

/dev/random says: A Cat's courage is as strong as a dog's chain
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

Re: Context Menu is missing

[stefan.naewe]

(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 AM,   wrote:
>> (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 don't top post and do "reply all")

>>> I tried but you are receiving only plain text emails.
>>> anyway...
>>
>> ??? ECANNOTUNDERSTAND
>>
>> Read about top-posting here: 
>> https://en.wikipedia.org/wiki/Posting_style#Top-posting
>>
>>> I reinstalled windows on my computer and then installed Git version
>>> 2.9.3 for windows.
>>> And the context menu were missing.
>>
>> In the explorer, I guess ?
>>
>>> I am talking about the one that you had:
>>> - Git History
>>> - Git Branch
>>>- branch_1
>>>- branch_2
>>> 
>>
>> Git for windows *doesn't* install that.
>>
>>> Git GUI and Git Bash are still there...
>>
>> Git for windows *does* install that.
>>
>> Maybe you had TortoiseGit installed before (just a wild guess, though)
>>
>> Stefan
>> --
>> 
>> /dev/random says: Gambling: The sure way of getting nothing for something.
>> python -c "print 
>> '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
>> GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF
> 
> 
> 


-- 

/dev/random says: Give instruction to a wise man and he will be yet wiser.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

Re: Context Menu is missing

[stefan.naewe]

(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 don't top post and do "reply all")
>>
> I tried but you are receiving only plain text emails.
> anyway...

??? ECANNOTUNDERSTAND

Read about top-posting here: 
https://en.wikipedia.org/wiki/Posting_style#Top-posting
 
> I reinstalled windows on my computer and then installed Git version
> 2.9.3 for windows.
> And the context menu were missing.

In the explorer, I guess ?

> I am talking about the one that you had:
> - Git History
> - Git Branch
>- branch_1
>- branch_2
> 

Git for windows *doesn't* install that.

> Git GUI and Git Bash are still there...

Git for windows *does* install that.

Maybe you had TortoiseGit installed before (just a wild guess, though)

Stefan
-- 

/dev/random says: Gambling: The sure way of getting nothing for something.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

Re: Context Menu is missing

[stefan.naewe]

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

> No,
> Windows 7 64Bit
> Version: 2.9.3.windows.2


Really? That's good to know.

Would it be OK to ask you to tell us what exactly you did and which
context menu is gone, or shall I guess again?


-- 

/dev/random says: A few cans short of a six pack, Six short.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

Re: Context Menu is missing

[stefan.naewe]

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

/dev/random says: I'd explain it to you, but your brain would explode.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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 
>  1 file changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/builtin/apply.c b/builtin/apply.c
> index ad403f8..429fe44 100644
> --- a/builtin/apply.c
> +++ b/builtin/apply.c
> @@ -4588,16 +4588,16 @@ static int apply_patch(struct apply_state *state,
>   return res;
>  }
>  
> -static int option_parse_exclude(const struct option *opt,
> - const char *arg, int unset)
> +static int apply_option_parse_exclude(const struct option *opt,
> +   const char *arg, int unset)
>  {
>   struct apply_state *state = opt->value;
>   add_name_limit(state, arg, 1);
>   return 0;
>  }
>  
> -static int option_parse_include(const struct option *opt,
> - const char *arg, int unset)
> +static int apply_option_parse_include(const struct option *opt,
> +   const char *arg, int unset)
>  {
>   struct apply_state *state = opt->value;
>   add_name_limit(state, arg, 0);
> @@ -4605,9 +4605,9 @@ static int option_parse_include(const struct option 
> *opt,
>   return 0;
>  }
>  
> -static int option_parse_p(const struct option *opt,
> -   const char *arg,
> -   int unset)
> +static int apply_option_parse_p(const struct option *opt,
> + const char *arg,
> + int unset)
>  {
>   struct apply_state *state = opt->value;
>   state->p_value = atoi(arg);
> @@ -4615,8 +4615,8 @@ static int option_parse_p(const struct option *opt,
>   return 0;
>  }
>  
> -static int option_parse_space_change(const struct option *opt,
> -  const char *arg, int unset)
> +static int apply_option_parse_space_change(const struct option *opt,
> +const char *arg, int unset)
>  {
>   struct apply_state *state = opt->value;
>   if (unset)
> @@ -4626,8 +4626,8 @@ static int option_parse_space_change(const struct 
> option *opt,
>   return 0;
>  }
>  
> -static int option_parse_whitespace(const struct option *opt,
> -const char *arg, int unset)
> +static int apply_option_parse_whitespace(const struct option *opt,
> +  const char *arg, int unset)
>  {
>   struct apply_state *state = opt->value;
>   state->whitespace_option = arg;
> @@ -4636,8 +4636,8 @@ static int option_parse_whitespace(const struct option 
> *opt,
>   return 0;
>  }
>  
> -static int option_parse_directory(const struct option *opt,
> -   const char *arg, int unset)
> +static int apply_option_parse_directory(const struct option *opt,
> + const char *arg, int unset)
>  {
>   struct apply_state *state = opt->value;
>   strbuf_reset(>root);
> @@ -4755,13 +4755,13 @@ int cmd_apply(int argc, const char **argv, const char 
> *prefix)
>   struct option builtin_apply_options[] = {
>   { OPTION_CALLBACK, 0, "exclude", , N_("path"),
>   N_("don't apply changes matching the given path"),
> - 0, option_parse_exclude },
> + 0, apply_option_parse_exclude },
>   { OPTION_CALLBACK, 0, "include", , N_("path"),
>   N_("apply changes matching the given path"),
> - 0, option_parse_include },
> + 0, apply_option_parse_include },
>   { OPTION_CALLBACK, 'p', NULL, , N_("num"),
>   N_("remove  leading slashes from traditional diff 
> paths"),
> - 0, option_parse_p },
> + 0, apply_option_parse_p },
>   OPT_BOOL(0, "no-add", _add,
>   N_("ignore additions made by the patch")),
>   OPT_BOOL(0, "stat", ,
> @@ -4793,13 +4793,13 @@ int cmd_apply(int argc, const char **argv, const char 
> *prefix)
>   N_("ensure at least  lines of context 
> match")),
>   { OPTION_CALLBACK, 0, "whitespace", , N_("action"),
>   N_("detect new or modified lines that have whitespace 
> errors"),
> - 0, option_parse_whitespace },
> + 0, apply_option_parse_whitespace },
>   { OPTION_CALLBACK, 0, "ignore-space-change", , NULL,
>   N_("ignore changes in whitespace when finding context"),
> - PARSE_OPT_NOARG, option_parse_space_change },
> + PARSE_OPT_NOARG, apply_option_parse_space_change },
>   { 

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

[stefan.naewe]

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 more
>>> specific names to avoid possible name collisions in th global
>>
>> s/th/the/
>>
>>> namespace.
> 
> Thanks. I will send an update with only a new version of this patch
> and of 28/40.
> 

There's another lowercase 'api' in patch 40

Stefan
-- 

/dev/random says: Tis better to have loved and lost than just to have lost.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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 
> ---
>  builtin/apply.c | 20 ++--
>  1 file changed, 10 insertions(+), 10 deletions(-)
> 
> diff --git a/builtin/apply.c b/builtin/apply.c
> index 1a488f9..ab8f0bd 100644
> --- a/builtin/apply.c
> +++ b/builtin/apply.c
> @@ -21,7 +21,7 @@
>  #include "ll-merge.h"
>  #include "rerere.h"
>  
> -enum ws_error_action {
> +enum apply_ws_error_action {
>   nowarn_ws_error,
>   warn_on_ws_error,
>   die_on_ws_error,
> @@ -29,7 +29,7 @@ enum ws_error_action {
>  };
>  
>  
> -enum ws_ignore {
> +enum apply_ws_ignore {
>   ignore_ws_none,
>   ignore_ws_change
>  };
> @@ -45,8 +45,8 @@ enum ws_ignore {
>   * See also "struct string_list symlink_changes" in "struct
>   * apply_state".
>   */
> -#define SYMLINK_GOES_AWAY 01
> -#define SYMLINK_IN_RESULT 02
> +#define APPLY_SYMLINK_GOES_AWAY 01
> +#define APPLY_SYMLINK_IN_RESULT 02
>  
>  struct apply_state {
>   const char *prefix;
> @@ -110,8 +110,8 @@ struct apply_state {
>   struct string_list fn_table;
>  
>   /* These control whitespace errors */
> - enum ws_error_action ws_error_action;
> - enum ws_ignore ws_ignore_action;
> + enum apply_ws_error_action ws_error_action;
> + enum apply_ws_ignore ws_ignore_action;
>   const char *whitespace_option;
>   int whitespace_error;
>   int squelch_whitespace_errors;
> @@ -3750,11 +3750,11 @@ static void prepare_symlink_changes(struct 
> apply_state *state, struct patch *pat
>   if ((patch->old_name && S_ISLNK(patch->old_mode)) &&
>   (patch->is_rename || patch->is_delete))
>   /* the symlink at patch->old_name is removed */
> - register_symlink_changes(state, patch->old_name, 
> SYMLINK_GOES_AWAY);
> + register_symlink_changes(state, patch->old_name, 
> APPLY_SYMLINK_GOES_AWAY);
>  
>   if (patch->new_name && S_ISLNK(patch->new_mode))
>   /* the symlink at patch->new_name is created or remains 
> */
> - register_symlink_changes(state, patch->new_name, 
> SYMLINK_IN_RESULT);
> + register_symlink_changes(state, patch->new_name, 
> APPLY_SYMLINK_IN_RESULT);
>   }
>  }
>  
> @@ -3769,9 +3769,9 @@ static int path_is_beyond_symlink_1(struct apply_state 
> *state, struct strbuf *na
>   break;
>   name->buf[name->len] = '\0';
>   change = check_symlink_changes(state, name->buf);
> - if (change & SYMLINK_IN_RESULT)
> + if (change & APPLY_SYMLINK_IN_RESULT)
>   return 1;
> - if (change & SYMLINK_GOES_AWAY)
> + if (change & APPLY_SYMLINK_GOES_AWAY)
>   /*
>* This cannot be "return 0", because we may
>* see a new one created at a higher level.
> 

Stefan
-- 

/dev/random says: Don't be so humble, you're not that great. -Golda Meir
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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 
>  1 file changed, 20 insertions(+), 20 deletions(-)
> 
> diff --git a/builtin/apply.c b/builtin/apply.c
> index ad403f8..429fe44 100644
> --- a/builtin/apply.c
> +++ b/builtin/apply.c
> @@ -4588,16 +4588,16 @@ static int apply_patch(struct apply_state *state,
>   return res;
>  }
>  
> -static int option_parse_exclude(const struct option *opt,
> - const char *arg, int unset)
> +static int apply_option_parse_exclude(const struct option *opt,
> +   const char *arg, int unset)
>  {
>   struct apply_state *state = opt->value;
>   add_name_limit(state, arg, 1);
>   return 0;
>  }
>  
> -static int option_parse_include(const struct option *opt,
> - const char *arg, int unset)
> +static int apply_option_parse_include(const struct option *opt,
> +   const char *arg, int unset)
>  {
>   struct apply_state *state = opt->value;
>   add_name_limit(state, arg, 0);
> @@ -4605,9 +4605,9 @@ static int option_parse_include(const struct option 
> *opt,
>   return 0;
>  }
>  
> -static int option_parse_p(const struct option *opt,
> -   const char *arg,
> -   int unset)
> +static int apply_option_parse_p(const struct option *opt,
> + const char *arg,
> + int unset)
>  {
>   struct apply_state *state = opt->value;
>   state->p_value = atoi(arg);
> @@ -4615,8 +4615,8 @@ static int option_parse_p(const struct option *opt,
>   return 0;
>  }
>  
> -static int option_parse_space_change(const struct option *opt,
> -  const char *arg, int unset)
> +static int apply_option_parse_space_change(const struct option *opt,
> +const char *arg, int unset)
>  {
>   struct apply_state *state = opt->value;
>   if (unset)
> @@ -4626,8 +4626,8 @@ static int option_parse_space_change(const struct 
> option *opt,
>   return 0;
>  }
>  
> -static int option_parse_whitespace(const struct option *opt,
> -const char *arg, int unset)
> +static int apply_option_parse_whitespace(const struct option *opt,
> +  const char *arg, int unset)
>  {
>   struct apply_state *state = opt->value;
>   state->whitespace_option = arg;
> @@ -4636,8 +4636,8 @@ static int option_parse_whitespace(const struct option 
> *opt,
>   return 0;
>  }
>  
> -static int option_parse_directory(const struct option *opt,
> -   const char *arg, int unset)
> +static int apply_option_parse_directory(const struct option *opt,
> + const char *arg, int unset)
>  {
>   struct apply_state *state = opt->value;
>   strbuf_reset(>root);
> @@ -4755,13 +4755,13 @@ int cmd_apply(int argc, const char **argv, const char 
> *prefix)
>   struct option builtin_apply_options[] = {
>   { OPTION_CALLBACK, 0, "exclude", , N_("path"),
>   N_("don't apply changes matching the given path"),
> - 0, option_parse_exclude },
> + 0, apply_option_parse_exclude },
>   { OPTION_CALLBACK, 0, "include", , N_("path"),
>   N_("apply changes matching the given path"),
> - 0, option_parse_include },
> + 0, apply_option_parse_include },
>   { OPTION_CALLBACK, 'p', NULL, , N_("num"),
>   N_("remove  leading slashes from traditional diff 
> paths"),
> - 0, option_parse_p },
> + 0, apply_option_parse_p },
>   OPT_BOOL(0, "no-add", _add,
>   N_("ignore additions made by the patch")),
>   OPT_BOOL(0, "stat", ,
> @@ -4793,13 +4793,13 @@ int cmd_apply(int argc, const char **argv, const char 
> *prefix)
>   N_("ensure at least  lines of context 
> match")),
>   { OPTION_CALLBACK, 0, "whitespace", , N_("action"),
>   N_("detect new or modified lines that have whitespace 
> errors"),
> - 0, option_parse_whitespace },
> + 0, apply_option_parse_whitespace },
>   { OPTION_CALLBACK, 0, "ignore-space-change", , NULL,
>   N_("ignore changes in whitespace when finding context"),
> - PARSE_OPT_NOARG, option_parse_space_change },
> + PARSE_OPT_NOARG, apply_option_parse_space_change },
>   { 

Re: [BUG] gitk

[stefan.naewe]

+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 it over VNC.
> 
> I cannot find any instructions for submitting patches to the gitk subproject.
> Does anyone know the process for this?
> 
> After looking at the original commit which caused this
> (66db14c94c95f911f55575c7fdf74c026443d482)...
> ... reverting may not be the right thing to do.
> Instead, lime should be replaced with "#32cd32", a trivial fix.
> 
> Again, I'd do this myself if I had instructions for submitting patches
> for to gitk.
> 
> Thanks,
> ~Eric
> 
> On Wed, Jun 8, 2016 at 5:58 AM,   wrote:
>> 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 clone repo’s unless they’re http while on my corporate proxy.
 I’m hoping someone can help me out or just do it for me ;-)
 I’d like to revert 66db14c94c95f911f55575c7fdf74c026443d482.

 That commit just renamed “green” to “lime”
 It causes gitk to not start up on when ran through VNC.
 It works fine on that same system natively or over X11 forwarding but not 
 VNC.
>>>
>>> FWIW, I can confirm that.
>>>
>>> git version 2.8.3
>>>
>>> My $HOME/.config/git/gitk contains:
>>>
>>> set mergecolors {red blue green purple brown "#009090" magenta "#808000" 
>>> "#009000" "#ff0080" cyan "#b07070" "#70b0f0" "#70f0b0" "#f0b070" "#ff70b0"}
>>>

>>> With that file gitk runs without problems.
>>> If I move that file away, gitk stops working over VNC and also forwarded 
>>> X11 for me.
>>
>> More Info:
>>
>> The forwarded X11 (which is from a Windows machine running Exceed to a Linux 
>> machine) works
>> without the gitk file mentioned above, if I edit the 'rgb.txt' used by 
>> Exceed to contain something like:
>>
>>  50 205  50 lime
>>
>> Before the editing the file only contained the following:
>>
>>  50 205  50 lime green
>>  50 205  50 LimeGreen
>>
>> I couldn't do the same for the VNC connection though (Xvnc seems to use a 
>> hardcoded 'rgb.txt' file).
>>
>> It seems that using 'lime' was not the best choice...
>>
>>
>> HTH
>>
>> Stefan
>> --
>> 
>> /dev/random says: I used to be schizophrenic, but we're all right now.
>> python -c "print 
>> '73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
>> GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF
>>
> 


-- 

/dev/random says: Lefties are the only ones in their right minds.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

Re: [BUG] gitk

[stefan.naewe]

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 clone repo’s unless they’re http while on my corporate proxy.
>> I’m hoping someone can help me out or just do it for me ;-)
>> I’d like to revert 66db14c94c95f911f55575c7fdf74c026443d482.
>>
>> That commit just renamed “green” to “lime”
>> It causes gitk to not start up on when ran through VNC.
>> It works fine on that same system natively or over X11 forwarding but not 
>> VNC.
> 
> FWIW, I can confirm that.
> 
> git version 2.8.3
> 
> My $HOME/.config/git/gitk contains:
> 
> set mergecolors {red blue green purple brown "#009090" magenta "#808000" 
> "#009000" "#ff0080" cyan "#b07070" "#70b0f0" "#70f0b0" "#f0b070" "#ff70b0"}
> 
> With that file gitk runs without problems.
> If I move that file away, gitk stops working over VNC and also forwarded X11 
> for me.

More Info:

The forwarded X11 (which is from a Windows machine running Exceed to a Linux 
machine) works
without the gitk file mentioned above, if I edit the 'rgb.txt' used by Exceed 
to contain something like:

 50 205  50 lime

Before the editing the file only contained the following:

 50 205  50 lime green
 50 205  50 LimeGreen

I couldn't do the same for the VNC connection though (Xvnc seems to use a 
hardcoded 'rgb.txt' file).

It seems that using 'lime' was not the best choice...


HTH

Stefan
-- 

/dev/random says: I used to be schizophrenic, but we're all right now.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF



signature.asc
Description: OpenPGP digital signature

Re: [BUG] gitk

[stefan.naewe]

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 someone can help me out or just do it for me ;-)
> I’d like to revert 66db14c94c95f911f55575c7fdf74c026443d482.
> 
> That commit just renamed “green” to “lime”
> It causes gitk to not start up on when ran through VNC.
> It works fine on that same system natively or over X11 forwarding but not VNC.

FWIW, I can confirm that.

git version 2.8.3

My $HOME/.config/git/gitk contains:

set mergecolors {red blue green purple brown "#009090" magenta "#808000" 
"#009000" "#ff0080" cyan "#b07070" "#70b0f0" "#70f0b0" "#f0b070" "#ff70b0"}

With that file gitk runs without problems.
If I move that file away, gitk stops working over VNC and also forwarded X11 
for me.

It runs natively on Windows though.

> It also seems from the following link/quote improper to use “lime” anyway.
> 
> From http://www.tkdocs.com/tutorial/fonts.html .. quote:
> Tk recognizes the set of color names defined by X11;
> normally these are not used, except for very common
> ones such as "red", "black", etc.


Stefan
-- 

/dev/random says: Useless Invention: Dehydrated water.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF



signature.asc
Description: OpenPGP digital signature

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

[stefan.naewe]

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 could just extend it to 64 bits now to give room
> for more future flags.
> 
> gcc -Wconversion is used to catch assignments that truncate bits. No new
> warning was introduced (in fact one in index_differs_from() was
> eliminated),
> 
> Signed-off-by: Nguyễn Thái Ngọc Duy 
> ---
>  builtin/commit.c | 2 +-
>  diff-lib.c   | 4 ++--
>  diff.c   | 2 +-
>  diff.h   | 6 +++---
>  4 files changed, 7 insertions(+), 7 deletions(-)
> 
> diff --git a/builtin/commit.c b/builtin/commit.c
> index 443ff91..fcfaa2b 100644
> --- a/builtin/commit.c
> +++ b/builtin/commit.c
> @@ -906,7 +906,7 @@ static int prepare_to_commit(const char *index_file, 
> const char *prefix,
>* submodules which were manually staged, which would
>* be really confusing.
>*/
> - int diff_flags = DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG;
> + uint64_t diff_flags = 
> DIFF_OPT_OVERRIDE_SUBMODULE_CONFIG;
>   if (ignore_submodule_arg &&
>   !strcmp(ignore_submodule_arg, "all"))
>   diff_flags |= DIFF_OPT_IGNORE_SUBMODULES;
> diff --git a/diff-lib.c b/diff-lib.c
> index bc49c70..27887d0 100644
> --- a/diff-lib.c
> +++ b/diff-lib.c
> @@ -71,7 +71,7 @@ static int match_stat_with_submodule(struct diff_options 
> *diffopt,
>  {
>   int changed = ce_match_stat(ce, st, ce_option);
>   if (S_ISGITLINK(ce->ce_mode)) {
> - unsigned orig_flags = diffopt->flags;
> + uint64_t orig_flags = diffopt->flags;
>   if (!DIFF_OPT_TST(diffopt, OVERRIDE_SUBMODULE_CONFIG))
>   set_diffopt_flags_from_submodule_config(diffopt, 
> ce->name);
>   if (DIFF_OPT_TST(diffopt, IGNORE_SUBMODULES))
> @@ -516,7 +516,7 @@ int do_diff_cache(const unsigned char *tree_sha1, struct 
> diff_options *opt)
>   return 0;
>  }
>  
> -int index_differs_from(const char *def, int diff_flags)
> +int index_differs_from(const char *def, uint64_t diff_flags)
>  {
>   struct rev_info rev;
>   struct setup_revision_opt opt;
> diff --git a/diff.c b/diff.c
> index d3734d3..f70425f 100644
> --- a/diff.c
> +++ b/diff.c
> @@ -4936,7 +4936,7 @@ int diff_can_quit_early(struct diff_options *opt)
>  static int is_submodule_ignored(const char *path, struct diff_options 
> *options)
>  {
>   int ignored = 0;
> - unsigned orig_flags = options->flags;
> + uint64_t orig_flags = options->flags;
>   if (!DIFF_OPT_TST(options, OVERRIDE_SUBMODULE_CONFIG))
>   set_diffopt_flags_from_submodule_config(options, path);
>   if (DIFF_OPT_TST(options, IGNORE_SUBMODULES))
> diff --git a/diff.h b/diff.h
> index 125447b..b497078 100644
> --- a/diff.h
> +++ b/diff.h
> @@ -115,8 +115,8 @@ struct diff_options {
>   const char *pickaxe;
>   const char *single_follow;
>   const char *a_prefix, *b_prefix;
> - unsigned flags;
> - unsigned touched_flags;
> + uint64_t flags;
> + uint64_t touched_flags;
>  
>   /* diff-filter bits */
>   unsigned int filter;
> @@ -348,7 +348,7 @@ extern int diff_result_code(struct diff_options *, int);
>  
>  extern void diff_no_index(struct rev_info *, int, const char **);
>  
> -extern int index_differs_from(const char *def, int diff_flags);
> +extern int index_differs_from(const char *def, uint64_t diff_flags);
>  
>  /*
>   * Fill the contents of the filespec "df", respecting any textconv defined by
> 

Stefan
-- 

/dev/random says: Make Headlines..use a corduroy pillow
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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 performed as part of the Linux/GCC build job to maintain a fast
> CI process.
> 
> Signed-off-by: Lars Schneider 
> ---
> 
> Patch as promised in 
> http://article.gmane.org/gmane.comp.version-control.git/291726
> 
> Cheers,
> Lars
> 
>  .travis.yml | 13 -
>  1 file changed, 12 insertions(+), 1 deletion(-)
> 
> diff --git a/.travis.yml b/.travis.yml
> index c3bf9c6..6ca7fb2 100644
> --- a/.travis.yml
> +++ b/.travis.yml
> @@ -12,6 +12,8 @@ addons:
>apt:
>  packages:
>  - language-pack-is
> +- asciidoc
> +- xmlto
> 
>  env:
>global:
> @@ -70,7 +72,16 @@ before_install:
> 
>  before_script: make --jobs=2
> 
> -script: make --quiet test
> +script:
> +  - >
> +  make --quiet test &&
> +  if [[ "$TRAVIS_OS_NAME" = linux ]] && [[ "$CC" = gcc ]];
> +  then
> +  echo ""
> +  echo 
> "" &&
> +  echo "$(tput setaf 2)Building documentation...$(tput sgr0)" &&
> +  make --quiet doc
> +  fi;
> 
>  after_failure:
>- >

Stefan
-- 

/dev/random says: The cat that ate the ball of yarnhad mittens!
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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

Am 12.04.2016 um 13:25 schrieb Rudinei Goi Roecker:
> I'm having a problem with included configurations in ~/.gitconfig, when
> using this command:
> 
> git config --global user.email
> 
> It doesn't return anything, in commits it works as intended. The
> configuration looks like this:
> 
> ~/.gitconfig
> [include]
>path = .gitconfig.user

Maybe you want to use

 path = ~/.gitconfig.user

here.

> # ... more configurations
> 
> ~/.gitconfig.user
> [user]
>name = My Full Name
>email = myem...@example.com

HTH,
  Stefan
-- 

/dev/random says: CURSOR: What you become when your system crashes.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

Re: support block comments in gitconfig

[stefan.naewe]

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 of gitconfig:

[include]
  path = ~/.another.gitconfig

??

That way you can comment out a lot of configuration with one '#'.

Just my €0.02

Stefan
-- 

/dev/random says: Air conditioned environment - Do not open Windows.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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

> https://msdn.microsoft.com/en-us/library/windows/desktop/ms682659
> 
> Pointed out by Jeff King.
> 
> Signed-off-by: Johannes Schindelin 
> ---
> 
> Relative to v1, only the commit message changed (to clarify that
> ExitThread() indeed never returns).
> 
>  compat/win32/pthread.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/compat/win32/pthread.h b/compat/win32/pthread.h
> index 20b35a2..148db60 100644
> --- a/compat/win32/pthread.h
> +++ b/compat/win32/pthread.h
> @@ -78,7 +78,7 @@ extern int win32_pthread_join(pthread_t *thread, void 
> **value_ptr);
>  #define pthread_equal(t1, t2) ((t1).tid == (t2).tid)
>  extern pthread_t pthread_self(void);
> 
> -static inline int pthread_exit(void *ret)
> +static inline int NORETURN pthread_exit(void *ret)
>  {
> ExitThread((DWORD)(intptr_t)ret);
>  }
> --


Stefan
-- 

/dev/random says: We're lost, but we're making good time.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

Zombie tag

[stefan.naewe]

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
Now, in B1, 'git fsck' shows a dangling tag that can be identified
as 'tag-a' from above. There's obviously no reflog in B1.
I don't know how to get rid of that tag.

A cleaned-up 'script' session of the above is attached.

The problem initially occurred on Windows with git 2.7.0 but could
be reproduced on a Linux machine with git 2.7.0.

What's going on here ?

Thanks,
  Stefan
-- 

/dev/random says: Polls show that 9 out of 6 schizophrenics agree.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF
~/tmp/zombie-tag ~
$ git init repo1
Initialized empty Git repository in /home/naewe_s/tmp/zombie-tag/repo1/.git/
$ git init repo2
Initialized empty Git repository in /home/naewe_s/tmp/zombie-tag/repo2/.git/
$ git init --bare bare1.git
Initialized empty Git repository in /home/naewe_s/tmp/zombie-tag/bare1.git/
$ cd repo1
$ echo A > A ; git add A ; git commit -m"add A"
[master (root-commit) d9e5baf] add A
 1 file changed, 1 insertion(+)
 create mode 100644 A
$ echo B > B ; git add B ; git commit -m"add B"
[master 3810738] add B
 1 file changed, 1 insertion(+)
 create mode 100644 B
$ git tag -m"initial" initial
$ git push ../bare1.git/ master initial
Counting objects: 7, done.
Delta compression using up to 2 threads.
Compressing objects:  25% (1/4)   
Compressing objects:  50% (2/4)   
Compressing objects:  75% (3/4)   
Compressing objects: 100% (4/4)   
Compressing objects: 100% (4/4), done.
Writing objects:  14% (1/7)   
Writing objects:  28% (2/7)   
Writing objects:  42% (3/7)   
Writing objects:  57% (4/7)   
Writing objects:  71% (5/7)   
Writing objects:  85% (6/7)   
Writing objects: 100% (7/7)   
Writing objects: 100% (7/7), 548 bytes | 0 bytes/s, done.
Total 7 (delta 1), reused 0 (delta 0)
To ../bare1.git
 * [new branch]  master -> master
 * [new tag] initial -> initial
$ cd ../repo2
$ for n in 1 2; do echo $n > $n ; git add $n; git commit -m"add $n"; done
[master (root-commit) e2ebcc4] add 1
 1 file changed, 1 insertion(+)
 create mode 100644 1
[master f8d1071] add 2
 1 file changed, 1 insertion(+)
 create mode 100644 2
$ git push -f ../bare1.git/ master
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects:  33% (1/3)   
Compressing objects:  66% (2/3)   
Compressing objects: 100% (3/3)   
Compressing objects: 100% (3/3), done.
Writing objects:  16% (1/6)   
Writing objects:  33% (2/6)   
Writing objects:  50% (3/6)   
Writing objects:  66% (4/6)   
Writing objects:  83% (5/6)   
Writing objects: 100% (6/6)   
Writing objects: 100% (6/6), 384 bytes | 0 bytes/s, done.
Total 6 (delta 1), reused 0 (delta 0)
To ../bare1.git
 + 3810738...f8d1071 master -> master (forced update)
$ git push ../bare1.git/ :initial
To ../bare1.git
 - [deleted] initial
$ cd ../bare1.git/
$ git log --oneline
f8d1071 add 2
e2ebcc4 add 1

$ git for-each-ref
f8d10716fc887da36df53f58660bfaa77ff5a411 commit refs/heads/master
$ git fsck
Checking object directories:   5% (13/256)   
Checking object directories:  11% (30/256)   
Checking object directories:  13% (35/256)   
Checking object directories:  22% (57/256)   
Checking object directories:  53% (137/256)   
Checking object directories:  81% (209/256)   
Checking object directories:  83% (213/256)   
Checking object directories:  85% (218/256)   
Checking object directories:  87% (223/256)   
Checking object directories:  88% (227/256)   
Checking object directories:  96% (246/256)   
Checking object directories:  97% (249/256)   
Checking object directories: 100% (256/256)   
Checking object directories: 100% (256/256), done.
dangling tag 88a23db671d20eb6a4384207bf24b8e0c667a288
dangling commit 381073887a81082128b84945fe07c96c400e86da
$ git show  88a23db671d20e
tag initial
Tagger: Stefan Naewe 
Date:   Thu Jan 21 08:51:05 2016 +0100

initial

commit d9e5baf52f472c49fd4fd1faeb6f0752dfe3980b
Author: Stefan Naewe 
Date:   Thu Jan 21 08:50:41 2016 +0100

add A

diff --git a/A b/A
new file mode 100644
index 000..f70f10e
--- /dev/null
+++ b/A
@@ -0,0 +1 @@
+A

$ git reflog

$ git gc
Counting objects: 6, done.
Delta compression using up to 2 threads.
Compressing objects:  33% (1/3)   
Compressing objects:  66% (2/3)   
Compressing objects: 100% (3/3)   
Compressing objects: 100% (3/3), done.
Writing objects:  16% (1/6)   
Writing objects:  33% (2/6)   
Writing objects:  50% (3/6)   
Writing objects:  66% (4/6)   
Writing objects:  83% (5/6)   
Writing objects: 100% (6/6)   
Writing objects: 100% (6/6), 

Re: Zombie tag

[stefan.naewe]

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 non-bare repo (R2) into B1
> - do 'git push B1 :tag-a' from R2 to delete the tag
> Now, in B1, 'git fsck' shows a dangling tag that can be identified
> as 'tag-a' from above. There's obviously no reflog in B1.
> I don't know how to get rid of that tag.

Just do 'git gc --prune=all' or 'git prune', stupid!

> A cleaned-up 'script' session of the above is attached.
> 
> The problem initially occurred on Windows with git 2.7.0 but could
> be reproduced on a Linux machine with git 2.7.0.
> 
> What's going on here ?

I guess one never stops learning when using git...

Stefan
-- 

/dev/random says: Socialism is the equal distribution of poverty.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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 is).

Is 'git am --keep-non-patch' what you're looking for ?

> 
> 
> Reproduction:
> 
> $ git log --oneline --decorate --graph --all
> * b41514b (HEAD) [baz] baz
> | * 5e31740 (master) [bar] bar
> |/
> * aaf5d34 [foo] foo
> $ git format-patch aaf5d34
> $ git checkout master
> $ git am 0001-baz-baz.patch
> $ git log --oneline --decorate --graph --all
> * d5161b8 (HEAD, master) baz
> * 5e31740 [bar] bar
> * aaf5d34 [foo] foo
> 
> I have omitted all output except for the `git log` output for brevity.
> As you can see, the commit resulting from `git am` has lost the "[bar]" 
> prefix from its commit message.
> 
> Looking at the patch,
> 
> $ cat 0001-baz-baz.patch
> From b41514be8a70fd44052bff0d3ce720373ec9cfd8 Mon Sep 17 00:00:00 2001
> From: Nathanael Huebbe 
> Date: Wed, 25 Nov 2015 15:28:09 +0100
> Subject: [PATCH] [baz] baz
> 
> ---
>  baz | 1 +
>  1 file changed, 1 insertion(+)
>  create mode 100644 baz
> 
> diff --git a/baz b/baz
> new file mode 100644
> index 000..7601807
> --- /dev/null
> +++ b/baz
> @@ -0,0 +1 @@
> +baz
> --
> 2.1.4
> 
> I see that the commit message contains the "[PATCH]"-prefix that `git am` is 
> supposed to strip,
> yet it seems to incorrectly continue to also strip the "[baz]"-prefix.
> 
> 
> Affected versions:
> I have reproduced the bug with versions 1.9.1, 2.1.4, and 2.6.3
> 
> 
> Severity:
> While I do not consider this a high priority bug, it becomes quite irksome in 
> some workflows.
> In my case, an upstream `svn` repository has the policy of using 
> "[branch-name]" prefixes
> to the commit messages, which are stripped whenever I transplant a commit 
> using the
> `git format-patch`/`git am` combination.
> 
> 
> 

HTH,
  Stefan
-- 

/dev/random says: Oxymoron: Slow speed.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

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

[stefan.naewe]

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
> 
> https://cdn.tutsplus.com/net/uploads/legacy/2081_gitwin/git-gui-stage.jpg
> 
> I'd like to open my editor with the "request.php".
> 
> Any chance to have that? Or do I miss something?

I have this in my .gitconfig:

[guitool "Edit/with GVim"]
cmd = gvim --remote-tab-silent $FILENAME
noconsole = yes
needsfile = yes

Works for me.

HTH,
  Stefan
-- 

/dev/random says: Why did Kamakazie pilots wear helmets???
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF

about rev-parse's quietness

[stefan.naewe]

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 log --oneline --abbrev-commit --decorate @{u}..

But I don't want to run that 'git log...' if there's no upstream configured
for HEAD (and I don't want to see any error!)

OK. That's a task for 'git rev-parse' I thought:

$ up=$(git rev-parse --verify --quiet @{u}) &&
  git log --left-right --oneline --abbrev-commit --decorate $up
fatal: no upstream configured for branch 'master'

Wait. What?

I thought rev-parse with '--verify' and '--quiet' is just that - quiet -
in case "...the first argument is not a valid object name" ?

Let's see:
$ git rev-parse --verify --quiet master@{xyz} || echo No
No

$ git rev-parse --verify --quiet master@{u} || echo No
fatal: no upstream configured for branch 'master'
No

I don't want to see that error (and I know I could just redirect stdout/stderr 
to /dev/null ...)

So: Are my expectations about 'rev-parse --verify --quiet' wrong or am I doing
something stupid ?

Thanks,
  Stefan
-- 

/dev/random says: Disclaimer: Written by a highly caffeinated mammal.
python -c "print 
'73746566616e2e6e616577654061746c61732d656c656b74726f6e696b2e636f6d'.decode('hex')"
 
GPG Key fingerprint = 2DF5 E01B 09C3 7501 BCA9  9666 829B 49C5 9221 27AF
N�r��yb�X��ǧv�^�)޺{.n�+ا���ܨ}���Ơz�:+v���zZ+��+zf���h���~i���z��w���?�&�)ߢf

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

[stefan.naewe]

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 insertions(+), 19 deletions(-)

diff --git a/Documentation/gittutorial-2.txt b/Documentation/gittutorial-2.txt
index 3109ea8..1901af7 100644
--- a/Documentation/gittutorial-2.txt
+++ b/Documentation/gittutorial-2.txt
@@ -368,17 +368,18 @@ situation:
 
 
 $ git status
-# On branch master
-# Changes to be committed:
-#   (use git reset HEAD file... to unstage)
-#
-#   new file: closing.txt
-#
-# Changes not staged for commit:
-#   (use git add file... to update what will be committed)
-#
-#   modified: file.txt
-#
+On branch master
+Changes to be committed:
+  (use git reset HEAD file... to unstage)
+
+new file:   closing.txt
+
+Changes not staged for commit:
+  (use git add file... to update what will be committed)
+  (use git checkout -- file... to discard changes in working directory)
+
+modified:   file.txt
+
 
 
 Since the current state of closing.txt is cached in the index file,
diff --git a/Documentation/gittutorial.txt b/Documentation/gittutorial.txt
index 8262196..8715244 100644
--- a/Documentation/gittutorial.txt
+++ b/Documentation/gittutorial.txt
@@ -107,14 +107,15 @@ summary of the situation with 'git status':
 
 
 $ git status
-# On branch master
-# Changes to be committed:
-#   (use git reset HEAD file... to unstage)
-#
-#  modified:   file1
-#  modified:   file2
-#  modified:   file3
-#
+On branch master
+Changes to be committed:
+Your branch is up-to-date with 'origin/master'.
+  (use git reset HEAD file... to unstage)
+
+modified:   file1
+modified:   file2
+modified:   file3
+
 
 
 If you need to make any further adjustments, do so now, and then add any
-- 
1.9.2.msysgit.0.2270.g8768113

--
To unsubscribe from this list: send the line unsubscribe git in
the body of a message to majord...@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html