config file not being copied from templates folder
The “git init” documentation for the “Template Directory” states that: “Files and directories in the template directory whose name do not start with a dot will be copied to the $GIT_DIR after it is created.” However, I put a file called “config” in this directory, and it was not copied to the .git directory after running “git init”. Instead there is always the same old default config file there (and I don’t know where this file comes from). I don’t know any other way of changing the default local config file used for new repos. I really want to change this default config file because I want to use “symlinks=true” in all new repos, regardless of what git was told to do about symlinks when it was installed. (In my case, the chocolatey installer that installs git seems to disable symlinks no matter what). -- Jack Zylkin
Hello Beautiful
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 to begin with. Hope to hear back from you. Jack.
Re: `git add <>` results in "fatal: ... is outside repository"
Hey Anthony, Are you sure that you have 8.3 active on the partition you are using? IIRC, It is not on by default anymore. To see, go to a cmd line and type "dir /x". If there are any files that exceed the 8.3 format, it will show those files with two names, the 8.3 name and the long name. If it is off and you want to turn it on, see https://support.microsoft.com/en-ca/help/121007/how-to-disable-8-3-file-name-creation-on-ntfs-partitions. and https://docs.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2012-R2-and-2012/ff621566(v=ws.11) for more information. A On Mon, Mar 11, 2019 at 2:18 PM Anthony Sottile wrote: > > On Mon, Mar 11, 2019 at 10:55 AM Torsten Bögershausen wrote: > > > > On Mon, Mar 11, 2019 at 06:48:11PM +0100, Johannes Sixt wrote: > > > Am 10.03.19 um 23:41 schrieb Anthony Sottile: > > > > git init longname-repo > > > > cd longname-repo > > > > touch f > > > > git add ..\longna~1\f > > > > > > > ... > > > > > > > > C:\Users\Anthony\AppData\Local\Temp\t\pre-commit-hooks\longname-repo>git > > > > add ..\longna~1\f > > > > fatal: ..\longna~1\f: '..\longna~1\f' is outside repository > > > > > > This has nothing to do with long vs. short path names. It would report > > > the same error when you say > > > > > > git add ..\longname-repo\f > > > > > > -- Hannes > > > > You can probably do another test: > > > > mkdir longname-rexxx > > git init longname-repo > > cd longname-repo > > touch f > > git add ..\longna~1\f > > > > And now nobody knows for shure if "longna~1" > > is longname-rexxx or longname-repo > > > > It may happen that it is longname-rep at this point in time, > > at your machine. > > It may happen that it is a complete different directory on another machine, > > or even on your machine. > > For that reason, to avoid that someone tampers data outside a repo, > > "../" (or ..\ under windows) is not accepted by Git. > > the same can be said for `git add /full/path/to/repo/file` as any of > those components could be symlinks. > > However that is currently allowed > > Note also I've updated my report, it isn't about relative paths any > more but about full paths with 8.3 paths > > Note that 8.3 filanames do canonically disambiguate themselves, the > number after the tilde is used to refer to filenames alphabetically > > This report is very similar to the change that happened to > disambiguate drive letters in > https://github.com/git/git/commit/d8727b3687c1d249e84be71a581cc1fb0581336a > > > > Oops, I misreported while trying to minimize my reproduction > > > > Here's an accurate bug report > > > > git properly handles this: > > > > git add C:\full\path\to\longname-repo\file > > > > When the root of the repo root is `C:\full\path\to\longname-repo` > > > > But it does not handle the equivalent 8.3 path: > > > > git add C:\full\path\to\longna~1\file
Hello Beautiful
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
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
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
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
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
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,
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,
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
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
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
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
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,
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,
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,
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,
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,
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
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,
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,
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,
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.
> 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 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 > 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 >> 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 wrote: >>>> Double check .gitattributes? >>>> >>>> On Feb 8, 2017 2:58 PM, "Jack Adrian Zappa" 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 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 >>>>> > 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 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 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/
Re: Trying to use xfuncname without success.
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 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 > 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 wrote: >>> Double check .gitattributes? >>> >>> On Feb 8, 2017 2:58 PM, "Jack Adrian Zappa" 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 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 >>>> > 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 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 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 ]*>>> >>>> ]+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.
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 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 wrote: >> Double check .gitattributes? >> >> On Feb 8, 2017 2:58 PM, "Jack Adrian Zappa" 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 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 >>> > 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 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 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 ]*>> >>>> ]+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.
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 wrote: > Double check .gitattributes? > > On Feb 8, 2017 2:58 PM, "Jack Adrian Zappa" 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 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 >> > 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 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 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 ]*> >>>> ]+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.
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 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 > 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 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 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 ]*>>> $ 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.
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 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 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 ]*> $ 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.
> 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 ]* 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 ]* $ 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.
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 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 ]* > > 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 ]* > René
Trying to use xfuncname without success.
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 ]* http://schemas.microsoft.com/vstudio/debugger/natvis/2010";> 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
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
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
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
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
On 08/12/16 03:53 PM, Junio C Hamano wrote: Jack Bates 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
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 --- 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=", &arg)) { 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
[PATCH v4] diff: handle --no-abbrev in no-index case
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 --- 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=", &arg)) { 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.d
[PATCH v4] diff: handle --no-abbrev in no-index case
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 --- 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=", &arg)) { 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/t4
[PATCH v3] diff: handle --no-abbrev in no-index case
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 --- 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=", &arg)) { 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/t4
Re: [PATCH] diff: fix up SHA-1 abbreviations outside of repository
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(&rev, 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
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(&rev, 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
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 --- 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=", &arg)) { 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/dif
[PATCH] diff: handle --no-abbrev outside of repository
The "git diff --no-index" codepath doesn't handle the --no-abbrev option. Signed-off-by: Jack Bates --- 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=", &arg)) { -- 2.10.2
Questions about GIT
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
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
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
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
On Thu, Sep 24, 2015 at 5:09 PM, Jack Adrian Zappa 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
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`
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 2>&1 | 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
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
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..pushremote definition order
There seems to be a difference in the behavior of "git push" depending on whether remote.pushdefault is defined before or after branch..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
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
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.
Do I have the right list for bug reports? Apologies if not. On Tue, Nov 6, 2012 at 5:58 PM, Jack O'Connor 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