RE: [BUG} stash show does not show untracked files stashed (reposted)
> -Original Message- > From: Philip Oakley > Sent: September 2, 2019 11:56 AM > To: 002901d55e8f$e4a4af70$adee0e50$@rogers.com; > randall.s.bec...@rogers.com > Cc: git@vger.kernel.org > Subject: Re: [BUG} stash show does not show untracked files stashed > (reposted) > > On 02/09/2019 14:01, Giuseppe Crinò wrote: > >> Suppose I have files a,b,c,d modified, but only file d is in the index. > >> After stash push (or save) --include-untracked, stash show only > >> displays file d. A subsequent pop will restore files a,b,c,d. So > >> functionally push and pop are fine, but stash show appears to ignores files > in the stash. > > This is more of an enhancement, isn't it? > > > > To reproduce > > > > $ touch a b c d > > $ git add d > > $ git stash push --include-untracked > > $ git stash show > > d | 0 > > 1 file changed, 0 insertions(+), 0 deletions(-) > > > > What is the output that you think should be printed? > > > > I'd guess > > 1 file changed, 0 insertions(+), 0 deletions(-), *3 files untracked* > > as they are what's meant to be in the stash... (obviously format to taste) More like this, from git stash show -p, to be consistent with git show -p 4ef9fc3 (the ref for the untracked files), showing 000 indicating that the file is not tracked. diff --git a/d b/d index e3e2f1d..f246285 100644 --- a/a +++ b/a @@ -2,3 +2,4 @@ This is file 1 Yet another line New line New line 2 + another line diff --git a/a b/a new file mode 100644 index 000..64d8b7a --- /dev/null +++ b/a @@ -0,0 +1 @@ +line in a diff --git a/b b/b new file mode 100644 index 000..9aeb214 --- /dev/null +++ b/b @@ -0,0 +1 @@ +line in b diff --git a/c b/c new file mode 100644 index 000..87bb92b --- /dev/null +++ b/c @@ -0,0 +1 @@ +line in c
[BUG} stash show does not show untracked files stashed (reposted)
I don't know whether this is new behaviour following changes to stash, but here goes. Suppose I have files a,b,c,d modified, but only file d is in the index. After stash push (or save) --include-untracked, stash show only displays file d. A subsequent pop will restore files a,b,c,d. So functionally push and pop are fine, but stash show appears to ignores files in the stash. The git log below shows a previous commit (dce2e3e) to the WIP stash (ab0834c) that does contain the untracked files, and git diff is happy to show the contents when using the ref directly. It is just counterintuitive for stash show not to display all entries previously pushed. I would have expected symmetry. This is not new. *-. ab0834c (refs/stash) WIP on master: bf223fc Updated known |\ \ | | * dce2e3e untracked files on master: bf223fc Updated known | * a5ad1ef index on master: bf223fc Updated known |/ * bf223fc (HEAD -> master) Updated known * db0efd4 (origin/master, origin/HEAD) initial This on git 2.23.0. I have the same behaviour on the Windows build of git 2.12.3. builtins/stash.c show_stash() does not look like it accounts for multiple paths when calling setup_revisions, so I think it is missing the path to the untracked file ref (dce2e32). I am guessing. Thanks, Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: [Question] clone performance
On August 24, 2019 5:00 PM, Bryan Turner wrote: > On Fri, Aug 23, 2019 at 6:59 PM wrote: > > > > Hi All, > > > > I'm trying to answer a question for a customer on clone performance. > > They are doing at least 2-3 clones a day, of repositories with about > > 2500 files and 10Gb of content. This is stressing the file system. > > Can you go into a bit more detail about what "stress" means? Using too > much disk space? Too many IOPS reading/packing? Since you specifically > called out the filesystem, does that mean the CPU/memory usage is > acceptable? The upstream is BitBucket, which does a gc frequently. I'm not sure any of this is relating to the pack structure. Git is spending most of its time writing the large number of large files into the working directory - it is stress mostly the disk, with a bit on the CPU (neither is acceptable to the customer). I am really unsure there is any way to make things better. The core issue is that the customer insists on doing a clone for every feature branch instead of using pull/checkout. I have been unable to change their mind - to this point anyway. We are going to be setting up a detailed performance analysis that may lead to some data the git team can use. Regards, Randall
[Question] clone performance
Hi All, I'm trying to answer a question for a customer on clone performance. They are doing at least 2-3 clones a day, of repositories with about 2500 files and 10Gb of content. This is stressing the file system. I have tried to convince them that their process is not reasonable and should stick with existing clones, using branch checkout rather that re=cloning for each feature branch. Sadly, I have not been successful - not for a lack of trying. Is there any way to improve raw clone performance in a situation like this, where status really doesn't matter, because the clone's life span is under 48 hours. TIA, Randall
Re: [BUG] More on t5562 hangs randomly in subtests 6,8 and 13 in 2.21.0-rc0
On 2019-02-13, Max Kirillov, wrote: >On Mon, Feb 11, 2019 at 11:59:00AM -0500, Randall S. Becker wrote: >> Hi All, >> >> I have localized the hang in t5562 (previous thread) to the >> invoke-with-content-length.pl script. > >I have yet to look at it more closely, but there have been >one case of misbehavior due to unintended reuse of output file (see >https://public-inbox.org/git/20181119101535.16538-1-care...@gmail.com/ ) >Could your case be somehow related to it? I don't think the lack of curl is an issue (one thing mentioned in the thread), as curl works fine. We are on 7.57.0. As far as the unintended reuse of the output file, and issues with pipes, yes, the NonStop is very sensitive to complex use of pipes and much of the compatibility issues we have had relate to those (usually Linux-specific pipe assumptions). That is where I have been looking when trying to debug this situation (not yet found anything). This could very well be directly related. Regards, Randall
RE: [Patch v1 1/3] test-lib-functions.sh: add generate_zero_bytes function
On February 11, 2019 20:18, Eric Sunshine wrote:
> On Mon, Feb 11, 2019 at 7:37 PM Jeff King wrote:
> > On Sat, Feb 09, 2019 at 09:05:04PM -0500, Eric Sunshine wrote:
> > > On Sat, Feb 9, 2019 at 1:59 PM wrote:
> > > > +generate_zero_bytes () {
> > > > + perl -e 'if ($ARGV[0] == "infinity") {
> > >
> > > s/perl/"$PERL_PATH"/
> >
> > This shouldn't be necessary. perl() is a function that uses $PERL_PATH
> > (so you only need $PERL_PATH when you're writing out another script
> > that doesn't run in the same process space as the rest of the test code).
>
> Thanks for clarifying. I either didn't know or forgot about that.
As did I, thank you.
RE: [PATCH v4 2/4] config.mak.uname: support for modern HPE NonStop config.
On January 3, 2019 14:45, Junio C Hamano wrote: > To: randall.s.bec...@rogers.com > Cc: git@vger.kernel.org; Randall S. Becker > Subject: Re: [PATCH v4 2/4] config.mak.uname: support for modern HPE > NonStop config. > > randall.s.bec...@rogers.com writes: > > > @@ -470,8 +489,13 @@ ifeq ($(uname_S),NONSTOP_KERNEL) > > NO_MKDTEMP = YesPlease > > # Currently libiconv-1.9.1. > > OLD_ICONV = UnfortunatelyYes > > - NO_REGEX = YesPlease > > + NO_REGEX=NeedsStartEnd > > NO_PTHREADS = UnfortunatelyYes > > > > # Not detected (nor checked for) by './configure'. > > # We don't have SA_RESTART on NonStop, unfortunalety. > > The hunk header claims that the preimage has 8 lines while the postimage > has 13 lines, adding 5 new lines in total. But that is not what we can see in > the hunk. > > It is unclear to me if the numbers on the hunk header are bogus, or the patch > text was truncated, so I cannot use these two patches with confidence. The > first hunk had the same issue, and 1/4 too. > > I do not see v4 3/4 and v4 4/4, either. It's not like you are the only person > who sends patches to the mailing list, and not having the patches as > responses to a cover letter for proper threading makes it very hard to see > which patches belong to the same series and if all the necessary patches in a > series have become available. > Is it possible to arrange that to happen? > > Thanks. I will reissue the whole package for you. I think I hacked it badly. Will get to it after $DAYJOB is done.
RE: [PATCH v4 2/4] Define config options required for the HPE NonStop NSX and NSE platforms
On January 24, 2018 4:19 PM, Junio C Hamano wrote:
>
> randall.s.bec...@rogers.com writes:
>
> > From: "Randall S. Becker"
> >
> > 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
> > ---
> > config.mak.uname | 29 +
> > 1 file changed, 21 insertions(+), 8 deletions(-)
>
> The "tar extraction option" thing in 1/4 is not something you use here?
Not
> complaining---I am merely trying to use this as one data point to help me
> assess/guess what 1/4 is about ;-)
The define is used only in my team's distribution engine and we are planning
to override the define as part of our Jenkins build of git. We do not expect
anyone else who clones git and builds on the platform to use this
capability. As a result, I did not want it to be defaulted as "ov", which is
our setting.
>
> >
> > diff --git a/config.mak.uname b/config.mak.uname index
> > 685a80d13..d9f8d57e3 100644
> > --- a/config.mak.uname
> > +++ b/config.mak.uname
> > @@ -428,27 +428,37 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
> > # INLINE='' would just replace one set of warnings with another and
> > # still not compile in c89 mode, due to non-const array
initializations.
> > CC = cc -c99
> > + # Build down-rev compatible objects that don't use our new
> getopt_long.
> > + ifeq ($(uname_R).$(uname_V),J06.21)
> > + CC += -WRVU=J06.20
> > + endif
> > + ifeq ($(uname_R).$(uname_V),L17.02)
> > + CC += -WRVU=L16.05
> > + endif
> > # Disable all optimization, seems to result in bad code, with -O or
-O2
> > # or even -O1 (default),
/usr/local/libexec/git-core/git-pack-objects
> > # abends on "git push". Needs more investigation.
> > - CFLAGS = -g -O0
> > + CFLAGS = -g -O0 -Winline
> > # We'd want it to be here.
> > prefix = /usr/local
> > # Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
> > - PERL_PATH = ${prefix}/bin/perl
> > - PYTHON_PATH = ${prefix}/bin/python
> > -
> > + PERL_PATH = /usr/bin/perl
> > + PYTHON_PATH = /usr/bin/python
> > + RM = /bin/rm -f
> > # As detected by './configure'.
> > # Missdetected, hence commented out, see below.
> > #NO_CURL = YesPlease
> > # Added manually, see above.
> > NEEDS_SSL_WITH_CURL = YesPlease
> > + NEEDS_CRYPTO_WITH_SSL = YesPlease
> > + HAVE_DEV_TTY = YesPlease
> > HAVE_LIBCHARSET_H = YesPlease
> > HAVE_STRINGS_H = YesPlease
> > NEEDS_LIBICONV = YesPlease
> > NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
> > NO_SYS_SELECT_H = UnfortunatelyYes
> > NO_D_TYPE_IN_DIRENT = YesPlease
> > + NO_GETTEXT = YesPlease
> > NO_HSTRERROR = YesPlease
> > NO_STRCASESTR = YesPlease
> > NO_MEMMEM = YesPlease
> > @@ -458,8 +468,13 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
> > NO_MKDTEMP = YesPlease
> > # Currently libiconv-1.9.1.
> > OLD_ICONV = UnfortunatelyYes
> > - NO_REGEX = YesPlease
> > + NO_REGEX=NeedsStartEnd
> > NO_PTHREADS = UnfortunatelyYes
> > + ifdef NO_PTHREADS
> > + else # WIP, use Posix User Threads
> > + PTHREAD_CFLAGS = -D_PUT_MODEL_ -I/usr/include
> > + PTHREAD_LIBS = -lput
> > + endif
> >
> > # Not detected (nor checked for) by './configure'.
> > # We don't have SA_RESTART on NonStop, unfortunalety.
> > @@ -477,9 +492,7 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
> > # RFE 10-120912-4693 submitted to HP NonStop development.
> > NO_SETITIMER = UnfortunatelyYes
> > SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
> > - SHELL_PATH = /usr/local/bin/bash
> > - # as of H06.25/J06.14, we might better use this
> > - #SHELL_PATH = /usr/coreutils/bin/bash
> > + SHELL_PATH = /usr/coreutils/bin/bash
> > endif
> > ifneq (,$(findstring MINGW,$(uname_S)))
> > pathsep = ;
