RE: [RFC] git clean --local

On December 2, 2018 8:26, Ævar Arnfjörð Bjarmason wrote: > > On Sat, Dec 01 2018, Cameron Boehmer wrote: > > > 1) add a new flag > > -l, --local > > Do not consult git config --global core.excludesFile in > > determining what files git ignores. This is useful in conjunction with > > -x/-X to

RE: Git Tags

On November 29, 2018 6:56, Mateusz Loskot wrote: > On Thu, 29 Nov 2018 at 12:50, Stefanie Leisestreichler > wrote: > > > > git tag -a 0.9.0 > > git push origin master > > > > In my local repository, when I run "git tag" it is showing me "0.9.0". > > > > Then I did (on box B) > > git clone

RE: Cygwin Git with Windows paths

> -Original Message- > From: git-ow...@vger.kernel.org On Behalf Of > Junio C Hamano > Sent: November 18, 2018 19:07 > To: Torsten Bögershausen > Cc: Steven Penny ; git@vger.kernel.org > Subject: Re: Cygwin Git with Windows paths > > Torsten Bögershausen writes: > > > And it may even

RE: [PATCH 1/1] poll: use GetTickCount64() to avoid wrap-around issues

On November 4, 2018 6:26 PM, Junio C Hamano, wrote: > Johannes Sixt writes: > > > Am 03.11.18 um 09:14 schrieb Carlo Arenas: > >> On Fri, Nov 2, 2018 at 9:44 AM Johannes Sixt wrote: > >>> > >>> + timeout = elapsed >= orig_timeout ? 0 : (int)(orig_timeout - > >>> + elapsed); > >> > >>

RE: [RFE] Please add name and email to git credentials

On November 1, 2018 10:13 AM, Christian Couder wrote: > Sent: > To: nicolas.mail...@laposte.net > Cc: git > Subject: Re: [RFE] Please add name and email to git credentials > > On Thu, Nov 1, 2018 at 2:31 PM Nicolas Mailhot > wrote: > > > > Le jeudi 01 novembre 2018 à 12:22 +0100, Ævar Arnfjörð

RE: Git for games working group

On September 23, 2018 3:54 PM, John Austin wrote: > On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker > wrote: > > I would even like to help with your effort and have non-unixy platforms I'd > like to do this on. > > Having this separate from git LFS is an even better

RE: Git for games working group

On September 23, 2018 1:29 PM, John Austin wrote: > I've been putting together a prototype file-locking implementation for a > system that plays better with git. What are everyone's thoughts on > something like the following? I'm tentatively labeling this system git-sync or > sync-server. There

RE: [Question] Alternative to git-lfs under go

On September 17, 2018 6:02 PM, Jonathan Nieder wrote: > Randall S. Becker wrote: > > On September 17, 2018 3:28 PM, Jonathan Nieder wrote: > >> Randall S. Becker wrote: > > >>> Does anyone know whether it is practical to rework git-lfs under a > >>> la

RE: [Question] Alternative to git-lfs under go

On September 17, 2018 6:01 PM, Taylor Blau wrote: > On Mon, Sep 17, 2018 at 05:55:55PM -0400, Randall S. Becker wrote: > > On September 17, 2018 3:28 PM, Jonathan Nieder wrote: > > > Randall S. Becker wrote: > > > > > > > Does anyone know whether

RE: [Question] Alternative to git-lfs under go

On September 17, 2018 3:28 PM, Jonathan Nieder wrote: > Randall S. Becker wrote: > > > Does anyone know whether it is practical to rework git-lfs under a > > language other than "go"? GCC is not even close to being possible to > > port to my NonStop platform (may

[Question] Alternative to git-lfs under go

Hi All, Does anyone know whether it is practical to rework git-lfs under a language other than "go"? GCC is not even close to being possible to port to my NonStop platform (may have tried, some have died - joke - trying). I would like to convert this directly to C or something more widely

RE: Git for games working group

On September 17, 2018 11:58 AM, Taylor Blau wrote: > On Mon, Sep 17, 2018 at 05:00:10PM +0200, Ævar Arnfjörð Bjarmason > wrote: > > > 2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z > > > together." This isn't possible in Git LFS today with the existing "git > > > lfs

RE: Git for games working group

On September 17, 2018 9:55 AM Taylor Blau wrote: > On Sun, Sep 16, 2018 at 04:55:13PM +0200, Ævar Arnfjörð Bjarmason wrote: > > In the hypothetical git-annex-like case (simplifying a bit for the > > purposes this explanation), for every FILE in your tree you have a > > corresponding FILE.lock

RE: [Question] Signature calculation ignoring parts of binary files

On September 13, 2018 1:52 PM, Junio C Hamano wrote: > Junio C Hamano writes: > > > "Randall S. Becker" writes: > > > >> The scenario is slightly different. > >> 1. Person A gives me a new binary file-1 with fingerprint A1. This > >> go

RE: [Question] Signature calculation ignoring parts of binary files

On September 13, 2018 11:03 AM, Junio C Hamano wrote: > "Randall S. Becker" writes: > > > The scenario is slightly different. > > 1. Person A gives me a new binary file-1 with fingerprint A1. This > > goes into git unchanged. > > 2. Person B gives me bina

RE: [Question] Signature calculation ignoring parts of binary files

On September 12, 2018 7:00 PM, Junio C Hamano wrote: > "Randall S. Becker" writes: > > >> author is important to our process. My objective is to keep the > >> original file 100% exact as supplied and then ignore any changes to > >> the met

RE: [Question] Signature calculation ignoring parts of binary files

On September 12, 2018 4:54 PM, I wrote: > On September 12, 2018 4:48 PM, Johannes Sixt wrote: > > Am 12.09.18 um 21:16 schrieb Randall S. Becker: > > > I feel really bad asking this, and I should know the answer, and yet. > > > > > > I have a binary file

RE: [Question] Signature calculation ignoring parts of binary files

> -Original Message- > From: git-ow...@vger.kernel.org On Behalf > Of Johannes Sixt > Sent: September 12, 2018 4:48 PM > To: Randall S. Becker > Cc: git@vger.kernel.org > Subject: Re: [Question] Signature calculation ignoring parts of binary files > > A

[Question] Signature calculation ignoring parts of binary files

I feel really bad asking this, and I should know the answer, and yet. I have a binary file that needs to go into a repo intact (unchanged). I also have a program that interprets the contents, like a textconv, that can output the relevant portions of the file in whatever format I like - used for

RE: Multiple GIT Accounts & HTTPS Client Certificates - Config

en if your user is "git" in all cases above. It is a bit hacky but it is part of the SSH spec and is supported by git and EGit (as of 5.x). Cheers, Randall -- Randall S. Becker Managing Director, Nexbridge Inc. LinkedIn.com/in/randallbecker +1.416.984.9826

RE: Automatic core.autocrlf?

On August 30, 2018 11:29 PM, Jonathan Nieder wrote: > Torsten Bögershausen wrote: > > > My original plan was to try to "make obsolete"/retire and phase out > > core.autocrlf completely. > > However, since e.g. egit/jgit uses it > > (they don't have support for .gitattributes at all) I am not

RE: Automatic core.autocrlf?

On August 30, 2018 2:57 PM, Torsten Bögershausen wrote: > On Thu, Aug 30, 2018 at 09:57:52AM -0500, Robert Dailey wrote: > > On Wed, Aug 29, 2018 at 11:54 PM Jonathan Nieder > wrote: > > > > > > Hi, > > > > > > Robert Dailey wrote: > > > > > > > Is there an 'auto' setting for the 'core.autocrlf'

RE: [GitHub] Your password was reset

On August 26, 2018 11:35 AM, pedro rijo, wrote: > Subject: Re: [GitHub] Your password was reset > > just wondering if there's something going on? Is there a github account > associated with the mailing list email? seems odd... > > GitHub escreveu no dia domingo, 26/08/2018 à(s) > 10:35: > > >

RE: Contributor Summit planning

On August 14, 2018 2:53 AM, Elijah Newren wrote: > On Mon, Aug 13, 2018 at 10:27 AM Jeff King wrote: > > > > For the past several years, we've held a Git Contributor Summit as > > part of the Git Merge conference. I'd like to get opinions from the > > community to help plan future installments.

RE: [PATCH] Makefile: enable DEVELOPER by default

On August 6, 2018 1:42 PM, Ævar Arnfjörð Bjarmason wrote: > On Mon, Aug 06 2018, Randall S. Becker wrote: > > > On August 6, 2018 12:40 PM, Ævar Arnfjörð Bjarmason wrote: > >> On Sat, Aug 04 2018, Junio C Hamano wrote: > >> > >> > Duy Nguyen writes: >

RE: [PATCH] Makefile: enable DEVELOPER by default

On August 6, 2018 1:02 PM, Peff wrote: > To: Ævar Arnfjörð Bjarmason > Cc: Junio C Hamano ; Duy Nguyen > ; Jonathan Nieder ; Stefan > Beller ; Git Mailing List ; git- > packag...@googlegroups.com; Han-Wen Nienhuys > Subject: Re: [PATCH] Makefile: enable DEVELOPER by default > > On Mon, Aug 06,

RE: [PATCH] Makefile: enable DEVELOPER by default

On August 6, 2018 12:40 PM, Ævar Arnfjörð Bjarmason wrote: > On Sat, Aug 04 2018, Junio C Hamano wrote: > > > Duy Nguyen writes: > > > >> On Sat, Aug 4, 2018 at 8:11 AM Jonathan Nieder > wrote: > >>> My main concern is not about them but about other people building > >>> from source in order to

RE: abstracting commit signing/verify to support other signing schemes

On August 3, 2018 5:39 PM, Tacitus Aedifex wrote: > I'm looking at the existing commit signing and verification integration and > it is > all GPG specific. I'm interested in refactoring the code to have a generic > signing/verifying interface so that "drivers" > for other signing tools can be

RE: Using Git for applications other than code development

Hi David, I have used git over the past 3 years in a manufacturing environment to manage component designs in a CAD/factory automation setting. There are a few main factors that you need to consider: 1. You will need an external tool like Git for Windows, GitHub Client or SourceTree for

RE: [PATCH 1/2] introduce "banned function" list

On July 19, 2018 6:46 PM, Junio wrote: > Jeff King writes: > > > For enforcement, we can rely on the compiler and just introduce code > > which breaks compilation when it sees these functions. This has a few > > advantages: > > > > 1. We know it's run as part of a build cycle, so it's > >

RE: OAuth2 support in git?

On June 14, 2018 11:15 AM, Jeff King wrote: > On Thu, Jun 14, 2018 at 10:13:42AM +, brian m. carlson wrote: > > > > I know that other git server environments like github support that > > > on client side by allowing tokens to be used as usernames in a BASIC > > > authentication flow. We could

RE: git question from a newbie

On June 5, 2018 5:24 PM, Steve Heinz wrote: > I am new to Git and have read quite a few articles on it. > I am planning on setting up a remote repository on a windows 2012 R2 server > and will access it via HTTPS. > I am setting up a local repository on my desk top (others in my group will do >

RE: how exactly can git config section names contain periods?

> -Original Message- > From: git-ow...@vger.kernel.org On Behalf > Of Robert P. J. Day > Sent: June 1, 2018 4:14 PM > To: Git Mailing list > Subject: how exactly can git config section names contain periods? > > > more oddities in my travels, this from Doc.../config.txt: > > "The

RE: Git Vulnerability Announced?

On May 31, 2018 11:57 AM, Erika Voss wrote: > There was an article I came across yesterday identifying a vulnerability to > patch our Git environments. I don’t see one that is available for our Mac > Clients - is there a more recent one that I can download that is available to > patch the 2.17.0

RE: which files are "known to git"?

On May 21, 2018 7:19 AM, Robert P. J. Day: > updating my git courseware and, since some man pages refer to files > "known to git", i just want to make sure i understand precisely which files > those are. AIUI, they would include: > > * tracked files > * ignored files > * new files which

RE: Add option to git to ignore binary files unless force added

On May 18, 2018 7:31 AM, Anmol Sethi <m...@anmol.io> > That works but most binaries do not have a file extension. Its just not > standard on linux. > > > On May 17, 2018, at 8:37 AM, Randall S. Becker <rsbec...@nexbridge.com> > wrote: > > > > On May 1

RE: Add option to git to ignore binary files unless force added

On May 16, 2018 11:18 PM, Jacob Keller > On Wed, May 16, 2018 at 5:45 PM, Anmol Sethi wrote: > > I think it’d be great to have an option to have git ignore binary files. My > repositories are always source only, committing a binary is always a mistake. > At the moment, I have to

RE: [Best Practices Request] clean/smudge configuration - Avoiding the chicken and egg

On May 11, 2018 3:26 PM, I wrote: > On May 10, 2018 10:27 PM, Junio C Hamano wrote: > > "Randall S. Becker" <rsbec...@nexbridge.com> writes: > > > > > What if we create a ../.gitconfig like ../.gitattributes, that is > > > loaded before .git/con

RE: [Best Practices Request] clean/smudge configuration

On May 10, 2018 10:27 PM, Junio C Hamano wrote: > "Randall S. Becker" <rsbec...@nexbridge.com> writes: > > > What if we create a ../.gitconfig like ../.gitattributes, that is > > loaded before .git/config? > > You should not forget one of the two reas

RE: [Best Practices Request] clean/smudge configuration

On May 9, 2018 6:39 PM, Bryan Turner wrote: > On Wed, May 9, 2018 at 3:09 PM Randall S. Becker > <rsbec...@nexbridge.com> > wrote: > > > The question: what is the best practice for versioning the parts of > > clean/smudge filters that are in .git/config given

RE: [Best Practices Request] clean/smudge configuration

On May 9, 2018 6:39 PM, Bryan Turner wrote > > On Wed, May 9, 2018 at 3:09 PM Randall S. Becker > <rsbec...@nexbridge.com> > wrote: > > > The question: what is the best practice for versioning the parts of > > clean/smudge filters that are in .git/config giv

[Best Practices Request] clean/smudge configuration

Hi Git Team, I'm trying to work out some best practices for managing clean/smudge filters and hit a bump. The situation is that I have an environment where the possible clean/smudge filter configuration can change over time and needs to be versioned with the product being managed in a git

RE: How to undo previously set configuration?

On April 5, 2018 7:21 AM, Ævar Arnfjörð Bjarmason wrote: > On Thu, Apr 05 2018, Olaf Hering wrote: > > > Am Thu, 05 Apr 2018 10:42:15 +0200 > > schrieb Ævar Arnfjörð Bjarmason : > > > >> I've been meaning to work on this but haven't figured out a good syntax > for it

RE: [ANNOUNCE] Git v2.17.0

On April 2, 2018 3:34 PM, Junio C Hamano wrote: > Subject: [ANNOUNCE] Git v2.17.0 > > The latest feature release Git v2.17.0 is now available at the usual places. > It is > comprised of 516 non-merge commits since v2.16.0, contributed by 71 > people, 20 of which are new faces. The NonStop

RE: [ANNOUNCE] Git v2.17.0

On April 2, 2018 7:20 PM, Junio C Hamano wrote: > To: Stefan Beller <sbel...@google.com> > Cc: Randall S. Becker <rsbec...@nexbridge.com>; git <git@vger.kernel.org> > Subject: Re: [ANNOUNCE] Git v2.17.0 > > Stefan Beller <sbel...@google.com> writes: > &g

RE: [ANNOUNCE] Git v2.17.0

On April 2, 2018 4:02 PM, Stefan Beller found my change: > On Mon, Apr 2, 2018 at 12:57 PM, Randall S. Becker > <rsbec...@nexbridge.com> wrote: > > On April 2, 2018 3:34 PM, Junio C Hamano wrote: > >> The latest feature release Git v2.17.0 is now availab

RE: [ANNOUNCE] Git v2.17.0

On April 2, 2018 3:34 PM, Junio C Hamano wrote: > The latest feature release Git v2.17.0 is now available at the usual places. > It is > comprised of 516 non-merge commits since v2.16.0, contributed by 71 > people, 20 of which are new faces. Just a heads up. I think this one might have gotten

RE: [RFC] git clone add option to track all remote branches

On April 1, 2018 11:22 PM Junio C Hamano wrote: > Junio C Hamano writes: > > If you are really doing your own development, then you would have some > > topic branches of your own, with forks of some (but most likely not > > all, especiallyi when there are many branches at the

RE: [PATCH v4] json_writer: new routines to create data in JSON format

On March 27, 2018 1:43 PM, Wink Saville wrote: > > the leading spaces are required in this case. > > the pretty json output contains 8 spaces for that sub-structure not a tab. > > is there a preferred way to denote this in the test script? > > > > Jeff > > I've used "git diff --check" which I got

RE: [bug] git stash push {dir-pathspec} wipes untracked files

> -Original Message- > From: git-ow...@vger.kernel.org On Behalf > Of Junio C Hamano > Sent: March 15, 2018 12:52 PM > To: Jake Stine > Cc: git@vger.kernel.org > Subject: Re: [bug] git stash push {dir-pathspec} wipes untracked files > >

RE: Why don't we symlink libexec/git-core/* to bin/git?

On March 13, 2018 2:37 PM, Junio C Hamano wrote: > Ævar Arnfjörð Bjarmason writes: > > > Related to this, I came across this bug report > > https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3265 which is > > wondering why we're installing N copies of the git binary,

RE: [PATCH 0/3] git worktree prune improvements

On March 2, 2018 10:39 PM, Nguy?n Thái Ng?c Duy wrote: > This is something we could do to improve the situation when a user manually > moves a worktree and not follow the update process (we have had the first > reported case [1]). Plus a bit cleanup in gc. > > I think this is something we should

RE: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On March 1, 2018 2:36 AM, Jeff King wrote: > On Wed, Feb 28, 2018 at 05:51:14PM +0100, demerphq wrote: > > > I would look into putting it into a module and then using the PERL5OPT > > environment var to have it loaded automagically in any of your perl > > scripts. > > > > For instance if you put

RE: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On February 28, 2018 3:04 PM, Jonathan Nieder wrote: > On February 28, 2018 1:52 PM, Jonathan Nieder wrote: > > Randall S. Becker wrote: > > > On February 28, 2018 12:44 PM, Jonathan Nieder wrote: > > >> Randall S. Becker wrote: > > > > >>> Th

RE: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On February 28, 2018 1:52 PM, Jonathan Nieder wrote: > Randall S. Becker wrote: > > On February 28, 2018 12:44 PM, Jonathan Nieder wrote: > >> Randall S. Becker wrote: > > >>> The problem is actually in git code in its test suite that uses perl > &g

RE: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On February 28, 2018 12:44 PM, Jonathan Nieder wrote: > Randall S. Becker wrote: > > > The problem is actually in git code in its test suite that uses perl > > inline, not in my test code itself. The difficulty I'm having is > > placing this appropriate so that the

RE: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On February 28, 2018 12:19 PM, demerphq wrote: > On 28 February 2018 at 18:10, Randall S. Becker <rsbec...@nexbridge.com> > wrote: > > On February 28, 2018 11:46 AM, demerphq wrote: > >> On 28 February 2018 at 08:49, Jeff King <p...@peff.net> wrote: > >>

RE: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On February 28, 2018 11:46 AM, demerphq wrote: > On 28 February 2018 at 08:49, Jeff King wrote: > > On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote: > > > >> > > > a) We could override the meaning of die() in Git.pm. This feels > >> > > > ugly but if it works, it

RE: [Problem] test_must_fail makes possibly questionable assumptions about exit_code.

On February 28, 2018 2:49 AM, Peff wrote: > On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote: > > > > > > a) We could override the meaning of die() in Git.pm. This feels > > > > > ugly but if it works, it would be a very small patch. > > > > > > > > Unlikely to work since I think

[Problem] test_must_fail makes possibly questionable assumptions about exit_code.

Hi all, After months of arguing with some platform developers on this subject, the perl spec was held over my head repeatedly about a few lines that are causing issues. The basic problem is this line (test-lib-functions.sh, line 633, still in ffa952497) >elif test $exit_code -gt 129 &&

RE: [PATCH 3/8] perl: generalize the Git::LoadCPAN facility

On February 25, 2018 1:57 PM, Ævar Arnfjörð Bjarmason wrote: > On Wed, Feb 14 2018, Jonathan Nieder jotted: > > > Ævar Arnfjörð Bjarmason wrote: > > > >> Change the two wrappers to load from CPAN (local OS) or our own copy > >> to do so via the same codepath. > > > > nit: I think with s/to

RE: Git should preserve modification times at least on request

On February 21, 2018 6:13 PM, Peter Backes wrote: > On Wed, Feb 21, 2018 at 11:44:13PM +0100, Ævar Arnfjörð Bjarmason wrote: > > If it were added as a first-level feature to git it would present a > > lot of UX confusion. E.g. you run "git add" and it'll be showing the > > mtime somehow, or you

RE: [BUG] Worktree prune complains about missing path

On February 20, 2018 5:22 PM Eric Sunshine wrote: > On Tue, Feb 20, 2018 at 3:36 PM, Randall S. Becker > <rsbec...@nexbridge.com> wrote: > > I’m a bit confused about this, as I thought I understood worktrees :(. > > > > /home/randall/nsgit/test/test dir.mytest: rm

[BUG] Worktree prune complains about missing path

I’m a bit confused about this, as I thought I understood worktrees :(. /home/randall/nsgit/test/test dir.mytest/dest git worktree list /home/randall/nsgit/test/test dir.mytest/dest: git worktree list /home/randall/nsgit/test/test dir.mytest/dest 4e901ca [master] /home/randall/nsgit/test/test

RE: Git should preserve modification times at least on request

On February 19, 2018 4:58 PM Johannes wrote: > On Mon, 19 Feb 2018, Peter Backes wrote: > > > please ensure to CC me if you reply as I am not subscribed to the list. > > > > https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preservi > > ng_modification_time_on_files.3F argues that git

Git 2.16.2 on NonStop Test Status

Just letting you know that we are one breakage reduced from 2.16.1. Now at 3 total (1308:23, 1404:52, 9001:134) - all of which were expected. Nice work. Cheers, Randall -- Brief whoami: NonStop developer since approximately NonStop(2112884442) UNIX developer since approximately

RE: git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands

On February 7, 2018 11:53 AM, Andreas Schwab wrote: > On Feb 06 2018, "Randall S. Becker" <rsbec...@nexbridge.com> wrote: > > > What I don't know - and it's not explicitly in the CVE - is just how > > many other terminal types with similar vulnerabilities are

RE: git: CVE-2018-1000021: client prints server sent ANSI escape codes to the terminal, allowing for unverified messages to potentially execute arbitrary commands

On February 5, 2018 3:43 PM, Jonathan Nieder wrote: > > Salvatore Bonaccorso wrote[1]: > > > the following vulnerability was published for git. > > > > CVE-2018-121[0]: > > |client prints server sent ANSI escape codes to the terminal, allowing > > |for unverified messages to potentially

RE: [PATCH 11/26] serve: introduce git-serve

On February 1, 2018 3:08 PM, Brandon Williams wrote: > On 02/01, Randall S. Becker wrote: > > On February 1, 2018 1:58 PM, Stefan Beller wrote: > > > On Thu, Feb 1, 2018 at 10:48 AM, Jeff Hostetler > > > <g...@jeffhostetler.com> > > > wrote: > >

RE: [PATCH 11/26] serve: introduce git-serve

On February 1, 2018 1:58 PM, Stefan Beller wrote: > On Thu, Feb 1, 2018 at 10:48 AM, Jeff Hostetler > wrote: > > > > > > On 1/2/2018 7:18 PM, Brandon Williams wrote: > >> > >> Introduce git-serve, the base server for protocol version 2. > >> > >> Protocol version 2 is

RE: Shawn Pearce has died

s will remain with us forever. Sincerest Condolences, Randall -- Randall S. Becker ITUGLIB Process Designer, Repository Manager, Git and Occasional Other Porting Dude NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.

RE: Missing ? wildcard character in gitignore documentation

On January 29, 2018 6:30 AM, Jack F wrote: > I have just noticed that the documentation for gitignore is missing > documentation on using the ? to match any single character. I have included > a example below with git version 2.14.1. > > |11:05:09 j ~/Development/ls-ignore [master] $ git status

RE: pushing a delete-only commit consumes too much traffic

n Ilya [mailto:basini...@gmail.com] > Sent: January 25, 2018 10:08 AM > To: Randall S. Becker <rsbec...@nexbridge.com>; git@vger.kernel.org > Subject: Re: pushing a delete-only commit consumes too much traffic > > > Were the 60Mb of jars previously pushed in a commit that already ex

RE: pushing a delete-only commit consumes too much traffic

On January 25, 2018 9:15 AM, Basin Ilya wrote: > I had a 60Mb worth of unneeded jar files in the project. I created a new > branch and performed `git rm` on them. Now while I was pushing the change > the counter of sent data reached 80Mb. Why is that? Can you provide more info? Were the 60Mb of

RE: [PATCH v2 0/6] Force pipes to flush immediately on NonStop platform

On January 23, 2018 1:13 PM, Junio C Hamano wrote: > > "Randall S. Becker" <rsbec...@nexbridge.com> writes: > > >> IOW, I do not see it explained clearly why this change is needed on > >> any single platform---so "that issue may be shared by o

RE: [PATCH v4 1/4] Add tar extract install options override in installation processing.

> -Original Message- > From: Todd Zullinger [mailto:t...@pobox.com] > Sent: January 24, 2018 5:02 PM > To: Junio C Hamano <gits...@pobox.com> > Cc: randall.s.bec...@rogers.com; git@vger.kernel.org; Randall S. Becker > <rsbec...@nexbridge.com> > Subject: R

RE: [PATCH v4 3/4] Bring NonStop platform definitions up to date in git-compat-util.h

On January 24, 2018 4:18 PM, Junio C Hamano wrote: > > "Randall S. Becker" <rsbec...@nexbridge.com> writes: > > >> > +#ifdef __TANDEM > >> > +#if !defined(_THREAD_SUPPORT_FUNCTIONS) && > >> !defined(_PUT_MODEL_) > >> &g

RE: [PATCH v4 3/4] Bring NonStop platform definitions up to date in git-compat-util.h

On January 24, 2018 3:36 PM, Junio C Hamano wrote: > randall.s.bec...@rogers.com writes: > > > From: "Randall S. Becker" <rsbec...@nexbridge.com> > > > > Add correct FLOSS (NonStop platform emulation) definitions into > > git-compat-util.h to allow c

RE: [PATCH v2 0/6] Force pipes to flush immediately on NonStop platform

On January 23, 2018 1:13 PM, Junio C Hamano wrote: > "Randall S. Becker" <rsbec...@nexbridge.com> writes: > > >> IOW, I do not see it explained clearly why this change is needed on > >> any single platform---so "that issue may be shared by othe

RE: [Nit] Lots of enumerated type warnings

On January 22, 2018 6:44 PM, Junio C Hamano wrote: > > "Randall S. Becker" <rsbec...@nexbridge.com> writes: > > > Here are a few examples, there are more: > > > > auto_crlf = git_config_bool(var, value); > > ^ > >

RE: [Nit] Lots of enumerated type warnings

On January 22, 2018 5:41 PM, Junio C Hamano wrote: > "Randall S. Becker" <rsbec...@nexbridge.com> writes: > > > I'm seeing an increase in the enumerated type warnings coming from my > > use of the c99 compiler for compiling git over time (loads more for > &

RE: [PATCH v2 0/6] Force pipes to flush immediately on NonStop platform

On January 22, 2018 5:36 PM, Junio C Hamano wrote: > Torsten Bögershausen <tbo...@web.de> writes: > > > On Fri, Jan 19, 2018 at 12:33:59PM -0500, randall.s.bec...@rogers.com > wrote: > >> From: "Randall S. Becker" <rsbec...@nexbridge.com> > >

[PATCH v4 2/4] Define config options required for the HPE NonStop NSX and NSE platforms

From: "Randall S. Becker" <rsbec...@nexbridge.com> Upgrade old options in config.mak.uname to currently supported NonStop operating system versions (J06.21 and L17.xx). Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com> --- config.mak.uname | 29 +++

[PATCH v4 3/4] Bring NonStop platform definitions up to date in git-compat-util.h

From: "Randall S. Becker" <rsbec...@nexbridge.com> Add correct FLOSS (NonStop platform emulation) definitions into git-compat-util.h to allow correct emulation of non-platform behaviour. Also added NSIG definition that is not explicitly supplied in signal.h on platform. Signed-o

[PATCH v4 0/4] Force pipes to flush immediately on NonStop platform

From: "Randall S. Becker" <rsbec...@nexbridge.com> Call setbuf(stream,NULL) to force pipe flushes not enabled by default on the NonStop platform in wrapper.c. This may be extended in future to a configure option. Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com> ---

[PATCH v4 4/4] Add intptr_t and uintptr_t to regcomp.c for NonStop platform.

From: "Randall S. Becker" <rsbec...@nexbridge.com> Fix missing intptr_t on NonStop in compat/regex/regcomp.c wrapped using the __TANDEM guard define. This is done because git-compat-util.h cannot be cleanly included into this file without additional compile errors. Signed-o

[PATCH v4 1/4] Add tar extract install options override in installation processing.

From: "Randall S. Becker" <rsbec...@nexbridge.com> Introduced TAR_EXTRACT_OPTIONS as a configuration option to change the options of tar processing during extract. The default value is "o" which synthesizes xof, by default. Signed-off-by: Randall S. Becker <rsbec...

RE: [PATCH v2 4/6] Force test suite traps to be cleared for NonStop ksh

On January 19, 2018 5:29 PM, I wrote: > On January 19, 2018 4:27 PM, Jeff King wrote: > > On Fri, Jan 19, 2018 at 12:34:04PM -0500, randall.s.bec...@rogers.com > wrote: > > > > > From: "Randall S. Becker" <rsbec...@nexbridge.com> > > > > &g

RE: [PATCH v2 2/6] Add tar extract install options override in installation processing.

On January 20, 2018 3:34 PM, Ævar Arnfjörð Bjarmason > On Sat, Jan 20 2018, Randall S. Becker jotted: > > > I will reissue this particular patch shortly. > > It makes sense to base that submission on the next branch instead of master. > I have a patch queued up there w

RE: [PATCH v2 2/6] Add tar extract install options override in installation processing.

On January 20, 2018 9:25 AM, René Scharfe wrote: > To: Randall S. Becker <rsbec...@nexbridge.com>; git@vger.kernel.org > Subject: Re: [PATCH v2 2/6] Add tar extract install options override in > installation processing. > > Am 20.01.2018 um 14:44 schrieb Randall S. Becker: &g

RE: [PATCH v2 2/6] Add tar extract install options override in installation processing.

On January 20, 2018 7:31 AM, René Scharfe wrote: > Am 19.01.2018 um 18:34 schrieb randall.s.bec...@rogers.com: > > From: "Randall S. Becker" <rsbec...@nexbridge.com> > > > > * Makefile: Add TAR_EXTRACT_OPTIONS to allow platform options to be > >

RE: [PATCH v2 0/6] Force pipes to flush immediately on NonStop platform

On January 20, 2018 6:10 AM, Torsten Bögershausen wrote: > On Fri, Jan 19, 2018 at 12:33:59PM -0500, randall.s.bec...@rogers.com > wrote: > > From: "Randall S. Becker" <rsbec...@nexbridge.com> > > > > * wrapper.c: called setbuf(stream,0) to force p

RE: [RFE/RFC] format-patch/diff via path

On January 20, 2018 2:15 AM, Junio C Hamano wrote: > "Randall S. Becker" <rsbec...@nexbridge.com> writes: > > > I’m still a bit perplexed by some behaviour seen today, and am looking > > for a clean way to deal with it that the documentation does not make > &

[RFE/RFC] format-patch/diff via path

I’m still a bit perplexed by some behaviour seen today, and am looking for a clean way to deal with it that the documentation does not make clear. So, I’m asking in a different way. Suppose a graph of A---B---C---D---E \ \ / \F—G/ When trying to perform a

RE: [PATCH v2 4/6] Force test suite traps to be cleared for NonStop ksh

On January 19, 2018 5:29 PM, I wrote: > On January 19, 2018 4:27 PM, Jeff King wrote: > > On Fri, Jan 19, 2018 at 12:34:04PM -0500, randall.s.bec...@rogers.com > wrote: > > > > > From: "Randall S. Becker" <rsbec...@nexbridge.com> > > > > &g

[Nit] Lots of enumerated type warnings

So here a bit of a nit or nano-quibble that I have. Call it my "warnings OCD" if you want. I'm seeing an increase in the enumerated type warnings coming from my use of the c99 compiler for compiling git over time (loads more for 2.16.0 compared to 2.3.7 when I took it on). What is the general

RE: [PATCH v3 0/6] Force pipes to flush immediately on NonStop platform

> -Original Message- > From: randall.s.bec...@rogers.com [mailto:randall.s.bec...@rogers.com] > Sent: January 19, 2018 6:00 PM > To: git@vger.kernel.org > Cc: Randall S. Becker <rsbec...@nexbridge.com> > Subject: [PATCH v3 0/6] Force pipes to flush immediate

[PATCH v3 0/6] Force pipes to flush immediately on NonStop platform

From: "Randall S. Becker" <rsbec...@nexbridge.com> * wrapper.c: called setbuf(stream,NULL) to force pipe flushes not enabled by default on the NonStop platform. This applies only to the NonStop platform guarded by #ifdef __TANDEM. Signed-off-by: Randall S. Becker <rsb

RE: [PATCH v2 1/6] Bypass GCC attributes on NonStop platform where used.

On January 19, 2018 5:43 PM, Ramsay Jones wrote: > On 19/01/18 21:20, Jeff King wrote: > > On Fri, Jan 19, 2018 at 08:28:48PM +, Ramsay Jones wrote: > > > >>> diff --git a/remote.c b/remote.c > >>> index 4e93753e1..c18f9de7f 100644 > >>> --- a/remote.c > >>> +++ b/remote.c > >>> @@ -11,6

RE: [PATCH v2 1/6] DO NOT APPLY Bypass GCC attributes on NonStop platform where used.

On January 19, 2018 3:29 PM, Ramsay Jones wrote: > On 19/01/18 17:34, randall.s.bec...@rogers.com wrote: > > From: "Randall S. Becker" <rsbec...@nexbridge.com> > > > > * remote.c: force ignoring of GCC __attribute construct not supported > >

  1   2   3   >