was the recent 'NOPATH' email humor or spam?
EOM -- Jason Pyeron | Architect PD Inc| 10 w 24th St | Baltimore, MD | .mil: jason.j.pyeron@mail.mil .com: jpye...@pdinc.us tel : 202-741-9397
RE: Finer timestamps and serialization in git
(please don’t cc me) > -Original Message- > From: Derrick Stolee > Sent: Wednesday, May 15, 2019 4:16 PM > > On 5/15/2019 3:16 PM, Eric S. Raymond wrote: I disagree with many of Eric's reasons - and agree with most of Derrick's refutation. But > > Changing the granularity of timestamps requires changing the commit format, > which is probably a non-starter. is not necessarily true. If we take the below example: committer Name 1557948240 -0400 and we follow the rule that: 1. any trailing zero after the decimal point MUST be omitted 2. if there are no digits after the decimal point, it MUST be omitted This would allow: committer Name 1557948240 -0400 committer Name 1557948240.12 -0400 but the following are never allowed: committer Name 1557948240. -0400 committer Name 1557948240.00 -0400 By following these rules, all previous commits' hash are unchanged. Future commits made on the top of the second will look like old commit formats. Commits coming from "older" tools will produce valid and mergeable objects. The loss precision has frustrated us several times as well. Respectfully, Jason Pyeron
RE: Delivery Status Notification (Failure)
> -Original Message- > From: Johannes Schindelin > Sent: Monday, February 18, 2019 4:00 PM > > On Mon, 18 Feb 2019, Senol Yazici wrote: > > > > I just stumbled over following page > > > > https://git-scm.com/about/distributed > > > > and was wondering if it is possible to > > > > - demilitarise that “dictator/lieutenant” thing and > > - de-religionise that “blessed” thing > > > > I did not had the feeling that git is “pro military”, or is against > > “non religious” developers/users. > > Those are valid concerns, and I value your feedback. > > It would probably be a good thing to change this, and you can even do it > yourself: create a Pull Request to change this file: > > https://github.com/git/git-scm.com/blob/master/app/views/about/_distributed.html.erb > Curious, where are the sources for the PNGs saved? I did not find any obvious vector or art project files. -Jason
RE: [PATCH v3 1/1] Support working-tree-encoding "UTF-16LE-BOM"
> -Original Message- > From: git-ow...@vger.kernel.org On Behalf Of > tbo...@web.de > Sent: Wednesday, January 30, 2019 10:02 AM > To: git@vger.kernel.org; adrigi...@gmail.com > Cc: Torsten Bögershausen > Subject: [PATCH v3 1/1] Support working-tree-encoding "UTF-16LE-BOM" > > From: Torsten Bögershausen > > Users who want UTF-16 files in the working tree set the .gitattributes > like this: > test.txt working-tree-encoding=UTF-16 > > The unicode standard itself defines 3 allowed ways how to encode UTF-16. > The following 3 versions convert all back to 'g' 'i' 't' in UTF-8: > > a) UTF-16, without BOM, big endian: > $ printf "\000g\000i\000t" | iconv -f UTF-16 -t UTF-8 | od -c > 000g i t > > b) UTF-16, with BOM, little endian: > $ printf "\377\376g\000i\000t\000" | iconv -f UTF-16 -t UTF-8 | od -c > 000g i t > > c) UTF-16, with BOM, big endian: > $ printf "\376\377\000g\000i\000t" | iconv -f UTF-16 -t UTF-8 | od -c > 000g i t > > Git uses libiconv to convert from UTF-8 in the index into ITF-16 in the > working tree. > After a checkout, the resulting file has a BOM and is encoded in "UTF-16", > in the version (c) above. > This is what iconv generates, more details follow below. > > iconv (and libiconv) can generate UTF-16, UTF-16LE or UTF-16BE: > > d) UTF-16 > $ printf 'git' | iconv -f UTF-8 -t UTF-16 | od -c > 000 376 377 \0 g \0 i \0 t > > e) UTF-16LE > $ printf 'git' | iconv -f UTF-8 -t UTF-16LE | od -c > 000g \0 i \0 t \0 > > f) UTF-16BE > $ printf 'git' | iconv -f UTF-8 -t UTF-16BE | od -c > 000 \0 g \0 i \0 t > > There is no way to generate version (b) from above in a Git working tree, > but that is what some applications need. > (All fully unicode aware applications should be able to read all 3 > variants, > but in practise we are not there yet). > > When producing UTF-16 as an output, iconv generates the big endian version > with a BOM. (big endian is probably chosen for historical reasons). > > iconv can produce UTF-16 files with little endianess by using "UTF-16LE" > as encoding, and that file does not have a BOM. > > Not all users (especially under Windows) are happy with this. > Some tools are not fully unicode aware and can only handle version (b). > > Today there is no way to produce version (b) with iconv (or libiconv). > Looking into the history of iconv, it seems as if version (c) will > be used in all future iconv versions (for compatibility reasons). Reading the RFC 2781 section 3.3: Text in the "UTF-16BE" charset MUST be serialized with the octets which make up a single 16-bit UTF-16 value in big-endian order. Systems labelling UTF-16BE text MUST NOT prepend a BOM to the text. Text in the "UTF-16LE" charset MUST be serialized with the octets which make up a single 16-bit UTF-16 value in little-endian order. Systems labelling UTF-16LE text MUST NOT prepend a BOM to the text. I opened a bug with libiconv... https://savannah.gnu.org/bugs/index.php?55609 > > Solve this dilemma and introduce a Git-specific "UTF-16LE-BOM". > libiconv can not handle the encoding, so Git pick it up, handles the BOM > and uses libiconv to convert the rest of the stream. > (UTF-16BE-BOM is added for consistency) > > Rported-by: Adrián Gimeno Balaguer > Signed-off-by: Torsten Bögershausen > --- > > Changes since v2: > Update the commit message (s/possible/allowed/) > Update the documentation, as suggested by Junio: > ...wonder if the following, > instead of the above hunk, would work better.. > Yes, it does. > > Documentation/gitattributes.txt | 4 ++- > compat/precompose_utf8.c | 2 +- > t/t0028-working-tree-encoding.sh | 12 - > utf8.c | 42 > utf8.h | 2 +- > 5 files changed, 48 insertions(+), 14 deletions(-) > > diff --git a/Documentation/gitattributes.txt > b/Documentation/gitattributes.txt > index b8392fc330..a2310fb920 100644 > --- a/Documentation/gitattributes.txt > +++ b/Documentation/gitattributes.txt > @@ -344,7 +344,9 @@ automatic line ending conversion based on your > platform. > > Use the following attributes if your '*.ps1' files are UTF-16 little > endian encoded without BOM and you want Git to use Windows line endings > -in the working directory. Please note, it is highly recommended to > +in the working directory (use `UTF-16-LE-BOM` instead of `UTF-16LE` if > +you want UTF-16 little endian with BOM). > +Please note, it is highly recommended to > explicitly define the line endings with `eol` if the `working-tree- > encoding` > attribute is used to avoid ambiguity. > > diff --git a/compat/precompose_utf8.c b/compat/precompose_utf8.c > index de61c15d34..136250fbf6 100644 > --- a/compat/precompose_utf8.c > +++ b/compat/precompose_utf8.c > @@ -79,7 +79,7 @@ void precompose_argv(int argc, const char **argv) > size_t namelen; >
RE: Git Test Coverage Report (Tuesday, Sept 25)
> -Original Message- > From: Derrick Stolee > Sent: Wednesday, September 26, 2018 6:43 AM > > On 9/25/2018 5:12 PM, Ben Peart wrote: > > > > > > On 9/25/2018 2:42 PM, Derrick Stolee wrote: > >> In an effort to ensure new code is reasonably covered by the test > >> suite, we now have contrib/coverage-diff.sh to combine the gcov > >> output from 'make coverage-test ; make coverage-report' with the > >> output from 'git diff A B' to discover _new_ lines of code that are > >> not covered. > >> > > > > I looked at the lines that came from my patches and most if not all of > > them are only going to be executed by the test suite if the correct > > "special setup" option is enabled. In my particular case, that is the > > option "GIT_TEST_INDEX_THREADS=" as documented in t/README. > > > > I suspect this will be the case for other code as well so I wonder if > > the tests should be run with each the GIT_TEST_* options that exist to > > exercise uncommon code paths with the test suite. This should prevent > > false positives on code paths that are actually covered by the test > > suite as long as it is run with the appropriate option set. > This is a bit tricky to do, but I will investigate. For some things, the > values can conflict with each other (GIT_TEST_SPLIT_INDEX doesn't play > nicely with other index options, I think). For others, we don't have the > environment variables in all versions yet, as they are still merging down. Remember that the code coverage is cumulative, on one of my projects where I have similar special cases the automated build will run through a sequence of different build options (including architectures) and executions - then generate the final report. Another thought would be to weight the report for "new lines of code" - which is the same we do for our Fortify scans. We take the git blame for the change range and de-prioritize the findings for lines outside of the changed lines. This could give a tighter focus on the newly change code's test coverage. > > > > I realize it would take a long time to run the entire test suite with > > all GIT_TEST_* variables so perhaps they can only be tested "as > > needed" (ie when patches add new variables in the "special setups" > > section of t/README). This should reduce the number of combinations > > that need to be run while still eliminating many of the false positive > > hits. > > This is something to think about. For my own thoughts, I was thinking of > trying to run it when we see large blocks of code that are uncovered and > obviously because of environment variables. This is what I was thinking > when I saw your and Duy's commits in the output. I'll see if I can > re-run the suite using GIT_TEST_INDEX_THREADS=2 and > GIT_TEST_INDEX_VERSION=4. > > Thanks, > -Stolee
RE: Blame / annotate with mixed mac line endings?
> -Original Message- > From: Junio C Hamano > Sent: Wednesday, May 2, 2018 21:22 > Subject: Re: Blame / annotate with mixed mac line endings? > > "Jason Pyeron" writes: > > > Any way to hit git with a stick to treat lone CR as a line > break for blame/annotate? > I highly suspect that you would get more help from those whose love > is Git if your inquiry were about a way to ask Git politely to do > what you want to achieve, rather than hitting it with a stick ;-) No offense meant. > Perhaps define a textconv filter to fix the incorrect line endings? Worked perfectly! I Read: https://github.com/git/git/blob/master/t/t8006-blame-textconv.sh Added to .git/config: [diff "test"] textconv = /usr/local/bin/helper.sh Added to .gitattributes: *.cfm diff=test $ cat /usr/local/bin/helper.sh cat "$1" | mac2unix The important issue was to not use mac2unix directly, because it modifies the file itself. Read: https://git.wiki.kernel.org/index.php/Textconv but it did not help so much. Thanks, Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Blame / annotate with mixed mac line endings?
I think this file may have been from a mac at one point. Note the lone CR (0x0d) line endings, with CRLFs later. $ cat src/htdocs/hr/ats/rpts/incl/slt_org.cfm | sed 's/[a-zA-Z]/x/g;s/[0-9]/8/g' | hexdump -C 3c 21 2d 2d 2d 0d 78 78 78 78 78 78 78 78 3a 20 |.- | 00c0 78 78 20 78 78 78 20 78 78 20 78 78 78 78 2d 3c |xx xxx xx -<| 00d0 2f 78 78 78 78 78 78 3e 0d 0a 09 3c 78 78 78 78 |/xx>..#xxx_xxx#,xxx">xxx.| 0190 0d 0a 09 3c 78 78 78 78 78 78 20 78 78 78 78 78 |...#xx| 01b0 78 5f 78 78 78 23 3c 2f 78 78 78 78 78 78 3e 0d |x_xxx#.| 01c0 0a 3c 2f 78 78 78 78 78 78 78 78 3e 0d 0a 3c 2f |...| 01db $ git annotate -L 13,17 --line-porcelain 'src/htdocs/hr/ats/rpts/incl/slt_org.cfm' fatal: file src/htdocs/hr/ats/rpts/incl/slt_org.cfm has only 10 lines $ cat src/htdocs/hr/ats/rpts/incl/slt_org.cfm | wc -l 10 $ cat src/htdocs/hr/ats/rpts/incl/slt_org.cfm | mac2unix | wc -l 18 $ git -c core.autocrlf=false -c core.eol=cr annotate -L 13,17 --line-porcelain 'src/htdocs/hr/ats/rpts/incl/slt_org.cfm' fatal: file src/htdocs/hr/ats/rpts/incl/slt_org.cfm has only 10 lines Any way to hit git with a stick to treat lone CR as a line break for blame/annotate? -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
git svn clone - Malformed network data: The XML response contains invalid XML: Malformed XML: no element found at /usr/share/perl5/vendor_perl/5.26/Git/SVN/Ra.pm line 312
I am asuming that this is an issue caused by codeplex's svn from tfs implementation. Does anyone here have any insight? $ git --version git version 2.15.0 $ git svn clone https://smtp4dev.svn.codeplex.com/svn smtp4dev Initialized empty Git repository in /cygdrive/c/Users/Public/Desktop/projects/smtp4dev/.git/ r20111 = 443d627cdfeeb240162b9f089ab50c6f058a1260 (refs/remotes/git-svn) A trunk/smtp4dev/smtp4dev.csproj A trunk/smtp4dev/Resources/Icon2.ico A trunk/smtp4dev/Resources/Icon1.ico A trunk/smtp4dev/RegistrySettings.cs A trunk/smtp4dev/Properties/Settings.settings A trunk/smtp4dev/Properties/Settings.Designer.cs A trunk/smtp4dev/Properties/Resources.resx A trunk/smtp4dev/Properties/Resources.Designer.cs A trunk/smtp4dev/Properties/AssemblyInfo.cs A trunk/smtp4dev/Program.cs A trunk/smtp4dev/OptionsForm.resx A trunk/smtp4dev/OptionsForm.Designer.cs A trunk/smtp4dev/OptionsForm.cs A trunk/smtp4dev/obj/Debug/TempPE/Properties.Resources.Designer.cs.dll A trunk/smtp4dev/obj/Debug/smtp4dev.Properties.Resources.resources A trunk/smtp4dev/obj/Debug/smtp4dev.pdb A trunk/smtp4dev/obj/Debug/smtp4dev.OptionsForm.resources A trunk/smtp4dev/obj/Debug/smtp4dev.MainForm.resources A trunk/smtp4dev/obj/Debug/smtp4dev.exe A trunk/smtp4dev/obj/Debug/smtp4dev.csproj.GenerateResource.Cache A trunk/smtp4dev/obj/Debug/smtp4dev.csproj.FileListAbsolute.txt A trunk/smtp4dev/obj/Debug/ResolveAssemblyReference.cache A trunk/smtp4dev/MainForm.resx A trunk/smtp4dev/MainForm.Designer.cs A trunk/smtp4dev/MainForm.cs A trunk/smtp4dev/lib/log4net.dll A trunk/smtp4dev/lib/cses.smtp.server.xml A trunk/smtp4dev/lib/cses.smtp.server.dll A trunk/smtp4dev/Email.cs A trunk/smtp4dev/bin/Debug/smtp4dev.vshost.exe A trunk/smtp4dev/bin/Debug/smtp4dev.vshost.exe.manifest A trunk/smtp4dev/bin/Debug/smtp4dev.vshost.exe.config A trunk/smtp4dev/bin/Debug/smtp4dev.pdb A trunk/smtp4dev/bin/Debug/smtp4dev.exe A trunk/smtp4dev/bin/Debug/smtp4dev.exe.config A trunk/smtp4dev/bin/Debug/log4net.dll A trunk/smtp4dev/bin/Debug/cses.smtp.server.xml A trunk/smtp4dev/bin/Debug/cses.smtp.server.dll A trunk/smtp4dev/app.config A trunk/smtp4dev.suo A trunk/smtp4dev.sln A trunk/smtp4dev.4.5.resharper.user A trunk/Setup/Setup.vdproj A trunk/Setup/Debug/smtp4dev-1.0.0.0.zip A trunk/Setup/Debug/Setup.msi A trunk/Setup/Debug/setup.exe A trunk/Setup/Debug/LICENSE A trunk/Setup/Debug/LICENSE.log4net A trunk/Setup/Debug/LICENSE.cses-smtp-server A trunk/LICENSE A trunk/LICENSE.rtf A trunk/LICENSE.log4net A trunk/LICENSE.cses-smtp-server A trunk/_ReSharper.smtp4dev/Xaml/CacheProvider.dat A trunk/_ReSharper.smtp4dev/WordIndex.New/6/61e28584.dat A trunk/_ReSharper.smtp4dev/WordIndex.New/.version A trunk/_ReSharper.smtp4dev/WebsiteFileReferences/.version A trunk/_ReSharper.smtp4dev/TodoCache/9/3ace61b9.dat A trunk/_ReSharper.smtp4dev/TodoCache/.version A trunk/_ReSharper.smtp4dev/ProjectModel/ProjectModel.dat A trunk/_ReSharper.smtp4dev/CachesImage.bin W: +empty_dir: trunk/Setup/Release W: +empty_dir: trunk/smtp4dev/obj/Debug/Refactor r20114 = 569cc523b14d6346f3198f37b27fccb8cb572ab1 (refs/remotes/git-svn) ... It chugs along then ... W: -empty_dir: trunk/Rnwood.Smtp4dev/Behaviour.cs W: -empty_dir: trunk/Rnwood.SmtpServer/SmtpRequest.cs r27599 = 9e769d8327767a155d7b96b7cc28579cf0ed4c93 (refs/remotes/git-svn) Malformed network data: The XML response contains invalid XML: Malformed XML: no element found at /usr/share/perl5/vendor_perl/5.26/Git/SVN/Ra.pm line 312. I have tried to fiddle with --log-window-size but nothing seemed to work. (https://stackoverflow.com/questions/38071052/getting-error-while-migrating-code-from-svn-to-git-repository-malformed-network) -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
RE: Is it possible to convert a Json file to xml file with Git
> -Original Message- > From: Eyjolfur Eyjolfsson > Sent: Wednesday, November 1, 2017 6:10 AM > To: Randall S. Becker > Cc: Kevin Daudt; git@vger.kernel.org > Subject: Re: Is it possible to convert a Json file to xml > file with Git > > Hi > > Thank you for your response and help. I am new to Git. Not a problem, but what you describe is not using git but rather a shell called bash. Bash is like cmd.exe or powershell.exe, it is not GIT. See http://tldp.org/HOWTO/Bash-Prog-Intro-HOWTO.html > The reason for my question is that I am using Git or Bash.exe (cURl) > to call a REST web service (open for test) and retrieving Json > from the web service and storing it into file. > This works fine from the Git Bash command line . My Git Command: Not a git command, that is a curl command. See https://curl.haxx.se/ > $ curl https://jsonplaceholder.typicode.com/posts -o c:\temper.txt > > I will look into the smudge filter. > You could search for "convert json to xml in LANGUAGE" where language is one you are familiar with. E.g. http://google.com/search?q=convert+json+to+xml+Java > One more question is there a possibility to call Git Bash with a > parameter like example > C:\Git\Git\git-bash.exe curl > https://jsonplaceholder.typicode.com/posts -o c:\temper.txt > > The reason I am asking this is that I am using NAV 2009 Classic Client > and want to lunch the Git Bash with > the command $ curl > https://jsonplaceholder.typicode.com/posts -o c:\temper.txt Again you are using Bash that came with a windows build of Git, just like when the Visual Studio shell gets installed. A place like https://stackoverflow.com/ may be a better resource than this mailing list about GIT. v/r, Jason Pyeron PS: Please do not top post. See http://www.idallen.com/topposting.html > > > Best regards > > (e) eyjolfureyjolfs...@tprg.com > (w) tpretailgroup.com > > > On 31 October 2017 at 21:52, Randall S. Becker > wrote: > >> On October 31, 2017 5:23 PM, Kevin Daudt wrote: > >> > On Tue, Oct 31, 2017 at 05:28:40PM +, Eyjolfur > Eyjolfsson wrote: > >> > I have a question. > >> > Is it possible to convert a Json file to XML with Git > >> > >> git is a version control system, which is mostly content > agnostic. It > > knows > >> nothing about json or xml, let alone how to convert them. > >> > >> You might want to use some kind of programming language to do the > >> conversion. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Rules for backup discussion
I would like to efficiently backup my project directories. I am thinking that the backup of a git enabled project should only backup the following sets of files: Files under .git/ The results of git clean -ndx The results of git status Does this make sense? Is there a less expensive way to calculate the backup file set? I ask because sometime git status takes a long time. -Jason
RE: Consider escaping special characters like 'less' does
> -Original Message-
> From: Jeff King
> Sent: Monday, October 16, 2017 6:13 PM
> To: Joris Valette
> Cc: Andreas Schwab; Jason Pyeron; git@vger.kernel.org
> Subject: Re: Consider escaping special characters like 'less' does
>
>
> I.e., something like this would probably help your case
> without hurting
> anybody:
>
> diff --git a/git-add--interactive.perl b/git-add--interactive.perl
> index 28b325d754..d44e5ea459 100755
> --- a/git-add--interactive.perl
> +++ b/git-add--interactive.perl
> @@ -714,6 +714,16 @@ sub parse_diff {
> push @{$hunk[-1]{DISPLAY}},
> (@colored ? $colored[$i] : $diff[$i]);
> }
> +
> + foreach my $hunk (@hunk) {
> + foreach my $line (@{$hunk->{DISPLAY}}) {
> + # all control chars minus newline and
> ESC (for color)
> + if ($line =~ s/[\000-\011\013-\032\034-\037]/?/g) {
What about CR [0x0D] ?
> + $hunk->{CONTROLCHARS} = 1;
> + }
> + }
> + }
> +
> return @hunk;
> }
>
> @@ -1407,6 +1417,9 @@ sub patch_update_file {
> if ($hunk[$ix]{TYPE} eq 'hunk') {
> $other .= ',e';
> }
> + if ($hunk[$ix]->{CONTROLCHARS}) {
> + print "warning: control characters in
> hunk have been replaced by '?'\n";
> + }
> for (@{$hunk[$ix]{DISPLAY}}) {
> print;
> }
>
> I can't help but feel this is the tip of a larger iceberg,
> though. E.g.,
> what about characters outside of the terminal's correct encoding? Or
> broken UTF-8 characters?
>
> -Peff
>
RE: Consider escaping special characters like 'less' does
> -Original Message- > From: Joris Valette > Sent: Sunday, October 15, 2017 9:34 AM > To: git@vger.kernel.org > Subject: Consider escaping special characters like 'less' does > > The pager 'less' escapes some characters when calling 'git diff'. This > is what I might get: > > $ git diff --cached > diff --git a/some_file b/some_file > new file mode 100644 > index 000..357323f > --- /dev/null > +++ b/some_file > @@ -0,0 +1 @@ > +Hello > \ No newline at end of file > > This example is a simple file encoded in UTF-8 *with BOM*. > On the other hand, the built-in git output shows this: > > $ git --no-pager diff --cached > diff --git a/some_file b/some_file > new file mode 100644 > index 000..357323f > --- /dev/null > +++ b/some_file > @@ -0,0 +1 @@ > +?Hello > \ No newline at end of file It is your terminal, not git's fault that you get a ? rendered. $ git diff diff --git a/test.txt b/test.txt index af9f93a..294e397 100644 --- a/test.txt +++ b/test.txt @@ -1 +1 @@ -the quick brown fox jumps over the lazy dog +the quick brown fox jumps over the lazy dog $ git diff | hexdump.exe -C 64 69 66 66 20 2d 2d 67 69 74 20 61 2f 74 65 73 |diff --git a/tes| 0010 74 2e 74 78 74 20 62 2f 74 65 73 74 2e 74 78 74 |t.txt b/test.txt| 0020 0a 69 6e 64 65 78 20 61 66 39 66 39 33 61 2e 2e |.index af9f93a..| 0030 32 39 34 65 33 39 37 20 31 30 30 36 34 34 0a 2d |294e397 100644.-| 0040 2d 2d 20 61 2f 74 65 73 74 2e 74 78 74 0a 2b 2b |-- a/test.txt.++| 0050 2b 20 62 2f 74 65 73 74 2e 74 78 74 0a 40 40 20 |+ b/test.txt.@@ | 0060 2d 31 20 2b 31 20 40 40 0a 2d 74 68 65 20 71 75 |-1 +1 @@.-the qu| 0070 69 63 6b 20 62 72 6f 77 6e 20 66 6f 78 20 6a 75 |ick brown fox ju| 0080 6d 70 73 20 6f 76 65 72 20 74 68 65 20 6c 61 7a |mps over the laz| Note: 0a is newline, 2b is + ef bb bf are the specials added to the file, 74 68 65 20 71 75 is 'the qu' 0090 79 20 64 6f 67 0a 2b ef bb bf 74 68 65 20 71 75 |y dog.+...the qu| 00a0 69 63 6b 20 62 72 6f 77 6e 20 66 6f 78 20 6a 75 |ick brown fox ju| 00b0 6d 70 73 20 6f 76 65 72 20 74 68 65 20 6c 61 7a |mps over the laz| 00c0 79 20 64 6f 67 0a |y dog.| 00c6 $ git diff | cat diff --git a/test.txt b/test.txt index af9f93a..294e397 100644 --- a/test.txt +++ b/test.txt @@ -1 +1 @@ -the quick brown fox jumps over the lazy dog +the quick brown fox jumps over the lazy dog $ git --no-pager diff diff --git a/test.txt b/test.txt index af9f93a..294e397 100644 --- a/test.txt +++ b/test.txt @@ -1 +1 @@ -the quick brown fox jumps over the lazy dog +the quick brown fox jumps over the lazy dog And my UTF-8 capable terminal displays it fine. What do you get when you pipe to hexdump? -Jason
RE: Git diff --no-index and file descriptor inputs
> -Original Message- > From: Martin Ågren > Sent: Thursday, September 7, 2017 1:48 PM > > On 7 September 2017 at 18:00, Jason Pyeron wrote: > > > > I was hoping to leverage --word-diff-regex, but the > --no-index option > > does not seem to work with <(...) notation. > > > > I am I doing something wrong or is this a bug? > > There were some patches floating around half a year ago, I > don't know what happened to them. > | From: Dennis Kaarsemaker | Sent: Friday, January 13, 2017 5:20 AM | Subject: [PATCH v2 0/2] diff --no-index: support symlinks and pipes > https://public-inbox.org/git/20170324213110.4331-1-den...@kaarsemaker.net/ I see, it goes back to 2016... | From: Dennis Kaarsemaker | Subject: [RFC/PATCH 0/2] git diff <(command1) <(command2) | Date: Fri, 11 Nov 2016 21:19:56 +0100 https://public-inbox.org/git/2016201958.2175-1-den...@kaarsemaker.net/ I will read up on those threads weekend, then try to apply the patches and see what happens. Thanks for the google fu help. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Git diff --no-index and file descriptor inputs
I was hoping to leverage --word-diff-regex, but the --no-index option does not seem to work with <(...) notation. I am I doing something wrong or is this a bug? -Jason (reply to list please) root@blackfat /projects $ git diff --no-index -- <(xmllint --format HRUniversalServices/pairs/src/esb/wsdl/pairs-american-dependents.wsdl) <(xmllint --format /projects/HRUniversalServices.368879ef/modules/pairs/src/esb/wsdl/pairs-amer ican-employees.wsdl) root@blackfat /projects $ echo git diff --no-index -- <(xmllint --format HRUniversalServices/pairs/src/esb/wsdl/pairs-american-dependents.wsdl) <(xmllint --format /projects/HRUniversalServices.368879ef/modules/pairs/src/esb/wsdl/pairs-amer ican-employees.wsdl) git diff --no-index -- /dev/fd/63 /dev/fd/62 root@blackfat /projects $ git diff --no-index -- HRUniversalServices/pairs/src/esb/wsdl/pairs-american-dependents.wsdl /projects/HRUniversalServices.368879ef/modules/pairs/src/esb/wsdl/pairs-amer ican-employees.wsdl | wc -l 92 root@blackfat /projects $ diff -u <(xmllint --format HRUniversalServices/pairs/src/esb/wsdl/pairs-american-dependents.wsdl) <(xmllint --format /projects/HRUniversalServices.368879ef/modules/pairs/src/esb/wsdl/pairs-amer ican-employees.wsdl) | wc -l 82 root@blackfat /projects $ git --version git version 2.13.2 root@blackfat /projects $ uname -a CYGWIN_NT-10.0 blackfat 2.8.1(0.312/5/3) 2017-07-03 14:11 x86_64 Cygwin -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
RE: cat-file timing window on Cygwin
> -Original Message-
> From: Ramsay Jones
> Sent: Sunday, August 27, 2017 11:48 AM
> To: Adam Dinwoodie
> Cc: Jeff King; git@vger.kernel.org; Johannes Schindelin
> Subject: Re: cat-file timing window on Cygwin
>
>
>
> On 27/08/17 12:33, Adam Dinwoodie wrote:
> > On Sun, Aug 27, 2017 at 03:06:31AM +0100, Ramsay Jones wrote:
> >> On 26/08/17 22:11, Adam Dinwoodie wrote:
> >>> On Sat, Aug 26, 2017 at 11:53:37AM -0700, Jeff King wrote:
> >>>> Interesting. I find it a little hard to believe there's
> so obvious
> >>>> a bug as "fflush(NULL) flushes stdin", but well...that's
> what it seems like.
> >>>>
> >>>> If that's truly what it is, this is the minimal
> reproduction I came
> >>>> up
> >>>> with:
> >>>>
> >>>> -- >8 --
> >>>> #include
> >>>>
> >>>> int main(void)
> >>>> {
> >>>> char buf[256];
> >>>> while (fgets(buf, sizeof(buf), stdin)) {
> >>>> fprintf(stdout, "got: %s", buf);
> >>>> fflush(NULL);
> >>>> }
> >>>> return 0;
> >>>> }
> >>>> -- 8< --
> >>>>
> >>>> If this really is the bug, then doing something like
> "seq 10 | ./a.out"
Tests good on latest snapshot. Fails on
Cygwin DLL version info:
DLL version: 2.8.2
DLL epoch: 19
DLL old termios: 5
DLL malloc env: 28
Cygwin conv: 181
API major: 0
API minor: 313
Shared data: 5
DLL identifier: cygwin1
Mount registry: 3
Cygwin registry name: Cygwin
Installations name: Installations
Cygdrive default prefix:
Build date:
Shared id: cygwin1S5
> >>>> would drop some of the input lines.
> >>>
> >>> ...yep. It does. Specifically, I consistently only get
> the firsts
> >>> line:
> >>>
> >>> $ seq 10 | ./a.exe
> >>> got: 1
> >>>
> >>> $
> >>>
> >>> If I introduce a delay between the lines of stdin (which
> I tested by
> >>> just typing stdin from the keyboard), it works as expected.
> >>>
> >>> Looks like this one will need to go to the Cygwin mailing
> list; I'll
> >>> take it there shortly. Thank you all for your help
> getting this far!
> >>
> >> This is apparently fixed in cygwin v2.8.3 [see commit 78ade082fe,
> >> ('Revert "errno: Stop using _impure_ptr->_errno completely"',
> >> 19-07-2017), commit 9cc89b0438 ("cygwin: Use errno instead of
> >> _impure_ptr->_errno", 19-07-2017), commit a674199fc9
> ("cygwin: Bump
> >> DLL version to 2.8.3",
> >> 19-07-2017) and commit d2ae2f00b8 ("cygwin: add fflush fix
> to release
> >> notes", 19-07-2017)].
> >>
> >> I haven't had a chance to try v2.8.3 yet (it's 3am and I'm
> about to
> >> go get some sleep).
> >
> > Cygwin 2.8.3 hasn't been released yet,
>
> Heh, yes, I found that out myself this afternoon. ;-)
>
> > but I've just tested the
> > latest development snapshot with Jeff's simple test case,
> and it works
> > as expected, so I'm going to assume the Git test will start passing
> > once that version of the Cygwin DLL is released too.
>
> Hmm, I'm not keen on installing "snapshot"(s), so I think I
> will wait for the release to test it. (However, as a matter
> of interest, how would I obtain/install/test this snapshot
> release - is it a 'low-risk' exercise?)
Using https://cygwin.com/snapshots/x86_64/cygwin-20170823.tar.xz
D:\inst\cygwin\cygwin-20170823>usr\bin\bash.exe
bash-4.4$ seq 10 | ./a.exe
got: 1
got: 2
got: 3
got: 4
got: 5
got: 6
got: 7
got: 8
got: 9
got: 10
bash-4.4$ cat cygcheck.out
Cygwin Configuration Diagnostics
Current System Time: Sun Aug 27 14:35:25 2017
Windows 10 Professional Ver 10.0 Build 14393
Cygwin DLL version info:
DLL version: 2.9.0
DLL epoch: 19
DLL old termios: 5
DLL malloc env: 28
Cygwin conv: 181
API major: 0
API minor: 317
Shared data: 5
DLL identifier: cygwin1
Mount registry: 3
Cygwin registry name: Cygwin
Installations name: Installations
Cygdrive default prefix:
Build date:
Snapshot date: 20170823-15:44:28
Shared id: cygwin1S5
bash-4.4$
v/r,
Jason Pyeron
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
index.lock porcelain interface?
While working on some scripts for continuous integration, we wanted to check if git was doing anything, before running our script. The best we came up with was checking for the existence of index.lock or if a merge in progress. The MERGE_HEAD can be checked, but we chose to use git status --porcelain=v2 . Is there a better check than does .git/index.lock exists, e.g. a porcelain interface? -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Continous Integration (was: RE: Git v2.13.1 SHA1 very broken)
Do we have Jenkins (or something else) setup for Git? We would be happy to donate (slave) VMs for cygwin builds og Git. -Jason Pyeron
RE: Git "Keeping Original Dates"
> -Original Message- > From: Hector Santos > Sent: Monday, June 5, 2017 5:14 PM > > I'm implementing GIT. If there an option or compile/version that "keep" file timestamps? That is not in the tree data structure, see below. root@blackfat /projects/tipsoftheday $ git cat-file -p head tree 4ca3c2a853c8e817d7de8563c331899cace8ee85 parent 2a33f293df6df0d3978612e41fb1ecd52e2450a5 author Jason Pyeron 1496424815 -0400 committer Jason Pyeron 1496424815 -0400 add JDK to CM root@blackfat /projects/tipsoftheday $ git cat-file -p 4ca3c2a853c8e817d7de8563c331899cace8ee85 04 tree 76094b81b3877b5b27cd4fe518fa0708af3cefedadmin 04 tree c66a88871c285e1485f92be0f8fa47185d94d0b3client 04 tree 460495af209a580e65b5d0b38132d774ddb283b7database 04 tree 264b191b036180039f3fd8c5d56c2b6800cb2ca2doc 04 tree dd128195971f7bafa56371aa6027d7c6bc80f351middleware 04 tree 7861fd39923950d501d4e39aeac4762f7daaca6breports 04 tree 2ad3dedf0313ae775321c88c53741a4b4a7e87b0tools I wish it was an allowable extension, the date could be between the mode and object type. v/r, Jason Pyeron
RE: How to watch a mailing list & repo for patches which affect a certain area of code? [OT]
> -Original Message-
> From: Stefan Beller
> Sent: Monday, October 10, 2016 15:08
>
> On Mon, Oct 10, 2016 at 11:56 AM, Jason Pyeron wrote:
> >> -Original Message-
> >> From: Stefan Beller
> >> Sent: Monday, October 10, 2016 14:43
> >>
> >> +cc Xiaolong Ye
> >>
> >> On Sun, Oct 9, 2016 at 2:26 PM, Jason Pyeron wrote:
> >> >> -Original Message-
> >> >> From: Ian Kelling
> >> >> Sent: Sunday, October 09, 2016 15:03
> >> >>
> >> >> I've got patches in various projects, and I don't have
> >> time to keep up
> >> >> with the mailing list, but I'd like to help out with
> >> >> maintenance of that
> >> >> code, or the functions/files it touches. People don't cc me.
> >> >> I figure I
> >> >> could filter the list, test patches submitted, commits made,
> >> >> mentions of
> >> >> files/functions, build filters based on the code I have in
> >> >> the repo even
> >> >> if it's been moved or changed subsequently. I'm wondering
> >> what other
> >> >> people have implemented already for automation around
> >> this, or general
> >> >> thoughts. Web search is not showing me much.
> >> >>
> >> >
> >> > One thought would be to apply every patch automatically (to
> >> the branches of interest?). Then trigger on the
> [successful] changed
> >> > code. This would simplify the logic to working on the
> >> source only and not parsing the emails.
> >> >
> >> > -Jason
> >> >
> >>
> >> I think this is currently attempted by some kernel people.
> >> However it is very hard to tell where to apply a patch, as it
> >
> > This is one of the reasons why I use bundles instead of
> format patch.
>
> Oh! That sounds interesting for solving the problem where to apply
> a change, but the big disadvantage of bundles to patches is
> the inability
> to just comment on it with an inline response.
Yep. It is a big one. I have a personal project to add a footer to a format
patch with the missing "binary" data. The thoughts were for the main cases
using a RLE bitmap for the whitespace in the above patch and the remainder of
the commit blob data. This would allow minimal duplicate information in the
email but pure text changes would be binary perfect so the commit id will still
be correct.
Sigh, never have enough free time.
> So I assume you follow
> a different workflow than git or the kernel do. Which project
> do you use it
> for and do you have some documentation/blog that explains
> that workflow?
This is used when collaborating cross enterprise. In these situations
enterprise A will not give access to enterprise B on their CI system, or git
repo, etc...
We all have a mailing list in common (encrypted/signed emails when it contains
sensitive info). The rules prevent us from using cloud solutions for almost all
of our work.
I have also worked on git for cross domain (tin foil hat time) source code
transfer.
As to a blog, never thought about it. Ask questions on the list and I will help.
>
>
> >
> >> is not formalized.
> >> See the series that was merged at 72ce3ff7b51c
> >> ('xy/format-patch-base'),
> >> which adds a footer to the patch, that tells you where
> >> exactly a patch ought
> >> to be applied.
> >
> > Cant wait for that.
>
> Well it is found in 2.9 and later. Currently the base footer is
> opt-in, e.g. you'd
> need to convince people to run `git config format.useAutoBase
> true` or to
> manually add the base to the patch via `format-patch --base=`.
Please make default in 2.10.2 .
>
> >
> >>
> >> The intention behind that series was to have some CI
> system hooked up
> >> and report failures to the mailing list as well IIUC. Maybe
> >> that helps with
> >> your use case, too?
> >
> > I envisioned that it would try for each head he was interested in.
> >
>
> Well the test system can be smart enough to differentiate between:
For the OP's case
Test 1: does it cleanly apply to any head, if no for all raise flag.
> * the patch you sent did not even compile on your base, so why
>are you sending bogus patches?
Test 2: is it in an area I care about, if not stop.
Test 3: does it compile for clean application, if no for all raise flag.
> * the patch you sent was fine as you sent it, but in the mean time
> the target head progressed, and it doesn't compile/test any more.
> collaboration is hard.
Yes, especially when you have no time, or management is in the way.
> * or an extension to the prior point: this patch is fine but is broken
> by the series xyz that is also in flight, please coordinate with
> name@email.
RE: How to watch a mailing list & repo for patches which affect a certain area of code?
> -Original Message-
> From: Stefan Beller
> Sent: Monday, October 10, 2016 14:43
>
> +cc Xiaolong Ye
>
> On Sun, Oct 9, 2016 at 2:26 PM, Jason Pyeron wrote:
> >> -Original Message-
> >> From: Ian Kelling
> >> Sent: Sunday, October 09, 2016 15:03
> >>
> >> I've got patches in various projects, and I don't have
> time to keep up
> >> with the mailing list, but I'd like to help out with
> >> maintenance of that
> >> code, or the functions/files it touches. People don't cc me.
> >> I figure I
> >> could filter the list, test patches submitted, commits made,
> >> mentions of
> >> files/functions, build filters based on the code I have in
> >> the repo even
> >> if it's been moved or changed subsequently. I'm wondering
> what other
> >> people have implemented already for automation around
> this, or general
> >> thoughts. Web search is not showing me much.
> >>
> >
> > One thought would be to apply every patch automatically (to
> the branches of interest?). Then trigger on the [successful] changed
> > code. This would simplify the logic to working on the
> source only and not parsing the emails.
> >
> > -Jason
> >
>
> I think this is currently attempted by some kernel people.
> However it is very hard to tell where to apply a patch, as it
This is one of the reasons why I use bundles instead of format patch.
> is not formalized.
> See the series that was merged at 72ce3ff7b51c
> ('xy/format-patch-base'),
> which adds a footer to the patch, that tells you where
> exactly a patch ought
> to be applied.
Cant wait for that.
>
> The intention behind that series was to have some CI system hooked up
> and report failures to the mailing list as well IIUC. Maybe
> that helps with
> your use case, too?
I envisioned that it would try for each head he was interested in.
RE: How to watch a mailing list & repo for patches which affect a certain area of code?
> -Original Message- > From: Ian Kelling > Sent: Sunday, October 09, 2016 15:03 > > I've got patches in various projects, and I don't have time to keep up > with the mailing list, but I'd like to help out with > maintenance of that > code, or the functions/files it touches. People don't cc me. > I figure I > could filter the list, test patches submitted, commits made, > mentions of > files/functions, build filters based on the code I have in > the repo even > if it's been moved or changed subsequently. I'm wondering what other > people have implemented already for automation around this, or general > thoughts. Web search is not showing me much. > One thought would be to apply every patch automatically (to the branches of interest?). Then trigger on the [successful] changed code. This would simplify the logic to working on the source only and not parsing the emails. -Jason
RE: A head scratcher, clone results in modified files (tested linux and cygwin) - .gitattributes file?
> -Original Message- > From: Torsten Bögershausen > Sent: Sunday, October 09, 2016 06:27 > > On 09/10/16 08:48, Jason Pyeron wrote: > > > The whole .gitattributes needs to be adopted, I think > > Git 2.10 or higher has "git ls-files --eol": > > git ls-files --eol | grep "i/crlf.*auto" > i/crlf w/crlf attr/text=auto src/site/xdoc/upgradeto2_3.xml > i/crlf w/crlf attr/text=auto > src/test/resources/org/apache/commons/io/FileUtilsTestDataCRLF.dat > i/crlf w/crlf attr/text=auto src/test/resources/test-file-gbk.bin > i/crlf w/crlf attr/text=auto > src/test/resources/test-file-iso8859-1-shortlines-win-linebr.bin > i/crlf w/crlf attr/text=auto > src/test/resources/test-file-utf8-win-linebr.bin > i/crlf w/crlf attr/text=auto > src/test/resources/test-file-windows-31j.bin > i/crlf w/crlf attr/text=auto > src/test/resources/test-file-x-windows-949.bin > i/crlf w/crlf attr/text=auto > src/test/resources/test-file-x-windows-950.bin > > Problem: > xml file had been commited with CRLF : either normalize it > or declare "-text". > > The same is valid for the other files as well. > They are identified by auto as text, and commited with CRLF. > My feeling is that they should be declared as "-text". > Or, to be more compatible, with "-crlf": > Good call. > Solution: > Make up your mind about the xml file and the html files. > If they are text, they need to be normalized. > > > Question: > What happens, if you do this: > # Auto detect text files and perform LF normalization > *crlf=auto > > *.bin-crlf > *.dat-crlf *.bin -text *.dat -text #fix that issue > *.java crlf diff=java > *.html crlf diff=html > *.csscrlf > *.js crlf > *.sqlcrlf > Or create a subordinate src/test/resources/.gitattributes: *-text Since these are "test" resources, some with text extensions from above. Thanks! -Jason
A head scratcher, clone results in modified files (tested linux and cygwin) - .gitattributes file?
Does anyone have any ideas as to why this clone resulted in modified files and how to prevent it? There is a .gitattributes in the tree, which says: *text=auto *.java text diff=java *.html text diff=html *.csstext *.js text *.sqltext But even then the *.bin files full of non-ascii garbage are impacted?! But I cannot find a difference: root@YYY /projects/commons-io $ git cat-file -p 7c9cd59c8a00e0bd3f18da42b32cd40024ad1505 | hexdump -C a9 fa bf e9 a4 6c a8 ca 0d 0a c1 63 c5 e9 a4 a4 |.l.c| 0010 a4 e5 0d 0a || 0014 root@YYY /projects/commons-io $ git cat-file -p 7c9cd59c8a00e0bd3f18da42b32cd40024ad1505 | sha1sum.exe d69820e1282801ccd627e35fb213e8832949c6ac *- root@YYY /projects/commons-io $ hexdump.exe -C src/test/resources/test-file-x-windows-950.bin a9 fa bf e9 a4 6c a8 ca 0d 0a c1 63 c5 e9 a4 a4 |.l.c| 0010 a4 e5 0d 0a || 0014 root@YYY /projects/commons-io $ sha1sum.exe src/test/resources/test-file-x-windows-950.bin d69820e1282801ccd627e35fb213e8832949c6ac *src/test/resources/test-file-x-windows-950.bin Deleting the .gitattributes and the checkout -- did not help. No luck deleting the file then restoring it either. Not even git clone git://git.apache.org/commons-io.git --config core.attributesFile=/dev/null fixed it. Details below. -Jason Cygwin test: root@YYY /projects $ git clone git://git.apache.org/commons-io.git Cloning into 'commons-io'... remote: Counting objects: 21203, done. remote: Compressing objects: 100% (3454/3454), done. remote: Total 21203 (delta 10822), reused 21129 (delta 10794) Receiving objects: 100% (21203/21203), 2.51 MiB | 607.00 KiB/s, done. Resolving deltas: 100% (10822/10822), done. Checking connectivity... done. root@YYY /projects $ cd commons-io/ root@YYY /projects/commons-io $ 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: src/main/java/org/apache/commons/io/serialization/package.html modified: src/site/xdoc/upgradeto2_3.xml modified: src/test/resources/org/apache/commons/io/FileUtilsTestDataCRLF.dat modified: src/test/resources/test-file-gbk.bin modified: src/test/resources/test-file-iso8859-1-shortlines-win-linebr.bin modified: src/test/resources/test-file-utf8-win-linebr.bin modified: src/test/resources/test-file-windows-31j.bin modified: src/test/resources/test-file-x-windows-949.bin modified: src/test/resources/test-file-x-windows-950.bin no changes added to commit (use "git add" and/or "git commit -a") root@YYY /projects/commons-io $ git rev-parse HEAD c5f2e40e7a8234fe48e08d451d3152ba58a03ac6 root@YYY /projects/commons-io $ git version git version 2.8.3 root@YYY /projects/commons-io $ git config --list user.email=jpye...@pdinc.us user.name=Jason Pyeron credential.helper=cache --timeout=99 push.default=simple core.repositoryformatversion=0 core.filemode=true core.bare=false core.logallrefupdates=true core.ignorecase=true remote.origin.url=git://git.apache.org/commons-io.git remote.origin.fetch=+refs/heads/*:refs/remotes/origin/* branch.master.remote=origin branch.master.merge=refs/heads/master $ uname -a CYGWIN_NT-6.1-WOW YYY 2.5.2(0.297/5/3) 2016-06-23 14:27 i686 Cygwin root@YYY /projects/commons-io $ Linux test: root@XX /tmp # git clone git://git.apache.org/commons-io.git Cloning into 'commons-io'... remote: Counting objects: 21203, done. remote: Compressing objects: 100% (3454/3454), done. remote: Total 21203 (delta 10822), reused 21129 (delta 10794) Receiving objects: 100% (21203/21203), 2.51 MiB | 176 KiB/s, done. Resolving deltas: 100% (10822/10822), done. root@XX /tmp # cd commons-io/ root@XX /tmp/commons-io # git status # On branch 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: src/main/java/org/apache/commons/io/serialization/package.html # modified: src/site/xdoc/upgradeto2_3.xml # modified: src/test/resources/org/apache/commons/io/FileUtilsTestDataCRLF.dat # modified: src/test/resources/test-file-gbk.bin # modified: src/test/resources/test-file-iso8859-1-shortlines-win-linebr.bin # modified: src/test/resources/test-file-utf8-win-linebr.bin # modified: src/test/resources/test-file-windows-31j.bin # modified: src/test/resources/test-file-x-windows-949.bin # modified: src/test/resources/test-file-x-windows-950.bin # n
RE: git-upload-pack hangs
> -Original Message- > From: Junio C Hamano > Sent: Tuesday, September 27, 2016 12:02 > > Jason Pyeron writes: > > > This is a very, very first draft. > > > > It is allowing IIS to work right now. > > > > I still need to address chunked issues, where there is no > content length (see > http://www.gossamer-threads.com/lists/apache/users/373042) > > > > Any comments, sugestions? > > Does this have any relation to another thread earlier this year, > which seems to have ended here: > > https://public-inbox.org/git/20160401235532.ga27...@sigill.intra.peff.net/ Looks like the same. Did not (don't know why I was unsubscribed a few months ago?!) see that one and gmane is killing me on my searches... I will read the full thread, digest and fold what I can glean in to my (in production right now) patch. -Jason
RE: git-upload-pack hangs
Thanks, I wrote this while on a train to get the site up 1st, I did not even
review it yet!
I think I am going to spend the time this weekend to clean it up, and submit a
patch for master and the version cygwin uses.
-Jason
> -Original Message-
> From: jch2...@gmail.com [mailto:jch2...@gmail.com] On Behalf
> Of Junio C Hamano
> Sent: Tuesday, September 27, 2016 00:18
> To: Jason Pyeron
> Subject: Re: git-upload-pack hangs
>
> Not a review, but size_t is an unsigned type, so specifying -1 as a
> fallback value,
> or comparing it with -1, does not make much sense. Perhaps
> use ssize_t?
>
> On Mon, Sep 26, 2016 at 8:45 PM, Jason Pyeron
> wrote:
> > This is a very, very first draft.
> >
> > It is allowing IIS to work right now.
> >
> > I still need to address chunked issues, where there is no
> content length (see
> http://www.gossamer-threads.com/lists/apache/users/373042)
> >
> > Any comments, sugestions?
> >
> > -Jason
> >
> > --- ./origsrc/git-v2.8.3/http-backend.c 2016-05-18
> 18:32:41.0 -0400
> > +++ ./src/git-v2.8.3/http-backend.c 2016-09-26
> 22:52:02.636135000 -0400
> > @@ -279,14 +279,17 @@
> > {
> > size_t len = 0, alloc = 8192;
> > unsigned char *buf = xmalloc(alloc);
> > + /* get request size */
> > + size_t req_len = git_env_ulong("CONTENT_LENGTH", -1);
> >
> > if (max_request_buffer < alloc)
> > max_request_buffer = alloc;
> >
> > - while (1) {
> > + while (req_len>0 || req_len==-1 ) {
> > + ssize_t maxread=alloc>req_len &&
> req_len!=-1?req_len:alloc;
> > ssize_t cnt;
> >
> > - cnt = read_in_full(fd, buf + len, alloc - len);
> > + cnt = read_in_full(fd, buf + len, maxread - len);
> > if (cnt < 0) {
> > free(buf);
> > return -1;
> > @@ -294,13 +297,19 @@
> >
> > /* partial read from read_in_full means we
> hit EOF */
> > len += cnt;
> > - if (len < alloc) {
> > + if (len < maxread) {
> > *out = buf;
> > return len;
> > }
> >
> > + if (req_len>0) {
> > + req_len -= cnt;
> > + if (req_len<0)
> > + req_len=0;
> > + }
> > +
> > /* otherwise, grow and try again (if we can) */
> > - if (alloc == max_request_buffer)
> > + if (alloc == max_request_buffer && maxread == alloc)
> > die("request was larger than our
> maximum size (%lu);"
> > " try setting
> GIT_HTTP_MAX_REQUEST_BUFFER",
> > max_request_buffer);
> > @@ -310,6 +319,10 @@
> > alloc = max_request_buffer;
> > REALLOC_ARRAY(buf, alloc);
> > }
> > +
> > + free(buf);
> > +
> > + return len;
> > }
> >
> > static void inflate_request(const char *prog_name, int
> out, int buffer_input)
> >
> >
> >> -Original Message-
> >> From: git-ow...@vger.kernel.org
> >> [mailto:git-ow...@vger.kernel.org] On Behalf Of Jason Pyeron
> >> Sent: Monday, September 26, 2016 09:26
> >> To: git@vger.kernel.org
> >> Subject: RE: git-upload-pack hangs
> >>
> >> > -Original Message-
> >> > From: Jason Pyeron
> >> > Sent: Monday, September 26, 2016 01:51
> >> >
> >> > git is hanging on clone. I am runnig (cygwin) git 2.8.3 on
> >> > IIS7 (windows server 2012 R2).
> >> >
> >> > Where can I start to perform additional debugging?
> >> >
> >>
> >> Reading this thread, it seems plausible as a cause since it
> >> aligns with my testing.
> >>
> >> http://www.spinics.net/lists/git/msg279437.html [ and
> >> http://www.spinics.net/lists/git/attachments/binQFGHirNLw3.bin ]
> >>
> >> I will start to trudge into the code to see if this (or
> >> similar) has been applied and if not, does it fix it.
> >>
> >> > Selected items I have read, but they did not help:
> >> >
> >> > http://unix.stackexchange.com/ques
RE: git-upload-pack hangs
This is a very, very first draft.
It is allowing IIS to work right now.
I still need to address chunked issues, where there is no content length (see
http://www.gossamer-threads.com/lists/apache/users/373042)
Any comments, sugestions?
-Jason
--- ./origsrc/git-v2.8.3/http-backend.c 2016-05-18 18:32:41.0 -0400
+++ ./src/git-v2.8.3/http-backend.c 2016-09-26 22:52:02.636135000 -0400
@@ -279,14 +279,17 @@
{
size_t len = 0, alloc = 8192;
unsigned char *buf = xmalloc(alloc);
+ /* get request size */
+ size_t req_len = git_env_ulong("CONTENT_LENGTH", -1);
if (max_request_buffer < alloc)
max_request_buffer = alloc;
- while (1) {
+ while (req_len>0 || req_len==-1 ) {
+ ssize_t maxread=alloc>req_len && req_len!=-1?req_len:alloc;
ssize_t cnt;
- cnt = read_in_full(fd, buf + len, alloc - len);
+ cnt = read_in_full(fd, buf + len, maxread - len);
if (cnt < 0) {
free(buf);
return -1;
@@ -294,13 +297,19 @@
/* partial read from read_in_full means we hit EOF */
len += cnt;
- if (len < alloc) {
+ if (len < maxread) {
*out = buf;
return len;
}
+ if (req_len>0) {
+ req_len -= cnt;
+ if (req_len<0)
+ req_len=0;
+ }
+
/* otherwise, grow and try again (if we can) */
- if (alloc == max_request_buffer)
+ if (alloc == max_request_buffer && maxread == alloc)
die("request was larger than our maximum size (%lu);"
" try setting GIT_HTTP_MAX_REQUEST_BUFFER",
max_request_buffer);
@@ -310,6 +319,10 @@
alloc = max_request_buffer;
REALLOC_ARRAY(buf, alloc);
}
+
+ free(buf);
+
+ return len;
}
static void inflate_request(const char *prog_name, int out, int buffer_input)
> -Original Message-
> From: git-ow...@vger.kernel.org
> [mailto:git-ow...@vger.kernel.org] On Behalf Of Jason Pyeron
> Sent: Monday, September 26, 2016 09:26
> To: git@vger.kernel.org
> Subject: RE: git-upload-pack hangs
>
> > -Original Message-
> > From: Jason Pyeron
> > Sent: Monday, September 26, 2016 01:51
> >
> > git is hanging on clone. I am runnig (cygwin) git 2.8.3 on
> > IIS7 (windows server 2012 R2).
> >
> > Where can I start to perform additional debugging?
> >
>
> Reading this thread, it seems plausible as a cause since it
> aligns with my testing.
>
> http://www.spinics.net/lists/git/msg279437.html [ and
> http://www.spinics.net/lists/git/attachments/binQFGHirNLw3.bin ]
>
> I will start to trudge into the code to see if this (or
> similar) has been applied and if not, does it fix it.
>
> > Selected items I have read, but they did not help:
> >
> > http://unix.stackexchange.com/questions/98959/git-upload-pack-
> > hangs-indefinitely
> >
> > https://sparethought.wordpress.com/2012/12/06/setting-git-to-w
> ork-behind-ntlm-authenticated-proxy-cntlm-to-the-rescue/
> >
> > https://sourceforge.net/p/cntlm/bugs/24/
> >
> > invocation of the clone:
> >
> > jpyeron.adm@SERVER /tmp
> > $ GIT_TRACE=1 GIT_CURL_VERBOSE=true git clone
> > http://SERVER.domain.com/git/test.git
> > 01:23:37.020476 git.c:350 trace: built-in: git
> > 'clone' 'http://SERVER.domain.com/git/test.git'
> > Cloning into 'test'...
> > 01:23:37.206046 run-command.c:336 trace: run_command:
> > 'git-remote-http' 'origin' 'http://SERVER.domain.com/git/test.git'
> > * STATE: INIT => CONNECT handle 0x60009a140; line 1397
> > (connection #-5000)
> > * Couldn't find host SERVER.domain.com in the .netrc file;
> > using defaults
> > * Added connection 0. The cache now contains 1 members
> > * Trying ::1...
> > * TCP_NODELAY set
> > * STATE: CONNECT => WAITCONNECT handle 0x60009a140; line 1450
> > (connection #0)
> > * Connected to SERVER.domain.com (::1) port 80 (#0)
> > * STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x60009a140;
> > line 1557 (connection #0)
> > * Marked for [keep alive]: HTTP default
> > * STATE: SENDPROTOCONNECT => DO handle 0x60009a140; line 1575
> > (connection #0)
> > > GET /git/test.git/info/refs?service=git-upload-pack HTTP/1.1
> > Host: SERVER.d
RE: git-upload-pack hangs
> -Original Message- > From: Jason Pyeron > Sent: Monday, September 26, 2016 01:51 > > git is hanging on clone. I am runnig (cygwin) git 2.8.3 on > IIS7 (windows server 2012 R2). > > Where can I start to perform additional debugging? > Reading this thread, it seems plausible as a cause since it aligns with my testing. http://www.spinics.net/lists/git/msg279437.html [ and http://www.spinics.net/lists/git/attachments/binQFGHirNLw3.bin ] I will start to trudge into the code to see if this (or similar) has been applied and if not, does it fix it. > Selected items I have read, but they did not help: > > http://unix.stackexchange.com/questions/98959/git-upload-pack- > hangs-indefinitely > > https://sparethought.wordpress.com/2012/12/06/setting-git-to-w ork-behind-ntlm-authenticated-proxy-cntlm-to-the-rescue/ > > https://sourceforge.net/p/cntlm/bugs/24/ > > invocation of the clone: > > jpyeron.adm@SERVER /tmp > $ GIT_TRACE=1 GIT_CURL_VERBOSE=true git clone > http://SERVER.domain.com/git/test.git > 01:23:37.020476 git.c:350 trace: built-in: git > 'clone' 'http://SERVER.domain.com/git/test.git' > Cloning into 'test'... > 01:23:37.206046 run-command.c:336 trace: run_command: > 'git-remote-http' 'origin' 'http://SERVER.domain.com/git/test.git' > * STATE: INIT => CONNECT handle 0x60009a140; line 1397 > (connection #-5000) > * Couldn't find host SERVER.domain.com in the .netrc file; > using defaults > * Added connection 0. The cache now contains 1 members > * Trying ::1... > * TCP_NODELAY set > * STATE: CONNECT => WAITCONNECT handle 0x60009a140; line 1450 > (connection #0) > * Connected to SERVER.domain.com (::1) port 80 (#0) > * STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x60009a140; > line 1557 (connection #0) > * Marked for [keep alive]: HTTP default > * STATE: SENDPROTOCONNECT => DO handle 0x60009a140; line 1575 > (connection #0) > > GET /git/test.git/info/refs?service=git-upload-pack HTTP/1.1 > Host: SERVER.domain.com > User-Agent: git/2.8.3 > Accept: */* > Accept-Encoding: gzip > Accept-Language: en-US, *;q=0.9 > Pragma: no-cache > > * STATE: DO => DO_DONE handle 0x60009a140; line 1654 (connection #0) > * STATE: DO_DONE => WAITPERFORM handle 0x60009a140; line 1781 > (connection #0) > * STATE: WAITPERFORM => PERFORM handle 0x60009a140; line 1791 > (connection #0) > * HTTP 1.1 or later with persistent connection, pipelining supported > < HTTP/1.1 200 OK > < Cache-Control: no-cache, max-age=0, must-revalidate > < Pragma: no-cache > < Content-Type: application/x-git-upload-pack-advertisement > < Expires: Fri, 01 Jan 1980 00:00:00 GMT > * Server Microsoft-IIS/8.5 is not blacklisted > < Server: Microsoft-IIS/8.5 > < X-Powered-By: ASP.NET > < Date: Mon, 26 Sep 2016 05:23:37 GMT > * Marked for [closure]: Connection: close used > < Connection: close > < Content-Length: 310 > < > * STATE: PERFORM => DONE handle 0x60009a140; line 1955 (connection #0) > * multi_done > * Curl_http_done: called premature == 0 > * Closing connection 0 > * The cache now contains 0 members > 01:23:37.688252 run-command.c:336 trace: run_command: > 'fetch-pack' '--stateless-rpc' '--stdin' '--lock-pack' > '--thin' '--check-self-contained-and-connected' '--cloning' > 'http://SERVER.domain.com/git/test.git/' > 01:23:37.717168 exec_cmd.c:120 trace: exec: 'git' > 'fetch-pack' '--stateless-rpc' '--stdin' '--lock-pack' > '--thin' '--check-self-contained-and-connected' '--cloning' > 'http://SERVER.domain.com/git/test.git/' > 01:23:37.749820 git.c:350 trace: built-in: git > 'fetch-pack' '--stateless-rpc' '--stdin' '--lock-pack' > '--thin' '--check-self-contained-and-connected' '--cloning' > 'http://SERVER.domain.com/git/test.git/' > * STATE: INIT => CONNECT handle 0x60009a140; line 1397 > (connection #-5000) > * Couldn't find host SERVER.domain.com in the .netrc file; > using defaults > * Added connection 1. The cache now contains 1 members > * Hostname SERVER.domain.com was found in DNS cache > * Trying ::1... > * TCP_NODELAY set > * STATE: CONNECT => WAITCONNECT handle 0x60009a140; line 1450 > (connection #1) > * Connected to SERVER.domain.com (::1) port 80 (#1) > * STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x60009a140; >
git-upload-pack hangs
git is hanging on clone. I am runnig (cygwin) git 2.8.3 on IIS7 (windows server 2012 R2). Where can I start to perform additional debugging? Selected items I have read, but they did not help: http://unix.stackexchange.com/questions/98959/git-upload-pack-hangs-indefinitely https://sparethought.wordpress.com/2012/12/06/setting-git-to-work-behind-ntlm-authenticated-proxy-cntlm-to-the-rescue/ https://sourceforge.net/p/cntlm/bugs/24/ invocation of the clone: jpyeron.adm@SERVER /tmp $ GIT_TRACE=1 GIT_CURL_VERBOSE=true git clone http://SERVER.domain.com/git/test.git 01:23:37.020476 git.c:350 trace: built-in: git 'clone' 'http://SERVER.domain.com/git/test.git' Cloning into 'test'... 01:23:37.206046 run-command.c:336 trace: run_command: 'git-remote-http' 'origin' 'http://SERVER.domain.com/git/test.git' * STATE: INIT => CONNECT handle 0x60009a140; line 1397 (connection #-5000) * Couldn't find host SERVER.domain.com in the .netrc file; using defaults * Added connection 0. The cache now contains 1 members * Trying ::1... * TCP_NODELAY set * STATE: CONNECT => WAITCONNECT handle 0x60009a140; line 1450 (connection #0) * Connected to SERVER.domain.com (::1) port 80 (#0) * STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x60009a140; line 1557 (connection #0) * Marked for [keep alive]: HTTP default * STATE: SENDPROTOCONNECT => DO handle 0x60009a140; line 1575 (connection #0) > GET /git/test.git/info/refs?service=git-upload-pack HTTP/1.1 Host: SERVER.domain.com User-Agent: git/2.8.3 Accept: */* Accept-Encoding: gzip Accept-Language: en-US, *;q=0.9 Pragma: no-cache * STATE: DO => DO_DONE handle 0x60009a140; line 1654 (connection #0) * STATE: DO_DONE => WAITPERFORM handle 0x60009a140; line 1781 (connection #0) * STATE: WAITPERFORM => PERFORM handle 0x60009a140; line 1791 (connection #0) * HTTP 1.1 or later with persistent connection, pipelining supported < HTTP/1.1 200 OK < Cache-Control: no-cache, max-age=0, must-revalidate < Pragma: no-cache < Content-Type: application/x-git-upload-pack-advertisement < Expires: Fri, 01 Jan 1980 00:00:00 GMT * Server Microsoft-IIS/8.5 is not blacklisted < Server: Microsoft-IIS/8.5 < X-Powered-By: ASP.NET < Date: Mon, 26 Sep 2016 05:23:37 GMT * Marked for [closure]: Connection: close used < Connection: close < Content-Length: 310 < * STATE: PERFORM => DONE handle 0x60009a140; line 1955 (connection #0) * multi_done * Curl_http_done: called premature == 0 * Closing connection 0 * The cache now contains 0 members 01:23:37.688252 run-command.c:336 trace: run_command: 'fetch-pack' '--stateless-rpc' '--stdin' '--lock-pack' '--thin' '--check-self-contained-and-connected' '--cloning' 'http://SERVER.domain.com/git/test.git/' 01:23:37.717168 exec_cmd.c:120 trace: exec: 'git' 'fetch-pack' '--stateless-rpc' '--stdin' '--lock-pack' '--thin' '--check-self-contained-and-connected' '--cloning' 'http://SERVER.domain.com/git/test.git/' 01:23:37.749820 git.c:350 trace: built-in: git 'fetch-pack' '--stateless-rpc' '--stdin' '--lock-pack' '--thin' '--check-self-contained-and-connected' '--cloning' 'http://SERVER.domain.com/git/test.git/' * STATE: INIT => CONNECT handle 0x60009a140; line 1397 (connection #-5000) * Couldn't find host SERVER.domain.com in the .netrc file; using defaults * Added connection 1. The cache now contains 1 members * Hostname SERVER.domain.com was found in DNS cache * Trying ::1... * TCP_NODELAY set * STATE: CONNECT => WAITCONNECT handle 0x60009a140; line 1450 (connection #1) * Connected to SERVER.domain.com (::1) port 80 (#1) * STATE: WAITCONNECT => SENDPROTOCONNECT handle 0x60009a140; line 1557 (connection #1) * Marked for [keep alive]: HTTP default * STATE: SENDPROTOCONNECT => DO handle 0x60009a140; line 1575 (connection #1) > POST /git/test.git/git-upload-pack HTTP/1.1 Host: SERVER.domain.com User-Agent: git/2.8.3 Accept-Encoding: gzip Content-Type: application/x-git-upload-pack-request Accept: application/x-git-upload-pack-result Content-Length: 140 * upload completely sent off: 140 out of 140 bytes * STATE: DO => DO_DONE handle 0x60009a140; line 1654 (connection #1) * STATE: DO_DONE => WAITPERFORM handle 0x60009a140; line 1781 (connection #1) * STATE: WAITPERFORM => PERFORM handle 0x60009a140; line 1791 (connection #1) -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
RE: co-authoring commits
> -Original Message-
> From: Theodore Ts'o
> Sent: Wednesday, June 17, 2015 6:52 PM
>
> On Wed, Jun 17, 2015 at 10:26:32PM +0200, Tuncer Ayaz wrote:
> >
> > By allowing multiple authors, you don't have to decide who's the
> > primary author, as in such situations usually there is no
> primary at
> > all. I sometimes deliberately override the author when
> committing and
> > add myself just as another co-author in the commit message, but as
> > others have noted it would be really great if we can just specify
> > multiple authors.
> One could imagine some frankly, quite rare example where
> there is a team of people who votes on each commit before it
> gets sent out and where everyone is equal and there is no
> hierarchy. In that case, perhaps you could set the from
> field to a mailing list address.
This is a perfect use the signed commit by multiple persons. Git already
supports it (under the hood and in reporting).
A quick google pulled up my notes on this:
http://marc.info/?l=git&m=140845378317052&w=2
$ cat merge-multisigs.sh
#!/bin/bash
(
for i in "$@"
do
gpg --dearmor < "$i"
done
) | gpg --enarmor
$ cat write-commit.ruby
#!/usr/bin/irb
require 'fileutils'
file = File.open(ARGV[0], "rb")
content = file.read
header = "commit #{content.length}\0"
store = header + content
require 'digest/sha1'
sha1 = Digest::SHA1.hexdigest(store)
require 'zlib'
zlib_content = Zlib::Deflate.deflate(store)
path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
FileUtils.mkdir_p(File.dirname(path))
File.open(path, 'w') { |f| f.write zlib_content }
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
--
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: Finding leaf nodes.
> -Original Message-
> From: Michael J Gruber
> Sent: Monday, April 13, 2015 10:23
>
> Jason Pyeron venit, vidit, dixit 12.04.2015 06:04:
> > I am trying to find all the unmerged commits [5].
>
> "Unmerged" to which branch?
All. I was atempting to describe a leaf node.
>
> It's not clear to me which commits you are looking for. By
> "leaf node" I
> would describe a commit without child commits. "unmerged" can only be
That is exactly what I meant.
> understood relative to a specific branch.
>
> Maybe you are looking for commits from remote refs which are
> not on any
> local branch?
Anywhere, that I know about. If the commit does not have a child, then that
commit needs to be in the list, I do not care about the branches.
>
> > I can find, as a human, all the commits by git log
> --oneline --graph --all [1] but I am looking for a scripted way.
> >
> > But git show-branch -a --independent misses some [2]
>
> This finds refs which are not "contained in" (can be reached from) any
> of the other refs. If a remote ref is contained in another
> remore ref it
> is not listed.
Your description is logical, but how can a commit be included in "another
remote ref"?
>
> > find .git/refs/ -type f -exec cat '{}' ';' | sort -u; finds
> too much [3].
>
> This finds all refs.
I know, the issue is I do not know how to filter it.
>
> > The closest I get is with refs=`git show-ref -s`; git log
> --format=%H $refs --not $(echo "$refs" | sed 's/$/^/') but it
> too [4] gives me extra, but I am really not sure why.
>
> This finds all commits which are on some ref (branch/tag/..),
> excluding
> those which are next to the tip or higher up from those refs.
>
> >
> > * | a54a4fb
> > * | a0d2e63
> > * | dd4400d
> > | | * 68ea2c8
> > | | |\
> > | |/ /
> > |/| |
> > | | * c74d3c5 ??? Why is this the only extra commit listed ???
>
> Because it is not "next to the tip", more specifically: not a first
> parent (foo^) of a referenced commit, and neither a
> predecessor of one.
I need to think on what you just said for this one.
>
> > | |/
> > |/|
> > * | 9c87570
> > * | 717e33d
> > * | 159799f
> >
> >
> > What should I do to automate this?
> >
>
> Please try and restate what you mean by "unmerged commits".
> Maybe remote
> commits not on any local branch, or remote commits not on master?
Regardless of branch references, I need to list all commits which do not have
any child commits.
>
> >
> >
> > 1:
See: yellow lines at
http://client.pdinc.us/git-leaf-nodes-334e98c075877ce78b1ef959cb1155f7.html
> >
> > 2:
> > 4d0579c438e9d750f158124284bd740a5a0e0e26
> > 68ea2c83978a7c023d76ebe438dd7d98fb1fd074
> > 982243cfde0dc6dfb1733d8e95748b7e687f57b8
> > C4bc3c4eb0015c73b50ea280a4a380e3cffc5160
> >
> > 3:
> > 00ea00e8e6a23a4243316f860aa07ed59203ab97
> > 144eb9f673f14010c600766762b99cba1a64cc6e
> > 2250af4ad29b92b07365320c5ccb7a22c17f588e
> > 26bdfdfe71f7ceb4e0954bc5ab6c198481a280ae
> > 283be0f77477fcd8c8bc878c602538f8a3451403
> > 2f47330df8fb0357ef4e4d605d5c402150892a18
> > 3ec60ab0dbdc63760429187605ede4549d7b2bad
> > 43813b0fc44f7c41d2cdd4573145dbeb1aae1aee
> > 4d5b52d440d3a64953a6d7ef3cbb81c8d289e392
> > 556a5c2d759b51080e3bfe07a89b67e927749328
> > 6fe0b6db2718625e5eeb3cbadeb58aa858ab4f1b
> > 717e33d67ad3297a15cb432d3f70f7c12d353fa3
> > 7587a45658aa689cc774d7253007be3feb2eec23
> > ad9b5fa90c8f52b3ca31dd433c2c4b408e5f2a8f
> > b3d7623b74dd75cc4f965d6b37dc461d2786f912
> > c19fc45c87de85122952d63d28a0c7d3a18b79d5
> > e8529e95d89d3f519a31ef7de5bd7f0d0d318e8c
> > f2e86371e7fe3391023adccd61856d088db773dd
> > fceca0050ceee8c4996a5740f7122e96c4948dd8
> >
> > 4:
> > c74d3c5cda60d8be7f38f1ec89c554a1346d57f8
> >
> > 5: My remotes:
> > https://github.com/CipherShed/CipherShed.git
> > https://github.com/pdinc-oss/CipherShed.git
> > https://github.com/discnl/CipherShed.git
> > https://github.com/eaglgenes101/CipherShed.git
> > https://github.com/erkinalp/CipherShed.git
> > https://github.com/GigabyteProductions/CipherShed.git
> > https://github.com/jeffallen/CipherShed.git
> > https://github.com/kaydiechii/CipherShed.git
> > https://github.com/srguglielmo/CipherShed.git
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
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
Finding leaf nodes.
I am trying to find all the unmerged commits [5].
I can find, as a human, all the commits by git log --oneline --graph --all [1]
but I am looking for a scripted way.
But git show-branch -a --independent misses some [2]
find .git/refs/ -type f -exec cat '{}' ';' | sort -u; finds too much [3].
The closest I get is with refs=`git show-ref -s`; git log --format=%H $refs
--not $(echo "$refs" | sed 's/$/^/') but it too [4] gives me extra, but I am
really not sure why.
* | a54a4fb
* | a0d2e63
* | dd4400d
| | * 68ea2c8
| | |\
| |/ /
|/| |
| | * c74d3c5 ??? Why is this the only extra commit listed ???
| |/
|/|
* | 9c87570
* | 717e33d
* | 159799f
What should I do to automate this?
1:
0748f668b7fe0cba7a0edf1684ae84ddf87104ee
13916782bebe690149bfd1c3fb31d6d08942585b
383f3ae77393c2e303b3c32ef7dee122f0b623be
473093c214ba578cd7aecb6e2e5caaad70d173e4
4d0579c438e9d750f158124284bd740a5a0e0e26
68ea2c83978a7c023d76ebe438dd7d98fb1fd074
6900b076d790593a909bc84a1d062217e4a32941
9802bc44da0a35e4c7a917cd23468c387897cccd
982243cfde0dc6dfb1733d8e95748b7e687f57b8
c197b7f71cd6d601b99adbe0a5cf5bf6bc749b6e
c4bc3c4eb0015c73b50ea280a4a380e3cffc5160
c5234422373d0425fa9cd610cb0848b7c33fe436
d6af1c103b0cdeb7e7d45ffce2a838fa7a287aea
eb50b82c6f3f55b66693482a913a5c1cfc19a03d
f9c41c1a17df4358558a23a7c45bc2c60bf97e27
Fb962761aa2ce6fbf77e4769c9e418bbe6f9f47f
2:
4d0579c438e9d750f158124284bd740a5a0e0e26
68ea2c83978a7c023d76ebe438dd7d98fb1fd074
982243cfde0dc6dfb1733d8e95748b7e687f57b8
C4bc3c4eb0015c73b50ea280a4a380e3cffc5160
3:
00ea00e8e6a23a4243316f860aa07ed59203ab97
144eb9f673f14010c600766762b99cba1a64cc6e
2250af4ad29b92b07365320c5ccb7a22c17f588e
26bdfdfe71f7ceb4e0954bc5ab6c198481a280ae
283be0f77477fcd8c8bc878c602538f8a3451403
2f47330df8fb0357ef4e4d605d5c402150892a18
3ec60ab0dbdc63760429187605ede4549d7b2bad
43813b0fc44f7c41d2cdd4573145dbeb1aae1aee
4d5b52d440d3a64953a6d7ef3cbb81c8d289e392
556a5c2d759b51080e3bfe07a89b67e927749328
6fe0b6db2718625e5eeb3cbadeb58aa858ab4f1b
717e33d67ad3297a15cb432d3f70f7c12d353fa3
7587a45658aa689cc774d7253007be3feb2eec23
ad9b5fa90c8f52b3ca31dd433c2c4b408e5f2a8f
b3d7623b74dd75cc4f965d6b37dc461d2786f912
c19fc45c87de85122952d63d28a0c7d3a18b79d5
e8529e95d89d3f519a31ef7de5bd7f0d0d318e8c
f2e86371e7fe3391023adccd61856d088db773dd
fceca0050ceee8c4996a5740f7122e96c4948dd8
4:
c74d3c5cda60d8be7f38f1ec89c554a1346d57f8
5: My remotes:
https://github.com/CipherShed/CipherShed.git
https://github.com/pdinc-oss/CipherShed.git
https://github.com/discnl/CipherShed.git
https://github.com/eaglgenes101/CipherShed.git
https://github.com/erkinalp/CipherShed.git
https://github.com/GigabyteProductions/CipherShed.git
https://github.com/jeffallen/CipherShed.git
https://github.com/kaydiechii/CipherShed.git
https://github.com/srguglielmo/CipherShed.git
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
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: Windows Bluescreen
> -Original Message- > From: Erik Friesen > Sent: Thursday, February 12, 2015 7:22 > > I'd say this is related. http://sourceforge.net/p/mingw/bugs/2240/ > > There isn't much hope, that was filed months ago with no action. I > suggest moving to another ssh library perhaps? Anyways, this is a > windows git bug report, so it really needs to stay with mysgit in my > opinion. FWIW, if it does not get fixed you can use the cygwin git and openssh without many problems, and the cygwin group is pretty responsive to issues like this. > > I'd say it should reproduce without much effort. Do a git push using > win7 64 pro or similar, I'd say it will have issues. > > At minimum, this should be on the list for others to view. I have run > across problems from others, but I don't think they realized it could > be an ssh problem. > > On Thu, Feb 12, 2015 at 4:33 AM, Chris Packham > wrote: > > On Thu, Feb 12, 2015 at 1:33 AM, Erik Friesen > wrote: > >> Pushing over http and https are unaffected.. My linux nas > died, so on > >> rebuild I tried to do the ssh thing, and realized quite soon that > >> things weren't right. > >> > >> As far as other uses of ssh, I don't know, I use putty > frequently, but > >> I am not clear if it is using the same libraries or not. > > > > I think putty ships it's own ssh implementation rather than using an > > openSSH port. > > > >> I hunted around for the bugreport email on mysgit but > couldn't seem to > >> find it. It seems in the foggy recesses I remember > reading about an > >> ssh issue with windows, but can't find it now. > >> > > > > https://github.com/msysgit/git/issues > > > > Happy hunting :). Actually if it is a ssh problem it might be a > > generic MSYS issue. So there's another bug tracker to look through > > > > http://sourceforge.net/p/mingw/bugs/ > > > > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Proper plumbing for porcelain gpg formats on git show?
> -Original Message- > From: Junio C Hamano > Sent: Friday, January 16, 2015 14:53 > > Jonathan Nieder writes: > > >> would there be interest in accepting a patch for > >> > >> %Gs - the raw GPG text from the commit > >> %Gf - the key fingerprint > > > > There may be bikeshedding on the exact format specifier, but aside > > from that I don't see why not. ;-) > > I was about to say "As long as the execution is good, why not? > Spawning an extra process 'gpg --list-packets' is not quite > acceptable without properly being lazy is not acceptable". > > But verify_signed_buffer() reads "gpg --status-fd=1 --verify" > output, it is already done lazily in format_commit_one() only when > the "%G?" placeholder is used, and the output we parse that are > prefixed by [GNUPG:] should have enough information to grab the > fingerprint from on the VALIDSIG line. > > So I do not see a lot of room to screw-up the execution ;-). This kind of begs the question of extracting signatures, not in one's keyring. I was surprised to see %GK fail because it was not yet in the keyring. I would also expect a "B", not a "N" for %G?, maybe there should be a "X" for can't verify. $ gpg --delete-keys DA0848AD gpg (GnuPG) 2.0.14; Copyright (C) 2009 Free Software Foundation, Inc. This is free software: you are free to change and redistribute it. There is NO WARRANTY, to the extent permitted by law. pub 2048R/DA0848AD 2014-06-24 Jason Pyeron Delete this key from the keyring? (y/N) y $ git diff-tree -s --format=%G? HEAD N $ git diff-tree -s --format=%GG HEAD gpg: Signature made Fri 16 Jan 2015 01:33:12 PM EST using RSA key ID DA0848AD gpg: Can't check signature: No public key $ git diff-tree -s --format=%GK HEAD $ gpg --keyserver hkp://pgp.mit.edu --recv-keys 8D6B5984DA0848AD gpg: requesting key DA0848AD from hkp server pgp.mit.edu gpg: key DA0848AD: public key "Jason Pyeron " imported gpg: Total number processed: 1 gpg: imported: 1 (RSA: 1) $ git diff-tree -s --format=%G? HEAD U $ git diff-tree -s --format=%GG HEAD gpg: Signature made Fri 16 Jan 2015 01:33:12 PM EST using RSA key ID DA0848AD gpg: Good signature from "Jason Pyeron " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 8C88 9ECF 7A2F 7977 7CE9 13B4 8D6B 5984 DA08 48AD $ git diff-tree -s --format=%GK HEAD 8D6B5984DA0848AD -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: RFC: update hook for GPG signed submission on secured branches
> -Original Message-
> From: Junio C Hamano
> Sent: Friday, January 16, 2015 14:33
>
> "Jason Pyeron" writes:
>
> > What would you change? Any bugs that you see?
>
> > sigkey=$(\
> > git cat-file $newrev -p |\
>
> "-p" being a command line option should come before revision, but
> more importantly, because you accept pushes only to refs/heads/, you
> would want to explicitly require commit objects, no? i.e.
>
> git cat-file commit "$newrev" |
True.
>
> I am not sure if you need these unsightly backslashes. When you
> stop talking to it after saying "$(", or "$( git cat-file ... |",
> the shell _knows_ that you haven't stopped what you want to tell
> it.
>
> > sed -e '/^ /{H;$!d;}; x;/^gpgsig /!d; s/^gpgsig//;' |\
> > cut -c 2- |\
>
> It always makes me feel nervous to see people pipe sed output to
> another filter that is a mere s/.//;
It was a very quick Lego block build.
>
> Is this complex pipeline the same as this (I didn't understand the
> trailing I at the end)?
Case insensitive, could have used [0-9a-fA-F].
>
> git cat-file commit "$newrev" |
> sed -ne '/^gpgsig /,/^ -END/{
> s/^gpgsig //
> s/^ //p
> }' |
Will all future signature values end with a "^ -END"? I was only going on
the assumption that continuation lines start with a single space.
> gpg --list-packets --textmode |
> sed -ne '/^:signature packet:/s/.*keyid \([0-9A-F]*\).*/\1/p'
>
> > gpg --list-packets --textmode |\
> > sed '/keyid/!d; s/.*keyid \([0-9A-F]\{16\}\).*/\1/I' \
> > )
>
> > if [ -z "$sigkey" ]; then
> > echo no GPG signature on commit $newrev
> > exit 1
> > fi
>
> I am not sure if the design of this, to require signature only on
> the tip commit, is sound. That is not a -bug- in the script,
> though.
It is to handle the "all my devs worked on this, they do GPG", so as
long as the tip os signed, it is an implicit I am responsible for what is
submitted.
>
> > if [[ $refname != refs/heads/* ]]; then
> > echo only heads may be pushed, illegal ref: $refname
> > exit 1;
> > fi
> >
> > head="${refname:11}"
>
> It is hard to tell where the magic number 11 comes from. Perhaps
>
> head="${refname#refs/heads/}"
>
> reads easier?
Much.
Thanks!
-Jason
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
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
RFC: update hook for GPG signed submission on secured branches
Dev & users:
I would like your feedback.
I am working on a continuous integration (CI) system for CipherShed.org and we
want to allow any fork to submit their patch to our CI server farm which will
do integration testing. We want it to be easy to submit code, but to not allow
interference with other submitters branches or fetching of other people's (any
for bandwidth and simplicity) branches.
What would you change? Any bugs that you see?
-Jason (no cc please, I am on the list)
Here are the 2 configs.
$ cat config
[core]
repositoryformatversion = 0
filemode = true
bare = true
[http]
receivepack = true
uploadpack = false
getanyfile = false
$ cat hooks/update
#!/bin/bash
# (c) 2015 PD Inc. License found at http://www.apache.org/licenses/LICENSE-2.0 .
# --- Command line
refname="$1"
oldrev="$2"
newrev="$3"
# --- Safety check
if [ -z "$GIT_DIR" ]; then
echo "Don't run this script from the command line." >&2
echo " (if you want, you could supply GIT_DIR then run" >&2
echo " $0 )" >&2
exit 1
fi
if [ -z "$refname" -o -z "$oldrev" -o -z "$newrev" ]; then
echo "usage: $0 " >&2
exit 1
fi
sigkey=$(\
git cat-file $newrev -p |\
sed -e '/^ /{H;$!d;}; x;/^gpgsig /!d; s/^gpgsig//;' |\
cut -c 2- |\
gpg --list-packets --textmode |\
sed '/keyid/!d; s/.*keyid \([0-9A-F]\{16\}\).*/\1/I' \
)
if [ -z "$sigkey" ]; then
echo no GPG signature on commit $newrev
exit 1
fi
if ! gpg -k "$sigkey" 2> /dev/null > /dev/null; then
# "$sigkey" not known
RES="$(gpg --keyserver hkp://pgp.mit.edu --recv-keys "$sigkey" 2>&1)"
if [ $? -ne 0 ]; then
echo "$RES"
exit 1
fi
fi
sigstatus=$(git log $newrev --pretty=format:%G? -n 1)
case "$sigstatus" in
G)
#ok, trusted
;;
U)
#ok, untrusted
;;
*)
#not ok
echo sigstatus: $sigstatus
git log $newrev --pretty=format:%GG -n 1
exit 1;
;;
esac
if [[ $refname != refs/heads/* ]]; then
echo only heads may be pushed, illegal ref: $refname
exit 1;
fi
head="${refname:11}"
shopt -s nocasematch
case "$head" in
${sigkey}-*)
#ok
;;
${sigkey}/*)
#ok
;;
${sigkey:(-8)}-*)
#ok
;;
${sigkey:(-8)}/*)
#ok
;;
*)
#not your branch
echo "you (a.k.a. $sigkey) are not authorized to push to
branch: $head"
echo "try making a branch like: $sigkey-... or $sigkey/*"
echo "you can use a less secure ${sigkey:(-8)} too"
exit 1
;;
esac
exit 0
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
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
Proper plumbing for porcelain gpg formats on git show?
I can't agree that
COMMITID=ef8df950c8d16dace62e55d18b26617b1268f1bc; \
git cat-file $COMMITID -p |\
sed -e '/^ /{H;$!d;}; x;/^gpgsig /!d; s/^gpgsig//;' |\
cut -c 2- |\
gpg --list-packets --textmode |\
sed '/keyid/!d; s/.*keyid \([0-9A-F]\{16\}\).*/\1/I'
is the way to go, when
COMMITID=ef8df950c8d16dace62e55d18b26617b1268f1bc; \
git log $COMMITID --pretty=format:%GK -n 1
and
COMMITID=ef8df950c8d16dace62e55d18b26617b1268f1bc; \
git show $COMMITID --pretty=format:%GK -s
do the same thing.
Is there a way to properly extract the GPG signature object, such that GPG
operations may be done on it?
Are the git log formats safe to use in scripts (asking because it was said not
to use at
http://git.661346.n2.nabble.com/show-pretty-B-without-a-diff-td5852061.html#a5853270)?
If git log with format specifiers is safe to use, would there be interest in
accepting a patch for
%Gs - the raw GPG text from the commit
%Gf - the key fingerprint
-Jason
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
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: Advise on a push only repo
> -Original Message-
> From: Junio C Hamano
> Sent: Thursday, January 15, 2015 14:31
>
> "Jason Pyeron" writes:
>
> > I am setting up a continous integration (CI) system for an
> open source
> > project and I want to allow forking developers to use the
> system, but
> > I do not want anyone to do a clone or fetch from the CI git
> repo, the
> > repo.
> >
> > Any advice on limiting the https smart protocol to push
> only, blocking clone and fetch?
> >
> > Looking at http-backend.c
> >542 static struct service_cmd {
> > ...
> >558 };
>
> Looking at http-backend.c
>
> 19 struct rpc_service {
> 20 const char *name;
> 21 const char *config_name;
> 22 signed enabled : 2;
> 23 };
> 24
> 25 static struct rpc_service rpc_service[] = {
> 26 { "upload-pack", "uploadpack", 1 },
> 27 { "receive-pack", "receivepack", -1 },
> 28 };
>
> So it would be natural to assume that there must be a way to
> enable/disable these two services, no?
>
> Looking at http_config() there, I would guess perhaps:
>
> [http]
> uploadpack = false
> getanyfile = false
>
> but I am not sure if the latter is needed (or anybody seriously
> tested it, for that matter).
Perfect! Had to add receivepack=true for the anonymous part.
root@twenty-one-100 /opt/git/public
# cat /etc/httpd/conf.d/git.conf
SetEnv GIT_PROJECT_ROOT /opt/git
SetEnv GIT_HTTP_EXPORT_ALL
ScriptAlias /git/ /usr/libexec/git-core/git-http-backend/
Options ExecCGI Indexes
Order allow,deny
Allow from all
Require all granted
root@twenty-one-100 /opt/git/public
# cat /opt/git/public/config
[core]
repositoryformatversion = 0
filemode = true
bare = true
[http]
receivepack = true
uploadpack = false
getanyfile = false
Test get known object...
root@twenty-one-100 /opt/git/public
# dir objects/bd/e1557acecaf3cebb4775b7b734f095e6010c15
-r--r--r--. 1 apache apache 163 Jan 15 16:56
objects/bd/e1557acecaf3cebb4775b7b734f095e6010c15
root@twenty-one-100 /opt/git/public
# curl
http://127.0.0.1/git/public/objects/bd/e1557acecaf3cebb4775b7b734f095e6010c15 -v
* About to connect() to 127.0.0.1 port 80 (#0)
* Trying 127.0.0.1... connected
* Connected to 127.0.0.1 (127.0.0.1) port 80 (#0)
> GET /git/public/objects/bd/e1557acecaf3cebb4775b7b734f095e6010c15 HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3
> Basic ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: 127.0.0.1
> Accept: */*
>
< HTTP/1.1 403 Forbidden
< Date: Thu, 15 Jan 2015 22:08:48 GMT
< Server: Apache/2.2.15 (CentOS)
< Expires: Fri, 01 Jan 1980 00:00:00 GMT
< Pragma: no-cache
< Cache-Control: no-cache, max-age=0, must-revalidate
< Content-Length: 0
< Connection: close
< Content-Type: text/plain; charset=UTF-8
<
* Closing connection #0
root@twenty-one-100 /opt/git/public
# fg
tail -f /var/log/httpd/*_log(wd: /opt/git)
==> /var/log/httpd/error_log <==
[Thu Jan 15 17:08:48 2015] [error] [client 127.0.0.1] Unsupported service:
getanyfile
==> /var/log/httpd/access_log <==
127.0.0.1 - - [15/Jan/2015:17:08:48 -0500] "GET
/git/public/objects/bd/e1557acecaf3cebb4775b7b734f095e6010c15 HTTP/1.1" 403 -
"-" "curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.16.2.3 Basic
ECC zlib/1.2.3 libidn/1.18 libssh2/1.4.2"
^Z
[1]+ Stopped tail -f /var/log/httpd/*_log (wd: /opt/git)
(wd now: /opt/git/public)
root@twenty-one-100 /opt/git/public
#
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
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
Advise on a push only repo
I am setting up a continous integration (CI) system for an open source project
and I want to allow forking developers to use the system, but I do not want
anyone to do a clone or fetch from the CI git repo, the repo.
Any advice on limiting the https smart protocol to push only, blocking clone
and fetch?
Looking at http-backend.c
542 static struct service_cmd {
543 const char *method;
544 const char *pattern;
545 void (*imp)(char *);
546 } services[] = {
547 {"GET", "/HEAD$", get_head},
548 {"GET", "/info/refs$", get_info_refs},
549 {"GET", "/objects/info/alternates$", get_text_file},
550 {"GET", "/objects/info/http-alternates$", get_text_file},
551 {"GET", "/objects/info/packs$", get_info_packs},
552 {"GET", "/objects/[0-9a-f]{2}/[0-9a-f]{38}$", get_loose_object},
553 {"GET", "/objects/pack/pack-[0-9a-f]{40}\\.pack$",
get_pack_file},
554 {"GET", "/objects/pack/pack-[0-9a-f]{40}\\.idx$", get_idx_file},
555
556 {"POST", "/git-upload-pack$", service_rpc},
557 {"POST", "/git-receive-pack$", service_rpc}
558 };
I feel I could just filter /git-receive-pack and /objects/ .
I am going to build my test system now.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
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: Software CM Tool Inquiry
Responses inline. > -Original Message- > From: Campbell, Polly R CTR Maritime EW Sys Div, WXMP > Sent: Tuesday, January 06, 2015 8:58 > > To Whom It May Concern, > > We are a software support activity for a system that is > loaded on a majority of the ships in the navy fleet; I am > looking for a CM software tool with the following > capabilities to meet our requirements: > > - Be able to upload unclassified and classified software > in a central location where everyone in our group could have > access to being able to see and/or pull down the media. This > would require an instance on both enclaves, UNCLASS and CLASSIFIED. > This list is not the best place to discuss that. > - Be able to see each item's contents along with > submitter, date submitted and size. Yes git can do that, but... > > - Lots of storage available with robust > inventory/tracking system. We would like to store a copy of > each hard drive in our systems for each configuration. > Git is designed to be a source tracking system, but others do use it for large objects. > - Procedure accessibility: Procedures should be organized > in an accessible format so that when performing a task, the > individuals will be able to quickly find/access the actual > procedure needing to be used. Do you mean a form of workflow? > > - Software baselines will need to be tracked, both raw > source code, and the compiled install disk. > We can exclude hard drives that are easy to recreate. > > We are interested in reviewing software packages to determine > what will fit our needs. > Again, git is an open source tool and project, not a vendor. You are not going to get a sources sought response from the project proper. If you would like I can help you off list, as this is type of work I supported for DISA and other COCOMs / Agencies. > Thank you, > Polly > > > Polly Campbell > Applied Logistics Services, Inc. > Code WXM, Bldg. 3330S > Crane Division NSWC > 300 Hwy 361 > Crane, IN 47522-5001 > Office: 812.854.8206 > Fax: 812.854.6570 > Email: polly.campbell@navy.mil > SIPR: polly.campb...@navy.smil.mil > > > v/r, Jason Pyeron 202-741-9397 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. smime.p7s Description: S/MIME cryptographic signature
git log --graph --oneline issues (very small edge case)
When a repo has multiple initial commits, the oneline graph can get borked. It will put a commit * with no parent directly above the next commit * with no children. This gives the false impression that the two commits are a sequence on a branch. E.g: * xxx update of A (#0011) * xxx merge of B->A (#0010) |\ | * xxx update of B (#0009) * | xxx update of A (#0008) * | xxx update of A (#0007) | * xxx update of B (#0006) | * xxx update of B (#0005) | * xxx inital commit B (#0004) | * xxx update of A' (#0003) | * xxx fork of A (#0002) |/ * xxx intial commit A (#0001) It should put a blank line after a commit without a parent, like so: * xxx update of A (#0011) * xxx merge of B->A (#0010) |\ | * xxx update of B (#0009) * | xxx update of A (#0008) * | xxx update of A (#0007) | * xxx update of B (#0006) | * xxx update of B (#0005) | * xxx inital commit B (#0004) | | * xxx update of A' (#0003) | * xxx fork of A (#0002) |/ * xxx intial commit A (#0001) Unless it is the last commit to be output. I hit this in the wild https://github.com/pdinc-oss/CipherShed.git, but now that the branches are merged the graph looks fine. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: git push hung?
No cc's please, I am on the list. > -Original Message- > From: Torsten Bögershausen > Sent: Sunday, December 07, 2014 12:58 > > On 2014-12-07 15.24, Jason Pyeron wrote: > > I am trying to push to our local intranet git (smart https > behind apache), and it has been at this point for 10+ hours. > > > > jpyeron@black /projects/git/git > > $ GIT_TRACE=1 git push > > 09:08:45.662902 git.c:349 trace: built-in: git 'push' > > 09:08:45.662902 run-command.c:341 trace: run_command: > 'git-remote-https' 'origin' 'https://intranet.pdinc.us/git/git/' > > 09:08:46.225700 run-command.c:341 trace: run_command: > 'git credential-cache --timeout=999 get' > > 09:08:46.256967 run-command.c:192 trace: exec: > '/bin/sh' '-c' 'git credential-cache --timeout=999 > get' 'git credential-cache --timeout=999 get' > > 09:08:46.366400 git.c:554 trace: exec: > 'git-credential-cache' '--timeout=999' 'get' > > 09:08:46.366400 run-command.c:341 trace: run_command: > 'git-credential-cache' '--timeout=999' 'get' > > 09:08:47.022999 run-command.c:341 trace: run_command: > 'git credential-cache --timeout=999 store' > > 09:08:47.038632 run-command.c:192 trace: exec: > '/bin/sh' '-c' 'git credential-cache --timeout=999 > store' 'git credential-cache --timeout=999 store' > > 09:08:47.116799 git.c:554 trace: exec: > 'git-credential-cache' '--timeout=999' 'store' > > 09:08:47.116799 run-command.c:341 trace: run_command: > 'git-credential-cache' '--timeout=999' 'store' > > 09:08:47.366931 run-command.c:341 trace: run_command: > 'send-pack' '--stateless-rpc' '--helper-status' '--thin' > '--progress' 'https://intranet.pdinc.us/git/git/' > 'refs/heads/master:refs/heads/master' > > 09:08:47.382565 exec_cmd.c:134 trace: exec: 'git' > 'send-pack' '--stateless-rpc' '--helper-status' '--thin' > '--progress' 'https://intranet.pdinc.us/git/git/' > 'refs/heads/master:refs/heads/master' > > 09:08:47.429465 git.c:349 trace: built-in: > git 'send-pack' '--stateless-rpc' '--helper-status' '--thin' > '--progress' 'https://intranet.pdinc.us/git/git/' > 'refs/heads/master:refs/heads/master' > > 09:08:47.538898 run-command.c:341 trace: run_command: > 'pack-objects' '--all-progress-implied' '--revs' '--stdout' > '--thin' '--delta-base-offset' '--progress' > > 09:08:47.695231 exec_cmd.c:134 trace: exec: 'git' > 'pack-objects' '--all-progress-implied' '--revs' '--stdout' > '--thin' '--delta-base-offset' '--progress' > > 09:08:47.742131 git.c:349 trace: built-in: > git 'pack-objects' '--all-progress-implied' '--revs' > '--stdout' '--thin' '--delta-base-offset' '--progress' > > Counting objects: 18734, done. > > Delta compression using up to 2 threads. > > Compressing objects: 100% (5707/5707), done. > > Writing objects: 100% (18734/18734), 9.37 MiB | 0 bytes/s, done. > > Total 18734 (delta 14519), reused 17108 (delta 12968) > > > > Servier died, this is in the log: > > > > fatal: protocol error: expected old/new/ref, got 'shallow > 3339e9f686bd4c17e3575c71327c4ccf1e8e077b' > > > > What steps can I take to debug this hang in the client? > > > > Git fetch hangs the same way with a server exit of fatal: > did not find object for shallow > 3339e9f686bd4c17e3575c71327c4ccf1e8e077b > > > > Note: I fixed the underlying problem with a git fetch > --unshallow upstream > > > Was the log above after the git fetch --unshallow upstream ? > What is the output if you run the following commands on the server: I will have to make a testcase, sice the underlying problem was fixed at the time. > git show 3339e9f686bd4c17e jpyeron@black /projects/git/git $ git show 3339e9f686bd4c17e commit 3339e9f686bd4c17e3575c71327c4ccf1e8e077b Author: Nicolas Pitre Date: Wed Jul 16 02:31:38 2008 -0400 ...
git push hung?
I am trying to push to our local intranet git (smart https behind apache), and it has been at this point for 10+ hours. jpyeron@black /projects/git/git $ GIT_TRACE=1 git push 09:08:45.662902 git.c:349 trace: built-in: git 'push' 09:08:45.662902 run-command.c:341 trace: run_command: 'git-remote-https' 'origin' 'https://intranet.pdinc.us/git/git/' 09:08:46.225700 run-command.c:341 trace: run_command: 'git credential-cache --timeout=999 get' 09:08:46.256967 run-command.c:192 trace: exec: '/bin/sh' '-c' 'git credential-cache --timeout=999 get' 'git credential-cache --timeout=999 get' 09:08:46.366400 git.c:554 trace: exec: 'git-credential-cache' '--timeout=999' 'get' 09:08:46.366400 run-command.c:341 trace: run_command: 'git-credential-cache' '--timeout=999' 'get' 09:08:47.022999 run-command.c:341 trace: run_command: 'git credential-cache --timeout=999 store' 09:08:47.038632 run-command.c:192 trace: exec: '/bin/sh' '-c' 'git credential-cache --timeout=999 store' 'git credential-cache --timeout=999 store' 09:08:47.116799 git.c:554 trace: exec: 'git-credential-cache' '--timeout=999' 'store' 09:08:47.116799 run-command.c:341 trace: run_command: 'git-credential-cache' '--timeout=999' 'store' 09:08:47.366931 run-command.c:341 trace: run_command: 'send-pack' '--stateless-rpc' '--helper-status' '--thin' '--progress' 'https://intranet.pdinc.us/git/git/' 'refs/heads/master:refs/heads/master' 09:08:47.382565 exec_cmd.c:134 trace: exec: 'git' 'send-pack' '--stateless-rpc' '--helper-status' '--thin' '--progress' 'https://intranet.pdinc.us/git/git/' 'refs/heads/master:refs/heads/master' 09:08:47.429465 git.c:349 trace: built-in: git 'send-pack' '--stateless-rpc' '--helper-status' '--thin' '--progress' 'https://intranet.pdinc.us/git/git/' 'refs/heads/master:refs/heads/master' 09:08:47.538898 run-command.c:341 trace: run_command: 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress' 09:08:47.695231 exec_cmd.c:134 trace: exec: 'git' 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress' 09:08:47.742131 git.c:349 trace: built-in: git 'pack-objects' '--all-progress-implied' '--revs' '--stdout' '--thin' '--delta-base-offset' '--progress' Counting objects: 18734, done. Delta compression using up to 2 threads. Compressing objects: 100% (5707/5707), done. Writing objects: 100% (18734/18734), 9.37 MiB | 0 bytes/s, done. Total 18734 (delta 14519), reused 17108 (delta 12968) Servier died, this is in the log: fatal: protocol error: expected old/new/ref, got 'shallow 3339e9f686bd4c17e3575c71327c4ccf1e8e077b' What steps can I take to debug this hang in the client? Git fetch hangs the same way with a server exit of fatal: did not find object for shallow 3339e9f686bd4c17e3575c71327c4ccf1e8e077b Note: I fixed the underlying problem with a git fetch --unshallow upstream -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: FW: [cygwin] Cygwin's git says "error: failed to read delta-pack base object"
TLDR = Cygwin remote filesystem sometimes has strange failures -> workaround is
to use rename, not link/unlink;
see
https://github.com/pdinc-oss/git/commit/5a36824ed01d4335148ca3846e75cc99c11650e2
> -Original Message-
> From: Jason Pyeron
> Sent: Friday, December 05, 2014 10:30
>
> > -Original Message-
> > From: Jason Pyeron
> > Sent: Thursday, December 04, 2014 16:34
> >
> > > -Original Message-
> > > From: brian m. carlson
> > > Sent: Wednesday, December 03, 2014 19:55
> > >
> > > On Wed, Dec 03, 2014 at 06:31:18PM -0500, Jason Pyeron wrote:
> > > > I remember hitting this a while ago, but just gave up.
> > > >
> > > > It seems to be a problem for others too.
> > > >
> > > > Any ideas on how to debug this so it can be patched?
> > > >
> > > > -Original Message-
> > > > From: Dave Lindbergh
> > > > Sent: Wednesday, December 03, 2014 18:07
> > > > To: cygwin
> > > >
> > > > Aha - you're right.
> > > >
> > > > It works fine on a local NTFS volume.
> > > >
> > > > I get the error when I do it on Z:, which is mapped to a
> > > network drive
> > > > (on another Windows box).
> > > >
> > > > Is there a workaround? Why does this happen?
I have a really hacky workaround, commit
5a36824ed01d4335148ca3846e75cc99c11650e2 comments out the logic and forces a
rename instead of link and unlink.
https://github.com/pdinc-oss/git/tree/cygwin-issue-remoteCIFS-rename
> Pseudo code and observations
> ./sha1_file.c:write_loose_object(sha1)
> {
> filename=sha1_file_name(sha1)
> (fd,tmp_file)=create_tmpfile(filename)
> write_buffer(fd)
> close_sha1_file(fd)
> return move_temp_to_file(tmp_file, filename)
> }
>
> move_temp_to_file(tmpfile, filename)
> {
> // I am thinking about forcing renames to see if the problem
> exists then as well
> // if that "works" then a per repo config option allowing
> for forced renames
> if (OBJECT_CREATION_USES_RENAMES) goto try_rename
> else if link(tmpfile,filename)
>
Dave has tested a build I made for him on 64 bit Cygwin and it works. I no
longer have access to the environment I was having this problem in last
February. I will try to investigate this further, but I am not hopeful, maybe
Corinna will have luck on the issue. But I was in a secure corporate
environment and I thought the host based security system (AV), coupled with the
remote file system was causing the problem, namely files created are not
available instantly.
I do think that we should have a config option for this, as most users who
could encounter such a problem are not likely to be able (or allowed) to
rebuild the git executable themselves.
> > -Original Message-
> > From: Corinna Vinschen
> > Sent: Friday, December 05, 2014 6:35
> > To: cyg...@cygwin.com
>
> > What I found in the strace is this:
> >
> > - Create file Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ
> >
> > - open file, write something, close file.
> >
> > - link (Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ,
> >
> >
> Z:\pic32mx-bmf\.git\objects\30\0bdeb2fd209d24afb865584da10b78aa8fefc4)
> > succeeds.
> >
> > - unlink (Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ) succeeds
> >
> > - Trying to open
> >
> >
> Z:\pic32mx-bmf\.git\objects\30\0bdeb2fd209d24afb865584da10b78aa8fefc4
> > but the file doesn't exist and NtCreateFile fails with status
> > 0xC034, STATUS_OBJECT_NAME_NOT_FOUND --> ENOENT.
> >
> > - Subsequent unlink (Z:\pic32mx-bmf\.git\objects\30) fails with a
> > STATUS_DIRECTORY_NOT_EMPTY --> ENOTEMPTY.
> >
> > - git seems to be prepared for such a case, the parent process calls
> > opendir/readdir on the directory. Enumerating the files in
> > Z:\pic32mx-bmf\.git\objects\30 shows the entries ".", ".." and
> > "0bdeb2fd209d24afb865584da10b78aa8fefc4".
> >
> > - Then git calls lstat on the file, which results in NtOpenFile
> > returning status STATUS_OBJECT_NAME_NOT_FOUND again.
> >
> > - From a POSIX POV this means "somebody else" deleted the file,
> > so the dir is empty now. Git tries to delete the directory again,
> > which again results in STATUS_DIRECTORY_NOT_EMPTY --> ENOTEMPTY
> > and, internally, a sharing vio
RE: FW: [cygwin] Cygwin's git says "error: failed to read delta-pack base object"
> -Original Message-
> From: Jason Pyeron
> Sent: Thursday, December 04, 2014 16:34
> To: git@vger.kernel.org
> Cc: 'brian m. carlson'
> Subject: RE: FW: [cygwin] Cygwin's git says "error:
> failed to read delta-pack base object"
>
> > -Original Message-
> > From: brian m. carlson
> > Sent: Wednesday, December 03, 2014 19:55
> >
> > On Wed, Dec 03, 2014 at 06:31:18PM -0500, Jason Pyeron wrote:
> > > I remember hitting this a while ago, but just gave up.
> > >
> > > It seems to be a problem for others too.
> > >
> > > Any ideas on how to debug this so it can be patched?
> > >
> > > -Original Message-
> > > From: Dave Lindbergh
> > > Sent: Wednesday, December 03, 2014 18:07
> > > To: cygwin
> > >
> > > Aha - you're right.
> > >
> > > It works fine on a local NTFS volume.
> > >
> > > I get the error when I do it on Z:, which is mapped to a
> > network drive
> > > (on another Windows box).
> > >
> > > Is there a workaround? Why does this happen?
> >
> > I don't think anyone is sure. My wild guess is that
> there's something
> > about the way that Cygwin wraps Windows calls that makes it
> > fail in this
> > case. It might be interesting to run the Windows and
> Cygwin versions
> > under an strace equivalent and see where things differ.
>
> [this was posted to the cygwin list]
>
> http://nerdfever.com/files/strace.txt
>
> >
> > It's an interesting problem, but I don't have any Windows
> > systems, so I
> > can't look into it.
>
> If it becomes a little less magic, I will chomp on the
> problem, but I cannot make a predictable test case.
Corrina at Cygwin devined the strace (see below) and I am working on a test
cases and hacks.
Pseudo code and observations
./sha1_file.c:write_loose_object(sha1)
{
filename=sha1_file_name(sha1)
(fd,tmp_file)=create_tmpfile(filename)
write_buffer(fd)
close_sha1_file(fd)
return move_temp_to_file(tmp_file, filename)
}
move_temp_to_file(tmpfile, filename)
{
// I am thinking about forcing renames to see if the problem exists then as
well
// if that "works" then a per repo config option allowing for forced renames
if (OBJECT_CREATION_USES_RENAMES) goto try_rename
else if link(tmpfile,filename)
if (failed except exist failures)
{
try_rename:
rename(tmpfile, filename)
if (ok) goto out
}
unlink_or_warn(tmpfile)
if (failed except exist failures) return error
out:
}
write_sha1_file(sha1)
{
return write_loose_object(sha1)
}
> -Original Message-
> From: Corinna Vinschen
> Sent: Friday, December 05, 2014 6:35
> To: cyg...@cygwin.com
> What I found in the strace is this:
>
> - Create file Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ
>
> - open file, write something, close file.
>
> - link (Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ,
>
> Z:\pic32mx-bmf\.git\objects\30\0bdeb2fd209d24afb865584da10b78aa8fefc4)
> succeeds.
>
> - unlink (Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ) succeeds
>
> - Trying to open
>
> Z:\pic32mx-bmf\.git\objects\30\0bdeb2fd209d24afb865584da10b78aa8fefc4
> but the file doesn't exist and NtCreateFile fails with status
> 0xC034, STATUS_OBJECT_NAME_NOT_FOUND --> ENOENT.
>
> - Subsequent unlink (Z:\pic32mx-bmf\.git\objects\30) fails with a
> STATUS_DIRECTORY_NOT_EMPTY --> ENOTEMPTY.
>
> - git seems to be prepared for such a case, the parent process calls
> opendir/readdir on the directory. Enumerating the files in
> Z:\pic32mx-bmf\.git\objects\30 shows the entries ".", ".." and
> "0bdeb2fd209d24afb865584da10b78aa8fefc4".
>
> - Then git calls lstat on the file, which results in NtOpenFile
> returning status STATUS_OBJECT_NAME_NOT_FOUND again.
>
> - From a POSIX POV this means "somebody else" deleted the file,
> so the dir is empty now. Git tries to delete the directory again,
> which again results in STATUS_DIRECTORY_NOT_EMPTY --> ENOTEMPTY
> and, internally, a sharing violation which disallows to move the
> directory out of the way.
>
> This looks suspiciously like a bug in the remote filesystem. Link
> succeeded, so there are two links to the same file in the directory.
> Unlinking link 1 succeeds, so there's still one link to the
> file in the
> directory, but link 2 is inaccessible as if the file has been deleted
> completely. Thus, a full POSIX git on this drive is broken.
>
> Can you please run
>
> /usr/lib/csih/getVolInfo /cygdriv
RE: SPAM: RE: FW: [cygwin] Cygwin's git says "error: failed to read delta-pack base object"
> -Original Message-
> From: git-ow...@vger.kernel.org
> [mailto:git-ow...@vger.kernel.org] On Behalf Of Jason Pyeron
> Sent: Thursday, December 04, 2014 16:34
> To: git@vger.kernel.org
> Cc: 'brian m. carlson'
> Subject: SPAM: RE: FW: [cygwin] Cygwin's git says "error:
> failed to read delta-pack base object"
>
> > -Original Message-
> > From: brian m. carlson
> > Sent: Wednesday, December 03, 2014 19:55
> >
> > On Wed, Dec 03, 2014 at 06:31:18PM -0500, Jason Pyeron wrote:
> > > I remember hitting this a while ago, but just gave up.
> > >
> > > It seems to be a problem for others too.
> > >
> > > Any ideas on how to debug this so it can be patched?
> > >
> > > -Original Message-
> > > From: Dave Lindbergh
> > > Sent: Wednesday, December 03, 2014 18:07
> > > To: cygwin
> > >
> > > Aha - you're right.
> > >
> > > It works fine on a local NTFS volume.
> > >
> > > I get the error when I do it on Z:, which is mapped to a
> > network drive
> > > (on another Windows box).
> > >
> > > Is there a workaround? Why does this happen?
> >
> > I don't think anyone is sure. My wild guess is that
> there's something
> > about the way that Cygwin wraps Windows calls that makes it
> > fail in this
> > case. It might be interesting to run the Windows and
> Cygwin versions
> > under an strace equivalent and see where things differ.
>
> [this was posted to the cygwin list]
>
> http://nerdfever.com/files/strace.txt
>
> >
> > It's an interesting problem, but I don't have any Windows
> > systems, so I
> > can't look into it.
>
> If it becomes a little less magic, I will chomp on the
> problem, but I cannot make a predictable test case.
Corrina at Cygwin devined the strace (see below) and I am working on a test
cases and hacks.
Pseudo code and observations
./sha1_file.c:write_loose_object(sha1)
{
filename=sha1_file_name(sha1)
(fd,tmp_file)=create_tmpfile(filename)
write_buffer(fd)
close_sha1_file(fd)
return move_temp_to_file(tmp_file, filename)
}
move_temp_to_file(tmpfile, filename)
{
// I am thinking about forcing renames to see if the problem exists then as
well
// if that "works" then a per repo config option allowing for forced renames
if (OBJECT_CREATION_USES_RENAMES) goto try_rename
else if link(tmpfile,filename)
if (failed except exist failures)
{
try_rename:
rename(tmpfile, filename)
if (ok) goto out
}
unlink_or_warn(tmpfile)
if (failed except exist failures) return error
out:
}
write_sha1_file(sha1)
{
return write_loose_object(sha1)
}
> -Original Message-
> From: Corinna Vinschen
> Sent: Friday, December 05, 2014 6:35
> To: cyg...@cygwin.com
> What I found in the strace is this:
>
> - Create file Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ
>
> - open file, write something, close file.
>
> - link (Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ,
>
> Z:\pic32mx-bmf\.git\objects\30\0bdeb2fd209d24afb865584da10b78aa8fefc4)
> succeeds.
>
> - unlink (Z:\pic32mx-bmf\.git\objects\30\tmp_obj_YljwNZ) succeeds
>
> - Trying to open
>
> Z:\pic32mx-bmf\.git\objects\30\0bdeb2fd209d24afb865584da10b78aa8fefc4
> but the file doesn't exist and NtCreateFile fails with status
> 0xC034, STATUS_OBJECT_NAME_NOT_FOUND --> ENOENT.
>
> - Subsequent unlink (Z:\pic32mx-bmf\.git\objects\30) fails with a
> STATUS_DIRECTORY_NOT_EMPTY --> ENOTEMPTY.
>
> - git seems to be prepared for such a case, the parent process calls
> opendir/readdir on the directory. Enumerating the files in
> Z:\pic32mx-bmf\.git\objects\30 shows the entries ".", ".." and
> "0bdeb2fd209d24afb865584da10b78aa8fefc4".
>
> - Then git calls lstat on the file, which results in NtOpenFile
> returning status STATUS_OBJECT_NAME_NOT_FOUND again.
>
> - From a POSIX POV this means "somebody else" deleted the file,
> so the dir is empty now. Git tries to delete the directory again,
> which again results in STATUS_DIRECTORY_NOT_EMPTY --> ENOTEMPTY
> and, internally, a sharing violation which disallows to move the
> directory out of the way.
>
> This looks suspiciously like a bug in the remote filesystem. Link
> succeeded, so there are two links to the same file in the directory.
> Unlinking link 1 succeeds, so there's still one link to the
> file in the
> directory, but link 2 is inaccessible as if the file has
RE: FW: [cygwin] Cygwin's git says "error: failed to read delta-pack base object"
> -Original Message- > From: brian m. carlson > Sent: Wednesday, December 03, 2014 19:55 > > On Wed, Dec 03, 2014 at 06:31:18PM -0500, Jason Pyeron wrote: > > I remember hitting this a while ago, but just gave up. > > > > It seems to be a problem for others too. > > > > Any ideas on how to debug this so it can be patched? > > > > -Original Message- > > From: Dave Lindbergh > > Sent: Wednesday, December 03, 2014 18:07 > > To: cygwin > > > > Aha - you're right. > > > > It works fine on a local NTFS volume. > > > > I get the error when I do it on Z:, which is mapped to a > network drive > > (on another Windows box). > > > > Is there a workaround? Why does this happen? > > I don't think anyone is sure. My wild guess is that there's something > about the way that Cygwin wraps Windows calls that makes it > fail in this > case. It might be interesting to run the Windows and Cygwin versions > under an strace equivalent and see where things differ. [this was posted to the cygwin list] http://nerdfever.com/files/strace.txt > > It's an interesting problem, but I don't have any Windows > systems, so I > can't look into it. If it becomes a little less magic, I will chomp on the problem, but I cannot make a predictable test case. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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
FW: [cygwin] Cygwin's git says "error: failed to read delta-pack base object"
I remember hitting this a while ago, but just gave up. It seems to be a problem for others too. Any ideas on how to debug this so it can be patched? -Original Message- From: Dave Lindbergh Sent: Wednesday, December 03, 2014 18:07 To: cygwin Subject: Re: [cygwin] Cygwin's git says "error: failed to read delta-pack base object" On Wed, Dec 3, 2014 at 3:42 PM, Jason Pyeron wrote: > [copy off list, because the sourceware system admins throws temper tantrums] >> -Original Message- >> From: Dave L >> Sent: Wednesday, December 03, 2014 15:30 >> >> ...but the git from github.com works fine. >> >> I installed Cygwin's version of git, and get this: >> >> $ git clone https://github.com/nerdfever/pic32mx-bmf >> Cloning into 'pic32mx-bmf'... >> remote: Counting objects: 12, done. >> remote: Total 12 (delta 0), reused 0 (delta 0) >> error: failed to read delta-pack base object >> 300bdeb2fd209d24afb865584da10b78aa8fefc4 >> fatal: unpack-objects failed > > What file system are you on? Local NTFS or remote? Aha - you're right. It works fine on a local NTFS volume. I get the error when I do it on Z:, which is mapped to a network drive (on another Windows box). Is there a workaround? Why does this happen? --Dave -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- 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: How safe are signed git tags? Only as safe as SHA-1 or somehow safer?
> -Original Message- > From: Patrick Schleizer > Sent: Friday, November 21, 2014 18:01 > > Dear git developers! > > Jeff King wrote: > > On Sun, Nov 16, 2014 at 03:31:10PM +, Patrick Schleizer wrote: > > > >> How safe are signed git tags? Especially because git uses > SHA-1. There > >> is contradictory information around. > >> > >> So if one verifies a git tag (`git tag -v tagname`), then > `checksout`s > >> the tag, and checks that `git status` reports no untracked/modified > >> files, without further manually auditing the code, how > secure is this > >> actually? Is it only as safe as SHA-1? > > > > Yes, it is only as "safe as SHA-1" in the sense that you > have GPG-signed > > only a SHA-1 hash. If somebody can find a collision with a > hash you have > > signed, they can substitute the colliding data for the data > you signed. The whole issue is a lot better than this makes it sound. Yes it is just a SHA1 hash, but it is a hash of a structured data format. You have very observable parts of that well structured data providede to the hash. The commit message, the directory contents, and lastly the files themselves. For a collision to occur, the commit message would have to likely have garbage in the message of a large nature. To generate a colision by commited file contents is unlikely because the file contents is reduced to a hash in the directory structure, which is in turn reduced to a hash in a commit structure. This would be noticed. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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 report: Author/Commit date in ISO 8601 format
> -Original Message- > From: Jeff King > Sent: Tuesday, August 26, 2014 9:33 > > On Tue, Aug 26, 2014 at 03:19:11PM +0200, Oliver Busch wrote: > > > PS: As far as I understand it, there is no "optionality" of > the "T" as an > > indicator for the start of the time part. > > The standard says (and I am quoting from Wikipedia here, as I do not > have it myself): > > 4.3.2 NOTE: By mutual agreement of the partners in information > interchange, the character [T] may be omitted in applications where > there is no risk of confusing a date and time of day representation > with others defined in this International Standard. >From ISO 8601:2004 4.3.2 Complete representations The time elements of a date and time of day expression shall be written in the following sequence. a) For calendar dates: year - month - day of the month - time designator - hour - minute - second - zone designator b) For ordinal dates: year - day of the year - time designator - hour - minute - second - zone designator c) For week dates: year - week designator - week - day of the week - time designator - hour - minute - second - zone designator The zone designator is empty if use is made of local time in accordance with 4.2.2.2 through 4.2.2.4, it is the UTC designator [Z] if use is made of UTC of day in accordance with 4.2.4 and it is the difference-component if use is made of local time and the difference from UTC in accordance with 4.2.5.2. The character [T] shall be used as time designator to indicate the start of the representation of the time of day component in these expressions. The hyphen [-] and the colon [:] shall be used, in accordance with 4.4.4, as separators within the date and time of day expressions, respectively, when required. NOTE By mutual agreement of the partners in information interchange, the character [T] may be omitted in applications where there is no risk of confusing a date and time of day representation with others defined in this International Standard. > > But I am not sure that "omitted" means "can be replaced with a space". > And while you can define "by mutual agreement" as "git defines the > format, so any consumers agree to it" that is not necessarily > useful to > somebody who wants to feed the result to an iso8601 parser > that does not > know or care about git (i.e., it shoves the conversion work onto the > person in the middle). Omitted /T?/ does not mean replaced with another character. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: [PATCH 00/18] Signed push
> -Original Message- > From: Junio C Hamano > Sent: Monday, August 25, 2014 13:55 > > Stefan Beller writes: > > >> "burden" is not an issue, as I'll be signing the push certificate > >> anyway when I push. A signed tag or a signed commit and > signed push > >> certificate solves two completely separate and orthogonal issues. > >> > >> What happens if you break into GitHub or k.org and did > >> > >> $ git tag maint_2014_08_22 master_2014_08_22 > > > > Ok, I personally haven't used tags a lot. > > I just tried to > > git tag -s testbreaktag v2.1.0 > > git show testbreaktag > > # However it would still read: > > tag v2.1.0 > > Tagger: Junio C Hamano > > Date: Fri Aug 15 15:09:28 2014 -0700 > > > > So as I do not posess your private key I could not create > signed tags > > even if I were to break into github/k.org > > The point was that after I push to 'maint', you break into the site > and copy or move that tag as if I pushed to 'master'. What is needed is not a signed push per se, but rather a need for a set of signed HEADS ... > > You could argue that I could create a signed tag 'maint-2014-08-25', > push it, and if you moved it to tags/master-2014-08-25 as an > attacker, the refname would not match the "tag " line in the signed > tag object. While that is true, nobody other thaan fsck checks the > contents on the "tag " line in practice. > > But more importantly. > > I may deem a commit a sensible version for the 'master' branch of > one repository but it would not be sensible for another repository's > 'master' branch. Imagine a world just like the kernel development > during 2.6 era used to be, where there was a separate tree 2.4 > maintained with its own 'master' branch. What is appropriate for > the tip of 'master' to one repository is not good for the other one, ... and these signed HEADS need to be tied to a particular repository instance. AFAIK git does not have any unique identifier per repository instance to leverage. If you were to make a repository instance id you could take that and the branch name as input to a signed hash for verification later. But this leads to deeper issues about new workflow, new configuration storage mechanisms, etc. > and your timestamped "tag " line may say for which branch the push > was for but does not say for which repository. The exact problem is > also shared with the desire to have a "branch" object expressed > elsewhere; as there is no identity for a "branch" in a distributed > world, trying to name "branch" as if it is a global entity without > mentioning what repository will lead to tears. > > Besides, these tags/maint-2014-08-25 tags will be interesting only > for those who are auditing and not for general public, and we do not > have a good way to "hide" uninteresting refs until those with narrow > niche interest ask yet, which is something we may want to add soon, > but I do not want "auditable push" taken hostage to that unrelated > feature. > -- > 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 > > -- 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: Signinig a commit with multiple signatures
> -Original Message-
> From: Jeff King
> Sent: Tuesday, August 19, 2014 4:05
>
> On Sun, Aug 17, 2014 at 09:30:47AM -0400, Jason Pyeron wrote:
>
> > I am working on an open source project right now where we
> are looking
> > to enforce a N of M audit approval process. It turns out that git
> > supports verifying multiple signatures because gpg supports
> signature
> > merging.
>
> In the scheme you propose, the commit object is actually rewritten. So
> whoever made and signed it first will then need to rebase on
> top of the
> rewritten multi-signed version.
Not exactly. A known and shared commit is used as the parent of an empty, no
changes commit. The "no changes" commit object is taken and passed around
before being added into the repository. There is no need for a rebase.
But my scheme uses out-of-band process to accomplish this. The idea of using
git to "distribute" the conflict resolution seemed like a valid use case of
sharing a working copy state for a distributed commit, just like this. [1][2]
>
> Is there a reason not to use detached signatures, and let each person
Yes. The embeded signatures provides the best user experience (UX) for
verification.
> add them after the fact? You can store them in git-notes and then push
> them along with the other commits (you can even check in a pre-receive
> hook that the commits meet your N of M criteria, as long as everybody
> has pushed up their signature notes).
>
> > $ cat write-commit.ruby
> > #!/usr/bin/irb
> > require 'fileutils'
> > file = File.open(ARGV[0], "rb")
> > content = file.read
> > header = "commit #{content.length}\0"
> > store = header + content
> > require 'digest/sha1'
> > sha1 = Digest::SHA1.hexdigest(store)
> > require 'zlib'
> > zlib_content = Zlib::Deflate.deflate(store)
> > path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
> > FileUtils.mkdir_p(File.dirname(path))
> > File.open(path, 'w') { |f| f.write zlib_content }
>
> I think this is just "git hash-object -w -t commit ", isn't it?
Let me find the most complicated way of saying this, yes. I feel silly for that.
-Jason
[1]:
http://git.661346.n2.nabble.com/Sharing-a-massive-distributed-merge-td6178696.html
[2]:
http://git.661346.n2.nabble.com/Sharing-merge-conflict-resolution-between-multiple-developers-td7616700.html
--
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: Location of git config on Windows
> -Original Message- > From: Daniel Corbe > Sent: Sunday, August 17, 2014 16:18 > > > I installed git on my Windows machine while it was connected to my > corporate network. It picked up on that fact and used a > mapped drive to > store its configuration file. > > As a result, I cannot currently use git when disconnected from my > network. It throws the following error message: fatal: > unable to access > 'Z:\/.config/git/config': Invalid argument As a workaround, use subst command to map the Z: to another path on your system. Depending on your OS and your git usage patterns you may have to perform the operation twice at both non-privilged and priviliged prompts. Ex: subst z: c:\Users\corbed\cached-z-drive > > Obviously this value is stored in the registry somewhere > because I made > an attempt to uninstall and reinstall git with the same results. > > Can someone give me some guidance here? > -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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
Signinig a commit with multiple signatures
I am working on an open source project right now where we are looking to
enforce a N of M audit approval process. It turns out that git supports
verifying multiple signatures because gpg supports signature merging.
My question is how can this workflow best be added into git and if not added
atleast supported.
Here are the manual procedures (scripts are in the bundle too):
> Procedures:
>
> 1. Identify a normal commit.
> 2. create a new commit file as:
> parent commit-id-of-step-1
> tree tree-id-from-git-cat-file-commit-commit-id-of-step-1
> author CipherShed Security Team
> timestamp timezone
> committer Actual Person timestamp timezone
> gpgsig output-from-merge-sig-tool [1]
> more-output
> more-output
>
> Comments for this commit
> ...
> ...
>
> 3. run ruby script [2] to add commit to git db
> 4. git update-ref refs/heads/BRANCH-NAME new-commit-id
To do this most properly I feel like there needs to be a way to "share" the
repository state and intterrupt the commit process.
Comments?
1:
$ cat merge-multisigs.sh
#!/bin/bash
(
for i in "$@"
do
gpg --dearmor < "$i"
done
) | gpg --enarmor
2:
$ cat write-commit.ruby
#!/usr/bin/irb
require 'fileutils'
file = File.open(ARGV[0], "rb")
content = file.read
header = "commit #{content.length}\0"
store = header + content
require 'digest/sha1'
sha1 = Digest::SHA1.hexdigest(store)
require 'zlib'
zlib_content = Zlib::Deflate.deflate(store)
path = '.git/objects/' + sha1[0,2] + '/' + sha1[2,38]
FileUtils.mkdir_p(File.dirname(path))
File.open(path, 'w') { |f| f.write zlib_content }
P.S. This was inspired by actual events and the parent thread.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
multisign.bundle
Description: Binary data
Git diff cr+lf inconsistency observations
(I am on the list cc not needed) jpyeron@black /projects/cipherShed $ git --version && uname -a git version 1.8.4.21.g992c386 CYGWIN_NT-5.2-WOW64 black 1.7.30(0.272/5/3) 2014-05-23 10:36 i686 Cygwin jpyeron@black /projects/cipherShed $ git diff src/Format/Format.vcproj diff --git a/src/Format/Format.vcproj b/src/Format/Format.vcproj index 41081b5..e78f153 100644 --- a/src/Format/Format.vcproj +++ b/src/Format/Format.vcproj @@ -505,6 +505,10 @@ > ^M + ^M + jpyeron@black /projects/cipherShed $ hexdump.exe -C src/Format/Format.vcproj | less 29c0 09 09 3c 2f 46 69 6c 65 3e 0d 0a 09 09 09 3c 46 |...| ---^^^^--- When it shows these, 2a50 09 09 09 3c 2f 46 69 6c 65 3e 0d 0a 09 09 09 3c |<| -^^--- these, 2a60 46 69 6c 65 0d 0a 09 09 09 09 52 65 6c 61 74 69 |File..Relati| --^^-- and these. 2a70 76 65 50 61 74 68 3d 22 2e 2e 5c 43 6f 6d 6d 6f |vePath="..\Commo| 2a80 6e 5c 54 63 64 65 66 73 2e 68 22 0d 0a 09 09 09 |n\Tcdefs.h".| 2a90 09 3e 0d 0a 09 09 09 3c 2f 46 69 6c 65 3e 0d 0a |.>...| -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Support for EBCDIC
> -Original Message-
> From: Jeff King
> Sent: Thursday, July 03, 2014 13:34
>
> On Wed, Jul 02, 2014 at 07:39:12PM -0700, Scott McKellar wrote:
>
> > Is Git supposed to be usable in an environment where the
> execution character set is EBCDIC?
>
> Not really.
If the core uses specific 8bit values for the internals then there is a hope and
prayer.
E.g. "blob" would need to be char _BLOB={0x62,0x6c,0x6f,0x62} because the hash
calculation would be wrong if were {0x82,0x93,0x96,0x82} ensuring the compiler
does not change that "binary" data value.
>
> In addition to the cases you found (and I would be surprised if there
> are not more, such as our reimplementation of ctype.h), we assume:
>
> - we can intermingle ASCII from string literals with user
> data to form
> diffs, commit objects, network protocols, etc. This is actually a
> problem not just for EBCDIC, but for any encoding which is not an
> ASCII-superset (like UTF-16).
And then all output would require code-page aware translation, but fix the above
first.
>
> - many outputs from git should be ASCII in order to
> interoperate with
> the outside world (object headers, network protocols, etc).
>
> So I'd be surprised if things worked well in an EBCDIC
> environment (but
> I have never worked with one, so maybe I do not understand all of the
> implications).
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
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: Show containing branches in log?
> -Original Message-
> From: Jeff King
> Sent: Wednesday, July 02, 2014 12:35
>
> On Wed, Jul 02, 2014 at 09:50:57AM -0500, Robert Dailey wrote:
>
> > I know that with the `git branch` command I can determine which
> > branches contain a commit. Is there a way to represent this
> > graphically with `git log`? Sometimes I just have a commit,
> and I need
> > to find out what branch contains that commit. The reason why `git
> > branch --contains` doesn't solve this problem for me is
> that it names
> > almost all branches because of merge commits. Too much ancestry has
> > been built since this commit, so there is no way to find
> the "closest"
> > branch that contains that commit.
> >
> > Is there a way to graphically see what is the "nearest" named ref to
> > the specified commit in the logs?
>
> Have you tried "git describe --contains --all "?
>
> To some degree, I fear your question isn't something git can
> answer. If
> the branch containing the commit has been merged into other branches,
> then they all "contain" the commit. There is not really any reason to
> prefer one over the other ("describe --contains" will try to find the
> "closest" branch, but that is based on heuristics and is not
> necessarily
> well-defined).
Another way I answer this question is git log --oneline --graph --all and then
search for the commit and follow the lines.
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
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
Git log --show-signature breaks --graph formatting
It looks like the gpg output is not parsed to prefix the correct number of spaces. What interests me the most is the folowing line is also wrong. $ git log --graph * commit 258e0a237cb69aaa587b0a4fb528bb0316b1b776 |\ Merge: 727c355 1ca13ed | | Author: Jason Pyeron | | Date: Mon Jun 30 13:22:29 2014 -0400 | | | | Merge of 1ca13ed2271d60ba93d40bcc8db17ced8545f172 branch - rebranding | | | * commit 1ca13ed2271d60ba93d40bcc8db17ced8545f172 | | Author: Stephen R Guglielmo | | Date: Mon Jun 23 09:45:27 2014 -0400 | | | | Minor URL updates | | | * commit d8587c43cfdb12343524ce117a4a59726c438925 | | Author: Stephen R Guglielmo | | Date: Tue Jun 17 12:58:23 2014 -0400 | | | | One final 'foundation' reference. Also fix a string length for the rescue disk. | | | * commit 49ecdfd874029ea287d2755f7e0d5188ce49e81a | | Author: Stephen R Guglielmo | | Date: Tue Jun 17 12:44:36 2014 -0400 $ git log --show-signature --graph * commit 258e0a237cb69aaa587b0a4fb528bb0316b1b776 |\ gpg: Signature made Mon, Jun 30, 2014 13:22:33 EDT using RSA key ID DA0848AD gpg: Good signature from "Jason Pyeron " Merge: 727c355 1ca13ed | | Author: Jason Pyeron | | Date: Mon Jun 30 13:22:29 2014 -0400 | | | | Merge of 1ca13ed2271d60ba93d40bcc8db17ced8545f172 branch - rebranding | | | * commit 1ca13ed2271d60ba93d40bcc8db17ced8545f172 | | gpg: Signature made Mon, Jun 23, 2014 9:45:47 EDT using RSA key ID DD3766FF gpg: Good signature from "Stephen Robert Guglielmo " gpg: aka "Stephen Robert Guglielmo " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0D54 BE6A B832 8701 AA94 9036 2D15 C7B0 DD37 66FF Author: Stephen R Guglielmo | | Date: Mon Jun 23 09:45:27 2014 -0400 | | | | Minor URL updates | | | * commit d8587c43cfdb12343524ce117a4a59726c438925 | | gpg: Signature made Tue, Jun 17, 2014 12:58:30 EDT using RSA key ID DD3766FF gpg: Good signature from "Stephen Robert Guglielmo " gpg: aka "Stephen Robert Guglielmo " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0D54 BE6A B832 8701 AA94 9036 2D15 C7B0 DD37 66FF Author: Stephen R Guglielmo | | Date: Tue Jun 17 12:58:23 2014 -0400 | | | | One final 'foundation' reference. Also fix a string length for the rescue disk. | | | * commit 49ecdfd874029ea287d2755f7e0d5188ce49e81a | | gpg: Signature made Tue, Jun 17, 2014 12:44:43 EDT using RSA key ID DD3766FF gpg: Good signature from "Stephen Robert Guglielmo " gpg: aka "Stephen Robert Guglielmo " gpg: WARNING: This key is not certified with a trusted signature! gpg: There is no indication that the signature belongs to the owner. Primary key fingerprint: 0D54 BE6A B832 8701 AA94 9036 2D15 C7B0 DD37 66FF Author: Stephen R Guglielmo | | Date: Tue Jun 17 12:44:36 2014 -0400 | | | | Should be done! -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Trouble merging renamed but identical files - CONFLICT (rename/rename)
> -Original Message- > From: Phil Hord > Sent: Sunday, June 29, 2014 16:27 > > On Sun, Jun 29, 2014 at 4:20 PM, Jason Pyeron > wrote: > >> -Original Message- > >> From: Phil Hord > >> Sent: Sunday, June 29, 2014 16:09 > >> > >> On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord > >> wrote: > >> > On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron > >> wrote: > >> >> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to > >> >> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually > >> reconciles the merge), > >> >> but it was too long to be readable in the email. > >> > >> Ok, I think I understand the issue you are trying to solve now. > >> > >> Git (rather famously[1]) does not record renames or copies. It is > >> expected instead that renames and copies will be detected > when it is > >> important after the fact. This allows us to ignore rename detection > >> and resolution when creating project history; in the future, better > >> rename/copy detection will "just work" on existing repositories and > >> the repos themselves will not need to be adjusted. > > > > Looking at http://pastebin.com/1R68v6jt , I have a work around. > > > > In summary, 7.git cherry-pick -x HEAD..rebranding , then > > > > git merge $(echo 'Merge of > 1ca13ed2271d60ba93d40bcc8db17ced8545f172 branch - > > rebranding' |\ > > git commit-tree -p HEAD -p rebranding \ > > $(git cat-file -p HEAD | grep ^tree | sed -e > 's/^tree //') ) > > > > Now it is perfect in the blame and log --graph. > > Yes, but your workaround unnecessarily duplicates commits and > complicates the history of your project. You are munging your project But I want to avoid thet complicating, while still showing that line 42 was modified by X. Should this be possible with a merge, without using cherry-pick? > to compensate for git's current shortcomings. Btw I am not able to pull up https://git.wiki.kernel.org/ or http://git.wiki.kernel.org/ -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Trouble merging renamed but identical files - CONFLICT (rename/rename)
> -Original Message- > From: Phil Hord > Sent: Sunday, June 29, 2014 16:09 > > On Sun, Jun 29, 2014 at 11:31 AM, Phil Hord > wrote: > > On Fri, Jun 27, 2014 at 8:42 PM, Jason Pyeron > wrote: > >> Sorry for the http://pastebin.com/1R68v6jt (changes the merge to > >> 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually > reconciles the merge), > >> but it was too long to be readable in the email. > > Ok, I think I understand the issue you are trying to solve now. > > Git (rather famously[1]) does not record renames or copies. It is > expected instead that renames and copies will be detected when it is > important after the fact. This allows us to ignore rename detection > and resolution when creating project history; in the future, better > rename/copy detection will "just work" on existing repositories and > the repos themselves will not need to be adjusted. Looking at http://pastebin.com/1R68v6jt , I have a work around. In summary, 7.git cherry-pick -x HEAD..rebranding , then git merge $(echo 'Merge of 1ca13ed2271d60ba93d40bcc8db17ced8545f172 branch - rebranding' |\ git commit-tree -p HEAD -p rebranding \ $(git cat-file -p HEAD | grep ^tree | sed -e 's/^tree //') ) Now it is perfect in the blame and log --graph. > > What you are encountering now seems to be a shortcoming of Git's > current rename/copy detection. But you are trying to overcome today's > shortcoming by adjusting your project history to accommodate it. > Instead you should just do the merge like you normally would without > regard to how 'git blame' shows the result. > > Maybe there is a bug here still, but it is probably in git-blame. > > [1] > https://git.wiki.kernel.org/index.php/GitFaq#Why_does_Git_not_ > .22track.22_renames.3F > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. smime.p7s Description: S/MIME cryptographic signature
RE: Trouble merging renamed but identical files - CONFLICT (rename/rename)
> -Original Message- > From: Jason Pyeron > Sent: Friday, June 27, 2014 20:42 > To: 'git' > Cc: 'Phil Hord' > Subject: RE: Trouble merging renamed but identical files - > CONFLICT (rename/rename) > > > -Original Message- > > From: Jason Pyeron > > Sent: Friday, June 27, 2014 18:39 > > > > > -Original Message- > > > From: Phil Hord [mailto:phil.h...@gmail.com] > > > Sent: Friday, June 27, 2014 17:46 > > > To: Jason Pyeron > > > Cc: git > > > Subject: Re: Trouble merging renamed but identical files - > > > CONFLICT (rename/rename) > > > > > > On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron > > > wrote: > > > > There are two identical files from the same original > > > parent, but both were > > > > renamed in their own branches. One branch moved the file to > > > a new folder, the > > > > other renamed the file in the same folder. > > > > > > You have not stated what you think the issue is. You have > > only stated > > > the setup. > > > > Thanks, I could have said it better. > > > > I think that git should understand that I have moved a file > > in path only (the tree object containing the file's entry > > change, but not the entry it self) and that the branch from > > which I want to merge back (with common ancestry) has renamed > > the file in the same path ( the tree object is unchanged, but > > the entry is) such that the object is re-parented and renamed > > in that path. > > > > How can this be done in git or if it cannot what are the > > chalenges to patching git for this issue. > > > > git cat-file -p b60070f4d0879e277f44d174a163bbb292325fea # > > tree d8df83fc6714aab1fc1df061fcb03410e1dab1e5 > > git cat-file -p d8df83fc6714aab1fc1df061fcb03410e1dab1e5 # > > 04 tree 68bb8a223284e0f5057421217a5965128bf1d51asrc > > git cat-file -p 68bb8a223284e0f5057421217a5965128bf1d51a # > > 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147 > TrueCrypt.sln > > > > git cat-file -p a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 # > > tree 7f82a6c46f19931c3c40d44dc196cbfab7feaa72 > > git cat-file -p 7f82a6c46f19931c3c40d44dc196cbfab7feaa72 # > > 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147 > CipherShed.sln > > > > > > > > > > > I suppose you want Git to merge without conflict in the > end, though, > > > based on your script. Is that right? > > > > > > > > > > Steps to reproduce the issue: > > > > git init > > > > git fetch https://github.com/pdinc-oss/CipherShed.git > > > > git fetch https://github.com/srguglielmo/CipherShed.git > > > > git checkout -b test b60070f4d0879e277f44d174a163bbb292325fea > > > > git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 > > > > > > > > CONFLICT (rename/rename): Rename > > > "TrueCrypt.sln"->"src/TrueCrypt.sln" in branch > > > > "HEAD" rename "TrueCrypt.sln"->"CipherShed.sln" in > > > > "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68" > > > > > > Git seems to be doing the correct thing here. > > > > > > > > > > git reset --hard b60070f4d0879e277f44d174a163bbb292325fea > > > > git mv src/TrueCrypt.sln src/CipherShed.sln > > > > git commit -m 'renamed to be congruent with a0c84ff' > > > > git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 > > > > > > > > Sill get a CONFLICT (rename/rename): Rename > > > > "TrueCrypt.sln"->"src/CipherShed.sln" in branch "HEAD" rename > > > > "TrueCrypt.sln"->"CipherShed.sln" in > > > "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68" > > > > > > Git seems to be doing the correct thing here, too. > > > > > > > I will have many more to come, any suggestions? > > > > > > Maybe you meant to move the renamed file to the same > folder where it > > > exists in the merge target. I do not get a conflict when > I do that. > > > > Are you saying I should git mv src/TrueCrypt.sln CipherShed.sln ? > > > > Then it will be in the wrong path as intended. > > > > > > > >git reset --hard b60070f4d0879e277f44d174a163bbb292325fea > > >git mv src/TrueCrypt.sln CipherShed.sln > >
RE: Trouble merging renamed but identical files - CONFLICT (rename/rename)
> -Original Message- > From: Jason Pyeron > Sent: Friday, June 27, 2014 18:39 > > > -Original Message- > > From: Phil Hord [mailto:phil.h...@gmail.com] > > Sent: Friday, June 27, 2014 17:46 > > To: Jason Pyeron > > Cc: git > > Subject: Re: Trouble merging renamed but identical files - > > CONFLICT (rename/rename) > > > > On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron > > wrote: > > > There are two identical files from the same original > > parent, but both were > > > renamed in their own branches. One branch moved the file to > > a new folder, the > > > other renamed the file in the same folder. > > > > You have not stated what you think the issue is. You have > only stated > > the setup. > > Thanks, I could have said it better. > > I think that git should understand that I have moved a file > in path only (the tree object containing the file's entry > change, but not the entry it self) and that the branch from > which I want to merge back (with common ancestry) has renamed > the file in the same path ( the tree object is unchanged, but > the entry is) such that the object is re-parented and renamed > in that path. > > How can this be done in git or if it cannot what are the > chalenges to patching git for this issue. > > git cat-file -p b60070f4d0879e277f44d174a163bbb292325fea # > tree d8df83fc6714aab1fc1df061fcb03410e1dab1e5 > git cat-file -p d8df83fc6714aab1fc1df061fcb03410e1dab1e5 # > 04 tree 68bb8a223284e0f5057421217a5965128bf1d51asrc > git cat-file -p 68bb8a223284e0f5057421217a5965128bf1d51a # > 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147TrueCrypt.sln > > git cat-file -p a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 # > tree 7f82a6c46f19931c3c40d44dc196cbfab7feaa72 > git cat-file -p 7f82a6c46f19931c3c40d44dc196cbfab7feaa72 # > 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147CipherShed.sln > > > > > > > I suppose you want Git to merge without conflict in the end, though, > > based on your script. Is that right? > > > > > > > Steps to reproduce the issue: > > > git init > > > git fetch https://github.com/pdinc-oss/CipherShed.git > > > git fetch https://github.com/srguglielmo/CipherShed.git > > > git checkout -b test b60070f4d0879e277f44d174a163bbb292325fea > > > git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 > > > > > > CONFLICT (rename/rename): Rename > > "TrueCrypt.sln"->"src/TrueCrypt.sln" in branch > > > "HEAD" rename "TrueCrypt.sln"->"CipherShed.sln" in > > > "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68" > > > > Git seems to be doing the correct thing here. > > > > > > > git reset --hard b60070f4d0879e277f44d174a163bbb292325fea > > > git mv src/TrueCrypt.sln src/CipherShed.sln > > > git commit -m 'renamed to be congruent with a0c84ff' > > > git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 > > > > > > Sill get a CONFLICT (rename/rename): Rename > > > "TrueCrypt.sln"->"src/CipherShed.sln" in branch "HEAD" rename > > > "TrueCrypt.sln"->"CipherShed.sln" in > > "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68" > > > > Git seems to be doing the correct thing here, too. > > > > > I will have many more to come, any suggestions? > > > > Maybe you meant to move the renamed file to the same folder where it > > exists in the merge target. I do not get a conflict when I do that. > > Are you saying I should git mv src/TrueCrypt.sln CipherShed.sln ? > > Then it will be in the wrong path as intended. > > > > >git reset --hard b60070f4d0879e277f44d174a163bbb292325fea > >git mv src/TrueCrypt.sln CipherShed.sln > >git commit -m 'renamed to be congruent with a0c84ff' > >git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 > > > > No conflict (on that file, anyway). > > Agreed, but not the desired end state. Sorry for the http://pastebin.com/1R68v6jt (changes the merge to 1ca13ed2271d60ba93d40bcc8db17ced8545f172, and manually reconciles the merge), but it was too long to be readable in the email. git blame HEAD -- src/Main/Forms/CipherShed.fbp | cut -c 1-8 | sort -u Gives: ac812aa3 b50a2fb1 git blame b60070f4d0879e277f44d174a163bbb292325fea -- src/Main/Forms/TrueCrypt.fbp | cut -c 1-8 | sort -u Gives: 07b2176f 0eb8b4fa 12c94add a17c95a3 a757b4d4 cac6cd14 d0a9dfa8 d94128a9 e
RE: Trouble merging renamed but identical files - CONFLICT (rename/rename)
> -Original Message- > From: Phil Hord [mailto:phil.h...@gmail.com] > Sent: Friday, June 27, 2014 17:46 > To: Jason Pyeron > Cc: git > Subject: Re: Trouble merging renamed but identical files - > CONFLICT (rename/rename) > > On Fri, Jun 27, 2014 at 4:47 PM, Jason Pyeron > wrote: > > There are two identical files from the same original > parent, but both were > > renamed in their own branches. One branch moved the file to > a new folder, the > > other renamed the file in the same folder. > > You have not stated what you think the issue is. You have only stated > the setup. Thanks, I could have said it better. I think that git should understand that I have moved a file in path only (the tree object containing the file's entry change, but not the entry it self) and that the branch from which I want to merge back (with common ancestry) has renamed the file in the same path ( the tree object is unchanged, but the entry is) such that the object is re-parented and renamed in that path. How can this be done in git or if it cannot what are the chalenges to patching git for this issue. git cat-file -p b60070f4d0879e277f44d174a163bbb292325fea # tree d8df83fc6714aab1fc1df061fcb03410e1dab1e5 git cat-file -p d8df83fc6714aab1fc1df061fcb03410e1dab1e5 # 04 tree 68bb8a223284e0f5057421217a5965128bf1d51asrc git cat-file -p 68bb8a223284e0f5057421217a5965128bf1d51a # 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147TrueCrypt.sln git cat-file -p a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 # tree 7f82a6c46f19931c3c40d44dc196cbfab7feaa72 git cat-file -p 7f82a6c46f19931c3c40d44dc196cbfab7feaa72 # 100644 blob 25c7d3b12bced67046359ba1e7945f82a2640147CipherShed.sln > > > I suppose you want Git to merge without conflict in the end, though, > based on your script. Is that right? > > > > Steps to reproduce the issue: > > git init > > git fetch https://github.com/pdinc-oss/CipherShed.git > > git fetch https://github.com/srguglielmo/CipherShed.git > > git checkout -b test b60070f4d0879e277f44d174a163bbb292325fea > > git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 > > > > CONFLICT (rename/rename): Rename > "TrueCrypt.sln"->"src/TrueCrypt.sln" in branch > > "HEAD" rename "TrueCrypt.sln"->"CipherShed.sln" in > > "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68" > > Git seems to be doing the correct thing here. > > > > git reset --hard b60070f4d0879e277f44d174a163bbb292325fea > > git mv src/TrueCrypt.sln src/CipherShed.sln > > git commit -m 'renamed to be congruent with a0c84ff' > > git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 > > > > Sill get a CONFLICT (rename/rename): Rename > > "TrueCrypt.sln"->"src/CipherShed.sln" in branch "HEAD" rename > > "TrueCrypt.sln"->"CipherShed.sln" in > "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68" > > Git seems to be doing the correct thing here, too. > > > I will have many more to come, any suggestions? > > Maybe you meant to move the renamed file to the same folder where it > exists in the merge target. I do not get a conflict when I do that. Are you saying I should git mv src/TrueCrypt.sln CipherShed.sln ? Then it will be in the wrong path as intended. > >git reset --hard b60070f4d0879e277f44d174a163bbb292325fea > git mv src/TrueCrypt.sln CipherShed.sln >git commit -m 'renamed to be congruent with a0c84ff' >git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 > > No conflict (on that file, anyway). Agreed, but not the desired end state. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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
Trouble merging renamed but identical files - CONFLICT (rename/rename)
There are two identical files from the same original parent, but both were renamed in their own branches. One branch moved the file to a new folder, the other renamed the file in the same folder. Steps to reproduce the issue: git init git fetch https://github.com/pdinc-oss/CipherShed.git git fetch https://github.com/srguglielmo/CipherShed.git git checkout -b test b60070f4d0879e277f44d174a163bbb292325fea git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 CONFLICT (rename/rename): Rename "TrueCrypt.sln"->"src/TrueCrypt.sln" in branch "HEAD" rename "TrueCrypt.sln"->"CipherShed.sln" in "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68" git reset --hard b60070f4d0879e277f44d174a163bbb292325fea git mv src/TrueCrypt.sln src/CipherShed.sln git commit -m 'renamed to be congruent with a0c84ff' git merge a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68 Sill get a CONFLICT (rename/rename): Rename "TrueCrypt.sln"->"src/CipherShed.sln" in branch "HEAD" rename "TrueCrypt.sln"->"CipherShed.sln" in "a0c84ff28f356bcb8b872a9c65a2e9bff97b3f68" I will have many more to come, any suggestions? Repos: https://github.com/srguglielmo/CipherShed/commit/1ca13ed2271d60ba93d40bcc8db17ce d8545f172 https://github.com/pdinc-oss/CipherShed/commit/b60070f4d0879e277f44d174a163bbb29 2325fea -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Tackling Git Limitations with Singular Large Line-seperated Plaintext files
> -Original Message-
> From: Linus Torvalds
> Sent: Friday, June 27, 2014 15:39
>
> On Fri, Jun 27, 2014 at 10:48 AM, Junio C Hamano
> wrote:
> >
> > Even though the original question mentioned "delta discovery", I
> > think what was being asked is not "delta" in the Git sense (which
> > your answer is about) but is "can we diff two long sequences of text
> > (that happens to consist of only 4-letter alphabet but that is a
> > irrelevant detail) without holding both in-core in their entirety?",
> > which is a more relevant question/desire from the application point
> > of view.
>
> .. even there, there's another issue. With enough memory, the diff
> itself should be fairly reasonable to do, but we do not have any sane
> *format* for diffing those kinds of things.
>
> The regular textual diff is line-based, and is not amenable to
> comparing two long lines. You'll just get a diff that says "the two
> really long lines are different".
>
> The binary diff option should work, but it is a horrible output
> format, and not very helpful. It contains all the relevant data ("copy
> this chunk from here to here"), but it's then shown in a binary
> encoding that isn't really all that useful if you want to say "what
> are the differences between these two chromosomes".
>
> I think it might be possible to just specify a special diff algorithm
> (git already supports that, obviously), and just introduce a new "use
> binary diffs with a textual representation" model.
>
> But it also sounds like there might be some actual performance problem
> with these 1GB file delta-calculations. Which I wouldn't be surprised
> about at all.
>
> Jarrad - is there any public data you could give as an example and for
> people to play with?
Until Jarrad replies see sample here:
http://www.genomatix.de/online_help/help/sequence_formats.html
The issue will be, if we talk about changes other than same length substitutions
(e.g. Down's Syndrome where it has an insertion of code) would require one code
per line for the diffs to work nicely.
-Jason
--
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
- -
- Jason Pyeron PD Inc. http://www.pdinc.us -
- Principal Consultant 10 West 24th Street #100-
- +1 (443) 269-1555 x333Baltimore, Maryland 21218 -
- -
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
This message is copyright PD Inc, subject to license 20080407P00.
--
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: Conventions on struct copying?
> -Original Message- > From: Junio C Hamano > Sent: Thursday, June 19, 2014 13:11 > > "brian m. carlson" writes: > > > I don't know of any place we explicitly copy structs like > > this,... > > which should be a reason enough. The first concrete guideline is > "just imitate the existing code". > > > but I don't know of any prohibition against it, either. > > So now you know ;-). To expand, on that do not trust the compiler to do deep copies. http://stackoverflow.com/questions/2302351/assign-one-struct-to-another-in-c Hit #1 on https://www.google.com/search?q=c+assignment+of+struct -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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
Importing history to show up in a blame
The only way I have found so far to do this is to merge the branch on to a tmp branch and then back! The only other way I found seems real bad: http://stackoverflow.com/questions/16473363/tell-git-blame-to-use-imported-histo ry And the way below does not work if there are edits already on master (that is non-identical files). Is there a better way? -Jason jpyeron@black /tmp/foo $ git --version git version 1.8.4.21.g992c386 jpyeron@black /tmp/foo $ git init history Initialized empty Git repository in /tmp/foo/history/.git/ jpyeron@black /tmp/foo $ cd history jpyeron@black /tmp/foo/history $ #make source.txt and commit ... jpyeron@black /tmp/foo/history $ git checkout --orphan HISTORICAL Switched to a new branch 'HISTORICAL' jpyeron@black /tmp/foo/history $ # import each historical version and commit ... jpyeron@black /tmp/foo/history $ git log --oneline --graph && git blame source.txt && sha1sum.exe source.txt * 2889460 v6 - latest * 62e4a90 v5 * bfdf128 v4 * 416d32a v3 * 241a7dc v2 * 7ef41ad v1 ^7ef41ad (Jason Pyeron 2014-06-18 13:47:57 -0400 1) 1 the 241a7dc5 (Jason Pyeron 2014-06-18 13:48:53 -0400 2) 2 quick 62e4a90e (Jason Pyeron 2014-06-18 13:50:44 -0400 3) 3 brown bfdf1285 (Jason Pyeron 2014-06-18 13:49:55 -0400 4) 4 fox 416d32a4 (Jason Pyeron 2014-06-18 13:49:34 -0400 5) 5 jumped 416d32a4 (Jason Pyeron 2014-06-18 13:49:34 -0400 6) 6 over 416d32a4 (Jason Pyeron 2014-06-18 13:49:34 -0400 7) 7 the 416d32a4 (Jason Pyeron 2014-06-18 13:49:34 -0400 8) 8 lazy 28894602 (Jason Pyeron 2014-06-18 13:51:03 -0400 9) 9 dogs cd49f005ab64dac61b2d420a7903fcd02b5f373f *source.txt jpyeron@black /tmp/foo/history $ git checkout master Switched to branch 'master' jpyeron@black /tmp/foo/history $ git log --oneline --graph && git blame source.txt && sha1sum.exe source.txt * f25b132 import of latest source ^f25b132 (Jason Pyeron 2014-06-18 13:45:56 -0400 1) 1 the ^f25b132 (Jason Pyeron 2014-06-18 13:45:56 -0400 2) 2 quick ^f25b132 (Jason Pyeron 2014-06-18 13:45:56 -0400 3) 3 brown ^f25b132 (Jason Pyeron 2014-06-18 13:45:56 -0400 4) 4 fox ^f25b132 (Jason Pyeron 2014-06-18 13:45:56 -0400 5) 5 jumped ^f25b132 (Jason Pyeron 2014-06-18 13:45:56 -0400 6) 6 over ^f25b132 (Jason Pyeron 2014-06-18 13:45:56 -0400 7) 7 the ^f25b132 (Jason Pyeron 2014-06-18 13:45:56 -0400 8) 8 lazy ^f25b132 (Jason Pyeron 2014-06-18 13:45:56 -0400 9) 9 dogs cd49f005ab64dac61b2d420a7903fcd02b5f373f *source.txt jpyeron@black /tmp/foo/history $ git checkout HISTORICAL Switched to branch 'HISTORICAL' jpyeron@black /tmp/foo/history $ git branch historymerge jpyeron@black /tmp/foo/history $ git checkout historymerge Switched to branch 'historymerge' jpyeron@black /tmp/foo/history $ git merge master Merge made by the 'recursive' strategy. jpyeron@black /tmp/foo/history $ git checkout master Switched to branch 'master' jpyeron@black /tmp/foo/history $ git merge historymerge Updating f25b132..5a9408a Fast-forward jpyeron@black /tmp/foo/history $ git branch -d historymerge Deleted branch historymerge (was 5a9408a). jpyeron@black /tmp/foo/history $ git log --oneline --graph && git blame source.txt && sha1sum.exe source.txt * 5a9408a Merge branch 'master' into historymerge |\ | * f25b132 import of latest source * 2889460 v6 - latest * 62e4a90 v5 * bfdf128 v4 * 416d32a v3 * 241a7dc v2 * 7ef41ad v1 ^7ef41ad (Jason Pyeron 2014-06-18 13:47:57 -0400 1) 1 the 241a7dc5 (Jason Pyeron 2014-06-18 13:48:53 -0400 2) 2 quick 62e4a90e (Jason Pyeron 2014-06-18 13:50:44 -0400 3) 3 brown bfdf1285 (Jason Pyeron 2014-06-18 13:49:55 -0400 4) 4 fox 416d32a4 (Jason Pyeron 2014-06-18 13:49:34 -0400 5) 5 jumped 416d32a4 (Jason Pyeron 2014-06-18 13:49:34 -0400 6) 6 over 416d32a4 (Jason Pyeron 2014-06-18 13:49:34 -0400 7) 7 the 416d32a4 (Jason Pyeron 2014-06-18 13:49:34 -0400 8) 8 lazy 28894602 (Jason Pyeron 2014-06-18 13:51:03 -0400 9) 9 dogs cd49f005ab64dac61b2d420a7903fcd02b5f373f *source.txt -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. history.bundle Description: Binary data
RE: Why does gpg.program work for commit but not log?
-- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. > -Original Message- > From: git-ow...@vger.kernel.org > [mailto:git-ow...@vger.kernel.org] On Behalf Of Jeff King > Sent: Wednesday, June 18, 2014 3:37 > To: Jason Pyeron > Cc: git@vger.kernel.org > Subject: Re: Why does gpg.program work for commit but not log? > > On Wed, Jun 18, 2014 at 12:18:35AM -0400, Jason Pyeron wrote: > > > jpyeron@black /projects/microsoft-smartcard-sign/tmp > > $ git --version > > git version 1.7.9 > > That's rather old. In the meantime we have: > > commit 6005dbb9bf21d10b209f7924e305bd04b9ab56d2 > Author: Jacob Sarvis > Date: Wed Mar 27 10:13:39 2013 -0500 > > log: read gpg settings for signed commit verification > > "show --show-signature" and "log --show-signature" > do not read the > gpg.program setting from git config, even though, > commit signing, > tag signing, and tag verification honor it. > > which is in v1.8.3. In general, please double-check your problem > against a recent version of "master" when making a bug report. Ok, so now I will be using locally compiled git. jpyeron@black /projects/microsoft-smartcard-sign/tmp $ /projects/git/local-build/bin/git --version git version 1.8.4.21.g992c386 jpyeron@black /projects/microsoft-smartcard-sign/tmp $ GIT_TRACE=1 /projects/git/local-build/bin/git log --show-signature trace: built-in: git 'log' '--show-signature' trace: run_command: 'less' trace: exec: 'less' trace: run_command: '/projects/microsoft-smartcard-sign/tmp/bin/logginggpg.sh' '--status-fd=1' '--verify' '/tmp/.git_vtag_tmp66WxpM' '-' commit 38afa1f4d0c73fd47d5788310a1a2080aa0abbba -- 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: Why does gpg.program work for commit but not log?
> -Original Message- > From: git-ow...@vger.kernel.org > [mailto:git-ow...@vger.kernel.org] On Behalf Of Jeff King > Sent: Wednesday, June 18, 2014 3:37 > To: Jason Pyeron > Cc: git@vger.kernel.org > Subject: Re: Why does gpg.program work for commit but not log? > > On Wed, Jun 18, 2014 at 12:18:35AM -0400, Jason Pyeron wrote: > > > jpyeron@black /projects/microsoft-smartcard-sign/tmp > > $ git --version > > git version 1.7.9 > > That's rather old. In the meantime we have: > > commit 6005dbb9bf21d10b209f7924e305bd04b9ab56d2 > Author: Jacob Sarvis > Date: Wed Mar 27 10:13:39 2013 -0500 > > log: read gpg settings for signed commit verification > > "show --show-signature" and "log --show-signature" > do not read the > gpg.program setting from git config, even though, > commit signing, > tag signing, and tag verification honor it. > > which is in v1.8.3. In general, please double-check your problem > against a recent version of "master" when making a bug report. > I will (try to) compile master and test. This is the latest version in cygwin. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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
Why does gpg.program work for commit but not log?
jpyeron@black /projects/microsoft-smartcard-sign/tmp $ git --version git version 1.7.9 jpyeron@black /projects/microsoft-smartcard-sign/tmp $ GIT_TRACE=1 git commit -S -m 'bin' trace: built-in: git 'commit' '-S' '-m' 'bin' trace: run_command: '/projects/microsoft-smartcard-sign/tmp/bin/logginggpg.sh' '-bsau' 'Jason Pyeron ' gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/documentation/faqs.html for more information You need a passphrase to unlock the secret key for user: "Jason Pyeron " 2048-bit RSA key, ID 54D0E8E4, created 2014-06-18 [master 38afa1f] bin 1 files changed, 19 insertions(+), 0 deletions(-) create mode 100755 bin/logginggpg.sh jpyeron@black /projects/microsoft-smartcard-sign/tmp $ GIT_TRACE=1 git log --show-signature trace: built-in: git 'log' '--show-signature' trace: run_command: 'less' trace: exec: 'less' trace: run_command: 'gpg' '--verify' '/tmp/.git_vtag_tmpNLFqtm' '-' commit 38afa1f4d0c73fd47d5788310a1a2080aa0abbba gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/documentation/faqs.html for more information gpg: Signature made Wed, Jun 18, 2014 0:11:40 EDT using RSA key ID 54D0E8E4 gpg: Good signature from "Jason Pyeron " Author: Jason Pyeron Date: Wed Jun 18 00:11:40 2014 -0400 bin trace: run_command: 'gpg' '--verify' '/tmp/.git_vtag_tmp41t6O6' '-' commit 174d4544627883c4b03a9b888c2d2c127accefa5 gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/documentation/faqs.html for more information gpg: Signature made Wed, Jun 18, 2014 0:08:39 EDT using RSA key ID 54D0E8E4 gpg: Good signature from "Jason Pyeron " Author: Jason Pyeron Date: Wed Jun 18 00:08:39 2014 -0400 loged signed commit trace: run_command: 'gpg' '--verify' '/tmp/.git_vtag_tmpo6b0D3' '-' commit 4f7ad8a8f38b06d675ac5196c80b1a26ecbee433 gpg: WARNING: using insecure memory! gpg: please see http://www.gnupg.org/documentation/faqs.html for more information gpg: Signature made Tue, Jun 17, 2014 23:18:01 EDT using RSA key ID 54D0E8E4 gpg: Good signature from "Jason Pyeron " Author: Jason Pyeron Date: Tue Jun 17 23:17:55 2014 -0400 test signed commit -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: ISO 13485
> -Original Message- > From: agi > Sent: Tuesday, June 17, 2014 10:58 > > Hi Jason, > > Thanks for the speedy reply. We are in the process of trying > to make our > software product ISO13485 compatible and we are assessing all systems > that we use. > Do you have a validation document for git that could provide > information > on how to use it in order to comply with ISO legislations? That would be customized to your QA process. A generalized document would be too vague. I am sure any process consultant could draft that up for you. (disclaimer: I have been paid to do things like this before) Maybe you could start by searching with things like https://www.google.com/search?q=using+QA+with+Git or contacting Atlassian about their QA product suite integration with Git. Maybe you could find a process consultant to do it cheaper if you release it out to the FOSS community? The "nice" (read as less effort) thing about ISO 13485 is it does not have a continual improvement requirement so as long as "defects" are detected and remediated you are good. Please note git does not detect defects, git does not remediate defects. What git does is ensure the approved artifact is unchanged in any attribute to maintain the exact level of quality from first inspection of that artifact for an unlimited amount of iterations. Git has built in "digital signatures" on the artifacts stored in its repository. > Any additional information or material you can think of is more than > welcome. > > Thanks in advance for your help! > > > Best Regards, > Agnes Pasztor > > Senior Test Engineer > Omixon Biocomputing Ltd. > > > On 06/16/2014 05:20 PM, Jason Pyeron wrote: > >> -Original Message- > >> From: agi > >> Sent: Monday, June 16, 2014 11:14 > >> > >> Hello, > >> > >> I would like to ask a question about GIT v. 1.7 > >> > >> Is it compatible with ISO 13485 (quality management system)? > >> Can it be > >> used for developing a medical diagnostic software? > > Yes. > > > > Now, do you have a specific question about how to use Git > in your QA process? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: ISO 13485
> -Original Message- > From: agi > Sent: Monday, June 16, 2014 11:14 > > Hello, > > I would like to ask a question about GIT v. 1.7 > > Is it compatible with ISO 13485 (quality management system)? > Can it be > used for developing a medical diagnostic software? Yes. Now, do you have a specific question about how to use Git in your QA process? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: [OT] List CC etiquette and my brain just do not seem to work
> -Original Message- > From: brian m. carlson [mailto:sand...@crustytoothpaste.net] > Sent: Sunday, June 15, 2014 12:45 > To: git@vger.kernel.org; Jason Pyeron > Subject: Re: [OT] List CC etiquette and my brain just do not > seem to work > > On Sun, Jun 15, 2014 at 10:27:21AM -0400, Jason Pyeron wrote: > > > > Why can the list set the reply to the list and if there is a sender > > whos email is not on the list add them to the reply to > header as well. > > https://www.google.com/search?q=reply+to+considered+harmful Nice! "Coddling the Brain-Dead, Penalizing the Conscientious" from the first result http://www.unicom.com/pw/reply-to-harmful.html That describes me to a tee, although I strongly disagree with their premise of "It Adds Nothing", it subtracts one message from my inbox. Btw, nice email address it is what I needed today. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Is there a reason the credential cache server cowardly refuses to delete/reuse the socket file?
> -Original Message- > From: Jeff King > Sent: Sunday, June 15, 2014 10:08 > > On Sun, Jun 15, 2014 at 09:48:24AM -0400, Jason Pyeron wrote: > > > Whenever my computer crashes, I am left with a socket file. > On next git > > invocation it tries to conenct to the file, but the daemon > is not running so it > > barfs until I delete the file. > > It's supposed to transparently handle this situation. The > server always > runs unlink() before binding to clear it out. The client will > spawn the > server when it tries to connect and gets either ENOENT or > ECONNREFUSED. > > But: > > > jpyeron@black /projects/dcarr/saar > > $ git push > > fatal: unable to connect to cache daemon: No error > > Apparently your errno is 0 after returning an error from > credential-cache.c:send_request? > > Could this be a cygwin weirdness? I'd be interested to see the output > of: > > echo url=https://example.com | > strace -f git credential-cache get On cygwin things can git a bit weird, I changed it to the actual executable. I marked the start of interest with lots of *** jpyeron@black /projects/dcarr $ echo url=https://example.com | strace -f /usr/lib/git-core/git-credential-cache get 3 3 [main] git-credential-cache (4308) ** 111 114 [main] git-credential-cache (4308) Program name: C:\cygwin\lib\git-core\git-credential-cache.exe (windows pid 4308) 53 167 [main] git-credential-cache (4308) OS version: Windows NT-5.2 50 217 [main] git-credential-cache (4308) ** 138 355 [main] git-credential-cache (4308) sigprocmask: 0 = sigprocmask (0, 0x0, 0x61276808) 364 719 [main] git-credential-cache 4308 open_shared: name shared.5, n 5, shared 0x60FF (wanted 0x60FF), h 0x368, *m 6 68 787 [main] git-credential-cache 4308 user_heap_info::init: heap base 0x8000, heap top 0x8000, heap size 0x1800 (402653184) 73 860 [main] git-credential-cache 4308 open_shared: name $$SID$$.1, n 1, shared 0x60FE (wanted 0x60FE), h 0x36C, *m 6 53 913 [main] git-credential-cache 4308 user_info::create: opening user shared for '$$SID$$' at 0x60FE 64 977 [main] git-credential-cache 4308 user_info::create: user shared version AB1FCCE8 611038 [main] git-credential-cache 4308 wow64_eval_expected_main_stack: expected allocbase: 0x3, stackbase: 0x23 681106 [main] git-credential-cache 4308 fhandler_pipe::create: name \\.\pipe\cygwin-c5e39b7a9d22bafb-4308-sigwait, size 164, mode PIPE_TYPE_MESSAGE 1101216 [main] git-credential-cache 4308 fhandler_pipe::create: pipe read handle 0x354 511267 [main] git-credential-cache 4308 fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-c5e39b7a9d22bafb-4308-sigwait 911358 [main] git-credential-cache 4308 fhandler_pipe::create: pipe write handle 0x350 621420 [main] git-credential-cache 4308 dll_crt0_0: finished dll_crt0_0 initialization 7082128 [main] git-credential-cache 4308 mount_info::conv_to_posix_path: conv_to_posix_path (C:\home\public\Desktop\projects\dcarr, no-keep-rel, no-add-slash) 692197 [main] git-credential-cache 4308 normalize_win32_path: C:\home\public\Desktop\projects\dcarr = normalize_win32_path (C:\home\public\Desktop\projects\dcarr) 452242 [main] git-credential-cache 4308 mount_info::conv_to_posix_path: /cygdrive/c/home/public/Desktop/projects/dcarr = conv_to_posix_path (C:\home\public\Desktop\projects\dcarr) -1042138 [sig] git-credential-cache 4308 wait_sig: entering ReadFile loop, my_readsig 0x354, my_sendsig 0x350 2672405 [main] git-credential-cache 4308 sigprocmask: 0 = sigprocmask (0, 0x0, 0x800180A8) 2372642 [main] git-credential-cache 4308 _cygwin_istext_for_stdio: fd 0: not open 602702 [main] git-credential-cache 4308 _cygwin_istext_for_stdio: fd 1: not open 372739 [main] git-credential-cache 4308 _cygwin_istext_for_stdio: fd 2: not open 1472886 [main] git-credential-cache (4308) open_shared: name cygpid.4308, n 4308, shared 0x60FD (wanted 0x60FD), h 0x330, *m 2 302916 [main] ? (4308) time: 1402843072 = time(0x0) 422958 [main] git-credential-cache 4308 pinfo::thisproc: myself dwProcessId 4308 6453603 [main] git-credential-cache 4308 environ_init: GetEnvironmentStrings returned 0x494040 503653 [main] git-credential-cache 4308 environ_init: 0x80028290: !::=::\ 543707 [main] git-credential-cache 4308 environ_init: 0x800282A0: !A:=A:\ 783785 [main] git-credential-cache 4308 environ_init: 0x800282B0: !B:=B:\ 833868 [main] git-credential-cache 4308 environ_init: 0x800282C0: !D:=D:\ 723940 [main] git-credential-cache 4308 environ_init: 0x800282D0: !E:=E:\ 563996 [main] git-crede
[OT] List CC etiquette and my brain just do not seem to work
Why can the list set the reply to the list and if there is a sender whos email is not on the list add them to the reply to header as well. I forget too many times to fix the address lines, and I get beaten with a stick at work when I use the reply all. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Is there a reason the credential cache server cowardly refuses to delete/reuse the socket file?
> -Original Message- > From: Jeff King > Sent: Sunday, June 15, 2014 10:08 > > On Sun, Jun 15, 2014 at 09:48:24AM -0400, Jason Pyeron wrote: > > > Whenever my computer crashes, I am left with a socket file. > On next git > > invocation it tries to conenct to the file, but the daemon > is not running so it > > barfs until I delete the file. > > It's supposed to transparently handle this situation. The > server always > runs unlink() before binding to clear it out. The client will > spawn the > server when it tries to connect and gets either ENOENT or > ECONNREFUSED. > > But: > > > jpyeron@black /projects/dcarr/saar > > $ git push > > fatal: unable to connect to cache daemon: No error > > Apparently your errno is 0 after returning an error from > credential-cache.c:send_request? > > Could this be a cygwin weirdness? I'd be interested to see the output > of: > > echo url=https://example.com | > strace -f git credential-cache get It paused at: 24 797029 [main] git 5112 fhandler_base::close: closing '/cygdrive/c/home/public/Desktop/projects/dcarr/saar/.git/config' handle 0x2D4 70 797099 [main] git 5112 close: 0 = close(3) 899 797998 [main] git 5112 fhandler_pipe::create: name \\.\pipe\cygwin-c5e39b7a9d22bafb-5112-pipe-0x1, size 65536, mode PIPE_TYPE_MESSAGE 316 798314 [main] git 5112 fhandler_pipe::create: pipe read handle 0x2C4 27 798341 [main] git 5112 fhandler_pipe::create: CreateFile: name \\.\pipe\cygwin-c5e39b7a9d22bafb-5112-pipe-0x1 63 798404 [main] git 5112 fhandler_pipe::create: pipe write handle 0x2C0 35 798439 [main] git 5112 build_fh_pc: fh 0x612ADE68, dev 00C6 25 798464 [main] git 5112 build_fh_pc: fh 0x612B9B4C, dev 00C5 24 798488 [main] git 5112 fhandler_base::set_flags: flags 0x1, supplied_bin 0x0 23 798511 [main] git 5112 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x1 22 798533 [main] git 5112 fhandler_base::set_flags: filemode set to binary 22 798555 [main] git 5112 fhandler_base::init: created new fhandler_base for handle 0x2C4, bin 1 26 798581 [main] git 5112 fhandler_base::set_flags: flags 0x10001, supplied_bin 0x0 26 798607 [main] git 5112 fhandler_base::set_flags: O_TEXT/O_BINARY set in flags 0x1 22 798629 [main] git 5112 fhandler_base::set_flags: filemode set to binary 23 798652 [main] git 5112 fhandler_base::init: created new fhandler_base for handle 0x2C0, bin 1 23 798675 [main] git 5112 fhandler_pipe::create: 0 = pipe([0x612ADE68, 0x612B9B4C], 65536, 0x1) 26 798701 [main] git 5112 pipe: 0 = pipe([3, 4]) 28 798729 [main] git 5112 child_info::child_info: subproc_ready 0x2B4 25 798754 [main] git 5112 fork: entering 181 798935 [main] git 5112 sig_send: sendsig 0x350, pid 5112, signal -40, its_me 1 24 798959 [main] git 5112 sig_send: wakeup 0x2AC 27 798986 [main] git 5112 sig_send: Waiting for pack.wakeup 0x2AC 6 798992 [sig] git 5112 wait_sig: signalling pack.wakeup 0x2AC 280 799272 [main] git 5112 sig_send: returning 0x0 from sending signal -40 39 799311 [main] git 5112 frok::parent: priority class 32 86 799397 [main] git 5112 frok::parent: stack - bottom 0x23, top 0x207000, addr 0x3, guardsize 0x0 25 799422 [main] git 5112 frok::parent: CreateProcessW (C:\cygwin\bin\git.exe, C:\cygwin\bin\git.exe, 0, 0, 1, 0x420, 0, 0, 0x22A8FC, 0x22A8D0) 2529 801951 [main] git 5112 frok::parent: forked pid 5796 213 802164 [main] git 5112 child_info::sync: n 2, waiting for subproc_ready(0x2B4) and child process(0x290) Should I have changed example.com to something else and should I have run it inside or outside of a git project directory? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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
Is there a reason the credential cache server cowardly refuses to delete/reuse the socket file?
Whenever my computer crashes, I am left with a socket file. On next git invocation it tries to conenct to the file, but the daemon is not running so it barfs until I delete the file. jpyeron@black /projects/dcarr/saar $ git push fatal: unable to connect to cache daemon: No error Username for xx ^C jpyeron@black /projects/dcarr/saar $ ls -al ~/.git-credential-cache/ total 1 drwx--+ 1 jpyeron Domain Users 0 Jun 9 14:09 . drwxr-xr-x+ 1 jpyeron root 0 Jun 8 22:45 .. srwxr-xr-x 1 jpyeron Domain Users 0 Jun 9 14:09 socket jpyeron@black /projects/dcarr/saar $ rm -f ~/.git-credential-cache/socket jpyeron@black /projects/dcarr/saar $ git push Username for xx Password for xxx Counting objects: 27, done. Delta compression using up to 2 threads. Compressing objects: 100% (9/9), done. Writing objects: 100% (14/14), 2.09 KiB, done. Total 14 (delta 6), reused 0 (delta 0) To x 345112c..48909da master -> master jpyeron@black /projects/dcarr/saar $ git --version git version 1.7.9 jpyeron@black /projects/dcarr/saar $ cygcheck.exe -V cygcheck (cygwin) 1.7.30 ... -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: GIT and large files
> -Original Message- > From: Stewart, Louis (IS) > Sent: Tuesday, May 20, 2014 11:38 > > Can GIT handle versioning of large 20+ GB files in a directory? Are you asking 20 files of a GB each or files 20GB each? A what and why may help with the underlying questions. v/r, Jason Pyeron -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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
Clear an invalid password out of the credential-cache?
Is it me or is the only way to clear a single invalid password out of the credential-cache is by "git credential-cache exit"? -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Re-Transmission of blobs?
> -Original Message- > From: Josef Wolf > Sent: Friday, September 13, 2013 6:23 > > On Thu, Sep 12, 2013 at 08:06:35PM +, Pyeron, Jason J CTR > (US) wrote: > > > Yes, but it is those awfully slow connections (slower that > the looping > > issue) which happen to always drop while cloning from our > office. And > > the round trip should be mitigated by http-keep-alives. > [ ... ] > > But, again if the connection drops, we have already lost the delta > > advantage. I would think the scenario would go like this: > > > > git clone url://blah/blah > > [fail] > > cd blah > > git clone --resume #uses normal methods I am using the mythical --resume, where it would fetch packs and indexes. > > [fail] > > while ! git clone --resume --HitItWithAStick > > > > replace clone with fetch for that use case too > > Last time I checked, cloning could not be resumed: > > http://git.661346.n2.nabble.com/git-clone-and-unreliable-links-td7570652.html > > If you're on a slow/unreliable link, you've lost. That is kind of the point. It should be possible. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: http.postBuffer set at the server side?
> -Original Message- > From: Jeff King > Sent: Wednesday, August 28, 2013 23:52 > To: Pyeron, Jason J CTR (US) > Cc: git@vger.kernel.org > Subject: Re: http.postBuffer set at the server side? > > On Wed, Aug 28, 2013 at 11:08:02PM +, Pyeron, Jason J CTR > (US) wrote: > > > We have systems hosting git which are behind proxies, and > unless the > > client sets the http.postBuffer to a large size they connections > > fails. > > > > Is there a way to set this on the server side? If not would > a patch be > > possible to fix this? > > What would it mean to set it on the server? It is the size > at which the client decides to use a "chunked" To tell the client... > transfer-encoding rather than buffering the whole output to > send at once. So you'd want to figure out why the server is > upset about the chunked encoding. > Unchangable settings in a specific case here. > > jason.pyeron@hostname /home/jason.pyeron/desktop/projectname > > $ git push remote --all > > Username for 'https://server.fqdn': > > Password for 'https://jpye...@server.fqdn': > > Counting objects: 1820, done. > > Delta compression using up to 4 threads. > > Compressing objects: 100% (1276/1276), done. > > error: RPC failed; result=22, HTTP code = 411 > > fatal: The remote end hung up unexpectedly Writing objects: 100% > > (1820/1820), 17.72 MiB | 5.50 MiB/s, done. > > Total 1820 (delta 527), reused 26 (delta 6) > > fatal: The remote end hung up unexpectedly > > The server (or the proxy) returns 411, complaining that it > didn't get a Content-Length header. That's because the git > http client doesn't know how big the content is ahead of time > (and that's kind of the point of chunked encoding; the > content is streamed). > > > jason.pyeron@hostname /home/jason.pyeron/desktop/projectname > > $ git config http.postBuffer 524288000 > > > > jason.pyeron@hostname /home/jason.pyeron/desktop/projectname > > $ git push remote --all > > Username for 'https://server.fqdn': > > Password for 'https://jpye...@server.fqdn': > > Counting objects: 1820, done. > > Delta compression using up to 4 threads. > > Compressing objects: 100% (1276/1276), done. > > Writing objects: 100% (1820/1820), 17.72 MiB | 11.31 MiB/s, done. > > Total 1820 (delta 519), reused 26 (delta 6) To > > https://server.fqdn/git/netasset-portal/ > > * [new branch] master -> master > > And here you've bumped the buffer to 500MB, so git will > potentially buffer that much in memory before sending > anything. Which works for your 17MB packfile, as we buffer > the whole thing and then send the exact size ahead of time, > appeasing the proxy. > > But there are two problems I see with just bumping the > postBuffer value: > > 1. You've just postponed the problem. The first 501MB push will fail > again. You can bump it higher, but you may eventually hit a point > where your buffer is too big to fit in RAM. > Agreed. By then I hope to get our infrastructure team to address the proxies. Liking the spool idea below. The other idea would be restrict the size of any one transfer. (would that work if a given commit is large than the threshold???) > 2. You've lost the pipelining. With a small postBuffer, we are > streaming content up to the server as pack-objects generates it. > But with a large buffer, we generate all of the content, > then start > sending the first byte (notice how the progress meter, which is > generated by pack-objects, shows twice as fast in the > second case. > It is not measuring the network at all, but is streaming into > git-remote-https's buffer). > > If the server really insists on a content-length header, then > we can't ever fix (2). But we could fix (1) by spooling the > packfile to disk and then sending from there (under the > assumption that you have way more temporary disk space than RAM). > Hmmm. So if the server says, hey I have a borked infrastructure, please send me a content length git could spool then. > However, if you have control of the proxies, the best thing > would be to tweak its config to stop complaining about a lack > of content-length header (at least in cases where you're > getting a "chunked" > content-transfer-encoding). That would solve both issues (and > without clients having to change anything). > One of the many is under my control, I will get that one addressed but the others there is no hope. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
RE: [cygwin] Re: Lack of case-sensitive filename handling with git 1.7.9-1 for Cygwin 64-bit
I just saw this on the cygwin list. > -Original Message- > From: Corinna Vinschen > Sent: Friday, August 16, 2013 4:18 > To: cyg...@cygwin.com > Subject: [cygwin] Re: Lack of case-sensitive filename > handling with git 1.7.9-1 for Cygwin 64-bit > > On Aug 16 10:32, Kal Sze wrote: > > I have been using Cygwin 32-bit on Windows 7 Profession > 64-bit. I had > > the HKLM\SYSTEM\CurrentControlSet\Control\Session > > Manager\kernel\ObCaseInsensitive registry key set to DWORD > 0x > > and case-sensitive filename handling has been fully working > in Cygwin > > 32-bit (as far as I can tell from my usage anyway). > > > > Now that Cygwin 64-bit has been released, I want to try it. > I notice > > that git in Cygwin 64-bit does not seem to correctly handle > filesname > > that differ only by case. > > > > To reproduce, create a repository in Cygwin 32-bit *with the > > aforementioned registry key set*: > > > > $ git init case_sensitivity_test; cd case_sensitivity_test > > > > Create two files of different content with similar filenames that > > differ only by case: > > > > $ echo 'FOO' > FOO.TXT; echo 'foo' > foo.txt > > > > Commit them into the repository: > > > > $ git add .; git commit -m 'Initial commit' > > [master (root-commit) 16d1b59] Initial commit > > 2 files changed, 2 insertions(+), 0 deletions(-) > > create mode 100644 FOO.TXT > > create mode 100644 foo.txt > > > > In Cygwin 32-bit, this looks all green: > > > > $ git status > > # On branch master > > nothing to commit (working directory clean) > > $ ls > > FOO.TXT foo.txt > > > > Now, fire up the Cygwin64 terminal and browse to the > repository, then: > > > > $ ls > > FOO.TXT foo.txt > > $ cat FOO.TXT > > FOO > > $ cat foo.txt > > foo > > > > So `ls` and `cat` both recognize the two different files. However: > > > > $ git status > > # On branch 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: foo.txt > > # > > no changes added to commit (use "git add" and/or "git > commit -a") > > > > "Oops." > > The interesting thing here is, if you try this the other way > around, you'll see the exact same effect. If you created the > above git repo with 64 bit git, everything works exactly as > in the 32 bit version and the two files are correctly recognized. > > I assume the format of the git database files depends on the > architecture. Therefore it's probably not advisable to use a > git repo created under 32 bit git with a 64 bit git and vice versa. Is this the best explanation for this? > > > Corinna > > -- > Corinna Vinschen Please, send mails > regarding Cygwin to > Cygwin Maintainer cygwin AT cygwin DOT com > Red Hat > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Collective wisdom about repos on NFS accessed by concurrent clients (== corruption!?)
> -Original Message- > From: Thomas Rast > Sent: Saturday, April 06, 2013 4:12 > > Kenneth Ölwing writes: > > > On 2013-04-05 15:42, Thomas Rast wrote: > >> Can you run the same tests under strace or similar, and gather the > >> relevant outputs? Otherwise it's probably very hard to say what is > >> going wrong. In particular we've had some reports on lustre that > >> boiled down to "impossible" returns from libc functions, not git > >> issues. It's hard to say without some evidence. > > Thomas, thanks for your reply. > > > > I'm assuming I should strace the git commands as they're > issued? I'm > > already collecting regular stdout/err output in a log as I go. Is > > there any debugging things I can turn on to make the calls issue > > internal tracing of some sort? > > I don't think there's any internal debugging that helps at this point. > Usually errors pointing to corruption are caused by a chain > of syscalls failing in some way, and the final error shows > only the last one, so > strace() output is very interesting. > > > The main issue I see is that I suspect it will generate so > much data > > that it'll overflow my disk ;-). > > Well, assuming you have some automated way of detecting when > it fails, you can just overwrite the same strace output file > repeatedly; we're only interested in the last one (or all the > last ones if several gits fail concurrently). We use tmpwatch for this type of issue, especially with oracle traces. Set up a directory and tell tmpwatch to delete files older than X. This will keep the files at bay and when you detect a problem stop the clean up script. > > Fiddling with strace will unfortunately change the timings > somewhat (causing a bunch of extra context switches per > syscall), but I hope that you can still get it to reproduce. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Version 1.8.1 does not compile on Cygwin 1.7.14
> -Original Message- > From: Mark Levedahl > Sent: Sunday, January 06, 2013 17:17 > > On 01/06/2013 02:54 PM, Junio C Hamano wrote: > > Jonathan Nieder writes: > > > >> Mark Levedahl wrote: > >> > >>> > However, > >>> the newer win32api is provided only for the current > cygwin release > >>> series, which can be reliably identified by having dll version > >>> 1.7.x, while the older frozen releases (dll versions 1.6.x from > >>> redhat, 1.5.x open source) still have the older api as no > updates are being made for the legacy version(s). > >> Ah. That makes sense, thanks. > >> > >> (For the future, if we wanted to diagnose an out-of-date > win32api and > >> print a helpful message, I guess cygcheck would be the command to > >> use.) > > Hmph, so we might see somebody who cares about Cygwin to > come up with > > a solution based on cygcheck (not on uname) to update this part, > > perhaps on top of Peff's "split default settings based on > uname into > > separate file" patch? > > > > If I understood what Mark and Torsten wrote correctly, you > will have > > the new win32api if you install 1.7.17 (or newer) from > scratch, but if > > you are on older 1.7.x then you can update the win32api part as a > > package update (as opposed to the whole-system upgrade). A > test based > > on "uname -r" cannot notice that an older 1.7.x (say 1.7.14) > > installation has a newer win32api because the user updated > it from the > > package (hence the user should not define CYGWIN_V15_WIN32API). > > > > Am I on the same page as you guys, or am I still behind? > > > > In the meantime, perhaps we would need something like this? > > It's perhaps worth noting how we got into this mess. The > problems have their root in > > adbc0b6b6e57c11ca49779d01f549260a920a97d > > Cygwin's entire goal is a completely POSIX compliant > environment running under Windows. The above commit > circumvents some of Cygwin's API regarding stat/fstat to make > things perhaps a bit faster, and definitely not POSIX Ug! > compliant (The commit message is wrong, the commit definitely > breaks POSIX compliance). That code is also what will not > compile on different w32api versions. It is curious: the > Cygwin mailing list has been absolutely silent since the > w32api change was introduced last summer, this is the only > piece of code I am aware of that was broken by the new > headers, and of course the purpose of this code is to Um, going out on a limb here, but those headers are used internally as "cygwin" apps are most likely to now know about those headers. > circumvent the Cygwin API (and by extension, Cygwin project goals). > > So, perhaps a better path forward is to disable / remove the > above code by default. (Those wanting a native Win32 git > should just use the native > Win32 git). Or a make option... -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Nike Air Max Shop
Is there a practical way to eliminate the spam here? Could vger.kernel.org use a postini (list maintainers contact me offline about this) account? -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Version 1.8.1 does not compile on Cygwin 1.7.14
> -Original Message- > From: Junio C Hamano > Sent: Sunday, January 06, 2013 16:36 > > Thanks; so perhaps you can give me an OK to forge your S-o-b > to the following? I am personally fine with it, because cygwin is used by developers not production systems and I expect my developers to upgrade their environment for security fixes, etc. If I ever had a situation where I am using git, in production, on cygwin, where I could not upgrade I would effort to make a compile test based patch to the make file to accommodate the issue. > > -- >8 -- > From: Mark Levedahl > Date: Sun, 6 Jan 2013 11:56:33 -0800 > Subject: [PATCH] Makefile: add comment on CYGWIN_V15_WIN32API > > There is no documented, reliable, and future-proof method to > determine the installed w32api version on Cygwin. There are > many things that can be done that will work frequently, > except when they won't. > > The only sane thing is to follow the guidance of the Cygwin > developers: the only supported configuration is that which > the current setup.exe produces, and in the case of problems, > if the installation is not up to date then updating is the > first required action. > > Signed-off-by: Mark Levedahl > --- > Makefile | 4 > 1 file changed, 4 insertions(+) > > diff --git a/Makefile b/Makefile > index 4d47af5..52e298a 100644 > --- a/Makefile > +++ b/Makefile > @@ -273,6 +273,10 @@ all:: > # > # Define NO_REGEX if you have no or inferior regex support > in your C library. > # > +# Define CYGWIN_V15_WIN32API if you are using Cygwin v1.7.x > but are not > +# using the current w32api packages. The recommended > approach, however, > +# is to update your installation if compilation errors occur. > +# > # Define HAVE_DEV_TTY if your system can open /dev/tty to > interact with the # user. > # > -- > 1.8.1.302.g0f4eaa7 -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Version 1.8.1 does not compile on Cygwin 1.7.14
> -Original Message- > From: git-ow...@vger.kernel.org > [mailto:git-ow...@vger.kernel.org] On Behalf Of Mark Levedahl > Sent: Sunday, January 06, 2013 16:10 > To: Junio C Hamano > Cc: Jonathan Nieder; Torsten Bögershausen; Stephen & Linda > Smith; Jason Pyeron; git@vger.kernel.org; Eric Blake > Subject: Re: Version 1.8.1 does not compile on Cygwin 1.7.14 > > On 01/06/2013 02:54 PM, Junio C Hamano wrote: > > Jonathan Nieder writes: > > > >> Mark Levedahl wrote: > >> > >>> > However, > >>> the newer win32api is provided only for the current > cygwin release > >>> series, which can be reliably identified by having dll version > >>> 1.7.x, while the older frozen releases (dll versions 1.6.x from > >>> redhat, 1.5.x open source) still have the older api as no > updates are being made for the legacy version(s). > >> Ah. That makes sense, thanks. > >> > >> (For the future, if we wanted to diagnose an out-of-date > win32api and > >> print a helpful message, I guess cygcheck would be the command to > >> use.) > > Hmph, so we might see somebody who cares about Cygwin to > come up with > > a solution based on cygcheck (not on uname) to update this part, > > perhaps on top of Peff's "split default settings based on > uname into > > separate file" patch? > > > > If I understood what Mark and Torsten wrote correctly, you > will have > > the new win32api if you install 1.7.17 (or newer) from > scratch, but if > > you are on older 1.7.x then you can update the win32api part as a > > package update (as opposed to the whole-system upgrade). A > test based > > on "uname -r" cannot notice that an older 1.7.x (say 1.7.14) > > installation has a newer win32api because the user updated > it from the > > package (hence the user should not define CYGWIN_V15_WIN32API). > > > > Am I on the same page as you guys, or am I still behind? > > > > In the meantime, perhaps we would need something like this? > > > > > > diff --git a/Makefile b/Makefile > > index 8e225ca..b45b06d 100644 > > --- a/Makefile > > +++ b/Makefile > > @@ -281,6 +281,9 @@ all:: > > # > > # Define NO_REGEX if you have no or inferior regex > support in your C library. > > # > > +# Define CYGWIN_V15_WIN32API if your Cygwin uses win32api > dll older > > +than # 1.7.x (this typically is true on Cygwin older than 1.7.17) # > > # Define HAVE_DEV_TTY if your system can open /dev/tty to > interact with the > > # user. > > # > > > Looking at a current setup.ini, the obsolete win32 api is a > single package "w32api" with last version 3.17-2, and is now > replaced by the new win32 api is in two packages, > "w32api-headers" + "w32api-runtime", both at version > 3.0b_svn5496-1. If setup.exe updated an older installation of > w32api, the old package is not deleted, but replaced by a > special "empty" package with (as of today) version -1. > Note that all of this could change at any time. Also, note > that the new w32api packages have version numbers that are > lower than the older obsoleted version. I would not rely on that information as it is not designed to convey the information the git build needs. > > Running "cygcheck -c w32api w32api-headers w32api-runtime" on > one machine gives > > Cygwin Package Information > Package VersionStatus > w32api -1 OK > w32api-headers 3.0b_svn5496-1 OK > w32api-runtime 3.0b_svn5496-1 OK > > So now, what do folks propose checking for? > a) w32api is installed? Nope - the package is not "removed", > it was updated to a special empty version to delete its > former contents, but a new fresh installation won't have this. > b) w32api-headers is installed? Nope - what happens on the > next repackaging? > c) w32api version is -1? Maybe, but that number could change. > etc. This is what is typically done in a configure script by test compiling. > > There is no documented, reliable, future-proof, method of > determining the installed w32api version on Cygwin. There are > many things that can be done that will work frequently, > except when they won't. I really think the only sane thing is > to follow the guidance of the Cygwin > developers: the only supported configuration is that which > the current setup.exe produces, and in
RE: Version 1.8.1 does not compile on Cygwin 1.7.14
> -Original Message- > From: Stephen & Linda Smith > Sent: Sunday, January 06, 2013 1:21 > > > Was it the commit before > > 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was it > > 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I > am doing a > > cygwin update presently to look at it. > > Since the email earlier today, I had blown away the > directory. I just now > did the following > > git clone https://github.com/git/git.git git-src && cd > git-src && make all > ... The make errored out as before > No error for me. > git co 9fca6c && make all > ... The make errored out as before No error for me. > > git co 9fca6c^ && make all > ... and this compiles to completion > > CYGWIN_NT-5.1 WINXPMACHINE 1.7.14(0.260/5/3) 2012-04-24 17:22 > i686 Cygwin This is old, do you have the luxury of updating it? > > What else can I do to test this out (I will get a current > cygwin tomorrow to use in a test). I would also check to see if your devel packages are up to date too. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Trying to understand the web dav details
Ignore everything below, it was a case sensitive typo. It always worked it. > -Original Message- > From: Jeff King > Sent: Sunday, January 06, 2013 0:38 > > On Sun, Jan 06, 2013 at 04:49:57AM +, Pyeron, Jason J CTR > (US) wrote: > > > > > How does the ?service= get translated in to the action > > > > performed on the web server? > > > > > > If you are using the git-http-backend CGI, it will interpret the > > > service > > > > No, using plain jane http and webdav. This server is not > "allowed" to > > use cgi processes. > > Then the service parameter should be ignored by your > webserver, and it should just serve the info/refs file from > the repository on the filesystem. And you are stuck using > WebDAV for push. > > > > GET /git/project-x/info/refs HTTP/1.1 > > [...] > > * The requested URL returned error: 404 Not Found > > Does the info/refs file exist in the project-x repository? Yes. > > > fatal: https://server/git/project-x/info/refs not found: > did you run git update-server-info on the server? > > Did you? > Many times. > If you can't run any git programs on the server at all (and > it sounds like that may be the case), you'll need to run it > locally before putting the repository data on the server. > > Once you have WebDAV set up for pushing, it will update the > info/refs file for each push. But if you are initially > seeding the server with rsync or a tarfile, you'll want to Seeding it seems to work, it is the bare init that seems to be failing. Might be on to something there. > make sure it has an up-to-date info/refs file. Here is the create script: #!/bin/bash if [ $# != 1 ]; then exit 1; fi if [ -e "$1" ]; then exit 2; fi mkdir "$1" cd "$1" git init --bare cp hooks/post-update.sample hooks/post-update chmod +x hooks/post-update git update-server-info -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Version 1.8.1 does not compile on Cygwin 1.7.14
> -Original Message- > From: Jason Pyeron > Sent: Saturday, January 05, 2013 22:38 > > > > Stephen & Linda Smith > > Sent: Saturday, January 05, 2013 21:05 > > > > Commit 9fca6cffc05321445b59c91e8f8d308f41588b53 message > states that > > the macro was being renamed for clarity. The patch also changes a > > define. > > Was it the commit before > 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiles or was > it 9fca6cffc05321445b59c91e8f8d308f41588b53 that compiled? I > am doing a cygwin update presently to look at it. > > > > > This change causes the code to not compile on cygwin 1.7.14. > > > > I narrowed the problem to this patch by bisecting commits between > > v1.8.0 and > > 1.8.1 > > > > Here is the error sequence: Cannot reproduce on head and current cygwin, more details please. > > > > CC compat/cygwin.o > > In file included from compat/../git-compat-util.h:90, > > from compat/cygwin.c:9: > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:103:2: > > warning: #warning "fd_set and associated macros have been > > defined in sys/types. > > This may cause runtime problems with W32 sockets" > > In file included from /usr/include/sys/socket.h:16, > > from compat/../git-compat-util.h:131, > > from compat/cygwin.c:9: > > /usr/include/cygwin/socket.h:29: error: redefinition of `struct > > sockaddr' > > /usr/include/cygwin/socket.h:41: error: redefinition of `struct > > sockaddr_storage' > > In file included from /usr/include/sys/socket.h:16, > > from compat/../git-compat-util.h:131, > > from compat/cygwin.c:9: > > /usr/include/cygwin/socket.h:59: error: redefinition of `struct > > linger' > > In file included from compat/../git-compat-util.h:131, > > from compat/cygwin.c:9: > > /usr/include/sys/socket.h:30: error: conflicting types for 'accept' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:536: > > error: previous declaration of 'accept' was here > > /usr/include/sys/socket.h:30: error: conflicting types for 'accept' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:536: jpyeron@porsche /projects/git/git $ make && uname -a && git status && git log --oneline | head -n1 GEN perl/PM.stamp SUBDIR gitweb SUBDIR ../ make[2]: `GIT-VERSION-FILE' is up to date. GEN git-instaweb BUILTIN all SUBDIR git-gui SUBDIR gitk-git make[1]: Nothing to be done for `all'. SUBDIR perl SUBDIR git_remote_helpers SUBDIR templates CYGWIN_NT-5.2-WOW64 porsche 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin # On branch master nothing to commit (working directory clean) 3e293fb Update draft release notes to 1.8.2 > > error: previous declaration of 'accept' was here > > /usr/include/sys/socket.h:32: error: conflicting types for 'bind' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:537: > > error: previous declaration of 'bind' was here > > /usr/include/sys/socket.h:32: error: conflicting types for 'bind' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:537: > > error: previous declaration of 'bind' was here > > /usr/include/sys/socket.h:33: error: conflicting types for 'connect' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:539: > > error: previous declaration of 'connect' was here > > /usr/include/sys/socket.h:33: error: conflicting types for 'connect' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:539: > > error: previous declaration of 'connect' was here > > /usr/include/sys/socket.h:34: error: conflicting types for > > 'getpeername' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:541: > > error: previous declaration of 'getpeername' was here > > /usr/include/sys/socket.h:34: error: conflicting types for > > 'getpeername' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:541: > > error: previous declaration of 'getpeername' was here > > /usr/include/sys/socket.h:35: error: conflicting types for > > 'getsockname' > > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w > insock2.h:5
RE: Version 1.8.1 does not compile on Cygwin 1.7.14
name' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:555: > error: previous declaration of 'gethostbyname' was here > /usr/include/netdb.h:199: error: conflicting types for > 'getprotobyname' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:559: > error: previous declaration of 'getprotobyname' was here > /usr/include/netdb.h:199: error: conflicting types for > 'getprotobyname' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:559: > error: previous declaration of 'getprotobyname' was here > /usr/include/netdb.h:200: error: conflicting types for > 'getprotobynumber' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:558: > error: previous declaration of 'getprotobynumber' was here > /usr/include/netdb.h:200: error: conflicting types for > 'getprotobynumber' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:558: > error: previous declaration of 'getprotobynumber' was here > /usr/include/netdb.h:203: error: conflicting types for 'getservbyport' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:556: > error: previous declaration of 'getservbyport' was here > /usr/include/netdb.h:203: error: conflicting types for 'getservbyport' > /usr/lib/gcc/i686-pc-cygwin/3.4.4/../../../../include/w32api/w insock2.h:556: > error: previous declaration of 'getservbyport' was here > Makefile:2384: recipe for target `compat/cygwin.o' failed > make: *** [compat/cygwin.o] Error 1 > -- > 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 > -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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
Trying to understand the web dav details
When doing a clone by https (reverse proxied to http) the first request is GET /git/project/info/refs?service=git-upload-pack How does the ?service= get translated in to the action performed on the web server? I ask because I have 2 projects, one works the other does not. I am using httpd-2.0.52-49.ent.centos4 and git-1.7.9.6-1. I am not even sure what to tell more about or where to look next. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Millisecond precision in timestamps?
> -Original Message- > From: Jeff King > Sent: Tuesday, November 27, 2012 20:18 > > On Tue, Nov 27, 2012 at 05:07:34PM -0800, Shawn O. Pearce wrote: > > > On Tue, Nov 27, 2012 at 4:26 PM, Felipe Contreras > > wrote: > > > On Wed, Nov 28, 2012 at 1:12 AM, Eric S. Raymond > wrote: > > >> Shawn Pearce : > > >>> Well... if we added a fractional seconds to a commit, older > > >>> versions of Git will scream loudly and refuse to work > with the new > > >>> commit. That would create a fork of Git. > > >> > > >> So much for that idea, I guess. > > >> > > >> Unless..I don't know how git's database representations > work. Are > > >> they version-stamped in any way? If so, some slightly painful > > >> hackery would get around that problem. > > > > > > % git cat-file -p HEAD > > > > > > You'll see exactly how git stores commits. Changing anything in > > > there must be done carefully. > > > > Apparently there is no room to change in these fields > without breaking > > compatibility with all current versions of Git. So its not > just done > > carefully... its deciding to make Git 2.0 that is not > compatible with > > any Git 1.x release. > > There is room for new headers, and older versions of git will > ignore them. You could add a new "committer-timestamp" field > that elaborates on the timestamp included on the committer > line. Newer versions of git would respect it, and older > versions would fall back to using the committer timestamp. Suggestion add a ms offset field. Ex: jpyeron@black /projects/git/git $ git cat-file -p HEAD tree 1e24acfbfcc05aa57e8cb2cfe3ffe01cb100961d parent e98fa647aa5673cc95b6e9be1fdc13c0afa2cb37 author Junio C Hamano 1350495361 -0700 committer Junio C Hamano 1350495402 -0700 mstimestamps author 0 committer 1234 Git 1.7.12.4 Signed-off-by: Junio C Hamano > > But I really wonder if anybody actually cares about adding > sub-second timestamp support, or if it is merely "because SVN has it". Not because subversion has it but because date != git(precisedate) and some automation using git in a larger enterprise workflow may assume that date 1354065991.1234 going in should be the same when queried. -Jason -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- - - - Jason Pyeron PD Inc. http://www.pdinc.us - - Principal Consultant 10 West 24th Street #100- - +1 (443) 269-1555 x333Baltimore, Maryland 21218 - - - -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- This message is copyright PD Inc, subject to license 20080407P00. -- 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: Failure using webdav basic auth by git client
I had to munge the body so the list would post it. See: http://vger.kernel.org/majordomo-taboos.txt > -Original Message- > From: Pyeron, Jason J CTR (US) > Sent: Thursday, November 08, 2012 2:49 PM > To: git@vger.kernel.org > Subject: Failure using webdav basic auth by git client > > My google fu has failed me on this issue. I am trying to setup http(s) > repositories for git. If I require authenticated users then git asks > for a username and password for the first volley of communications, but > then does not include the Authorization header on subsequent requests. > > Below is the log if I enable username and password BASIC auth in > Apache. > > user@host /tmp/foo/test > $ git push origin master > trace: built-in: git 'push' 'origin' 'master' > trace: run_command: 'git-remote-http' 'origin' > 'http://server/git/test/' > * Couldn't find host server in the .netrc file; using defaults > * About to connect() to server port 80 (#0) > * Trying server... > * 0x800766e8 is at send pipe head! > * STATE: CONNECT => WAITCONNECT handle 0x8007f040; (connection #0) > * Connected to server (server) port 80 (#0) > * Connected to server (server) port 80 (#0) > * STATE: WAITCONNECT => DO handle 0x8007f040; (connection #0) > > GET /git/test/info/refs?service=git-receive-pack HTTP/1.1 > User-Agent: git/1.7.9 > Host: server > Accept: */* > Pragma: no-cache > > * STATE: DO => DO_DONE handle 0x8007f040; (connection #0) > * STATE: DO_DONE => WAITPERFORM handle 0x8007f040; (connection #0) > * STATE: WAITPERFORM => PERFORM handle 0x8007f040; (connection #0) > * additional stuff not fine /usr/src/ports/curl/curl-7.27.0-1/src/curl- > 7.27.0/lib/transfer.c:1037: 0 0 > * The requested URL returned error: 401 Authorization Required > * Closing connection #0 > Username for 'http://server': > Password for 'http://test@server': > * Couldn't find host server in the .netrc file; using defaults > * About to connect() to server port 80 (#0) > * Trying server... > * 0x800766e8 is at send pipe head! > * STATE: CONNECT => WAITCONNECT handle 0x8007f9c0; (connection #0) > * Connected to server (server) port 80 (#0) > * Connected to server (server) port 80 (#0) > * STATE: WAITCONNECT => DO handle 0x8007f9c0; (connection #0) > > GET /git/test/info/refs?service=git-receive-pack HTTP/1.1 > User-Agent: git/1.7.9 > Host: server > Accept: */* > Pragma: no-cache > > * STATE: DO => DO_DONE handle 0x8007f9c0; (connection #0) > * STATE: DO_DONE => WAITPERFORM handle 0x8007f9c0; (connection #0) > * STATE: WAITPERFORM => PERFORM handle 0x8007f9c0; (connection #0) > * additional stuff not fine /usr/src/ports/curl/curl-7.27.0-1/src/curl- > 7.27.0/lib/transfer.c:1037: 0 0 > * HTTP 1.1 or later with persistent connection, pipelining supported > < HTTP/1.1 401 Authorization Required > < Date: Fri, 02 Nov 2012 03:11:53 GMT > < Server: Apache/2.0.52 (CentOS) > < WWW-Authenticate: Basic realm="Git" > < Content-Length: 479 > < Connection: close > < C-o-n-t-e-n-t---T-y-p-e-:- -t-e-x-t-/-h-t-m-l-;- -c-h-a-r-s-e-t-=-i-s-o---8-8-5-9---1- > < > * Closing connection #0 > * Issue another request to this URL: > 'http://server/git/test/info/refs?service=git-receive-pack' > * Couldn't find host server in the .netrc file; using defaults > * About to connect() to server port 80 (#0) > * Trying server... > * 0x800766e8 is at send pipe head! > * STATE: CONNECT => WAITCONNECT handle 0x8007f9c0; (connection #0) > * Connected to server (server) port 80 (#0) > * Connected to server (server) port 80 (#0) > * STATE: WAITCONNECT => DO handle 0x8007f9c0; (connection #0) > * Server auth using Basic with user 'test' > > GET /git/test/info/refs?service=git-receive-pack HTTP/1.1 > Authorization: Basic dGVzdDpwYXNzd29yZA== > User-Agent: git/1.7.9 > Host: server > Accept: */* > Pragma: no-cache > > * STATE: DO => DO_DONE handle 0x8007f9c0; (connection #0) > * STATE: DO_DONE => WAITPERFORM handle 0x8007f9c0; (connection #0) > * STATE: WAITPERFORM => PERFORM handle 0x8007f9c0; (connection #0) > * additional stuff not fine /usr/src/ports/curl/curl-7.27.0-1/src/curl- > 7.27.0/lib/transfer.c:1037: 0 0 > * HTTP 1.1 or later with persistent connection, pipelining supported > < HTTP/1.1 200 OK > < Date: Fri, 02 Nov 2012 03:11:53 GMT > < Server: Apache/2.0.52 (CentOS) > < Last-Modified: Thu, 01 Nov 2012 01:32:28 GMT > < ETag: "714064-0-fdf5a300" > < Accept-Ranges: bytes > < Content-Length: 0 > < Connection: close > < Content-Type: text/plain; charset=UTF-8 > < > * STATE: PERFORM => DONE handle 0x8007f9c0; (connection #0) > * Closing connection #0 > * Couldn't find host server in the .netrc file; using defaults > * About to connect() to server port 80 (#0) > * Trying server... > * 0x800766e8 is at send pipe head! > * STATE: CONNECT => WAITCONNECT handle 0x80076678; (connection #0) > * Connected to server (server) port 80 (#0) > * Connected to server (server) port 80 (#0) > * STATE: WAITCONNECT => DO handle 0x80076678; (connection #0) > * Server auth using Basic with user 'test'
