Hello Beautiful

2018-07-22 Thread Jack
Hi Dear, my name is Jack and i am seeking for a relationship in which i will 
feel loved after a series of failed relationships. 

I am hoping that you would be interested and we could possibly get to know each 
other more if you do not mind. I am open to answering questions from you as i 
think my approach is a little inappropriate. Hope to hear back from you.

Jack.


Hello Beautiful

2018-07-12 Thread Jack
Hi Dear, my name is Jack and i am seeking for a relationship in which i will 
feel loved after a series of failed relationships. 

I am hoping that you would be interested and we could possibly get to know each 
other more if you do not mind. I am open to answering questions from you as i 
think my approach is a little inappropriate. Hope to hear back from you.

Jack.


Git not creating new directory when cloning

2018-06-21 Thread Jack Adrian Zappa
Hi, I was trying to clone a repo into a non-existent directory. but it
gave me a failure:

$  git clone  https://github.com/jelera/vim-javascript-syntax.git
~/.vim/bundle/vim-javascript-syntax
fatal: destination path
'/home/username/.vim/bundle/vim-javascript-syntax' already exists and
is not an empty directory.

(the command was taken from install procedure from
https://github.com/jelera/vim-javascript-syntax)

The directory "/home/username/.vim/bundle" already existed, but
"'/home/username/.vim/bundle/vim-javascript-syntax" did not.  Upon
creating the "vim-javascript-syntax" sub-directory, the clone command
succeeded.  From what I read from the docs
(https://git-scm.com/docs/git-clone):

> git clone [--template=]
> [-l] [-s] [--no-hardlinks] [-q] [-n] [--bare] [--mirror]
> [-o ] [-b ] [-u ] [--reference ]
> [--dissociate] [--separate-git-dir ]
> [--depth ] [--[no-]single-branch] [--no-tags]
> [--recurse-submodules[=]] [--[no-]shallow-submodules]
>  [--jobs ] [--]  []
...
> 
>
> The name of a new directory to clone into. The "humanish" part of the source 
> repository is used if no directory is explicitly given (repo for 
> /path/to/repo.git and foo for host.xz:foo/.git). Cloning into an existing 
> directory is only allowed if the directory is empty.

Which to me, implies that the directory doesn't have to exist prior to
cloning.  So is this a bug or a misunderstanding?

Thanks,


A


Hello Beautiful

2018-03-25 Thread Jack
Hi Dear, my name is Jack and i am seeking for a relationship in which i will 
feel loved after a series of failed relationships. 

I am hoping that you would be interested and we could possibly get to know each 
other more if you do not mind. I am open to answering questions from you as i 
think my approach is a little inappropriate. Hope to hear back from you.

Jack.


Hello Beautiful

2018-03-25 Thread Jack
Hi Dear, my name is Jack and i am seeking for a relationship in which i will 
feel loved after a series of failed relationships. 

I am hoping that you would be interested and we could possibly get to know each 
other more if you do not mind. I am open to answering questions from you as i 
think my approach is a little inappropriate. Hope to hear back from you.

Jack.


Hello Beautiful

2018-03-25 Thread Jack
Cześć Drogi, nazywam się Jack i szukam związku, w którym będę czuć się kochany 
po serii nieudanych związków.

Mam nadzieję, że byłbyś zainteresowany i moglibyśmy się lepiej poznać, jeśli 
nie masz nic przeciwko. Jestem otwarty na udzielanie odpowiedzi na pytania od 
ciebie, ponieważ uważam, że moje podejście jest trochę niewłaściwe. Mam 
nadzieję, że odezwę się od ciebie.

Jacek.


Hi Pretty,

2018-03-18 Thread Jack
Hi Dear, my name is Jack and i am seeking for a relationship in which i will 
feel loved after a series of failed relationships. 

I am hoping that you would be interested and we could possibly get to know each 
other more if you do not mind. I am open to answering questions from you as i 
think my approach is a little inappropriate. Hope to hear back from you.

Jack.


NICE TO MEET YOU,

2018-03-18 Thread Jack
Hi Dear, my name is Jack and i am seeking for a relationship in which i will 
feel loved after a series of failed relationships. 

I am hoping that you would be interested and we could possibly get to know each 
other more if you do not mind. I am open to answering questions from you as i 
think my approach is a little inappropriate. Hope to hear back from you.

Jack.


Hello Beautiful

2018-03-04 Thread jack
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.


Hello Beautiful

2018-02-10 Thread jack
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.


Re: Missing ? wildcard character in gitignore documentation

2018-01-29 Thread Jack F
Ah. Yes it does. Apologies. Maybe a "See glob(7) for more pattern
matching options, including ! ? [] *"

Thank you very much.

Cheers.

From,
Jack

On 29/01/18 15:47, Randall S. Becker wrote:
> On January 29, 2018 6:30 AM, Jack F wrote:
>> I have just noticed that the documentation for gitignore is missing
>> documentation on using the ? to match any single character. I have included
>> a example below with git version 2.14.1.
>>
>> |11:05:09 j ~/Development/ls-ignore [master] $ git status On branch
>> master Your branch is up-to-date with 'origin/master'. nothing to commit,
>> working tree clean 11:05:11 j ~/Development/ls-ignore [master] $ cat
>> .gitignore *~ node_modules yarn* 11:05:21 j ~/Development/ls-ignore
>> [master] $ touch test.swo 11:05:31 j ~/Development/ls-ignore [master]?1 $
>> git status On branch master Your branch is up-to-date with 'origin/master'.
>> Untracked files: (use "git add ..." to include in what will be 
>> committed)
>> test.swo nothing added to commit but untracked files present (use "git add"
>> to track) 11:05:35 j ~/Development/ls-ignore [master]?1 $ echo "*.sw?" >>
>> .gitignore 11:05:40 j ~/Development/ls-ignore [master]≠1 $ cat .gitignore *~
>> node_modules
>> yarn* *.sw? 11:05:51 j ~/Development/ls-ignore [master]≠1 $ git status On
>> branch master Your branch is up-to-date with 'origin/master'. Changes not
>> staged for commit: (use "git add ..." to update what will be
>> committed) (use "git checkout -- ..." to discard changes in working
>> directory) modified: .gitignore no changes added to commit (use "git add"
>> and/or "git commit -a")|
>>
>>
>>
>> Noticed it when checking an npm package (ignore) that uses the
>> documentation (https://git-scm.com/docs/gitignore) to determine its
>> functionality. It is documented in https://git-scm.com/book/en/v2/Git-
>> Basics-Recording-Changes-to-the-Repository#Ignoring-Files
> The implication of support for ? is there through the following paragraph 
> from the gitignore documentation:
>
> "Otherwise, Git treats the pattern as a shell glob suitable for 
> consumption by fnmatch(3)
> with the FNM_PATHNAME flag: wildcards in the pattern will not match a / 
> in the
> pathname. For example, "Documentation/*.html" matches 
> "Documentation/git.html"
> but not "Documentation/ppc/ppc.html" or 
> "tools/perf/Documentation/perf.html"."
>
> Of course you have to go read fnmatch(3), so it might be good for expand on 
> this here :).
>
> Cheers,
> Randall
>
> -- Brief whoami:
>  NonStop developer since approximately 2112884442
>  UNIX developer since approximately 421664400
> -- In my real life, I talk too much.
>
>
>

-- 
https://bytes.nz
https://keybase.io/bytesnz




Missing ? wildcard character in gitignore documentation

2018-01-29 Thread Jack F
Hello,

I have just noticed that the documentation for gitignore is missing
documentation on using the ? to match any single character. I have
included a example below with git version 2.14.1.

|11:05:09 j ~/Development/ls-ignore [master] $ git status On branch
master Your branch is up-to-date with 'origin/master'. nothing to
commit, working tree clean 11:05:11 j ~/Development/ls-ignore [master] $
cat .gitignore *~ node_modules yarn* 11:05:21 j ~/Development/ls-ignore
[master] $ touch test.swo 11:05:31 j ~/Development/ls-ignore [master]?1
$ git status On branch master Your branch is up-to-date with
'origin/master'. Untracked files: (use "git add ..." to include in
what will be committed) test.swo nothing added to commit but untracked
files present (use "git add" to track) 11:05:35 j
~/Development/ls-ignore [master]?1 $ echo "*.sw?" >> .gitignore 11:05:40
j ~/Development/ls-ignore [master]≠1 $ cat .gitignore *~ node_modules
yarn* *.sw? 11:05:51 j ~/Development/ls-ignore [master]≠1 $ git status
On branch master Your branch is up-to-date with 'origin/master'. Changes
not staged for commit: (use "git add ..." to update what will be
committed) (use "git checkout -- ..." to discard changes in
working directory) modified: .gitignore no changes added to commit (use
"git add" and/or "git commit -a")|



Noticed it when checking an npm package (ignore) that uses the
documentation (https://git-scm.com/docs/gitignore) to determine its
functionality. It is documented in
https://git-scm.com/book/en/v2/Git-Basics-Recording-Changes-to-the-Repository#Ignoring-Files

Cheers.

From,
Jack

https://bytes.nz
https://keybase.io/bytesnz



Hello Beautiful,

2017-11-18 Thread jack
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.


Hello Beautiful,

2017-08-05 Thread Jack
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.


Hello Beautiful,

2017-07-29 Thread Jack
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.


Nice To know you,

2017-07-27 Thread Jack
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.


Hello Beautiful,

2017-07-22 Thread Jack
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.


Hello dear

2017-07-16 Thread Jack

Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more. 
Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon. 

Jack.


Hello Beautiful,

2017-07-16 Thread Jack
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.


Hello Beautiful,

2017-04-28 Thread Jack
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.


Hello Beautiful,

2017-03-14 Thread Jack
Good day dear, i hope this mail meets you well? my name is Jack, from the U.S. 
I know this may seem inappropriate so i ask for your forgiveness but i wish to 
get to know you better, if I may be so bold. I consider myself an easy-going 
man, adventurous, honest and fun loving person but I am currently looking for a 
relationship in which I will feel loved. I promise to answer any question that 
you may want to ask me...all i need is just your attention and the chance to 
know you more.

Please tell me more about yourself, if you do not mind. Hope to hear back from 
you soon.

Jack.


Re: Trying to use xfuncname without success.

2017-02-08 Thread Jack Adrian Zappa
>  where it has grabbed a line at 126 and is using that for the hunk header.

When I say that, I mean that it is using that line for *every* hunk
header, for every change, regardless if it has passed a hunk head that
it should have matched.





On Wed, Feb 8, 2017 at 7:01 PM, Jack Adrian Zappa <adrianh@gmail.com> wrote:
> Tried to copy the .git/config file over to the non-working repository
> and it didn't seem to do anything.  Could the git database be
> partially corrupted?
>
> On Wed, Feb 8, 2017 at 7:00 PM, Jack Adrian Zappa <adrianh@gmail.com> 
> wrote:
>> Well, it mostly works, but I'm getting some weirdness where it has
>> grabbed a line at 126 and is using that for the hunk header.  Strange
>> thing is, I move the file to another repository, commit it, make a
>> change to the fileand do a diff, and it gets the correct hunk header.
>>
>> I'm at a loss. :(
>>
>> On Wed, Feb 8, 2017 at 4:12 PM, Jack Adrian Zappa <adrianh@gmail.com> 
>> wrote:
>>> That was it.  I have a .gitattributes file in my home directory.
>>> Ahhh, but it's not in my %userprofile% directory, but in my ~
>>> directory.
>>>
>>> A bit confusing having 2 home directories.  I made a link to my
>>> .gitconfig, but forgot to make a link to my .gitattributes.
>>>
>>> Thanks.
>>>
>>>
>>> A
>>>
>>> On Wed, Feb 8, 2017 at 4:05 PM, Samuel Lijin <sxli...@gmail.com> wrote:
>>>> Double check .gitattributes?
>>>>
>>>> On Feb 8, 2017 2:58 PM, "Jack Adrian Zappa" <adrianh@gmail.com> wrote:
>>>>>
>>>>> Thanks Samuel,
>>>>>
>>>>> That example showed that there must be something wrong in my .git
>>>>> directory, because with it, I'm getting the correct output.  Moving
>>>>> the same lines to my .git/config didn't work.
>>>>>
>>>>> On Wed, Feb 8, 2017 at 3:46 PM, Samuel Lijin <sxli...@gmail.com> wrote:
>>>>> > I just put this togther: https://github.com/sxlijin/xfuncname-test
>>>>> >
>>>>> > Try cloning and then for any of config1 thru 3,
>>>>> >
>>>>> > $ cp configX .git/config
>>>>> > $ git diff HEAD^ -- test.natvis
>>>>> >
>>>>> > On Wed, Feb 8, 2017 at 2:42 PM, Jack Adrian Zappa
>>>>> > <adrianh@gmail.com> wrote:
>>>>> >> Thanks Samuel,
>>>>> >>
>>>>> >> So, the question is, what is causing this problem on my system?
>>>>> >>
>>>>> >> Anyone have an idea to help diagnose this problem?
>>>>> >>
>>>>> >> On Wed, Feb 8, 2017 at 3:24 PM, Samuel Lijin <sxli...@gmail.com> wrote:
>>>>> >>> On Windows 7, it works for me in both CMD and Git Bash:
>>>>> >>>
>>>>> >>> $ git --version
>>>>> >>> git version 2.11.0.windows.3
>>>>> >>>
>>>>> >>> $ git diff HEAD^ --word-diff
>>>>> >>> diff --git a/test.natvis b/test.natvis
>>>>> >>> index 93396ad..1233b8c 100644
>>>>> >>> --- a/test.natvis
>>>>> >>> +++ b/test.natvis
>>>>> >>> @@ -18,6 +18,7 @@ test
>>>>> >>>
>>>>> >>>
>>>>> >>>   
>>>>> >>>   {+added_var+}
>>>>> >>>
>>>>> >>>
>>>>> >>>   var2
>>>>> >>>
>>>>> >>> On Wed, Feb 8, 2017 at 12:37 PM, René Scharfe <l@web.de> wrote:
>>>>> >>>> Am 08.02.2017 um 18:11 schrieb Jack Adrian Zappa:
>>>>> >>>>> Thanks Rene, but you seem to have missed the point.  NOTHING is
>>>>> >>>>> working.  No matter what I put there, it doesn't seem to get
>>>>> >>>>> matched.
>>>>> >>>>
>>>>> >>>> I'm not so sure about that.  With your example I get this diff
>>>>> >>>> without
>>>>> >>>> setting diff.natvis.xfuncname:
>>>>> >>>>
>>>>> >>>> diff --git a/a.natvis b/a.natvis
>>>>> >>>> index 7f9bdf5..bc3c090 100644
>>

Re: Trying to use xfuncname without success.

2017-02-08 Thread Jack Adrian Zappa
Tried to copy the .git/config file over to the non-working repository
and it didn't seem to do anything.  Could the git database be
partially corrupted?

On Wed, Feb 8, 2017 at 7:00 PM, Jack Adrian Zappa <adrianh@gmail.com> wrote:
> Well, it mostly works, but I'm getting some weirdness where it has
> grabbed a line at 126 and is using that for the hunk header.  Strange
> thing is, I move the file to another repository, commit it, make a
> change to the fileand do a diff, and it gets the correct hunk header.
>
> I'm at a loss. :(
>
> On Wed, Feb 8, 2017 at 4:12 PM, Jack Adrian Zappa <adrianh@gmail.com> 
> wrote:
>> That was it.  I have a .gitattributes file in my home directory.
>> Ahhh, but it's not in my %userprofile% directory, but in my ~
>> directory.
>>
>> A bit confusing having 2 home directories.  I made a link to my
>> .gitconfig, but forgot to make a link to my .gitattributes.
>>
>> Thanks.
>>
>>
>> A
>>
>> On Wed, Feb 8, 2017 at 4:05 PM, Samuel Lijin <sxli...@gmail.com> wrote:
>>> Double check .gitattributes?
>>>
>>> On Feb 8, 2017 2:58 PM, "Jack Adrian Zappa" <adrianh@gmail.com> wrote:
>>>>
>>>> Thanks Samuel,
>>>>
>>>> That example showed that there must be something wrong in my .git
>>>> directory, because with it, I'm getting the correct output.  Moving
>>>> the same lines to my .git/config didn't work.
>>>>
>>>> On Wed, Feb 8, 2017 at 3:46 PM, Samuel Lijin <sxli...@gmail.com> wrote:
>>>> > I just put this togther: https://github.com/sxlijin/xfuncname-test
>>>> >
>>>> > Try cloning and then for any of config1 thru 3,
>>>> >
>>>> > $ cp configX .git/config
>>>> > $ git diff HEAD^ -- test.natvis
>>>> >
>>>> > On Wed, Feb 8, 2017 at 2:42 PM, Jack Adrian Zappa
>>>> > <adrianh@gmail.com> wrote:
>>>> >> Thanks Samuel,
>>>> >>
>>>> >> So, the question is, what is causing this problem on my system?
>>>> >>
>>>> >> Anyone have an idea to help diagnose this problem?
>>>> >>
>>>> >> On Wed, Feb 8, 2017 at 3:24 PM, Samuel Lijin <sxli...@gmail.com> wrote:
>>>> >>> On Windows 7, it works for me in both CMD and Git Bash:
>>>> >>>
>>>> >>> $ git --version
>>>> >>> git version 2.11.0.windows.3
>>>> >>>
>>>> >>> $ git diff HEAD^ --word-diff
>>>> >>> diff --git a/test.natvis b/test.natvis
>>>> >>> index 93396ad..1233b8c 100644
>>>> >>> --- a/test.natvis
>>>> >>> +++ b/test.natvis
>>>> >>> @@ -18,6 +18,7 @@ test
>>>> >>>
>>>> >>>
>>>> >>>   
>>>> >>>   {+added_var+}
>>>> >>>
>>>> >>>
>>>> >>>   var2
>>>> >>>
>>>> >>> On Wed, Feb 8, 2017 at 12:37 PM, René Scharfe <l@web.de> wrote:
>>>> >>>> Am 08.02.2017 um 18:11 schrieb Jack Adrian Zappa:
>>>> >>>>> Thanks Rene, but you seem to have missed the point.  NOTHING is
>>>> >>>>> working.  No matter what I put there, it doesn't seem to get
>>>> >>>>> matched.
>>>> >>>>
>>>> >>>> I'm not so sure about that.  With your example I get this diff
>>>> >>>> without
>>>> >>>> setting diff.natvis.xfuncname:
>>>> >>>>
>>>> >>>> diff --git a/a.natvis b/a.natvis
>>>> >>>> index 7f9bdf5..bc3c090 100644
>>>> >>>> --- a/a.natvis
>>>> >>>> +++ b/a.natvis
>>>> >>>> @@ -19,7 +19,7 @@
>>>> >>>> xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010;>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> -  added_var
>>>> >>>> +  added_vars
>>>> >>>>
>>>> >>>>
>>>> >>>>var2
>>>> >>>>
>>>> >>>> Note the XML namespace in the hunk header.  It's put there by the
>>>> >>>> default rule because "xmlns" starts at the beginning of the line.
>>>> >>>> Your
>>>> >>>> diff has nothing there, which means the default rule is not used,
>>>> >>>> i.e.
>>>> >>>> your user-defined rule is in effect.
>>>> >>>>
>>>> >>>> Come to think of it, this line break in the middle of the
>>>> >>>> AutoVisualizer
>>>> >>>> tab might have been added by your email client unintentionally, so
>>>> >>>> that
>>>> >>>> we use different test files, which then of course results in
>>>> >>>> different
>>>> >>>> diffs.  Is that the case?
>>>> >>>>
>>>> >>>> Anyway, if I run the following two commands:
>>>> >>>>
>>>> >>>> $ git config diff.natvis.xfuncname "^[\t ]*<Type[\t
>>>> >>>> ]+Name=\"([^\"]+)\".*$"
>>>> >>>> $ echo '*.natvis diff=natvis' >.gitattributes
>>>> >>>>
>>>> >>>> ... then I get this, both on Linux (git version 2.11.1) and on
>>>> >>>> Windows
>>>> >>>> (git version 2.11.1.windows.1):
>>>> >>>>
>>>> >>>> diff --git a/a.natvis b/a.natvis
>>>> >>>> index 7f9bdf5..bc3c090 100644
>>>> >>>> --- a/a.natvis
>>>> >>>> +++ b/a.natvis
>>>> >>>> @@ -19,7 +19,7 @@ test
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> -  added_var
>>>> >>>> +  added_vars
>>>> >>>>
>>>> >>>>
>>>> >>>>var2
>>>> >>>>
>>>> >>>>> Just to be sure, I tested your regex and again it didn't work.
>>>> >>>>
>>>> >>>> At this point I'm out of ideas, sorry. :(  The only way I was able to
>>>> >>>> break it was due to mistyping the extension as "netvis" several times
>>>> >>>> for some reason.
>>>> >>>>
>>>> >>>> René


Re: Trying to use xfuncname without success.

2017-02-08 Thread Jack Adrian Zappa
Well, it mostly works, but I'm getting some weirdness where it has
grabbed a line at 126 and is using that for the hunk header.  Strange
thing is, I move the file to another repository, commit it, make a
change to the fileand do a diff, and it gets the correct hunk header.

I'm at a loss. :(

On Wed, Feb 8, 2017 at 4:12 PM, Jack Adrian Zappa <adrianh@gmail.com> wrote:
> That was it.  I have a .gitattributes file in my home directory.
> Ahhh, but it's not in my %userprofile% directory, but in my ~
> directory.
>
> A bit confusing having 2 home directories.  I made a link to my
> .gitconfig, but forgot to make a link to my .gitattributes.
>
> Thanks.
>
>
> A
>
> On Wed, Feb 8, 2017 at 4:05 PM, Samuel Lijin <sxli...@gmail.com> wrote:
>> Double check .gitattributes?
>>
>> On Feb 8, 2017 2:58 PM, "Jack Adrian Zappa" <adrianh@gmail.com> wrote:
>>>
>>> Thanks Samuel,
>>>
>>> That example showed that there must be something wrong in my .git
>>> directory, because with it, I'm getting the correct output.  Moving
>>> the same lines to my .git/config didn't work.
>>>
>>> On Wed, Feb 8, 2017 at 3:46 PM, Samuel Lijin <sxli...@gmail.com> wrote:
>>> > I just put this togther: https://github.com/sxlijin/xfuncname-test
>>> >
>>> > Try cloning and then for any of config1 thru 3,
>>> >
>>> > $ cp configX .git/config
>>> > $ git diff HEAD^ -- test.natvis
>>> >
>>> > On Wed, Feb 8, 2017 at 2:42 PM, Jack Adrian Zappa
>>> > <adrianh@gmail.com> wrote:
>>> >> Thanks Samuel,
>>> >>
>>> >> So, the question is, what is causing this problem on my system?
>>> >>
>>> >> Anyone have an idea to help diagnose this problem?
>>> >>
>>> >> On Wed, Feb 8, 2017 at 3:24 PM, Samuel Lijin <sxli...@gmail.com> wrote:
>>> >>> On Windows 7, it works for me in both CMD and Git Bash:
>>> >>>
>>> >>> $ git --version
>>> >>> git version 2.11.0.windows.3
>>> >>>
>>> >>> $ git diff HEAD^ --word-diff
>>> >>> diff --git a/test.natvis b/test.natvis
>>> >>> index 93396ad..1233b8c 100644
>>> >>> --- a/test.natvis
>>> >>> +++ b/test.natvis
>>> >>> @@ -18,6 +18,7 @@ test
>>> >>>
>>> >>>
>>> >>>   
>>> >>>   {+added_var+}
>>> >>>
>>> >>>
>>> >>>   var2
>>> >>>
>>> >>> On Wed, Feb 8, 2017 at 12:37 PM, René Scharfe <l@web.de> wrote:
>>> >>>> Am 08.02.2017 um 18:11 schrieb Jack Adrian Zappa:
>>> >>>>> Thanks Rene, but you seem to have missed the point.  NOTHING is
>>> >>>>> working.  No matter what I put there, it doesn't seem to get
>>> >>>>> matched.
>>> >>>>
>>> >>>> I'm not so sure about that.  With your example I get this diff
>>> >>>> without
>>> >>>> setting diff.natvis.xfuncname:
>>> >>>>
>>> >>>> diff --git a/a.natvis b/a.natvis
>>> >>>> index 7f9bdf5..bc3c090 100644
>>> >>>> --- a/a.natvis
>>> >>>> +++ b/a.natvis
>>> >>>> @@ -19,7 +19,7 @@
>>> >>>> xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010;>
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> -  added_var
>>> >>>> +  added_vars
>>> >>>>
>>> >>>>
>>> >>>>var2
>>> >>>>
>>> >>>> Note the XML namespace in the hunk header.  It's put there by the
>>> >>>> default rule because "xmlns" starts at the beginning of the line.
>>> >>>> Your
>>> >>>> diff has nothing there, which means the default rule is not used,
>>> >>>> i.e.
>>> >>>> your user-defined rule is in effect.
>>> >>>>
>>> >>>> Come to think of it, this line break in the middle of the
>>> >>>> AutoVisualizer
>>> >>>> tab might have been added by your email client unintentionally, so
>>> >>>> that
>>> >>>> we use different test files, which then of course results in
>>> >>>> different
>>> >>>> diffs.  Is that the case?
>>> >>>>
>>> >>>> Anyway, if I run the following two commands:
>>> >>>>
>>> >>>> $ git config diff.natvis.xfuncname "^[\t ]*<Type[\t
>>> >>>> ]+Name=\"([^\"]+)\".*$"
>>> >>>> $ echo '*.natvis diff=natvis' >.gitattributes
>>> >>>>
>>> >>>> ... then I get this, both on Linux (git version 2.11.1) and on
>>> >>>> Windows
>>> >>>> (git version 2.11.1.windows.1):
>>> >>>>
>>> >>>> diff --git a/a.natvis b/a.natvis
>>> >>>> index 7f9bdf5..bc3c090 100644
>>> >>>> --- a/a.natvis
>>> >>>> +++ b/a.natvis
>>> >>>> @@ -19,7 +19,7 @@ test
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> -  added_var
>>> >>>> +  added_vars
>>> >>>>
>>> >>>>
>>> >>>>var2
>>> >>>>
>>> >>>>> Just to be sure, I tested your regex and again it didn't work.
>>> >>>>
>>> >>>> At this point I'm out of ideas, sorry. :(  The only way I was able to
>>> >>>> break it was due to mistyping the extension as "netvis" several times
>>> >>>> for some reason.
>>> >>>>
>>> >>>> René


Re: Trying to use xfuncname without success.

2017-02-08 Thread Jack Adrian Zappa
That was it.  I have a .gitattributes file in my home directory.
Ahhh, but it's not in my %userprofile% directory, but in my ~
directory.

A bit confusing having 2 home directories.  I made a link to my
.gitconfig, but forgot to make a link to my .gitattributes.

Thanks.


A

On Wed, Feb 8, 2017 at 4:05 PM, Samuel Lijin <sxli...@gmail.com> wrote:
> Double check .gitattributes?
>
> On Feb 8, 2017 2:58 PM, "Jack Adrian Zappa" <adrianh@gmail.com> wrote:
>>
>> Thanks Samuel,
>>
>> That example showed that there must be something wrong in my .git
>> directory, because with it, I'm getting the correct output.  Moving
>> the same lines to my .git/config didn't work.
>>
>> On Wed, Feb 8, 2017 at 3:46 PM, Samuel Lijin <sxli...@gmail.com> wrote:
>> > I just put this togther: https://github.com/sxlijin/xfuncname-test
>> >
>> > Try cloning and then for any of config1 thru 3,
>> >
>> > $ cp configX .git/config
>> > $ git diff HEAD^ -- test.natvis
>> >
>> > On Wed, Feb 8, 2017 at 2:42 PM, Jack Adrian Zappa
>> > <adrianh@gmail.com> wrote:
>> >> Thanks Samuel,
>> >>
>> >> So, the question is, what is causing this problem on my system?
>> >>
>> >> Anyone have an idea to help diagnose this problem?
>> >>
>> >> On Wed, Feb 8, 2017 at 3:24 PM, Samuel Lijin <sxli...@gmail.com> wrote:
>> >>> On Windows 7, it works for me in both CMD and Git Bash:
>> >>>
>> >>> $ git --version
>> >>> git version 2.11.0.windows.3
>> >>>
>> >>> $ git diff HEAD^ --word-diff
>> >>> diff --git a/test.natvis b/test.natvis
>> >>> index 93396ad..1233b8c 100644
>> >>> --- a/test.natvis
>> >>> +++ b/test.natvis
>> >>> @@ -18,6 +18,7 @@ test
>> >>>
>> >>>
>> >>>   
>> >>>   {+added_var+}
>> >>>
>> >>>
>> >>>   var2
>> >>>
>> >>> On Wed, Feb 8, 2017 at 12:37 PM, René Scharfe <l@web.de> wrote:
>> >>>> Am 08.02.2017 um 18:11 schrieb Jack Adrian Zappa:
>> >>>>> Thanks Rene, but you seem to have missed the point.  NOTHING is
>> >>>>> working.  No matter what I put there, it doesn't seem to get
>> >>>>> matched.
>> >>>>
>> >>>> I'm not so sure about that.  With your example I get this diff
>> >>>> without
>> >>>> setting diff.natvis.xfuncname:
>> >>>>
>> >>>> diff --git a/a.natvis b/a.natvis
>> >>>> index 7f9bdf5..bc3c090 100644
>> >>>> --- a/a.natvis
>> >>>> +++ b/a.natvis
>> >>>> @@ -19,7 +19,7 @@
>> >>>> xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010;>
>> >>>>
>> >>>>
>> >>>>
>> >>>> -  added_var
>> >>>> +  added_vars
>> >>>>
>> >>>>
>> >>>>var2
>> >>>>
>> >>>> Note the XML namespace in the hunk header.  It's put there by the
>> >>>> default rule because "xmlns" starts at the beginning of the line.
>> >>>> Your
>> >>>> diff has nothing there, which means the default rule is not used,
>> >>>> i.e.
>> >>>> your user-defined rule is in effect.
>> >>>>
>> >>>> Come to think of it, this line break in the middle of the
>> >>>> AutoVisualizer
>> >>>> tab might have been added by your email client unintentionally, so
>> >>>> that
>> >>>> we use different test files, which then of course results in
>> >>>> different
>> >>>> diffs.  Is that the case?
>> >>>>
>> >>>> Anyway, if I run the following two commands:
>> >>>>
>> >>>> $ git config diff.natvis.xfuncname "^[\t ]*<Type[\t
>> >>>> ]+Name=\"([^\"]+)\".*$"
>> >>>> $ echo '*.natvis diff=natvis' >.gitattributes
>> >>>>
>> >>>> ... then I get this, both on Linux (git version 2.11.1) and on
>> >>>> Windows
>> >>>> (git version 2.11.1.windows.1):
>> >>>>
>> >>>> diff --git a/a.natvis b/a.natvis
>> >>>> index 7f9bdf5..bc3c090 100644
>> >>>> --- a/a.natvis
>> >>>> +++ b/a.natvis
>> >>>> @@ -19,7 +19,7 @@ test
>> >>>>
>> >>>>
>> >>>>
>> >>>> -  added_var
>> >>>> +  added_vars
>> >>>>
>> >>>>
>> >>>>var2
>> >>>>
>> >>>>> Just to be sure, I tested your regex and again it didn't work.
>> >>>>
>> >>>> At this point I'm out of ideas, sorry. :(  The only way I was able to
>> >>>> break it was due to mistyping the extension as "netvis" several times
>> >>>> for some reason.
>> >>>>
>> >>>> René


Re: Trying to use xfuncname without success.

2017-02-08 Thread Jack Adrian Zappa
Thanks Samuel,

That example showed that there must be something wrong in my .git
directory, because with it, I'm getting the correct output.  Moving
the same lines to my .git/config didn't work.

On Wed, Feb 8, 2017 at 3:46 PM, Samuel Lijin <sxli...@gmail.com> wrote:
> I just put this togther: https://github.com/sxlijin/xfuncname-test
>
> Try cloning and then for any of config1 thru 3,
>
> $ cp configX .git/config
> $ git diff HEAD^ -- test.natvis
>
> On Wed, Feb 8, 2017 at 2:42 PM, Jack Adrian Zappa <adrianh@gmail.com> 
> wrote:
>> Thanks Samuel,
>>
>> So, the question is, what is causing this problem on my system?
>>
>> Anyone have an idea to help diagnose this problem?
>>
>> On Wed, Feb 8, 2017 at 3:24 PM, Samuel Lijin <sxli...@gmail.com> wrote:
>>> On Windows 7, it works for me in both CMD and Git Bash:
>>>
>>> $ git --version
>>> git version 2.11.0.windows.3
>>>
>>> $ git diff HEAD^ --word-diff
>>> diff --git a/test.natvis b/test.natvis
>>> index 93396ad..1233b8c 100644
>>> --- a/test.natvis
>>> +++ b/test.natvis
>>> @@ -18,6 +18,7 @@ test
>>>
>>>
>>>   
>>>   {+added_var+}
>>>
>>>
>>>   var2
>>>
>>> On Wed, Feb 8, 2017 at 12:37 PM, René Scharfe <l@web.de> wrote:
>>>> Am 08.02.2017 um 18:11 schrieb Jack Adrian Zappa:
>>>>> Thanks Rene, but you seem to have missed the point.  NOTHING is
>>>>> working.  No matter what I put there, it doesn't seem to get matched.
>>>>
>>>> I'm not so sure about that.  With your example I get this diff without
>>>> setting diff.natvis.xfuncname:
>>>>
>>>> diff --git a/a.natvis b/a.natvis
>>>> index 7f9bdf5..bc3c090 100644
>>>> --- a/a.natvis
>>>> +++ b/a.natvis
>>>> @@ -19,7 +19,7 @@ 
>>>> xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010;>
>>>>
>>>>
>>>>
>>>> -  added_var
>>>> +  added_vars
>>>>
>>>>
>>>>var2
>>>>
>>>> Note the XML namespace in the hunk header.  It's put there by the
>>>> default rule because "xmlns" starts at the beginning of the line.  Your
>>>> diff has nothing there, which means the default rule is not used, i.e.
>>>> your user-defined rule is in effect.
>>>>
>>>> Come to think of it, this line break in the middle of the AutoVisualizer
>>>> tab might have been added by your email client unintentionally, so that
>>>> we use different test files, which then of course results in different
>>>> diffs.  Is that the case?
>>>>
>>>> Anyway, if I run the following two commands:
>>>>
>>>> $ git config diff.natvis.xfuncname "^[\t ]*<Type[\t ]+Name=\"([^\"]+)\".*$"
>>>> $ echo '*.natvis diff=natvis' >.gitattributes
>>>>
>>>> ... then I get this, both on Linux (git version 2.11.1) and on Windows
>>>> (git version 2.11.1.windows.1):
>>>>
>>>> diff --git a/a.natvis b/a.natvis
>>>> index 7f9bdf5..bc3c090 100644
>>>> --- a/a.natvis
>>>> +++ b/a.natvis
>>>> @@ -19,7 +19,7 @@ test
>>>>
>>>>
>>>>
>>>> -  added_var
>>>> +  added_vars
>>>>
>>>>
>>>>var2
>>>>
>>>>> Just to be sure, I tested your regex and again it didn't work.
>>>>
>>>> At this point I'm out of ideas, sorry. :(  The only way I was able to
>>>> break it was due to mistyping the extension as "netvis" several times
>>>> for some reason.
>>>>
>>>> René


Re: Trying to use xfuncname without success.

2017-02-08 Thread Jack Adrian Zappa
Thanks Samuel,

So, the question is, what is causing this problem on my system?

Anyone have an idea to help diagnose this problem?

On Wed, Feb 8, 2017 at 3:24 PM, Samuel Lijin <sxli...@gmail.com> wrote:
> On Windows 7, it works for me in both CMD and Git Bash:
>
> $ git --version
> git version 2.11.0.windows.3
>
> $ git diff HEAD^ --word-diff
> diff --git a/test.natvis b/test.natvis
> index 93396ad..1233b8c 100644
> --- a/test.natvis
> +++ b/test.natvis
> @@ -18,6 +18,7 @@ test
>
>
>   
>   {+added_var+}
>
>
>   var2
>
> On Wed, Feb 8, 2017 at 12:37 PM, René Scharfe <l@web.de> wrote:
>> Am 08.02.2017 um 18:11 schrieb Jack Adrian Zappa:
>>> Thanks Rene, but you seem to have missed the point.  NOTHING is
>>> working.  No matter what I put there, it doesn't seem to get matched.
>>
>> I'm not so sure about that.  With your example I get this diff without
>> setting diff.natvis.xfuncname:
>>
>> diff --git a/a.natvis b/a.natvis
>> index 7f9bdf5..bc3c090 100644
>> --- a/a.natvis
>> +++ b/a.natvis
>> @@ -19,7 +19,7 @@ 
>> xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010;>
>>
>>
>>
>> -  added_var
>> +  added_vars
>>
>>
>>var2
>>
>> Note the XML namespace in the hunk header.  It's put there by the
>> default rule because "xmlns" starts at the beginning of the line.  Your
>> diff has nothing there, which means the default rule is not used, i.e.
>> your user-defined rule is in effect.
>>
>> Come to think of it, this line break in the middle of the AutoVisualizer
>> tab might have been added by your email client unintentionally, so that
>> we use different test files, which then of course results in different
>> diffs.  Is that the case?
>>
>> Anyway, if I run the following two commands:
>>
>> $ git config diff.natvis.xfuncname "^[\t ]*<Type[\t ]+Name=\"([^\"]+)\".*$"
>> $ echo '*.natvis diff=natvis' >.gitattributes
>>
>> ... then I get this, both on Linux (git version 2.11.1) and on Windows
>> (git version 2.11.1.windows.1):
>>
>> diff --git a/a.natvis b/a.natvis
>> index 7f9bdf5..bc3c090 100644
>> --- a/a.natvis
>> +++ b/a.natvis
>> @@ -19,7 +19,7 @@ test
>>
>>
>>
>> -  added_var
>> +  added_vars
>>
>>
>>var2
>>
>>> Just to be sure, I tested your regex and again it didn't work.
>>
>> At this point I'm out of ideas, sorry. :(  The only way I was able to
>> break it was due to mistyping the extension as "netvis" several times
>> for some reason.
>>
>> René


Re: Trying to use xfuncname without success.

2017-02-08 Thread Jack Adrian Zappa
> I'm not so sure about that.  With your example I get this diff without
setting diff.natvis.xfuncname:

So, to make sure we are on the same page, I removed the
diff.natvis.xfuncname from the .gitconfig and .git/config.  My output
was:

C:\Users\adrianh\Documents\tmp>git diff
diff --git a/test.natvis b/test.natvis
index 93fd5b4..351301f 100644
--- a/test.natvis
+++ b/test.natvis
@@ -18,6 +18,7 @@


  
+ added_var


   var2

So I didn't get the default output that your specified.

I've been modifying the .gitconfig file directly, but I tried your command:

git config diff.natvis.xfuncname "^[\t ]*<Type[\t ]+Name=\"([^\"]+)\".*$"

and still had the same results.  I.e. NOTHING. :(

On Wed, Feb 8, 2017 at 1:37 PM, René Scharfe <l@web.de> wrote:
> Am 08.02.2017 um 18:11 schrieb Jack Adrian Zappa:
>> Thanks Rene, but you seem to have missed the point.  NOTHING is
>> working.  No matter what I put there, it doesn't seem to get matched.
>
> I'm not so sure about that.  With your example I get this diff without
> setting diff.natvis.xfuncname:
>
> diff --git a/a.natvis b/a.natvis
> index 7f9bdf5..bc3c090 100644
> --- a/a.natvis
> +++ b/a.natvis
> @@ -19,7 +19,7 @@ 
> xmlns="http://schemas.microsoft.com/vstudio/debugger/natvis/2010;>
>
>
>
> -  added_var
> +  added_vars
>
>
>var2
>
> Note the XML namespace in the hunk header.  It's put there by the
> default rule because "xmlns" starts at the beginning of the line.  Your
> diff has nothing there, which means the default rule is not used, i.e.
> your user-defined rule is in effect.
>
> Come to think of it, this line break in the middle of the AutoVisualizer
> tab might have been added by your email client unintentionally, so that
> we use different test files, which then of course results in different
> diffs.  Is that the case?
>
> Anyway, if I run the following two commands:
>
> $ git config diff.natvis.xfuncname "^[\t ]*<Type[\t ]+Name=\"([^\"]+)\".*$"
> $ echo '*.natvis diff=natvis' >.gitattributes
>
> ... then I get this, both on Linux (git version 2.11.1) and on Windows
> (git version 2.11.1.windows.1):
>
> diff --git a/a.natvis b/a.natvis
> index 7f9bdf5..bc3c090 100644
> --- a/a.natvis
> +++ b/a.natvis
> @@ -19,7 +19,7 @@ test
>
>
>
> -  added_var
> +  added_vars
>
>
>var2
>
>> Just to be sure, I tested your regex and again it didn't work.
>
> At this point I'm out of ideas, sorry. :(  The only way I was able to
> break it was due to mistyping the extension as "netvis" several times
> for some reason.
>
> René


Re: Trying to use xfuncname without success.

2017-02-08 Thread Jack Adrian Zappa
Thanks Rene, but you seem to have missed the point.  NOTHING is
working.  No matter what I put there, it doesn't seem to get matched.

Just to be sure, I tested your regex and again it didn't work.

Someone on the SO site stated they could get it to work on FreeBSD and
I'm on Windows, so this might be a platform thing.  Can anyone else on
Windows please confirm?

Thanks,


A

On Tue, Feb 7, 2017 at 6:18 PM, René Scharfe <l@web.de> wrote:
> Am 07.02.2017 um 20:21 schrieb Jack Adrian Zappa:
>>
>> I'm trying to setup a hunk header for .natvis files. For some reason,
>> it doesn't seem to be working. I'm following their instructions from
>> here, which doesn't say much in terms of restrictions of the regex,
>> such as, is the matched item considered the hunk header or do I need a
>> group? I have tried both with no success. This is what I have:
>>
>> [diff "natvis"]
>> xfuncname = "^[\\\t ]*<Type[\\\t ]+Name=\"([^\"])\".*$"
>
>
> The extra "\\" allow backslashes to be used for indentation as well as
> between Type and Name, which is probably not what you want.  And your
> expression only matches single-char Name attributes.  Try:
>
> xfuncname = "^[\t ]*<Type[\t ]+Name=\"([^\"]+)\".*$"
>
> René


Trying to use xfuncname without success.

2017-02-07 Thread Jack Adrian Zappa
I'm trying to specify a hunk header using xfuncname, and it just
doesn't want to work.

The full question is on SO here:

http://stackoverflow.com/questions/42078376/why-isnt-my-xfuncname-working-in-my-gitconfig-file

But the basic gist is that no matter what regex I specify, git will
not recognise the hunk header.  Am I doing something wrong or is this
a bug?

For those who don't want to jump to the SO site, I've copied the text below:

-8<8<8<8<8<8<8<8<---

I'm trying to setup a hunk header for .natvis files. For some reason,
it doesn't seem to be working. I'm following their instructions from
here, which doesn't say much in terms of restrictions of the regex,
such as, is the matched item considered the hunk header or do I need a
group? I have tried both with no success. This is what I have:

[diff "natvis"]
xfuncname = "^[\\\t ]*

  

  var













  
  added_var


  var2

  


with the added_var being the new line added.

I'm really not sure why this is so difficult.

EDIT:

Here is a sample output of what I am getting:

$ git diff --word-diff
diff --git a/test.natvis b/test.natvis
index 73c06bc..bc0f549 100644
--- a/test.natvis
+++ b/test.natvis
@@ -18,6 +18,7 @@


  
  {+added_var+}


  var2
warning: LF will be replaced by CRLF in test.natvis.
The file will have its original line endings in your working directory.

Even using xfuncname = "^.*$" I would have expected that  would have shown up as my hunk header, but I get
nothing. :(

EDIT:

I've tried the solution proposed by torek, but to no avail. It's like
it doesn't know what to do with the xfuncname entry. :(


Re: grep open pull requests

2017-01-19 Thread Jack Bates

On 19/01/17 12:02 PM, Jeff King wrote:

It's much trickier to find from the git topology whether a particular
history contains rebased versions of commits.  You can look at the
--cherry options to "git log", which use patch-ids to try to equate
commits. Something like:

  git for-each-ref --format='%(refname)' 'refs/pull/*/head' |
  while read refname; do
if test -z "$(git rev-list --right-only --cherry-pick -1 
origin...$refname)
then
echo "$refname: not merged"
fi
  done

That's obviously much less efficient than `--no-merged`, but it should
generally work. The exception is if the rebase changed the commit
sufficiently that its patch-id may have changed.


Cool, thanks for all your help! "git log --cherry-pick" works quite 
well. One thing: I expected the following to be equivalent, but found 
that they're not. Is that by accident or design?


  $ git rev-list --cherry-pick --right-only master...refs/pull/1112/head
  $ git rev-list --cherry-pick master..refs/pull/1112/head


I think that's probably the best answer to your "unmerged" question,
too. Ask the API which PRs are unmerged, and then do whatever git-level
analysis you want based on that.


Right, that makes sense. Thanks again!


grep open pull requests

2017-01-19 Thread Jack Bates

I have a couple questions around grepping among open pull requests.

First, "git for-each-ref --no-merged": When I run the following,
it lists refs/pull/1112/head, even though #1112 was merged in commit 
ced4da1. I guess this is because the tip of refs/pull/1112/head is 
107fc59, not ced4da1?


This maybe shows my lack of familiarity with Git details,
but superficially the two commits appear identical -- [1] and [2] --
same parent, etc. Nonetheless they have different SHA-1s.
I'm not sure why that is -- I didn't merge the commit --
but regardless, GitHub somehow still connects ced4da1 with #1112.

So my question is, how are they doing that,
and why can't "git for-each-ref --no-merged" likewise
connect ced4da1 with refs/pull/1112/head?

  $ git clone \
  >   --bare \
  >   --config remote.origin.fetch=+refs/pull/*/head:refs/pull/*/head \
  >   https://github.com/apache/trafficserver.git
  $ cd trafficserver.git
  $ git for-each-ref --no-merged


More generally, what I want is to periodically list open pull requests 
that add or modify lines containing the string "memset". So far I have 
the following in a Makefile. Can you recommend any improvements?


.PHONY: all
all: trafficserver.git
cd trafficserver.git && git fetch
	cd trafficserver.git && git for-each-ref --format '%(refname)' 
refs/pull --no-merged | \

  while read refname; do \
	git log -p "master..$$refname" | grep -q '^+.*memset' && echo 
"$$refname"; \

  done

trafficserver.git:
git clone \
  --bare \
  --config remote.origin.fetch=+refs/pull/*/head:refs/pull/*/head \
  https://github.com/apache/trafficserver.git


Lastly, a question more about GitHub than Git, but: Given the way GitHub 
is setup, I hope I can get a list of unmerged pull requests from Git 
alone. Can you think of a way to list *open* pull requests,

or is that status only available out of band?

Thanks!


[1] 
https://github.com/apache/trafficserver/commit/107fc59104cce2a4b527f04e7ac86695c98b568c
[2] 
https://github.com/apache/trafficserver/commit/ced4da13279f834c381925f2ecd1649bfb459e8b


Re: [PATCH] imap-send.c: Avoid deprecated openssl 1.1.0 API

2017-01-12 Thread Jack Bates

You might need the following, to still build with LibreSSL.
That was my experience anyway, when I recently prepared similar fixes 
for OpenSSL 1.1 and Apache Traffic Server.


#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)

On 12/01/17 03:42 AM, eroen wrote:

Library initialization functions are deprecated in openssl 1.1.0 API, as
initialization is handled by openssl internally.

Symbols for deprecated functions are not exported if openssl is built with
`--api=1.1 disable-deprecated`, so their use will cause a build failure.

Reported-by: Lars Wendler (Polynomial-C)

X-Gentoo-Bug: 592466
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=592466
---
 imap-send.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/imap-send.c b/imap-send.c
index 5c7e27a89..98774360e 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -284,8 +284,10 @@ static int ssl_socket_connect(struct imap_socket *sock, 
int use_tls_only, int ve
int ret;
X509 *cert;

+#if OPENSSL_VERSION_NUMBER < 0x1010L
SSL_library_init();
SSL_load_error_strings();
+#endif

meth = SSLv23_method();
if (!meth) {



Re: [PATCH] imap-send.c: Avoid deprecated openssl 1.1.0 API

2017-01-12 Thread Jack Bates

You might need the following, to still build with LibreSSL.
That was my experience anyway, when I recently prepared similar fixes 
for OpenSSL 1.1 and Apache Traffic Server.


#if OPENSSL_VERSION_NUMBER < 0x1010L || defined(LIBRESSL_VERSION_NUMBER)

On 12/01/17 03:42 AM, eroen wrote:

Library initialization functions are deprecated in openssl 1.1.0 API, as
initialization is handled by openssl internally.

Symbols for deprecated functions are not exported if openssl is built with
`--api=1.1 disable-deprecated`, so their use will cause a build failure.

Reported-by: Lars Wendler (Polynomial-C)

X-Gentoo-Bug: 592466
X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=592466
---
 imap-send.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/imap-send.c b/imap-send.c
index 5c7e27a89..98774360e 100644
--- a/imap-send.c
+++ b/imap-send.c
@@ -284,8 +284,10 @@ static int ssl_socket_connect(struct imap_socket *sock, 
int use_tls_only, int ve
int ret;
X509 *cert;

+#if OPENSSL_VERSION_NUMBER < 0x1010L
SSL_library_init();
SSL_load_error_strings();
+#endif

meth = SSLv23_method();
if (!meth) {



Re: [PATCH v4] diff: handle --no-abbrev in no-index case

2016-12-08 Thread Jack Bates

On 08/12/16 03:53 PM, Junio C Hamano wrote:

Jack Bates <bk8...@nottheoilrig.com> writes:

@@ -3364,6 +3365,7 @@ void diff_setup(struct diff_options *options)

options->file = stdout;

+   options->abbrev = DEFAULT_ABBREV;


This is a new change relative to your earlier one.

I looked at all the callers of diff_setup() and noticed that many of
them were initializing "struct diff_options" that is on-stack that
is totally uninitialized, which means they were using a completely
random value that happened to be on the stack.

Which was surprising and made me wonder how the entire "diff" code
could have ever worked correctly for the past 10 years, as it's not
like all the users always passed --[no-]abbrev[=] from the
command line.

In any case, this cannot possibly be introducing a regression; these
callsites of diff_setup() were starting from a random garbage---now
they start with -1 in this field.  If they were doing the right
thing by assigning their own abbrev to the field after diff_setup()
returned, they will continue to do the same, and otherwise they will
keep doing whatever random things they have been doing when the
uninitialized field happened to contain -1 the same way.

I didn't look carefully at the additional tests, but the code change
looks good.

Thanks.


Great, thanks for reviewing it!


Re: [PATCH v4] diff: handle --no-abbrev in no-index case

2016-12-06 Thread Jack Bates

On 06/12/16 09:56 AM, Jack Bates wrote:

There are two different places where the --no-abbrev option is parsed,
and two different places where SHA-1s are abbreviated. We normally parse
--no-abbrev with setup_revisions(), but in the no-index case, "git diff"
calls diff_opt_parse() directly, and diff_opt_parse() didn't handle
--no-abbrev until now. (It did handle --abbrev, however.) We normally
abbreviate SHA-1s with find_unique_abbrev(), but commit 4f03666 ("diff:
handle sha1 abbreviations outside of repository, 2016-10-20) recently
introduced a special case when you run "git diff" outside of a
repository.

setup_revisions() does also call diff_opt_parse(), but not for --abbrev
or --no-abbrev, which it handles itself. setup_revisions() sets
rev_info->abbrev, and later copies that to diff_options->abbrev. It
handles --no-abbrev by setting abbrev to zero. (This change doesn't
touch that.)

Setting abbrev to zero was broken in the outside-of-a-repository special
case, which until now resulted in a truly zero-length SHA-1, rather than
taking zero to mean do not abbreviate. The only way to trigger this bug,
however, was by running "git diff --raw" without either the --abbrev or
--no-abbrev options, because 1) without --raw it doesn't respect abbrev
(which is bizarre, but has been that way forever), 2) we silently clamp
--abbrev=0 to MINIMUM_ABBREV, and 3) --no-abbrev wasn't handled until
now.

The outside-of-a-repository case is one of three no-index cases. The
other two are when one of the files you're comparing is outside of the
repository you're in, and the --no-index option.

Signed-off-by: Jack Bates <j...@nottheoilrig.com>
---
 diff.c  | 6 +-
 t/t4013-diff-various.sh | 7 +++
 t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir  | 3 +++
 t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir | 3 +++
 t/t4013/diff.diff_--no-index_--raw_dir2_dir | 3 +++
 t/t4013/diff.diff_--raw_--abbrev=4_initial  | 6 ++
 t/t4013/diff.diff_--raw_--no-abbrev_initial | 6 ++
 t/t4013/diff.diff_--raw_initial | 6 ++
 8 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_dir2_dir
 create mode 100644 t/t4013/diff.diff_--raw_--abbrev=4_initial
 create mode 100644 t/t4013/diff.diff_--raw_--no-abbrev_initial
 create mode 100644 t/t4013/diff.diff_--raw_initial

diff --git a/diff.c b/diff.c
index ec87283..84dba60 100644
--- a/diff.c
+++ b/diff.c
@@ -3106,7 +3106,8 @@ static const char *diff_abbrev_oid(const struct object_id 
*oid, int abbrev)
abbrev = FALLBACK_DEFAULT_ABBREV;
if (abbrev > GIT_SHA1_HEXSZ)
die("BUG: oid abbreviation out of range: %d", abbrev);
-   hex[abbrev] = '\0';
+   if (abbrev)
+   hex[abbrev] = '\0';
return hex;
}
 }
@@ -3364,6 +3365,7 @@ void diff_setup(struct diff_options *options)

options->file = stdout;

+   options->abbrev = DEFAULT_ABBREV;
options->line_termination = '\n';
options->break_opt = -1;
options->rename_limit = -1;
@@ -4024,6 +4026,8 @@ int diff_opt_parse(struct diff_options *options,
offending, optarg);
return argcount;
}
+   else if (!strcmp(arg, "--no-abbrev"))
+   options->abbrev = 0;
else if (!strcmp(arg, "--abbrev"))
options->abbrev = DEFAULT_ABBREV;
else if (skip_prefix(arg, "--abbrev=", )) {
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 566817e..d09acfe 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -311,6 +311,13 @@ diff --line-prefix=abc master master^ side
 diff --dirstat master~1 master~2
 diff --dirstat initial rearrange
 diff --dirstat-by-file initial rearrange
+# No-index --abbrev and --no-abbrev


I updated this comment to be consistent with the no-index vs. 
outside-of-a-repository distinction in the commit message.



+diff --raw initial
+diff --raw --abbrev=4 initial
+diff --raw --no-abbrev initial
+diff --no-index --raw dir2 dir
+diff --no-index --raw --abbrev=4 dir2 dir
+diff --no-index --raw --no-abbrev dir2 dir
 EOF

 test_expect_success 'log -S requires an argument' '
diff --git a/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir 
b/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
new file mode 100644
index 000..a71b38a
--- /dev/null
+++ b/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
@@ -0,0 +1,3 @@
+$ git diff --no-index --raw --abbrev=4 dir2 dir
+:00 100644 000

[PATCH v4] diff: handle --no-abbrev in no-index case

2016-12-06 Thread Jack Bates
There are two different places where the --no-abbrev option is parsed,
and two different places where SHA-1s are abbreviated. We normally parse
--no-abbrev with setup_revisions(), but in the no-index case, "git diff"
calls diff_opt_parse() directly, and diff_opt_parse() didn't handle
--no-abbrev until now. (It did handle --abbrev, however.) We normally
abbreviate SHA-1s with find_unique_abbrev(), but commit 4f03666 ("diff:
handle sha1 abbreviations outside of repository, 2016-10-20) recently
introduced a special case when you run "git diff" outside of a
repository.

setup_revisions() does also call diff_opt_parse(), but not for --abbrev
or --no-abbrev, which it handles itself. setup_revisions() sets
rev_info->abbrev, and later copies that to diff_options->abbrev. It
handles --no-abbrev by setting abbrev to zero. (This change doesn't
touch that.)

Setting abbrev to zero was broken in the outside-of-a-repository special
case, which until now resulted in a truly zero-length SHA-1, rather than
taking zero to mean do not abbreviate. The only way to trigger this bug,
however, was by running "git diff --raw" without either the --abbrev or
--no-abbrev options, because 1) without --raw it doesn't respect abbrev
(which is bizarre, but has been that way forever), 2) we silently clamp
--abbrev=0 to MINIMUM_ABBREV, and 3) --no-abbrev wasn't handled until
now.

The outside-of-a-repository case is one of three no-index cases. The
other two are when one of the files you're comparing is outside of the
repository you're in, and the --no-index option.

Signed-off-by: Jack Bates <j...@nottheoilrig.com>
---
 diff.c  | 6 +-
 t/t4013-diff-various.sh | 7 +++
 t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir  | 3 +++
 t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir | 3 +++
 t/t4013/diff.diff_--no-index_--raw_dir2_dir | 3 +++
 t/t4013/diff.diff_--raw_--abbrev=4_initial  | 6 ++
 t/t4013/diff.diff_--raw_--no-abbrev_initial | 6 ++
 t/t4013/diff.diff_--raw_initial | 6 ++
 8 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_dir2_dir
 create mode 100644 t/t4013/diff.diff_--raw_--abbrev=4_initial
 create mode 100644 t/t4013/diff.diff_--raw_--no-abbrev_initial
 create mode 100644 t/t4013/diff.diff_--raw_initial

diff --git a/diff.c b/diff.c
index ec87283..84dba60 100644
--- a/diff.c
+++ b/diff.c
@@ -3106,7 +3106,8 @@ static const char *diff_abbrev_oid(const struct object_id 
*oid, int abbrev)
abbrev = FALLBACK_DEFAULT_ABBREV;
if (abbrev > GIT_SHA1_HEXSZ)
die("BUG: oid abbreviation out of range: %d", abbrev);
-   hex[abbrev] = '\0';
+   if (abbrev)
+   hex[abbrev] = '\0';
return hex;
}
 }
@@ -3364,6 +3365,7 @@ void diff_setup(struct diff_options *options)
 
options->file = stdout;
 
+   options->abbrev = DEFAULT_ABBREV;
options->line_termination = '\n';
options->break_opt = -1;
options->rename_limit = -1;
@@ -4024,6 +4026,8 @@ int diff_opt_parse(struct diff_options *options,
offending, optarg);
return argcount;
}
+   else if (!strcmp(arg, "--no-abbrev"))
+   options->abbrev = 0;
else if (!strcmp(arg, "--abbrev"))
options->abbrev = DEFAULT_ABBREV;
else if (skip_prefix(arg, "--abbrev=", )) {
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 566817e..d09acfe 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -311,6 +311,13 @@ diff --line-prefix=abc master master^ side
 diff --dirstat master~1 master~2
 diff --dirstat initial rearrange
 diff --dirstat-by-file initial rearrange
+# No-index --abbrev and --no-abbrev
+diff --raw initial
+diff --raw --abbrev=4 initial
+diff --raw --no-abbrev initial
+diff --no-index --raw dir2 dir
+diff --no-index --raw --abbrev=4 dir2 dir
+diff --no-index --raw --no-abbrev dir2 dir
 EOF
 
 test_expect_success 'log -S requires an argument' '
diff --git a/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir 
b/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
new file mode 100644
index 000..a71b38a
--- /dev/null
+++ b/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
@@ -0,0 +1,3 @@
+$ git diff --no-index --raw --abbrev=4 dir2 dir
+:00 100644 ... ... A   dir/sub
+$
diff --git a/t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir 
b/t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir
new file

[PATCH v4] diff: handle --no-abbrev in no-index case

2016-12-06 Thread Jack Bates
There are two different places where the --no-abbrev option is parsed,
and two different places where SHA-1s are abbreviated. We normally parse
--no-abbrev with setup_revisions(), but in the no-index case, "git diff"
calls diff_opt_parse() directly, and diff_opt_parse() didn't handle
--no-abbrev until now. (It did handle --abbrev, however.) We normally
abbreviate SHA-1s with find_unique_abbrev(), but commit 4f03666 ("diff:
handle sha1 abbreviations outside of repository, 2016-10-20) recently
introduced a special case when you run "git diff" outside of a
repository.

setup_revisions() does also call diff_opt_parse(), but not for --abbrev
or --no-abbrev, which it handles itself. setup_revisions() sets
rev_info->abbrev, and later copies that to diff_options->abbrev. It
handles --no-abbrev by setting abbrev to zero. (This change doesn't
touch that.)

Setting abbrev to zero was broken in the outside-of-a-repository special
case, which until now resulted in a truly zero-length SHA-1, rather than
taking zero to mean do not abbreviate. The only way to trigger this bug,
however, was by running "git diff --raw" without either the --abbrev or
--no-abbrev options, because 1) without --raw it doesn't respect abbrev
(which is bizarre, but has been that way forever), 2) we silently clamp
--abbrev=0 to MINIMUM_ABBREV, and 3) --no-abbrev wasn't handled until
now.

The outside-of-a-repository case is one of three no-index cases. The
other two are when one of the files you're comparing is outside of the
repository you're in, and the --no-index option.

Signed-off-by: Jack Bates <j...@nottheoilrig.com>
---
 diff.c  | 6 +-
 t/t4013-diff-various.sh | 7 +++
 t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir  | 3 +++
 t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir | 3 +++
 t/t4013/diff.diff_--no-index_--raw_dir2_dir | 3 +++
 t/t4013/diff.diff_--raw_--abbrev=4_initial  | 6 ++
 t/t4013/diff.diff_--raw_--no-abbrev_initial | 6 ++
 t/t4013/diff.diff_--raw_initial | 6 ++
 8 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_dir2_dir
 create mode 100644 t/t4013/diff.diff_--raw_--abbrev=4_initial
 create mode 100644 t/t4013/diff.diff_--raw_--no-abbrev_initial
 create mode 100644 t/t4013/diff.diff_--raw_initial

diff --git a/diff.c b/diff.c
index ec87283..84dba60 100644
--- a/diff.c
+++ b/diff.c
@@ -3106,7 +3106,8 @@ static const char *diff_abbrev_oid(const struct object_id 
*oid, int abbrev)
abbrev = FALLBACK_DEFAULT_ABBREV;
if (abbrev > GIT_SHA1_HEXSZ)
die("BUG: oid abbreviation out of range: %d", abbrev);
-   hex[abbrev] = '\0';
+   if (abbrev)
+   hex[abbrev] = '\0';
return hex;
}
 }
@@ -3364,6 +3365,7 @@ void diff_setup(struct diff_options *options)
 
options->file = stdout;
 
+   options->abbrev = DEFAULT_ABBREV;
options->line_termination = '\n';
options->break_opt = -1;
options->rename_limit = -1;
@@ -4024,6 +4026,8 @@ int diff_opt_parse(struct diff_options *options,
offending, optarg);
return argcount;
}
+   else if (!strcmp(arg, "--no-abbrev"))
+   options->abbrev = 0;
else if (!strcmp(arg, "--abbrev"))
options->abbrev = DEFAULT_ABBREV;
else if (skip_prefix(arg, "--abbrev=", )) {
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 566817e..d7b71a0 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -311,6 +311,13 @@ diff --line-prefix=abc master master^ side
 diff --dirstat master~1 master~2
 diff --dirstat initial rearrange
 diff --dirstat-by-file initial rearrange
+# --abbrev and --no-abbrev outside of repository
+diff --raw initial
+diff --raw --abbrev=4 initial
+diff --raw --no-abbrev initial
+diff --no-index --raw dir2 dir
+diff --no-index --raw --abbrev=4 dir2 dir
+diff --no-index --raw --no-abbrev dir2 dir
 EOF
 
 test_expect_success 'log -S requires an argument' '
diff --git a/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir 
b/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
new file mode 100644
index 000..a71b38a
--- /dev/null
+++ b/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
@@ -0,0 +1,3 @@
+$ git diff --no-index --raw --abbrev=4 dir2 dir
+:00 100644 ... ... A   dir/sub
+$
diff --git a/t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir 
b/t/t4013/diff.diff_--no-index_--raw_--no-abbr

[PATCH v3] diff: handle --no-abbrev in no-index case

2016-12-05 Thread Jack Bates
There are two different places where the --no-abbrev option is parsed,
and two different places where SHA-1s are abbreviated. We normally parse
--no-abbrev with setup_revisions(), but in the no-index case, "git diff"
calls diff_opt_parse() directly, and diff_opt_parse() didn't handle
--no-abbrev until now. (It did handle --abbrev, however.) We normally
abbreviate SHA-1s with find_unique_abbrev(), but commit 4f03666 ("diff:
handle sha1 abbreviations outside of repository, 2016-10-20) recently
introduced a special case when you run "git diff" outside of a
repository.

setup_revisions() does also call diff_opt_parse(), but not for --abbrev
or --no-abbrev, which it handles itself. setup_revisions() sets
rev_info->abbrev, and later copies that to diff_options->abbrev. It
handles --no-abbrev by setting abbrev to zero. (This change doesn't
touch that.)

Setting abbrev to zero was broken in the outside-of-a-repository special
case, which until now resulted in a truly zero-length SHA-1, rather than
taking zero to mean do not abbreviate. The only way to trigger this bug,
however, was by running "git diff --raw" without either the --abbrev or
--no-abbrev options, because 1) without --raw it doesn't respect abbrev
(which is bizarre, but has been that way forever), 2) we silently clamp
--abbrev=0 to MINIMUM_ABBREV, and 3) --no-abbrev wasn't handled until
now.

The outside-of-a-repository case is one of three no-index cases. The
other two are when one of the files you're comparing is outside of the
repository you're in, and the --no-index option.

Signed-off-by: Jack Bates <j...@nottheoilrig.com>
---
 diff.c  | 6 +-
 t/t4013-diff-various.sh | 7 +++
 t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir  | 3 +++
 t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir | 3 +++
 t/t4013/diff.diff_--no-index_--raw_dir2_dir | 3 +++
 t/t4013/diff.diff_--raw_--abbrev=4_initial  | 6 ++
 t/t4013/diff.diff_--raw_--no-abbrev_initial | 6 ++
 t/t4013/diff.diff_--raw_initial | 6 ++
 8 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_dir2_dir
 create mode 100644 t/t4013/diff.diff_--raw_--abbrev=4_initial
 create mode 100644 t/t4013/diff.diff_--raw_--no-abbrev_initial
 create mode 100644 t/t4013/diff.diff_--raw_initial

diff --git a/diff.c b/diff.c
index ec87283..84dba60 100644
--- a/diff.c
+++ b/diff.c
@@ -3106,7 +3106,8 @@ static const char *diff_abbrev_oid(const struct object_id 
*oid, int abbrev)
abbrev = FALLBACK_DEFAULT_ABBREV;
if (abbrev > GIT_SHA1_HEXSZ)
die("BUG: oid abbreviation out of range: %d", abbrev);
-   hex[abbrev] = '\0';
+   if (abbrev)
+   hex[abbrev] = '\0';
return hex;
}
 }
@@ -3364,6 +3365,7 @@ void diff_setup(struct diff_options *options)
 
options->file = stdout;
 
+   options->abbrev = DEFAULT_ABBREV;
options->line_termination = '\n';
options->break_opt = -1;
options->rename_limit = -1;
@@ -4024,6 +4026,8 @@ int diff_opt_parse(struct diff_options *options,
offending, optarg);
return argcount;
}
+   else if (!strcmp(arg, "--no-abbrev"))
+   options->abbrev = 0;
else if (!strcmp(arg, "--abbrev"))
options->abbrev = DEFAULT_ABBREV;
else if (skip_prefix(arg, "--abbrev=", )) {
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 566817e..d7b71a0 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -311,6 +311,13 @@ diff --line-prefix=abc master master^ side
 diff --dirstat master~1 master~2
 diff --dirstat initial rearrange
 diff --dirstat-by-file initial rearrange
+# --abbrev and --no-abbrev outside of repository
+diff --raw initial
+diff --raw --abbrev=4 initial
+diff --raw --no-abbrev initial
+diff --no-index --raw dir2 dir
+diff --no-index --raw --abbrev=4 dir2 dir
+diff --no-index --raw --no-abbrev dir2 dir
 EOF
 
 test_expect_success 'log -S requires an argument' '
diff --git a/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir 
b/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
new file mode 100644
index 000..a71b38a
--- /dev/null
+++ b/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
@@ -0,0 +1,3 @@
+$ git diff --no-index --raw --abbrev=4 dir2 dir
+:00 100644 ... ... A   dir/sub
+$
diff --git a/t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir 
b/t/t4013/diff.diff_--no-index_--raw_--no-abbr

Re: [PATCH] diff: fix up SHA-1 abbreviations outside of repository

2016-12-05 Thread Jack Bates

On 05/12/16 12:26 AM, Jeff King wrote:

On Sun, Dec 04, 2016 at 11:19:46PM -0800, Junio C Hamano wrote:

-   if (no_index)
+   if (no_index) {
/* If this is a no-index diff, just run it and exit there. */
+   startup_info->have_repository = 0;
diff_no_index(, argc, argv);
+   }


This kind of change makes me nervous (partly because I am not seeing
the whole code but only this part of the patch).

Some code may react to "have_repository" being zero and do the right
thing (which I think is what you are using from your previous "we
did one of the three cases" change here), but the codepath that led
to "have_repository" being set to non-zero previously must have done
a lot more than just flipping that field to non-zero, and setting
zero to this field alone would not "undo" what it did.


I _think_ it's OK because the only substantive change would be the
chdir() to the top of the working tree. But that information is carried
through by revs->prefix, which we act on regardless of the value of
startup_info->have_repository when we call prefix_filename().

I agree that it may be an accident waiting to happen, though, as soon as
some buried sub-function needs to care about the distinction.


I wonder if we're better off if we made sure that diff_no_index()
works the same way regardless of the value of "have_repository"
field?


If you mean adding a diffopt flag like "just abbreviate everything to
FALLBACK_DEFAULT_ABBREV even if we're in a repository", and then setting
that in diff_no_index(), I agree that is a lot cleaner.

I'm still not 100% convinced that it's actually the correct behavior,
but at least doing a more contained version wouldn't take away other
functionality like reading config.


I don't have a strong reason for wanting these three cases to behave 
identically, I was merely surprised that they don't. I think you 
expected them to behave the same as well? I'll withdraw this patch.


Conceptually I do think of "git diff" as having two separate modes, "in 
repository" and "out of repository", with the --no-index option forcing 
the "out of repository" mode. But maybe there are good reasons why this 
isn't accurate, or maybe it doesn't matter that it's not 100% accurate.


In summary, currently all of the three cases are "no index" but only the 
first case doesn't "have repository".


Thank you for your thoughtful feedback!


[PATCH] diff: fix up SHA-1 abbreviations outside of repository

2016-12-04 Thread Jack Bates
The three cases where "git diff" operates outside of a repository are 1)
when we run it outside of a repository, 2) when one of the files we're
comparing is outside of the repository we're in, and 3) the --no-index
option. Commit 4f03666 ("diff: handle sha1 abbreviations outside of
repository", 2016-10-20) only worked in the first case.
---
 builtin/diff.c  |  4 +++-
 t/t4063-diff-no-index-abbrev.sh | 50 +
 2 files changed, 53 insertions(+), 1 deletion(-)
 create mode 100755 t/t4063-diff-no-index-abbrev.sh

diff --git a/builtin/diff.c b/builtin/diff.c
index 7f91f6d..ec7c432 100644
--- a/builtin/diff.c
+++ b/builtin/diff.c
@@ -342,9 +342,11 @@ int cmd_diff(int argc, const char **argv, const char 
*prefix)
   "--no-index" : "[--no-index]");
 
}
-   if (no_index)
+   if (no_index) {
/* If this is a no-index diff, just run it and exit there. */
+   startup_info->have_repository = 0;
diff_no_index(, argc, argv);
+   }
 
/* Otherwise, we are doing the usual "git" diff */
rev.diffopt.skip_stat_unmatch = !!diff_auto_refresh_index;
diff --git a/t/t4063-diff-no-index-abbrev.sh b/t/t4063-diff-no-index-abbrev.sh
new file mode 100755
index 000..d1d6302
--- /dev/null
+++ b/t/t4063-diff-no-index-abbrev.sh
@@ -0,0 +1,50 @@
+#!/bin/sh
+
+test_description='don'\'' peek into .git when operating outside of a repository
+
+When abbreviating SHA-1s, if another object in the repository has the
+same abbreviation, we normally lengthen the abbreviation until it'\''s
+unique. Commit 4f03666 ("diff: handle sha1 abbreviations outside of
+repository", 2016-10-20) addressed the case of abbreviating SHA-1s
+outside the context of a repository. In that case we shouldn'\''t peek
+into a .git directory to make an abbreviation unique.
+
+To check that we don'\''t, create an blob with a SHA-1 that starts with
+. (Outside of a repository, SHA-1s are all zeros.) Then make an
+abbreviation and check that Git doesn'\''t lengthen it.
+
+The three cases where "git diff" operates outside of a repository are
+1) when we run it outside of a repository, 2) when one of the files
+we'\''re comparing is outside of the repository we'\''re in,
+and 3) the --no-index option.
+'
+
+. ./test-lib.sh
+
+test_expect_success setup '
+   echo 1 >a &&
+   echo 2 >b &&
+   git init repo &&
+   (
+   cd repo &&
+
+   # Create a blob
+   # 2e907f44c3881822c473d8842405cfd96362
+   echo 119132 >collision &&
+   git add collision
+   )
+'
+
+cat >expect 

[PATCH v2] diff: handle --no-abbrev outside of repository

2016-12-02 Thread Jack Bates
The "git diff --no-index" codepath didn't handle the --no-abbrev option.
Also it didn't behave the same as find_unique_abbrev()
in the case where abbrev == 0.
find_unique_abbrev() returns the full, unabbreviated string in that
case, but the "git diff --no-index" codepath returned an empty string.

Signed-off-by: Jack Bates <j...@nottheoilrig.com>
---
 diff.c  | 6 +-
 t/t4013-diff-various.sh | 7 +++
 t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir  | 3 +++
 t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir | 3 +++
 t/t4013/diff.diff_--no-index_--raw_dir2_dir | 3 +++
 t/t4013/diff.diff_--raw_--abbrev=4_initial  | 6 ++
 t/t4013/diff.diff_--raw_--no-abbrev_initial | 6 ++
 t/t4013/diff.diff_--raw_initial | 6 ++
 8 files changed, 39 insertions(+), 1 deletion(-)
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir
 create mode 100644 t/t4013/diff.diff_--no-index_--raw_dir2_dir
 create mode 100644 t/t4013/diff.diff_--raw_--abbrev=4_initial
 create mode 100644 t/t4013/diff.diff_--raw_--no-abbrev_initial
 create mode 100644 t/t4013/diff.diff_--raw_initial

diff --git a/diff.c b/diff.c
index ec87283..84dba60 100644
--- a/diff.c
+++ b/diff.c
@@ -3106,7 +3106,8 @@ static const char *diff_abbrev_oid(const struct object_id 
*oid, int abbrev)
abbrev = FALLBACK_DEFAULT_ABBREV;
if (abbrev > GIT_SHA1_HEXSZ)
die("BUG: oid abbreviation out of range: %d", abbrev);
-   hex[abbrev] = '\0';
+   if (abbrev)
+   hex[abbrev] = '\0';
return hex;
}
 }
@@ -3364,6 +3365,7 @@ void diff_setup(struct diff_options *options)
 
options->file = stdout;
 
+   options->abbrev = DEFAULT_ABBREV;
options->line_termination = '\n';
options->break_opt = -1;
options->rename_limit = -1;
@@ -4024,6 +4026,8 @@ int diff_opt_parse(struct diff_options *options,
offending, optarg);
return argcount;
}
+   else if (!strcmp(arg, "--no-abbrev"))
+   options->abbrev = 0;
else if (!strcmp(arg, "--abbrev"))
options->abbrev = DEFAULT_ABBREV;
else if (skip_prefix(arg, "--abbrev=", )) {
diff --git a/t/t4013-diff-various.sh b/t/t4013-diff-various.sh
index 566817e..d7b71a0 100755
--- a/t/t4013-diff-various.sh
+++ b/t/t4013-diff-various.sh
@@ -311,6 +311,13 @@ diff --line-prefix=abc master master^ side
 diff --dirstat master~1 master~2
 diff --dirstat initial rearrange
 diff --dirstat-by-file initial rearrange
+# --abbrev and --no-abbrev outside of repository
+diff --raw initial
+diff --raw --abbrev=4 initial
+diff --raw --no-abbrev initial
+diff --no-index --raw dir2 dir
+diff --no-index --raw --abbrev=4 dir2 dir
+diff --no-index --raw --no-abbrev dir2 dir
 EOF
 
 test_expect_success 'log -S requires an argument' '
diff --git a/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir 
b/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
new file mode 100644
index 000..a71b38a
--- /dev/null
+++ b/t/t4013/diff.diff_--no-index_--raw_--abbrev=4_dir2_dir
@@ -0,0 +1,3 @@
+$ git diff --no-index --raw --abbrev=4 dir2 dir
+:00 100644 ... ... A   dir/sub
+$
diff --git a/t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir 
b/t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir
new file mode 100644
index 000..e0f0097
--- /dev/null
+++ b/t/t4013/diff.diff_--no-index_--raw_--no-abbrev_dir2_dir
@@ -0,0 +1,3 @@
+$ git diff --no-index --raw --no-abbrev dir2 dir
+:00 100644  
 A dir/sub
+$
diff --git a/t/t4013/diff.diff_--no-index_--raw_dir2_dir 
b/t/t4013/diff.diff_--no-index_--raw_dir2_dir
new file mode 100644
index 000..3cb4ee7
--- /dev/null
+++ b/t/t4013/diff.diff_--no-index_--raw_dir2_dir
@@ -0,0 +1,3 @@
+$ git diff --no-index --raw dir2 dir
+:00 100644 000... 000... A dir/sub
+$
diff --git a/t/t4013/diff.diff_--raw_--abbrev=4_initial 
b/t/t4013/diff.diff_--raw_--abbrev=4_initial
new file mode 100644
index 000..c3641db
--- /dev/null
+++ b/t/t4013/diff.diff_--raw_--abbrev=4_initial
@@ -0,0 +1,6 @@
+$ git diff --raw --abbrev=4 initial
+:100644 100644 35d2... 9929... M   dir/sub
+:100644 100644 01e7... 10a8... M   file0
+:00 100644 ... b1e6... A   file1
+:100644 00 01e7... ... D   file2
+$
diff --git a/t/t4013/diff.diff_--raw_--no-abbrev_initial 
b/t/t4013/diff.diff_--raw_--no-abbrev_initial
new file mode 100644
index 000..c87a125
--- /dev/null
+++ b/t/t4013/diff.diff_--raw

[PATCH] diff: handle --no-abbrev outside of repository

2016-11-28 Thread Jack Bates
The "git diff --no-index" codepath
doesn't handle the --no-abbrev option.

Signed-off-by: Jack Bates <j...@nottheoilrig.com>
---
 diff.c | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/diff.c b/diff.c
index ec87283..0447eff 100644
--- a/diff.c
+++ b/diff.c
@@ -3106,7 +3106,8 @@ static const char *diff_abbrev_oid(const struct object_id 
*oid, int abbrev)
abbrev = FALLBACK_DEFAULT_ABBREV;
if (abbrev > GIT_SHA1_HEXSZ)
die("BUG: oid abbreviation out of range: %d", abbrev);
-   hex[abbrev] = '\0';
+   if (abbrev)
+   hex[abbrev] = '\0';
return hex;
}
 }
@@ -4024,6 +4025,8 @@ int diff_opt_parse(struct diff_options *options,
offending, optarg);
return argcount;
}
+   else if (!strcmp(arg, "--no-abbrev"))
+   options->abbrev = 0;
else if (!strcmp(arg, "--abbrev"))
options->abbrev = DEFAULT_ABBREV;
else if (skip_prefix(arg, "--abbrev=", )) {
-- 
2.10.2


Questions about GIT

2015-12-14 Thread Jack McLear
Hi

I’ve recently been made aware of GIT and had a few questions.
I’m currently working on creating a middleware between FORAN (a CAD system) and 
Teamcenter.

Do you know if GIT would work between the two?

We’re currently using a Centralised version control system.

So to check my understanding, using GIT to create a distributed version control 
would have the following benefits
The CAD designer who has design a pump assembly for example could create an 
additional branch and “plays around” with the pump to make improvements without 
editing the main pump branch?
Could more than one user create independent branches?
If both users wanted to merge their independent branch with the main branch, 
what would happen? Would one take priority?

Is that the main benefit in terms of a CAD system, the branching ability?

Thanks

Jack



GIT_INDEX_FILE relative paths are relative to the work tree

2015-11-27 Thread Jack O'Connor
When I use a relative path in the GIT_INDEX_FILE environment variable,
git interprets that path relative to the the work tree. This can be
confusing if my cwd is some subdirectory of my project; in that case
an index file is created in the project root rather than in my cwd. It
can also be confusing if I'm using --git-dir and --work-tree, in which
case the path is interpreted relative to the latter.

Is this behavior intentional? If so, I think it would be worth
mentioning in the documentation for GIT_INDEX_FILE. But I can't think
of a case where I would ever want an index file to end up inside my
work tree.

This also comes up in http://stackoverflow.com/a/7645492/823869. Using
absolute paths is a workaround.
--
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


Combining APPLE_COMMON_CRYPTO=1 and NO_OPENSSL=1 produces unexpected result

2015-11-25 Thread Jack Nagel
When compiling git on OS X (where APPLE_COMMON_CRYPTO=1 is the
default) and specifying NO_OPENSSL=1, the resulting git uses the
BLK_SHA1 implementation rather than the functions available in
CommonCrypto.

$ uname -a
Darwin broadwell.local 15.0.0 Darwin Kernel Version 15.0.0: Sat Sep 19
15:53:46 PDT 2015; root:xnu-3247.10.11~1/RELEASE_X86_64 x86_64

$ make NO_OPENSSL=1
[...]
$ nm git | grep _SHA1_
000100173f00 t _blk_SHA1_Block
000100174e80 T _blk_SHA1_Final
00010018fbb0 s _blk_SHA1_Final.pad
000100173de0 T _blk_SHA1_Init
000100173e10 T _blk_SHA1_Update

However, with OpenSSL available, it does use the CommonCrypto functions:

$ make
[...]
$ nm git | grep _SHA1_
 U _CC_SHA1_Final
 U _CC_SHA1_Init
 U _CC_SHA1_Update

I would not expect the presence of NO_OPENSSL=1 to change the behavior
here, since neither case actually makes use of the OpenSSL SHA1
functions.
--
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


Problem staging file

2015-11-09 Thread Jack Adrian Zappa
I'm using vss2git [1] which as the name suggests, converts a VSS
source control database to git.  It has had a couple of hiccups, but
for the most part I've not had too much problems that I couldn't
manually fix except for this one.

I have a file that refuses to be staged.  The commands are:

git add -A
git commit -f d:\tmp\tmp1233.tmp

To override, I've tried to manually add the file and even use the -a
switch on commit line, but no joy.  The file in question stays firmly
in the "Changes not staged for commit" section.

Anyone know why this would be the case and how to fix it?

Thanks,


A


[1] https://github.com/trevorr/vss2git
--
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


Re: diff not finding difference

2015-09-24 Thread Jack Adrian Zappa
On Thu, Sep 24, 2015 at 5:09 PM, Jack Adrian Zappa
<adrianh@gmail.com> wrote:
> This is a weird one:
>
> [file-1 begin]
>
> abcd efg hijklmnop
>
> [file-1 end]
>
> [file-2 begin]
>
> blah blah blah
> /
> abdc boo ya!
>
> [file-2 end]
>
> Do a diff between these and it won't find any difference.
>
> Same with the following two lines, each in a different file:
> sabc fed ghi jkl
> abc def ghi jkl
>
> I first noticed this on the command line git and then in VS2013.  The
> original problem was like my first example.  The files were much
> longer, but all that git would see is the addition of the line of
> ..., but not the removal of the original line.
>
> I've tried some other simple file changes with similar results.
> Something seems to be definitely broken in git diff. :(
>
> Command line version of git is 1.9.5 msysgit.0.
>
>
> A

BTW, I've upgraded to git version 2.5.3.windows.1 and the problem
still persists.


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


Fwd: diff not finding difference

2015-09-24 Thread Jack Adrian Zappa
This is a weird one:

[file-1 begin]

abcd efg hijklmnop

[file-1 end]

[file-2 begin]

blah blah blah
/
abdc boo ya!

[file-2 end]

Do a diff between these and it won't find any difference.

Same with the following two lines, each in a different file:
sabc fed ghi jkl
abc def ghi jkl

I first noticed this on the command line git and then in VS2013.  The
original problem was like my first example.  The files were much
longer, but all that git would see is the addition of the line of
..., but not the removal of the original line.

I've tried some other simple file changes with similar results.
Something seems to be definitely broken in git diff. :(

Command line version of git is 1.9.5 msysgit.0.


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


Bug: version 2.4 seems to have broken `git clone --progress`

2015-05-11 Thread Jack O'Connor
In git 2.3.7 I could run the following command and see progress in the
terminal, despite the redirection of stdout and stderr:

git clone https://github.com/oconnor663/dotfiles --progress 21 | cat

As of 2.4, that command no longer shows progress. When I bisect, the
responsible commit is 2879bc3b0c3acc89f0415ac0d0e3946599d9fc88
(transport-helper: ask the helper to set progress and verbosity
options after asking for its capabilities). Can anyone suggest a
workaround?

-- Jack O'Connor
--
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


local clone and submodules

2014-12-10 Thread Jack Nagel
Say I have a local repository with several submodules that point at
remote repositories. All submodules are up-to-date.

I want to clone everything to another location on disk, *without
hitting the network to fetch the submodules*. Obviously a simple git
clone will work for the superproject, but submodules will be
re-fetched from the remote if I pass --recurse-submodules.

Is there any way to do this offline? Reading through the
documentation, it doesn't seem easy, but perhaps it is possible to do
by recursing through the submodules manually.

In Homebrew, we allow building packages directly from a project's
source repository. Currently, the repositories are downloaded into a
local cache, then checked out into a build directory using git
checkout-index and git submodule foreach. However, some projects
require access to the git repository to do things like compute a
version string.

We experimented with using GIT_DIR, but sometimes we are operating on
multiple git repositories, and saving and restoring its value in the
right places is tedious and error prone.

Our current solution is to symlink the .git directory into the build
directory, but I'd like to replace this manual checkout + symlink with
something cleaner. I could just copy the entire repository from the
cache into the build directory, but we deal with some fairly large
repositories so I would prefer to be able to use git clone or git
clone --shared.

Thanks for any suggestions,
Jack
--
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


Running make in contrib/subtree does not create executable

2014-08-17 Thread Jack Nagel
Running make in contrib/subtree no longer creates the git-subtree executable:

$ git describe
v2.1.0
$ make -C contrib/subtree
/Library/Developer/CommandLineTools/usr/bin/make -C ../../ GIT-VERSION-FILE
GIT_VERSION = 2.1.0
make[1]: `GIT-VERSION-FILE' is up to date.
/Library/Developer/CommandLineTools/usr/bin/make -C ../../ GIT-VERSION-FILE
make[1]: `GIT-VERSION-FILE' is up to date.
make: `../../GIT-VERSION-FILE' is up to date.
$ ls contrib/subtree/git-subtree
ls: contrib/subtree/git-subtree: No such file or directory

The change appears to be inadvertent. I bisected it to
8e2a5ccad11bc21eb72499133bc884024e299983 (contrib/subtree/Makefile:
use GIT-VERSION-FILE).

This was reproduced on OS X 10.9 with GNU make 3.81.

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


[BUG] remote.pushdefault and branch.name.pushremote definition order

2014-02-23 Thread Jack Nagel
There seems to be a difference in the behavior of git push depending
on whether remote.pushdefault is defined before or after
branch.name.pushremote in .git/config.

If remote.pushdefault is defined to be origin, and later in the
file, branch.master.pushremote is defined to be upstream, then a
plain git push from master errors out because I haven't provided a
refspec or configured push.default. This makes sense.

However, if the order of the two in the file is reversed, then a plain
git push pushes to the origin repository, even though I have set
the pushremote for master to upstream. This appears to be a bug.

I would expect the order that things are defined in the config file to
have no effect on the behavior of git push.

I have reproduced this using git 1.9.0 and 1.8.3.4.

Thanks,
Jack
--
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


Please Confirm

2013-12-08 Thread Jack Kofi (ESQ).
Greetings to you, 

I want you to assist me in transferring the sum of US$9.5M left behind by my 
dead client. I am willing to offer 50% to you as the sole beneficiary after the 
funds has been transferred to you.

Get back to me if you are interested so that i can provide you with more details

Regards,
Jack Kofi, esq
--
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


Please Confirm

2013-12-07 Thread Jack Kofi (ESQ).
Greetings to you,

I am Jack Kofi, esq. I want to solicit your consideration to receive some funds 
(US$9.5M) on my behalf.

Get back to me if you are interested so that i can provide you with more 
details.

Yours Sincerely,
Jack Kofi
--
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


Re: Bug? Subtree merge seems to choke on trailing slashes.

2012-11-13 Thread Jack O'Connor
Do I have the right list for bug reports? Apologies if not.

On Tue, Nov 6, 2012 at 5:58 PM, Jack O'Connor oconnor...@gmail.com wrote:

 I'm summarizing from here:
 http://stackoverflow.com/questions/5904256/git-subtree-merge-into-a-deeply-nested-subdirectory

 Quick repro:
 1) I do an initial subtree merge in what I think is the standard way
 (http://www.kernel.org/pub/software/scm/git/docs/howto/using-merge-subtree.html).
 My prefix is simply test/.
 2) I try to merge more upstream changes on top of that with the
 following command:
 git merge --strategy-option=subtree='test/' $upstream_stuff
 3) Git fails with an obscure error:
 fatal: entry  not found in tree daf4d0f0a20b8b6ec007be9fcafeac84a6eba4f0

 If I remove the trailing slash from the command in step 2, it works just fine:
 git merge --strategy-option=subtree='test' $upstream_stuff

 Note in the error message above, there's a double space after entry.
 Is it looking for a tree with an empty name? Did my trailing slash
 imply a directory named empty-string?

 Thanks for your help.

 -- Jack O'Connor
--
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