RE: Suggestion: make git checkout safer
On June 3, 2015 1:35 PM Junio C Hamano wrote: > Ed Avis writes: > > If my personal experience is anything to go by, newcomers may fall > > into the habit of running 'git checkout .' to restore missing files. > Is that really true? It all depends on why you came to a situation to have > "missing files" in the first place, I would think, but "git checkout $path" is "I > messed up the version in the working tree at $path, and want to restore them". > One particular kind of "I messed up" may be "I deleted by mistake" (hence > making them "missing"), but is it so common to delete things by mistake, as > opposed to editing, making a mess and realizing that the work so far was not > improving things and wanting to restart from scratch? When working in an IDE like ECLIPSE or MonoDevelop, accidentally hitting the DEL button or a drag-drop move is a fairly common trigger for the "Wait-No-Stop-Oh-Drats" process which includes running git checkout to recover. My keyboard is excessively sensitive static, so this happens more often than I will admit (shamelessly blaming hardware when it really is a user problem). Git checkout is a life-saver in this case as is frequently committing. :) Cheers, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suggestion: make git checkout safer
On June 3, 2015 2:11 PM Junio C Hamano wrote: > "Randall S. Becker" writes: > > On June 3, 2015 1:35 PM Junio C Hamano wrote: > >> Is that really true? It all depends on why you came to a situation > >> to have "missing files" in the first place, I would think, but "git > >> checkout $path" is "I messed up the version in the working tree at > >> $path, and want to restore them". One particular kind of "I messed > >> up" may be "I deleted by mistake" > >> (hence making them "missing"), but is it so common to delete things > >> by mistake, as opposed to editing, making a mess and realizing that > >> the work so far was not improving things and wanting to restart from > >> scratch? > > > > When working in an IDE like ECLIPSE or MonoDevelop, accidentally > > hitting the DEL button or a drag-drop move is a fairly common trigger > > for the "Wait-No-Stop-Oh-Drats" process which includes running git > > checkout to recover. > > That is an interesting tangent. If you are lucky then the deleted file may be > unedited one, but I presume that you are not always lucky. So perhaps "git > checkout" is not a solution to that particular IDE issue in the first place? Agreed. That's why I like knowing what's in my sausages and commit often. Only lost a minor change once from this. I wonder what else is afoot. Ed, can you expand on the issue? -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Suggestion: make git checkout safer
On June 3, 2015 3:06 PM Jeff King wrote: > On Wed, Jun 03, 2015 at 10:32:40AM -0700, Junio C Hamano wrote: > > "git checkout $paths" (and you can give "." for $paths to mean > > "everything") is akin to "cp -R $elsewhere/$path ." to restore the > > working tree copies from somewhere else. > > > > "Ouch, 'git checkout .' overwrote what was in my working tree" is > > exactly the same kind of confusion as "I ran 'cp -r ../saved .' and it > > overwrote everything". As you said in your initial response, that is > > what the command is meant for. > > > > What does that similar command outside world, "cp", have for "more > > safety"? 'cp -i' asks if the user wants to overwrite a file for each > > path; perhaps a behaviour similar to that was the original poster > > wanted to see? > > Yeah, I'd say "cp -i" is the closest thing. I don't have a problem with > adding that, > but I'd really hate for it to be the default (just as I find distros which > "alias > rm='rm -i" annoying). Brainstorming a few compromises: or some such config option to turn on behaviour like this: core.checkout=-i or some such thing where if there are strictly more than m files being touched and strictly less than n files to act accordingly - a threshold concept: core.checkout_warn_upperlimit=n # default to 0 core.checkout_warn_lowerlimit=m # default to 0 or in a more gross fashion provide a pre-checkout hook to do all the work of prompting/control of the situation. Personally I'm happy with the defaults as they are (and was not a fan of defaulting rm -i or cp -i either) but I can see the point and have had diffuse whines from my team on the checkout subject, which is why I'm commenting. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: GIT for Microsoft Access projects
> -Original Message- > From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On > Behalf Of Konstantin Khomoutov > Sent: June 8, 2015 12:15 PM > To: hack...@suddenlink.net > Cc: git@vger.kernel.org > Subject: Re: GIT for Microsoft Access projects > > On Mon, 8 Jun 2015 9:45:17 -0500 > wrote: > > [...] > > My question is, will GIT work with MS access forms, queries, tables, > > modules, etc? > [...] > > Git works with files. So in principle it will work with *files* > containing your MS access stuff. > > But Git will consider and treat those files as opaque blobs of data. > That is, you will get no "fancy diffing" like asking Git to graphically > (or otherwise) show you what exact changes have been made to a > particular form or query between versions X and Y of a given MS access > document -- all it will be able to show you is commit messages > describing those changes. > > So... If you're fine with this setting, Git will work for you, > but if not, it won't. > > One last note: are you really sure you want an SCM/VCS tool to manage > your files and not a document management system (DMS) instead? > I mean stuff like Alfresco (free software by the way) and the like. Consider also what you are specifically managing in MS Access. Are you looking for management of configuration data, like settings, properties, and such, or is this transactional or user-related. If managing environment-specific content, it may be worth storing raw SQL INSERT statements, with appropriate variable references, or export to XML/CSV, and having those in git so that the purpose for configuration-like data can be explained and diff'ed. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH v6 17/19] fsck: Introduce `git fsck --quick`
On June 21, 2015 12:56 AM, Michael Haggerty wrote: > On 06/19/2015 10:53 PM, Junio C Hamano wrote: > > Johannes Schindelin writes: > > > >> Can you think of a name for the option that is as short as `--quick` > >> but means the same as `--connectivity-only`? > > > > No I can't. I think `--connectivity-only` is a very good name that is > > unfortunately a mouthful, I agree that we need a name that is as short > > as `--x` that means the same as `--connectivity-only`. I do not > > think `--quick` is that word; it does not mean such a thing. > > `--connectivity-only` says that "of all the things that fsck can do, skip everything > except for the connectivity check". But the switch really affects not the > connectivity part of the checks (that part is done in either case), but the blob > part. So, if we ignore the length of the option name for a moment, it seems like > the options should be something like `--check-blob-integrity`/`--no-check-blob- > integrity`. The default would remain `--check-blob-integrity` of course, but > > * Someday there might be a config setting that people can use to change the > default behavior of fsck to `--no-check-blob-integrity`. > * Someday there might be other expensive types of checks [1] that we want to > turn on/off independent of blob integrity checks. > > But now that I'm writing this, a silly question occurs to me: Do we need an > overall option like this at all? If I demote all blob-integrity checks to "ignore" > via the mechanism that you have added, then shouldn't fsck automatically > detect that it doesn't have to open the blobs at all and enable this speedup > automatically? So maybe `--(no-)?check-blob-integrity` is actually a shorthand > for turning a few more specific checks on/off at once. > > As for thinking of a shorter name for the option: assuming the blob integrity > checks can be turned on and off independently as described above, then I think > it is reasonable to *also* add a `--quick` option defined as > > --quick: Skip some expensive checks, dramatically reducing the > runtime of `git fsck`. Currently this is equivalent to > `--no-check-blob-integrity`. > > In the future if we invent other expensive checks we might also add them to the > list of things that are skipped by `--quick`. Synonym suggestions: --links or --relations I was going to include --refs but that may be ambiguous. Links also has meaning so it's probably out and --hitch may just be silly and needlessly introducing a new term. Cheers, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in
RE: RFC/Pull Request: Refs db backend
> -Original Message- > From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On > Behalf Of David Turner > Sent: June 23, 2015 4:05 PM > To: Stefan Beller > Cc: git mailing list; ronnie sahlberg > Subject: Re: RFC/Pull Request: Refs db backend > > On Tue, 2015-06-23 at 10:16 -0700, Stefan Beller wrote: > > > The db backend code was added in the penultimate commit; the rest is > > > just code rearrangement and minor changes to make alternate backends > > > possible. There ended up being a fair amount of this rearrangement, > > > but the end result is that almost the entire git test suite runs > > > under the db backend without error (see below for > > details). > > > > Looking at the end result in refs-be-db.c it feels like there are more > > functions in the refs_be_db struct, did this originate from other > > design choices? IIRC Ronnie wanted to have as least functions in there > > as possible, and share as much of the code between the databases, such > > that the glue between the db and the refs code is minimal. > > I didn't actually spend that much time reading Ronnie's backend code. > My code aims to be extremely thoroughly compatible. I spent a ton of time > making sure that the git test suite passed. I don't know if an alternate > approach would have been as compatible. > > The requirement for reflog storage did complicate things a bit. > > I also didn't see a strong need to abstract the database, since LMDB is > common, > widely compatible, and tiny. Just to beg a request: LMDB is not available on some MPP architectures to which git has been ported. If it comes up, I beg you not to add this as a dependency to base git components. Thanks, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: RFC/Pull Request: Refs db backend
> -Original Message- > From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On > Behalf Of David Turner > Sent: June 23, 2015 4:22 PM > To: Randall S. Becker > Cc: 'Stefan Beller'; 'git mailing list'; 'ronnie sahlberg' > Subject: Re: RFC/Pull Request: Refs db backend > > > Just to beg a request: LMDB is not available on some MPP architectures to > which git has been ported. If it comes up, I beg you not to add this as a > dependency to base git components. > > My changes make `configure` check for the presence of liblmdb. The LMDB > code is only built if liblmdb is present. So, I think we're good. Thanks :) You have no idea how much, in a "burnt by that in other projects" POV. Cheers, Randall -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Creating remote git repository?
On December 14, 2016 1:01 AM, essam Ganadily wrote: > given that git is an old and mature product i wounder why there is no > command line (git.exe in windows) way of creating a remote git repository? > > "git remote create repo myreponame" Why not run the commands mkdir myreponame; cd myreponame; git init under an SSH command on the destination host. That should get you what you want. Cheers, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much.
RE: /* compiler workaround */ - what was the issue?
On May 9, 2016 3:40 PM Philip Oakley wrote: > From: "Stefan Beller" > > On Fri, May 6, 2016 at 12:57 PM, Junio C Hamano > wrote: > >> Marc Branchaud writes: > >> > >>> On 2016-05-06 02:54 PM, Junio C Hamano wrote: > > I wonder if can we come up with a short and sweet notation to > remind futhre readers that this "initialization" is not > initializing but merely squelching warnings from stupid compilers, > and agree to use it consistently? > >>> > >>> Perhaps > >>> > >>> #define COMPILER_UNINITIALIZED_WARNING_INITIALIZER 0 > >>> > >>> or, for short-and-sweet > >>> > > > > /* Here could go a longer explanation than the 4 character > > define :) */ > >>> #define CUWI 0 > >>> > >>> ? > >>> > >>> :) > >> > >> I get that smiley. > >> > >> I was hinting to keep the /* compiler workaround */ comment, but in a > >> bit shorter form. > >> -- > > For some background, I found $gmane/169098/focus=169104 which covers > some of the issues (the focused msg is one from Junio). Hannes then notes > ($gmane/169121) that the current xx = xx; could be seen as possible > undefined behaviour - perhaps one of those 'no good solution' problems. > > Perhaps a suitable name... > > #define SUPPRESS_COMPILER_UNINITIALIZED_WARNING 0 > /* Use when some in-use compiler is unable to determine if the variable is > used uninitialized, and no good default value is available */ > > Though, where best to put it? I would suggest this type of approach should be detected in the configure script and added automagically (as best as possible) or as a hint supplied by the platform's own specific configuration files if necessary as a last gasp. -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git and Mozaik
Hi Everyone, I'm embarking on a bit of a quest to bring git into a CNC manufacturing environment for the Mozaik software package. Does anyone in the group have experience with git for that package (expecting probably not, but I had to ask)? I'm hoping that there won't be too many problems (internal file format seems relatively compatible for the stuff that needs to be versioned although if there are one-liner text files it may be annoying and I may have to provide my own diff engine). Cheers, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Bug] git-log prints wrong unixtime with --date=format:%s
On May 18, 2016 12:22 PM Jeff King wrote:
> > I tried a few obvious things, but couldn't make anything work. Setting
> > "timezone" manually seems to do nothing. It's supposed to be set by
> > putting the right thing in $TZ and then calling tzset(). So I tried
> > munging $TZ to something like "+0200". It did have _some_ effect, but
> > I
>
> Wouldn't that be more like "UTC+0200"?
>
> In any case, I do not think anybody wants to do tzset() on each and every
> commit while running "git log". Can we declare "format:"
> will always use the local timezone, or something?
Off the wall: Dealing in a dispersed team sharing a server that has a
timezone local for only two of the members, git log messes with me also from
a TZ POV. I would like to suggest a more general solution, like configuring
my own TZ in ~/.gitconfig which would potentially allow an override on the
command line. Would user.timezone be helpful in this situation and if set,
call setenv("TZ=...")? It's not an issue when I'm local, but if I touch a
clone on the server, even I get confused around DST changes in October ;).
Cheers,
Randall
-- Brief whoami: NonStop&UNIX developer since approximately
UNIX(421664400)/NonStop(2112884442)
-- In my real life, I talk too much.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Opinion gathering] Git remote whitelist/blacklist
On May 20, 2016 10:22 AM, Francois Beutin wrote: > We (Ensimag students) plan to implement the "remote whitelist/blacklist" > feature described in the SoC 2016 ideas, but first I would like to be sure we > agree on what exactly this feature would be, and that the community sees an > interest in it. > > The general idea is to add a way to prevent accidental push to the wrong > repository, we see two ways to do it: > First solution: > - a whitelist: Git will accept a push to a repository in it > - a blacklist: Git will refuse a push to a repository in it > - a default policy > > Second solution: > - a default policy > - a list of repository not following the default policy > > The new options in config if we implement the first solution: > > [remote] > # List of repository that will be allowed/denied with > # a whitelist/blacklist > whitelisted = "http://git-hosting.org"; > blacklisted = "http://git-hosting2.org"; > > # What is displayed when the user attempts a push on an > # unauthorised repository? (this option overwrites > # the default message) > denymessage = "message" > > # What git should do if the user attempts a push on an > # unauthorised repository (reject or warn and > # ask the user)? > denypolicy = reject(default)/warning > > # How should unknown repositories be treated? > defaultpolicy = allow(default)/deny > > > Some concrete usage example: > > - A beginner is working on company code, to prevent him from > accidentally pushing the code on a public repository, the > company (or him) can do: > git config --global remote.defaultpolicy "deny" > git config --global remote.denymessage "Not the company's server!" > git config --global remote.denypolicy "reject" > git config --global remote.whitelisted "http://company-server.com"; > > > - A regular git user fears that he might accidentally push sensible > code to a public repository he often uses for free-time > projects, he can do: > git config remote.defaultpolicy "allow" #not really needed > git config remote.denymessage "Are you sure it is the good server?" > git config remote.denypolicy "warning" > git config remote.blacklisted "http://github/personnalproject"; > > > We would like to gather opinions about this before starting to > implement it, is there any controversy? Do you prefer the > first or second solution (or none)? Do you find the option's > names accurate? How would this feature be secure and made reliably consistent in managing the policies (I do like storing the lists separate from the repository, btw)? My concern is that by using git config, a legitimate clone can be made of a repository with these attributes, then the attributes overridden by local config on the clone turning the policy off, changing the remote, and thereby allowing a push to an unauthorized destination (example: one on the originally intended blacklist). It is unclear to me how a policy manager would keep track of this or even know this happened and prevent policies from being bypassed - could you clarify this for the requirements? Cheers, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Opinion gathering] Git remote whitelist/blacklist
On May 24, 2016 12:08 PM, Matthieu Moy wrote: > > So, when trying a forbidden push, Git would deny it and the only way > > to force the push would be to remove the blacklist from the config, right? > > > > Probably the sanest way to go. I thought about adding a "git push > > --force-even-if-in-blacklist" or so, but I don't think the feature > > deserves one specific option (hence add some noise in `git push -h`). > > Yeah, I agree --even-if-in-blacklist is a road to madness, but I wonder how > this is different from setting pushURL to /dev/null or something illegal and > replace that phony configuration value when you really need to push? May be missing the point, but isn't the original intent to provide policy-based to control the push destinations? A sufficiently knowledgeable person, being a couple of weeks into git, would easily see that the config points to a black-listed destination and easily bypass it with a config update, rendering all this pointless? This seems to me to be a lot of effort to go to for limited value - unless immutable attributes are going to be obtained from the upstream repository - which also seems to run counter to the whole point. Confusededly, Randall -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [Opinion gathering] Git remote whitelist/blacklist
On May 24, 2016 3:25 PM Lars Schneider wrote: > > On 24 May 2016, at 12:16, Randall S. Becker > wrote: > > > > On May 24, 2016 12:08 PM, Matthieu Moy wrote: > >>> So, when trying a forbidden push, Git would deny it and the only way > >>> to force the push would be to remove the blacklist from the config, right? > >>> > >>> Probably the sanest way to go. I thought about adding a "git push > >>> --force-even-if-in-blacklist" or so, but I don't think the feature > >>> deserves one specific option (hence add some noise in `git push -h`). > >> > >> Yeah, I agree --even-if-in-blacklist is a road to madness, but I > >> wonder how this is different from setting pushURL to /dev/null or > >> something illegal and replace that phony configuration value when you > really need to push? > > > > May be missing the point, but isn't the original intent to provide policy- > based to control the push destinations? A sufficiently knowledgeable person, > being a couple of weeks into git, would easily see that the config points to a > black-listed destination and easily bypass it with a config update, rendering > all this pointless? This seems to me to be a lot of effort to go to for limited > value - unless immutable attributes are going to be obtained from the > upstream repository - which also seems to run counter to the whole point. > > An actor with a bad intent will *always* be able to bypass this. However, I > see two use cases: > > (1) Accidental pushes. > An inexpierenced developer clones a repo from github.com, commits for > whatever reason company code and pushes. At this point the code leaked. > The blacklist feature could have warned/stopped the developer. > > (2) Intentional open source pushes. > At my day job we encourage people to contribute to open source. However, > we want them to follow our open source contribution process. If they run > "git push" on a new github.com repo then I want to interrupt the push and > tell them to look at our contribution guidelines. Afterwards they could > whitelist the repo on their local machine and push without trouble. > > In summary I think the feature could be a safety net for the developer to not > leak company code. A more paranoid ;) and probably safer approach to satisfy UC.2 is to use something like Github Enterprise or Stash on a local server inside your firewall as the place where developers are allowed to push code, and then firewall block external entities. If you want to allow sharing of specific repositories, set up a pull from the remote that is allowed through the firewall and that server on a specific branch that can be shared (the branch should obviously be secured by a person in a different role/function - or set up a Jenkins job to do the push, perhaps, from that server. This could be considered potentially a closer implementation of your contribution process. For UC.1, if your clone is done via anonymous HTTPS, and push via SSH, accidents are less likely to happen, particularly if SSH to github is blocked at the firewall. I think there may be technical solutions to your problem that do not involve modification to git. These are just suggestions from what I have observed others doing in harsher environments. Cheers, Randall -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: feature request: git svn dommit --preserve-timestamps
Somewhen near June 10, 2016 9:40 PM, Eric Wong wrote: > Peter Münster wrote: > > On Tue, Jun 07 2016, Eric Wong wrote: > > > Peter Münster wrote: > > >> It would be nice, if timestamps could be preserved when rewriting > > >> the git-log. > > > > > > Unfortunately, last I checked (a long time ago!), explicitly setting > > > revprops might require SVN administrators to enable the feature for > > > the repo. > > > > Not the svn-log, only the git-log. > > The git log after dcommit is tied to the SVN log, so git-svn can only reflect > changes which appear in SVN. > > Sidenote: The convention is reply-to-all on lists like > this one which do not require subscription to post. > It prevents the list from being a single-point-of-failure > or censorship. > > > > It's been a while and I'm not up-to-date with the latest SVN. > > > Maybe there's a newer/easier way you could give us details about :) > > > > No, sorry. I don't care about the svn-log. > > Unfortunately, you would have to care about svn log as long as SVN exists in > your workflow and you need to interact with SVN users. > > git svn tries hard to work transparently and as close to the behavior of the > upstream SVN repo as possible. Having had to deal with this in pure git without factoring in git svn, this seems to be is a matter of policy rather than technical requirement. Various customers of mine have decided that using the commit time as a uniform timestamp to be applied to all files pulled in the specific commit, is the way to go when doing continuous integration. The solution that we ended up with was a step in our Jenkins build jobs that would set the timestamp of all files associated with the specific commit to the time of the commit itself. Any commit not part of the commit that changed that state of the repository was untouched. This became arbitrarily complex when the job was impacted by multiple commits, but the general consensus of those who made the decisions was to apply all timestamps associated with all commits, in order, of application (Jenkins seems happy to deal with this part), so that the files do keep relatively sane from a build perspective. Personally, I am relatively happy with this solution, even if it adds a huge amount of time to the build - generally more than the build itself - so that timestamps are "sane". Doing it for straight clones does not seem worth it, because timestamps don't appear to matter, policy wise, unless official builds are being done. It may be worth considering that in the discussion. My comments are just based on a production perspective, rather than development, so I ask forgiveness for any red-herrings that may be involved. Cheers, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Using Git for Cobol source
On February 3, 2016 4:20 AM, Per Jørgen Johnsen wrote: > Subject: SV: Using Git for Cobol source > I wonder if it is ok to use Git for source control for Cobol programs and take > advantage of parallel development ? > > Today we are using VSS and needs to be replaced. Our Cobol development is > done by an Eclipse tool (Micro Focus Enterprise Developer) COBOL should be no problem for git. The one caution I would have for you is that if you happen to be using fixed-format mode with column-based sequence numbers (that would be really old COBOL 74 mode), the sequence numbers may give false positives on diff results. If you have those, lose them. This would apply to VSS also, so you're probably not using those anyway. If you are functional in VSS for COBOL, you should be fine. Your challenge will be migrating history, which is possible, but will involve some effort. Regards, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Some strange behavior of git
On February 24, 2016 5:43 PM, Olga Pshenichnikova wrote > What can be cause for further confusing behavior? > > git@ip5server:~$ git status > On branch master > Untracked files: >(use "git add ..." to include in what will be committed) > > app/addons/arliteks/ > > nothing added to commit but untracked files present (use "git add" > to track) > git@ip5server:~$ git clean -dn > Would remove app/addons/arliteks/ > Would remove design/ > Would remove js/ > Would remove var/langs/en/ > > Why I don't see all 4 directories in first command? What do your .gitignore files contain in this project? Cheers, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Consulting for implementation
Hi Jose,
In my $DAYJOB, I do a lot of process and requirements work often involving git
- so I'm more of an advocate than a representative. Although I cannot speak on
behalf of the community as a whole, I would be happy to have a preliminary
discussion with you on the type of guidance you might need. Please reply
privately with contact info and I will try to help.
Regards,
Randall
> -Original Message-
> From: git-ow...@vger.kernel.org [mailto:git-ow...@vger.kernel.org] On
> Behalf Of JOSE
> Sent: February 26, 2016 4:56 PM
> To: git@vger.kernel.org
> Subject: Consulting for implementation
>
> good afternoon GIT Community
>
> We are a group of people interested in using management software versions
> of GIT for the solution of social problems and citizen empowerment in smart
> cities.
>
> I need to speak with a representative of the community, to explain the idea
> and have an advice of the feasibility of the proposal.
>
> Thanks for your time, I´ll wait for your answer.
>
> Sincerely
>
> José from BioRed {.n + +% ݶ w {.n + ^n r z h&
> z z ޗ + +zf
> h ~iz_ j:+v )ߣ m
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: libcurl dependency for implementing RFC3161 timestamps
On March 9, 2016 6:41 AM, Duy Nguyen wrote: > To: Anton Wuerfel > Cc: Git Mailing List ; i4pa...@cs.fau.de; > phillip.raff...@fau.de > Subject: Re: libcurl dependency for implementing RFC3161 timestamps > > On Wed, Mar 9, 2016 at 6:24 PM, Anton Wuerfel > wrote: > > -As git tag is a builtin part of the main git executable, introduce a > > libcurl dependency for the main executable (maybe not best-practice). > > libcurl was part of the main executable and then split out because it > increased startup time [1]. I don't know if it's still true nowadays, maybe > you > should do a simple test before deciding to go that way. The NSE NonStop port observed that at 2.7.3 (admittedly old) that libcurl was not used for local operations including status, log, reset, etc., but was needed for push, pull, fetch (a.k.a. network) operations. The libcurl.so is loaded statically at start-up for any components needing the latter operations. Added it for local processing is not going to help performance :(, which is quite bad enough on our platform. Sincerely, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Ability to remember last known good build
On March 11, 2016 1:08 PM Junio C Hamano wrote: > "Pedroso, Osiris" writes: > > > I participate in an open source project that any pull merge is accepted, no > matter what. > > > > This makes for lots of broken builds, even though we do have Travis-CI > enabled on the project, because people will merge a request before even the > build is complete. > > > > Therefore, I would like to remember the id of the commit of the last > successful build. This would be updated by the Travis-CI script itself upon a > successful build. > > > > I imagine best option would be to merge master to a certain branch named > "Last_known_Linux_build" or "Last_known_Windows_build" or even > "Last_known_build_all_tests_passing". > > > > I am new to git, but some other experienced co-volunteers tell me that it > may not be possible due to authentication issues. > > > > Any better way of accomplishing this? > > "test && git branch -f last-good"? I think semantically a last-good tag might be another option, unless you are applying build fixes to a last-good topic branch. You also have the option of adding content to the tag describing the build reason, engine used, etc. See git tag --help. I have used that in a Jenkins environment putting the tag move in the step following a build (failure does not execute the step so the last-good build tag stays where it is). Cheers, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Tabs in commit messages - de-tabify option in strbuf_stripspace()?
On March 15, 2016 8:17 PM Linus Torvalds wrote: > So I end up doing this manually when I notice, but I was wondering ig maybe > git could just have an option to "git am" and friends to de-tabify the commit > message. > > It's particularly noticeable when people line things up using tabs (for the > kernel, it's often things like "cpu1 does X, cpu2 does Y"), and then when you > do "git log" it looks like a unholy mess, because the 4-char indentation of > the > log message ends up causing those things to not line up at all after all. > > The natural thing to do would be to pass in a "tab size" parameter to > strbuf_stripspace(), and default it to 0 (for no change), but have some way to > let people say "expand tabs to spaces at 8-character tab-stops" or similar > (but let people use different tab-stops if they want). > > Do people hate that idea? I may not get around to it for a while (it's the > kernel merge window right now), but I can write the patch eventually - I just > wanted to do an RFC first. Speaking partly as a consumer of the comments and partly as someone who generates the commits through APIs, I would ask that the commit tab handling semantic be more formalized than just tab size to strbuf_stripspace(). While it might seem a bit unfair to have to worry about non-git git clients, the detabbing can impact the other commit implementers (e.g., SourceTree, EGit, JGit, and the raft of process automation bits out there using JGit for cool stuff). Personally, I would prefer to have a normalized behaviour so that any bit of automation building a commit message would have a specific definition to go to (and hopefully comply with) in order to properly format the message for posterity and across all consumers. It might also be useful to have some ability to be presentation-compatible with legacy commits (done after this type of enhancement) so that a reasonable presentation can be done for those 8 year old commits that still have embedded tabs. Personally, I don't encourage tabs in commits myself and do see the value of this, but is this really restricted just to git am? Just my $0.02, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: Git mascot
> On April 15, 2016 12:42 PM> Behalf Of Christian Howe wrote > There has been talk of a git mascot a while back in 2005. Some people > mentioned a fish or a turtle. Since all the great open source projects like > Linux or RethinkDB have a cute mascot, git definitely needs one as well. A > mascot gives people a recognizable persona towards which they can direct > their unbounded love for the project. It'd even be good if a plush doll of > this > mascot could eventually be created for people to physically express their love > of git through cuddling and hugging. The image in my mind is of a tree, shown above and below ground with roots and branches intertwined, reaching outward and downward. Cheers, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: What's the ".git/gitdir" file?
-Original Message- On Tue, October-27-15 6:23 PM, Stefan Beller wrote: >On Tue, Oct 27, 2015 at 3:04 PM, Kyle Meyer wrote: >> When a ".git" file points to another repo, a ".git/gitdir" file is >> created in that repo. >> >> For example, running >> >> $ mkdir repo-a repo-b >> $ cd repo-a >> $ git init >> $ cd ../repo-b >> $ echo "gitdir: ../repo-a/.git" > .git >> $ git status >> >> results in a file "repo-a/.git/gitdir" that contains >> >> $ cat repo-a/.git/gitdir >> .git >> >> I don't see this file mentioned in the gitrepository-layout manpage, >> and my searches haven't turned up any information on it. What's the >> purpose of ".git/gitdir"? Are there cases where it will contain >> something other than ".git"? > >It's designed for submodules to work IIUC. > >Back in the day each git submodule had its own .git directory keeping its >local >objects. >Nowadays the repository of submodule is kept in the superprojects >>.git/modules/ directory. Slightly OT: Is there any way of avoiding having that file in the first place? I'm hoping to have a git repository in a normal file system (Posix) and a working area in a rather less-than-normal one where dots in file names are bad (actually a dot is a separator). Cheers, Randall -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: [PATCH] Limit the size of the data block passed to SHA1_Update()
On October-30-15 6:18 PM, Atousa Pahlevan Duprat wrote: >Some implementations of SHA_Updates have inherent limits on the max chunk size. >SHA1_MAX_BLOCK_SIZE can be defined to set the max chunk size supported, if >required. This is enabled for OSX CommonCrypto library and set to 1GiB. >--- > Didn't we have this same issue with NonStop port about a year ago and decided to provision this through the configure script? Cheers, Randall -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: When a file was locked by some program, git will work stupidly
On November-01-15 11:57 PM dayong xie wrote: >To be specific >In my Unity project, there is a native plugin, and plugin's extension is >.dll, >and this plugin is under git version control, when Unity is running, >the plugin >file will be locked. >If i merge another branch, which contains modification of the plugin, git will >>report error, looks >like: >error: unable to unlink old 'xxx/xxx.dll' (Permission denied) This is not >>bad, however, the unfinished merge action will not revert by git, a lot of >>changes produced in repository. >usually it makes me crazy, even worse, some of my partners are not good at >>using git. >Of course, this problem can be avoided by quit Unity, but not every time we >can >remember. In my opinion, git should revert the unfinished action when the >error >occurred, not just stop. What version of Unity (or Unity Pro) are you using? Is this experienced with the Commit in MonoDevelop/Visual Studio or are you using a separate git client? I have found similar issues in some versions of Unity and MonoDevelop or Visual Studio not saving all files, especially the project files until you have fully exited - nothing to do with git, but your git commits may not contain complete images of your change. When I use git with Unity, I either have the source committed through MonoDevelop (no issues) if my changes are source-only, or if I have assets and project changes, then I do exit completely so that I am sure Unity flushes everything to disk and I can get a single atomic commit with all the Unity and C# bits using SourceTree or gitk. OTOH I'm not sure you really should be storing build products out of MonoDevelop or Visual Studio in your git repository. If the DLL can be rebuild automatically on the client - usual answer is yes - then let it. Handle the release build separately - at least in a separate branch that does not involve having the Unity editor open to get in the way. In my environment, I have added *.dll (and other stuff) to .gitignore so that I do not track dll changes - they get built on demand instead. There are recommended ways of using git in the Unity forums. Cheers, Randall -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
RE: How to move users from SEU (AS400) to Git?
On December-02-15 1:10 PM dleong wrote: >I stumbled on this topic while doing a research on how to move RPG source >control to adopt using Git. I wonder if the original question was answered. >My company would love to have a more central system to maintain both RPG codes >and javascript codes. We use Rational Developer exclusively (no more >SEU) for our developers and we do not have budget to use Team Concert from IBM. >So Git seems like a good solution. I don't see any reason why Git would not be happy with RPG, whether structured or not, providing you have a reasonably Posix-like file system. The Rational Suite includes ClearCase, which can also be converted to Git (BTDT), although it is a bit intricate to convert and the complexity depends entirely on what part of history you want to preserve. Cheers, Randall -- NonStop and Unix geek since before the CSNet mass migration. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Git 2.3.7 hangs on fetch but not clone
I have some strange behaviour I am trying to diagnose on the NonStop port of git 2.3.7. The situation is we have a *LARGE* cloned repository with some local modifications of openssl, which we are trying to clone again for a Jenkins build. The command: git clone /local/openssl openssl works fine and rapidly (well under 30 seconds), but with a newly created empty repo, simulating what the Jenkins Git plugin does: mkdir /local/test/openssl cd /local/test/openssl git init /local/test/openssl git -c core.askpass=true fetch --verbose --progress /local/git/openssl +refs/heads/*:refs/remotes/origin/* does the usual: remote: Counting objects: 113436, done. remote: Compressing objects: 100% (23462/23462), done. then hangs forever without creating any files in the working directory. There are also no files or directories modified since the init operation. Processes left around, and without consuming resources, are: 1493172290 2030043151 - 15:58:29 00:15 git pack-objects --revs --thin --stdout --progress --delta-base-offset --include-tag 452984908 402653262 - 15:58:29 00:00 git -c core.askpass=true fetch --verbose --progress /local/git/openssl +refs/heads/*:refs/remotes/origin/* 402653262 1694498903 - 15:58:28 00:00 git -c core.askpass=true fetch --verbose --progress /local/git/openssl +refs/heads/*:refs/remotes/origin/* 2030043151 402653262 - 15:58:29 00:00 git-upload-pack /local/git/openssl This does not happen for our smaller repositories. Any pointers on where to look would be appreciated. Kindly, Randall -- Brief whoami: NonStop&UNIX developer since approximately UNIX(421664400)/NonStop(2112884442) -- In my real life, I talk too much. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[Question] Complex textconv text
Hi all, I have a strange situation and need help with resolving funky characters in .git/config. My situation is this: [diff "*.dat"] textconv = enscribe-conv --format=-a1\(A=-a1,-a16,-a32\|P=-a1,-a32,-a16\|=-a1,-d,a14\),-a224 Basically this is a formatter for diff so that I can show structured binary data. The unquoted syntax of the format string is: --format=-a1(A=-a1,-a16,-a32|P=-a1,-a32,-a16|=-a1,-d,a14),-a224 Content is not really important. The issue is that git is reporting fatal: bad config line 2 in file .git/config when I escape the (, ), and | characters. I get syntax errors otherwise from the shell running the textconv. I have tried --format="-a1(A=-a1,-a16,-a32|P=-a1,-a32,-a16|=-a1,-d,a14),-a224", to no avail. How should I safely escape the characters in here? Thanks, Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: [Question] Complex textconv text
On December 13, 2018 10:08, I wrote: > I have a strange situation and need help with resolving funky characters in > .git/config. My situation is this: > > [diff "*.dat"] > textconv = enscribe-conv > --format=-a1\(A=-a1,-a16,-a32\|P=-a1,-a32,-a16\|=-a1,-d,a14\),-a224 > > Basically this is a formatter for diff so that I can show structured binary data. > The unquoted syntax of the format string is: > --format=-a1(A=-a1,-a16,-a32|P=-a1,-a32,-a16|=-a1,-d,a14),-a224 > > Content is not really important. The issue is that git is reporting fatal: > bad config line 2 in file .git/config when I escape the (, ), and | characters. I > get syntax errors otherwise from the shell running the textconv. I have tried - > -format="-a1(A=-a1,-a16,-a32|P=-a1,-a32,-a16|=-a1,-d,a14),-a224", to no > avail. How should I safely escape the characters in here? Easiest bypass was to wrap the mess above into a shell script and execute it that way, which works just fine. I'm not sure it's possible to escape all of the special characters. Seems like the safest approach anyway. Cheers, Randall
Missed Commit in 2.20.1
On April 2, 2018 4:02 PM, Stefan Beller found my change:
> On Mon, Apr 2, 2018 at 12:57 PM, Randall S. Becker
> wrote:
> > On April 2, 2018 3:34 PM, Junio C Hamano wrote:
> >> The latest feature release Git v2.17.0 is now available at the usual
> >> places. It is comprised of 516 non-merge commits since v2.16.0,
> >> contributed by 71 people, 20 of which are new faces.
> >
> > Just a heads up. I think this one might have gotten missed at some point
a
> few months back. I think it was submitted back in January. Not sure where
it
> fell off or whether it was just dropped.
> >
> > diff --git a/transport-helper.c b/transport-helper.c index
> > 3f380d87d..5ee7007f6 100644
> > --- a/transport-helper.c
> > +++ b/transport-helper.c
> > @@ -1212,7 +1212,7 @@ static int udt_do_read(struct
> unidirectional_transfer *t)
> > return 0; /* No space for more. */
> >
> > transfer_debug("%s is readable", t->src_name);
> > - bytes = read(t->src, t->buf + t->bufuse, BUFFERSIZE -
t->bufuse);
> > + bytes = xread(t->src, t->buf + t->bufuse, BUFFERSIZE -
t->bufuse);
> > if (bytes < 0 && errno != EWOULDBLOCK && errno != EAGAIN &&
> > errno != EINTR) {
> > error_errno("read(%s) failed", t->src_name);
>
> Patch at https://public-
> inbox.org/git/010f01d38a9e$a5c4f290$f14ed7b0$@nexbridge.com/
Just a subtle reminder that this particular change does not seem to have
made it into 2.20.1. I've retrofitted xread into the NonStop port and will
be re-submitting it with the remaining platform changes assuming the test
suite runs at least as well as our last port at 2.17.0 (in progress as we
speak). We are down to four variances from standard code:
*git-compat-util.h referencing FLOSS headers needed on platform.
*this one (xread instead of read in transport-helper.c)
*config.mak.uname specific settings for NonStop not currently present.
*t/Makefile - have to comment out all test-lint dependencies because of
segfault at 2.20.1. (to be investigated but we don't submit this unless we
find a good fix)
Please stay tuned for patches. We are very much looking forward to having
the two (or three) different NonStop hardware personalities supported
without mods in the very near future. Our goal, assuming those patches are
acceptable, is to move our build/test/distro into a Jenkins config that runs
with minimal human involvement (a.k.a. me).
Cheers,
Randall
-- Brief whoami:
NonStop developer since approximately NonStop(2112884442)
UNIX developer since approximately 421664400
-- In my real life, I talk too much.
[Bug] t0410 breakages at 2.20.1 on NonStop platform
Hi All,
Were getting some new breakages in t0410 that I cant explain easily or
either it is the test itself at commit 0d0ac3826a.
[Filtered]
*** t0410-partial-clone.sh ***
not ok 5 - missing ref object, but promised, passes fsck
not ok 6 - missing object, but promised, passes fsck
not ok 7 - missing CLI object, but promised, passes fsck
not ok 12 - rev-list stops traversal at missing and promised commit
not ok 13 - missing tree objects with --missing=allow-promisor and
--exclude-promisor-objects
not ok 14 - missing non-root tree object and rev-list
not ok 15 - rev-list stops traversal at missing and promised tree
not ok 16 - rev-list stops traversal at missing and promised blob
not ok 22 - gc stops traversal when a missing but promised object is reached
The first one to fail which probably would give me a hint on others is:
Initialized empty Git repository in /home/git/git/t/trash
directory.t0410-partial-clone/repo/.git/
[master (root-commit) 6591d03] 1
Author: A U Thor
1 file changed, 1 insertion(+)
create mode 100644 1.t
[master 5355e57] 2
Author: A U Thor
1 file changed, 1 insertion(+)
create mode 100644 2.t
[master a3007a6] 3
Author: A U Thor
1 file changed, 1 insertion(+)
create mode 100644 3.t
Enumerating objects: 1, done.
Counting objects: 100% (1/1), done.
Writing objects: 100% (1/1), done.
Total 1 (delta 0), reused 0 (delta 0)
fa10eb4e855a356f0abe9c352b62b71d481918b1
rm: cannot remove
'repo/.git/objects/fa/10eb4e855a356f0abe9c352b62b71d481918b1': No such file
or directory
not ok 6 - missing object, but promised, passes fsck
#
# rm -rf repo &&
# test_create_repo repo &&
# test_commit -C repo 1 &&
# test_commit -C repo 2 &&
# test_commit -C repo 3 &&
# git -C repo tag -a annotated_tag -m "annotated tag" &&
#
# C=$(git -C repo rev-parse 1) &&
# T=$(git -C repo rev-parse 2^{tree}) &&
# B=$(git hash-object repo/3.t) &&
# AT=$(git -C repo rev-parse annotated_tag) &&
#
# promise_and_delete "$C" &&
# promise_and_delete "$T" &&
# promise_and_delete "$B" &&
# promise_and_delete "$AT" &&
#
# git -C repo config core.repositoryformatversion 1 &&
# git -C repo config extensions.partialclone "arbitrary
string" &&
# git -C repo fsck
#
The repo/.git contains the following at the time of failure:
.git/objects
.git/objects/info
.git/objects/pack
.git/objects/pack/pack-fa10eb4e855a356f0abe9c352b62b71d481918b1.idx
.git/objects/pack/pack-fa10eb4e855a356f0abe9c352b62b71d481918b1.pack
.git/objects/pack/pack-fa10eb4e855a356f0abe9c352b62b71d481918b1.promisor
.git/refs
.git/refs/heads
.git/refs/heads/master
.git/refs/tags
.git/refs/tags/1
.git/refs/tags/2
.git/refs/tags/3
.git/refs/tags/annotated_tag
Given the contents, I'm not surprised the 'rm' failed. Any help would be
appreciated in tracking down what happened.
Thanks,
Randall
-- Brief whoami:
NonStop developer since approximately NonStop(2112884442)
UNIX developer since approximately 421664400
-- In my real life, I talk too much.
[PATCH v1 2/4] config.mak.uname: support for modern HPE NonStop config.
From: "Randall S. Becker"
A number of configuration options are not automatically detected by
configure mechanisms, including the location of Perl and Python.
There was a problem at a specific set of operating system versions
that caused getopt to have compile errors. Accounted for this by
providing emulation defines for those versions.
Signed-off-by: Randall S. Becker
---
config.mak.uname | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/config.mak.uname b/config.mak.uname
index 3ee7da0e23..aa4432ac2f 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -441,26 +441,45 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
# INLINE='' would just replace one set of warnings with another and
# still not compile in c89 mode, due to non-const array initializations.
CC = cc -c99
+ # Build down-rev compatible objects that don't use our new getopt_long.
+ ifeq ($(uname_R).$(uname_V),J06.21)
+ CC += -WRVU=J06.20
+ endif
+ ifeq ($(uname_R).$(uname_V),L17.02)
+ CC += -WRVU=L16.05
+ endif
+
# Disable all optimization, seems to result in bad code, with -O or -O2
# or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
# abends on "git push". Needs more investigation.
- CFLAGS = -g -O0
+ CFLAGS = -g -O0 -Winline
# We'd want it to be here.
prefix = /usr/local
# Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
- PERL_PATH = ${prefix}/bin/perl
- PYTHON_PATH = ${prefix}/bin/python
-
+ PERL_PATH = /usr/bin/perl
+ PYTHON_PATH = /usr/bin/python
+ # The current /usr/coreutils/rm at lowest support level does not work
+ # with the git test structure. Default to the older rm.
+ RM = /bin/rm -f
# As detected by './configure'.
# Missdetected, hence commented out, see below.
#NO_CURL = YesPlease
# Added manually, see above.
+ # Missdetected, hence commented out, see below.
+ #NO_CURL = YesPlease
+ # Added manually, see above.
+ # Not detected by ./configure. Add manually.
+ NEEDS_SSL_WITH_CURL = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
+ HAVE_DEV_TTY = YesPlease
+
HAVE_LIBCHARSET_H = YesPlease
HAVE_STRINGS_H = YesPlease
NEEDS_LIBICONV = YesPlease
NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
NO_SYS_SELECT_H = UnfortunatelyYes
NO_D_TYPE_IN_DIRENT = YesPlease
+ NO_GETTEXT = YesPlease
NO_HSTRERROR = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
@@ -470,8 +489,13 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
NO_MKDTEMP = YesPlease
# Currently libiconv-1.9.1.
OLD_ICONV = UnfortunatelyYes
- NO_REGEX = YesPlease
+ NO_REGEX=NeedsStartEnd
NO_PTHREADS = UnfortunatelyYes
+ ifdef NO_PTHREADS
+ else # WIP, use of Posix User Threads is planned but not working yet
+ PTHREAD_CFLAGS = -D_PUT_MODEL_ -I/usr/include
+ PTHREAD_LIBS = -lput
+ endif
# Not detected (nor checked for) by './configure'.
# We don't have SA_RESTART on NonStop, unfortunalety.
--
2.17.0.10.gb132f7033
[PATCH v1 1/4] transport-helper: use xread instead of read
From: "Randall S. Becker"
This fix was needed on HPE NonStop NSE and NSX where SSIZE_MAX is less than
BUFFERSIZE resulting in EINVAL. The call to read in transport-helper.c
was the only place outside of wrapper.c where it is used instead of xread.
Signed-off-by: Randall S. Becker
---
transport-helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/transport-helper.c b/transport-helper.c
index bf225c698f..a290695a12 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -1225,7 +1225,7 @@ static int udt_do_read(struct unidirectional_transfer *t)
return 0; /* No space for more. */
transfer_debug("%s is readable", t->src_name);
- bytes = read(t->src, t->buf + t->bufuse, BUFFERSIZE - t->bufuse);
+ bytes = xread(t->src, t->buf + t->bufuse, BUFFERSIZE - t->bufuse);
if (bytes < 0 && errno != EWOULDBLOCK && errno != EAGAIN &&
errno != EINTR) {
error_errno(_("read(%s) failed"), t->src_name);
--
2.17.0.10.gb132f7033
[PATCH v1 0/4] HPE NonStop Port Commits
From: "Randall S. Becker" This set of patches is a distilled version of the minimal set of changes to git that will allow it to run as client and server on HPE NonStop NSE and NSX systems. NSR systems are no longer under support so references to them have been removed. Each patch in this set is independent but required for correctness. Randall S. Becker (4): transport-helper: use xread instead of read config.mak.uname: support for modern HPE NonStop config. git-compat-util.h: add FLOSS headers for HPE NonStop compat/regex/regcomp.c: define intptr_t and uintptr_t on NonStop compat/regex/regcomp.c | 8 config.mak.uname | 34 +- git-compat-util.h | 15 +++ transport-helper.c | 2 +- 4 files changed, 53 insertions(+), 6 deletions(-) -- 2.17.0.10.gb132f7033
[PATCH v1 4/4] compat/regex/regcomp.c: define intptr_t and uintptr_t on NonStop
From: "Randall S. Becker" The system definition header files on HPE NonStop do not define intptr_t and uintptr_t as do other platforms. These typedefs are added specifically wrapped in a __TANDEM ifdef. Signed-off-by: Randall S. Becker --- compat/regex/regcomp.c | 8 1 file changed, 8 insertions(+) diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c index 51cd60baa3..c0d838834a 100644 --- a/compat/regex/regcomp.c +++ b/compat/regex/regcomp.c @@ -17,6 +17,14 @@ License along with the GNU C Library; if not, see <http://www.gnu.org/licenses/>. */ +#if defined __TANDEM + /* This is currently duplicated from git-compat-utils.h */ +# ifdef NO_INTPTR_T + typedef long intptr_t; + typedef unsigned long uintptr_t; +# endif +#endif + static reg_errcode_t re_compile_internal (regex_t *preg, const char * pattern, size_t length, reg_syntax_t syntax); static void re_compile_fastmap_iter (regex_t *bufp, -- 2.17.0.10.gb132f7033
[PATCH v1 3/4] git-compat-util.h: add FLOSS headers for HPE NonStop
From: "Randall S. Becker" The HPE NonStop (a.k.a. __TANDEM) platform cannot build git without using the FLOSS package supplied by HPE. The convenient location for including the relevant headers is in this file. The NSIG define is also not defined on __TANDEM, so we define it here as 100 if it is not defined only for __TANDEM builds. Signed-off-by: Randall S. Becker --- git-compat-util.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/git-compat-util.h b/git-compat-util.h index 09b0102cae..3f615f7ed8 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -397,6 +397,21 @@ static inline char *git_find_last_dir_sep(const char *path) #define query_user_email() NULL #endif +#ifdef __TANDEM +#if !defined(_THREAD_SUPPORT_FUNCTIONS) && !defined(_PUT_MODEL_) +/* #include */ +/* #include */ +#endif +#include +#include +#if ! defined NSIG +/* NonStop NSE and NSX do not provide NSIG. SIGGUARDIAN(99) is the highest + known, by detective work using kill -l as a list is all signals + instead of signal.h where it should be. */ +# define NSIG 100 +#endif +#endif + #if defined(__HP_cc) && (__HP_cc >= 61000) #define NORETURN __attribute__((noreturn)) #define NORETURN_PTR -- 2.17.0.10.gb132f7033
RE: [PATCH v1 3/4] git-compat-util.h: add FLOSS headers for HPE NonStop
On December 27, 2018 7:10, Derrick Stolee wrote: > On 12/26/2018 6:05 PM, randall.s.bec...@rogers.com wrote: > > The NSIG define is also not defined on __TANDEM, so we define it here > > as 100 if it is not defined only for __TANDEM builds. > [snip] > > +#if ! defined NSIG > > Why didn't you use "#ifndef" here? > > Taking a look at the file, I see both "#ifdef" and "#if defined" but no "#if ! > defined". I'm good with revising as follows and removing the irrelevant lines (stay tuned): +#ifdef __TANDEM +#include +#include +#ifndef NSIG +/* NonStop NSE and NSX do not provide NSIG. SIGGUARDIAN(99) is the highest + known, by detective work using kill -l as a list is all signals + instead of signal.h where it should be. */ +# define NSIG 100 +#endif +#endif + Cheers, Randall
[PATCH v2 3/4] git-compat-util.h: add FLOSS headers for HPE NonStop
From: "Randall S. Becker" The HPE NonStop (a.k.a. __TANDEM) platform cannot build git without using the FLOSS package supplied by HPE. The convenient location for including the relevant headers is in this file. The NSIG define is also not defined on __TANDEM, so we define it here as 100 if it is not defined only for __TANDEM builds. Signed-off-by: Randall S. Becker --- git-compat-util.h | 15 +++ 1 file changed, 15 insertions(+) diff --git a/git-compat-util.h b/git-compat-util.h index 09b0102cae..3f615f7ed8 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -397,6 +397,21 @@ static inline char *git_find_last_dir_sep(const char *path) #define query_user_email() NULL #endif +#ifdef __TANDEM +#include +#include +#ifndef NSIG +/* NonStop NSE and NSX do not provide NSIG. SIGGUARDIAN(99) is the highest + known, by detective work using kill -l as a list is all signals + instead of signal.h where it should be. */ +# define NSIG 100 +#endif +#endif + #if defined(__HP_cc) && (__HP_cc >= 61000) #define NORETURN __attribute__((noreturn)) #define NORETURN_PTR -- 2.17.0.10.gb132f7033
RE: [PATCH v1 0/4] HPE NonStop Port Commits
On December 27, 2018 7:13, Derrick Stolee: > On 12/26/2018 6:05 PM, randall.s.bec...@rogers.com wrote: > > From: "Randall S. Becker" > > > > This set of patches is a distilled version of the minimal set of > > changes to git that will allow it to run as client and server on HPE > > NonStop NSE and NSX systems. NSR systems are no longer under support > > so references to them have been removed. Each patch in this set is > > independent but required for correctness. > > > > Randall S. Becker (4): > >transport-helper: use xread instead of read > >config.mak.uname: support for modern HPE NonStop config. > >git-compat-util.h: add FLOSS headers for HPE NonStop > >compat/regex/regcomp.c: define intptr_t and uintptr_t on NonStop > > These patches look correct to me. Just one question on patch 3 > (git-compat-util.h: add FLOSS headers for HPE NonStop). > > I'm not able to comment on patch 2 (config.mak.uname: support for modern > HPE NonStop config.), but it looks to be wrapped in a platform-specific 'if', > so should be fine if you are happy with it. Thanks! Please go for it, with v2 3/4 that should be available now. This will radically simplify our life on maintaining the port. Kind Regards, Randall et. Cohorts who know who they are.
RE: [PATCH v1 2/4] config.mak.uname: support for modern HPE NonStop config.
On December 27, 2018 12:03, Eric Sunshine wrote:
> On Wed, Dec 26, 2018 at 6:05 PM wrote:
> > A number of configuration options are not automatically detected by
> > configure mechanisms, including the location of Perl and Python.
> > [...]
> > Signed-off-by: Randall S. Becker
> > ---
> > diff --git a/config.mak.uname b/config.mak.uname @@ -441,26 +441,45
> @@
> > ifeq ($(uname_S),NONSTOP_KERNEL)
> > # Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
> > - PERL_PATH = ${prefix}/bin/perl
> > - PYTHON_PATH = ${prefix}/bin/python
> > + PERL_PATH = /usr/bin/perl
> > + PYTHON_PATH = /usr/bin/python
>
> Is the in-code comment about ${prefix} still applicable after this change?
The ${prefix} is not applicable on this platform for perl and python. Those
locations must be in /usr/bin and are managed by the Operating System vendor
not by customers. The change is wrapped in an IF so is only applicable to
NonStop.
>
> > + # The current /usr/coreutils/rm at lowest support level does not
> > work
> > + # with the git test structure. Default to the older rm.
> > + RM = /bin/rm -f
>
> This comment would be far more helpful if it explained in what way 'rm'
> actually fails with the test suite. Without that information, the comment is
> effectively useless.
There is a temporary failure in the vendor supplied rm. The cause we never
disclosed to my team. Honestly, it created a large amount of angst that should
be gone but there are still old OS versions that have this issue. This is as
much as we know.
>
> > # As detected by './configure'.
> > # Missdetected, hence commented out, see below.
> > #NO_CURL = YesPlease
> > # Added manually, see above.
> > + # Missdetected, hence commented out, see below.
> > + #NO_CURL = YesPlease
> > + # Added manually, see above.
>
> These added lines are just duplicating the existing line immediately above.
> That's weird. I'll fix it. Thanks for the catch.
>
> > + # Not detected by ./configure. Add manually.
> > + NEEDS_SSL_WITH_CURL = YesPlease
> > + NEEDS_CRYPTO_WITH_SSL = YesPlease
> > + HAVE_DEV_TTY = YesPlease
>
> I find these comments about 'configure' "misdetecting" or "not detecting"
> features confusing. The point of config.mak.uname is to provide sane
> defaults for people building without using the 'configure' script, so it feels
> weird to be talking about 'configure'
> here. Also, what does it mean to say that 'configure' "misdetects"?
> Does that mean that it fails to write assignments such as "NO_CURL =
> YesPlease" to config.autogen or does it mean that it writes incorrect
> assignments to that file?
This came from another team. We can't currently use config.autogen anyway on
the platform - this came from the prior attempt at porting. By misdetect I mean
just that, however. We do not get good values.
>
> > @@ -470,8 +489,13 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
> > + ifdef NO_PTHREADS
> > + else # WIP, use of Posix User Threads is planned but not working yet
> > + PTHREAD_CFLAGS = -D_PUT_MODEL_ -I/usr/include
> > + PTHREAD_LIBS = -lput
> > + endif
>
> Why not a simpler 'ifndef'?
Another team is current working on the PTHREAD implementation and wanted this.
I think what happened was that we have non-pthread requirements under
development. I can remove this.
[PATCH v2 2/4] config.mak.uname: support for modern HPE NonStop config.
From: "Randall S. Becker"
A number of configuration options are not automatically detected by
configure mechanisms, including the location of Perl and Python.
There was a problem at a specific set of operating system versions
that caused getopt to have compile errors. Accounted for this by
providing emulation defines for those versions.
Signed-off-by: Randall S. Becker
---
config.mak.uname | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/config.mak.uname b/config.mak.uname
index 3ee7da0e23..aa4432ac2f 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -441,26 +441,45 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
# INLINE='' would just replace one set of warnings with another and
# still not compile in c89 mode, due to non-const array initializations.
CC = cc -c99
+ # Build down-rev compatible objects that don't use our new getopt_long.
+ ifeq ($(uname_R).$(uname_V),J06.21)
+ CC += -WRVU=J06.20
+ endif
+ ifeq ($(uname_R).$(uname_V),L17.02)
+ CC += -WRVU=L16.05
+ endif
+
# Disable all optimization, seems to result in bad code, with -O or -O2
# or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
# abends on "git push". Needs more investigation.
- CFLAGS = -g -O0
+ CFLAGS = -g -O0 -Winline
# We'd want it to be here.
prefix = /usr/local
# Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
- PERL_PATH = ${prefix}/bin/perl
- PYTHON_PATH = ${prefix}/bin/python
-
+ PERL_PATH = /usr/bin/perl
+ PYTHON_PATH = /usr/bin/python
+ # The current /usr/coreutils/rm at lowest support level does not work
+ # with the git test structure. Long paths cause nftw as in
+ # 'trash directory...' break at OS releases J06.21 and L17.02.
+ # Default to the older rm until those two releases are deprecated.
+ RM = /bin/rm -f
# As detected by './configure'.
# Missdetected, hence commented out, see below.
#NO_CURL = YesPlease
# Added manually, see above.
+ NEEDS_SSL_WITH_CURL = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
+ HAVE_DEV_TTY = YesPlease
HAVE_LIBCHARSET_H = YesPlease
HAVE_STRINGS_H = YesPlease
NEEDS_LIBICONV = YesPlease
NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
NO_SYS_SELECT_H = UnfortunatelyYes
NO_D_TYPE_IN_DIRENT = YesPlease
+ NO_GETTEXT = YesPlease
NO_HSTRERROR = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
@@ -470,8 +489,13 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
NO_MKDTEMP = YesPlease
# Currently libiconv-1.9.1.
OLD_ICONV = UnfortunatelyYes
- NO_REGEX = YesPlease
+ NO_REGEX=NeedsStartEnd
NO_PTHREADS = UnfortunatelyYes
# Not detected (nor checked for) by './configure'.
# We don't have SA_RESTART on NonStop, unfortunalety.
--
2.17.0.10.gb132f7033
[PATCH v3 2/4] config.mak.uname: support for modern HPE NonStop config.
From: "Randall S. Becker"
A number of configuration options are not automatically detected by
configure mechanisms, including the location of Perl and Python.
There was a problem at a specific set of operating system versions
that caused getopt to have compile errors. Account for this by
providing emulation defines for those versions.
Signed-off-by: Randall S. Becker
---
config.mak.uname | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/config.mak.uname b/config.mak.uname
index 3ee7da0e23..aa4432ac2f 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -441,26 +441,45 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
# INLINE='' would just replace one set of warnings with another and
# still not compile in c89 mode, due to non-const array initializations.
CC = cc -c99
+ # Build down-rev compatible objects that don't use our new getopt_long.
+ ifeq ($(uname_R).$(uname_V),J06.21)
+ CC += -WRVU=J06.20
+ endif
+ ifeq ($(uname_R).$(uname_V),L17.02)
+ CC += -WRVU=L16.05
+ endif
+
# Disable all optimization, seems to result in bad code, with -O or -O2
# or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
# abends on "git push". Needs more investigation.
- CFLAGS = -g -O0
+ CFLAGS = -g -O0 -Winline
# We'd want it to be here.
prefix = /usr/local
- # Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
+ # perl and python must be in /usr/bin on NonStop - supplied by HPE
+ # with operating system in that managed directory.
- PERL_PATH = ${prefix}/bin/perl
- PYTHON_PATH = ${prefix}/bin/python
-
+ PERL_PATH = /usr/bin/perl
+ PYTHON_PATH = /usr/bin/python
+ # The current /usr/coreutils/rm at lowest support level does not work
+ # with the git test structure. Long paths cause nftw as in
+ # 'trash directory...' cause rm to terminate prematurely without fully
+ # removing the directory at OS releases J06.21 and L17.02.
+ # Default to the older rm until those two releases are deprecated.
+ RM = /bin/rm -f
# As detected by './configure'.
# Missdetected, hence commented out, see below.
#NO_CURL = YesPlease
# Added manually, see above.
+ NEEDS_SSL_WITH_CURL = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
+ HAVE_DEV_TTY = YesPlease
HAVE_LIBCHARSET_H = YesPlease
HAVE_STRINGS_H = YesPlease
NEEDS_LIBICONV = YesPlease
NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
NO_SYS_SELECT_H = UnfortunatelyYes
NO_D_TYPE_IN_DIRENT = YesPlease
+ NO_GETTEXT = YesPlease
NO_HSTRERROR = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
@@ -470,8 +489,13 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
NO_MKDTEMP = YesPlease
# Currently libiconv-1.9.1.
OLD_ICONV = UnfortunatelyYes
- NO_REGEX = YesPlease
+ NO_REGEX=NeedsStartEnd
NO_PTHREADS = UnfortunatelyYes
# Not detected (nor checked for) by './configure'.
# We don't have SA_RESTART on NonStop, unfortunalety.
--
2.17.0.10.gb132f7033
RE: Missed Commit in 2.20.1
On December 27, 2018 17:40, Ævar Arnfjörð Bjarmason wrote: > On Wed, Dec 26 2018, Randall S. Becker wrote: > > > Please stay tuned for patches. We are very much looking forward to > > having the two (or three) different NonStop hardware personalities > > supported without mods in the very near future. Our goal, assuming > > those patches are acceptable, is to move our build/test/distro into a > > Jenkins config that runs with minimal human involvement (a.k.a. me). > > Portability patches like that are definitely wanted. > > In case you haven't seen my recent work on getting GitLab CI up & running > check out https://public- > inbox.org/git/875zwm15k2@evledraar.gmail.com/ > > It differs from existing CI implementations for git.git in being focused on > doing the actual run on remote hosts that can be ssh'd to. > > So perhaps you'd be interested in some of: > > a) Contributing a NonStop box to the GCC Compile Farm >(https://cfarm.tetaneutral.net/machines/list/). Then I can add it to >my tests, but also other people porting free software will fix bugs >pro-actively before you spot them. If I win the lottery, sure. Right now, a contribution like that is a bit beyond my budget. I'm not sure that anything "GCC" will fly with management since GCC does not port to the platform at all at this point in time. Many have tried. Many have failed. We're limited to c89 and c99. > b) I now have a gitlab-runner I maintain powering this git-ci.git stuff >& presenting it on gitlab.com, if you give me SSH access I can add it >to my own runs... Sorry, no can do on this one. > c) ...or you can just run your own gitlab-runner on >https://gitlab.com/git-vcs/git-ci/ (although this amounts to giving >me ssh access, since you'll be running my code) This may be more possible. I've been considering putting up a GitLab instance but it's a matter of not having enough time. I have more than enough LXC ubuntu instances still available for something like that. > d) ... or reuse the CI code I wrote to setup your own runner/pusher >against NonStop, only you'd have access to this More likely. Private chat worth it perhaps. > e) Or do whatever you're planning with Jenkins. We are currently using Jenkins to build/test git. I was thinking about contributing a Jenkinsfile that would build on a Controller (what happens today for our git port), or setting up a parameterized form for SSH for an Agent that might be better in a farm setting. I am close to the point where human interaction is limited to 'git branch -f production vn.mm.l' and git is tested and built for distribution without further touching. At least once my platform patches are applied it will be. > If you want to just go with e) that's fine, just saying that you could re-use > some existing stuff with a-d) if you wanted. I am interested. Let's see how my $DAYJOB goes in the next few months. I really do like the idea of setting up a community instance of GitLab to do this and include a CI runner. Hmmm. Cheers, Randall
RE: [PATCH v3 2/4] config.mak.uname: support for modern HPE NonStop config.
On December 28, 2018 14:43, Eric Sunshine wrote: > On Thu, Dec 27, 2018 at 5:39 PM wrote: > > A number of configuration options are not automatically detected by > > configure mechanisms, including the location of Perl and Python. > > > > There was a problem at a specific set of operating system versions > > that caused getopt to have compile errors. Account for this by > > providing emulation defines for those versions. > > This version of the patch looks much better and addresses my comments on > previous attempts. One note below... > > > Signed-off-by: Randall S. Becker > > --- > > diff --git a/config.mak.uname b/config.mak.uname @@ -441,26 +441,45 > @@ > > ifeq ($(uname_S),NONSTOP_KERNEL) > > + # The current /usr/coreutils/rm at lowest support level does not > > work > > + # with the git test structure. Long paths cause nftw as in > > + # 'trash directory...' cause rm to terminate prematurely without > > fully > > + # removing the directory at OS releases J06.21 and L17.02. > > + # Default to the older rm until those two releases are deprecated. > > + RM = /bin/rm -f > > Thanks, this comment does a much better job of explaining the actual > problem and selling the solution. > > There is a slight grammatical problem: > > Long paths _cause_ ... _cause_ rm to terminate... > > which might deserve fixing. Rerolled. Thanks.
[PATCH v4 2/4] config.mak.uname: support for modern HPE NonStop config.
From: "Randall S. Becker"
A number of configuration options are not automatically detected by
configure mechanisms, including the location of Perl and Python.
There was a problem at a specific set of operating system versions
that caused getopt to have compile errors. Account for this by
providing emulation defines for those versions.
Signed-off-by: Randall S. Becker
---
config.mak.uname | 34 +-
1 file changed, 29 insertions(+), 5 deletions(-)
diff --git a/config.mak.uname b/config.mak.uname
index 3ee7da0e23..aa4432ac2f 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -441,26 +441,45 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
# INLINE='' would just replace one set of warnings with another and
# still not compile in c89 mode, due to non-const array initializations.
CC = cc -c99
+ # Build down-rev compatible objects that don't use our new getopt_long.
+ ifeq ($(uname_R).$(uname_V),J06.21)
+ CC += -WRVU=J06.20
+ endif
+ ifeq ($(uname_R).$(uname_V),L17.02)
+ CC += -WRVU=L16.05
+ endif
+
# Disable all optimization, seems to result in bad code, with -O or -O2
# or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
# abends on "git push". Needs more investigation.
- CFLAGS = -g -O0
+ CFLAGS = -g -O0 -Winline
# We'd want it to be here.
prefix = /usr/local
- # Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
+ # perl and python must be in /usr/bin on NonStop - supplied by HPE
+ # with operating system in that managed directory.
- PERL_PATH = ${prefix}/bin/perl
- PYTHON_PATH = ${prefix}/bin/python
-
+ PERL_PATH = /usr/bin/perl
+ PYTHON_PATH = /usr/bin/python
+ # The current /usr/coreutils/rm at lowest support level does not work
+ # with the git test structure. Long paths as in
+ # 'trash directory...' cause rm to terminate prematurely without fully
+ # removing the directory at OS releases J06.21 and L17.02.
+ # Default to the older rm until those two releases are deprecated.
+ RM = /bin/rm -f
# As detected by './configure'.
# Missdetected, hence commented out, see below.
#NO_CURL = YesPlease
# Added manually, see above.
+ NEEDS_SSL_WITH_CURL = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
+ HAVE_DEV_TTY = YesPlease
HAVE_LIBCHARSET_H = YesPlease
HAVE_STRINGS_H = YesPlease
NEEDS_LIBICONV = YesPlease
NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
NO_SYS_SELECT_H = UnfortunatelyYes
NO_D_TYPE_IN_DIRENT = YesPlease
+ NO_GETTEXT = YesPlease
NO_HSTRERROR = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
@@ -470,8 +489,13 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
NO_MKDTEMP = YesPlease
# Currently libiconv-1.9.1.
OLD_ICONV = UnfortunatelyYes
- NO_REGEX = YesPlease
+ NO_REGEX=NeedsStartEnd
NO_PTHREADS = UnfortunatelyYes
# Not detected (nor checked for) by './configure'.
# We don't have SA_RESTART on NonStop, unfortunalety.
--
2.17.0.10.gb132f7033
RE: [PATCH v1 2/4] config.mak.uname: support for modern HPE NonStop config.
On December 28, 2018 15:07, Junio C Hamano
> "Randall S. Becker" writes:
>
> > On December 27, 2018 12:03, Eric Sunshine wrote:
> >> On Wed, Dec 26, 2018 at 6:05 PM wrote:
> >> > A number of configuration options are not automatically detected by
> >> > configure mechanisms, including the location of Perl and Python.
> >> > [...]
> >> > Signed-off-by: Randall S. Becker
> >> > ---
> >> > diff --git a/config.mak.uname b/config.mak.uname @@ -441,26
> +441,45
> >> @@
> >> > ifeq ($(uname_S),NONSTOP_KERNEL)
> >> > # Our's are in ${prefix}/bin (perl might also be in
/usr/bin/perl).
> >> > - PERL_PATH = ${prefix}/bin/perl
> >> > - PYTHON_PATH = ${prefix}/bin/python
> >> > + PERL_PATH = /usr/bin/perl
> >> > + PYTHON_PATH = /usr/bin/python
> >>
> >> Is the in-code comment about ${prefix} still applicable after this
change?
> >
> > The ${prefix} is not applicable on this platform for perl and python.
> > Those locations must be in /usr/bin and are managed by the Operating
> > System vendor not by customers. The change is wrapped in an IF so is
> > only applicable to NonStop.
>
> So the answer is "Our's are in ${prefix}/bin..." is no longer correct? If
so, this
> patch must remove that stale comment at the same time, no?
Yessir. Fixed at v3 (now at v4).
RE: [PATCH v1 1/4] transport-helper: use xread instead of read
On December 28, 2018 15:11, Junio C Hamano wrote:
> randall.s.bec...@rogers.com writes:
>
> > From: "Randall S. Becker"
> >
> > This fix was needed on HPE NonStop NSE and NSX where SSIZE_MAX is less
> > than BUFFERSIZE resulting in EINVAL. The call to read in
> > transport-helper.c was the only place outside of wrapper.c where it is
used
> instead of xread.
> >
> > Signed-off-by: Randall S. Becker
> > ---
> > transport-helper.c | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/transport-helper.c b/transport-helper.c index
> > bf225c698f..a290695a12 100644
> > --- a/transport-helper.c
> > +++ b/transport-helper.c
> > @@ -1225,7 +1225,7 @@ static int udt_do_read(struct
> unidirectional_transfer *t)
> > return 0; /* No space for more. */
> >
> > transfer_debug("%s is readable", t->src_name);
> > - bytes = read(t->src, t->buf + t->bufuse, BUFFERSIZE - t->bufuse);
> > + bytes = xread(t->src, t->buf + t->bufuse, BUFFERSIZE - t->bufuse);
> > if (bytes < 0 && errno != EWOULDBLOCK && errno != EAGAIN &&
> > errno != EINTR) {
> > error_errno(_("read(%s) failed"), t->src_name);
>
> As Peff pointed out in the earlier round of the same patch, replacing
read()
> with xread() here will affect what errno's can be possible after the
function
> returns. The checks affected by this change must also be updated, either
in
> the same patch, or a follow-up patch in the same series. Otherwise we
> _will_ forget to clean them up.
If I read the xread code correctly, the change would be to leave EINTR and
remove the other two conditions. Correct?
[PATCH v4 1/4] transport-helper: use xread instead of read
From: "Randall S. Becker"
This fix was needed on HPE NonStop NSE and NSX where SSIZE_MAX is less than
BUFFERSIZE resulting in EINVAL. The call to read in transport-helper.c
was the only place outside of wrapper.c where it is used instead of xread.
Signed-off-by: Randall S. Becker
---
transport-helper.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/transport-helper.c b/transport-helper.c
index bf225c698f..a290695a12 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -1225,7 +1225,7 @@ static int udt_do_read(struct unidirectional_transfer *t)
return 0; /* No space for more. */
transfer_debug("%s is readable", t->src_name);
- bytes = read(t->src, t->buf + t->bufuse, BUFFERSIZE - t->bufuse);
+ bytes = xread(t->src, t->buf + t->bufuse, BUFFERSIZE - t->bufuse);
- if (bytes < 0 && errno != EWOULDBLOCK && errno != EAGAIN &&
- errno != EINTR) {
+ if (bytes < 0 && errno != EINTR) {
error_errno(_("read(%s) failed"), t->src_name);
--
2.17.0.10.gb132f7033
[BUG] t0410 2.20.1 fails on NonStop NSX platform
This is a bit of a head-scratcher. There are two NonStop platforms, which behave essentially the same way. One, NSE, uses ia64, while NSX uses x64. There are subtle differences in ksh and bash for the platforms based on what is released when. The NSE platform has no problem running t0410 in Jenkins. However, NSX fails in a few spots: This is at 2.20.1. Our last port on this platform variant was 2.16.1, where there were no unexplained issues. I am suspecting that the problem is shell related, but I'm just not sure what the test is supposed to do here. There are 9 other failures that appear related, with the No such file or directory condition. If I add the -f flag to rm in delete_object(), all t0410 tests pass except the last (22), but I don't think that meets the intent of test itself. I wonder whether one of the authors of the test might chime in on this. The first, subtest 12 results in: Initialized empty Git repository in /mypath/git/t/trash directory.t0410-partial-clone/repo/.git/ [master (root-commit) 7745948] foo Author: A U Thor 1 file changed, 1 insertion(+) create mode 100644 foo.t [master e514b54] bar Author: A U Thor 1 file changed, 1 insertion(+) create mode 100644 bar.t Enumerating objects: 1, done. Counting objects: 100% (1/1), done. Writing objects: 100% (1/1), done. Total 1 (delta 0), reused 0 (delta 0) 2b7df34bc09be010087307b898e994ce709c0db1 rm: cannot remove 'repo/.git/objects/2b/7df34bc09be010087307b898e994ce709c0db1': No such file or directory not ok 12 - rev-list stops traversal at missing and promised commit # # rm -rf repo && # test_create_repo repo && # test_commit -C repo foo && # test_commit -C repo bar && # # FOO=$(git -C repo rev-parse foo) && # promise_and_delete "$FOO" && # # git -C repo config core.repositoryformatversion 1 && # git -C repo config extensions.partialclone "arbitrary string" && # GIT_TEST_COMMIT_GRAPH=0 git -C repo rev-list --exclude-promisor-objects --objects bar >out && # grep $(git -C repo rev-parse bar) out && # ! grep $FOO out # Cheers, Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
[Patch v5 1/4] transport-helper: use xread instead of read
From: "Randall S. Becker"
This fix was needed on HPE NonStop NSE and NSX where SSIZE_MAX is less than
BUFFERSIZE resulting in EINVAL. The call to read in transport-helper.c
was the only place outside of wrapper.c where it is used instead of xread.
Signed-off-by: Randall S. Becker
---
transport-helper.c | 5 ++---
1 file changed, 2 insertions(+), 3 deletions(-)
diff --git a/transport-helper.c b/transport-helper.c
index bf225c698..5afead9f8 100644
--- a/transport-helper.c
+++ b/transport-helper.c
@@ -1225,9 +1225,8 @@ static int udt_do_read(struct unidirectional_transfer *t)
return 0; /* No space for more. */
transfer_debug("%s is readable", t->src_name);
- bytes = read(t->src, t->buf + t->bufuse, BUFFERSIZE - t->bufuse);
- if (bytes < 0 && errno != EWOULDBLOCK && errno != EAGAIN &&
- errno != EINTR) {
+ bytes = xread(t->src, t->buf + t->bufuse, BUFFERSIZE - t->bufuse);
+ if (bytes < 0 && errno != EINTR) {
error_errno(_("read(%s) failed"), t->src_name);
return -1;
} else if (bytes == 0) {
--
2.12.3
[Patch v5 2/4] config.mak.uname: support for modern HPE NonStop config.
From: "Randall S. Becker"
A number of configuration options are not automatically detected by
configure mechanisms, including the location of Perl and Python.
There was a problem at a specific set of operating system versions
that caused getopt to have compile errors. Account for this by
providing emulation defines for those versions.
Signed-off-by: Randall S. Becker
---
config.mak.uname | 29 +++--
1 file changed, 23 insertions(+), 6 deletions(-)
diff --git a/config.mak.uname b/config.mak.uname
index 3ee7da0e2..686156d53 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -441,26 +441,43 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
# INLINE='' would just replace one set of warnings with another and
# still not compile in c89 mode, due to non-const array initializations.
CC = cc -c99
+ # Build down-rev compatible objects that don't use our new getopt_long.
+ ifeq ($(uname_R).$(uname_V),J06.21)
+ CC += -WRVU=J06.20
+ endif
+ ifeq ($(uname_R).$(uname_V),L17.02)
+ CC += -WRVU=L16.05
+ endif
# Disable all optimization, seems to result in bad code, with -O or -O2
# or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
# abends on "git push". Needs more investigation.
- CFLAGS = -g -O0
+ CFLAGS = -g -O0 -Winline
# We'd want it to be here.
prefix = /usr/local
- # Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
- PERL_PATH = ${prefix}/bin/perl
- PYTHON_PATH = ${prefix}/bin/python
-
+ # perl and python must be in /usr/bin on NonStop - supplied by HPE
+ # with operating system in that managed directory.
+ PERL_PATH = /usr/bin/perl
+ PYTHON_PATH = /usr/bin/python
+ # The current /usr/coreutils/rm at lowest support level does not work
+ # with the git test structure. Long paths as in
+ # 'trash directory...' cause rm to terminate prematurely without fully
+ # removing the directory at OS releases J06.21 and L17.02.
+ # Default to the older rm until those two releases are deprecated.
+ RM = /bin/rm -f
# As detected by './configure'.
# Missdetected, hence commented out, see below.
#NO_CURL = YesPlease
# Added manually, see above.
+ NEEDS_SSL_WITH_CURL = YesPlease
+ NEEDS_CRYPTO_WITH_SSL = YesPlease
+ HAVE_DEV_TTY = YesPlease
HAVE_LIBCHARSET_H = YesPlease
HAVE_STRINGS_H = YesPlease
NEEDS_LIBICONV = YesPlease
NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
NO_SYS_SELECT_H = UnfortunatelyYes
NO_D_TYPE_IN_DIRENT = YesPlease
+ NO_GETTEXT = YesPlease
NO_HSTRERROR = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
@@ -470,7 +487,7 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
NO_MKDTEMP = YesPlease
# Currently libiconv-1.9.1.
OLD_ICONV = UnfortunatelyYes
- NO_REGEX = YesPlease
+ NO_REGEX=NeedsStartEnd
NO_PTHREADS = UnfortunatelyYes
# Not detected (nor checked for) by './configure'.
--
2.12.3
[Patch v5 3/4] git-compat-util.h: add FLOSS headers for HPE NonStop
From: "Randall S. Becker" The HPE NonStop (a.k.a. __TANDEM) platform cannot build git without using the FLOSS package supplied by HPE. The convenient location for including the relevant headers is in this file. The NSIG define is also not defined on __TANDEM, so we define it here as 100 if it is not defined only for __TANDEM builds. Signed-off-by: Randall S. Becker --- git-compat-util.h | 11 +++ 1 file changed, 11 insertions(+) diff --git a/git-compat-util.h b/git-compat-util.h index 09b0102ca..3da6f0673 100644 --- a/git-compat-util.h +++ b/git-compat-util.h @@ -397,6 +397,17 @@ static inline char *git_find_last_dir_sep(const char *path) #define query_user_email() NULL #endif +#ifdef __TANDEM +#include +#include +#ifndef NSIG +/* NonStop NSE and NSX do not provide NSIG. SIGGUARDIAN(99) is the highest + known, by detective work using kill -l as a list is all signals + instead of signal.h where it should be. */ +# define NSIG 100 +#endif +#endif + #if defined(__HP_cc) && (__HP_cc >= 61000) #define NORETURN __attribute__((noreturn)) #define NORETURN_PTR -- 2.12.3
[Patch v5 4/4] compat/regex/regcomp.c: define intptr_t and uintptr_t on NonStop
From: "Randall S. Becker" The system definition header files on HPE NonStop do not define intptr_t and uintptr_t as do other platforms. These typedefs are added specifically wrapped in a __TANDEM ifdef. Signed-off-by: Randall S. Becker --- compat/regex/regcomp.c | 8 1 file changed, 8 insertions(+) diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c index 51cd60baa..c0d838834 100644 --- a/compat/regex/regcomp.c +++ b/compat/regex/regcomp.c @@ -17,6 +17,14 @@ License along with the GNU C Library; if not, see <http://www.gnu.org/licenses/>. */ +#if defined __TANDEM + /* This is currently duplicated from git-compat-utils.h */ +# ifdef NO_INTPTR_T + typedef long intptr_t; + typedef unsigned long uintptr_t; +# endif +#endif + static reg_errcode_t re_compile_internal (regex_t *preg, const char * pattern, size_t length, reg_syntax_t syntax); static void re_compile_fastmap_iter (regex_t *bufp, -- 2.12.3
[Patch v5 0/4] HPE NonStop Port Commits
From: "Randall S. Becker" This set of patches is a distilled version of the minimal set of changes to git that will allow it to run as client and server on HPE NonStop NSE and NSX systems. NSR systems are no longer under support so references to them have been removed. Each patch in this set is independent but required for correctness. Randall S. Becker (4): transport-helper: use xread instead of read config.mak.uname: support for modern HPE NonStop config. git-compat-util.h: add FLOSS headers for HPE NonStop compat/regex/regcomp.c: define intptr_t and uintptr_t on NonStop compat/regex/regcomp.c | 8 config.mak.uname | 29 +++-- git-compat-util.h | 11 +++ transport-helper.c | 5 ++--- 4 files changed, 44 insertions(+), 9 deletions(-) -- 2.12.3
RE: [Patch v5 2/4] config.mak.uname: support for modern HPE NonStop config.
On January 3, 2019 16:38, Eric Sunshine wrote: > On Thu, Jan 3, 2019 at 4:04 PM wrote: > > A number of configuration options are not automatically detected by > > configure mechanisms, including the location of Perl and Python. > > > > There was a problem at a specific set of operating system versions > > that caused getopt to have compile errors. Account for this by > > providing emulation defines for those versions. > > > > Signed-off-by: Randall S. Becker > > --- > > diff --git a/config.mak.uname b/config.mak.uname @@ -470,7 +487,7 > @@ > > ifeq ($(uname_S),NONSTOP_KERNEL) > > NO_MKDTEMP = YesPlease > > OLD_ICONV = UnfortunatelyYes > > - NO_REGEX = YesPlease > > + NO_REGEX=NeedsStartEnd > > NO_PTHREADS = UnfortunatelyYes > > Style nit (probably not worth a re-roll): you lost the whitespace surrounding > '=' I can fix this one in the next round of changes, or after this gets in, if that works, or signoff on this being fixed in place.
RE: [Patch v5 3/4] git-compat-util.h: add FLOSS headers for HPE NonStop
On January 3, 2019 16:41, Eric Sunshine wrote: > On Thu, Jan 3, 2019 at 4:04 PM wrote: > > The HPE NonStop (a.k.a. __TANDEM) platform cannot build git without > > using the FLOSS package supplied by HPE. The convenient location for > > including the relevant headers is in this file. > > > > The NSIG define is also not defined on __TANDEM, so we define it here > > as 100 if it is not defined only for __TANDEM builds. > > > > Signed-off-by: Randall S. Becker > > --- > > diff --git a/git-compat-util.h b/git-compat-util.h @@ -397,6 +397,17 > > @@ static inline char *git_find_last_dir_sep(const char *path) > > +#ifdef __TANDEM > > +#include > > +#include > > +#ifndef NSIG > > +/* NonStop NSE and NSX do not provide NSIG. SIGGUARDIAN(99) is the > highest > > + known, by detective work using kill -l as a list is all signals > > + instead of signal.h where it should be. */ > > Style nit: With two minor exceptions, all other multi-line comments in this > file > are formatted as: > > /* > * Multi-line > * comment. > */ Doh! I just missed that one. I'll fix this on the next round, if that's ok.
[Possible Bug] Commit generates GC repack failure
Hi All, I'm trying to track down what happened this morning. We had a commit that caused a background gc to occur. What happened was: $ git commit -m "history commit ... " Auto packing the repository in background for optimum performance. See "git help gc" for manual housekeeping. warning: The last gc run reported the following. Please correct the root cause and remove .git/gc.log. Automatic cleanup will not be performed until the file is removed. fatal: open /dev/null failed: Invalid function argument fatal: failed to run repack Obviously the /dev/null open was not right, but I don't know where this is in the git code to investigate further. Any pointers on where to look would be appreciated. This started happening at 2.20.1 on the NonStop platform. Cheers, Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: [Possible Bug] Commit generates GC repack failure
On January 14, 2019 10:12, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Jan 14 2019, Randall S. Becker wrote:
>
> > Hi All,
> >
> > I'm trying to track down what happened this morning. We had a commit
> > that caused a background gc to occur. What happened was:
> >
> > $ git commit -m "history commit ... "
> > Auto packing the repository in background for optimum performance.
> > See "git help gc" for manual housekeeping.
> > warning: The last gc run reported the following. Please correct the
> > root cause and remove .git/gc.log.
> > Automatic cleanup will not be performed until the file is removed.
> >
> > fatal: open /dev/null failed: Invalid function argument
> > fatal: failed to run repack
> >
> > Obviously the /dev/null open was not right, but I don't know where
> > this is in the git code to investigate further. Any pointers on where
> > to look would be appreciated. This started happening at 2.20.1 on the
> NonStop platform.
>
> We use start_command() when gc does run_command_v_opt() of e.g. git-
> repack. See in that file:
>
> null_fd = open("/dev/null", O_RDWR | O_CLOEXEC)
>
> Maybe that sort of code just fails on NonStop?
That line of code works fine on the platform. I tested it in isolation at
various OS levels. Let me go back and say that I'm not 100% sure this is new,
but may have been there since just before 2.16. Still perplexed recognizing
that that is the only point in git code where that can happen.
Cheers,
Randall
RE: [PATCH] blame: add the ability to ignore commits
On January 14, 2019 12:46, Junio C Hamano wrote: > Barret Rhoden writes: > > > On 2019-01-10 at 14:29 Junio C Hamano wrote: > >> > For instance, commit X does this: > >> > > >> > -foo(x,y); > >> > +foo(x,y,z); > >> > > >> > Then commit Y comes along to reformat it: > >> > > >> > -foo(x,y,z); > >> > +foo(x, y, z); > >> > > >> > And the history / rev-list for the file looks like: > >> > > >> > ---O---A---X---B---C---D---Y---E---F > >> > > >> > I want to ignore/skip Y and see X in the blame output. > >> > >> If you skip Y, the altered history would have "foo(x, y, z)" in E, > >> "foo(x,y,z)" in X, and "foo(x,y)" in A. If you start blaming from F, > >> you'd get E as the commit that explains the latest state. If you do > >> not skip Y, you'd get Y. I am not sure how you'd get X in either > >> case. > > > > The way to do it is ... > > Sorry, I made a too-fuzzy statement. What I meant was, that unless you are > ignoring E, I do not know why you "would want to" attribute a line "foo(x, y, > z)" that appears in F to X. Starting from X up to D (and to Y in real history, but > you are ignoring Y), the line was "foo(x,y,z)", after E, it is "foo(x, y, z)". I > didn't mean to ask how you "would show" such a result---as I do not yet > understand why you would want such a result to begin with. >From my own community, this came up also. The intent was to show everyone who touched a particular line, throughout history, not just the current one. Perhaps that is what Barret is going for. Regards, Randall
RE: [Not Git Bug] Commit generates GC repack failure
On January 14, 2019 10:07, Duy Nguyen wrote: > To: Randall S. Becker > Cc: Git Mailing List > Subject: Re: [Possible Bug] Commit generates GC repack failure > > On Mon, Jan 14, 2019 at 10:03 PM Duy Nguyen > wrote: > > > > On Mon, Jan 14, 2019 at 9:51 PM Randall S. Becker > > wrote: > > > > > > Hi All, > > > > > > I'm trying to track down what happened this morning. We had a commit > > > that caused a background gc to occur. What happened was: > > > > > > $ git commit -m "history commit ... " > > > Auto packing the repository in background for optimum performance. > > > See "git help gc" for manual housekeeping. > > > warning: The last gc run reported the following. Please correct the > > > root cause and remove .git/gc.log. > > > Automatic cleanup will not be performed until the file is removed. > > > > > > fatal: open /dev/null failed: Invalid function argument > > > > sanitize_stdfds() in setup.c can attempt to open /dev/null then > > redirect stdout and stderr to it. I think this is part of the > > daemonization that is done in background gc. > > However the message does not match. I think you will find this "open > /dev/null failed" line in run-command.c Mystery solved. The problem seems to occur with garbage collection on older versions of the operating system than the one we built 2.20.1 on. We sent out the advice to revert to 2.16.2, which was built on a prior revision that did not introduce incompatibilities. This was a specific situation with header files on a new version of the OS that introduced incompatibilities. The impact was not limited to the line in run-command.c, but was way more extensive. Thanks for the help, Randall
RE:
On January 23, 2019 11:00, Christopher Hagler wrote: > Send the email to this address > majord...@vger.kernel.org and it will work > > On Jan 23, 2019, at 8:16 AM, Cody Kratzer > > I've sent this same email 3 times. I don't think it works. I'm > > researching this morning how to unsubscribe from this git group. > > > > CODY KRATZER WEB DEVELOPMENT MANAGER > > 866-344-3875 x145 > > c...@lightingnewyork.com > > M - F 9 - 5:30 > > On Wed, Jan 23, 2019 at 5:51 AM Christopher Hagler > > wrote: > >> > >> Unsubscribe git Reference information to the mailing lists are available here: http://vger.kernel.org/vger-lists.html#git
RE: Git checkout multiple options issue
On January 28, 2019 8:25, COLLOMB Joris wrote: > git checkout -fb "branch_name" > (force branch creation and checkout it) > > doesn't work (even if option a separated). > > I don't know if this is consider as an issue, but here it is. I think you might mean (which works on every platform I have): git checkout -f -b "branch_name" There is no provision for aggregating options into one. -fb (invalid) is not the same as -f -b (valid). Regards, Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
RE: Git checkout multiple options issue
On January 28, 2019 9:25, COLLOMB Joris wrote: > -Message d'origine- >> De : Randall S. Becker Envoyé : lundi 28 janvier >> 2019 15:12 À : COLLOMB Joris -EXT ; >> git@vger.kernel.org Objet : RE: Git checkout multiple options issue >> >> On January 28, 2019 8:25, COLLOMB Joris wrote: >> > git checkout -fb "branch_name" >> > (force branch creation and checkout it) >> > >> > doesn't work (even if option a separated). >> > >> > I don't know if this is consider as an issue, but here it is. >> >> I think you might mean (which works on every platform I have): >> >> git checkout -f -b "branch_name" >> >> There is no provision for aggregating options into one. -fb (invalid) is not the >> same as -f -b (valid). > git checkout -f -b "branch_name" > gives me " Fatal: A branch named 'branch_name' already exists." Once the branch is created, you can't force its creation, because it is already created. Just git checkout "branch_name" is sufficient at this point. git is correct to complain that you are trying to create a branch that already exists. git log --decorate --oneline --graph --all will show you where your branch points in history at any given moment in time in a convenient form. > I understand that here the checkout is force, but not the branch creation. > The opposite option order doesn't work: > > git checkout -b -f "branch_name" > gives me "Fatal: '-f' is not a valid branch name." In this case, you are asking git to create a branch named -f (the -b branch option). Then "branch_name" becomes the reference that would be used to find the commit that -f would have pointed to. However, -f is not a valid name because it is an option and git is correct to reject it. git checkout options are described here: https://git-scm.com/docs/git-checkout Regards, Randall
RE: Git checkout multiple options issue
On January 28, 2019 11:03, COLLOMB Joris wrote: >> -Message d'origine----- >> De : Randall S. Becker Envoyé : lundi 28 janvier >> 2019 16:20 À : COLLOMB Joris -EXT ; >> git@vger.kernel.org Objet : RE: Git checkout multiple options issue >> >> On January 28, 2019 9:25, COLLOMB Joris wrote: >> > -Message d'origine- >> >> De : Randall S. Becker Envoyé : lundi 28 >> >> janvier >> >> 2019 15:12 À : COLLOMB Joris -EXT >> >> ; >> >> git@vger.kernel.org Objet : RE: Git checkout multiple options issue >> >> >> >> On January 28, 2019 8:25, COLLOMB Joris wrote: >> >> > git checkout -fb "branch_name" >> >> > (force branch creation and checkout it) >> >> > >> >> > doesn't work (even if option a separated). >> >> > >> >> > I don't know if this is consider as an issue, but here it is. >> >>. >> >> I think you might mean (which works on every platform I have): >> >> >> >> git checkout -f -b "branch_name" >> >> >> >> There is no provision for aggregating options into one. -fb (invalid) >> >> is >> not the >> >> same as -f -b (valid). >> >> > git checkout -f -b "branch_name" >> > gives me " Fatal: A branch named 'branch_name' already exists." >> >> Once the branch is created, you can't force its creation, because it is >> already >> created. Just >> >> git checkout "branch_name" >> >> is sufficient at this point. git is correct to complain that you are trying >> to >> create a branch that already exists. >> >> git log --decorate --oneline --graph --all >> >> will show you where your branch points in history at any given moment in >> time in a convenient form. > >> > I understand that here the checkout is force, but not the branch creation. >> > The opposite option order doesn't work: >> > >> > git checkout -b -f "branch_name" >> > gives me "Fatal: '-f' is not a valid branch name." >> >> In this case, you are asking git to create a branch named -f (the -b branch >> option). Then "branch_name" becomes the reference that would be used to >> find the commit that -f would have pointed to. However, -f is not a valid >> name because it is an option and git is correct to reject it. >> >> git checkout options are described here: >> https://git-scm.com/docs/git-checkout >> > Once the branch is created, you can't force its creation, because it is >> already created. > Sorry to not be agree, in the man page of git branch: > >-f, --force >Reset to if exists already. > Without -f git branch refuses to change an existing branch. In combination > with -d (or --delete), allow >deleting the branch irrespective of its merged status. In > combination > with -m (or --move), allow renaming the branch even if the new branch name > already exists. > > The behavior I was expecting with > git checkout -b -f "branch_name" > is a checkout on a forced branch creation at . > > So the only solution for me is : > git branch -f "branch_name" && git checkout "branch_name" > > So to resume: > - This is not an issue, just a divergence between my logic and git > implementation. > - The message "Fatal: '-f' is not a valid branch name." is maybe not optimal, > and it may better be " Fatal: you trying to force the creation of a branch. > Please do "git branch -f" if you know what you're doing" A few things: 1. Please put your responses at the end, by convention, for this distribution list so that I don't have to reformat the message each time 😉 2. You cannot assume that a flag in one command is going to do the same thing in another command. -f in checkout means one thing. -f in branch means something different. It is dangerous to conflate the meaning of flags between commands. 3. git branch -f is used to force a branch move on a branch that you do not have checked out, so mixing these is semantically incorrect. git branch -f will deliberately fail if you try to use it on the branch that is checked out. This is correct behaviour. 4. git checkout -f means to do the checkout even if the HEAD and working index do not match and has nothing to do with branch creation. These are entirely different meanings and must not be "blended" into one concept. 5.
RE: [BUG]: git checkout on a new tag with current HEAD shows "head detached" at previous tag
On February 5, 2019 4:20, Dani Koretsky wrote: > I have 2 tags such as release-17.6.230 and release-17.6.220: > If I'm changing commits, all works as expected. > > If however both are pointing to the same commit, the output is as follows: > > git checkout release-17.6.220 > git status > HEAD detached at release-17.6.220 > > now if I run: > git checkout release-17.6.230 > git status > HEAD detached at release-17.6.220 > > Which is theoretically correct, but I'd expect after checking out a certain > tag > I'd be see that specific tag... > > Sorry if this is intended behavior, I couldn't find clear mention of this > behavior on the git checkout documentation online.. Please use git checkout -b release-17.6.220 What your commands above have done is resolved release-17.6.220 to a commit, then checked out that commit instead of creating a branch. Alternatively, use git checkout -b new-branch release-17.6.220 to name it something else. Regards, Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
[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: [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
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 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 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
[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: [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 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 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
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: 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: 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: [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: [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-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
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
[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 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 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
[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 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
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
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
[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: [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
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: [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
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 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.
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: [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(-)
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
[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: [RFE] Please add name and email to git credentials
On November 1, 2018 10:13 AM, Christian Couder wrote: > Sent: > To: nicolas.mail...@laposte.net > Cc: git > Subject: Re: [RFE] Please add name and email to git credentials > > On Thu, Nov 1, 2018 at 2:31 PM Nicolas Mailhot > wrote: > > > > Le jeudi 01 novembre 2018 à 12:22 +0100, Ævar Arnfjörð Bjarmason a > > écrit : > > > > > > Where would we get an E-Mail to lookup to pass to the helper? Are > > > you just asking that the helper git the result of $(git config > > > user.name && git config user.email)? If so why can't it just look > > > this up itself? > > > > So, just in case it was not clear enough, allow things in .gitconfig > > like > > > > [credential "https://pkgs.fedoraproject.org/";] > > username = doe4ever > > name = John Doe > > email = doe4e...@fedoraproject.org > > [credential "https://gitlab.corp.com/";] username = jdoe56874 name = > > John Doe, Snr Engineer email = john@corp.com > > > > Instead of just > > > > [user] > > name = John Doe > > email = john@corp.com > > [credential "https://pkgs.fedoraproject.org/";] > > username = doe4ever > > [credential "https://gitlab.corp.com/";] username = jdoe56874 > > > > and drat, I've commited to XXX with the wrong name/email again > > How can Git know when you commit where you will want to push the > commit afterwards? > > What if you want to push the same commit to 2 different places that need > different credentials? Agree. You are asking git to change history depending on where pushes are done. Applying a legacy VCS paradigm here? Git has a global view of history. It must be the same everywhere, so if you push to two different places, the history must be the same, because those two places may in turn push to another shared repo. Then who is the authority? What I have managed to do is to associated name and email with config --local so that it binds to the clone and overrides your --global setting. I can have different identities based on what clone I am working on, but once history is created, that's it. If I push from one clone to another, the identity of the clone where I did my first commit is what the second clone sees. Hope this helps. Randall -- Brief whoami: NonStop developer since approximately 2112884442 UNIX developer since approximately 421664400 -- In my real life, I talk too much.
