RE: [DISCUSSION] Growing the Git community
On September 20, 2019 10:36 AM, brian m. carlson wrote: > To: Derrick Stolee > Cc: git@vger.kernel.org; p...@peff.net; Emily Shaffer > ; Jonathan Nieder ; > Johannes Schindelin ; gits...@pobox.com; > garimasi...@gmail.com > Subject: Re: [DISCUSSION] Growing the Git community > > On 2019-09-19 at 16:30:13, Derrick Stolee wrote: > > 1. Improve the documentation for contributing to Git. > > > > In preparation for this email, I talked to someone familiar with > > issues around new contributors, and they sat down to try and figure > > out how to contribute to Git. The first place they went was > > https://github.com/git/git and looked at the README. It takes deep > > reading of a paragraph to see a link to the SubmittingPatches docs. > > > > To improve this experience, we could rewrite the README to have > > clearer section markers, including one "Contributing to Git" section > > relatively high in the doc. We may want to update the README for multiple > reasons. > > It should link to the new "My First Contribution" document > > (https://git-scm.com/docs/MyFirstContribution). > > I think there's a lot of improvements we could make here, and I know that > many folks are already working on contributor documentation. > That's enormously valuable work, and I'm pleased to see it going on. > > > 2. Add more pointers to GitGitGadget > > > > We have a reference to GitGitGadget in the GitHub PR template to try > > and get people who try to submit a pull request to git/git to instead > > create one on GitGitGadget. However, that captures contributors who > > didn't read the docs about how to submit! (This is somewhat covered by > > the "My First Contribution" doc as well, so making that more visible > > will also help.) > > I think GitGitGadget is a useful tool which I haven't really had the time to > learn how to use. I appreciate that many people prefer a patch-based > workflow, and that using a patch-based workflow and a mailing list provides > the project independence and avoids favoring any hosting platform or tool, > which I agree with. > > I think also that many folks find a pull request-based workflow to be easier > and more familiar and supporting this a bit better may lower the barrier to > entry, so I'm in favor of bridges that make contributing easier, even if one > still needs to subscribe to the list to get feedback. > > > 4. Add an official Code of Conduct > > > > So far, the community has had an unofficial policy of "be nice, as > > much as possible". We should add a Code of Conduct that is more > > explicit about the behavior we want to model. This was also discussed > > in the meeting with wide approval. > > I think this is a good idea. We already document how to contribute to the > community by sending a bug report or a patch: how to format your emails, > how to sign off your patches, and how to write a good commit message. I > see a code of conduct as another way to do this by documenting our social > norms much as we document the way our contributions should look > technically. > > I also know in the past we have had problems with a contributor who was > being argumentative and disagreeable. I think documenting the kind of > behavior we want to see both helps individuals ask themselves if their own > behavior is helping us provide a positive community and helps other > contributors provide feedback about unhelpful or unacceptable behavior on > the rare occasion that we see it. > > Lest I give the impression otherwise, I think that overall the Git community > is > quite welcoming and positive, and I anticipate that it will continue to remain > that way. I expect that the difference in behavior on the list if we adopt a > code of conduct will be small, since so far pretty much everyone seems to be > engaging in productive, helpful ways. > > However, I know that many folks from underrepresented groups in tech feel > more comfortable when there's a code of conduct because it signals to them > that the project cares about fostering a respectful, healthy community and > that their contributions are likely to be welcomed. I recommend the > Contributor Covenant for this purpose, since it is well known, well accepted, > and is used by numerous other FLOSS projects. Speak as one of those from two very specific underrepresented groups, I have found the committers and reviewers welcoming (and sometimes rightly and deservedly harsh when it was warranted). Although I only have a small number of contributions, I have not found there to be any glaring gaps in the implied policies that have grown organically in the team to this point and hope that we do not become overly formalized as that will, in my experience, push people away. The organic policies of this group are very closely aligned with the Contributor Covenant used by FLOSS - close enough that perhaps only a semanticist will find a difference, so I do find Brian's suggestion to be supportable. Kind Regards, Randall -- Brief whoa
RE: Patching Git to handle dates before the Unix epoch
On September 10, 2019 10:15 AM, Diomidis Spinellis wrote: > As people use Git to create synthetic commits of code written in the past > [1,2] it becomes important to handle dates before the Unix epoch > (1/1/1970). I see that modern C libraries, Unix kernels, and tools can handle > such dates. However Git seems to mishandle such dates in several places, > such as in date.c [3,4]. I'm planning to work on a fix, but before I embark > on > this I have a few questions. > > - Do you see any reasons that may prevent the acceptance of such a patch? > - Can you think of any non-obvious issues (e.g. backward compatibility, > switch to the Gregorian calendar) I should be aware of? > - Should I submit changes as a bug fix on the maint branch or as a new > feature on master? My suggestion is a new feature as a patch. See other contributions. While you're at this, especially given how extensive this may be given the time_t references, it might be useful to examine the end of epoch concerns as well. 2036 is not that far off and some of the repositories I am managing will likely last beyond the Unix date rollover. There are no time64_t to get us to 2106, but even that is probably not sufficient (thinking beyond my own expiry date). The concept of unlimited date ranges is intriguing if we are going to store broader range artifacts in git, like signatures of physical core samples and use the carbon dating in git, or some Sci-Fi conceptual commit on old 1701D. So if I had a preference, it would be to store an extensible date range going from the Big Bang to the Big Crunch (or beyond), but that is excessive. Sadly my platform's own date ranges are 64-bit microsecond that range from year 1 (AD) - 1 (AD) and I can't map easily to Unix dates. Just my $0.02, Randall
Question of intent: stash push --include-untracked
I'm a bit perplexed about what is intended follow a git stash push --include-untracked. Suppose I have files a,b,c,known modified, but only known is in the index. After the stash, stash show only displays known. A subsequent pop will restore a,b,c. So functionally push and pop are fine, but show appears to ignores files in the stash. The log 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. Is this new, or intended. *-. 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 Thanks, Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: How to build to debug with gdb?
On August 27, 2019 1:56 PM, Matheus Tavares Bernardino wrote:
> On Tue, Aug 27, 2019 at 1:27 PM Giuseppe Crino'
> wrote:
> > Hello, to debug some issues I built and installed git via
> >
> > $ make prefix=/usr/local DEVELOPER=1 CFLAGS="-O0 -g"
> > $ sudo make install
> > $ git --version # git version 2.23.0.40.g4d8aada92f
>
> Hmm, could it be perhaps that CFLAGS is being overwritten? To debug Git
> with GDB I always add this to my config.mak file:
>
> CFLAGS += -g3 -O0
> LDFLAGS += -g3 -O0
>
> And then just compile with `make`. Maybe give it a try?
>
> > But it seems there's still some optimization going on that prevents gdb
> from working correctly.
> >
> > For example
> >
> > (gdb) b builtin/config.c:752
> > Breakpoint 1 at 0x43942: file builtin/config.c, line 752.
> > (gdb) r config --global --edit
> > Starting program: /usr/local/bin/git config --global --edit [Thread
> > debugging using libthread_db enabled] Using host libthread_db library
> > "/lib/x86_64-linux-gnu/libth read_db.so.1".
> >
> > Breakpoint 1, cmd_config (argc=0, argv=,
> > prefix=) at builtin/config.c:753
> > 753 if (fd >= 0) {
> > (gdb) p fd
> > $1 =
> >
> > What am I missing?
Given that you are 40 commits in from 2.23.0, is it possible that you have
compiled a few objects, like main, using the old CFLAGS? Gdb is notorious for
not showing symbols if main does not have it. Have you done a git clean -dxf
before building with the new CFLAGS?
Just a thought.
Randall
RE: [Feature Request] Option to make .git not read-only in cloned repos
On August 26, 2019 11:28 AM, Junio C Hamano wrote: > "Randall S. Becker" writes: > > >> Sometimes I clone a repo just to grep for an error string and then I > >> don't need it anymore, or I clone several repos until I find the one > >> that contains what I want and delete the rest. Sometimes I want to > >> write a patch for some software I don't develop regularly so I don't need > to keep a clone of it. > >> > >> In any case, it would be useful to know the reason those files are > >> read-only in the first place. Do you guys know who might know? > > > > Why don't you wrap your clone in a script that calls chmod -R u+w .git > > after the clone? This seems like a pretty trivial approach regardless > > of your workflow. This works in Linux, Mac, Windows (under > > cygwin-bash) and anything else POSIX-ish. > > But on anything POSIX-ish, is it a problem for some files (but not any > directory) in .git is made read-only? Not for me or anyone I personally support. As I suggested to Albert, wrapping a clone in a script with a chmod would solve the problem with minimal work. My own personal issue is convincing people not to clone for every topic branch, but that's unrelated.
RE: [Feature Request] Option to make .git not read-only in cloned repos
On August 25, 2019 3:59 PM, Albert Vaca Cintora wrote: > To: Johannes Sixt > On Sun, Aug 25, 2019 at 7:54 PM Johannes Sixt wrote: > > > > Am 23.08.19 um 22:43 schrieb Albert Vaca Cintora: > > > However, I'm sure that a large percentage of developers out there > > > will agree with me that having to use force (-f) to delete every > > > cloned repo is annoying, and even worse, it creates the bad habit of > > > always force-deleting everything. > > > > IMO, the bad habit is to delete cloned repositories all the time. If > > your workflow necessitates this, then you are doing something wrong. > > Maybe you have an X-Y-problem? > > > > -- Hannes > > There are plenty of valid workflows where one would delete a repo. > > What you suggest is like saying I shouldn't delete pictures from my camera, > because in that case I shouldn't have taken them in the first place. > > Sometimes I clone a repo just to grep for an error string and then I don't > need it anymore, or I clone several repos until I find the one that contains > what I want and delete the rest. Sometimes I want to write a patch for some > software I don't develop regularly so I don't need to keep a clone of it. > > In any case, it would be useful to know the reason those files are read-only > in > the first place. Do you guys know who might know? Why don't you wrap your clone in a script that calls chmod -R u+w .git after the clone? This seems like a pretty trivial approach regardless of your workflow. This works in Linux, Mac, Windows (under cygwin-bash) and anything else POSIX-ish.
RE: Feedback on git switch and git restore
On August 20, 2019 6:56 PM, brian m. carlson wrote: > To: git@vger.kernel.org > Cc: Duy Nguyen > Subject: Feedback on git switch and git restore > > I just wanted to let folks know that I've seen multiple positive comments on > Twitter today (at least 3) about "git switch" and "git restore". Folks seem > to > really like these new commands and are excited about the improved UI. It's been a bit of a mixed bag from the NonStop community so far. Personally, as the platform maintainer, I am very happy with these. Regards, Randall
RE: Only track built files for final output?
On August 20, 2019 1:47 PM, Pratyush Yadav > On 20/08/19 08:21AM, Leam Hall wrote: > > Hey all, a newbie could use some help. > > > > We have some code that generates data files, and as a part of our > > build process those files are rebuilt to ensure things work. This > > causes an issue with branches and merging, as the data files change > > slightly and dealing with half a dozen merge conflicts, for files that > > are in an interim state, is frustrating. The catch is that when the > > code goes to the production state, those files must be in place and current. > > > > We use a release branch, and then fork off that for each issue. > > Testing, and file creation, is a part of the pre-merge process. This > > is what causes the merge conflicts. > > > > Right now my thought is to put the "final" versions of the files in > > some other directory, and put the interim file storage directory in > .gitignore. > > Is there a better way to do this? > > > > My philosophy with Git is to only track files that I need to generate the final > product. I never track the generated files, because I can always get to them > via the tracked "source" files. > > So for example, I was working on a simple parser in Flex and Bison. Flex and > Bison take source files in their syntax, and generate a C file each that is then > compiled and linked to get to the final binary. So instead of tracking the > generated C files, I only tracked the source Flex and Bison files. My build > system can always get me the generated files. > > So in your case, what's wrong with just tracking the source files needed to > generate the other files, and then when you want a release binary, just clone > the repo, run your build system, and get the generated files? > What benefit do you get by tracking the generated files? The benefit of putting final release packages into git is based on the following set of requirements in highly regulated industries: 1. The release artifacts can never change from the point in time at which they are certified as working (a.k.a. passed tests) to the point when they are replaced with other artifacts (a subsequent release). Recompiling is not sufficient as the compilers themselves may change or be compromised. This is an audit requirement. 2. The source commit(s) used to create the release artifacts must be immutable so that the origins of the release artifacts are always known. This is also an audit requirement in regulated industries. 3. Disconnecting the source from the object (as is common in artifact repositories) breaks #2 and allows malicious code injection in after-the-test code reproduction. Variant of #2 but from the security perspective. 4. Metadata on the origin of the release artifacts (the clone URL, the parent commit, the branch, signed commits), are required for forensic analysis of code in a compliance environment. There are other related variants of the above, but those are the essential ones that are generally accepted in financial, insurance, medical device, and industrial applications. Increasingly, food production and distribution sectors are realizing that they are also subject to the above. I sadly cannot cite specific internal regulations or policies for NDA reasons, but hope that others are able to do that. Regards, Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: [ANNOUNCE] Git v2.23.0
On August 16, 2019 5:00 PM, Junio C Hamano wrote: > The latest feature release Git v2.23.0 is now available at the usual places. > It > is comprised of 505 non-merge commits since v2.22.0, contributed by 77 > people, 26 of which are new faces. We are having a transient failure in t0021. It runs fine in isolation but is failing when running inside our Jenkins CI build. This is subtest 15 only. I'm not really going to whine about it this time, but it is strange that it keeps showing up occasionally. We are still passing the test and releasing the binaries.
RE: git switch and restore user interface
On August 19, 2019 5:41 AM, Ed Avis wrote: > To: git@vger.kernel.org > Subject: git switch and restore user interface > > I think it would be helpful for git switch to print a reminder of the old and > new branches. > > Hi, a couple of suggestions for these experimental new commands. Git > switch should print the branch you are leaving: > > % git switch foo > You were previously on branch bar (abcdef). > You are now on branch foo (bcdef0). > > Sometimes I forget what branch I was on before and having it in the terminal > history would help a lot. > > > For git restore, it might be worth splitting the command further, into 'safe > restore' and 'destructive restore'. The safe command would always stop > rather than lose data: > > % git safe-restore . > The following local changes would be overwritten: >Fee.c >Foe.c > Stash them first, or (etc etc). > > The command that unconditionally overwrites working copy changes should > be given a different and more dangerous-sounding name. > > The reason I suggest this is to make sure of a sensible answer to the > newcomer's question: "I just deleted a file by mistake in my working copy, > how do I get it back from git?". Too often at the moment the answer is "git > checkout ." which while correct is also much too dangerous to be a first > resort. There should be an obvious and safe command for restoring missing > files without losing local changes. > > In fact, I'd be quite happy for it to be like git clean, which in the default > configuration requires some flag like -f to make it lose any local changes, > even though the very purpose of git clean is to delete files. I would be happier to have git restore --stash or some configuration option, like restore.stash=auto that has git automatically stash on a restore. But would the stash include everything or just the paths you are restoring? It might be nice to teach git clean the same option. Cheers, Randall
[RFE] Teach hash-object to be able to choose signature types
Hi All, I do not know whether this would be a good enhancement or micro project for someone (maybe me) to take on, but I'm wondering whether it might be a good idea to provide an option to hash-object to select the signature being computed. The use case begins when someone computes an object signature and stores a pre-converted SHA1 value. Then the repository is changed over to SHA256. When hash-object is next called, perhaps in a different clone or some other "next" scenario, the new signature will be SHA256, if I understand this correctly, and from the perspective of the someone in the use case, the signature mismatches. What I am proposing is an option like --signature-type=SHA1|SHA256 or similar as an option to hash-object to allow the non-default signature to be selected explicitly. This is not entirely trivial looking through the code and presumably would require either teaching hash_object_file_literally or having a separate method to do the alternate calculation. Thoughts? Regards, Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: Non-robust lock files in containers can lead to repo corruption
On August 10, 2019 12:06 PM, Gregory Szorc wrote: > I tracked down a source of Git corrupting repositories to lock file design not > being robust when containers / PID namespaces are present. > > In my case, the corruption stemmed from premature release of the `git gc` > lock in the gc.pid file. But since the lock file code for that file is in > gc.c, there > could be other lock files in Git affected by the same design limitation as > well. > > The lock design of gc.pid stores the current hostname and PID of the locking > process in the file. If another process comes along and its hostname matches > the stored hostname, it checks to see if the listed PID exists. If the PID is > missing, it assumes the lock is stale and releases the lock. > > A limitation with this approach is it isn't robust in the presence of > containers > / PID namespaces. In containers, it is common for the hostname to match > the container host's hostname. Or the hostname will be static string. In > Kubernetes, all containers within a pod share the same hostname. Containers > (almost always) run in separate PID namespaces, so PIDs from outside the > container aren't visible to the container itself. > This means that if e.g. 2 `git gc` processes are running with the same > hostname in separate containers / PID namespaces, Git could prematurely > release the lock file because it thinks the "other" PID is dead and repo > corruption could ensue due to the 2 `git gc` processes racing with each other. > > The on-disk format of lock files obviously needs to be backwards compatible > with older clients. One backwards compatible solution is to append > something to the hostname to disambiguate containers / PID namespaces. > Mercurial appends the current PID namespace identifier to the hostname [1] > and my experience is that this is sufficient to mitigate the issue. It is > possible > more robust solutions are achievable. While I like the idea personally, many platforms, including NonStop (TNS/E), do not support pid namespaces. In particular setns(2) may not be implemented. Please make sure that any changes detect this condition properly and omit the use of namespaces. Regards, Randall
RE: What's cooking in git.git (Jul 2019, #06; Thu, 25)
On August 11, 2019 8:39 PM, Junio C Hamano wrote: > Jeff King writes: > > > IMHO scripting around "action" commands like checkout is less bad than > > around "output" commands like log. The general action of "switch to > > this branch" is unlikely to be changed much over the years (or via > > config), but the output of log, etc, is. > > > > There are no guarantees, of course, but I imagine that the tradeoff in > > simplicity of using git-switch versus manually reimplementing it is > > probably a good one for many scripts. > > Another reason why scripting around "action" may be OK is that most of the > time scriptors would want to (blindly) adopt improvements made to the > underly ing command anyway. If you scripted around "git checkout" before > we introduced multiple worktree feature where a branch that is already > active in another worktree is protected from getting checked out elsewhere, > your script will automatically get that protection (and more importantly, the > error message given as an explanation to the end users) for free. Of course > your script must be prepared to react correctly to a failure from "git > checkout", but that goes without saying for any command you invoke in your > script. That would describe my subcommunity pretty accurately đ Thanks, Randall
RE: [ANNOUNCE] Git v2.23.0-rc2
On August 9, 2019 5:24 PM, I wrote: > On 12:29 Fri 09 Aug 2019, Junio C Hamano wrote: > > >A release candidate Git v2.23.0-rc2 is now available for testing at > > >the usual places. It is comprised of 483 non-merge commits since > > >v2.22.0, contributed by 67 people, 24 of which are new faces. > > > > > >The tarballs are found at: > > > > > >https://www.kernel.org/pub/software/scm/git/testing/ > *big-snip* > > NonStop platform testing is in progress. NonStop platform testing passed. Thanks all.
RE: [ANNOUNCE] Git v2.23.0-rc2
On 12:29 Fri 09 Aug 2019, Junio C Hamano wrote: > >A release candidate Git v2.23.0-rc2 is now available for testing at the > >usual places. It is comprised of 483 non-merge commits since v2.22.0, > >contributed by 67 people, 24 of which are new faces. > > > >The tarballs are found at: > > > >https://www.kernel.org/pub/software/scm/git/testing/ *big-snip* NonStop platform testing is in progress.
RE: What's cooking in git.git (Jul 2019, #06; Thu, 25)
On August 9, 2019 1:45 PM, Junio C Hamano wrote: > "Randall S. Becker" writes: > > > On 01 Aug 2019 13:05:12, Junio wrote: > >> >> *snip* > > > > I think this got missed in the shuffle, but I am getting questions > > about the topic from my own team that I cannot answer. > > > > I noticed that the switch and restore commands are now available in > > 2.23.0 but are not discussed in recent What's Cooking or Git Rev (or I > > blithely missed them). The question from my team is what are the plans > > for deprecating checkout. They have loads of scripts and want to plan > > for moving over. > > The two new commands were done in response to a common "checkout > does two different things, either checkout a branch in order to start working > on it, or checkout paths into the current workspace to work on them" > complaint. Those who are used to and are OK with the "git" command that > changes behaviour based on the rest of args (i.e. > "checkout " and "checkout [] " are the > ways to obtain these two behaviours) can safely keep using the command > they are familiar with. > > I do not think there currently is any plan to deprecate checkout. Thanks.
RE: What's cooking in git.git (Jul 2019, #06; Thu, 25)
On August 9, 2019 12:29 PM, Jeff King wrote: > On Fri, Aug 09, 2019 at 10:06:06AM -0400, Randall S. Becker wrote: > > > On 01 Aug 2019 13:05:12, Junio wrote: > > > >> *snip* > > > > I think this got missed in the shuffle, but I am getting questions about the > topic from my own team that I cannot answer. > > > > I noticed that the switch and restore commands are now available in > > 2.23.0 but are not discussed in recent What's Cooking or Git Rev (or I > > blithely missed them). The question from my team is what are the plans > > for deprecating checkout. They have loads of scripts and want to plan > > for moving over. > > I don't know of any plans for checkout in particular, but I think the docs for > restore/switch make it clear that it's way too early to start scripting around > them: > > $ git grep EXPERIMENTAL Documentation/ > Documentation/git-restore.txt:THIS COMMAND IS EXPERIMENTAL. THE > BEHAVIOR MAY CHANGE. > Documentation/git-switch.txt:THIS COMMAND IS EXPERIMENTAL. THE > BEHAVIOR MAY CHANGE. Thanks Peff. Good guidance. I did not notice that part. Appreciations, Randall
RE: What's cooking in git.git (Jul 2019, #06; Thu, 25)
On 01 Aug 2019 13:05:12, Junio wrote: > >> *snip* I think this got missed in the shuffle, but I am getting questions about the topic from my own team that I cannot answer. I noticed that the switch and restore commands are now available in 2.23.0 but are not discussed in recent What's Cooking or Git Rev (or I blithely missed them). The question from my team is what are the plans for deprecating checkout. They have loads of scripts and want to plan for moving over. Regards and Thanks, Randall
[Question] git checkout lifespan
Hi All, I don't recall when this was previously discussed, but the timing is relevant at 2.23.0. With switch and restore commands coming in this release, I was wondering how long checkout will be provided for compatibility - or if it will be deprecated at all. I assume that enhancements should only go to switch and restore, but what of fixes? Should they go to only the new commands or both? Thanks, Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: [PATCH 0/3] --end-of-options marker
On August 6, 2019 1:38 PM, Jeff King wrote: > To: Randall S. Becker > Cc: 'Junio C Hamano' ; git@vger.kernel.org > Subject: Re: [PATCH 0/3] --end-of-options marker > > On Tue, Aug 06, 2019 at 12:36:26PM -0400, Randall S. Becker wrote: > > > > > This series provides an alternative to "--" to stop option parsing > > > > without indicating that further arguments are pathspecs. > > > > Would this offer the opportunity to, in the long term, supply options > > to external diff engines, for example? > > > > Something like git diff --end-of-options --diff-opt1 --diff-opt2 -- a > > b > > I'd expect that to interpret "--diff-opt1" and "--diff-opt2" as non-option > arguments, which in the context of git-diff means endpoints of the diff. > > So no, I don't think you can use it like you're asking here. > > > I'm just noodling here, wondering why otherwise > > > > git rev-list --max-parents=4 -- --count docs/ > > > > does not work. I thought -- was pretty specific in terms of turning > > off interpretation. So is it not a defect that --count is being interpreted? > > The command-line above means that "--count" is interpreted > (unambiguously) as a path. The problem is that if you want it to be > interpreted as a starting point for traversal, then it must come _before_ the > "--". > > > I have a fear for all my sub-teams who script with the assumption that > > -- has a specific meaning of stopping interpretation. > > Nothing about "--" is changed by my series; it will still stop option > interpretation in rev-list and in other commands. But as before, rev-list (and > other Git commands that use the revision.c parser) use it to separate > revisions and pathspecs. That's unlike how most other programs use "--", but > that ship sailed for Git in 2005. Thanks for the explanation. Randall
RE: [PATCH 0/3] --end-of-options marker
On August 6, 2019 12:25 PM, Junio wrote: > Jeff King writes: > > > It's hard for scripted uses of rev-list, etc, to avoid option > > injection from untrusted arguments, because revision arguments must > > come before any "--" separator. I.e.: > > > > git rev-list "$revision" -- "$path" > > > > might mistake "$revision" for an option (with rev-list, that would > > make it an error, but something like git-log would default to HEAD). > > Just to make sure I understand what I just read, let me paraphrase. > We would want to accept > > git rev-list --max-parents=4 \ > --end-of-options \ > --count -- docs/ > > so that '--count' would go thru the usual "as we have -- later, it must be a rev > and we do not even disambiguate. What does get_sha1() say it is?" and > "docs/" would be taken as a pathspec. > "git rev-list --max-parents=4 --count -- docs/" would have treated "--count" > as an option and would error out due to lack of any starting revision. > > On the other hand, "git log --count -- docs/" would take "--count" > as an option, but does not complain about lack of any revs. It just starts > digging from HEAD and ends up ignoring the "--count" branch (or is this > feature meant to support tags? As far as I recall, we do not allow branch > names that begin with a dash). > > > This series provides an alternative to "--" to stop option parsing > > without indicating that further arguments are pathspecs. Would this offer the opportunity to, in the long term, supply options to external diff engines, for example? Something like git diff --end-of-options --diff-opt1 --diff-opt2 -- a b I'm just noodling here, wondering why otherwise git rev-list --max-parents=4 -- --count docs/ does not work. I thought -- was pretty specific in terms of turning off interpretation. So is it not a defect that --count is being interpreted? I have a fear for all my sub-teams who script with the assumption that -- has a specific meaning of stopping interpretation. Slightly confused, Randall > > > > [1/3]: revision: allow --end-of-options to end option parsing > > [2/3]: parse-options: allow --end-of-options as a synonym for "--" > > [3/3]: gitcli: document --end-of-options > > > > Documentation/gitcli.txt | 6 ++ > > parse-options.c | 3 ++- > > revision.c | 8 +++- > > t/t0040-parse-options.sh | 7 +++ > > t/t4202-log.sh | 7 +++ > > t/t6000-rev-list-misc.sh | 8 > > 6 files changed, 37 insertions(+), 2 deletions(-)
Final test result git 2.23.0.rc0 NonStop TNS/E platform
Hi all, The test finally finished, and the only failures where: t0016 (reported), t0066 (reported), t9001 (no valid sendmail, expected to fail), t9020 (no SVN expected to fail) Looking forward to rc1. Cheers, Randall
RE: [ANNOUNCE] Git v2.23.0-rc0 - Initial test failures on NonStop
On July 30, 2019 3:50 PM, Todd Zullinger wrote: > To: Randall S. Becker > Cc: 'Junio C Hamano' ; Christian Couder > ; SZEDER GĂĄbor ; Jeff > King ; git@vger.kernel.org; git- > packag...@googlegroups.com > Subject: Re: [ANNOUNCE] Git v2.23.0-rc0 - Initial test failures on NonStop > > Hi, > > [added Christian, SZEDER, and Jeff to Cc as author and helpers on the newly- > added t0016-oidmap] > > Randall S. Becker wrote: > > A preview of the situation with testing 2.23.0.rc0 on NonStop is not > > great. We have had some new failures right off the bat on our NonStop > > platforms. This is a preview of what we find within the first bit of > > testing. The tests run a long time, so more to come. > > > > t0016: oidmap > > > > Subtest 6 had an ordering issue. We do not know whether the problem is > > the code or the test result not keeping up with the code changes. > > > > --- expect 2019-07-30 16:56:36 + > > +++ actual 2019-07-30 16:56:36 + > > @@ -1,6 +1,6 @@ > > NULL > > NULL > > NULL > > +7c7cd714e262561f73f3079dfca4e8724682ac21 3 > > 139b20d8e6c5b496de61f033f642d0e3dbff528d 2 > > d79ce1670bdcb76e6d1da2ae095e890ccb326ae9 1 > > -7c7cd714e262561f73f3079dfca4e8724682ac21 3 > > I hit the same failure while building for Fedora on the s390x architecture. I > have not dug into it much yet, but perhaps this is an endianess issue? My platforms are BIGendian, so perhaps that's it. The bucket calculation uses bit arithmetic so that could contribute.
RE: [ANNOUNCE] Git v2.23.0-rc0 - Initial test failures on NonStop
On July 30, 2019 3:45 PM, Jeff King wrote: > To: Randall S. Becker > Cc: 'Junio C Hamano' ; git@vger.kernel.org; git- > packag...@googlegroups.com > Subject: Re: [ANNOUNCE] Git v2.23.0-rc0 - Initial test failures on NonStop > > On Tue, Jul 30, 2019 at 01:08:37PM -0400, Randall S. Becker wrote: > > > t0016: oidmap > > > > Subtest 6 had an ordering issue. We do not know whether the problem is > the code or the test result not keeping up with the code changes. > > --- expect 2019-07-30 16:56:36 + > > +++ actual 2019-07-30 16:56:36 + > > @@ -1,6 +1,6 @@ > > NULL > > NULL > > NULL > > +7c7cd714e262561f73f3079dfca4e8724682ac21 3 > > 139b20d8e6c5b496de61f033f642d0e3dbff528d 2 > > d79ce1670bdcb76e6d1da2ae095e890ccb326ae9 1 > > -7c7cd714e262561f73f3079dfca4e8724682ac21 3 > > This one is very curious. It's iterating a hash, which _seems_ like it would > produce non-deterministic output. But neither this test nor the hashmap test > it is based on sorts the output, and they pass consistently for me. I assume > that's because while hash ordering is not guaranteed, it happens to be the > same as long the pattern of inserts is the same (with our implementation, > which does not do any hash randomization). > > But I am scratching my head as to what could be different on your platform > that would cause a different ordering (especially when the hashmap test this > is based on doesn't get one!). > > I guess in some sense it may not be worth tracking down, and we should just > sort the output of a hash iteration unconditionally when comparing it to > expected output. Definitely a head scratcher. Is it possible that the bucket() function, which uses key->hash & (map->tablesize - 1); might better use key->hash % (map->tablesize - 1); I have not seen a bucket computation done this way before so that surprised me, not that it should make a difference on hash-determinism. The only thing that might is an uninitialized stack variable, which on this platform's C compiler will not initialize. Global statics are always 0 unless otherwise specified, but I'm not sure about stack-local (but there's nothing wrong I can see in hashmap.c on those points. Sorting the output seems like a safe option, providing that the hash is itself demonstrably solid otherwise. Cheers, Randall
RE: [ANNOUNCE] Git v2.23.0-rc0 - Initial test failures on NonStop
On July 30, 2019 1:32 PM, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> > t0066: dir-iterator
> >
> > Subtest 4 depends on a non-portable error code. ENOENT is not
> guaranteed ...
> > Subtest 5 also depends on a non-portable error code. ENOTDIR is not
gua...
>
> Yikes, and sorry. I've become somewhat complacent after relying on how
> good our other reviewers are, pretty much ignored the new code in fringes
> like t/helper/, and failed catch an obvious amateurish mistake like this
one.
>
> I do not think of a portable way to map an int ENOENT to a string
"ENOENT",
> but there are only only two errors test-dir-iterator test code cares
about, so
> perhaps a patch like the following may be sufficient.
>
> I wonder if a tool like sparse can help us catch a pattern that feeds
errno to
> "%d" format.
>
> t/helper/test-dir-iterator.c | 11 ++-
> t/t0066-dir-iterator.sh | 4 ++--
> 2 files changed, 12 insertions(+), 3 deletions(-)
>
> diff --git a/t/helper/test-dir-iterator.c b/t/helper/test-dir-iterator.c
index
> a5b96cb0dc..c7c30664da 100644
> --- a/t/helper/test-dir-iterator.c
> +++ b/t/helper/test-dir-iterator.c
> @@ -4,6 +4,15 @@
> #include "iterator.h"
> #include "dir-iterator.h"
>
> +static const char *error_name(int error_number) {
> + switch (error_number) {
> + case ENOENT: return "ENOENT";
> + case ENOTDIR: return "ENOTDIR";
> + default: return "ESOMETHINGELSE";
> + }
> +}
> +
> /*
> * usage:
> * tool-test dir-iterator [--follow-symlinks] [--pedantic] directory_path
@@ -
> 31,7 +40,7 @@ int cmd__dir_iterator(int argc, const char **argv)
> diter = dir_iterator_begin(path.buf, flags);
>
> if (!diter) {
> - printf("dir_iterator_begin failure: %d\n", errno);
> + printf("dir_iterator_begin failure: %s\n",
error_name(errno));
> exit(EXIT_FAILURE);
> }
>
> diff --git a/t/t0066-dir-iterator.sh b/t/t0066-dir-iterator.sh index
> 9354d3f1ed..92910e4e6c 100755
> --- a/t/t0066-dir-iterator.sh
> +++ b/t/t0066-dir-iterator.sh
> @@ -55,13 +55,13 @@ test_expect_success 'dir-iterator should list files in
> the correct order' '
> test_expect_success 'begin should fail upon inexistent paths' '
> test_must_fail test-tool dir-iterator ./inexistent-path \
> >actual-inexistent-path-output &&
> - echo "dir_iterator_begin failure: 2" >expected-inexistent-path-
> output &&
> + echo "dir_iterator_begin failure: ENOENT"
> +>expected-inexistent-path-output &&
> test_cmp expected-inexistent-path-output actual-inexistent-path-
> output '
>
> test_expect_success 'begin should fail upon non directory paths' '
> test_must_fail test-tool dir-iterator ./dir/b >actual-non-dir-output
> &&
> - echo "dir_iterator_begin failure: 20" >expected-non-dir-output &&
> + echo "dir_iterator_begin failure: ENOTDIR" >expected-non-dir-
> output &&
> test_cmp expected-non-dir-output actual-non-dir-output '
>
Seems reasonable. Better than trying to use strerror(), which previously
(I'm not sure whether it was this project or another) had a similar mapping
issue because the error text does not match either.
RE: [ANNOUNCE] Git v2.23.0-rc0 - Initial test failures on NonStop
Hi All, A preview of the situation with testing 2.23.0.rc0 on NonStop is not great. We have had some new failures right off the bat on our NonStop platforms. This is a preview of what we find within the first bit of testing. The tests run a long time, so more to come. t0016: oidmap Subtest 6 had an ordering issue. We do not know whether the problem is the code or the test result not keeping up with the code changes. --- expect 2019-07-30 16:56:36 + +++ actual 2019-07-30 16:56:36 + @@ -1,6 +1,6 @@ NULL NULL NULL +7c7cd714e262561f73f3079dfca4e8724682ac21 3 139b20d8e6c5b496de61f033f642d0e3dbff528d 2 d79ce1670bdcb76e6d1da2ae095e890ccb326ae9 1 -7c7cd714e262561f73f3079dfca4e8724682ac21 3 t0066: dir-iterator Subtest 4 depends on a non-portable error code. ENOENT is not guaranteed to be the same on all systems. It is 4002 on NonStop and 2 on many other machines. --- expected-inexistent-path-output 2019-07-30 16:58:51 + +++ actual-inexistent-path-output 2019-07-30 16:58:50 + @@ -1 +1 @@ -dir_iterator_begin failure: 2 +dir_iterator_begin failure: 4002 Subtest 5 also depends on a non-portable error code. ENOTDIR is not guaranteed to be the same on all systems. It is 4020 on NonStop and 20 on many other machines. --- expected-non-dir-output 2019-07-30 16:58:51 + +++ actual-non-dir-output 2019-07-30 16:58:51 + @@ -1 +1 @@ -dir_iterator_begin failure: 20 +dir_iterator_begin failure: 4020 Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: [Question] Diff text filters and git add
On July 9, 2019 5:51 PM, Peff wrote: > To: Randall S. Becker > Cc: git@vger.kernel.org > Subject: Re: [Question] Diff text filters and git add > > On Tue, Jul 09, 2019 at 05:43:05PM -0400, Randall S. Becker wrote: > > > I am trying to do something a bit strange and wonder about the best > > way to go. I have a text filter that presents content of very special > > binary file formats using textconv. What I am wondering is whether > > using the textconv mechanism is sufficient to have git calculate the > > file signature or whether I need to use an external diff engine, so > > that git add behaves in a stable manner (i.e., does git internally use > > the textconv mechanism for evaluating whether a file changed or > > whether the external diff engine is required, or whether this is even > possible at all). > > No, textconv only applies when generating a diff to output, and will never > impact what's stored in Git. > > It sounds like you might want a clean filter instead, to sanitize the file > contents as they come into Git (and perhaps a matching smudge filter to > convert back to the working-tree version if necessary). > > You're talking about "the diff engine" here, but note that git-add would never > do a diff at all. It cares only about full sha1s (and optimizes out > re-computing > the sha1 on each invocation by using stat data). So outside of clean/smudge, > there's nothing else going on. Thanks. I can script this instead. Will do an external diff then --assume-unchanged when I detect an equivalence. Appreciate the advice and info, Randall
[Question] Diff text filters and git add
Hi all, I am trying to do something a bit strange and wonder about the best way to go. I have a text filter that presents content of very special binary file formats using textconv. What I am wondering is whether using the textconv mechanism is sufficient to have git calculate the file signature or whether I need to use an external diff engine, so that git add behaves in a stable manner (i.e., does git internally use the textconv mechanism for evaluating whether a file changed or whether the external diff engine is required, or whether this is even possible at all). The basic use case is that there is a timestamp embedded in the binary file that I want to forever ignore when committing. I only need this done on one specific machine, which is under Jenkins control, so it's not something developers would deal with at all (so the filter config is in one place). When the binary generator runs, if the two file images are "similar enough" (as in: the same except for the generated timestamp, and a couple of other annoying bits of metadata), I want git to think that they are the same in an automated way, so that when I am constructing commits, I do not want what would be considered a duplicate of what is essentially the same file. Sadly, I cannot modify the generator, so I'm stuck with the files being wonky. I also cannot run the generator anywhere downstream, so doing so on the deployment engine is also not an option (don't ask, the generator is limited on where it can be run). Suggestions are welcome, please. Thanks, Randall
RE: [Patch 0/5] Add exclusions for tests requiring cvs where cvs is not installed
On June 13, 2019 3:31 PM, I wrote: > On June 13, 2019 3:07 PM, Peff wrote: > > On Thu, Jun 13, 2019 at 02:53:08PM -0400, randall.s.bec...@rogers.com > > wrote: > > > > > From: "Randall S. Becker" > > > > > > t9600 to t9604 currently depend on cvs to function correctly, > > > otherwise all of those tests fail. This patch follows an existing > > > pattern of from the t9400 series by attempting to run cvs without > > > arguments, which succeeds if installed, and skipping the test if the > > > command fails. > > > > Hrm. I don't have cvs installed, and those tests are properly skipped for > > me. > > That's because they include lib-cvs.sh, which has: > > > > if ! type cvs >/dev/null 2>&1 > > then > > skip_all='skipping cvsimport tests, cvs not found' > > test_done > > fi > > > > Why doesn't that work for you? Does the "type" check not work (e.g., > > you have something called "cvs" but it does not behave as we expect)? > > If so, then it sounds like we just need to harmonize that with the other > checks. > > > > It also sounds like the t9400 tests could be using lib-cvs to avoid > > duplicating logic, though it might need some refactoring (they don't > > need cvsps, for example). > > The t9400 tests use the same technique as I used - and I mistakenly trusted > it. > The type check does not fail. > > if ! type cvs >/dev/null 2>&1 > then > echo "oops" > fi > > does not print "oops". type is reporting $?=0 and a legitimate file in > /usr/local/bin/cvs. Confusingly, t9400 skips, but type reports a valid path. I > think the test done in the t9400 series is not correct. > > cvs >/dev/null 2>&1 on the platform causes $?=255, while a blah >/dev/null > 2>&1 reports $?=127. > > There is something else going on causing the cvs-related tests to fail that > this > patch might be hiding. We do have cvsps so I'm now much more confused by > the whole thing. > > Let's drop this patch for now. I was premature on this patch and need to dig > deeper as to what is going on. We do not need the patch. The situation was caused by an old version of CVS (pre 1.11) that was causing t9600... to fail. The message was buried under --verbose. I ported CVS 1.11.23 and CVS tests are now working. My bad. Cheers, Randall
RE: [Patch 0/5] Add exclusions for tests requiring cvs where cvs is not installed
On June 13, 2019 3:07 PM, Peff wrote: > On Thu, Jun 13, 2019 at 02:53:08PM -0400, randall.s.bec...@rogers.com > wrote: > > > From: "Randall S. Becker" > > > > t9600 to t9604 currently depend on cvs to function correctly, > > otherwise all of those tests fail. This patch follows an existing > > pattern of from the t9400 series by attempting to run cvs without > > arguments, which succeeds if installed, and skipping the test if the > > command fails. > > Hrm. I don't have cvs installed, and those tests are properly skipped for me. > That's because they include lib-cvs.sh, which has: > > if ! type cvs >/dev/null 2>&1 > then > skip_all='skipping cvsimport tests, cvs not found' > test_done > fi > > Why doesn't that work for you? Does the "type" check not work (e.g., you > have something called "cvs" but it does not behave as we expect)? If so, then > it sounds like we just need to harmonize that with the other checks. > > It also sounds like the t9400 tests could be using lib-cvs to avoid > duplicating > logic, though it might need some refactoring (they don't need cvsps, for > example). The t9400 tests use the same technique as I used - and I mistakenly trusted it. The type check does not fail. if ! type cvs >/dev/null 2>&1 then echo "oops" fi does not print "oops". type is reporting $?=0 and a legitimate file in /usr/local/bin/cvs. Confusingly, t9400 skips, but type reports a valid path. I think the test done in the t9400 series is not correct. cvs >/dev/null 2>&1 on the platform causes $?=255, while a blah >/dev/null 2>&1 reports $?=127. There is something else going on causing the cvs-related tests to fail that this patch might be hiding. We do have cvsps so I'm now much more confused by the whole thing. Let's drop this patch for now. I was premature on this patch and need to dig deeper as to what is going on. Randall
[Patch 1/5] t9600-cvsimport: exclude test if cvs is not installed
From: "Randall S. Becker" The t9600-cvsimport test requires the cvs package to be installed on the system on which the test is being run. The test will fail if cvs is not installed. The patch checks that cvs is installed by running the object without arguments, which should complete successfully if available. Signed-off-by: Randall S. Becker --- t/t9600-cvsimport.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/t/t9600-cvsimport.sh b/t/t9600-cvsimport.sh index 251fdd66c4..d6bf38918b 100755 --- a/t/t9600-cvsimport.sh +++ b/t/t9600-cvsimport.sh @@ -3,6 +3,13 @@ test_description='git cvsimport basic tests' . ./lib-cvs.sh +cvs >/dev/null 2>&1 +if test $? -ne 1 +then + skip_all='skipping git-cvsimport tests, cvs not found' + test_done +fi + if ! test_have_prereq NOT_ROOT; then skip_all='When cvs is compiled with CVS_BADROOT commits as root fail' test_done -- 2.22.0
[Patch 2/5] t9601-cvsimport-vendor-branch: exclude test if cvs is not installed
From: "Randall S. Becker" The t9601-cvsimport-vendor-branch test requires the cvs package to be installed on the system on which the test is being run. The test will fail if cvs is not installed. The patch checks that cvs is installed by running the object without arguments, which should complete successfully if available. Signed-off-by: Randall S. Becker --- t/t9601-cvsimport-vendor-branch.sh | 8 1 file changed, 8 insertions(+) diff --git a/t/t9601-cvsimport-vendor-branch.sh b/t/t9601-cvsimport-vendor-branch.sh index 827d39f5bf..a473f07d2d 100755 --- a/t/t9601-cvsimport-vendor-branch.sh +++ b/t/t9601-cvsimport-vendor-branch.sh @@ -32,8 +32,16 @@ # tag has been removed. test_description='git cvsimport handling of vendor branches' + . ./lib-cvs.sh +cvs >/dev/null 2>&1 +if test $? -ne 1 +then + skip_all='skipping git-cvsimport tests, cvs not found' + test_done +fi + setup_cvs_test_repository t9601 test_expect_success PERL 'import a module with a vendor branch' ' -- 2.22.0
[Patch 4/5] t9603-cvsimport-patchsets: exclude test if cvs is not installed
From: "Randall S. Becker" The t9603-cvsimport-patchsets test requires the cvs package to be installed on the system on which the test is being run. The test will fail if cvs is not installed. The patch checks that cvs is installed by running the object without arguments, which should complete successfully if available. Signed-off-by: Randall S. Becker --- t/t9603-cvsimport-patchsets.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/t/t9603-cvsimport-patchsets.sh b/t/t9603-cvsimport-patchsets.sh index 3e64b11eac..354cd66400 100755 --- a/t/t9603-cvsimport-patchsets.sh +++ b/t/t9603-cvsimport-patchsets.sh @@ -14,6 +14,13 @@ test_description='git cvsimport testing for correct patchset estimation' . ./lib-cvs.sh +cvs >/dev/null 2>&1 +if test $? -ne 1 +then + skip_all='skipping git-cvsimport tests, cvs not found' + test_done +fi + setup_cvs_test_repository t9603 test_expect_failure PERL 'import with criss cross times on revisions' ' -- 2.22.0
[Patch 0/5] Add exclusions for tests requiring cvs where cvs is not installed
From: "Randall S. Becker" t9600 to t9604 currently depend on cvs to function correctly, otherwise all of those tests fail. This patch follows an existing pattern of from the t9400 series by attempting to run cvs without arguments, which succeeds if installed, and skipping the test if the command fails. Randall S. Becker (5): t9600-cvsimport: exclude test if cvs is not installed t9601-cvsimport-vendor-branch: exclude test if cvs is not installed t9602-cvsimport-branches-tags: exclude test if cvs is not installed t9603-cvsimport-patchsets: exclude test if cvs is not installed t9604-cvsimport-timestamps: exclude test if cvs is not installed t/t9600-cvsimport.sh | 7 +++ t/t9601-cvsimport-vendor-branch.sh | 8 t/t9602-cvsimport-branches-tags.sh | 7 +++ t/t9603-cvsimport-patchsets.sh | 7 +++ t/t9604-cvsimport-timestamps.sh| 7 +++ 5 files changed, 36 insertions(+) -- 2.22.0
[Patch 3/5] t9602-cvsimport-branches-tags: exclude test if cvs is not installed
From: "Randall S. Becker" The t9602-cvsimport-branches-tags test requires the cvs package to be installed on the system on which the test is being run. The test will fail if cvs is not installed. The patch checks that cvs is installed by running the object without arguments, which should complete successfully if available. Signed-off-by: Randall S. Becker --- t/t9602-cvsimport-branches-tags.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/t/t9602-cvsimport-branches-tags.sh b/t/t9602-cvsimport-branches-tags.sh index e1db323f54..52e8507725 100755 --- a/t/t9602-cvsimport-branches-tags.sh +++ b/t/t9602-cvsimport-branches-tags.sh @@ -6,6 +6,13 @@ test_description='git cvsimport handling of branches and tags' . ./lib-cvs.sh +cvs >/dev/null 2>&1 +if test $? -ne 1 +then + skip_all='skipping git-cvsimport tests, cvs not found' + test_done +fi + setup_cvs_test_repository t9602 test_expect_success PERL 'import module' ' -- 2.22.0
[Patch 5/5] t9604-cvsimport-timestamps: exclude test if cvs is not installed
From: "Randall S. Becker" The t9604-cvsimport-timestamps test requires the cvs package to be installed on the system on which the test is being run. The test will fail if cvs is not installed. The patch checks that cvs is installed by running the object without arguments, which should complete successfully if available. Signed-off-by: Randall S. Becker --- t/t9604-cvsimport-timestamps.sh | 7 +++ 1 file changed, 7 insertions(+) diff --git a/t/t9604-cvsimport-timestamps.sh b/t/t9604-cvsimport-timestamps.sh index 2ff4aa932d..1fbbd179c1 100755 --- a/t/t9604-cvsimport-timestamps.sh +++ b/t/t9604-cvsimport-timestamps.sh @@ -3,6 +3,13 @@ test_description='git cvsimport timestamps' . ./lib-cvs.sh +cvs >/dev/null 2>&1 +if test $? -ne 1 +then + skip_all='skipping git-cvsimport tests, cvs not found' + test_done +fi + setup_cvs_test_repository t9604 test_expect_success PERL 'check timestamps are UTC (TZ=CST6CDT)' ' -- 2.22.0
RE: [ANNOUNCE] Git v2.22.0
On Friday, June 7, 2019 5:31 PM, Junio C Hamano wrote: > The latest feature release Git v2.22.0 is now available at the > usual places. It is comprised of 745 non-merge commits since > v2.21.0, contributed by 74 people, 18 of which are new faces. Report from NonStop tests: t7519 subtest 25 still fails on first execution but not on second. t9001 subtests 33, 82, 118, 119, 146 fail. We have no normal sendmail on platform. t9020, t9600, t9601, t9602 all fail - we have no SVN. I may be able to handle exclusions for the next release. So essentially, no change from previous releases other than t7519 being wonky. This is a pass. Thanks for all hard work from the team. Regards, Randall
RE: [ANNOUNCE] Git v2.22.0-rc3
On Monday, June 3, 2019 10:14 AM, I wrote: > On Monday, June 3, 2019 9:50 AM, Johannes Schindelin wrote: > > To: Randall S. Becker > > Cc: 'Junio C Hamano' ; git@vger.kernel.org > > Subject: RE: [ANNOUNCE] Git v2.22.0-rc2 > > > > Hi Randall, > > > > On Sun, 2 Jun 2019, Randall S. Becker wrote: > > > > > Just a few small nits from RC2 test results on the NonStop TNS/E > > > platform: > > > > > > 1. t0021 subtest 15 is being flakey. It fails on the first run (make > > > -k > > > test) but succeeds when run in isolation. This is new on the NonStop > > > TNS/E platform. t0021 has been a bit flakey in the past, but not > > > recently. Just thought I'd mention it. It's only slightly > > > disconcerting because I make very heavy use of smudge filters but > > > since it runs fine in isolation, I'm going to assume it is fine. We > > > had one unsubstantiated report of an occasional misfire of smudge > > > filters, but no substantive evidence at this point to reproduce the > situation. > > > > t0021.15 is indeed flaky, and not only for NonStop. It is so flaky, > > even, > that I > > opened https://github.com/gitgitgadget/git/issues/241 > > Thanks. > > > > 2. t7519 subtest 25 still does not pass (previously reported for > > > RC1) when run via "make -k test" the first time. This runs > > > successfully when run in isolation or the second time. > > > > I offered a fix for that in js/fsmonitor-unflake, and it already made > > it > into > > `next` (and hopefully into v2.22.0) as you can see here: > > https://github.com/gitgitgadget/git/commit/b5a81697520 (look for the > > branch symbol below the commit message). > > I'll keep an eye out for it. We are good with RC2 anyway. > > > > 3. t9001, t9020, t9600, t9601, t9602, t9604, fail, but should not > > > run on platform (not new, just a reminder). We do not have sendmail > > > or subversion. > > > > At least for Subversion, this should be detected. For send-email, I > > don't know... There *was* a bug in t9001 where it failed to mark a > > send-email tests cases with the `PERL` prerequisite, but that was > > fixed, and I guess > you > > have Perl anyway? > > Yes, we do have Perl on the box. However, the send-email functions do not > work - probably missing modules. As far as SVN goes, we have the git SVN > modules, but not the actual SVM modules in our Perl. There has been some > effort to port those, but we have had CPAN issues for a while now. I am > trying to find a resource to help with porting - personally, I could really use > the SVN module to allow svn2git to function on box. That would make my > life a whole lot easier. RC3 shows no new breaks on NonStop. We are good with approving this one. Kind Regards, Randall
RE: [ANNOUNCE] Git v2.22.0-rc2
On Monday, June 3, 2019 9:50 AM, Johannes Schindelin wrote: > To: Randall S. Becker > Cc: 'Junio C Hamano' ; git@vger.kernel.org > Subject: RE: [ANNOUNCE] Git v2.22.0-rc2 > > Hi Randall, > > On Sun, 2 Jun 2019, Randall S. Becker wrote: > > > Just a few small nits from RC2 test results on the NonStop TNS/E > > platform: > > > > 1. t0021 subtest 15 is being flakey. It fails on the first run (make > > -k > > test) but succeeds when run in isolation. This is new on the NonStop > > TNS/E platform. t0021 has been a bit flakey in the past, but not > > recently. Just thought I'd mention it. It's only slightly > > disconcerting because I make very heavy use of smudge filters but > > since it runs fine in isolation, I'm going to assume it is fine. We > > had one unsubstantiated report of an occasional misfire of smudge > > filters, but no substantive evidence at this point to reproduce the situation. > > t0021.15 is indeed flaky, and not only for NonStop. It is so flaky, even, that I > opened https://github.com/gitgitgadget/git/issues/241 Thanks. > > 2. t7519 subtest 25 still does not pass (previously reported for RC1) > > when run via "make -k test" the first time. This runs successfully > > when run in isolation or the second time. > > I offered a fix for that in js/fsmonitor-unflake, and it already made it into > `next` (and hopefully into v2.22.0) as you can see here: > https://github.com/gitgitgadget/git/commit/b5a81697520 (look for the > branch symbol below the commit message). I'll keep an eye out for it. We are good with RC2 anyway. > > 3. t9001, t9020, t9600, t9601, t9602, t9604, fail, but should not run > > on platform (not new, just a reminder). We do not have sendmail or > > subversion. > > At least for Subversion, this should be detected. For send-email, I don't > know... There *was* a bug in t9001 where it failed to mark a send-email > tests cases with the `PERL` prerequisite, but that was fixed, and I guess you > have Perl anyway? Yes, we do have Perl on the box. However, the send-email functions do not work - probably missing modules. As far as SVN goes, we have the git SVN modules, but not the actual SVM modules in our Perl. There has been some effort to port those, but we have had CPAN issues for a while now. I am trying to find a resource to help with porting - personally, I could really use the SVN module to allow svn2git to function on box. That would make my life a whole lot easier. Cheers, Randall
RE: [ANNOUNCE] Git v2.22.0-rc2
Just a few small nits from RC2 test results on the NonStop TNS/E platform: 1. t0021 subtest 15 is being flakey. It fails on the first run (make -k test) but succeeds when run in isolation. This is new on the NonStop TNS/E platform. t0021 has been a bit flakey in the past, but not recently. Just thought I'd mention it. It's only slightly disconcerting because I make very heavy use of smudge filters but since it runs fine in isolation, I'm going to assume it is fine. We had one unsubstantiated report of an occasional misfire of smudge filters, but no substantive evidence at this point to reproduce the situation. 2. t7519 subtest 25 still does not pass (previously reported for RC1) when run via "make -k test" the first time. This runs successfully when run in isolation or the second time. 3. t9001, t9020, t9600, t9601, t9602, t9604, fail, but should not run on platform (not new, just a reminder). We do not have sendmail or subversion. So it looks like we're a go on RC2 on NonStop. Thanks, Randall
RE: RFC: Separate commit identification from Merkle hashing
On May 23, 2019 17:19, Eric S. Raymond wrote: > Jonathan Nieder : > > Honestly, I do think you have missed some fundamental issues. > > https://public-inbox.org/git/ab3222ab-9121-9534-1472- > fac790bf08a4@gmai > > l.com/ > > discusses this further. > > Have re-read. That was a different pair of proposals. > > I have abandoned the idea of forcing timestamp uniqueness entirely - that > was a hack to define a canonical commit order, and my new RFC describes a > better way to get this. > > I still think finer-grained timestamps would be a good idea, but that is much > less important than the different set of properties we can guarantee via the > new RFC. I don't think finer-grained timestamps will help long-term. The faster systems get, the more resolution we need. At this point, I can easily get two commits within the same microsecond. The weird part is that if the commits are done from two different CPUs on my platform, it is theoretically possible (although highly unlikely) that the second commit could be one microsecond earlier than the first commit, on the same file system, if a inter-CPU clock-sync had not been done for the past few seconds. On a broader scale, that is somewhat obvious and assumes global time synchronisation is maintained. It also makes me wonder what happens when git runs on a quantum computer and a commit goes to the wrong universe (joke). Just my $0.014 Randall
RE: Issues with t7519.19, was RE: [Breakage] 2.22.0-rc1 t5401-update-hooks.sh
On May 23, 2019 16:06, Johannes Schindelin wrote: > On Wed, 22 May 2019, Randall S. Becker wrote: > > > On May 21, 2019 20:48, brian m. carlson wrote: > > > To: Randall S. Becker > > > Cc: 'Git Mailing List' > > > Subject: Re: [Breakage] 2.22.0-rc1 t5401-update-hooks.sh > > > > > > On 2019-05-21 at 21:47:54, Randall S. Becker wrote: > > > > When running the test in isolation, it passes without incident > > > > whether or not --verbose is used. So far, this only occurs on the > > > > first run through. I wanted to report it, based on the > > > > inconsistency of results. This is not the first time tests have > > > > acted in this fashion, and I realize it is difficult to do > > > > anything about it without being able to recreate > > > the situation. > > > > > > Does running git clean -dxf cause it to be reproducible? > > > > I will give it a go. Having exactly the same behaviour in t7519 > > subtest 19. I wonder whether there are breadcrumbs not being cleaned > > up. Will report back when I am able - may take a day or so. > > I fear that t7519's problems are *completely* unrelated to the t5401 issue > you reported earlier. I hunted the t7519 problems down today, and I could > imagine that these patches fix your t7519, too: > > https://github.com/gitgitgadget/git/pull/223 >From the description, I believe it. Timestamp resolution on NonStop is in >microseconds and those are not even slightly simulated. Coupled with this >being an MPP not SMP, things can occur within the same microsecond, or in >weird situations slightly before or after when comparing the clock on >different CPUs. Yes, time-travel is possible at the single microsecond level >đ. Cores are synchronized, but our machine has 4 CPUs and synchronizing the >file system across all of them does lead to slightly strange situations.
RE: [Breakage] 2.22.0-rc1 t5401-update-hooks.sh
On May 21, 2019 20:48, brian m. carlson wrote: > To: Randall S. Becker > Cc: 'Git Mailing List' > Subject: Re: [Breakage] 2.22.0-rc1 t5401-update-hooks.sh > > On 2019-05-21 at 21:47:54, Randall S. Becker wrote: > > When running the test in isolation, it passes without incident whether > > or not --verbose is used. So far, this only occurs on the first run > > through. I wanted to report it, based on the inconsistency of results. > > This is not the first time tests have acted in this fashion, and I > > realize it is difficult to do anything about it without being able to > > recreate > the situation. > > Does running git clean -dxf cause it to be reproducible? Made no difference. t5401 passed cleanly after a the clean -dxf. I don't know where the breadcrumbs are. I guess it could be something funky in the file system on platform or with bash.
RE: [Breakage] 2.22.0-rc1 t5401-update-hooks.sh
On May 21, 2019 20:48, brian m. carlson wrote: > To: Randall S. Becker > Cc: 'Git Mailing List' > Subject: Re: [Breakage] 2.22.0-rc1 t5401-update-hooks.sh > > On 2019-05-21 at 21:47:54, Randall S. Becker wrote: > > When running the test in isolation, it passes without incident whether > > or not --verbose is used. So far, this only occurs on the first run > > through. I wanted to report it, based on the inconsistency of results. > > This is not the first time tests have acted in this fashion, and I > > realize it is difficult to do anything about it without being able to > > recreate > the situation. > > Does running git clean -dxf cause it to be reproducible? I will give it a go. Having exactly the same behaviour in t7519 subtest 19. I wonder whether there are breadcrumbs not being cleaned up. Will report back when I am able - may take a day or so. Cheers, Randall
[Breakage] 2.22.0-rc1 t5401-update-hooks.sh
Another situation came up during regression testing on NonStop: t5401 broke on the first run through (most tests), with the failures below. *** t5401-update-hooks.sh *** not ok 1 - setup # # echo This is a test. >a && # git update-index --add a && # tree0=$(git write-tree) && # commit0=$(echo setup | git commit-tree $tree0) && # echo We hope it works. >a && # git update-index a && # tree1=$(git write-tree) && # commit1=$(echo modify | git commit-tree $tree1 -p $commit0) && # git update-ref refs/heads/master $commit0 && # git update-ref refs/heads/tofail $commit1 && # git clone --bare ./. victim.git && # GIT_DIR=victim.git git update-ref refs/heads/tofail $commit1 && # git update-ref refs/heads/master $commit1 && # git update-ref refs/heads/tofail $commit0 # t5401-update-hooks.sh: line 26: victim.git/hooks/pre-receive: No such file or di rectory chmod: cannot access 'victim.git/hooks/pre-receive': No such file or directory t5401-update-hooks.sh: line 35: victim.git/hooks/update: No such file or directo ry chmod: cannot access 'victim.git/hooks/update': No such file or directory t5401-update-hooks.sh: line 45: victim.git/hooks/post-receive: No such file or d irectory chmod: cannot access 'victim.git/hooks/post-receive': No such file or directory t5401-update-hooks.sh: line 54: victim.git/hooks/post-update: No such file or di rectory chmod: cannot access 'victim.git/hooks/post-update': No such file or directory ok 2 - push etc. When running the test in isolation, it passes without incident whether or not --verbose is used. So far, this only occurs on the first run through. I wanted to report it, based on the inconsistency of results. This is not the first time tests have acted in this fashion, and I realize it is difficult to do anything about it without being able to recreate the situation. Such as it is, Randall
RE: [Breakage] 2.22.0-rc1 - t0211-trace2-perf.sh
On May 21, 2019 07:59, Duy Nguyen wrote: > On Tue, May 21, 2019 at 6:51 PM Ăvar ArnfjĂśrĂ° Bjarmason > wrote: > > But the real bug looks like the trace2 code unconditionally depending > > on pthreads, even though NonStop has 'NO_PTHREADS = > UnfortunatelyYes' > > defined. > > > > That's why we get this th%d:unknown stuff, the trace2/tr2_tls.c code > > using pthreads is failing with whatever pthread-bizarro NonStop has. > > > > That seems easy enough to "fix", just always fake up "main" if we > > don't have pthreads, but perhaps Jeff H. has another opinion on it... > > That's not NonStop. thread-utils.h (re)defines pthread_getspecific() to return > NULL when NO_PTHREADS, which triggers this I think. The platform *is* NonStop, which has SPT and PUT pthreads, but we have never been able to make them work with git, so did not include them in the configuration.
[Breakage] 2.22.0-rc1 - t0211-trace2-perf.sh
Hi All, On the NonStop platform, the entire test for t0211-trace2-perf.sh does not work. The first case, in verbose, reports: We get errors when the script is run: Use of uninitialized value within @tokens in pattern match (m//) at t0211/scrub_perf.perl line 29, <> line 1. Initialized empty Git repository in /home/git/git/t/trash directory.t0211-trace2-perf/.git/ expecting success: test_when_finished "rm trace.perf actual expect" && GIT_TR2_PERF="$(pwd)/trace.perf" test-tool trace2 001return 0 && perl "$TEST_DIRECTORY/t0211/scrub_perf.perl" actual && cat >expect <<-EOF && d0|main|version|$V d0|main|start||_T_ABS_|||_EXE_ trace2 001return 0 d0|main|cmd_name|trace2 (trace2) d0|main|exit||_T_ABS_|||code:0 d0|main|atexit||_T_ABS_|||code:0 EOF test_cmp expect actual --- expect 2019-05-21 10:38:47 + +++ actual 2019-05-21 10:38:47 + @@ -1,5 +1,5 @@ -d0|main|version|2.22.0.rc1 -d0|main|start||_T_ABS_|||_EXE_ trace2 001return 0 -d0|main|cmd_name|trace2 (trace2) -d0|main|exit||_T_ABS_|||code:0 -d0|main|atexit||_T_ABS_|||code:0 +d0|th01:unknown|version|2.22.0.rc1 +d0|th02:unknown|start||_T_ABS_|||_EXE_ trace2 001return 0 +d0|th03:unknown|cmd_name|trace2 (trace2) +d0|th04:unknown|exit||_T_ABS_|||code:0 +d0|th06:unknown|atexit||_T_ABS_|||code:0 Our perl is v5.24.0 and this cannot be upgraded. Thoughts? Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: [BUG] GIT_SSH_COMMAND is not being decomposed
On April 15, 2019 17:14, Andreas Schwab wrote: > On Apr 15 2019, "Randall S. Becker" wrote: > > > on virtually any platform at my disposal (Windows, Ubuntu, MacOS, the > > older NonStop variant), and have that work with no problem. Somewhere > > after get_ssh_command(), the command is being interpreted it its parts > > either as a shell or something else (still trying to find that). > > See run-command.c:prepare_shell_cmd, if the command contains shell meta > characters it is passed to sh -c without further quoting. > > Andreas. Well crap. That explains far too much about what is happening. đ. One of the special parameters is specified as -S \$ZSSH2 (example, referring to the process name - which begin with $ and have to be escaped with \). This obviously triggers the alternate path and has been problematic. On the older systems, we found fewer (a.k.a just about none) uses of this parameter, so never encountered it. On the newer systems, virtually everyone is using -S. Ergo, behavioural differences. That explains a whole lot of why we need a wrapper script. Thanks for the pointer to the strcspn() reference. I can stop obsessing about this (thanks too Johannes, Szeder, Ăvar) for the help. As a suggestion, with people who know how to escape stuff properly (or not), perhaps we can select the alternate behaviour explicitly using a core.sshIgnoreEscape=true/false option. Thoughts on that? Regards, Randall
RE: [BUG] GIT_SSH_COMMAND is not being decomposed
On April 13, 2019 17:48, SZEDER GĂĄbor wrote: > On Sat, Apr 13, 2019 at 10:39:35PM +0200, Ăvar ArnfjĂśrĂ° Bjarmason wrote: > > On Sat, Apr 13 2019, Randall S. Becker wrote: > > > > > I am encountering a problem on one of our NonStop platform variants > > > where the GIT_SSH_COMMAND string is not being broken into > > > constituent parts. This is causing SSH to not run properly. As > > > background, SSH is not in a standard location and has non-standard > > > required arguments. This also occurs with core.sshCommand. The > situation is: > > > > > > git config --global core.sshCommand '/G/system/zssh/sshossz5 -Q' > > > > > > which correctly sets .gitconfig as: > > > > > > [core] > > > sshCommand = /G/system/zssh/sshossz5 -Q > > > > > > When git is run with GIT_TRACE=true GIT_PACKET_TRACE=true git fetch > > > > > > We get the partial trace: > > > 14:19:56.027088 trace: built-in: git fetch > > > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5 -Q' -G > > > user@host > > > > > > The same trace on our systems that actually do work results in: > > > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5' '-Q' > > > -G user@host > > > > > > I need help resolving why this is happening (as in where to look and > > > debug the situation). > > > > This doesn't seem to be documented *explicitly* (except between the > > lines & inferred), but it's only supported to pass a *command* there, > > i.e. the path of the ssh binary. > > 'man git' it quite explicit about this: > > $GIT_SSH_COMMAND takes precedence over $GIT_SSH, and is interpreted > by the shell, which allows additional arguments to be included. > $GIT_SSH on the other hand must be just the path to a program (which > can be a wrapper shell script, if additional arguments are needed). > > Quick test shows that the implementation agrees with the > documentation: > > $ GIT_TRACE=2 GIT_SSH_COMMAND='/usr/bin/ssh -v' git push -n github > 23:39:02.048870 git.c:419 trace: built-in: git push -n github > 23:39:02.060821 run-command.c:643 trace: run_command: unset > GIT_PREFIX; '/usr/bin/ssh -v' g...@github.com 'git-receive-pack > '\''/szeder/git'\''' > OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016 > debug1: Reading configuration data /home/szeder/.ssh/config > <... snipt rest of the verbose ssh output ...> > > And the config setting works, too: > > $ GIT_TRACE=2 git -c core.sshCommand='/usr/bin/ssh -v' push -n github > 23:42:55.26 git.c:439 trace: built-in: git push -n github > 23:42:55.285149 run-command.c:663 trace: run_command: unset > GIT_CONFIG_PARAMETERS GIT_PREFIX; '/usr/bin/ssh -v' g...@github.com > 'git-receive-pack '\''/szeder/git'\''' > OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016 > debug1: Reading configuration data /home/szeder/.ssh/config > <...> > > Note that in both cases the trace shows '/usr/bin/ssh -v', IOW neither > $GIT_SSH_COMMAND nor 'core.sshCommand' are broken up. > > But this is just an avarage Linux box, so perhaps this is a NonStop-specific > issue? > > > > See the code around get_ssh_command() > > in connect.c. The whole env/config value we look up gets passed as one. > > > > So if you need arguments you need to create a wrapper script and set > > ssh command to that script. What is strange is that GIT_SSH_COMMAND='/usr/bin/ssh -v' should not execute if we are just looking at an object path. It should be broken into '/usr/bin/ssh' and '-v' otherwise spawn* or exec* will not execute it. I'm still trying to understand why I can successfully do things like the following: $ GIT_SSH_COMMAND="ssh -i ~/.ssh/myid" git fetch on virtually any platform at my disposal (Windows, Ubuntu, MacOS, the older NonStop variant), and have that work with no problem. Somewhere after get_ssh_command(), the command is being interpreted it its parts either as a shell or something else (still trying to find that).
RE: [BUG] GIT_SSH_COMMAND is not being decomposed
On April 13, 2019 17:48, SZEDER GĂĄbor wrote: > To: Ăvar ArnfjĂśrĂ° Bjarmason > Cc: Randall S. Becker ; git@vger.kernel.org > Subject: Re: [BUG] GIT_SSH_COMMAND is not being decomposed > > On Sat, Apr 13, 2019 at 10:39:35PM +0200, Ăvar ArnfjĂśrĂ° Bjarmason wrote: > > On Sat, Apr 13 2019, Randall S. Becker wrote: > > > I am encountering a problem on one of our NonStop platform variants > > > where the GIT_SSH_COMMAND string is not being broken into > > > constituent parts. This is causing SSH to not run properly. As > > > background, SSH is not in a standard location and has non-standard > > > required arguments. This also occurs with core.sshCommand. The > situation is: > > > > > > git config --global core.sshCommand '/G/system/zssh/sshossz5 -Q' > > > > > > which correctly sets .gitconfig as: > > > > > > [core] > > > sshCommand = /G/system/zssh/sshossz5 -Q > > > > > > When git is run with GIT_TRACE=true GIT_PACKET_TRACE=true git fetch > > > > > > We get the partial trace: > > > 14:19:56.027088 trace: built-in: git fetch > > > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5 -Q' -G > > > user@host > > > > > > The same trace on our systems that actually do work results in: > > > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5' '-Q' > > > -G user@host > > > > > > I need help resolving why this is happening (as in where to look and > > > debug the situation). > > > > This doesn't seem to be documented *explicitly* (except between the > > lines & inferred), but it's only supported to pass a *command* there, > > i.e. the path of the ssh binary. > > 'man git' it quite explicit about this: > > $GIT_SSH_COMMAND takes precedence over $GIT_SSH, and is interpreted > by the shell, which allows additional arguments to be included. > $GIT_SSH on the other hand must be just the path to a program (which > can be a wrapper shell script, if additional arguments are needed). > > Quick test shows that the implementation agrees with the > documentation: > > $ GIT_TRACE=2 GIT_SSH_COMMAND='/usr/bin/ssh -v' git push -n github > 23:39:02.048870 git.c:419 trace: built-in: git push -n github > 23:39:02.060821 run-command.c:643 trace: run_command: unset > GIT_PREFIX; '/usr/bin/ssh -v' g...@github.com 'git-receive-pack > '\''/szeder/git'\''' > OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016 > debug1: Reading configuration data /home/szeder/.ssh/config > <... snipt rest of the verbose ssh output ...> > > And the config setting works, too: > > $ GIT_TRACE=2 git -c core.sshCommand='/usr/bin/ssh -v' push -n github > 23:42:55.26 git.c:439 trace: built-in: git push -n github > 23:42:55.285149 run-command.c:663 trace: run_command: unset > GIT_CONFIG_PARAMETERS GIT_PREFIX; '/usr/bin/ssh -v' g...@github.com 'git- > receive-pack '\''/szeder/git'\''' > OpenSSH_7.2p2 Ubuntu-4ubuntu2.8, OpenSSL 1.0.2g 1 Mar 2016 > debug1: Reading configuration data /home/szeder/.ssh/config > <...> > > Note that in both cases the trace shows '/usr/bin/ssh -v', IOW neither > $GIT_SSH_COMMAND nor 'core.sshCommand' are broken up. > > But this is just an avarage Linux box, so perhaps this is a NonStop-specific > issue? I'm sure it is a NonStop issue. It is interesting that 2.21.0 broke the string apart on the older NonStop variant and not the newer one. But looking at the code, I can't imagine how the string was broken up into parts. Makes no sense at all with xstrdup() and argv_array_push(). > > See the code around get_ssh_command() > > in connect.c. The whole env/config value we look up gets passed as one. > > > > So if you need arguments you need to create a wrapper script and set > > ssh command to that script. Going forward, I'm going to use (and strongly recommend) a wrapper on both NonStop variants. It's the right way to go, and not only a trivial script but makes configuring communication with upstream servers much easier (there are potentially multiple TCP/IP stacks and multiple SSH d databases available that need to be selected on the sshoss command line). Managing all that in one place is easier than having each user worry about it changing over time. Thanks again, Randall
RE: [BUG] GIT_SSH_COMMAND is not being decomposed
On April 13, 2019 16:40, Ăvar ArnfjĂśrĂ° Bjarmason wrote: > On Sat, Apr 13 2019, Randall S. Becker wrote: > > > I am encountering a problem on one of our NonStop platform variants > > where the GIT_SSH_COMMAND string is not being broken into constituent > > parts. This is causing SSH to not run properly. As background, SSH is > > not in a standard location and has non-standard required arguments. > > This also occurs with core.sshCommand. The situation is: > > > > git config --global core.sshCommand '/G/system/zssh/sshossz5 -Q' > > > > which correctly sets .gitconfig as: > > > > [core] > > sshCommand = /G/system/zssh/sshossz5 -Q > > > > When git is run with GIT_TRACE=true GIT_PACKET_TRACE=true git fetch > > > > We get the partial trace: > > 14:19:56.027088 trace: built-in: git fetch > > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5 -Q' -G > > user@host > > > > The same trace on our systems that actually do work results in: > > 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5' '-Q' -G > > user@host > > > > I need help resolving why this is happening (as in where to look and > > debug the situation). > > This doesn't seem to be documented *explicitly* (except between the lines & > inferred), but it's only supported to pass a *command* there, i.e. the path of > the ssh binary. See the code around get_ssh_command() in connect.c. The > whole env/config value we look up gets passed as one. > > So if you need arguments you need to create a wrapper script and set ssh > command to that script. Thanks. I didn't know that, because this technique worked for years on the older platform variant. My wrapper works fine on the newer system. With appreciation, Randall
[BUG] GIT_SSH_COMMAND is not being decomposed
I am encountering a problem on one of our NonStop platform variants where the GIT_SSH_COMMAND string is not being broken into constituent parts. This is causing SSH to not run properly. As background, SSH is not in a standard location and has non-standard required arguments. This also occurs with core.sshCommand. The situation is: git config --global core.sshCommand '/G/system/zssh/sshossz5 -Q' which correctly sets .gitconfig as: [core] Â Â Â sshCommand = /G/system/zssh/sshossz5 -Q When git is run with GIT_TRACE=true GIT_PACKET_TRACE=true git fetch We get the partial trace: 14:19:56.027088 trace: built-in: git fetch 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5 -Q' -G user@host The same trace on our systems that actually do work results in: 14:19:56.029895 trace: run_command: '/G/system/zssh/sshossz5' '-Q' -G user@host I need help resolving why this is happening (as in where to look and debug the situation). Urgently, Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: Semantic errors
> Of On March 25, 2019 15:22, Fabio Aiuto wrote: > Il giorno sab, 23/03/2019 alle 15.34 -0400, Randall S. Becker ha > scritto: > > On March 23, 2019 9:00, Fabio Aiuto wrote: > > > To: Randall S. Becker ; git@vger.kernel.org > > > Subject: Re: Semantic errors > > > > > > Il giorno ven, 22/03/2019 alle 18.43 -0400, Randall S. Becker ha > > > scritto: > > > > > -Original Message- > > > > > From: Fabio Aiuto > > > > > Sent: March 22, 2019 17:41 > > > > > To: Randall S. Becker ; git@vger.kernel > > > > > .org > > > > > Subject: Re: Semantic errors > > > > > > > > > > Il giorno ven, 22/03/2019 alle 17.39 -0400, Randall S. Becker ha > > > > > scritto: > > > > > > On March 22, 2019 17:25, Fabio Aiuto > > > > > > > Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. > > > > > > > Becker ha > > > > > > > scritto: > > > > > > > > > Of On March 21, 2019 15:32, Fabio Aiuto wrote: > > > > > > > > > Il giorno gio, 21/03/2019 alle 15.16 -0400, Randall S. > > > > > > > > > Becker ha > > > > > > > > > scritto: > > > > > > > > > > On March 21, 2019 15:06, Fabio Aiuto wrote: > > > > > > > > > > > I'm browsins git code with Eclipse. I'm on a local > > > > > > > > > > > branch called "studio" based on master (last public > > > > > > > > > > > commit e902e9b by Junio C Hamano on Monday March 11 > > > > > > > > > > > 2019). I've built everything by > > > > > > > > > > > changing: > > > > > > > > > > > CFLAGS = -g -Wall (removing -O2 to have smooth trace > > > > > > > > > > > in debugging). > > > > > > > > > > > But the environment detects the following semantic > > > > > > > > > > > errors (I made no > > > > > > > > > > > edits!!!): > > > > > > > > > > > Description ResourcePathLoca > > > > > > > > > > > tion > > > > > > > > > > > Type > > > > > > > > > > > Symbol 'GIT_HTML_PATH' could not be resolved > > > > > > > > > > > git > > > > > > > > > > > .c > > > > > > > > > > > /g > > > > > > > > > > > it > > > > > > > > > > > line 154 Semantic Error > > > > > > > > > > > Symbol 'GIT_MAN_PATH' could not be resolved > > > > > > > > > > > git. > > > > > > > > > > > c > > > > > > > > > > > /gi > > > > > > > > > > > t > > > > > > > > > > > line 158 Semantic Error > > > > > > > > > > > Symbol 'GIT_INFO_PATH' could not be resolved > > > > > > > > > > > git > > > > > > > > > > > .c > > > > > > > > > > > /g > > > > > > > > > > > it > > > > > > > > > > > line 162 Semantic Error > > > > > > > > > > > Symbol 'active_cache' could not be resolved > > > > > > > > > > > comm > > > > > > > > > > > it.c > > > > > > > > > > > /git > > > > > > > > > > > /builtin line 899Semantic Error > > > > > > > > > > > Field 'ce_intent_to_add(active_cache[i])' could not > > > > > > > > > > > be resolved > > > > > > > > > > > commit.c /git/builtinline 899 > > > > > > > > > > > Sem > > > > > > > > > > > anti > > > > > > > > > > > c > > > > > > > > > > > Error > > > > > > > > > > > Symbol 'active_nr' could not be resolved com > > > > > > > > > > > mit. > >
RE: Semantic errors
On March 23, 2019 9:00, Fabio Aiuto wrote: > To: Randall S. Becker ; git@vger.kernel.org > Subject: Re: Semantic errors > > Il giorno ven, 22/03/2019 alle 18.43 -0400, Randall S. Becker ha > scritto: > > > -Original Message- > > > From: Fabio Aiuto > > > Sent: March 22, 2019 17:41 > > > To: Randall S. Becker ; git@vger.kernel.org > > > Subject: Re: Semantic errors > > > > > > Il giorno ven, 22/03/2019 alle 17.39 -0400, Randall S. Becker ha > > > scritto: > > > > On March 22, 2019 17:25, Fabio Aiuto > > > > > Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. Becker ha > > > > > scritto: > > > > > > > Of On March 21, 2019 15:32, Fabio Aiuto wrote: > > > > > > > Il giorno gio, 21/03/2019 alle 15.16 -0400, Randall S. > > > > > > > Becker ha > > > > > > > scritto: > > > > > > > > On March 21, 2019 15:06, Fabio Aiuto wrote: > > > > > > > > > I'm browsins git code with Eclipse. I'm on a local > > > > > > > > > branch called "studio" based on master (last public > > > > > > > > > commit e902e9b by Junio C Hamano on Monday March 11 > > > > > > > > > 2019). I've built everything by > > > > > > > > > changing: > > > > > > > > > CFLAGS = -g -Wall (removing -O2 to have smooth trace in > > > > > > > > > debugging). > > > > > > > > > But the environment detects the following semantic > > > > > > > > > errors (I made no > > > > > > > > > edits!!!): > > > > > > > > > Description ResourcePathLocation > > > > > > > > > Type > > > > > > > > > Symbol 'GIT_HTML_PATH' could not be resolved git > > > > > > > > > .c > > > > > > > > > /g > > > > > > > > > it > > > > > > > > > line 154 Semantic Error > > > > > > > > > Symbol 'GIT_MAN_PATH' could not be resolved git. > > > > > > > > > c > > > > > > > > > /gi > > > > > > > > > t > > > > > > > > > line 158 Semantic Error > > > > > > > > > Symbol 'GIT_INFO_PATH' could not be resolved git > > > > > > > > > .c > > > > > > > > > /g > > > > > > > > > it > > > > > > > > > line 162 Semantic Error > > > > > > > > > Symbol 'active_cache' could not be resolved comm > > > > > > > > > it.c > > > > > > > > > /git > > > > > > > > > /builtin line 899Semantic Error > > > > > > > > > Field 'ce_intent_to_add(active_cache[i])' could not be > > > > > > > > > resolved > > > > > > > > > commit.c /git/builtinline 899Sem > > > > > > > > > anti > > > > > > > > > c > > > > > > > > > Error > > > > > > > > > Symbol 'active_nr' could not be resolved commit. > > > > > > > > > c > > > > > > > > > /gi > > > > > > > > > t/bu > > > > > > > > > iltin line 889Semantic Error > > > > > > > > > Symbol 'active_nr' could not be resolved commit. > > > > > > > > > c > > > > > > > > > /gi > > > > > > > > > t/bu > > > > > > > > > iltin line 898Semantic Error > > > > > > > > > Field 'oid' could not be resolved commit.c > > > > > > > > > /g > > > > > > > > > it/b > > > > > > > > > uilt > > > > > > > > > in > > > > > > > > > line 1654 Semantic Error > > > > > > > > > Symbol 'active_nr' could not be resolved commit. > > > > > > > > > c > > > > > > > > > /gi > > > > > >
RE: Semantic errors
> -Original Message- > From: Fabio Aiuto > Sent: March 22, 2019 17:41 > To: Randall S. Becker ; git@vger.kernel.org > Subject: Re: Semantic errors > > Il giorno ven, 22/03/2019 alle 17.39 -0400, Randall S. Becker ha > scritto: > > On March 22, 2019 17:25, Fabio Aiuto > > > Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. Becker ha > > > scritto: > > > > > Of On March 21, 2019 15:32, Fabio Aiuto wrote: > > > > > Il giorno gio, 21/03/2019 alle 15.16 -0400, Randall S. Becker ha > > > > > scritto: > > > > > > On March 21, 2019 15:06, Fabio Aiuto wrote: > > > > > > > I'm browsins git code with Eclipse. I'm on a local branch > > > > > > > called "studio" based on master (last public commit e902e9b > > > > > > > by Junio C Hamano on Monday March 11 2019). I've built > > > > > > > everything by > > > > > > > changing: > > > > > > > CFLAGS = -g -Wall (removing -O2 to have smooth trace in > > > > > > > debugging). > > > > > > > But the environment detects the following semantic errors (I > > > > > > > made no > > > > > > > edits!!!): > > > > > > > Description ResourcePathLocation > > > > > > > Type > > > > > > > Symbol 'GIT_HTML_PATH' could not be resolved git.c > > > > > > > /g > > > > > > > it > > > > > > > line 154 Semantic Error > > > > > > > Symbol 'GIT_MAN_PATH' could not be resolved git.c > > > > > > > /gi > > > > > > > t > > > > > > > line 158 Semantic Error > > > > > > > Symbol 'GIT_INFO_PATH' could not be resolved git.c > > > > > > > /g > > > > > > > it > > > > > > > line 162 Semantic Error > > > > > > > Symbol 'active_cache' could not be resolved commit.c > > > > > > > /git > > > > > > > /builtin line 899Semantic Error > > > > > > > Field 'ce_intent_to_add(active_cache[i])' could not be > > > > > > > resolved > > > > > > > commit.c /git/builtinline 899Semanti > > > > > > > c > > > > > > > Error > > > > > > > Symbol 'active_nr' could not be resolved commit.c > > > > > > > /gi > > > > > > > t/bu > > > > > > > iltin line 889Semantic Error > > > > > > > Symbol 'active_nr' could not be resolved commit.c > > > > > > > /gi > > > > > > > t/bu > > > > > > > iltin line 898Semantic Error > > > > > > > Field 'oid' could not be resolved commit.c/g > > > > > > > it/b > > > > > > > uilt > > > > > > > in > > > > > > > line 1654 Semantic Error > > > > > > > Symbol 'active_nr' could not be resolved commit.c > > > > > > > /gi > > > > > > > t/bu > > > > > > > iltin line 901Semantic Error > > > > > > > Symbol 'active_cache_tree' could not be resolved com > > > > > > > mit. > > > > > > > c > > > > > > > /git/builtin line 1654 Semantic Error > > > > > > > Symbol 'active_cache_changed' could not be resolved > > > > > > > comm > > > > > > > it.c > > > > > > > /git/builtin line 418Semantic Error > > > > > > > Symbol 'active_cache_tree' could not be resolved com > > > > > > > mit. > > > > > > > c > > > > > > > /git/builtin line 419Semantic Error > > > > > > > Symbol 'active_nr' could not be resolved commit.c > > > > > > > /gi > > > > > > > t/bu > > > > > > > iltin line 254Semantic Error > > > > > > > Symbol 'active_cache' could not be resolved commit.c > > > > > > > /git > > > > &
RE: Semantic errors
On March 22, 2019 17:25, Fabio Aiuto > Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. Becker ha > scritto: > > > Of On March 21, 2019 15:32, Fabio Aiuto wrote: > > > Il giorno gio, 21/03/2019 alle 15.16 -0400, Randall S. Becker ha > > > scritto: > > > > On March 21, 2019 15:06, Fabio Aiuto wrote: > > > > > I'm browsins git code with Eclipse. I'm on a local branch called > > > > > "studio" based on master (last public commit e902e9b by Junio C > > > > > Hamano on Monday March 11 2019). I've built everything by > > > > > changing: > > > > > CFLAGS = -g -Wall (removing -O2 to have smooth trace in > > > > > debugging). > > > > > But the environment detects the following semantic errors (I > > > > > made no > > > > > edits!!!): > > > > > Description ResourcePathLocation > > > > > Type > > > > > Symbol 'GIT_HTML_PATH' could not be resolved git.c > > > > > /g > > > > > it > > > > > line 154 Semantic Error > > > > > Symbol 'GIT_MAN_PATH' could not be resolved git.c > > > > > /gi > > > > > t > > > > > line 158 Semantic Error > > > > > Symbol 'GIT_INFO_PATH' could not be resolved git.c > > > > > /g > > > > > it > > > > > line 162 Semantic Error > > > > > Symbol 'active_cache' could not be resolved commit.c > > > > > /git > > > > > /builtin line 899Semantic Error > > > > > Field 'ce_intent_to_add(active_cache[i])' could not be resolved > > > > > commit.c /git/builtinline 899Semantic > > > > > Error > > > > > Symbol 'active_nr' could not be resolved commit.c > > > > > /gi > > > > > t/bu > > > > > iltin line 889Semantic Error > > > > > Symbol 'active_nr' could not be resolved commit.c > > > > > /gi > > > > > t/bu > > > > > iltin line 898Semantic Error > > > > > Field 'oid' could not be resolved commit.c/git/b > > > > > uilt > > > > > in > > > > > line 1654 Semantic Error > > > > > Symbol 'active_nr' could not be resolved commit.c > > > > > /gi > > > > > t/bu > > > > > iltin line 901Semantic Error > > > > > Symbol 'active_cache_tree' could not be resolved commit. > > > > > c > > > > > /git/builtin line 1654 Semantic Error > > > > > Symbol 'active_cache_changed' could not be resolved comm > > > > > it.c > > > > > /git/builtin line 418Semantic Error > > > > > Symbol 'active_cache_tree' could not be resolved commit. > > > > > c > > > > > /git/builtin line 419Semantic Error > > > > > Symbol 'active_nr' could not be resolved commit.c > > > > > /gi > > > > > t/bu > > > > > iltin line 254Semantic Error > > > > > Symbol 'active_cache' could not be resolved commit.c > > > > > /git > > > > > /builtin line 255Semantic Error > > > > > > > > > > I can debug without problems, but what if I should trece through > > > > > one of those errors? > > > > > How can I fix them? > > > > > > > > This situation occurs in many projects in ECLIPSE, not only git. > > > > The > > > > errors are likely coming from one of the error parsers that you > > > > have enabled in your workspace. Look in the Project Properties or > > > > Workspace Preferences under C/C++ Build/Settings in the Error > > > > Parsers tab for your build configuration. You may have to turn off > > > > some of those. > > > > There is also the C/C++ General/Code Analysis Preferences setting > > > > where you might have to turn off the problematic errors. I have > > > > found that this is a common situation for code that is imported > > > > into ECLIPSE from other platforms, where the GNU error and > > > > analysis tools are overly aggressive by default. > > > > &g
RE: Semantic errors
> Of On March 22, 2019 16:25, Fabio Aiuto wrote: > To: Randall S. Becker ; git@vger.kernel.org > Subject: Re: Semantic errors > > Il giorno gio, 21/03/2019 alle 17.03 -0400, Randall S. Becker ha > scritto: > > > Of On March 21, 2019 15:32, Fabio Aiuto wrote: > > > Il giorno gio, 21/03/2019 alle 15.16 -0400, Randall S. Becker ha > > > scritto: > > > > On March 21, 2019 15:06, Fabio Aiuto wrote: > > > > > I'm browsins git code with Eclipse. I'm on a local branch called > > > > > "studio" based on master (last public commit e902e9b by Junio C > > > > > Hamano on Monday March 11 2019). I've built everything by > > > > > changing: > > > > > CFLAGS = -g -Wall (removing -O2 to have smooth trace in > > > > > debugging). > > > > > But the environment detects the following semantic errors (I > > > > > made no > > > > > edits!!!): > > > > > Description ResourcePathLocation > > > > > Type > > > > > Symbol 'GIT_HTML_PATH' could not be resolved git.c > > > > > /g > > > > > it > > > > > line 154 Semantic Error > > > > > Symbol 'GIT_MAN_PATH' could not be resolved git.c > > > > > /gi > > > > > t > > > > > line 158 Semantic Error > > > > > Symbol 'GIT_INFO_PATH' could not be resolved git.c > > > > > /g > > > > > it > > > > > line 162 Semantic Error > > > > > Symbol 'active_cache' could not be resolved commit.c > > > > > /git > > > > > /builtin line 899Semantic Error > > > > > Field 'ce_intent_to_add(active_cache[i])' could not be resolved > > > > > commit.c /git/builtinline 899Semantic > > > > > Error > > > > > Symbol 'active_nr' could not be resolved commit.c > > > > > /gi > > > > > t/bu > > > > > iltin line 889Semantic Error > > > > > Symbol 'active_nr' could not be resolved commit.c > > > > > /gi > > > > > t/bu > > > > > iltin line 898Semantic Error > > > > > Field 'oid' could not be resolved commit.c/git/b > > > > > uilt > > > > > in > > > > > line 1654 Semantic Error > > > > > Symbol 'active_nr' could not be resolved commit.c > > > > > /gi > > > > > t/bu > > > > > iltin line 901Semantic Error > > > > > Symbol 'active_cache_tree' could not be resolved commit. > > > > > c > > > > > /git/builtin line 1654 Semantic Error > > > > > Symbol 'active_cache_changed' could not be resolved comm > > > > > it.c > > > > > /git/builtin line 418Semantic Error > > > > > Symbol 'active_cache_tree' could not be resolved commit. > > > > > c > > > > > /git/builtin line 419Semantic Error > > > > > Symbol 'active_nr' could not be resolved commit.c > > > > > /gi > > > > > t/bu > > > > > iltin line 254Semantic Error > > > > > Symbol 'active_cache' could not be resolved commit.c > > > > > /git > > > > > /builtin line 255Semantic Error > > > > > > > > > > I can debug without problems, but what if I should trece through > > > > > one of those errors? > > > > > How can I fix them? > > > > > > > > This situation occurs in many projects in ECLIPSE, not only git. > > > > The > > > > errors are likely coming from one of the error parsers that you > > > > have enabled in your workspace. Look in the Project Properties or > > > > Workspace Preferences under C/C++ Build/Settings in the Error > > > > Parsers tab for your build configuration. You may have to turn off > > > > some of those. > > > > There is also the C/C++ General/Code Analysis Preferences setting > > > > where you might have to turn off the problematic errors. I have > > > > found that this is a common situation for code that is imported > > > > into ECLIPSE from other platforms, where
[RFC] git stash --snapshot
About two weeks ago there was a discussion about building an undo stack.
https://public-inbox.org/git/000401d4d6c8$f68bb020$e3a31060$@nexbridge.com/
it had me thinking about whether a stash --snapshot might be useful. Below
is a conceptual change - by no means even close to complete. This would
allow scripting to wrap critical commands with a "git stash push --snapshot"
without changing the working directory. For symmetry, a "git stash pop
--force" is needed if --include-untracked were used to stash everything in
the first place. It might be more useful also to wait until stash is
converted to C, I suppose. I'm wondering whether to pursue this or drop it.
Thoughts? (and I beg forgiveness for what my mailer might do to the wrapping
of this patch, and I already know the indent is wrong between 329 and 370,
and that the granularity of the --force option is wrong).
diff --git a/git-stash.sh b/git-stash.sh
index 789ce2f41d..7741192980 100755
--- a/git-stash.sh
+++ b/git-stash.sh
@@ -5,12 +5,13 @@ dashless=$(basename "$0" | sed -e 's/-/ /')
USAGE="list []
or: $dashless show []
or: $dashless drop [-q|--quiet] []
- or: $dashless ( pop | apply ) [--index] [-q|--quiet] []
+ or: $dashless ( pop | apply ) [--index] [-q|--quiet] [-f|--force]
[]
or: $dashless branch []
or: $dashless save [--patch] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] []
or: $dashless [push [--patch] [-k|--[no-]keep-index] [-q|--quiet]
[-u|--include-untracked] [-a|--all] [-m ]
+ [--snapshot]
[-- ...]]
or: $dashless clear"
@@ -252,6 +253,7 @@ push_stash () {
patch_mode=
untracked=
stash_msg=
+ snapshot=
while test $# != 0
do
case "$1" in
@@ -286,6 +288,9 @@ push_stash () {
--message=*)
stash_msg=${1#--message=}
;;
+ --snapshot)
+ snapshot=t
+ ;;
--help)
show_help
;;
@@ -329,6 +334,8 @@ push_stash () {
die "$(gettext "Cannot save the current status")"
say "$(eval_gettext "Saved working directory and index state
\$stash_msg")"
+ if test -z "$snapshot"
+ then
if test -z "$patch_mode"
then
test "$untracked" = "all" && CLEAN_X_OPTION=-x ||
CLEAN_X_OPTION=
@@ -363,6 +370,7 @@ push_stash () {
git reset -q -- "$@"
fi
fi
+ fi
}
save_stash () {
@@ -490,6 +498,7 @@ parse_flags_and_rev()
FLAGS=
REV=
+ FORCE_OPTION=
for opt
do
case "$opt" in
@@ -499,6 +508,9 @@ parse_flags_and_rev()
--index)
INDEX_OPTION=--index
;;
+ -f|--force)
+ FORCE_OPTION=--force
+ ;;
--help)
show_help
;;
@@ -607,7 +619,7 @@ apply_stash () {
if test -n "$u_tree"
then
GIT_INDEX_FILE="$TMPindex" git read-tree "$u_tree" &&
- GIT_INDEX_FILE="$TMPindex" git checkout-index --all &&
+ GIT_INDEX_FILE="$TMPindex" git checkout-index --all
$FORCE_OPTION &&
rm -f "$TMPindex" ||
die "$(gettext "Could not restore untracked files from stash
entry")"
fi
@@ -688,7 +700,7 @@ apply_to_branch () {
set -- --index "$@"
assert_stash_like "$@"
- git checkout -b $branch $REV^ &&
+ git checkout -b $branch $FORCE_OPTION $REV^ &&
apply_stash "$@" && {
test -z "$IS_STASH_REF" || drop_stash "$@"
}
Regards,
Randall
-- Brief whoami:
NonStop developer since approximately 2112884442
UNIX developer since approximately 421664400
-- In my real life, I talk too much.
RE: Semantic errors
> Of On March 21, 2019 15:32, Fabio Aiuto wrote: > Il giorno gio, 21/03/2019 alle 15.16 -0400, Randall S. Becker ha > scritto: > > On March 21, 2019 15:06, Fabio Aiuto wrote: > > > I'm browsins git code with Eclipse. I'm on a local branch called > > > "studio" based on master (last public commit e902e9b by Junio C > > > Hamano on Monday March 11 2019). I've built everything by changing: > > > CFLAGS = -g -Wall (removing -O2 to have smooth trace in debugging). > > > But the environment detects the following semantic errors (I made no > > > edits!!!): > > > Description ResourcePathLocationType > > > Symbol 'GIT_HTML_PATH' could not be resolved git.c /g > > > it > > > line 154 Semantic Error > > > Symbol 'GIT_MAN_PATH' could not be resolved git.c /gi > > > t > > > line 158 Semantic Error > > > Symbol 'GIT_INFO_PATH' could not be resolved git.c /g > > > it > > > line 162 Semantic Error > > > Symbol 'active_cache' could not be resolved commit.c > > > /git > > > /builtin line 899Semantic Error > > > Field 'ce_intent_to_add(active_cache[i])' could not be resolved > > > commit.c /git/builtinline 899Semantic Error > > > Symbol 'active_nr' could not be resolved commit.c/gi > > > t/bu > > > iltin line 889Semantic Error > > > Symbol 'active_nr' could not be resolved commit.c/gi > > > t/bu > > > iltin line 898Semantic Error > > > Field 'oid' could not be resolved commit.c/git/built > > > in > > > line 1654 Semantic Error > > > Symbol 'active_nr' could not be resolved commit.c/gi > > > t/bu > > > iltin line 901Semantic Error > > > Symbol 'active_cache_tree' could not be resolved commit.c > > > /git/builtin line 1654 Semantic Error > > > Symbol 'active_cache_changed' could not be resolved commit.c > > > /git/builtin line 418Semantic Error > > > Symbol 'active_cache_tree' could not be resolved commit.c > > > /git/builtin line 419Semantic Error > > > Symbol 'active_nr' could not be resolved commit.c/gi > > > t/bu > > > iltin line 254Semantic Error > > > Symbol 'active_cache' could not be resolved commit.c > > > /git > > > /builtin line 255Semantic Error > > > > > > I can debug without problems, but what if I should trece through one > > > of those errors? > > > How can I fix them? > > > > This situation occurs in many projects in ECLIPSE, not only git. The > > errors are likely coming from one of the error parsers that you have > > enabled in your workspace. Look in the Project Properties or Workspace > > Preferences under C/C++ Build/Settings in the Error Parsers tab for > > your build configuration. You may have to turn off some of those. > > There is also the C/C++ General/Code Analysis Preferences setting > > where you might have to turn off the problematic errors. I have found > > that this is a common situation for code that is imported into ECLIPSE > > from other platforms, where the GNU error and analysis tools are > > overly aggressive by default. > > > > Good luck. > > Randall > > > > -- Brief whoami: > > NonStop developer since approximately 2112884442 > > UNIX developer since approximately 421664400 > > -- In my real life, I talk too much. > > > > > > > Thank you I tried to disable all of them, but they all remain. For example the > variable 'active_nr' is actually never declared. That's so strange. Hope to > solve this all soon. I'm freezed... It is very likely in ECLIPSE either in workstation or project settings relating to error parsers (turn everything off). It still may be an error parser issue. One key thing... do not use -Wall. There are also settings about what to do in some error conditions configured in ECLIPSE. -Wall could be probably triggering a response from one of the error parsers. But the Semantic Error type is not normally from the compiler; rather, it is from ECLIPSE CDT pre-scanning the code. Anyway, check out other -W settings to disable all warnings as a start. If you are building in Cygwin or Mingw, you probably can ignore the ECLIPSE errors, especially if git actually built. If you are trying to mix a managed build and a non-managed build in the same project, you are going to be out of luck.
RE: Semantic errors
On March 21, 2019 15:06, Fabio Aiuto wrote: > I'm browsins git code with Eclipse. I'm on a local branch called "studio" > based > on master (last public commit e902e9b by Junio C Hamano on Monday > March 11 2019). I've built everything by changing: > CFLAGS = -g -Wall (removing -O2 to have smooth trace in debugging). > But the environment detects the following semantic errors (I made no > edits!!!): > Description ResourcePathLocationType > Symbol 'GIT_HTML_PATH' could not be resolved git.c /git > line 154 Semantic Error > Symbol 'GIT_MAN_PATH' could not be resolved git.c /git > line 158 Semantic Error > Symbol 'GIT_INFO_PATH' could not be resolved git.c /git > line 162 Semantic Error > Symbol 'active_cache' could not be resolved commit.c/git > /builtin line 899Semantic Error > Field 'ce_intent_to_add(active_cache[i])' could not be resolved > commit.c /git/builtinline 899Semantic Error > Symbol 'active_nr' could not be resolved commit.c/git/bu > iltin line 889Semantic Error > Symbol 'active_nr' could not be resolved commit.c/git/bu > iltin line 898Semantic Error > Field 'oid' could not be resolved commit.c/git/builtin > line 1654 Semantic Error > Symbol 'active_nr' could not be resolved commit.c/git/bu > iltin line 901Semantic Error > Symbol 'active_cache_tree' could not be resolved commit.c > /git/builtin line 1654 Semantic Error > Symbol 'active_cache_changed' could not be resolved commit.c > /git/builtin line 418Semantic Error > Symbol 'active_cache_tree' could not be resolved commit.c > /git/builtin line 419Semantic Error > Symbol 'active_nr' could not be resolved commit.c/git/bu > iltin line 254Semantic Error > Symbol 'active_cache' could not be resolved commit.c/git > /builtin line 255Semantic Error > > I can debug without problems, but what if I should trece through one of > those errors? > How can I fix them? This situation occurs in many projects in ECLIPSE, not only git. The errors are likely coming from one of the error parsers that you have enabled in your workspace. Look in the Project Properties or Workspace Preferences under C/C++ Build/Settings in the Error Parsers tab for your build configuration. You may have to turn off some of those. There is also the C/C++ General/Code Analysis Preferences setting where you might have to turn off the problematic errors. I have found that this is a common situation for code that is imported into ECLIPSE from other platforms, where the GNU error and analysis tools are overly aggressive by default. Good luck. Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: [PATCH v1 11/11] doc: promote "git restore"
> -Original Message- > From: git-ow...@vger.kernel.org On Behalf > Of Elijah Newren > Sent: March 9, 2019 14:38 > To: Nguyáť n ThĂĄi Ngáťc Duy > Cc: Git Mailing List ; Junio C Hamano > > Subject: Re: [PATCH v1 11/11] doc: promote "git restore" > > On Fri, Mar 8, 2019 at 2:17 AM Nguyáť n ThĂĄi Ngáťc Duy > wrote: > > > > The new command "git restore" (together with "git switch") are added > > to avoid the confusion of one-command-do-all "git checkout" for new > > users. They are also helpful to avoid ambiguation context. > > s/ambiguation/ambiguous/ or s/ambiguation context/ambiguity/? > > > For these reasons, promote it everywhere possible. This includes > > documentation, suggestions/advice from other commands. > > > > One nice thing about git-restore is the ability to restore > > "everything", so it can be used in "git status" advice instead of both > > "git checkout" and "git reset". The three commands suggested by "git > > status" are add, rm and restore. > > > > "git checkout" is also removed from "git help" (i.e. it's no longer > > considered a commonly used command) Just curious: At what point did git checkout become not commonly used? Git switch and git restore are not yet in git as of 2.21.0, which is rather current. Maybe I missed a thread.
RE: git MUST notify user when files will be deleted or overwritten by command
On March 9, 2019 5:48, Kevin Daudt wrote: > On Sat, Mar 09, 2019 at 10:19:03AM +, Dimitri Joukoff wrote: > > Hi, > > > > As a relatively novice user of git, there have been far too many times > > that I have lost data, sometimes quite a lot. So this proposal is > > about catering for the less experienced users and averting fits of > > anger and frustration. The only reason my computer still works is > > because my sub-conscious mind stops me from smashing it or throwing it > > against a wall. It seems my sub-conscious mind has a pragmatic view > > of the world and understands that whilst I may receive instantaneous > > satisfaction at the time, in the long term, the pain will be far > > worse, and thus prevents me from doing something rash. > > > > Yes, it can be very frustrating to lose things you did not intend to lose, so > making sure your tooling limits the chances of that happing is certainly a > worthwile goal. > > > > > Below is the detail of my proposal: > Whenever a command is issued in > > git that will cause git to overwrite or delete *ANY* files whose > > current state isn't already recorded in the repository, git should > > prompt the user to confirm the operation. This includes untracked > > files as well as files that are in the 'not staged' > > and 'staged' lists. > > > > To make the consequences of the command transparent, the confirmation > > should include a list of files that will be affected (perhaps in a > > similar way to how git status works). The scope of the files listed > > must match the scope of the command to be executed. No hidden > > changes, no side-effects. > > > > Saying no to the confirmation should abort the command. > > > > It may be useful to allow confirmation of individual files, but as a > > novice user, I can't argue this point objectively, nor reason about > > its implications and complexity. > > > > This feature should be enabled by default whenever a clone or init > > operation are performed. > > > > The user should be able to progressively reduce the range of commands > > and amount of confirmation interactions that take place. The > > configuration technique could follow the already established procedure > > for other configurable data in git. So this could be done globally > > for the user, or locally within each repository. > > > > > > As a novice user, there may be further useful extensions of this idea, > > about which I'm unable to reason. So I welcome further elaboration of > > the idea discussed above. > > A lot of confirmations only result in people automatically dismissing them > (confirmation saturation), missing the goal of what you intend. > > Instead of asking for confirmation, it's much better to allow people to undo > these mistakes. You see the same pattern in gmail for example, where they > hardly ask you for any confirmation, but instead show an undo button that > allows you to undo the last operation. In my opinion this is a better way to > go then to add confirmations everywhere. > > I know this has come up on the git mailing list more often, but I cannot find a > relevant thread at this moment. First, I really do not like the idea of confirmations. This could complicate scripting and would drive much of the work I do with git in Jenkins up a wall. You would need access to stdin for almost anything. Second, I think an automatic undo has merit and could further differentiate git from other DVCS and VCS systems. My thought is along the lines of starting with the stash concept for each undo - almost like an auto-stash. Basically, any time you perform a working-directory modifying operation, a stash-like commit is added to the repository at HEAD (possibly ignoring .gitignore or precious files, like --include-untracked but in a config like undo.untracked=on, to avoid needing to remember to do this). I envision it being a stash without modifying the working-directory or changing the repository state other than the "undo" unlike what stash does. Considering the performance hit this *will* cause, I would want an option to not do this (say, undo.enable=on/off, off by default unless there was some newbie metric , or maybe undo.fearful=high ), and a limit to the number of undoes (undo.limit=n), and an auto-drop capability so that when you finally commit, you have the option to drop the undoes of the previous parent commit (undo.autoclean=on/off), or limit it to cleaning after more than one commit is done beyond the commit where the undo exists (undo.autoclean=n). Deriving an "undo" off of a specific parent commit (HEAD), instead of deriving "undoes" on each other, might be helpful in resolving the question of how to you roll off (get rid of) undoes over time - making it just based on the time of the snapshot and how many you want to keep. The reason I would hang it off of a HEAD commit is that a checkout/switch would preserve the undo stack so that when you returned to a branch, its undo stack would be available, like stash. I
RE: Need multibyte advice - Shift-JIS
On February 27, 2019 14:36, Johannes Sixt wrote: > Am 27.02.19 um 19:50 schrieb Randall S. Becker: > > On February 27, 2019 13:18, Michal SuchĂĄnek wrote: > >> What are your requirements, exactly? > > Source code and comments contain SJIS content. The requirement is to > > be able to move seamlessly in and out of git, and have git > > show/diff/log display SJIS as well as ASCII content. How that happens > > is open. The > > UTF-16 is a red-herring, only as an attempt at getting at SJIS content > > differently than the limitation imposed by less. > > When your file content contains ShiftJIS, you should set an attribute in > .gitattributes: > > *.sourcecode encoding=ShiftJIS > > When your git commits messages contain ShiftJIS, you should configure > > git config i18n.commitEncoding ShiftJIS > > More precisely, this assumes that your editor that composes to commits > messages writes the .git/COMMIT_MSG in ShiftJIS. > > When your terminal or pager is configured that it interprets the byte stream > that it receives from applications for display as ShiftJIS, then you should > configure > > git config i18n.logOutputEncoding ShiftJIS > > You can set this independently from the other settings. In particular, when it > is not set, UTF-8 is assumed. That is, if your terminal or pager supports UTF- > 8, you should *NOT* set this configuration (or set it to UTF-8). > > And, of course, you must have built Git with iconv, which must have support > for ShiftJIS. Thanks. I will forward this along and check the iconv build and rev-level we have used in git. Many thanks.
RE: Need multibyte advice - Shift-JIS
On February 27, 2019 13:18, Michal SuchĂĄnek wrote: > On Wed, 27 Feb 2019 12:59:15 -0500 > "Randall S. Becker" wrote: > > > On February 27, 2019 12:51, Michal SuchĂĄnek wrote: > > > To: Randall S. Becker > > > Cc: git@vger.kernel.org > > > Subject: Re: Need multibyte advice - Shift-JIS > > > > > > I'm sorry if I was not clear about all this. NonStop is not a Linux > > platform. It > is POSIX. Not all utilities are available and not all utilities have all > capabilities. > lv is not available for the platform. less considers the data binary and > displays > what usually is displayed when you try to use it for binary multibyte. You get > @^@- and such. It does not present the data in the correct character set for > the user. > > > > This was only one part of my original question. I am searching elsewhere > for support on pagers, because this really is not an appropriate discussion > for > the git group to focus on, do let's drop this, please, as not worth > continuing. > My original request was more about how to set up the file attributes, > difference engine, and the rest of the git infrastructure. The partner I am > working with is doing this with git hooks, which I am not really happy about. > Let's prune this discussion as not worthy. > > > > Yes, this is totally unclear. Setting git hooks is possible but setting > LESSCHARDEF is not? It can enter the environment simply through .profile, where we can change GIT_PAGER. We have established that separately. > Is patching git acceptable or is that out of question too? I have done a bunch of git patching, where specifically. > What are your requirements, exactly? Source code and comments contain SJIS content. The requirement is to be able to move seamlessly in and out of git, and have git show/diff/log display SJIS as well as ASCII content. How that happens is open. The UTF-16 is a red-herring, only as an attempt at getting at SJIS content differently than the limitation imposed by less.
RE: Need multibyte advice - Shift-JIS
On February 27, 2019 12:51, Michal SuchĂĄnek wrote: > To: Randall S. Becker > Cc: git@vger.kernel.org > Subject: Re: Need multibyte advice - Shift-JIS > > On Wed, 27 Feb 2019 12:38:06 -0500 > "Randall S. Becker" wrote: > > > On February 27, 2019 12:15, Michal SuchĂĄnek wrote: > > > To: Randall S. Becker > > > Cc: git@vger.kernel.org > > > Subject: Re: Need multibyte advice - Shift-JIS > > > > > > On Wed, 27 Feb 2019 12:03:58 -0500 > > > "Randall S. Becker" wrote: > > > > > > > On February 27, 2019 11:52, Michal SuchĂĄnek wrote: > > > > > To: Randall S. Becker > > > > > Cc: git@vger.kernel.org > > > > > Subject: Re: Need multibyte advice - Shift-JIS > > > > > > > > > > On Wed, 27 Feb 2019 11:33:47 -0500 "Randall S. Becker" > > > > > wrote: > > > > > > > > > > > On February 27, 2019 11:29 Michal SuchĂĄnek wrote: > > > > > > > On Wed, 27 Feb 2019 11:19:33 -0500 "Randall S. Becker" > > > > > > > wrote: > > > > > > > > > > > > > > > On February 27, 2019 11:11, Michal SuchĂĄnek wrote: > > > > > > > > > On Wed, 27 Feb 2019 10:54:23 -0500 "Randall S. Becker" > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > On February 27, 2019 9:09, Michal SuchĂĄnek wrote: > > > > > > > > > > > On Wed, 27 Feb 2019 08:04:08 -0500 "Randall S. Becker" > > > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > > > > > Hi Git Team, > > > > > > > > > > > > > > > > > > > > > > > > I have to admit being perplexed by this one. I > > > > > > > > > > > > have been asked to support the Shift-JIS character > > > > > > > > > > > > set in file contents, comments, and logs, for a > > > > > > > > > > > > partner of mine. I know there are a few ways to do > > > > > > > > > > > > this, but I'm looking for the official non-hacky > > > > > > > > > > > > way > > > > > > > to do this. > > > > > > > > > > > > This is CLI only, and our pager, less, does not > > > > > > > > > > > > support multi-byte, so I'm looking > > > > > > > > > > for > > > > > > > > > > > options there also. > > > > > > > > > > > > > > > > > > > > > > SJIS is about as much multibyte as UTF-8. > > > > > > > > > > > > > > > > > > > > > > Why do you think less does not support it? > > > > > > > > > > > > > > > > > > > > > > Last time I looked there was SJIS locale for libc so > > > > > > > > > > > it is only matter of generating the correct locales > > > > > > > > > > > and using them. Of course, if you are > > > > > > > > > > running > > > > > > > > > > > in UTF-8 SJIS will look like garbage. > > > > > > > > > > > > > > > > > > > > Sadly, I did not personally build less on this > > > > > > > > > > platform, and the libc used did not include UTF-16, on > > > > > > > > > > the platform vendor supplied less. cat works fine, but > > > > > > > > > > the usual > > > > > > > > > > LESSCHARSET=utf-16 is unsupported, so I am looking for > > > > > > > > > > an alternative. THAT is why I think less does not support > > > > > > > > > > it. > > > > > > > > > > Sorry, I should have made that more > > > > > > > clear. > > > > > > > > > > > > > > > > > > > > cat works fine, so if I set GIT_PAGER=cat, I can at > > > > > > > > > > least see the diffs cleanly in SJIS, but this partner > > > > > > > > > > wants a pager that is > >
RE: Need multibyte advice - Shift-JIS
On February 27, 2019 12:15, Michal SuchĂĄnek wrote: > To: Randall S. Becker > Cc: git@vger.kernel.org > Subject: Re: Need multibyte advice - Shift-JIS > > On Wed, 27 Feb 2019 12:03:58 -0500 > "Randall S. Becker" wrote: > > > On February 27, 2019 11:52, Michal SuchĂĄnek wrote: > > > To: Randall S. Becker > > > Cc: git@vger.kernel.org > > > Subject: Re: Need multibyte advice - Shift-JIS > > > > > > On Wed, 27 Feb 2019 11:33:47 -0500 > > > "Randall S. Becker" wrote: > > > > > > > On February 27, 2019 11:29 Michal SuchĂĄnek wrote: > > > > > On Wed, 27 Feb 2019 11:19:33 -0500 "Randall S. Becker" > > > > > wrote: > > > > > > > > > > > On February 27, 2019 11:11, Michal SuchĂĄnek wrote: > > > > > > > On Wed, 27 Feb 2019 10:54:23 -0500 "Randall S. Becker" > > > > > > > wrote: > > > > > > > > > > > > > > > On February 27, 2019 9:09, Michal SuchĂĄnek wrote: > > > > > > > > > On Wed, 27 Feb 2019 08:04:08 -0500 "Randall S. Becker" > > > > > > > > > wrote: > > > > > > > > > > > > > > > > > > > Hi Git Team, > > > > > > > > > > > > > > > > > > > > I have to admit being perplexed by this one. I have > > > > > > > > > > been asked to support the Shift-JIS character set in > > > > > > > > > > file contents, comments, and logs, for a partner of > > > > > > > > > > mine. I know there are a few ways to do this, but I'm > > > > > > > > > > looking for the official non-hacky way > > > > > to do this. > > > > > > > > > > This is CLI only, and our pager, less, does not > > > > > > > > > > support multi-byte, so I'm looking > > > > > > > > for > > > > > > > > > options there also. > > > > > > > > > > > > > > > > > > SJIS is about as much multibyte as UTF-8. > > > > > > > > > > > > > > > > > > Why do you think less does not support it? > > > > > > > > > > > > > > > > > > Last time I looked there was SJIS locale for libc so it > > > > > > > > > is only matter of generating the correct locales and > > > > > > > > > using them. Of course, if you are > > > > > > > > running > > > > > > > > > in UTF-8 SJIS will look like garbage. > > > > > > > > > > > > > > > > Sadly, I did not personally build less on this platform, > > > > > > > > and the libc used did not include UTF-16, on the platform > > > > > > > > vendor supplied less. cat works fine, but the usual > > > > > > > > LESSCHARSET=utf-16 is unsupported, so I am looking for an > > > > > > > > alternative. THAT is why I think less does not support it. > > > > > > > > Sorry, I should have made that more > > > > > clear. > > > > > > > > > > > > > > > > cat works fine, so if I set GIT_PAGER=cat, I can at least > > > > > > > > see the diffs cleanly in SJIS, but this partner wants a pager > > > > > > > > that is > usable. > > > > > > > > > > > > > > > > > > > > > > So you want to use SJIS because UTF-16 is not supported. So > > > > > > > what is the problem with SJIS (or UTF-8 for that matter)? > > > > > > > > > > > > The partner I am working with is using multi-byte SJIS, which > > > > > > is also not > > > > > supported by this incarnation of less. As a result, UTF-8 does > > > > > not work either in this situation. The content is definitely > > > > > multi-byte. > > > > > I know this was fixed in RedHat's Less in 2016, but did not make > > > > > this > > > platform. > > > > > > > > > > > > > > > > Both UTF-8 and SJIS is multibyte and both is supported by less > > > > > in general. If your particular less cannot support it then it is > > > > > broken and you should fix it or get it fixed. > > > > > > > > To be more specific, the implementation of less' UTF-8 on this > > > > platform will > > > present the data as unusable junk as expected. SJIS is multi-byte, > > > but is not one of the allowed encodings in less. I am not empowered to > "get it fixed". > > > Thanks for your advice. > > > > > > > > > > How is this 'allowed encodings in less' defined? > > > > When you run less with LESSCHARSET=encoding, if the encoding is not > known, you get the error: > > invalid charset name > > > > Doing the due diligence, I actually read the man page on the platform > before asking the question, which listed the following as the only allowed > encodings: ascii, iso8859, latin1, latin9, dos, IBM-1047, koi8-r, next, utf-8, > windows. The utf-8 variant does not know how to display its multi-byte > forms in SJIS, as with other platforms. Does that make sense now? > > > > Does the said man page also mention LESSCHARDEF or LESSOPEN? Of course it does.
RE: Need multibyte advice - Shift-JIS
On February 27, 2019 11:52, Michal SuchĂĄnek wrote: > To: Randall S. Becker > Cc: git@vger.kernel.org > Subject: Re: Need multibyte advice - Shift-JIS > > On Wed, 27 Feb 2019 11:33:47 -0500 > "Randall S. Becker" wrote: > > > On February 27, 2019 11:29 Michal SuchĂĄnek wrote: > > > On Wed, 27 Feb 2019 11:19:33 -0500 > > > "Randall S. Becker" wrote: > > > > > > > On February 27, 2019 11:11, Michal SuchĂĄnek wrote: > > > > > On Wed, 27 Feb 2019 10:54:23 -0500 "Randall S. Becker" > > > > > wrote: > > > > > > > > > > > On February 27, 2019 9:09, Michal SuchĂĄnek wrote: > > > > > > > On Wed, 27 Feb 2019 08:04:08 -0500 "Randall S. Becker" > > > > > > > wrote: > > > > > > > > > > > > > > > Hi Git Team, > > > > > > > > > > > > > > > > I have to admit being perplexed by this one. I have been > > > > > > > > asked to support the Shift-JIS character set in file > > > > > > > > contents, comments, and logs, for a partner of mine. I > > > > > > > > know there are a few ways to do this, but I'm looking for > > > > > > > > the official non-hacky way > > > to do this. > > > > > > > > This is CLI only, and our pager, less, does not support > > > > > > > > multi-byte, so I'm looking > > > > > > for > > > > > > > options there also. > > > > > > > > > > > > > > SJIS is about as much multibyte as UTF-8. > > > > > > > > > > > > > > Why do you think less does not support it? > > > > > > > > > > > > > > Last time I looked there was SJIS locale for libc so it is > > > > > > > only matter of generating the correct locales and using > > > > > > > them. Of course, if you are > > > > > > running > > > > > > > in UTF-8 SJIS will look like garbage. > > > > > > > > > > > > Sadly, I did not personally build less on this platform, and > > > > > > the libc used did not include UTF-16, on the platform vendor > > > > > > supplied less. cat works fine, but the usual > > > > > > LESSCHARSET=utf-16 is unsupported, so I am looking for an > > > > > > alternative. THAT is why I think less does not support it. > > > > > > Sorry, I should have made that more > > > clear. > > > > > > > > > > > > cat works fine, so if I set GIT_PAGER=cat, I can at least see > > > > > > the diffs cleanly in SJIS, but this partner wants a pager that is > > > > > > usable. > > > > > > > > > > > > > > > > So you want to use SJIS because UTF-16 is not supported. So what > > > > > is the problem with SJIS (or UTF-8 for that matter)? > > > > > > > > The partner I am working with is using multi-byte SJIS, which is > > > > also not > > > supported by this incarnation of less. As a result, UTF-8 does not > > > work either in this situation. The content is definitely multi-byte. > > > I know this was fixed in RedHat's Less in 2016, but did not make this > platform. > > > > > > > > > > Both UTF-8 and SJIS is multibyte and both is supported by less in > > > general. If your particular less cannot support it then it is broken > > > and you should fix it or get it fixed. > > > > To be more specific, the implementation of less' UTF-8 on this platform will > present the data as unusable junk as expected. SJIS is multi-byte, but is not > one of the allowed encodings in less. I am not empowered to "get it fixed". > Thanks for your advice. > > > > How is this 'allowed encodings in less' defined? When you run less with LESSCHARSET=encoding, if the encoding is not known, you get the error: invalid charset name Doing the due diligence, I actually read the man page on the platform before asking the question, which listed the following as the only allowed encodings: ascii, iso8859, latin1, latin9, dos, IBM-1047, koi8-r, next, utf-8, windows. The utf-8 variant does not know how to display its multi-byte forms in SJIS, as with other platforms. Does that make sense now?
RE: Need multibyte advice - Shift-JIS
On February 27, 2019 11:29 Michal SuchĂĄnek wrote: > On Wed, 27 Feb 2019 11:19:33 -0500 > "Randall S. Becker" wrote: > > > On February 27, 2019 11:11, Michal SuchĂĄnek wrote: > > > On Wed, 27 Feb 2019 10:54:23 -0500 > > > "Randall S. Becker" wrote: > > > > > > > On February 27, 2019 9:09, Michal SuchĂĄnek wrote: > > > > > On Wed, 27 Feb 2019 08:04:08 -0500 "Randall S. Becker" > > > > > wrote: > > > > > > > > > > > Hi Git Team, > > > > > > > > > > > > I have to admit being perplexed by this one. I have been asked > > > > > > to support the Shift-JIS character set in file contents, > > > > > > comments, and logs, for a partner of mine. I know there are a > > > > > > few ways to do this, but I'm looking for the official non-hacky way > to do this. > > > > > > This is CLI only, and our pager, less, does not support > > > > > > multi-byte, so I'm looking > > > > for > > > > > options there also. > > > > > > > > > > SJIS is about as much multibyte as UTF-8. > > > > > > > > > > Why do you think less does not support it? > > > > > > > > > > Last time I looked there was SJIS locale for libc so it is only > > > > > matter of generating the correct locales and using them. Of > > > > > course, if you are > > > > running > > > > > in UTF-8 SJIS will look like garbage. > > > > > > > > Sadly, I did not personally build less on this platform, and the > > > > libc used did not include UTF-16, on the platform vendor supplied > > > > less. cat works fine, but the usual LESSCHARSET=utf-16 is > > > > unsupported, so I am looking for an alternative. THAT is why I > > > > think less does not support it. Sorry, I should have made that more > clear. > > > > > > > > cat works fine, so if I set GIT_PAGER=cat, I can at least see the > > > > diffs cleanly in SJIS, but this partner wants a pager that is usable. > > > > > > > > > > So you want to use SJIS because UTF-16 is not supported. So what is > > > the problem with SJIS (or UTF-8 for that matter)? > > > > The partner I am working with is using multi-byte SJIS, which is also not > supported by this incarnation of less. As a result, UTF-8 does not work either > in this situation. The content is definitely multi-byte. I know this was > fixed in > RedHat's Less in 2016, but did not make this platform. > > > > Both UTF-8 and SJIS is multibyte and both is supported by less in general. If > your particular less cannot support it then it is broken and you should fix > it or > get it fixed. To be more specific, the implementation of less' UTF-8 on this platform will present the data as unusable junk as expected. SJIS is multi-byte, but is not one of the allowed encodings in less. I am not empowered to "get it fixed". Thanks for your advice.
RE: Need multibyte advice - Shift-JIS
On February 27, 2019 11:11, Michal SuchĂĄnek wrote: > On Wed, 27 Feb 2019 10:54:23 -0500 > "Randall S. Becker" wrote: > > > On February 27, 2019 9:09, Michal SuchĂĄnek wrote: > > > On Wed, 27 Feb 2019 08:04:08 -0500 > > > "Randall S. Becker" wrote: > > > > > > > Hi Git Team, > > > > > > > > I have to admit being perplexed by this one. I have been asked to > > > > support the Shift-JIS character set in file contents, comments, > > > > and logs, for a partner of mine. I know there are a few ways to do > > > > this, but I'm looking for the official non-hacky way to do this. > > > > This is CLI only, and our pager, less, does not support > > > > multi-byte, so I'm looking > > for > > > options there also. > > > > > > SJIS is about as much multibyte as UTF-8. > > > > > > Why do you think less does not support it? > > > > > > Last time I looked there was SJIS locale for libc so it is only > > > matter of generating the correct locales and using them. Of course, > > > if you are > > running > > > in UTF-8 SJIS will look like garbage. > > > > Sadly, I did not personally build less on this platform, and the libc > > used did not include UTF-16, on the platform vendor supplied less. cat > > works fine, but the usual LESSCHARSET=utf-16 is unsupported, so I am > > looking for an alternative. THAT is why I think less does not support > > it. Sorry, I should have made that more clear. > > > > cat works fine, so if I set GIT_PAGER=cat, I can at least see the > > diffs cleanly in SJIS, but this partner wants a pager that is usable. > > > > So you want to use SJIS because UTF-16 is not supported. So what is the > problem with SJIS (or UTF-8 for that matter)? The partner I am working with is using multi-byte SJIS, which is also not supported by this incarnation of less. As a result, UTF-8 does not work either in this situation. The content is definitely multi-byte. I know this was fixed in RedHat's Less in 2016, but did not make this platform.
RE: Need multibyte advice - Shift-JIS
On February 27, 2019 9:09, Michal SuchĂĄnek wrote: > On Wed, 27 Feb 2019 08:04:08 -0500 > "Randall S. Becker" wrote: > > > Hi Git Team, > > > > I have to admit being perplexed by this one. I have been asked to > > support the Shift-JIS character set in file contents, comments, and > > logs, for a partner of mine. I know there are a few ways to do this, > > but I'm looking for the official non-hacky way to do this. This is CLI > > only, and our pager, less, does not support multi-byte, so I'm looking for > options there also. > > SJIS is about as much multibyte as UTF-8. > > Why do you think less does not support it? > > Last time I looked there was SJIS locale for libc so it is only matter of > generating the correct locales and using them. Of course, if you are running > in UTF-8 SJIS will look like garbage. Sadly, I did not personally build less on this platform, and the libc used did not include UTF-16, on the platform vendor supplied less. cat works fine, but the usual LESSCHARSET=utf-16 is unsupported, so I am looking for an alternative. THAT is why I think less does not support it. Sorry, I should have made that more clear. cat works fine, so if I set GIT_PAGER=cat, I can at least see the diffs cleanly in SJIS, but this partner wants a pager that is usable.
Need multibyte advice - Shift-JIS
Hi Git Team, I have to admit being perplexed by this one. I have been asked to support the Shift-JIS character set in file contents, comments, and logs, for a partner of mine. I know there are a few ways to do this, but I'm looking for the official non-hacky way to do this. This is CLI only, and our pager, less, does not support multi-byte, so I'm looking for options there also. I normally do all of my UTF-16 work from a workstation via ECLIPSE, with UTF-8 comments, so never really have encountered this as an issue. Although our UTF-16 HTML files look pretty ugly in a diff. The platform (NonStop) does not have a lot of UTF-16 tooling by default (less does not support it), so I may have to write stuff, which is no issue. We are on 2.21.0 officially as of yesterday. Kind Regards, Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: [BUG] git log -L ... -s does not suppress diff output
On February 25, 2019 12:18, Jeff King wrote: > To: Matthew Booth > Cc: git@vger.kernel.org > Subject: Re: [BUG] git log -L ... -s does not suppress diff output > > On Mon, Feb 25, 2019 at 05:03:50PM +, Matthew Booth wrote: > > > Example output: > > > > = > > $ git --version > > git version 2.20.1 > > > > $ git log -L 2957,3107:nova/compute/manager.py -s commit > > 35ce77835bb271bad3c18eaf22146edac3a42ea0 > > > > > > diff --git a/nova/compute/manager.py b/nova/compute/manager.py > > --- a/nova/compute/manager.py > > +++ b/nova/compute/manager.py > > @@ -2937,152 +2921,151 @@ > > def rebuild_instance(self, context, instance, orig_image_ref, > > image_ref, > > injected_files, new_pass, orig_sys_metadata, > > = > > At first I wondered why you would want to do this, since the point of -L is to > walk through that diff. But I suppose you might want to see just the commits, > without the actual patch, and that's what "-s" ought to do. > > > git log docs suggest it should not do this: > > > >-s, --no-patch > >Suppress diff output. Useful for commands like git show > > that show the patch by default, or to cancel > >the effect of --patch. > > > > Couldn't find anything in a search of the archives of this mailing > > list, although that's obviously far from conclusive. Seems to be > > longstanding, as it was mentioned on StackOverflow back in 2015: > > I think the issue is just that "-L" follows a very different code path than > the > normal diff generator. Perhaps something like this helps? > > diff --git a/line-log.c b/line-log.c > index 63df51a08f..ed46a3a493 100644 > --- a/line-log.c > +++ b/line-log.c > @@ -1106,7 +1106,8 @@ int line_log_print(struct rev_info *rev, struct > commit *commit) > struct line_log_data *range = lookup_line_range(rev, commit); > > show_log(rev); > - dump_diff_hacky(rev, range); > + if (!(rev->diffopt.output_format & DIFF_FORMAT_NO_OUTPUT)) > + dump_diff_hacky(rev, range); > return 1; > } I hit this about 6 months ago while trying to show off git to some colleagues - it was on 2.8.5. Sadly I forgot about it. Glad it came back. Thanks.
Re: [ANNOUNCE] Git v2.21.0
Just some good news. We have two platform variants in NonStop to worry about (soon to be three). Our testing is being conducted on the oldest and slowest (J-series) so that we catch whatever we can. 2.21.0 one is still testing 2.21.0 in our Jenkins instance on J-series but is looking consistent with rc2 (although we're just entering the scary tests area 5300-5599). The newer L-series machines had no trouble at all and passed (other than the usual t9001 and t9020 which won't work on platform anyway). Test time was about 9 hours on our L-series machine compared with 50-ish on the J-series. Thanks for the hard work everyone!
RE: Fetching master branch with tags associated with it
On February 22, 2019 11:07, Jeff King wrote: > To: Dominik Salvet > Cc: git@vger.kernel.org > Subject: Re: Fetching master branch with tags associated with it > > On Thu, Feb 21, 2019 at 06:02:54PM +0100, Dominik Salvet wrote: > > > Now, I want to refresh the repository the same way - fetching only > > commits from the master branch and tags that are pointing to the > > master branch and also refresh those tags as well in case of their > > target commit change at the remote (you can expect that it always > > points to a master commit). Nevertheless, I don't really know how to > > do it. The closest I got, are the following commands: > > > > ```sh > > git fetch --tags origin master && > > git merge FETCH_HEAD > > ``` > > > > However, there obviously are some problems with this solution. The > > `--tags` flag will cause to fetch tags from all branches. Furthermore, > > it will fetch also their commits, which is absolutely what I don't > > want to. > > > > I have Git 2.17.1 (on Ubuntu 18.04.2) and in its `git fetch --help` is > > stated, if I understood it correctly, that without passing neither > > `--tags` nor `--no-tags`, it will do exactly what I want. > > Nevertheless, without using any of the mentioned flags, it behaves > > more like using `--no-tags`. > > Generally yes, that's how it's supposed to work. However, I think tag- > following does not kick in when you've given a specific refspec. > > So take this toy setup for example: > > -- >8 -- > git init repo > cd repo > > # one tags accessible from master > git commit --allow-empty -m one > git tag one > > # one tag accessible only from "other" > git checkout -b other > git commit --allow-empty -m two > git tag two > > # now fetch into another repository > git init child > cd child > git remote add origin .. > git fetch origin master > -- 8< -- > > That won't pick up the "one" tag in that final fetch. But if you use the > normal > configured refspec (but tell it only to grab "master"): > > git config remote.origin.fetch > refs/heads/master:refs/remotes/origin/master > git fetch origin > > then it works. I don't know if there's a less-awkward way to get what you > want, though. It really seems like there should be a "--tags=follow" > or similar. This may be restating, but I had a received request a while back to fetch only tags commits known to the repository. The scenario here is as follows: git clone --depth=1 url-ish git fetch --depth=1 --tags This actually fetches all tags and expands the depth of the repository to the whole history to provide the basis for all of the tags. What I would have anticipated is that the HEAD commit from the depth=1, if it had a tag, would fetch that tag, and then expand the history of the tag in support of it, but only if the tag were signed. If the tag is not signed, I'm not sure that the history to build it is required, since the same argument could be made for the HEAD commit itself. If there was no tag on the HEAD commit, there would be no tag fetched in this situation. So to further the request above, a fetch of tags of known unsigned tags seems reasonable, in a depth restricted situation or a branch limited situation. In an island of sparceness situation, with gaps in the history, I can see how git describe would give wildly wrong answers, but having those gaps could break the validation of signed tags anyway. Of course, my expectations may be completely wrong here. Regards, Randall
RE: [Suggestion] Add Skip for t9020
On February 21, 2019 19:47, Jonathan Nieder wrote: > Randall S. Becker wrote: > > > While this is a bit of a hack, it might be useful for skipping t9020 > > in environments where the svn.remote package is not installed. I can > > make this into a patch if this style is reasonable - guessing probably > > not and that the REMOTE_SVN test should go elsewhere if it is called that. > > > > diff --git a/t/t9020-remote-svn.sh b/t/t9020-remote-svn.sh index > > 6fca08e5e3..31edf99371 100755 > > --- a/t/t9020-remote-svn.sh > > +++ b/t/t9020-remote-svn.sh > > @@ -12,6 +12,12 @@ then > > test_done > > fi > > > > +python -c "import svn.remote" 2>/dev/null >/dev/null if [ $? -eq 0 ]; > > +then > > + test_set_prereq REMOTE_SVN > > +fi > > +if ! test_have_prereq REMOTE_SVN > > +then > > + skip_all='skipping remote-svn tests, python svn.remote not > > available' > > + test_done > > +fi > > Interesting. Where do we use the svn.remote package? I did a quick grep > and didn't find any instances. Well, this was the remote svn test, so I figured I would be specific. We don't have the svn package either so could restrict to that. > Do you have output from running "./t9020-remote-svn.sh -v -i"? Initialized empty Git repository in /home/git/git/t/trash directory.t9020-remote-svn/.git/ expecting success: init_git && git fetch svnsim && test_cmp .git/refs/svn/svnsim/master .git/refs/remotes/svnsim/master && cp .git/refs/remotes/svnsim/master master.good Initialized empty Git repository in /home/git/git/t/trash directory.t9020-remote-svn/.git/ fatal: error reading from fast-import: Resource temporarily unavailable progress Imported commit 1. fatal: error while running fast-import not ok 1 - simple fetch # # init_git && # git fetch svnsim && # test_cmp .git/refs/svn/svnsim/master .git/refs/remotes/svnsim/master && # cp .git/refs/remotes/svnsim/master master.good #
RE: [ANNOUNCE] Git v2.21.0-rc2
On February 21, 2019 16:07, SZEDER GĂĄbor: > On Thu, Feb 21, 2019 at 10:54:31AM -0500, Randall S. Becker wrote: > > /home/git/git/t: sh t4153-am-resume-override-opts.sh ok 1 - setup ok 2 > > # skip --3way overrides --no-3way (missing TTY) ok 3 - --no-quiet > > overrides --quiet ok 4 - --signoff overrides --no-signoff ok 5 # skip > > --reject overrides --no-reject (missing TTY) # passed all 5 test(s) > > 1..5 > > > > Technically, we have TTY, but not that dev. The TTYs are not under > > /dev/tty*, however. > > The TTY prereq is not about /dev/tty, but about whether 't/test-terminal.perl' > can simulate a pseudo-terminal, i.e. the necessary Perl modules are installed > and working appropriately. Good point. We don't have IO:Pty on the platform.
[Suggestion] Add Skip for t9020
On February 21, 2019 15:00, I wrote:
> To: 'Junio C Hamano'
> Cc: git@vger.kernel.org; 'Johannes Schindelin'
> ; 'Duy Nguyen'
> Subject: RE: [ANNOUNCE] Git v2.21.0-rc2
>
> On February 21, 2019 10:55, I wrote:
> > On February 20, 2019 14:42, Junio C Hamano wrote:
> > > "Randall S. Becker" writes:
> > >
> > > > On February 19, 2019 18:29, Junio C Hamano wrote:
> > > >> A release candidate Git v2.21.0-rc2 is now available for testing
> > > >> at the usual places. It is comprised of 474 non-merge commits
> > > >> since v2.20.0, contributed by 61 people, 16 of which are new faces.
> > > >
> > > > Thanks. t5562 works properly on NonStop (3 tests under various
loads).
> > > > I am starting a full regression test now - see you in two days or
> > > > so with a full report.
> > >
> > > Thanks. In the end I ended up doing the following:
> > >
> > > - kept most of your "feed NULs generated from a helper program via
> > >pipe, instead of reading from /dev/zero" patch,
> > >
> > > - replaced the helper program used in the above with the test-tool
> > >one by Dscho,
> > >
> > > - used Max's "do not reuse the output file---the background writer
> > >about to die may still have it open when the next test starts",
> > >
> > > - used Max's "when testing the program with overly large input
> > >declared with content-length, do not have to feed from /dev/zero;
> > >/dev/null suffices as a mistaken program attempting to read would
> > >die when seeing EOF anyway" patch to reduce one mention of
> > >/dev/zero (or one pipe from the helper output) further.
> > >
> > > Hopefully Dscho's Azure thing would also be happy with one less use
> > > of Perl script.
> > >
> > > As I said earlier, a few places in t/ still mention /dev/zero and I
> > > think it is a real bug on platforms without /dev/zero in t4153:
> > >
> > > $ git grep -h dev/zero t/
> > > test_must_fail test_terminal git am --3way > > test_must_fail test_terminal git am --reject > > &&
> > >
> > > Curiously, applying the attached patch and running the test on Linux
> > > would notice that we do not have such a device file, and the use of
> > > test_must_fail does *not* make it a-OK [*]. I am not sure why you
> > > are not getting hit by the same issue.
> > >
> > > Side note: test_must_fail is to ensure that the command
> > > exits in a controlled way without segfault, so at the first
> > > glance, replacing /dev/zero with something nonsensical and
> > > nonexistent ought to make the command pass, but that is not
> > > the case. The shell notices redirection failure and aborts
> > > the &&-chain. This behaviour matches what we want, so I
> > > won't complain ;-)
> > >
> > > Another mention of /dev/zero appears in t/helper/test-sha1.sh (not
> > > to be confused with t/helper/test-sha1.c). This seems to be run
> > > only with an explicit "make -C t/helper check-sha1" request, so
> > > perhaps nobody on your platform ran it to get hit by it. I wonder
> > > if anybody runs this on any platform, to be honest, though. Duy
> > > Cc'ed as the last person to touch that particular target---yes, I
> > > know I was guilty of introducing it in b65bc21e ("Makefile: add
> > > framework to verify and
> > bench sha1 implementations.", 2006-06-24).
> > >
> > > t/t4153-am-resume-override-opts.sh | 4 ++--
> > > 1 file changed, 2 insertions(+), 2 deletions(-)
> > >
> > > diff --git a/t/t4153-am-resume-override-opts.sh b/t/t4153-am-resume-
> > > override-opts.sh index 8ea22d1bcb..29ef22c94f 100755
> > > --- a/t/t4153-am-resume-override-opts.sh
> > > +++ b/t/t4153-am-resume-override-opts.sh
> > > @@ -40,7 +40,7 @@ test_expect_success TTY '--3way overrides --no-
> > 3way' '
> > >
> > > # Applying side1 with am --3way will succeed due to the threeway-
> > > merge.
> > > # Applying side2 will fail as --3way does not apply to it.
> > > - test_must_fail test_terminal git am --3way > > + test_must_fail test_terminal git am --3way > > test_path_is_dir .git/rebase-apply &&
> > > test side1 = "$(cat file2)&qu
RE: [ANNOUNCE] Git v2.21.0-rc2
On February 21, 2019 10:55, I wrote:
> On February 20, 2019 14:42, Junio C Hamano wrote:
> > "Randall S. Becker" writes:
> >
> > > On February 19, 2019 18:29, Junio C Hamano wrote:
> > >> A release candidate Git v2.21.0-rc2 is now available for testing at
> > >> the usual places. It is comprised of 474 non-merge commits since
> > >> v2.20.0, contributed by 61 people, 16 of which are new faces.
> > >
> > > Thanks. t5562 works properly on NonStop (3 tests under various loads).
> > > I am starting a full regression test now - see you in two days or so
> > > with a full report.
> >
> > Thanks. In the end I ended up doing the following:
> >
> > - kept most of your "feed NULs generated from a helper program via
> >pipe, instead of reading from /dev/zero" patch,
> >
> > - replaced the helper program used in the above with the test-tool
> >one by Dscho,
> >
> > - used Max's "do not reuse the output file---the background writer
> >about to die may still have it open when the next test starts",
> >
> > - used Max's "when testing the program with overly large input
> >declared with content-length, do not have to feed from /dev/zero;
> >/dev/null suffices as a mistaken program attempting to read would
> >die when seeing EOF anyway" patch to reduce one mention of
> >/dev/zero (or one pipe from the helper output) further.
> >
> > Hopefully Dscho's Azure thing would also be happy with one less use of
> > Perl script.
> >
> > As I said earlier, a few places in t/ still mention /dev/zero and I
> > think it is a real bug on platforms without /dev/zero in t4153:
> >
> > $ git grep -h dev/zero t/
> > test_must_fail test_terminal git am --3way > test_must_fail test_terminal git am --reject >
> > Curiously, applying the attached patch and running the test on Linux
> > would notice that we do not have such a device file, and the use of
> > test_must_fail does *not* make it a-OK [*]. I am not sure why you are
> > not getting hit by the same issue.
> >
> > Side note: test_must_fail is to ensure that the command
> > exits in a controlled way without segfault, so at the first
> > glance, replacing /dev/zero with something nonsensical and
> > nonexistent ought to make the command pass, but that is not
> > the case. The shell notices redirection failure and aborts
> > the &&-chain. This behaviour matches what we want, so I
> > won't complain ;-)
> >
> > Another mention of /dev/zero appears in t/helper/test-sha1.sh (not to
> > be confused with t/helper/test-sha1.c). This seems to be run only
> > with an explicit "make -C t/helper check-sha1" request, so perhaps
> > nobody on your platform ran it to get hit by it. I wonder if anybody
> > runs this on any platform, to be honest, though. Duy Cc'ed as the
> > last person to touch that particular target---yes, I know I was guilty
> > of introducing it in b65bc21e ("Makefile: add framework to verify and
> bench sha1 implementations.", 2006-06-24).
> >
> > t/t4153-am-resume-override-opts.sh | 4 ++--
> > 1 file changed, 2 insertions(+), 2 deletions(-)
> >
> > diff --git a/t/t4153-am-resume-override-opts.sh b/t/t4153-am-resume-
> > override-opts.sh index 8ea22d1bcb..29ef22c94f 100755
> > --- a/t/t4153-am-resume-override-opts.sh
> > +++ b/t/t4153-am-resume-override-opts.sh
> > @@ -40,7 +40,7 @@ test_expect_success TTY '--3way overrides --no-
> 3way' '
> >
> > # Applying side1 with am --3way will succeed due to the threeway-
> > merge.
> > # Applying side2 will fail as --3way does not apply to it.
> > - test_must_fail test_terminal git am --3way > + test_must_fail test_terminal git am --3way > test_path_is_dir .git/rebase-apply &&
> > test side1 = "$(cat file2)"
> > '
> > @@ -94,7 +94,7 @@ test_expect_success TTY '--reject overrides --no-
> reject'
> > '
> > test_path_is_dir .git/rebase-apply &&
> > test_path_is_missing file.rej &&
> >
> > - test_must_fail test_terminal git am --reject > + test_must_fail test_terminal git am --reject > test_path_is_dir .git/rebase-apply &&
> > test_path_is_file file.rej
> > '
>
> Here's what we get with this patch (and without it):
>
> /home/git/git/t: sh t4153-am-resume-override-opts.sh
RE: [ANNOUNCE] Git v2.21.0-rc2
On February 20, 2019 14:42, Junio C Hamano wrote:
> "Randall S. Becker" writes:
>
> > On February 19, 2019 18:29, Junio C Hamano wrote:
> >> A release candidate Git v2.21.0-rc2 is now available for testing at
> >> the usual places. It is comprised of 474 non-merge commits since
> >> v2.20.0, contributed by 61 people, 16 of which are new faces.
> >
> > Thanks. t5562 works properly on NonStop (3 tests under various loads).
> > I am starting a full regression test now - see you in two days or so
> > with a full report.
>
> Thanks. In the end I ended up doing the following:
>
> - kept most of your "feed NULs generated from a helper program via
>pipe, instead of reading from /dev/zero" patch,
>
> - replaced the helper program used in the above with the test-tool
>one by Dscho,
>
> - used Max's "do not reuse the output file---the background writer
>about to die may still have it open when the next test starts",
>
> - used Max's "when testing the program with overly large input
>declared with content-length, do not have to feed from /dev/zero;
>/dev/null suffices as a mistaken program attempting to read would
>die when seeing EOF anyway" patch to reduce one mention of
>/dev/zero (or one pipe from the helper output) further.
>
> Hopefully Dscho's Azure thing would also be happy with one less use of
Perl
> script.
>
> As I said earlier, a few places in t/ still mention /dev/zero and I think
it is a
> real bug on platforms without /dev/zero in t4153:
>
> $ git grep -h dev/zero t/
> test_must_fail test_terminal git am --3way test_must_fail test_terminal git am --reject
> Curiously, applying the attached patch and running the test on Linux would
> notice that we do not have such a device file, and the use of
test_must_fail
> does *not* make it a-OK [*]. I am not sure why you are not getting hit by
> the same issue.
>
> Side note: test_must_fail is to ensure that the command
> exits in a controlled way without segfault, so at the first
> glance, replacing /dev/zero with something nonsensical and
> nonexistent ought to make the command pass, but that is not
> the case. The shell notices redirection failure and aborts
> the &&-chain. This behaviour matches what we want, so I
> won't complain ;-)
>
> Another mention of /dev/zero appears in t/helper/test-sha1.sh (not to be
> confused with t/helper/test-sha1.c). This seems to be run only with an
> explicit "make -C t/helper check-sha1" request, so perhaps nobody on your
> platform ran it to get hit by it. I wonder if anybody runs this on any
platform,
> to be honest, though. Duy Cc'ed as the last person to touch that
particular
> target---yes, I know I was guilty of introducing it in b65bc21e
("Makefile: add
> framework to verify and bench sha1 implementations.", 2006-06-24).
>
> t/t4153-am-resume-override-opts.sh | 4 ++--
> 1 file changed, 2 insertions(+), 2 deletions(-)
>
> diff --git a/t/t4153-am-resume-override-opts.sh b/t/t4153-am-resume-
> override-opts.sh
> index 8ea22d1bcb..29ef22c94f 100755
> --- a/t/t4153-am-resume-override-opts.sh
> +++ b/t/t4153-am-resume-override-opts.sh
> @@ -40,7 +40,7 @@ test_expect_success TTY '--3way overrides --no-3way' '
>
> # Applying side1 with am --3way will succeed due to the threeway-
> merge.
> # Applying side2 will fail as --3way does not apply to it.
> - test_must_fail test_terminal git am --3way + test_must_fail test_terminal git am --3waytest_path_is_dir .git/rebase-apply &&
> test side1 = "$(cat file2)"
> '
> @@ -94,7 +94,7 @@ test_expect_success TTY '--reject overrides --no-reject'
> '
> test_path_is_dir .git/rebase-apply &&
> test_path_is_missing file.rej &&
>
> - test_must_fail test_terminal git am --reject + test_must_fail test_terminal git am --rejecttest_path_is_dir .git/rebase-apply &&
> test_path_is_file file.rej
> '
Here's what we get with this patch (and without it):
/home/git/git/t: sh t4153-am-resume-override-opts.sh
ok 1 - setup
ok 2 # skip --3way overrides --no-3way (missing TTY)
ok 3 - --no-quiet overrides --quiet
ok 4 - --signoff overrides --no-signoff
ok 5 # skip --reject overrides --no-reject (missing TTY)
# passed all 5 test(s)
1..5
Technically, we have TTY, but not that dev. The TTYs are not under
/dev/tty*, however.
Regards,
Randall
RE: [Breakage] t0021 Subtest 15 v2.21.0.-rc2 on NonStop.
On February 20, 2019 7:53, SZEDER GĂĄbor wrote: > On Wed, Feb 20, 2019 at 07:12:49AM -0500, Randall S. Becker wrote: > > Sadly I have to report that this subtest breaks on NonStop as of > > v2.21.0-rc2. It succeeds when run with --verbose, but not without, > > making this difficult to diagnose. > > That particular test is known to be flaky, see: > > > https://public-inbox.org/git/000901d4bf98$1ab08fe0$5011afa0$@nexbridge.com/T/#u Agree, but it's been a while since it broke here. And subtest 15 never did from what I can tell.
[Breakage] t0021 Subtest 15 v2.21.0.-rc2 on NonStop.
Sadly I have to report that this subtest breaks on NonStop as of v2.21.0-rc2. It succeeds when run with --verbose, but not without, making this difficult to diagnose. Sincerely, Randall
RE: [ANNOUNCE] Git v2.21.0-rc2
On February 19, 2019 18:29, Junio C Hamano wrote: > A release candidate Git v2.21.0-rc2 is now available for testing at the usual > places. It is comprised of 474 non-merge commits since v2.20.0, contributed > by 61 people, 16 of which are new faces. Thanks. t5562 works properly on NonStop (3 tests under various loads). I am starting a full regression test now - see you in two days or so with a full report. Regards, Randall
RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News
On February 19, 2019 15:16, Max Kirillov wrote: > On Mon, Feb 18, 2019 at 10:57:13PM +0100, Johannes Schindelin wrote: > > I have to take that assessment back. So sad. > > > > After that build, I cherry-picked the commit on top of shears/pu > > (which is Git for Windows' ever-green branch that continuously rebases > > Git for Windows' `master` onto git.git's `pu`), and the build seems to hang > again: > > > > https://dev.azure.com/git-for-windows/git/_build/results?buildId=31291 > > Hi. > > You seem to be talking about the hang like it's some old thing, I probably > have missed some earlier discussion. I have not heard before that it hangs on > linux. The 60 seconds hang because of lost SIGCHILD is not it. Also the hang > observed at NonStop is not it as well since the no-reuse hack did not help > (though numbered output files probably would be more sure to avoid > duplications expecially at Windows where you cannot just unlink busy file and > reuse its place in directory) > > >From the tasks you have posted there seem to be no details > available. The test is not reported as completed, and the overall build fails, > and there seem to no additional data except the log available. > > Have you or somebody else been investigating it or is there otherwise any > information about those hangs? The no-reuse hack made a big different (https://public-inbox.org/git/20181124093719.10705-1-...@max630.net/) in conjunction with replacing "Randall S. Becker" writes: > > On February 16, 2019 3:27, Max Kirillov wrote: > >> What you could try is > >> https://public-inbox.org/git/20181124093719.10705-1- > m...@max630.net/ > >> (I'm not sure it would not conflict by now), this would remove > >> dependency between tests. If it helps it would be very valuable > information. > > > > Good news. This patch does seem to do the trick. I wonder whether > > this fixes the Azure build also. > > > > I have run the test under the following conditions: > > Run 1 (system idle): Pass > > Run 2 (system idle): Pass > > Run 3 (system idle): Pass > > Run 4 (system idle): Pass > > Run 5 (system idle): Pass > > Run 6 (system mild load, heavy file system): Pass Run 7 (system mild > > load, moderate file system load - git fetch): Pass Run 8 (heavy > > system load, heavy file system load): Pass Run 9 (--verbose, heavy > > system load, heavy file system load): Pass Run 10 (GIT_TRACE=true, > > --verbose, heavy system load, heavy file system > > load): Pass > > Run 11 (very heavy system load, very heavy file system load): Pass > > That indeed is a good news. > > > The current condition of the code is (the generate_zero_bytes delete > > was previously removed so can be ignored for the patch): > > Just to make sure I do not misunderstand, this result is with Max's > patch but without the generate_zero_bytes stuff? Correct.
RE: [PATCH 0/1] Fix hang in t5562, introduced in v2.21.0-rc1
On February 18, 2019 15:41, Johannes Schindelin wrote: > To: Randall S. Becker > Cc: 'Junio C Hamano' ; 'Johannes Schindelin via > GitGitGadget' ; git@vger.kernel.org; 'Max Kirillov' > > Subject: RE: [PATCH 0/1] Fix hang in t5562, introduced in v2.21.0-rc1 > > Hi Randall, > > On Thu, 14 Feb 2019, Randall S. Becker wrote: > > > On February 14, 2019 17:39, Junio C Hamano wrote: > > > To: Randall S. Becker > > > Cc: 'Johannes Schindelin via GitGitGadget' ; > > > git@vger.kernel.org; 'Max Kirillov' > > > Subject: Re: [PATCH 0/1] Fix hang in t5562, introduced in > > > v2.21.0-rc1 > > > > > > "Randall S. Becker" writes: > > > > > > > Unfortunately, subtest 13 still hangs on NonStop, even with this > > > > patch, so our Pipeline still hangs. I'm glad it's better on Azure, > > > > but I don't think this actually addresses the root cause of the hang. > > > > > > Sigh. > > > > > > > possible this is not the test that is failing, but actually the > > > > git-http-backend? The code is not in a loop, if that helps. It is > > > > not consuming any significant cycles. I don't know that part of > > > > the code at all, sadly. The code is here: > > > > > > > > * in the operating system from here up * > > > > cleanup_children + 0x5D0 (UCr) > > > > cleanup_children_on_exit + 0x70 (UCr) > > > > git_atexit_dispatch + 0x200 (UCr) > > > > __process_atexit_functions + 0xA0 (DLL zcredll) > > > > CRE_TERMINATOR_ + 0xB50 (DLL zcredll) > > > > exit + 0x2A0 (DLL zcrtldll) > > > > die_webcgi + 0x240 (UCr) > > > > die_errno + 0x360 (UCr) > > > > write_or_die + 0x1C0 (UCr) > > > > end_headers + 0x1A0 (UCr) > > > > die_webcgi + 0x220 (UCr) > > > > die + 0x320 (UCr) > > > > inflate_request + 0x520 (UCr) > > > > run_service + 0xC20 (UCr) > > > > service_rpc + 0x530 (UCr) > > > > cmd_main + 0xD00 (UCr) > > > > main + 0x190 (UCr) > > > > > > > > Best guess is that a signal (SIGCHLD?) is possibly getting eaten > > > > or neglected somewhere between the test, perl, and git-http-backend. > > > > > > So we are trying to die(), which actually happens in die_webcgi(), > > > and > > then try > > > to write some message _but_ notice an error inside > > > write_or_dir() and try to exit because we do not want to recurse > > > forever trying to die, giving a message to say how/why we died, and > > > die because failing to give that message, forever. > > > > > > But in our attempt to exit(), we try to "cleanup children" and that > > > is > > what gets > > > stuck. > > > > > > One big difference before and after the /dev/zero change is that the > > process > > > is now on a downstream of the pipe. If we prepare a large file with > > > a > > finite > > > size full of NULs and replace /dev/null with it, instead of feeding > > > NULs > > from > > > the pipe, would it change the equation? > > > > Doubtful. The processes are still around, and are waiting on read but > > not actively reading (CPU time is not going up, so we're not reading > > an infinite stream). To me, this is a pipe situation where there is > > simply nothing waiting on the pipe (maybe a flush missing?). I'm > > grasping are straws without knowing the actual process architecture of the > test to debug it. > > So could you try with this patch? > > -- snipsnap -- > diff --git a/http-backend.c b/http-backend.c index d5cea0329a..7c1b4a2555 > 100644 > --- a/http-backend.c > +++ b/http-backend.c > @@ -427,6 +427,7 @@ static void inflate_request(const char *prog_name, > int out, int buffer_input, ss > > done: > git_inflate_end(&stream); > + close(0); > close(out); > free(full_request); > } Based on d62dad7a7d (v2.21.0-rc0) undoing all of the fixes, this change on its own makes no difference to the hang situation - it is still there as it was when originally reported. Using POSIX::_exit does not change the outcome of the test either on its own or in conjunction with this fix.
RE: [PATCH 0/1] Fix hang in t5562, introduced in v2.21.0-rc1
On February 18, 2019 15:47, I wrote: > On February 18, 2019 15:41, Johannes Schindelin wrote: > > On Thu, 14 Feb 2019, Randall S. Becker wrote: > > > > > On February 14, 2019 17:39, Junio C Hamano wrote: > > > > To: Randall S. Becker > > > > Cc: 'Johannes Schindelin via GitGitGadget' > > > > ; git@vger.kernel.org; 'Max Kirillov' > > > > > > > > Subject: Re: [PATCH 0/1] Fix hang in t5562, introduced in > > > > v2.21.0-rc1 > > > > > > > > "Randall S. Becker" writes: > > > > > > > > > Unfortunately, subtest 13 still hangs on NonStop, even with this > > > > > patch, so our Pipeline still hangs. I'm glad it's better on > > > > > Azure, but I don't think this actually addresses the root cause > > > > > of the > hang. > > > > > > > > Sigh. > > > > > > > > > possible this is not the test that is failing, but actually the > > > > > git-http-backend? The code is not in a loop, if that helps. It > > > > > is not consuming any significant cycles. I don't know that part > > > > > of the code at all, sadly. The code is here: > > > > > > > > > > * in the operating system from here up * > > > > > cleanup_children + 0x5D0 (UCr) > > > > > cleanup_children_on_exit + 0x70 (UCr) > > > > > git_atexit_dispatch + 0x200 (UCr) > > > > > __process_atexit_functions + 0xA0 (DLL zcredll) > > > > > CRE_TERMINATOR_ + 0xB50 (DLL zcredll) > > > > > exit + 0x2A0 (DLL zcrtldll) > > > > > die_webcgi + 0x240 (UCr) > > > > > die_errno + 0x360 (UCr) > > > > > write_or_die + 0x1C0 (UCr) > > > > > end_headers + 0x1A0 (UCr) > > > > > die_webcgi + 0x220 (UCr) > > > > > die + 0x320 (UCr) > > > > > inflate_request + 0x520 (UCr) > > > > > run_service + 0xC20 (UCr) > > > > > service_rpc + 0x530 (UCr) > > > > > cmd_main + 0xD00 (UCr) > > > > > main + 0x190 (UCr) > > > > > > > > > > Best guess is that a signal (SIGCHLD?) is possibly getting eaten > > > > > or neglected somewhere between the test, perl, and git-http- > backend. > > > > > > > > So we are trying to die(), which actually happens in die_webcgi(), > > > > and > > > then try > > > > to write some message _but_ notice an error inside > > > > write_or_dir() and try to exit because we do not want to recurse > > > > forever trying to die, giving a message to say how/why we died, > > > > and die because failing to give that message, forever. > > > > > > > > But in our attempt to exit(), we try to "cleanup children" and > > > > that is > > > what gets > > > > stuck. > > > > > > > > One big difference before and after the /dev/zero change is that > > > > the > > > process > > > > is now on a downstream of the pipe. If we prepare a large file > > > > with a > > > finite > > > > size full of NULs and replace /dev/null with it, instead of > > > > feeding NULs > > > from > > > > the pipe, would it change the equation? > > > > > > Doubtful. The processes are still around, and are waiting on read > > > but not actively reading (CPU time is not going up, so we're not > > > reading an infinite stream). To me, this is a pipe situation where > > > there is simply nothing waiting on the pipe (maybe a flush > > > missing?). I'm grasping are straws without knowing the actual > > > process architecture of > the > > test to debug it. > > > > So could you try with this patch? > > > > -- snipsnap -- > > diff --git a/http-backend.c b/http-backend.c index > > d5cea0329a..7c1b4a2555 > > 100644 > > --- a/http-backend.c > > +++ b/http-backend.c > > @@ -427,6 +427,7 @@ static void inflate_request(const char *prog_name, > > int out, int buffer_input, ss > > > > done: > > git_inflate_end(&stream); > > + close(0); > > close(out); > > free(full_request); > > } > > In isolation or with the other fixes associated with t5562? Or, which baseline > commit should I use? 8989e1950a or d92031209a or some other? It works fine based off of d92031209a - the test actually runs a bit faster based on the wall clock.
RE: [PATCH] t5562: chunked sleep to avoid lost SIGCHILD
On February 18, 2019 15:50, Max Kirillov wrote:
> To: SZEDER GĂĄbor ; git@vger.kernel.org
> Cc: Max Kirillov ; Johannes Schindelin
> ; Randall S. Becker
> ; 'Junio C Hamano'
> Subject: [PATCH] t5562: chunked sleep to avoid lost SIGCHILD
>
> If was found during stress-test run that a test may hang by 60 seconds.
> It supposedly happens because SIGCHILD was received before sleep has
> started.
>
> Fix by looping by smaller chunks, checking $exited after each of them.
> Then lost SIGCHILD would not cause longer delay than 1 second.
>
> Reported-by: SZEDER GĂĄbor
> Signed-off-by: Max Kirillov
> ---
> Submitting as proper patch. Note: I believe it does not relate to other issues
> discussed in this thread.
> t/t5562/invoke-with-content-length.pl | 7 ++-
> 1 file changed, 6 insertions(+), 1 deletion(-)
>
> diff --git a/t/t5562/invoke-with-content-length.pl b/t/t5562/invoke-with-
> content-length.pl
> index 0943474af2..257e280e3b 100644
> --- a/t/t5562/invoke-with-content-length.pl
> +++ b/t/t5562/invoke-with-content-length.pl
> @@ -29,7 +29,12 @@
> }
> print $out $body_data or die "Cannot write data: $!";
>
> -sleep 60; # is interrupted by SIGCHLD
> +my $counter = 0;
> +while (not $exited and $counter < 60) {
> +sleep 1;
> +$counter = $counter + 1;
> +}
> +
> if (!$exited) {
> close($out);
> die "Command did not exit after reading whole body";
I tried this fix and it made no difference to the hang on NonStop. I do not
think this fixes the root cause as sleep was never an issue and SIGCHLD was not
missed in any test I conducted. Maybe on another platform it is required.
RE: [PATCH 0/1] Fix hang in t5562, introduced in v2.21.0-rc1
On February 18, 2019 15:41, Johannes Schindelin wrote: > On Thu, 14 Feb 2019, Randall S. Becker wrote: > > > On February 14, 2019 17:39, Junio C Hamano wrote: > > > To: Randall S. Becker > > > Cc: 'Johannes Schindelin via GitGitGadget' ; > > > git@vger.kernel.org; 'Max Kirillov' > > > Subject: Re: [PATCH 0/1] Fix hang in t5562, introduced in > > > v2.21.0-rc1 > > > > > > "Randall S. Becker" writes: > > > > > > > Unfortunately, subtest 13 still hangs on NonStop, even with this > > > > patch, so our Pipeline still hangs. I'm glad it's better on Azure, > > > > but I don't think this actually addresses the root cause of the hang. > > > > > > Sigh. > > > > > > > possible this is not the test that is failing, but actually the > > > > git-http-backend? The code is not in a loop, if that helps. It is > > > > not consuming any significant cycles. I don't know that part of > > > > the code at all, sadly. The code is here: > > > > > > > > * in the operating system from here up * > > > > cleanup_children + 0x5D0 (UCr) > > > > cleanup_children_on_exit + 0x70 (UCr) > > > > git_atexit_dispatch + 0x200 (UCr) > > > > __process_atexit_functions + 0xA0 (DLL zcredll) > > > > CRE_TERMINATOR_ + 0xB50 (DLL zcredll) > > > > exit + 0x2A0 (DLL zcrtldll) > > > > die_webcgi + 0x240 (UCr) > > > > die_errno + 0x360 (UCr) > > > > write_or_die + 0x1C0 (UCr) > > > > end_headers + 0x1A0 (UCr) > > > > die_webcgi + 0x220 (UCr) > > > > die + 0x320 (UCr) > > > > inflate_request + 0x520 (UCr) > > > > run_service + 0xC20 (UCr) > > > > service_rpc + 0x530 (UCr) > > > > cmd_main + 0xD00 (UCr) > > > > main + 0x190 (UCr) > > > > > > > > Best guess is that a signal (SIGCHLD?) is possibly getting eaten > > > > or neglected somewhere between the test, perl, and git-http-backend. > > > > > > So we are trying to die(), which actually happens in die_webcgi(), > > > and > > then try > > > to write some message _but_ notice an error inside > > > write_or_dir() and try to exit because we do not want to recurse > > > forever trying to die, giving a message to say how/why we died, and > > > die because failing to give that message, forever. > > > > > > But in our attempt to exit(), we try to "cleanup children" and that > > > is > > what gets > > > stuck. > > > > > > One big difference before and after the /dev/zero change is that the > > process > > > is now on a downstream of the pipe. If we prepare a large file with > > > a > > finite > > > size full of NULs and replace /dev/null with it, instead of feeding > > > NULs > > from > > > the pipe, would it change the equation? > > > > Doubtful. The processes are still around, and are waiting on read but > > not actively reading (CPU time is not going up, so we're not reading > > an infinite stream). To me, this is a pipe situation where there is > > simply nothing waiting on the pipe (maybe a flush missing?). I'm > > grasping are straws without knowing the actual process architecture of the > test to debug it. > > So could you try with this patch? > > -- snipsnap -- > diff --git a/http-backend.c b/http-backend.c index d5cea0329a..7c1b4a2555 > 100644 > --- a/http-backend.c > +++ b/http-backend.c > @@ -427,6 +427,7 @@ static void inflate_request(const char *prog_name, > int out, int buffer_input, ss > > done: > git_inflate_end(&stream); > + close(0); > close(out); > free(full_request); > } In isolation or with the other fixes associated with t5562? Or, which baseline commit should I use? 8989e1950a or d92031209a or some other?
RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News
On February 18, 2019 15:25, Max Kirillov wrote: > On Sat, Feb 16, 2019 at 10:57:52AM -0800, Junio C Hamano wrote: > > I'm inclined to > > > > - keep b46221ff in 'master', not reverted. > > from the branch, cc95bc2025 "t5562: replace /dev/zero with a pipe from > generate_zero_bytes" could be replaced with [1] > "t5562: do not depend on /dev/zero", for simplicity. I cannot however test > the issue as I have no access to the platform in question. As far as I > understand, both should work. > > [1] https://public-inbox.org/git/20190215164237.12250-1- > m...@max630.net/ AFAIK, b46221ff and [1] should be included. I have no preference on the title. As soon as (dT based $DAYJOB and $SLEEP) the merge is available (or -rc2) comes out, I will test t5562 then run a full regression on NonStop and report back. t5562 takes under a minute. The full suite is 50 hours. How's that? Cheers, Randall
RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News
On February 18, 2019 13:46, Junio C Hamano wrote:
> Junio C Hamano writes:
>
> > I have been wondering about the whole /dev/zero business. Although we
> > have b46221ff ("Merge branch 'rb/no-dev-zero-in-test'",
> > 2019-02-13) in 'master', "git grep /dev/zero t" has hits in
> > t/helper/test-sha1.sh and t/t4152-am-resume-override-opts.sh, so it
> > must have been somewhat incomplete to help platforms that lack
> > /dev/zero in the first place.
> >
> > We haven't heard from Dscho in European timezone, but I'm inclined to
> >
> > - keep b46221ff in 'master', not reverted.
> > - apply Max's "t5562: do not reuse output files"
> >
> > to 'master' and hope that we can declare victory in this part of the
> > code ;-). There may be fix-ups for other topics before -rc2 on top of
> > that, though.
>
> Just to make sure you didn't miss the exchange, the above plan is still the
> latest ("Max's patch is [1]). As I'll be offline most of the day today, you
> still
> have time to stop or make me change course to avoid disaster by interjecting
> (which would be very much appreciated).
No interjection expected. That is what I have been testing, so anticipate that
this is correct.
Re: [RFE] Demilitarize Documentation (was RE: Delivery Status Notification (Failure))
On February 18, 2019 11:13, I wrote: > To: 'Senol Yazici' ; git@vger.kernel.org > Subject: RE: Delivery Status Notification (Failure) > > On February 18, 2019 5:47, Senol Yazici > > 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. > > I think there is a point here. In some of my customers, we have replaced > these terms with the following (the Repository is optional in the second two): > > * Blessed: Repository of Record > * Dictator: Committer [Repository] > * Lieutenant: Contributor [Repository] > > This seems more closely aligned with the real roles being applied to > activities > associated with the repositories involved. > > Taking a lesson from other Open Source projects, Jenkins has deprecated > Master/Slave in favour of Controller/Agent. This seems not only more > acceptable to some, but in my view more descriptive. The terms on the page > above do not actually make any descriptive sense to a newbie. And confusion > could ensue from the dictionary definitions: > > * Lieutenant: an aide or representative of another in the performance of > duty : assistant (not what that repository is for) > * Dictator: one holding complete autocratic control : a person with unlimited > governmental power (not how the git team behaves) > * Blessed: honored in worship : hallowed; of or enjoying happiness (although > I can see the happiness part of this one) It probably would be worth submitting this as an issue to the documentation project at https://github.com/git/git-scm.com. Depending on the response from the committers, I might be willing to take that on, but digging deeper, I'm not sure the terms I proposed as sufficient.
RE: [BUG] ls-files showing deleted files (unchecked lstat return value)
On February 18, 2019 10:17, SZEDER GĂĄbor wrote: > To: Joe Ranieri > Cc: git@vger.kernel.org > Subject: Re: [BUG] ls-files showing deleted files (unchecked lstat return > value) > > On Sun, Feb 17, 2019 at 08:49:39AM -0500, Joe Ranieri wrote: > > "git ls-files -m" can show deleted files, despite -d not having been > > specified. > > To my understanding that's intentional: a deleted file is considered modified, > because its content clearly doesn't match the tracked content. That's a good point and why I asked for a specific test condition that illustrated the bug as being unanticipated. I'm not sure what Joe supplied elsewhere in the thread does that. > > This is due to ls-files.c's show_files function calling lstat but not > > checking the return value before calling ie_modified with the > > uninitialized stat structure.
RE: Delivery Status Notification (Failure)
On February 18, 2019 5:47, Senol Yazici > 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. I think there is a point here. In some of my customers, we have replaced these terms with the following (the Repository is optional in the second two): * Blessed: Repository of Record * Dictator: Committer [Repository] * Lieutenant: Contributor [Repository] This seems more closely aligned with the real roles being applied to activities associated with the repositories involved. Taking a lesson from other Open Source projects, Jenkins has deprecated Master/Slave in favour of Controller/Agent. This seems not only more acceptable to some, but in my view more descriptive. The terms on the page above do not actually make any descriptive sense to a newbie. And confusion could ensue from the dictionary definitions: * Lieutenant: an aide or representative of another in the performance of duty : assistant (not what that repository is for) * Dictator: one holding complete autocratic control : a person with unlimited governmental power (not how the git team behaves) * Blessed: honored in worship : hallowed; of or enjoying happiness (although I can see the happiness part of this one) Regards, Randall
RE: [Fix v1] builtin/ls-files.c: add error check on lstat for modified files
On February 17, 2019 12:05, Ramsay Jones wrote: > On 17/02/2019 16:34, randall.s.bec...@rogers.com wrote: > > From: "Randall S. Becker" > > > > The result from lstat, checking whether a file has been deleted, is > > now included priot to calling id_modified when showing modified files. > > Prior > > s/priot/prior/; s/id_modified/ie_modified/ > > > to this fix, it is possible that files that were deleted could show up > > as being modified because the lstat error was unchecked. > > > > Reported-by: Joe Ranieri > > Signed-off-by: Randall S. Becker > > --- > > builtin/ls-files.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/builtin/ls-files.c b/builtin/ls-files.c index > > 29a8762d4..fc21f4795 100644 > > --- a/builtin/ls-files.c > > +++ b/builtin/ls-files.c > > @@ -348,7 +348,7 @@ static void show_files(struct repository *repo, > struct dir_struct *dir) > > err = lstat(fullname.buf, &st); > > if (show_deleted && err) > > To be pedantic, this should probably check for (err == ENOENT), since > lstat() can fail for several reasons which don't imply that the path has been > deleted. However, that is unlikely. That would be very platform specific error checking. lstat can fail for a variety of other reasons also leaving the file deleted (like a symlink issue), but you are correct. I was following the prior line's model of checking for consistency. > No reason to include such a check in this patch, of course. > > ATB, > Ramsay Jones > > > show_ce(repo, dir, ce, fullname.buf, > tag_removed); > > - if (show_modified && ie_modified(repo->index, ce, > &st, 0)) > > + if (show_modified && !err && ie_modified(repo- > >index, ce, &st, 0)) > > show_ce(repo, dir, ce, fullname.buf, > tag_modified); > > } > > } > > This was just to address what Joe reported earlier. It seemed like an easy one to address. Regards, Randall
[Fix v1] builtin/ls-files.c: add error check on lstat for modified files
From: "Randall S. Becker" The result from lstat, checking whether a file has been deleted, is now included priot to calling id_modified when showing modified files. Prior to this fix, it is possible that files that were deleted could show up as being modified because the lstat error was unchecked. Reported-by: Joe Ranieri Signed-off-by: Randall S. Becker --- builtin/ls-files.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/builtin/ls-files.c b/builtin/ls-files.c index 29a8762d4..fc21f4795 100644 --- a/builtin/ls-files.c +++ b/builtin/ls-files.c @@ -348,7 +348,7 @@ static void show_files(struct repository *repo, struct dir_struct *dir) err = lstat(fullname.buf, &st); if (show_deleted && err) show_ce(repo, dir, ce, fullname.buf, tag_removed); - if (show_modified && ie_modified(repo->index, ce, &st, 0)) + if (show_modified && !err && ie_modified(repo->index, ce, &st, 0)) show_ce(repo, dir, ce, fullname.buf, tag_modified); } } -- 2.12.3
RE: [BUG] ls-files showing deleted files (unchecked lstat return value)
On February 17, 2019 8:50, Joe Ranieri wrote: > "git ls-files -m" can show deleted files, despite -d not having been > specified. > This is due to ls-files.c's show_files function calling lstat but not > checking the > return value before calling ie_modified with the uninitialized stat structure. What version of git are you looking scanning? Commit 8989e1950a (2.21.0-rc1) has the following: err = lstat(fullname.buf, &st); if (show_deleted && err) ... You may be correct that the following check: if (show_modified && ie_modified(repo->index, ce, &st, 0 may need to include !err. Is that your conclusion? Is there a test case you have to demonstrate this that I can include in the test suite? The patch would be (subject to my bad mailer messing it up): diff --git a/builtin/ls-files.c b/builtin/ls-files.c index 29a8762d46..fc21f47954 100644 --- a/builtin/ls-files.c +++ b/builtin/ls-files.c @@ -348,7 +348,7 @@ static void show_files(struct repository *repo, struct dir_struct *dir) err = lstat(fullname.buf, &st); if (show_deleted && err) show_ce(repo, dir, ce, fullname.buf, tag_removed); - if (show_modified && ie_modified(repo->index, ce, &st, 0)) + if (show_modified && !err && ie_modified(repo->index, ce, &st, 0)) show_ce(repo, dir, ce, fullname.buf, tag_modified); } } Regards, Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News
On February 16, 2019 13:06, Junio C Hamano wrote: > "Randall S. Becker" writes: > > On February 16, 2019 3:27, Max Kirillov wrote: > >> What you could try is > >> https://public-inbox.org/git/20181124093719.10705-1- > m...@max630.net/ > >> (I'm not sure it would not conflict by now), this would remove > >> dependency between tests. If it helps it would be very valuable > information. > > > > Good news. This patch does seem to do the trick. I wonder whether this > > fixes the Azure build also. > > > > I have run the test under the following conditions: > > Run 1 (system idle): Pass > > Run 2 (system idle): Pass > > Run 3 (system idle): Pass > > Run 4 (system idle): Pass > > Run 5 (system idle): Pass > > Run 6 (system mild load, heavy file system): Pass Run 7 (system mild > > load, moderate file system load - git fetch): Pass Run 8 (heavy system > > load, heavy file system load): Pass Run 9 (--verbose, heavy system > > load, heavy file system load): Pass Run 10 (GIT_TRACE=true, --verbose, > > heavy system load, heavy file system > > load): Pass > > Run 11 (very heavy system load, very heavy file system load): Pass > > That indeed is a good news. > > > The current condition of the code is (the generate_zero_bytes delete > > was previously removed so can be ignored for the patch): > > Just to make sure I do not misunderstand, this result is with Max's patch but > without the generate_zero_bytes stuff? Correct. > Thanks, all. Hopefully we can get this test failures behind us before -rc2; > knock, knock... Once the fix is integrated and in the usual spots, I can verify with haste. The full test cycle is now at 50 hours (argh), which I will rerun in full at rc2, but this one is fast.
RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News
On February 16, 2019 11:51, I wrote: > To: 'Max Kirillov' > Cc: 'SZEDER GĂĄbor' ; 'Johannes Schindelin' > ; 'Junio C Hamano' ; > git@vger.kernel.org > Subject: RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News > > On February 16, 2019 3:27, Max Kirillov wrote: > > On Fri, Feb 15, 2019 at 04:13:15PM -0500, Randall S. Becker wrote: > > > Sadly, the fix does not change the results. In fact, it makes the > > > hang far more likely. Subtest 6,7,8 fails here, at close() > > > > Correct, I did not expect it to help, it was for the other issue. > > > > As for the hang issue, from your another message it seems to me that > > perl waiting correctly, there are really child process which do not exit. > > > > What you could try is > > https://public-inbox.org/git/20181124093719.10705-1-...@max630.net/ > > (I'm not sure it would not conflict by now), this would remove > > dependency between tests. If it helps it would be very valuable > information. > > Good news. This patch does seem to do the trick. I wonder whether this fixes > the Azure build also. And apologies for the stupid wrapping done by my mail client when I pasted the diff in. The patch is available from the link above anyway so you don't need the junk from my mailer anyway. Cheers, Randall
RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) - Good News
On February 16, 2019 3:27, Max Kirillov wrote:
> On Fri, Feb 15, 2019 at 04:13:15PM -0500, Randall S. Becker wrote:
> > Sadly, the fix does not change the results. In fact, it makes the hang
> > far more likely. Subtest 6,7,8 fails here, at close()
>
> Correct, I did not expect it to help, it was for the other issue.
>
> As for the hang issue, from your another message it seems to me that perl
> waiting correctly, there are really child process which do not exit.
>
> What you could try is
> https://public-inbox.org/git/20181124093719.10705-1-...@max630.net/
> (I'm not sure it would not conflict by now), this would remove dependency
> between tests. If it helps it would be very valuable information.
Good news. This patch does seem to do the trick. I wonder whether this fixes
the Azure build also.
I have run the test under the following conditions:
Run 1 (system idle): Pass
Run 2 (system idle): Pass
Run 3 (system idle): Pass
Run 4 (system idle): Pass
Run 5 (system idle): Pass
Run 6 (system mild load, heavy file system): Pass
Run 7 (system mild load, moderate file system load - git fetch): Pass
Run 8 (heavy system load, heavy file system load): Pass
Run 9 (--verbose, heavy system load, heavy file system load): Pass
Run 10 (GIT_TRACE=true, --verbose, heavy system load, heavy file system
load): Pass
Run 11 (very heavy system load, very heavy file system load): Pass
The current condition of the code is (the generate_zero_bytes delete was
previously removed so can be ignored for the patch):
diff --git a/t/t5562-http-backend-content-length.sh
b/t/t5562-http-backend-content-length.sh
index bbadde2c6e..f0f425b2cf 100755
--- a/t/t5562-http-backend-content-length.sh
+++ b/t/t5562-http-backend-content-length.sh
@@ -8,12 +8,12 @@ test_lazy_prereq GZIP 'gzip --version'
verify_http_result() {
# some fatal errors still produce status 200
# so check if there is the error message
- if grep 'fatal:' act.err
+ if grep 'fatal:' act.err.$test_count
then
return 1
fi
- if ! grep "Status" act.out >act
+ if ! grep "Status" act.out.$test_count >act
then
printf "Status: 200 OK\r\n" >act
fi
@@ -33,7 +33,7 @@ test_http_env() {
REQUEST_METHOD=POST \
"$PERL_PATH" \
"$TEST_DIRECTORY"/t5562/invoke-with-content-length.pl \
- "$request_body" git http-backend >act.out 2>act.err
+ "$request_body" git http-backend >act.out.$test_count
2>act.err.$test_count
}
ssize_b100dots() {
@@ -143,14 +143,14 @@ test_expect_success GZIP 'push gzipped empty' '
test_expect_success 'CONTENT_LENGTH overflow ssite_t' '
NOT_FIT_IN_SSIZE=$(ssize_b100dots) &&
- generate_zero_bytes infinity | env \
+ env \
CONTENT_TYPE=application/x-git-upload-pack-request \
QUERY_STRING=/repo.git/git-upload-pack \
PATH_TRANSLATED="$PWD"/.git/git-upload-pack \
GIT_HTTP_EXPORT_ALL=TRUE \
REQUEST_METHOD=POST \
CONTENT_LENGTH="$NOT_FIT_IN_SSIZE" \
- git http-backend >/dev/null 2>err &&
+ git http-backend /dev/null 2>err &&
grep "fatal:.*CONTENT_LENGTH" err
'
@@ -161,7 +161,7 @@ test_expect_success 'empty CONTENT_LENGTH' '
GIT_HTTP_EXPORT_ALL=TRUE \
REQUEST_METHOD=GET \
CONTENT_LENGTH="" \
- git http-backend act.out 2>act.err &&
+ git http-backend act.out.$test_count
2>act.err.$test_count &&
verify_http_result "200 OK"
'
More on t5562 Hang (was RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results))
On February 15, 2019 8:50, I wrote: > On February 15, 2019 8:02, SZEDER GĂĄbor wrote: > > To: Johannes Schindelin > > Cc: Randall S. Becker ; 'Junio C Hamano' > > ; git@vger.kernel.org; 'Max Kirillov' > > > > Subject: Re: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results) > > > > On Thu, Feb 14, 2019 at 10:36:42PM +0100, Johannes Schindelin wrote: > > > On Thu, 14 Feb 2019, Randall S. Becker wrote: > > > > > > > t5562 still hangs (blocking) - this breaks our CI pipeline since > > > > the test hangs and we have no explanation of whether the hang is > > > > in git or the tests. > > > > > > I have "good" news: it now also hangs on Ubuntu 16.04 in Azure > Pipelines' > > > Linux agents. > > > > I haven't yet seen that hang in the wild and couldn't reproduce it on > > purpose, but there is definitely something fishy with t5562 even on > > Linux and even without that perl generate_zero_bytes helper. > > > > $ git checkout cc95bc2025^ > > Previous HEAD position was cc95bc2025 t5562: replace /dev/zero with > > a pipe from generate_zero_bytes > > HEAD is now at 24b451e77c t5318: replace use of /dev/zero with > > generate_zero_bytes > > $ make > > > > $ cd t > > # take note of the shell's PID > > $ echo $$ > > 15522 > > $ ./t5562-http-backend-content-length.sh --stress |tee LOG > > OK3.0 > > OK1.0 > > OK6.0 > > OK0.0 > > > > > > And then in another terminal run this: > > > > $ pstree -a -p 15522 > > > > or, to make it easier noticable what changed and what stayed the same: > > > > $ watch -d pstree -a -p 15522 > > > > The output will sooner or later will look like this: > > > > bash,15522 > > âât5562-http-back,21082 ./t5562-http-backend-content-length.sh -- > stress > > âât5562-http-back,21089 ./t5562-http-backend-content-length.sh > > -- stress > > â ââsh,24906 ./t5562-http-backend-content-length.sh --stress > > âât5562-http-back,21090 ./t5562-http-backend-content-length.sh > > -- stress > > â ââsh,26660 ./t5562-http-backend-content-length.sh --stress > > âât5562-http-back,21092 ./t5562-http-backend-content-length.sh > > -- stress > > â ââsh,4202 ./t5562-http-backend-content-length.sh --stress > > â ââsh,5696 ./t5562-http-backend-content-length.sh --stress > > â ââperl,5697 /home/szeder/src/git/t/t5562/invoke-with- > content- > > length.pl push_body.gz.trunc git http-backend > > â ââ(git,5722) > > âât5562-http-back,21093 ./t5562-http-backend-content-length.sh > > -- stress > > â ââsh,25572 ./t5562-http-backend-content-length.sh --stress > > > > > > It won't show most of the processes run in the tests, because they are > > just too fast and short-lived. However, occasionally it does show a > > stuck git process, which is shown as in regular 'ps aux' > > output: > > > > szeder 5722 0.0 0.0 0 0 pts/16 Z+ 13:36 0:00 [git] > > > > > > Note that this is not a "proper" hang, in the sense that this process > > is not stuck forever, but only for about 1 minute, after which it > > disappears, and the test continues and eventually finishes with > > success. I've looked into the logs of a couple of such stuck jobs, > > and it seems that it varies in which test that git process happened to get > stuck. > > We see something similar. The 60 seconds is in the support script in the > t/t5562 directory. If a SIGCHLD is received, the sleep is interrupted and perl > terminates (no hang). If the sleep is not interrupted, NonStop hangs in the > close() after coming out of sleep because perl still has output to send > somewhere. We are hung in the close call - which is really perplexing > considering a close on NonStop in any other product is immediate and rather > harsh, but perl's semantics for close() are: "Closing a pipe also waits for > the > process executing on the pipe to complete" (from the Perl spec), which > seems to apply on NonStop because the git (5722) is reading but not > receiving any data and not terminating - based on your tree above. Or, in > other words, perl closing the pipe will not cause git (5722) to terminate > because perl is waiting on git (5722) to terminate before completing the > close. The only time it would not hang is if git (5722) term
RE: [ANNOUNCE] Git v2.21.0-rc1 (NonStop Results)
On February 15, 2019 15:37, Max Kirillov wrote:
> On Fri, Feb 15, 2019 at 02:02:13PM +0100, SZEDER GĂĄbor wrote:
> > I haven't yet seen that hang in the wild and couldn't reproduce it on
> > purpose, but there is definitely something fishy with t5562 even on
> > Linux and even without that perl generate_zero_bytes helper.
> >
> > It won't show most of the processes run in the tests, because they are
> > just too fast and short-lived. However, occasionally it does show a
> > stuck git process, which is shown as in regular 'ps aux'
> > output:
> >
> > szeder 5722 0.0 0.0 0 0 pts/16 Z+ 13:36 0:00 [git]
> >
> >
> > Note that this is not a "proper" hang, in the sense that this process
> > is not stuck forever, but only for about 1 minute
>
> This is probably because of SIGCHILD comes before "sleep". I believe this is
> unrelated to the hang issue. The hang issue looks like something is wrong
> with cleanu_children(), or maybe in the child which it tries to kill and wait,
> not in tests.
>
> As for this zombie issue, could be fixed with, for example, more busy wait
> like the following. It may with some bigger probability miss SIGCHILD to the
> first sleep because there is a bit more to do before it. But the penalty is
> only
> 1 second now, and as it still happens rarely there seems to be no visible
> degradation.
>
> --- 8< ---
> diff --git a/t/t5562/invoke-with-content-length.pl b/t/t5562/invoke-with-
> content-length.pl
> index 0943474af2..257e280e3b 100644
> --- a/t/t5562/invoke-with-content-length.pl
> +++ b/t/t5562/invoke-with-content-length.pl
> @@ -29,7 +29,12 @@
> }
> print $out $body_data or die "Cannot write data: $!";
>
> -sleep 60; # is interrupted by SIGCHLD
> +my $counter = 0;
> +while (not $exited and $counter < 60) {
> +sleep 1;
> +$counter = $counter + 1;
> +}
> +
> if (!$exited) {
> close($out);
> die "Command did not exit after reading whole body";
>From the trace I found in perl, we have gone past sleep and are hung at
close($out);
Commenting out the close() does nothing because perl still hangs on an implied
close resulting from the exception thrown by die(). See my other post on adding
GIT_TRACE and the changes resulting from that.
Sadly, the fix does not change the results. In fact, it makes the hang far more
likely. Subtest 6,7,8 fails here, at close()
waitpid + 0x130 (SLr)
$n_EnterPriv + 0x280 (Milli)
Perl_wait4pid + 0x130 (UCr)
Perl_my_pclose + 0x4C0 (UCr)
Perl_io_close + 0x180 (UCr)
Perl_do_close + 0x620 (UCr)
Perl_pp_close + 0xA70 (UCr)
Perl_runops_standard + 0xF0 (UCr)
S_run_body + 0x870 (UCr)
perl_run + 0x2D0 (UCr)
main + 0x3D0 (UCr)
