RE: [RFC] git clean --local

[Randall S. Becker]

On December 2, 2018 8:26, Ævar Arnfjörð Bjarmason wrote:
> 
> On Sat, Dec 01 2018, Cameron Boehmer wrote:
> 
> > 1) add a new flag
> > -l, --local
> > Do not consult git config --global core.excludesFile in
> > determining what files git ignores. This is useful in conjunction with
> > -x/-X to preserve user files while removing build artifacts.
> 
> Or perhaps a general flag to ignore configuration would be useful for such
> cases, see https://public-
> inbox.org/git/87zhtqvm66@evledraar.gmail.com/

Would something like git clean --exclude=file-pattern work as a compromise 
notion? Files matching the pattern would not be cleaned regardless of 
.gitignore or their potential preciousness status long-term. Multiple 
repetitions of the --exclude option might be supportable. I could see that 
being somewhat useful in scripting.

Cheers,
Randall

RE: Git Tags

[Randall S. Becker]

On November 29, 2018 6:56, Mateusz Loskot wrote:
> On Thu, 29 Nov 2018 at 12:50, Stefanie Leisestreichler
>  wrote:
> >
> > git tag -a 0.9.0
> > git push origin master
> >
> > In my local repository, when I run "git tag" it is showing me "0.9.0".
> >
> > Then I did (on box B)
> > git clone ssh://user@host:/path/project.git cd project git tag
> >
> > Now git tag is showing nothing.
> >
> > Why is the tag only available in my local repository?
> 
> >From https://git-scm.com/book/en/v2/Git-Basics-Tagging
> "By default, the git push command doesn’t transfer tags to remote servers.
> You will have to explicitly push tags to a shared server after you have 
> created
> them."

git push --tags

and

git fetch --tags

to be symmetrical

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: Cygwin Git with Windows paths

[Randall S. Becker]

> -Original Message-
> From: git-ow...@vger.kernel.org  On Behalf Of
> Junio C Hamano
> Sent: November 18, 2018 19:07
> To: Torsten Bögershausen 
> Cc: Steven Penny ; git@vger.kernel.org
> Subject: Re: Cygwin Git with Windows paths
> 
> Torsten Bögershausen  writes:
> 
> > And it may even be that we need a special handling for the "\" to be
> > treated as "/".
> 
> I do not do Windows, but is_dir_sep() needs to be tweaked if you want to do
> that.

Heavy Cygwin user here. It is used in my environment for cross-compilation. 
Everything should be done using / separators in Cygwin, not \. So /cygdrive/c, 
/cygdrive/d always prefaces the path rather than C:\ or D:\, which won't parse. 
It is, essentially, a bash environment, including that git completions work 
properly. Backslash ends up doing what it would in bash.

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

[Randall S. Becker]

On November 4, 2018 6:26 PM, Junio C Hamano, wrote:
> Johannes Sixt  writes:
> 
> > Am 03.11.18 um 09:14 schrieb Carlo Arenas:
> >> On Fri, Nov 2, 2018 at 9:44 AM Johannes Sixt  wrote:
> >>>
> >>> +  timeout = elapsed >= orig_timeout ? 0 : (int)(orig_timeout -
> >>> + elapsed);
> >>
> >> nitpick: cast to DWORD instead of int
> >
> > No; timeout is of type int; after an explicit type cast we don't want
> > to have another implicit conversion.
> >
> > -- Hannes
> 
> OK, thanks.  It seems that the relative silence after this message is a
sign that
> the resulting patch after squashing is what everybody is happey with?

On my platform (HPE NonStop), DWORD is being defined as unsigned int
(32-bit) rather than unsigned long long (64 bit). The definition comes
through the odbc/windows.h include, not the compiler or any core definition.
It's only a nano-quibble (if even that), because GetTickCount64 is not
defined on the platform anyway, so this is probably not a big deal.

Cheers,
Randall

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

[Randall S. Becker]

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.

RE: Git for games working group

[Randall S. Becker]

On September 23, 2018 3:54 PM, John Austin wrote:
> On Sun, Sep 23, 2018 at 10:57 AM Randall S. Becker
>  wrote:
> >  I would even like to help with your effort and have non-unixy platforms I'd
> like to do this on.
> > Having this separate from git LFS is an even better idea IMO, and I would
> suggest implementing this using the same set of build tools that git uses so
> that it is broadly portable, unlike git LFS. Glad to help there too.
> 
> Great to hear -- once the code is in a bit better shape I can open it up on
> github. Cross platform is definitely one of my focuses. I'm currently
> implementing in Rust because it targets the same space as C and has great,
> near trivial, cross-platform support. What sorts of platforms are you
> interested in? Windows is my first target because that's where many game
> developers live.

I have looked at porting Rust to my two mid-to-large platforms which do not 
have a Rust port. I would prefer keeping within what git currently requires 
without adding dependencies, but I'd be happy to take a Rust prototype and 
translate it. My need is actually not for gamers, but in similar processes that 
gamers use. The following dependences are not available on the two platforms I 
have in mind: g++ or clang; 
And cmake (despite efforts by people on the platform to do ports). This puts me 
in a difficult spot with Rust. I understand you might want to use Rust's 
implied threating, so I would be willing to do the pthread work to make it 
happen in C.

> > I would suggest that a higher-level grouping mechanism of resource groups
> might be helpful - as in "In need this directory" rather than "I need this 
> file".
> Better still, I could see "I need all objects in this commit-ish", which would
> allow a revert operation to succeed or fail atomically while adhering to a 
> lock
> requirement.
> > One bit that traditional lock-brokering systems implement involve forcing
> security attribute changes - so an unlocked file is stored as chmod a-w to
> prevent accidental modification of lockables, when changing that to chmod
> ?+w when a lock is acquired. It's not perfect, but does catch a lot of errors.
> 
> Agreed -- I think this is all up to how the query endpoint and client is
> designed. A couple of different types of clients could be implemented,
> depending on the policies you want in place. One could have strict security
> that stored unlocked files with a-w, as mentioned. Another could be a
> weaker client, and simply warn developers when their current branch is in
> conflict.

Regards,
Randall

RE: Git for games working group

[Randall S. Becker]

On September 23, 2018 1:29 PM, John Austin wrote:
> I've been putting together a prototype file-locking implementation for a
> system that plays better with git. What are everyone's thoughts on
> something like the following? I'm tentatively labeling this system git-sync or
> sync-server. There are two pieces:
> 
> 1. A centralized repository called the Global Graph that contains the union 
> git
> commit graph for local developer repos. When Developer A makes a local
> commit on branch 'feature', git-sync will automatically push that new commit
> up to the global server, under a name-spaced
> branch: 'developera_repoabcdef/feature'. This can be done silently as a
> force push, and shouldn't ever interrupt the developer's workflow.
> Simple http queries can be made to the Global Graph, such as "Which
> commits descend from commit abcdefgh?"
> 
> 2. A client-side tool that queries the Global Graph to determine when your
> current changes are in conflict with another developer. It might ask "Are
> there any commits I don't have locally that modify lockable_file.bin?". This
> could either be on pre-commit, or for more security, be part of a read-only
> marking system ala Git LFS. There wouldn't be any "lock" per say, rather, the
> client could refuse to modify a file if it found other commits for that file 
> in the
> global graph.
> 
> The key here is the separation of concerns. The Global Graph is fairly
> dimwitted -- it doesn't know anything about file locking. But it provides a
> layer of information from which we can implement file locking on the client
> side (or perhaps other interesting systems).
> 
> Thoughts?

I'm encouraged of where this is going. I might suggest "sync" is the wrong name 
here, with "mutex" being slightly better - I would even like to help with your 
effort and have non-unixy platforms I'd like to do this on.

Having this separate from git LFS is an even better idea IMO, and I would 
suggest implementing this using the same set of build tools that git uses so 
that it is broadly portable, unlike git LFS. Glad to help there too.

I would suggest that a higher-level grouping mechanism of resource groups might 
be helpful - as in "In need this directory" rather than "I need this file". 
Better still, I could see "I need all objects in this commit-ish", which would 
allow a revert operation to succeed or fail atomically while adhering to a lock 
requirement.

One bit that traditional lock-brokering systems implement involve forcing 
security attribute changes - so an unlocked file is stored as chmod a-w to 
prevent accidental modification of lockables, when changing that to chmod ?+w 
when a lock is acquired. It's not perfect, but does catch a lot of errors.

Cheers,
Randall

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

[Randall S. Becker]

On September 17, 2018 6:02 PM, Jonathan Nieder wrote:
> Randall S. Becker wrote:
> > On September 17, 2018 3:28 PM, Jonathan Nieder wrote:
> >> Randall S. Becker wrote:
> 
> >>> Does anyone know whether it is practical to rework git-lfs under a
> >>> language other than "go"? GCC is not even close to being possible to
> >>> port to my NonStop platform (may have tried, some have died - joke -
> >>> trying). I would like to convert this directly to C or something
> >>> more widely portable. Is there a protocol doc out there I can reference?
> >>
> >> Can you say more about the context?  You might like
> >>
> >>  git clone --filter=blob:limit=512m 
> >>
> >> which tells Git to avoid downloading any blobs larger than 512
> >> megabytes until you know they need them.  See
> >> Documentation/technical/partial-clone.txt
> >> for more details.
> >
> > Sorry, I was not clear. I am not having issues with large files or
> > blob limits.  Members of my community wish to use Git LFS support on
> > their enterprise git servers, so as platform maintainer for git on
> > NonStop, I am trying to accommodate them. The stumbling block is that
> > "Go" language will not port to the platform.
> 
> Thanks.  Then the answer is "no": there has not been a reimplementation of
> Git LFS in another language, and my advice to someone pursuing that would
> be to use the native Git feature described above instead (or to get Go
> working on their platform).
> 
> If I'm reading
> https://github.com/git-lfs/git-lfs/blob/master/CONTRIBUTING.md
> correctly, the preferred way to contact the Git LFS maintainers is using
> Github's issue tracker.
> 
> Thanks and sorry I don't have better news, Jonathan

It is the interoperability with existing Git LFS repositories that my community 
is requesting, not specifically any file size issues. Some want the locking 
function. The API looks fairly straight forward and I suspect a complete 
reimplementation will take less of my time than trying to get GO to actually 
run on the platform. Cross-compilation might be an option, but that's likely a 
tricky proposition that has not worked in the past - the issue there is that 
cross compilation requires Windows and Cygwin, which make configure rather 
confused and so far, not workable. Neither GCC nor GNULIB build completely in 
port attempts. So the answer is "NO". ☹

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

[Randall S. Becker]

On September 17, 2018 6:01 PM, Taylor Blau wrote:
> On Mon, Sep 17, 2018 at 05:55:55PM -0400, Randall S. Becker wrote:
> > On September 17, 2018 3:28 PM, Jonathan Nieder wrote:
> > > Randall S. Becker wrote:
> > >
> > > > Does anyone know whether it is practical to rework git-lfs under a
> > > > language other than "go"? GCC is not even close to being possible
> > > > to port to my NonStop platform (may have tried, some have died -
> > > > joke - trying). I would like to convert this directly to C or
> > > > something more widely portable. Is there a protocol doc out there I
can
> reference?
> > >
> > > Can you say more about the context?  You might like
> > >
> > >  git clone --filter=blob:limit=512m 
> > >
> > > which tells Git to avoid downloading any blobs larger than 512
> > > megabytes until you know they need them.  See
> > > Documentation/technical/partial- clone.txt for more details.
> >
> > Sorry, I was not clear. I am not having issues with large files or
> > blob limits.  Members of my community wish to use Git LFS support on
> > their enterprise git servers, so as platform maintainer for git on
> > NonStop, I am trying to accommodate them. The stumbling block is that
> > "Go" language will not port to the platform.
> 
> We have an open-source specification here [1], and the rest of our API
> documentation is in here [2].
> 
> Does that help?
> 
> [1]: https://github.com/git-lfs/git-lfs/blob/master/docs/spec.md
> [2]: https://github.com/git-lfs/git-lfs/tree/master/docs/api

Very much, thank you!

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

[Randall S. Becker]

On September 17, 2018 3:28 PM, Jonathan Nieder wrote:
> Randall S. Becker wrote:
> 
> > Does anyone know whether it is practical to rework git-lfs under a
> > language other than "go"? GCC is not even close to being possible to
> > port to my NonStop platform (may have tried, some have died - joke -
> > trying). I would like to convert this directly to C or something more
> > widely portable. Is there a protocol doc out there I can reference?
> 
> Can you say more about the context?  You might like
> 
>  git clone --filter=blob:limit=512m 
> 
> which tells Git to avoid downloading any blobs larger than 512 megabytes
> until you know they need them.  See Documentation/technical/partial-
> clone.txt
> for more details.

Sorry, I was not clear. I am not having issues with large files or blob
limits.  Members of my community wish to use Git LFS support on their
enterprise git servers, so as platform maintainer for git on NonStop, I am
trying to accommodate them. The stumbling block is that "Go" language will
not port to the platform.

Cheers,
Randall

[Question] Alternative to git-lfs under go

[Randall S. Becker]

Hi All,

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

Thanks,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: Git for games working group

[Randall S. Becker]

On September 17, 2018 11:58 AM, Taylor Blau wrote:
> On Mon, Sep 17, 2018 at 05:00:10PM +0200, Ævar Arnfjörð Bjarmason
> wrote:
> > >   2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z
> > >  together." This isn't possible in Git LFS today with the existing
"git
> > >  lfs lock" command (I had to check, but it takes only _one_
filename as
> > >  its argument).
> > >
> > >  Perhaps it would be nice to support something like this someday
in
> > >  Git LFS, but I think we would have to reimagine how this would
look
> > >  in your file.lock scheme.
> >
> > If you can do it for 1 file you can do it for N with a for-loop, no?
> > So is this just a genreal UI issue in git-annex where some commands
> > don't take lists of filenames (or git pathspecs) to operate on, or a
> > more general issue with locking?
> 
> I think that it's more general.
> 
> I envision a scenario where between iterations of the for-loop, another
> client acquires a lock later on in the list. I think that the general
problem here
> is that there is no transactional way to express "please give me all N of
these
> locks".

A composite mutex is better, constructing a long name of X+Y+Z.lock and
obtaining the lock of that, then attempting all locks X.lock,Y.lock,Z.lock
and if any fail, free up what you did. Otherwise you run into a potential
mutex conflict if someone attempts the locks in a different order. Not
perfect, but it prevents two from going after the same set of resources, if
that set is common. Another pattern is to have a very temporary dir.lock
that is active while locks are being grabbed within a subtree, then released
when all locks are acquired or fail (so very short time). This second
pattern should generally work no matter what combination of locks are
required, although single threads lock acquisition - which is probably a
good thing functionally, but slower operationally.

Cheers,
Randall

RE: Git for games working group

[Randall S. Becker]

On September 17, 2018 9:55 AM Taylor Blau wrote:
> On Sun, Sep 16, 2018 at 04:55:13PM +0200, Ævar Arnfjörð Bjarmason wrote:
> > In the hypothetical git-annex-like case (simplifying a bit for the
> > purposes this explanation), for every FILE in your tree you have a
> > corresponding FILE.lock file, but it's not a boolean, but a log of
> > who's asked for locks, i.e. lines of:
> >
> > 
> >
> > E.g.:
> >
> > $ cat Makefile.lock
> > my-random-per-repo-id 2018-09-15 1 ava...@gmail.com "refactoring
> all Makefiles"
> > my-random-per-repo-id 2018-09-16 0 ava...@gmail.com "done!"
> >
> > This log is append-only, when clients encounter conflicts there's a
> > merge driver to ensure that all updates are kept.
> 
> Certainly. I think that there are two things that aren't well expressed
under
> this mechanism:
> 
>   1. Having a log of locks held against that (a) file doesn't prevent us
>  from introducing merge conflicts at the .lock level, so we're
>  reliant upon the caller first running 'git pull' and hoping that no
>  one beats them out to locking and pushing their lock.
> 
>   2. Multi-file locks, e.g., "I need to lock file(s) X, Y, and Z
>  together." This isn't possible in Git LFS today with the existing
"git
>  lfs lock" command (I had to check, but it takes only _one_ filename
as
>  its argument).
> 
>  Perhaps it would be nice to support something like this someday in
>  Git LFS, but I think we would have to reimagine how this would look
>  in your file.lock scheme.

I have an interest in this particular scheme, so am looking at porting both
golang and git-lfs over to my platform (HPE-NonStop). The multi-file lock
problem can be addressed through a variety of cooperative scheme, and if I
get the port, I'm hoping to contribute something to solve it (that's a big
IF at this point in time) - there are known mutex patterns to solve this
AFAIR. My own community has a similar requirement, so I'm investigating.

Cheers,
Randall

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

[Randall S. Becker]

On September 13, 2018 1:52 PM, Junio C Hamano wrote:
> Junio C Hamano  writes:
> 
> > "Randall S. Becker"  writes:
> >
> >> The scenario is slightly different.
> >> 1. Person A gives me a new binary file-1 with fingerprint A1. This
> >> goes into git unchanged.
> >> 2. Person B gives me binary file-2 with fingerprint B2. This does not
> >> go into git yet.
> >> 3. We attempt a git diff between the committed file-1 and uncommitted
> >> file-2 using a textconv implementation that strips what we don't need
to
> compare.
> >> 4. If file-1 and file-2 have no difference when textconv is used,
> >> file-2 is not added and not committed. It is discarded with impunity,
> >> never to be seen again, although we might whine a lot at the user for
> >> attempting to put
> >> file-2 in - but that's not git's issue.
> >
> > You are forgetting that Git is a distributed version control system,
> > aren't you?  Person A and B can introduce their "moral equivalent but
> > bytewise different" copies to their repository under the same object
> > name, and you can pull from them--what happens?
> >
> > It is fundamental that one object name given to Git identifies one
> > specific byte sequence contained in an object uniquely.  Once you
> > broke that, you no longer have Git.
> 
> Having said all that, if you want to keep the original with frills but
somehow
> give these bytewise different things that reduce to the same essence (e.g.
> when passed thru a filter like textconv), I suspect a better approach
might be
> to store both the "original" and the result of passing the "original"
through
> the filter in the object database.  In the above example, you'll get two
> "original"
> objects from person A and person B, plus one "canonical" object that are
> bytewise different from either of these two originals, but what they
reduce
> to when you use the filter on them.  Then you record the fact that to
derive
> the "essence" object, you can reduce either person A's or person B's
> "original" through the filter, perhaps by using "git notes" attached to
the
> "essence" object, recording the object names of these originals (the
reason
> why using notes in this direction is because you can mechanically
determine
> which "essence"
> object any given "original" object reduces to---it is just the matter of
passing
> it through the filter.  But there can be more than one "original" that
reduces
> to the same "essence").

I like that idea. It turns the reduced object into a contract. Thanks.

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

[Randall S. Becker]

On September 13, 2018 11:03 AM, Junio C Hamano wrote:
> "Randall S. Becker"  writes:
> 
> > The scenario is slightly different.
> > 1. Person A gives me a new binary file-1 with fingerprint A1. This
> > goes into git unchanged.
> > 2. Person B gives me binary file-2 with fingerprint B2. This does not
> > go into git yet.
> > 3. We attempt a git diff between the committed file-1 and uncommitted
> > file-2 using a textconv implementation that strips what we don't need to
> compare.
> > 4. If file-1 and file-2 have no difference when textconv is used,
> > file-2 is not added and not committed. It is discarded with impunity,
> > never to be seen again, although we might whine a lot at the user for
> > attempting to put
> > file-2 in - but that's not git's issue.
> 
> You are forgetting that Git is a distributed version control system,
aren't you?
> Person A and B can introduce their "moral equivalent but bytewise
different"
> copies to their repository under the same object name, and you can pull
from
> them--what happens?
> 
> It is fundamental that one object name given to Git identifies one
specific
> byte sequence contained in an object uniquely.  Once you broke that, you
no
> longer have Git.

At that point I have a morally questionable situation, agreed. However, both
are permitted to exist in the underlying tree without conflict in git -
which I do consider a legitimately possible situation that will not break
the application at all - although there is a semantic conflict in the
application (not in git) that requires human decision to resolve. The fact
that both objects can exist in git with different fingerprints is a good
thing because it provides immutable evidence and ownership of someone
bypassing the intent of the application.

So, rather than using textconv, I shall implement this rule in the
application rather than trying to configure git to do it. If two conflicting
objects enter the commit history, the application will have the
responsibility to resolve the semantic/legal conflict.

Thanks,
Randall

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

[Randall S. Becker]

On September 12, 2018 7:00 PM, Junio C Hamano wrote:
> "Randall S. Becker"  writes:
> 
> >> author is important to our process. My objective is to keep the
> >> original file 100% exact as supplied and then ignore any changes to
> >> the metadata that I don't care about (like Creator) if the remainder of
the
> file is the same.
> 
> That will *not* work.  If person A gave you a version of original, which
> hashes to X after you strip the cruft you do not care about, you would
> register that original with person A's fingerprint on under the name of X.
> What happens when person B gives you another version, which is not byte-
> for-byte identical to the one you got earlier from person A, but does hash
to
> the same X after you strip the cruft?  If you are going to store it in
Git, and if
> by SHA-1 you are calling what we perceive as "object name" in Git land,
you
> must store that one with person B's fingerprint on it also under the name
of
> X.  Now which version will you get from Git when you ask it to give you
the
> object that hashes to X?

The scenario is slightly different.
1. Person A gives me a new binary file-1 with fingerprint A1. This goes into
git unchanged.
2. Person B gives me binary file-2 with fingerprint B2. This does not go
into git yet.
3. We attempt a git diff between the committed file-1 and uncommitted file-2
using a textconv implementation that strips what we don't need to compare.
4. If file-1 and file-2 have no difference when textconv is used, file-2 is
not added and not committed. It is discarded with impunity, never to be seen
again, although we might whine a lot at the user for attempting to put
file-2 in - but that's not git's issue.
5. If file-1 and file-2 have differences when textconv is used, file-2 is
committed with fingerprint B2.
6. Even if an error is made by the user and they commit file-2 with B2
regardless of textconv, there will be a human who complains about it, but
git has two unambiguous fingerprints that happen to have no diffs after
textconv is applied.

My original hope was that textconv could be used to influence the
fingerprint, but I do not think that is the case, so I went with an
alternative. In the application, I am not allowed to strip any cruft off
file-1 when it is stored - it must be byte-for-byte the original file. This
application is marginally related to a DRM-like situation where we only care
about the original image provided by a user, but any copies that are
provided by another user with modified metadata will be disallowed from
repository.

Does that make more sense? 

Cheers,
Randall

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

[Randall S. Becker]

On September 12, 2018 4:54 PM, I wrote:
> On September 12, 2018 4:48 PM, Johannes Sixt wrote:
> > Am 12.09.18 um 21:16 schrieb Randall S. Becker:
> > > I feel really bad asking this, and I should know the answer, and yet.
> > >
> > > I have a binary file that needs to go into a repo intact (unchanged).
> > > I also have a program that interprets the contents, like a textconv,
> > > that can output the relevant portions of the file in whatever format
> > > I like - used for diff typically, dumps in 1K chunks by file section.
> > > What I'm looking for is to have the SHA1 signature calculated with
> > > just the relevant portions of the file so that two actually
> > > different files will be considered the same by git during a commit
> > > or status. In real terms, I'm trying to ignore the Creator metadata
> > > of a JPG because it is mutable and irrelevant to my repo contents.
> > >
> > > I'm sorry to ask, but I thought this was in .gitattributes but I
> > > can't confirm the SHA1 behaviour.
> >
> > You are looking for a clean filter. See the 'filter' attribute in 
> > gitattributes(5).
> > Your clean filter program or script should strip the unwanted metadata
> > or set it to a constant known-good value.
> >
> > (You shouldn't need a smudge filter.)
> >
> > -- Hannes
> 
> Thanks Hannes. I thought about the clean filter, but I don't actually want to
> modify the file when going into git, just for SHA calculation. I need to be 
> able
> to keep some origin metadata that might change with subsequent copies, so
> just cleaning the origin is not going to work - actually knowing the original
> author is important to our process. My objective is to keep the original file
> 100% exact as supplied and then ignore any changes to the metadata that I
> don't care about (like Creator) if the remainder of the file is the same.

I had a thought that might be workable, opinions are welcome on this.

The commit of my rather weird project is done by a script so I have flexibility 
in my approach. What I could do is set up a diff textconv configuration so that 
the text diff of the two JPG files will show no differences if the immutable 
fields and the image are the same. I can then trigger a git add and git commit 
for only those files where git diff reports no differences. That way the actual 
original file is stored in git with 100% fidelity (no cleaning). It's not as 
elegant as I'd like, but it does solve what I'm trying to do. Does this sound 
reasonable and/or is there a better way?

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

> -Original Message-
> From: git-ow...@vger.kernel.org  On Behalf
> Of Johannes Sixt
> Sent: September 12, 2018 4:48 PM
> To: Randall S. Becker 
> Cc: git@vger.kernel.org
> Subject: Re: [Question] Signature calculation ignoring parts of binary files
> 
> Am 12.09.18 um 21:16 schrieb Randall S. Becker:
> > I feel really bad asking this, and I should know the answer, and yet.
> >
> > I have a binary file that needs to go into a repo intact (unchanged).
> > I also have a program that interprets the contents, like a textconv,
> > that can output the relevant portions of the file in whatever format I
> > like - used for diff typically, dumps in 1K chunks by file section.
> > What I'm looking for is to have the SHA1 signature calculated with
> > just the relevant portions of the file so that two actually different
> > files will be considered the same by git during a commit or status. In
> > real terms, I'm trying to ignore the Creator metadata of a JPG because
> > it is mutable and irrelevant to my repo contents.
> >
> > I'm sorry to ask, but I thought this was in .gitattributes but I can't
> > confirm the SHA1 behaviour.
> 
> You are looking for a clean filter. See the 'filter' attribute in 
> gitattributes(5).
> Your clean filter program or script should strip the unwanted metadata or set
> it to a constant known-good value.
> 
> (You shouldn't need a smudge filter.)
> 
> -- Hannes

Thanks Hannes. I thought about the clean filter, but I don't actually want to 
modify the file when going into git, just for SHA calculation. I need to be 
able to keep some origin metadata that might change with subsequent copies, so 
just cleaning the origin is not going to work - actually knowing the original 
author is important to our process. My objective is to keep the original file 
100% exact as supplied and then ignore any changes to the metadata that I don't 
care about (like Creator) if the remainder of the file is the same.

Regards,
Randall

[Question] Signature calculation ignoring parts of binary files

[Randall S. Becker]

I feel really bad asking this, and I should know the answer, and yet.

I have a binary file that needs to go into a repo intact (unchanged). I also
have a program that interprets the contents, like a textconv, that can
output the relevant portions of the file in whatever format I like - used
for diff typically, dumps in 1K chunks by file section. What I'm looking for
is to have the SHA1 signature calculated with just the relevant portions of
the file so that two actually different files will be considered the same by
git during a commit or status. In real terms, I'm trying to ignore the
Creator metadata of a JPG because it is mutable and irrelevant to my repo
contents.

I'm sorry to ask, but I thought this was in .gitattributes but I can't
confirm the SHA1 behaviour.

Sheepishly,
Randall


-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: Multiple GIT Accounts & HTTPS Client Certificates - Config

[Randall S. Becker]

On September 10, 2018 4:09 AM, Sergei Haller wrote:
> my problem is basically the following: my git server (https) requires
> authentication using a clent x509 certificate.
> 
> And I have multiple x509 certificates that match the server.
> 
> when I access the https server using a browser, the browser asks which
> certificate to use and everything is fine.
> 
> When I try to access the git server from the command line (git pull or 
> similar),
> the git will pick one of the available certificates (randomly or 
> alphabetically)
> and try to access the server with that client certificate. Ending in the
> situation that git picks the wrong certificate.
> 
> I can workaround by deleting all client certificates from the windows
> certificate store except the "correct" one => then git command line will pick
> the correct certificate (the only one available) and everything works as
> expected.
> 
> Workaround is a workaround, I need to use all of the certificates repeatedly
> for different repos and different other aplications (non-git), so I've been
> deliting and reinstalling the certificates all the time in the last weeks...
> 
> How can I tell git cmd (per config option??) to use a particular client
> certificate for authenticating to the https server (I could provide 
> fingerprint
> or serial number or sth like that)
> 
> current environment: windows 10 and git version 2.18.0.windows.1
> 
> Would be absolutely acceptable if git would ask interactively which client
> certificate to use (in case its not configurable)
> 
> (I asked this question here before:
> https://stackoverflow.com/questions/51952568/multiple-git-accounts-
> https-client-certificates-config
> )

Would you consider using SSH to authenticate? You can control which private key 
you use based on your ~/.ssh/config entries, which are case sensitive. You can 
choose the SSH key to use by playing with the case of the host name, like:

github.com
Github.com
gitHub.com

even if your user is "git" in all cases above. It is a bit hacky but it is part 
of the SSH spec and is supported by git and EGit (as of 5.x).

Cheers,
Randall

--
Randall S. Becker
Managing Director, Nexbridge Inc.
LinkedIn.com/in/randallbecker
+1.416.984.9826

RE: Automatic core.autocrlf?

[Randall S. Becker]

On August 30, 2018 11:29 PM, Jonathan Nieder wrote:
> Torsten Bögershausen wrote:
> 
> > My original plan was to try to "make obsolete"/retire and phase out
> > core.autocrlf completely.
> > However, since e.g. egit/jgit uses it
> > (they don't have support for .gitattributes at all) I am not sure if
> > this is a good idea either.
> 
> Interesting.  [1] appears to have intended to add this feature.
> Do you remember when it is that you tested?
> 
> Feel free to file bugs using [2] for any missing features.
> 
> [1] https://git.eclipse.org/r/c/60635
> [2] https://www.eclipse.org/jgit/support/

My testing was done on EGit 5.0.1 yesterday, which does not provide a default 
to core.autocrlf.

Cheers,
Randall

RE: Automatic core.autocrlf?

[Randall S. Becker]

On August 30, 2018 2:57 PM, Torsten Bögershausen wrote:
> On Thu, Aug 30, 2018 at 09:57:52AM -0500, Robert Dailey wrote:
> > On Wed, Aug 29, 2018 at 11:54 PM Jonathan Nieder 
> wrote:
> > >
> > > Hi,
> > >
> > > Robert Dailey wrote:
> > >
> > > > Is there an 'auto' setting for the 'core.autocrlf' config? Reason
> > > > I ask is, I want that setting to be 'input' on linux but 'true' on
> > > > Windows.
> > >
> > > Others are exploring your question about the configuration language,
> > > but I want to emphasize some other ramifications.
> > >
> > > Why do we still have 'core.autocrlf'?  Do 'core.eol' and related
> > > settings take care of that need, or is autocrlf still needed?  If
> > > core.eol etc do not take care of this need, what should we do to get
> > > them to?
> > >
> > > Thanks, after having run into a few too many autocrlf-related
> > > messes, Jonathan
> >
> > From my perspective, the confusion is due to the evolution of the
> > feature. There's multiple ways to control EOL handling but most of it
> > is legacy/backward compatibility, I think. core.autocrlf is a
> > fall-back for repos that do not have a .gitattributes. Because
> > .gitattributes is optional by design, I'm not sure if getting rid of
> > the config options is a good idea.
> 
> Good summary. My original plan was to try to "make obsolete"/retire and
> phase out core.autocrlf completely.
> However, since e.g. egit/jgit uses it
> (they don't have support for .gitattributes at all) I am not sure if this
is a good
> idea either. Opinions are welcome.
> 
> 
> > But your point did make me think
> > about how `core.autocrlf = true` should probably be a system config
> > default for the Git for Windows project. The default for that value
> > should be platform-defined. That would make it automatically work the
> > way I want, and might solve a lot of the issues where people are
> > committing CRLF into repositories on Windows.
> 
> Unless I am wrong, that had been the default a long time ago:
> Git for Windows (at that time msysgit) had core.autocrlf=true by default.
> While this is a good choice for many repos, some people prefer
> core.autocrlf=input.
> Others just commit files for Windows-based repos with CRLF, and the
> advantage is, that "git diff" doesn't show "^M" somewhere.
> 
> I allways encourage people to set up a .gitattributes file.
> Does anybody thinks that we can make core.autocrlf obsolete ?

The last time I checked, EGit does not set this by default. ECLIPSE Oxygen
3A/EGit-JGit 5.0.1, when running on Windows, creates core.filemode=false,
core.logallrefupdates=true, repositoryformatversion=0, symlinks=false. Some
SourceTree versions that predate the newer SourceTreeApp are somewhat stuck
on older embedded versions of git, but that may not be relevant. Personally,
I would seriously like to drop core.autocrlf and just have everyone on LF
EOL characters. I get frequently burnt by this despite knowing better.

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: [GitHub] Your password was reset

[Randall S. Becker]

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


My first reactions were:

1. Someone is trying a phishing scam on the distribution list. It has happened 
before.

2. Someone set up the wrong email address for their GitHub account.

I hope it's not #1.

Cheers,
Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(2112884442)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: Contributor Summit planning

[Randall S. Becker]

On August 14, 2018 2:53 AM, Elijah Newren wrote:
> On Mon, Aug 13, 2018 at 10:27 AM Jeff King  wrote:
> >
> > For the past several years, we've held a Git Contributor Summit as
> > part of the Git Merge conference. I'd like to get opinions from the
> > community to help plan future installments. Any feedback or opinion is
> > welcome, but some obvious things to think about:
> >
> >   - where, when, and how often?
> >
> > Plans are shaping up to have Git Merge 2019 in Brussels right after
> > FOSDEM in February (like it was two years ago), with a contributor
> > summit attached.
> >
> > Are there people who would be more likely to attend a contributor
> > summit if it were held elsewhere (e.g., in North America, probably
> > in the Bay Area)? Are people interested in attending a separate
> > contributor summit not attached to the larger Git Merge (and if so,
> > is there any other event it might be worth connecting it with,
> > time-wise)?  Are people interested in going to two summits in a year
> > (e.g., Brussels in February, and then maybe some in North America
> > later in the year), or is that diminishing returns?
> 
> Convincing my employer to send me to an event in North America is a lot
> easier than one in Europe; they mostly allow me to work on git stuff as a side
> project just to make me happy rather than as a business priority, so
> competing business interests, shifting managers, etc. make things hard for
> me to predict (so you may want to weight my preferences less than normal).
> 
> My last manger did say they'd send me to the next contributor summit (I
> think even if it ended up being in Europe rather than North America), but of
> course, he was pulled to a different team a few months ago, so I'm not sure
> if that still stands.
> 
> 
> On a personal note, I'm also somewhat travel averse.  It'd be nice to go to a
> Git conference again (last and only I went to was I think Git Together 2011),
> but I know when it comes close to time to actually travel, I'll start
> questioning my sanity when I said that -- particularly if it's far away or at 
> all
> complicated.  (So maybe you really ought to discount my preferences...)

Unrelated directly to above, I noticed that I actually showed up on the list 
for 2018 based on git log anyway. Does this mean I'd be welcome? Personally, 
it's actually easier to get approval to travel to Brussels now than SFO even 
though the latter is closer. With that in mind, I can do either (or both - 
depending on scheduling).

Cheers,
Randall

RE: [PATCH] Makefile: enable DEVELOPER by default

[Randall S. Becker]

On August 6, 2018 1:42 PM, Ævar Arnfjörð Bjarmason wrote:
> On Mon, Aug 06 2018, Randall S. Becker wrote:
> 
> > On August 6, 2018 12:40 PM, Ævar Arnfjörð Bjarmason wrote:
> >> On Sat, Aug 04 2018, Junio C Hamano wrote:
> >>
> >> > Duy Nguyen  writes:
> >> >
> >> >> On Sat, Aug 4, 2018 at 8:11 AM Jonathan Nieder
> >> >> 
> >> wrote:
> >> >>> My main concern is not about them but about other people building
> >> >>> from source in order to run (instead of to develop) Git, and by
> >> >>> extension, the people they go to for help when it doesn't work.
> >> >>> I have lots of bitter experience of -Werror being a support
> >> >>> headache and leading to bad workarounds when someone upgrades
> >> >>> their compiler and the build starts failing due to a new warning it has
> introduced.
> >> >>
> >> >> Even old compilers can also throw some silly, false positive
> >> >> warnings (which now turn into errors) because they are not as
> >> >> smart as new ones.
> >> >
> >> > I agree with both of the above.  I do not think the pros-and-cons
> >> > are in favor of forcing the developer bit to everybody, even though
> >> > I am sympathetic to the desire to see people throw fewer bad
> >> > changes that waste review bandwidth by not compiling or passing its
> >> > own tests at us.
> >>
> >> I agree.
> >>
> >> Responding to the thread in general, perhaps people would like this
> >> more if we turned DEVELOPER=1 DEVOPTS=no-error on by default?
> >>
> >> That's basically why I added it in 99f763baf5 ("Makefile: add a
> >> DEVOPTS to suppress -Werror under DEVELOPER", 2018-04-14), because I
> >> wanted the abilty to have verbose informative output without the
> >> build dying on some older systems / compilers.
> >>
> >> It's fine and understandable if you're someone who's just building a
> >> package on some older system if you get a bunch of compiler warnings,
> >> but more annoying if you have to dig into how to disable a default -
> Werror.
> >
> > I am the platform maintainer for HPE NonStop and need to make sure I'm
> > not packaging DEV builds to anyone
> 
> Perhaps confusingly, the DEVELOPER=1 flag in git is not like the developer
> flag in some other projects. It's purely there to turn on extra compiler
> warnings (by default, fatal), it doesn't e.g. turn on extra asserts, tracing, 
> or
> suppress stripping of the binaries.
> 
> So if we enabled some variant of it by default it would be fine to ship the
> result of that to your users, e.g. I ship DEVELOPER=1 builds to users.

That works for me. I generally consider warnings to be errors in my builds 
anyway, by policy (except when I have no choice in the matter and the warning 
is explainable).

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: [PATCH] Makefile: enable DEVELOPER by default

[Randall S. Becker]

On August 6, 2018 1:02 PM, Peff wrote:
> To: Ævar Arnfjörð Bjarmason 
> Cc: Junio C Hamano ; Duy Nguyen
> ; Jonathan Nieder ; Stefan
> Beller ; Git Mailing List ; git-
> packag...@googlegroups.com; Han-Wen Nienhuys 
> Subject: Re: [PATCH] Makefile: enable DEVELOPER by default
> 
> On Mon, Aug 06, 2018 at 06:40:14PM +0200, Ævar Arnfjörð Bjarmason
> wrote:
> 
> > Responding to the thread in general, perhaps people would like this
> > more if we turned DEVELOPER=1 DEVOPTS=no-error on by default?
> >
> > That's basically why I added it in 99f763baf5 ("Makefile: add a
> > DEVOPTS to suppress -Werror under DEVELOPER", 2018-04-14), because I
> > wanted the abilty to have verbose informative output without the build
> > dying on some older systems / compilers.
> >
> > It's fine and understandable if you're someone who's just building a
> > package on some older system if you get a bunch of compiler warnings,
> > but more annoying if you have to dig into how to disable a default
> > -Werror.
> 
> I had the impression that DEVELOPER=1 was allowed to set flags that old
> versions might not even know about. Hence they might actually barf, even
> without -Werror. Maybe that's better since the introduction of the detect-
> compiler script, though.
> 
> I do think we may have a skewed view of the population on this list.
> We're developers ourselves, and we interact with new developers that we
> want to help.  But there are masses of people[1] building Git who are _not_
> developers, and want the default to be as robust as possible.
> They're probably not going to show up in this thread.
> 
> -Peff
> 
> [1] I actually wonder how large that mass is. Clearly there are many
> orders of magnitude more users than there are developers. But I have
> no idea what percentage of them build from source versus using
> somebody else's binary package.

One? 

Jokingly,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: [PATCH] Makefile: enable DEVELOPER by default

[Randall S. Becker]

On August 6, 2018 12:40 PM, Ævar Arnfjörð Bjarmason wrote:
> On Sat, Aug 04 2018, Junio C Hamano wrote:
> 
> > Duy Nguyen  writes:
> >
> >> On Sat, Aug 4, 2018 at 8:11 AM Jonathan Nieder 
> wrote:
> >>> My main concern is not about them but about other people building
> >>> from source in order to run (instead of to develop) Git, and by
> >>> extension, the people they go to for help when it doesn't work.  I
> >>> have lots of bitter experience of -Werror being a support headache
> >>> and leading to bad workarounds when someone upgrades their compiler
> >>> and the build starts failing due to a new warning it has introduced.
> >>
> >> Even old compilers can also throw some silly, false positive warnings
> >> (which now turn into errors) because they are not as smart as new
> >> ones.
> >
> > I agree with both of the above.  I do not think the pros-and-cons are
> > in favor of forcing the developer bit to everybody, even though I am
> > sympathetic to the desire to see people throw fewer bad changes that
> > waste review bandwidth by not compiling or passing its own tests at
> > us.
> 
> I agree.
> 
> Responding to the thread in general, perhaps people would like this more if
> we turned DEVELOPER=1 DEVOPTS=no-error on by default?
> 
> That's basically why I added it in 99f763baf5 ("Makefile: add a DEVOPTS to
> suppress -Werror under DEVELOPER", 2018-04-14), because I wanted the
> abilty to have verbose informative output without the build dying on some
> older systems / compilers.
> 
> It's fine and understandable if you're someone who's just building a package
> on some older system if you get a bunch of compiler warnings, but more
> annoying if you have to dig into how to disable a default -Werror.

Any idea when this is going to be in an official release, and exactly what the 
settings will be for "Not Developer". I assume DEVELOPER=0 and DEVOPTS=error, 
which is the current behaviour, correct? I am the platform maintainer for HPE 
NonStop and need to make sure I'm not packaging DEV builds to anyone, since I'm 
the only one doing this for the platform. It's another hoop, but hopefully not 
a bad one. The question is the best place to set this, assuming we are using 
Jenkins for our builds, and I'd rather keep the existing config.mak.uname the 
same, since at least it seems stable. We currently just run "make" for our 
build. So make arguments? And is making the change now non-destructive in 
preparation so that I don't forget when the time comes?

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

On August 3, 2018 5:39 PM, Tacitus Aedifex wrote:
> I'm looking at the existing commit signing and verification integration and 
> it is
> all GPG specific. I'm interested in refactoring the code to have a generic
> signing/verifying interface so that "drivers"
> for other signing tools can be created and other signing tools can be used
> (e.g. OpenBSD signify).
> 
> The existing interface defined in gpg-interface.h is already fairly generic. 
> It
> looks like the only things that would need to be fixed are the names of some
> members in the signature_check struct and the GPG specific constants.
> 
> I propose to rename the gpg-interface.h file to signature-interface.h.
> There are several different ways to do the "polymorphism" needed to have a
> base signature_check struct with a tool-specific part for storing the tool-
> specific data (e.g. gpg_output, gpg_status, result). I'm looking for
> suggestions on the way this has been done in other places in the Git code so I
> can do it the same way. My initial impulse it to have a union of tool-specific
> structs inside of the signature_check struct.
> 
> The plan for changing the signing behavior is to change the code looking for
> commit.gpgsign in sequencer.c to instead look for commit.signtool.
> The string value will define which signing tool to use. The default will be 
> null
> which is the equivilent to gpgsign=false. To get GPG signing the user would
> set it to "gpg". To maintain backwards compatibility, the code will continue 
> to
> check for commit.gpgsign and translate that to commit.signtool=gpg and
> output a warning.
> 
> I also think that it makes sense to move the user.signingkey to be
> gpg.signingkey since that only makes sense in the context of GPG.
> 
> The real trick here is how to handle signatures from different tools in a 
> given
> project. I think the answer is to store the value of commit.signtool along 
> with
> the signature blob associted with each signed commit. That way the
> signature verification code can know which tool to use to verify the
> signature. If a commit has a signture but no tool selector, the default will 
> be
> to assume GPG to preserve backwards compatibility.

If I may suggest something a little off the wall... the abstraction needs to go 
beyond just the signing tool, but the whole signing infrastructure. I would 
like to see something along the lines of introducing a signing authority into 
the mix, so that not only the tool of signing is abstracted, but also the 
interface to who, if anyone, is responsible for signing. If I had my dream, it 
would be that one (or more) signing authorities would have potentially 
overlapping responsibilities for signing parts of the tree either on demand or 
by requirement.

So when a commit occurs, at least on master, or other designated branches, it 
may be the repository requires a signature from a particular authority, 
regardless of whether the committer has requested one. And there may be more 
than one authority or notary involved. Or, the repository could accept the 
signature of the committer as abstracted.

Where I'm going is that I would like to see a tighter integration with 
block-chain concepts in git. My customer base has very tight requirements for 
this type of software certification. Signatures, GPG or other, may only go so 
far. I am even considering whether particular parts of the tree are even 
visible (remember the Islands of Sparceness discussion?).

I expect to be able to contribute more to this conversation in a few months 
(current $NDA prohibition), if this goes anywhere.

My feature time machine window doesn't see this any time soon, if ever, but one 
never knows. I have my delusional hopes. 

Please take this as simply a suggestion for the long-term.

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: Using Git for applications other than code development

[Randall S. Becker]

Hi David,

I have used git over the past 3 years in a manufacturing environment to
manage component designs in a CAD/factory automation setting. There are a
few main factors that you need to consider:

1. You will need an external tool like Git for Windows, GitHub Client or
SourceTree for performing git operations on your workstations because your
design software is unlikely to support any VCS directly.
2. Your design software probably needs to store its designs in some text
form. This will allow a lot of the advanced git functions, like annotate, to
work nicely. This is not a requirement as git is happy to manage binaries
(your renderings, for example).
3. You might need to figure out a way to interpret changes when there are
conflicts between designers. This either means learning the underlying
format (auto-lisp??) or making choices of whose design is going to take
priority without trying to merge changes or otherwise resolve conflicts.
4. Lastly (but really there are more you will encounter), you will need to
decide on either a local shared repository (GitHub Enterprise, BitBucket
Server, GitLab, etc.) or a similar cloud solution (same names). There are
costs for each, usually depending on your team size. The costs are pretty
small for small teams and more than worth it, IMHO.
5. I have been repeatedly surprised at how many hardware component designers
actually have git experience (followed lastly deliberately).

Git is generally a good fit for advanced manufacturing. I'm including a
discussion of git in a seminar I am giving at IWF Atlanta next month.

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.


From: git-ow...@vger.kernel.org  On Behalf Of
David Hind
Sent: July 25, 2018 9:02 AM
To: 'git@vger.kernel.org' 
Subject: Using Git for applications other than code development

Hi, 

I work for a company that is looking to adopt VCS and I like sound of Git
(although I have no experience of using VCS). My question is, everything
seems to be directed towards code developers. Can I use Git to do revision
control for other types of design document? For example electrical circuit
designs, circuit PCB designs etc.?

Thanks!
David 



Dynex Semiconductor Limited.
Registered in England and Wales: No 3824626
Registered Office: Doddington Road, Lincoln, LN6 3LF, United Kingdom

This e-mail and any attachments are confidential and may be privileged. If
you are not the intended recipient please notify the sender immediately,
delete the email from your system and do not disclose the contents to
another person, use it for any purpose or store or copy the information in
any medium.
Whilst we run anti-virus software on all internet emails we do not accept
responsibility for viruses and advise that in keeping with good computing
practice you should ensure this email and any attachments are virus free.

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

[Randall S. Becker]

On July 19, 2018 6:46 PM, Junio wrote:
> Jeff King  writes:
> 
> > For enforcement, we can rely on the compiler and just introduce code
> > which breaks compilation when it sees these functions. This has a few
> > advantages:
> >
> >   1. We know it's run as part of a build cycle, so it's
> >  hard to ignore. Whereas an external linter is an extra
> >  step the developer needs to remember to do.
> >
> >   2. Likewise, it's basically free since the compiler is
> >  parsing the code anyway.
> >
> >   3. We know it's robust against false positives (unlike a
> >  grep-based linter).
> >
> > The one big disadvantage is that it will only check code that is
> > actually compiled, so it may miss code that isn't triggered on your
> > particular system. But since presumably people don't add new code
> > without compiling it (and if they do, the banned function list is the
> > least of their worries), we really only care about failing to clean up
> > old code when adding new functions to the list. And that's easy enough
> > to address with a manual audit when adding a new function (which is
> > what I did for the functions here).
> >
> > That leaves only the question of how to trigger the compilation error.
> > The goals are:
> 
> I actually have another question, though.
> 
> Is it a downside that it is cumbersome to override?  This is not a
rhetorical
> question.  I am not convinced there will not be a legit circumstance that
> calling strcpy (or whatever we are going to ban) is the best solution and
it is
> safe.  By "best", what I mean is "you could instead use
> memcpy/strncpy/whatever" can legitimately be argued with "but still using
> memcpy/strncpy/whatever is inferior than using strcpy in this case for
such
> and such reasons".

Putting on my old-guy compiler hat, this sounds like a more complex activity
that something akin to lint might be useful at handling. Having a
post-processor that searches for offending functions but also supports
annotations explaining exceptions (why you really had to use strncpy because
the NULL was hiding in a bad place and you promise to fix it), might be
useful. Personally, I'd rather know that that code compiles first and then
violates rules that I can fix following basic prototyping than getting
yelled at up front - but that's just me. I can't suggest a good thing to
handle this, short of augmenting lint, and if we were in java, annotations
would be the way to go, but this seems like a problem that other products
have solved.

Cheers,
Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(2112884442)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: OAuth2 support in git?

[Randall S. Becker]

On June 14, 2018 11:15 AM, Jeff King wrote:
> On Thu, Jun 14, 2018 at 10:13:42AM +, brian m. carlson wrote:
> 
> > > I know that other git server environments like github support that
> > > on client side by allowing tokens to be used as usernames in a BASIC
> > > authentication flow. We could do the same but I am asking whether
> > > there is also a way to transport tokens in a standard conform
> > > "Authorization: Bearer ..." Header field.
> >
> > There isn't any support for Bearer authentication in Git.  For HTTP,
> > we use libcurl, which doesn't provide this natively.  While it could
> > in theory be added, it would require some reworking of the auth code.
> >
> > You are, of course, welcome to send a patch.
> 
> If it's just a custom Authorization header, we should be able to support it
> with existing curl versions without _too_ much effort.
> 
> I think there are probably two possible directions:
> 
>  1. add a special "bearer" command line option, etc, as a string
> 
>  2. add a boolean option to send the existing "password" field as a
> "bearer" header
> 
> I suspect (2) would fit in with the existing code better, as the special case
> would mostly be limited to the manner in which we feed the credential to
> curl. And you could probably just set a config option for "this url's auth 
> will
> be oauth2", and use the existing mechanisms for providing the password.
> 
> We'd maybe also want to allow credential helpers to say "by the way, this
> password should be treated as a bearer token", for cases where you might
> sometimes use oauth2 and sometimes a real password.

Be aware that there are 4 (ish) flavours of OAuth2 the last time I checked. It 
is important to know which one (or all) to implement. The embedded form is 
probably the easiest to comprehend - and the least implemented from my 
research. More common OAuth2 instances use a third-man website to hold session 
keys and authorization. That may be problematic for a whole bunch of us who do 
not play in that world.

Cheers,
Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(2112884442)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: git question from a newbie

[Randall S. Becker]

On June 5, 2018 5:24 PM, Steve Heinz wrote:
> I am new to Git and have read quite a few articles on it.
> I am planning on setting up a remote repository on a windows 2012 R2
server
> and will access it via HTTPS.
> I am setting up a local repository on my desk top (others in my group will
do
> the same).
> On "server1":  I install Git and create a repository "repos".
> On "server1":  I create a dummy webpage "default.htm" and place it in the
> repo folder.
> On "server1":  I create a web application in IIS pointing to Git
> On Server1":   change permissions so IIS_User  has access to the folders.
> On "server1":  inside the "repos" folder and right click and choose "bash
> here"
> On "server1":   $ git init  -bare(it's really 2 hyphens)
> 
> On Desktop:  open Chrome and type in URL to make sure we can access it
> https://xyz/repos/default.htm
>   ** make sure you have access, no certificate issues or firewall
issues.  The
> pages shows up fine
> 
> On Desktop:  install Git and create repository "repos".
> On Desktop:  right click in "repos" folder and choose "bash here"
> On Desktop:  $ git init
> On Desktop : add a folder "testProject" under the "repos" folder and add
> some files to the folder
> On Desktop:  $ git add . (will add files and folder to
working tree)
> On Desktop   $ git status   (shows it recognizes the filed
were added)
> On Desktop   $ git commit -m "test project commit"   (will stage
changes)
> On Desktop   $ git push https://xyz.domainname.com/repos master
> 
> ** this is the error I get,  I have tried many different things.  I am
sure I am
> doing something stupid
> ** I have tried a bunch of variations but I always get the same error.  It
looks
> like some type of network/permission
> ** thing but everything seems OK.
>Fatal: repository 'https://xyz.domainname.com/repos/' not found
> 
> *** this is where I get the error trying to push staged items to the
remote
> repository.
> *** I have tried to clone the empty remote repository still same error
> *** I checked port 443 is opened and being used for https
> *** tried to set origin to https://xyz.domainname.com/repos; and then $git
> push origin master   (same error)
> *** I tried passing credentials to the remote server as well

Missing glue - git remote

git remote add origin https://xyz.domainname.com/repos

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

> -Original Message-
> From: git-ow...@vger.kernel.org  On Behalf
> Of Robert P. J. Day
> Sent: June 1, 2018 4:14 PM
> To: Git Mailing list 
> Subject: how exactly can git config section names contain periods?
> 
> 
>   more oddities in my travels, this from Doc.../config.txt:
> 
> "The file consists of sections and variables.  A section begins with the
name
> of the section in square brackets and continues until the next section
begins.
> Section names are case-insensitive.  Only alphanumeric characters, `-` and
`.`
> are allowed in section names.
>   ^ ?
> 
>   what? how can section names contain periods? reading further,
> 
> "Sections can be further divided into subsections.  To begin a subsection
put
> its name in double quotes, separated by space from the section name, in
the
> section header, like in the example below:
> 
> 
> [section "subsection"]
> 
> 
>   ok, so how on earth would i use "git config" at the command line to set
a
> config variable with some arbitrary level of subsections? let's try this:
> 
>   $ git config --global a.b.c.d.e rday
> 
> huh ... seemed to work fine, and added this to my ~/.gitconfig:
> 
>   [a "b.c.d"]
>   e = rday
> 
> as i see it, the first component is intgerpreted as the section name, the
last
> component is the variable/key(?) name, and everything in between is
> treated as subsection(s), which is not at all obvious from that Doc file,
or from
> "man git-config".
> 
>   and if a section name can contain periods, how would you specify that at
the
> command line?

I'm with Robert on this. I would have thought that the interpretation should
have been:

["a.b.c.d"]
 e = rday

Confused as well,

Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: Git Vulnerability Announced?

[Randall S. Becker]

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

Do you have a reference, CVE number, or other information about this 
vulnerability?

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: which files are "known to git"?

[Randall S. Becker]

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

You might want to consider git metadata/config/attribute files, hooks,
filters, etc., that may not be not formally part of a repository, but can be
required to ensure the content is complete.

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

On May 18, 2018 7:31 AM, Anmol Sethi <m...@anmol.io>
> That works but most binaries do not have a file extension. Its just not
> standard on linux.
> 
> > On May 17, 2018, at 8:37 AM, Randall S. Becker <rsbec...@nexbridge.com>
> wrote:
> >
> > On May 16, 2018 11:18 PM, Jacob Keller
> >> On Wed, May 16, 2018 at 5:45 PM, Anmol Sethi <m...@anmol.io> wrote:
> >>> I think it’d be great to have an option to have git ignore binary
> >>> files. My
> >> repositories are always source only, committing a binary is always a
> mistake.
> >> At the moment, I have to configure the .gitignore to ignore every
> >> binary file and that gets tedious. Having git ignore all binary files 
> >> would be
> great.
> >>>
> >>> This could be achieved via an option in .gitconfig or maybe a
> >>> special line in
> >> .gitignore.
> >>>
> >>> I just want to never accidentally commit a binary again.
> >>
> >> I believe you can do a couple things. There should be a hook which
> >> you can modify to validate that there are no binary files on
> >> pre-commit[1], or pre- push[2] to verify that you never push commits
> with binaries in them.
> >>
> >> You could also implement the update hook on the server if you control
> >> it, to allow it to block pushes which contain binary files.
> >
> > What about configuring ${HOME}/.config/git/ignore instead (described at
> https://git-scm.com/docs/gitignore). Inside, put:
> >
> > *.o
> > *.exe
> > *.bin
> > *.dat
> > Etc

I have a similar problem on my platform, with a different solution. My builds 
involve GCC binaries, NonStop L-series binaries (x86), and a NonStop J-series 
binaries (itanium). To keep me sane, I have all build targets going to separate 
directories, like Build/GCC, Build/Lbin, Build/Jbin away from the sources. This 
allows me to ignore Build/ regardless of extension and also to build different 
targets without link collisions. This is similar to how Java works (a.k.a. 
bin/). Much more workable, IMHO, than trying to manage individual binaries name 
by name or even by extension. I also have a mix of jpg and UTF-16 HTML that 
would end up in false-positives on a pure binary match and I do want to manage 
those.

What helps me is that I do most of my work in ECLIPSE, so derived resources 
(objects, generated sources) get auto-ignored by EGit, if you can make your 
compiler arrange that - but that's an ECLIPSE thing not a file system thing.

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

On May 16, 2018 11:18 PM, Jacob Keller
> On Wed, May 16, 2018 at 5:45 PM, Anmol Sethi  wrote:
> > I think it’d be great to have an option to have git ignore binary files. My
> repositories are always source only, committing a binary is always a mistake.
> At the moment, I have to configure the .gitignore to ignore every binary file
> and that gets tedious. Having git ignore all binary files would be great.
> >
> > This could be achieved via an option in .gitconfig or maybe a special line 
> > in
> .gitignore.
> >
> > I just want to never accidentally commit a binary again.
> 
> I believe you can do a couple things. There should be a hook which you can
> modify to validate that there are no binary files on pre-commit[1], or pre-
> push[2] to verify that you never push commits with binaries in them.
> 
> You could also implement the update hook on the server if you control it, to
> allow it to block pushes which contain binary files.

What about configuring ${HOME}/.config/git/ignore instead (described at 
https://git-scm.com/docs/gitignore). Inside, put:

*.o
*.exe
*.bin
*.dat
Etc

Cheers,
Randall

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

[Randall S. Becker]

On May 11, 2018 3:26 PM, I wrote:
> On May 10, 2018 10:27 PM, Junio C Hamano wrote:
> > "Randall S. Becker" <rsbec...@nexbridge.com> writes:
> >
> > > What if we create a ../.gitconfig like ../.gitattributes, that is
> > > loaded before .git/config?
> >
> > You should not forget one of the two reasons why clean/smudge/diff etc.
> > drivers must be given with a step of redirection, split between
> > attributes and config.  "This path holds text from ancient macs" at
> > the logical level may be expressed in .gitattributes, and then "when
> > checking out text from ancient macs, process the blob data with this
> > program to turn it into a form suitable for working tree" is given as
> > a smudge filter program, that is (1) suitable for the platform _you_
> > as the writer of the config file is using *AND* (2) something you are
> confortable running on behalf of you.
> >
> > We *deliberately* lack a mechanism to pay attention to in-tree config
> > that gets propagated to those who get them via "git clone", exactly
> > because otherwise your upstream may not just specify a "smudge"
> > program that your platform would be unable to run, but can specify a
> > "smudge" program that pretends to be a smudger, but is actually a
> > program that installs a keylogger and posts your login password and
> > bank details to this mailing list ;-)
> >
> > So, no, I do not think in-tree configuration will fly.
> 
> I agree, which is why I asked the original question instead of posting it as a
> formal patch. We would probably get a brand new CVE implementing the
> proposed proto-changes even if the original intent was internal trusted
> repositories only. That's why I asked this as a "Best Practices" type 
> question,
> which I think I have a better idea on now. The actual situation is rather cool
> from a DevOps point of view, and whatever the ultimate solution is, might
> make for a nice presentation at some future conference .

Here's where I ended up, from a solution standpoint:

0. Make sure the git scripts you use are always trusted using your favourite 
technique
1. Wrap the clone in a such a script to do the next two steps to avoid the 
usual problems of forgetting things
2. The clone script should use "git -c name=value clone repo" for all 
clean/smudge values needed that would otherwise be in .git/config if we had one 
which we don't
3. Have the script create/update .git/config using "git config --local name 
value" with all of the same clean/smudge values for subsequent operations.

>From there, it seems that the contents of the smudged files are always 
>correct, assuming the filter works of course. It was the use of -c that makes 
>this work.

Sound about right?

Cheers,
Randall

RE: [Best Practices Request] clean/smudge configuration

[Randall S. Becker]

On May 10, 2018 10:27 PM, Junio C Hamano wrote:
> "Randall S. Becker" <rsbec...@nexbridge.com> writes:
> 
> > What if we create a ../.gitconfig like ../.gitattributes, that is
> > loaded before .git/config?
> 
> You should not forget one of the two reasons why clean/smudge/diff etc.
> drivers must be given with a step of redirection, split between attributes and
> config.  "This path holds text from ancient macs" at the logical level may be
> expressed in .gitattributes, and then "when checking out text from ancient
> macs, process the blob data with this program to turn it into a form suitable
> for working tree" is given as a smudge filter program, that is (1) suitable 
> for
> the platform _you_ as the writer of the config file is using *AND* (2)
> something you are confortable running on behalf of you.
> 
> We *deliberately* lack a mechanism to pay attention to in-tree config that
> gets propagated to those who get them via "git clone", exactly because
> otherwise your upstream may not just specify a "smudge" program that your
> platform would be unable to run, but can specify a "smudge" program that
> pretends to be a smudger, but is actually a program that installs a keylogger
> and posts your login password and bank details to this mailing list ;-)
> 
> So, no, I do not think in-tree configuration will fly.

I agree, which is why I asked the original question instead of posting it as a 
formal patch. We would probably get a brand new CVE implementing the proposed 
proto-changes even if the original intent was internal trusted repositories 
only. That's why I asked this as a "Best Practices" type question, which I 
think I have a better idea on now. The actual situation is rather cool from a 
DevOps point of view, and whatever the ultimate solution is, might make for a 
nice presentation at some future conference .

Cheers and thanks,
Randall

RE: [Best Practices Request] clean/smudge configuration

[Randall S. Becker]

On May 9, 2018 6:39 PM, Bryan Turner wrote:
> On Wed, May 9, 2018 at 3:09 PM Randall S. Becker
> <rsbec...@nexbridge.com>
> wrote:
> 
> > The question: what is the best practice for versioning the parts of
> > clean/smudge filters that are in .git/config given that only some
> > users in my environment will be cloning the repository in question and
> > that I
> really
> > can't put the entries in /etc/gitconfig or ~/.gitconfig because of
> potential
> > conflicts with other repositories that might also have clean/smudge
> > definitions.
> 
> Depending on level of trust, one approach might be to use an [include] in
> .git/config to include a file that's in the repository. Something like:
> 
> [include]
>  path = ../path/to/config
> 

What if we create a ../.gitconfig like ../.gitattributes, that is loaded
before .git/config? With loads of warnings in the documentation about what
*NOT* to put in here, any platform specifics and your own risk. The code in
config.c would look like the following, with obvious updates to
documentation and the test suite, so it's not fully baked yet. So far, I
don't have a solution to the chicken-and-egg problem, other than this.
However, if I'm barking up the wrong ballpark...

diff --git a/config.c b/config.c
index b0c20e6cb..75d5288ff 100644
--- a/config.c
+++ b/config.c
@@ -1555,11 +1555,15 @@ static int do_git_config_sequence(const struct
config_options *opts,
char *xdg_config = xdg_config_home("config");
char *user_config = expand_user_path("~/.gitconfig", 0);
char *repo_config;
+   char *repo_config_versioned;

-   if (opts->commondir)
+   if (opts->commondir) {
repo_config = mkpathdup("%s/config", opts->commondir);
-   else
+   repo_config_versioned = mkpathdup("%s/../.gitconfig",
opts->commondir);
+   } else {
repo_config = NULL;
+   repo_config_versioned = NULL;
+   }

current_parsing_scope = CONFIG_SCOPE_SYSTEM;
if (git_config_system() && !access_or_die(git_etc_gitconfig(), R_OK,
0))
@@ -1574,6 +1578,8 @@ static int do_git_config_sequence(const struct
config_options *opts,
ret += git_config_from_file(fn, user_config, data);

current_parsing_scope = CONFIG_SCOPE_REPO;
+   if (repo_config_versioned && !access_or_die(repo_config_versioned,
R_OK, 0))
+   ret += git_config_from_file(fn, repo_config_versioned,
data);
if (repo_config && !access_or_die(repo_config, R_OK, 0))
ret += git_config_from_file(fn, repo_config, data);

@@ -1585,6 +1591,7 @@ static int do_git_config_sequence(const struct
config_options *opts,
free(xdg_config);
free(user_config);
free(repo_config);
+   free(repo_config_versioned);
return ret;
 }

RE: [Best Practices Request] clean/smudge configuration

[Randall S. Becker]

On May 9, 2018 6:39 PM, Bryan Turner wrote
> 
> On Wed, May 9, 2018 at 3:09 PM Randall S. Becker
> <rsbec...@nexbridge.com>
> wrote:
> 
> > The question: what is the best practice for versioning the parts of
> > clean/smudge filters that are in .git/config given that only some
> > users in my environment will be cloning the repository in question and
> > that I
> really
> > can't put the entries in /etc/gitconfig or ~/.gitconfig because of
> potential
> > conflicts with other repositories that might also have clean/smudge
> > definitions.
> 
> Depending on level of trust, one approach might be to use an [include] in
> .git/config to include a file that's in the repository. Something like:
> 
> [include]
>  path = ../path/to/config

It's a possibility, but I don't like the implications. Files that are subject 
to the clean/smudge would need to be reprocessed manually. In the scenario:

1. A checkout is done, changing ../path/to/config.
2. The clean/smudge configuration changes in ../path/to/config, but the files 
impacted by it do not.
3. git does not look like it would not be aware of the change until after the 
checkout, which is too late.
4. The work tree is now inconsistent with the idempotency of the clean/smudge 
rules, basically because nothing happened. (not blaming git here, just timing).

As far as I understand, this is a bit of a chicken-and-egg problem because the 
clean/smudge config needs to be there before the checkout. Correct?

Cheers,
Randall

[Best Practices Request] clean/smudge configuration

[Randall S. Becker]

Hi Git Team,

I'm trying to work out some best practices for managing clean/smudge filters
and hit a bump. The situation is that I have an environment where the
possible clean/smudge filter configuration can change over time and needs to
be versioned with the product being managed in a git repository. Part of the
configuration is no problem in .gitattributes, but the other bits are in
.git/config. I get that the runnable part of the filters need to be strictly
platform independent in principle, but I can abstract that part in this
situation.

The question: what is the best practice for versioning the parts of
clean/smudge filters that are in .git/config given that only some users in
my environment will be cloning the repository in question and that I really
can't put the entries in /etc/gitconfig or ~/.gitconfig because of potential
conflicts with other repositories that might also have clean/smudge
definitions.

Thanks,
Randall 

RE: How to undo previously set configuration?

[Randall S. Becker]

On April 5, 2018 7:21 AM, Ævar Arnfjörð Bjarmason wrote:
> On Thu, Apr 05 2018, Olaf Hering wrote:
> 
> > Am Thu, 05 Apr 2018 10:42:15 +0200
> > schrieb Ævar Arnfjörð Bjarmason :
> >
> >> I've been meaning to work on this but haven't figured out a good syntax
> for it (suggestions welcome!).
> >
> > Just prefix the knob with something like "no." or "-" or whatever to 
> > indicate
> that it never happened.
> 
> Those wouldn't work, respectively, because:
> 
>  a) For 'no.' there would be no way to override three-level keys,
> because prefixing such a key with "no" would introduce a 4th nesting
> level, which would be incompatible with existing config parsers.
> 
>  b) Similarly a prefix of - dies in git now. Unless I misunderstand
> you. I'm assuming you mean something like:
> 
> [user]
> # This is an error
> -email
> 
> Although I see we don't ignore or error out on:
> 
> [user "-email"]
> foo=bar
> 
>But that's back to problem a), and also looks ugly since you need
>something like the extra foo=bar so we'll pay attention to it.
> 
> Also it's important that the syntax leaves room for item #1 that I mentioned,
> 
> I.e. not just ignore stuff like user.email, but being able to specify where 
> from
> you'd like to ignore that. Sometimes your local sysadmin is overzealous with
> his /etc/gitconfig settings and you'd like to quarantine just that, but pay
> attention to everything else in ~/.gitconfig, or similarly in
> /some/repo/.git/config ignore your usual custom sendemail.* from
> ~/.gitconfig but not /etc/gitconfig, so the semantics can't just be "clear
> existing".
> 
> But of course, you might say that it *should* be a syntax error because if you
> rely on this feature and downgrade, you don't want to suddenly pay
> attention to the sendemail.* config again.
> 
> I think that's an acceptable failure mode, and better than the syntax error,
> because that's exactly what we have now, so this is similar to e.g. the
> conditional include directive which was understood but just copmletely
> ignored by older versions.
> 
> So we're OK with getting different config between versions with new
> releases, but at all costs don't want to have new releases introduce
> constructs that older gits error out on, and let's say hypothetically we
> supported something like:
> 
> [user "-email"]
> [user]
> email = ...
> 
> Even `git config -l` on older version won't show that "user.-email", and it's
> better if older tools at least understand the syntax, even though they don't
> pick up on the magic.

I may be missing something but..

Another completely different approach to "undoing" configurations is to 
consider using git for this. Have a repository set up for your ~ directory, 
ignoring content other than .*, so you would ignore any sub-repositories at 
this level. Then manage your configuration as any other repo.

For configurations that are not user-specific, use in-repository configurations 
instead of system and global, so your undo is also handled by git. However, you 
can version control your /etc directory as well. We do that to detect changes 
(as a practical example, we have /etc/.git with some bits ignored but critical 
things involving rc.d, and the system git configurations are managed content in 
that repository. This implies our Ops team has to use git to make changes - a 
good thing - and 'git status' and 'git log' tells me immediately if someone 
changed something.

Undo becomes a git operation in both situations.

This may be complete OT, but I thought it might help

Cheers,
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.17.0

[Randall S. Becker]

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

The NonStop platform variant's regression suite (after applying are now very 
small set of platform mods) had the usual failures in t1308:23, t1404:52, and 4 
in t9001. This is equivalent to the same breaks since 2.8.5 through 2.16.2. We 
should be installing in production tomorrow.

Thanks for everyone's hard work.

Cheers,
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.17.0

[Randall S. Becker]

On April 2, 2018 7:20 PM, Junio C Hamano wrote:
> To: Stefan Beller <sbel...@google.com>
> Cc: Randall S. Becker <rsbec...@nexbridge.com>; git <git@vger.kernel.org>
> Subject: Re: [ANNOUNCE] Git v2.17.0
> 
> Stefan Beller <sbel...@google.com> writes:
> 
> > Patch at
> > https://public-
> inbox.org/git/010f01d38a9e$a5c4f290$f14ed7b0$@nexbridge
> > .com/
> 
> Thanks for a pointer.  I think it was left behind and got forgotten while
> waiting for a reroll and tying the loose ends.
> 
> I'll go offline for most of the rest of the week.  It would be wonderful
if Git
> 2.17 turns out to be flawless, but that is not a realistic expectation.
Wishing
> for the second best, I'd very much appreciate it if people worked hard to
find
> and fix regressions and collect materials for its first maintenance
release
> 2.17.1 ;-)

No worries. We're running the test suite now (NonStop Platform) and assuming
all is good, it goes into our prod environment this week.

Cheers,
Randall

RE: [ANNOUNCE] Git v2.17.0

[Randall S. Becker]

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

That was it, thanks.

Cheers,
Randall

RE: [ANNOUNCE] Git v2.17.0

[Randall S. Becker]

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);

Cheers,
Randall

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

[Randall S. Becker]

On April 1, 2018 11:22 PM Junio C Hamano wrote:
> Junio C Hamano  writes:
> > If you are really doing your own development, then you would have some
> > topic branches of your own, with forks of some (but most likely not
> > all, especiallyi when there are many branches at the upstream)
> > branches you got from the upstream, and "git branch --list" that shows
> > only your own and what you are interested in (i.e. those that you
> > actually bothered to "git checkout ") without showing
> > random other branches that exist at the remote but do not interest you
> > is a feature.  Your hypothetical "clone" that indiscriminatedly forks
> > all branches at remote locally will destroy the usefulness of it.
> 
> Related to this, a feature I have long thought we wished to have is
complete
> opposite of this.  After creating and working on a local topic branch and
then
> concluding the work on it, a user would "git push" the branch out to a
> remote, and then check out a different branch (e.g. the 'master' branch).
I
> wish we had a mode that would automatically *delete* the local topic
branch
> that has already been pushed out (and more importantly, a branch that I
> have *done* with, at least for now), to unclutter my local branch
> namespace.  When I want to further work on it, I can ask "git checkout" to
> dwim to recreate one on demand.
> 
> Of course, there are some wrinkles due to pesky impleemntation details
> (e.g. the "autonuke-and-recreate" would lose reflog), but I do not think
it is
> fundamental hurdle.

I'm a little skeptical and confused here. The original RFC does not appear
to stipulate that this is isolated to a single bare. If B,C,D all clone
A.git from one server, it might be ok. If B clones A.git, and C clones B,
and D mirrors C, where would the remote tracking occur. The main value, as a
repo admin of A.git would be to know everything, but that's unlikely.
Stating the obvious rub is, in a DVCS, where connections are not guaranteed,
one can easily move a clone or delete a clone, and your tracking branch
becomes worthless. You might never know about C/D mirrors or even be able to
establish a connection between A.git and those two, in practice - I have
examples of those.
OTOH I have been toying with suggesting a solution to this for a couple of
years, differentiating a transient clone from a (pick a term) authentic
clone, the latter which has some blockchainish so that git will whine
without a valid signature on the clone. Changing the clone without
communicating with the upstream to revalidate it (deferrals could be
implemented), temporarily or permanently invalidates the authentic clone so
it effective becomes pruneable, like a worktree. I see a very deep potential
rabbit hole here that detracts from DVCS principles unless we do have the
conceptual split of the two classes of clones. rm .git is just too easy and
too frequent an operation to just ignore the implication of the deliberate
loss of tracking that is highly unlikely to be trackable by the farthest
upstream, resulting in a whole lot of clutter with no way back.
Alternatively, if the downstreams periodically are forced to revalidate the
tracking branches, then you have sometime potentially workable but annoying
at best, and impractical in some security policies at worst.

Just my $0.02 from managing boat-loads of 4 and 5 level deep repositories.

Cheers,
Randall

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

[Randall S. Becker]

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

While I have not done this in the git suite, my own suites use something along 
the lines of the following when I need (and have to validate) exact spacing at 
the beginning of lines in expected output:

cat <<-EOF | sed "1,\$s/_/ /g" >expect
{ level1 ...
{ level2
Etc.
EOF

Providing you don't use _ elsewhere in the output. It's a bit hacky but works.

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

> -Original Message-
> From: git-ow...@vger.kernel.org  On Behalf
> Of Junio C Hamano
> Sent: March 15, 2018 12:52 PM
> To: Jake Stine 
> Cc: git@vger.kernel.org
> Subject: Re: [bug] git stash push {dir-pathspec} wipes untracked files
> 
> Jake Stine  writes:
> 
> > Hi, I ran into what I believe is a bug today.  I’m using primarily Git
> > for Windows 2.16.2 and also reproduced the behavior on Git for Windows
> > 2.15.1 and Git 2.14.1 on Ubuntu:
> >
> > Given any repository with at least one subdirectory:
> >
> > 1.   Create some untracked files in the subdir
> > 2.   Modify a tracked file in the subdir
> > 3.   Execute `git stash push subdir`
> > 4.   The untracked files will be removed, without warning.
> >
> > `git stash push` behaves as-expcted and does not touch untracked
> > files.  It’s only when a directory tree is specified as [pathspec]
> > that the problem occurs.
> 
> I wonder if this is the same as the topic on this thread.
> 
>   https://public-
> inbox.org/git/CA+HNv10i7AvWXjrQjxxy1LNJTmhr7LE4TwxhHUYBiWtmJCOf_
> a...@mail.gmail.com/
> 
> What is curious is that the fix bba067d2 ("stash: don't delete untracked files
> that match pathspec", 2018-01-06) appeared first in 2.16.2, on which
> Windows 2.16.2 is supposed to be built upon.
> 
> > Here's the precise reproduction case executed on a linux box:
> 
> This does not reproduce for me with v2.16.2-17-g38e79b1fda (the tip of
> 'maint'); I do not have an  install of vanilla v2.16.2 handy, but I suspect 
> v2.16.2
> would work just fine, too.

This does not reproduce for me either in v2.16.2.9-g3dbadef9f (which is the 
NonStop port of 2.16.2)

On branch master
Changes not staged for commit:
  (use "git add ..." to update what will be committed)
  (use "git checkout -- ..." to discard changes in working directory)

modified:   subdir/a

Untracked files:
  (use "git add ..." to include in what will be committed)

subdir/b

no changes added to commit (use "git add" and/or "git commit -a")
/home/randall/foot: git stash push subdir
Saved working directory and index state WIP on master: b772270 i
/home/randall/foot: ls subdir
a  b
/home/randall/foot: git status
On branch master
Untracked files:
  (use "git add ..." to include in what will be committed)

subdir/b

nothing added to commit but untracked files present (use "git add" to track)

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

[Randall S. Becker]

On March 13, 2018 2:37 PM, Junio C Hamano wrote:
> Ævar Arnfjörð Bjarmason  writes:
> 
> > Related to this, I came across this bug report
> > https://gitlab.com/gitlab-org/omnibus-gitlab/issues/3265 which is
> > wondering why we're installing N copies of the git binary, presumably
> > they're building with NO_INSTALL_HARDLINKS.
> > ...
> > But is there any reason anyone can think of for why we shouldn't be
> > figuring out the relative path and symlinking the two?
> 
> 
> There is no fundamental reason not to offer such an "install" method as an
> option; unless you count a more philosophical aversion to use symlinks due
> to (perceived) additional fragility, that is.
> 
> The resulting code may become messier than without, but as long as it is
> without the reasonable range for usual price we would pay for a new
> "feature", that would be tolerable, I guess.

A possible (remote) reason for not doing this is in environments using ACLs 
that somehow want different access permissions on some functions vs. others AND 
where the platform does not have the ability to separately secure links vs. 
objects. I don't know of such an environment, but you never know. I know it's a 
stretch, but I can see security-types being worried about this. I do know of 
environments where /usr/local/lib is secured differently from /usr/local/bin to 
prevent inappropriate .so loads on a selective basis, so there's that. Again, 
this is a stretch. As long as we continue to have a method of forcing the 
expensive way for the paranoidly inclined ;)-- not meaning offence to 
those, of course.

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

On March 2, 2018 10:39 PM, Nguy?n Thái Ng?c Duy wrote:
> This is something we could do to improve the situation when a user manually
> moves a worktree and not follow the update process (we have had the first
> reported case [1]). Plus a bit cleanup in gc.
> 
> I think this is something we should do until we somehow make the user
> aware that the worktree is broken as soon as they move a worktree
> manually. But there's some more work to get there.
> 
> [1] http://public-inbox.org/git/%3Caa98f187-4b1a-176d-2a1b-
> 826c99577...@aegee.org%3E

I wonder whether the OT thread discussion about branch annotation may have some 
value here. For some repositories I manage, I have received questions about 
whether there was some way to know that a branch in the clone was associated 
with a worktree "at any point in the past", which, once the worktree has been 
pruned, is not derivable in a formal computational sense - there may be 
specific conditions where it is. Perhaps, if that line of development moves 
forward, that we should considering annotating the worktree-created branch to 
help with our pruning process and to identify where the branch originated.

Just a thought.

Cheers,
Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(2112884442)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

On March 1, 2018 2:36 AM, Jeff King wrote:
> On Wed, Feb 28, 2018 at 05:51:14PM +0100, demerphq wrote:
> 
> > I would look into putting it into a module and then using the PERL5OPT
> > environment var to have it loaded automagically in any of your perl
> > scripts.
> >
> > For instance if you put that code into a module called Git/DieTrap.pm
> >
> > then you could do:
> >
> > PERL5OPT=-MGit::DieTrap
> >
> > In your test setup code assuming you have some. Then you don't need to
> > change any of your scripts just the test runner framework.
> 
> That's a clever trick.
> 
> It's not clear to me though if we just want to tweak the programs run in the
> test scripts in order to get test_must_fail to stop complaining, or if we
> consider the unusual exit codes from our perl-based Git programs to be an
> error that should be fixed for real use, too.

I'm living unusual exit code IRL all the time. So "fixed for real", is what I'm 
looking for. So if we were to do that, where is the best place to insert a fix 
- my original question - that would be permanent in the main git test code. Or 
perhaps this needs to be in the main code itself.

Cheers,
Randall

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

[Randall S. Becker]

On February 28, 2018 3:04 PM, Jonathan Nieder wrote:
> On February 28, 2018 1:52 PM, Jonathan Nieder wrote:
> > Randall S. Becker wrote:
> > > On February 28, 2018 12:44 PM, Jonathan Nieder wrote:
> > >> Randall S. Becker wrote:
> >
> > >>> The problem is actually in git code in its test suite that uses
> > >>> perl inline, not in my test code itself.
> > [...]
> > >> Can you elaborate with an example?  My understanding was that
> > >> test_must_fail is only for running git.
> > [...]
> > > Have a look at a recent t1404 as a sample. Line 615 is the one
> > > causing the platform grief, because it triggers a 'die'. However,
> > > the particular test case #54, had no difference on platform with
> > > test_must_fail or !, which has the same underlying EBADF completion
> after
> > digging and digging.
> >
> > Sorry to be dense: what I see on that line is
> >
> > test_must_fail git update-ref -d $prefix/foo >out 2>err &&
> 
> My bad, I think. I'm going to go looking through my notes and get back on
> which line in the test was the issue. I assumed from your response that it
> might have been the test_must_fail, which is throughout the git test
suite.
> Obviously it isn't the line failing in this case. Stay tuned.

The original thread below has details of what the original issue was and
why. It hit three tests specifically on this platform where die was invoked
(at least on one of them). Perl was invoked under the covers and the
completion code of 169 propagated back through git to the test framework.
https://public-inbox.org/git/499fb29f-ca34-8d28-256d-896107c29...@kdbg.org/T
/#m0b30f0857feae2044f38e04dc6b8565b68b7d52b

While removing test_must_fail is laudable, it won't seemingly solve the
underlying cause that I am trying to work through, which is inserting the
$SIGdie reporting 169 on platform and inserting:

 SIG{__DIE__} = sub {
   CORE::die @_ if $^S || !defined($^S);
   print STDERR "fatal: @_";
   exit 128;
 };

I just don't know the framework well enough (or perl for that matter) to
know the exact spot to place this so that it would work properly and be
acceptable to the committers (you know who you are :-) ). 

I hope that provides info on what is going on and why I am motivated to fix
this by (nearly) whatever means necessary.

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

On February 28, 2018 1:52 PM, Jonathan Nieder wrote:
> Randall S. Becker wrote:
> > On February 28, 2018 12:44 PM, Jonathan Nieder wrote:
> >> Randall S. Becker wrote:
> 
> >>> The problem is actually in git code in its test suite that uses perl
> >>> inline, not in my test code itself.
> [...]
> >> Can you elaborate with an example?  My understanding was that
> >> test_must_fail is only for running git.
> [...]
> > Have a look at a recent t1404 as a sample. Line 615 is the one causing
> > the platform grief, because it triggers a 'die'. However, the
> > particular test case #54, had no difference on platform with
> > test_must_fail or !, which has the same underlying EBADF completion
after
> digging and digging.
> 
> Sorry to be dense: what I see on that line is
> 
>   test_must_fail git update-ref -d $prefix/foo >out 2>err &&

My bad, I think. I'm going to go looking through my notes and get back on
which line in the test was the issue. I assumed from your response that it
might have been the test_must_fail, which is throughout the git test suite.
Obviously it isn't the line failing in this case. Stay tuned.

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

[Randall S. Becker]

On February 28, 2018 12:44 PM, Jonathan Nieder wrote:
> Randall S. Becker wrote:
> 
> > The problem is actually in git code in its test suite that uses perl
> > inline, not in my test code itself. The difficulty I'm having is
> > placing this appropriate so that the signal handler gets used
> > throughout the test suite including in the perl -e invocations. This
> > is more a lack of my own understanding of plumbing of git test
> > framework rather than of using or coding perl.
> 
> Can you elaborate with an example?  My understanding was that
> test_must_fail is only for running git.  If a test is running perl and
wants to
> check its exit code, the test is supposed to use !, not test_must_fail.
> 
> t/README backs me up:
> 
>  - use '! git cmd' when you want to make sure the git command exits
>with failure in a controlled way by calling "die()".  Instead,
>use 'test_must_fail git cmd'.  This will signal a failure if git
>dies in an unexpected way (e.g. segfault).
> 
>On the other hand, don't use test_must_fail for running regular
>platform commands; just use '! cmd'.  We are not in the business
>of verifying that the world given to us sanely works.
> 
> So I don't consider the initial issue you raised a test issue at all!
> It's a bug in the git commands, and a fix for it should not be specific to
the
> test suite.
> 
> And now it sounds like there is a second issue: the test suite is
overusing
> test_must_fail in some context and that needs to be fixed as well.

Have a look at a recent t1404 as a sample. Line 615 is the one causing the
platform grief, because it triggers a 'die'. However, the particular test
case #54, had no difference on platform with test_must_fail or !, which has
the same underlying EBADF completion after digging and digging.

not ok 52 - delete fails cleanly if packed-refs file is locked
#
#   prefix=refs/locked-packed-refs &&
#   # Set up a reference with differing loose and packed
versions:
#   git update-ref $prefix/foo $C &&
#   git pack-refs --all &&
#   git update-ref $prefix/foo $D &&
#   git for-each-ref $prefix >unchanged &&
#   # Now try to delete it while the `packed-refs` lock is held:
#   : >.git/packed-refs.lock &&
#   test_when_finished "rm -f .git/packed-refs.lock" &&
#   ! git update-ref -d $prefix/foo >out 2>err &&
#   git for-each-ref $prefix >actual &&
#   test_i18ngrep "Unable to create $Q.*packed-refs.lock$Q: File
exists" err &&
#   test_cmp unchanged actual
#

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

[Randall S. Becker]

On February 28, 2018 12:19 PM, demerphq wrote:
> On 28 February 2018 at 18:10, Randall S. Becker <rsbec...@nexbridge.com>
> wrote:
> > On February 28, 2018 11:46 AM, demerphq wrote:
> >> On 28 February 2018 at 08:49, Jeff King <p...@peff.net> wrote:
> >> > On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote:
> >> >
> >> >> > > >  a) We could override the meaning of die() in Git.pm.  This feels
> >> >> > > > ugly but if it works, it would be a very small patch.
> >> >> > >
> >> >> > > Unlikely to work since I think we use eval {} to trap
> >> >> > > exceptions from die.
> >> >> > >
> >> >> > > >  b) We could forbid use of die() and use some git_die() instead
> (but
> >> >> > > > with a better name) for our own error handling.
> >> >> > >
> >> >> > > Call sites may be dual-use: "die" can either be caught by an
> >> >> > > eval or used to show an error message to the user.
> >> >>
> >> >> 
> >> >>
> >> >> > > >  d) We could wrap each command in an eval {...} block to convert
> the
> >> >> > > > result from die() to exit 128.
> >> >> > >
> >> >> > > I prefer option d)
> >> >> >
> >> >> > FWIW, I agree with all of that. You can do (d) without an
> >> >> > enclosing eval block by just hooking the __DIE__ handler, like:
> >> >> >
> >> >> > $SIG{__DIE__} = sub {
> >> >> >   print STDERR "fatal: @_\n";
> >> >> >   exit 128;
> >> >> > };
> >> >>
> >> >> Looks like it has the same problems I pointed out with a) and b).
> >> >
> >> > You're right. I cut down my example too much and dropped the
> >> > necessary eval magic. Try this:
> >> >
> >> > -- >8 --
> >> > SIG{__DIE__} = sub {
> >> >   CORE::die @_ if $^S || !defined($^S);
> >> >   print STDERR "fatal: @_";
> >> >   exit 128;
> >> > };
> >>
> >> FWIW, this doesn't need to use CORE::die like that unless you have
> >> code that overrides die() or CORE::GLOBAL::die, which would be pretty
> unusual.
> >>
> >> die() within $SIG{__DIE__} is special cased not to trigger
> >> $SIG{__DIE__} again.
> >>
> >> Of course it doesn't hurt, but it might make a perl hacker do a
> >> double take why you are doing it. Maybe add a comment like
> >>
> >> # using CORE::die to armor against overridden die()
> >
> > The problem is actually in git code in its test suite that uses perl 
> > inline, not in
> my test code itself. The difficulty I'm having is placing this appropriate so 
> that
> the signal handler gets used throughout the test suite including in the perl 
> -e
> invocations. This is more a lack of my own understanding of plumbing of git
> test framework rather than of using or coding perl.
> 
> Did you reply to the wrong mail?
> 
> Create a file like:
> 
> .../Git/DieTrap.pm
> 
> which would look like  this:
> 
> package Git::DieTrap;
> use strict;
> use warnings;
> 
> SIG{__DIE__} = sub {
>CORE::die @_ if $^S || !defined($^S);
>print STDERR "fatal: @_";
>exit 128;
> };
> 
> 1;
> __END__
> 
> and then you would do:
> 
> export PERL5OPT=-MGit::DieTrap
> 
> before executing any tests. ANY use of perl from that point on will behave as
> though it has:
> 
> use Git::DieTrap;
> 
> at the top of the script, be it a -e, or any other way that Perl code is
> executed.

The context of this request, perhaps missing, what that I have been trying to 
move the platform to the standard git code base. It is not my issue 
specifically. Rather, if someone else wants to build and test git on the 
platform, they should not have to have any knowledge of putting in hacks to 
make it work. I can personally make this work. That's not the point. It is to 
allow others on platform to make it work without deep knowledge. Otherwise, I 
am not being productive with my efforts.

Cheers,
Randall

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

[Randall S. Becker]

On February 28, 2018 11:46 AM, demerphq wrote:
> On 28 February 2018 at 08:49, Jeff King  wrote:
> > On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote:
> >
> >> > > >  a) We could override the meaning of die() in Git.pm.  This feels
> >> > > > ugly but if it works, it would be a very small patch.
> >> > >
> >> > > Unlikely to work since I think we use eval {} to trap exceptions
> >> > > from die.
> >> > >
> >> > > >  b) We could forbid use of die() and use some git_die() instead (but
> >> > > > with a better name) for our own error handling.
> >> > >
> >> > > Call sites may be dual-use: "die" can either be caught by an eval
> >> > > or used to show an error message to the user.
> >>
> >> 
> >>
> >> > > >  d) We could wrap each command in an eval {...} block to convert the
> >> > > > result from die() to exit 128.
> >> > >
> >> > > I prefer option d)
> >> >
> >> > FWIW, I agree with all of that. You can do (d) without an enclosing
> >> > eval block by just hooking the __DIE__ handler, like:
> >> >
> >> > $SIG{__DIE__} = sub {
> >> >   print STDERR "fatal: @_\n";
> >> >   exit 128;
> >> > };
> >>
> >> Looks like it has the same problems I pointed out with a) and b).
> >
> > You're right. I cut down my example too much and dropped the necessary
> > eval magic. Try this:
> >
> > -- >8 --
> > SIG{__DIE__} = sub {
> >   CORE::die @_ if $^S || !defined($^S);
> >   print STDERR "fatal: @_";
> >   exit 128;
> > };
> 
> FWIW, this doesn't need to use CORE::die like that unless you have code that
> overrides die() or CORE::GLOBAL::die, which would be pretty unusual.
> 
> die() within $SIG{__DIE__} is special cased not to trigger $SIG{__DIE__}
> again.
> 
> Of course it doesn't hurt, but it might make a perl hacker do a double take
> why you are doing it. Maybe add a comment like
> 
> # using CORE::die to armor against overridden die()

The problem is actually in git code in its test suite that uses perl inline, 
not in my test code itself. The difficulty I'm having is placing this 
appropriate so that the signal handler gets used throughout the test suite 
including in the perl -e invocations. This is more a lack of my own 
understanding of plumbing of git test framework rather than of using or coding 
perl.

Cheers,
Randall

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

[Randall S. Becker]

On February 28, 2018 2:49 AM, Peff wrote:
> On Wed, Feb 28, 2018 at 07:42:51AM +, Eric Wong wrote:
> 
> > > > >  a) We could override the meaning of die() in Git.pm.  This feels
> > > > > ugly but if it works, it would be a very small patch.
> > > >
> > > > Unlikely to work since I think we use eval {} to trap exceptions
> > > > from die.
> > > >
> > > > >  b) We could forbid use of die() and use some git_die() instead (but
> > > > > with a better name) for our own error handling.
> > > >
> > > > Call sites may be dual-use: "die" can either be caught by an eval
> > > > or used to show an error message to the user.
> >
> > 
> >
> > > > >  d) We could wrap each command in an eval {...} block to convert the
> > > > > result from die() to exit 128.
> > > >
> > > > I prefer option d)
> > >
> > > FWIW, I agree with all of that. You can do (d) without an enclosing
> > > eval block by just hooking the __DIE__ handler, like:
> > >
> > > $SIG{__DIE__} = sub {
> > >   print STDERR "fatal: @_\n";
> > >   exit 128;
> > > };
> >
> > Looks like it has the same problems I pointed out with a) and b).
> 
> You're right. I cut down my example too much and dropped the necessary
> eval magic. Try this:
> 
> -- >8 --
> SIG{__DIE__} = sub {
>   CORE::die @_ if $^S || !defined($^S);
>   print STDERR "fatal: @_";
>   exit 128;
> };
> 
> eval {
>   die "inside eval";
> };
> print "eval status: $@" if $@;
> 
> die "outside eval";
> -- 8< --
> 
> Running that should produce:
> 
> $ perl foo.pl; echo $?
> eval status: inside eval at foo.pl line 8.
> fatal: outside eval at foo.pl line 12.
> 128
> 
> It may be getting a little too black-magic, though. Embedding in an eval is at
> least straightforward, if a bit more invasive.

I like this solution. The $64K question for me is how (a.k.a. where) to 
instrument this broadly instead of in each perl fragment in the test suite.  
The code:

$SIG{__DIE__} = sub {
  CORE::die @_ if $^S || !defined($^S);
  print STDERR "fatal: @_";
  exit 128;
};

eval {
  die "inside eval";
};

print "eval status: $@" if $@;

die "outside eval";

as tested above, in NonStop results in an exit code of 128 whether run from a 
script or from stdin (a good thing). I'm happy to do the heavy lifting on this, 
but  a bit more direction as to the implementation would help.

Cheers,
Randall

[Problem] test_must_fail makes possibly questionable assumptions about exit_code.

[Randall S. Becker]

Hi all,

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

>elif test $exit_code -gt 129 && test $exit_code -le 192
>   then
>   echo >&2 "test_must_fail: died by signal $(($exit_code -
128)):

According to the perl spec http://perldoc.perl.org/functions/die.html, die
basically takes whatever errno is, mods it with 256 and there you go. EBADF
is what is used when perl reads from stdin and calls die - that's standard
perl. In most systems, you end up with something useful, when EBADF is 9.
But when it is 4009, you get a garbage answer (4009 mod 256 a.k.a. 169).
However, only 128-165 are technically reserved for signals, rather than all
the way up to 192, which may be true in some places but not everywhere.

The advice (I'm putting that nicely) I received was to use exit so that the
result is predictable - unlikely to be useful in the 15K test suites in git.
However, dropping this to 165 conditionally might help.

I'm looking for what approach to take here, because I don't think I'm going
to get perl fixed any time soon, or the error number range on the platform
fixed ... ever.

This is causing only two breaks that I have lived with and probably still
could. Consider me begging for a suggestion.

Sincerest,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

On February 25, 2018 1:57 PM, Ævar Arnfjörð Bjarmason wrote:
> On Wed, Feb 14 2018, Jonathan Nieder jotted:
> 
> > Ævar Arnfjörð Bjarmason wrote:
> >
> >> Change the two wrappers to load from CPAN (local OS) or our own copy
> >> to do so via the same codepath.
> >
> > nit: I think with s/to load/that load/ this will be easier to read.
> >
> >> I added the Error.pm wrapper in 20d2a30f8f ("Makefile: replace
> >> perl/Makefile.PL with simple make rules", 2017-12-10), and shortly
> >> afterwards Matthieu Moy added a wrapper for Mail::Address in
> >> bd869f67b9 ("send-email: add and use a local copy of Mail::Address",
> >> 2018-01-05).
> >>
> >> His was simpler since Mail::Address doesn't have an "import" method,
> >> but didn't do the same sanity checking, e.g. a missing FromCPAN
> >> directory (which OS packages are likely not to have) wouldn't be
> >> explicitly warned about.
> >
> > I'm having trouble parsing this.  Mail::Address didn't do the same
> > sanity checking or his didn't?
> >
> > The comma before e.g. should be a period or semicolon, since it's
> > starting a new independent clause.
> >
> >> Now both use a modification of the previously Error.pm-specific
> >> codepath, which has been amended to take the module to load as
> >> parameter, as well as whether or not that module has an import method.
> >
> > Does "now" mean before this patch or after this patch?  Usually commit
> > messages describe the status quo without the patch in the present
> > tense and the change the patch will make in the imperative.
> > So this could say:
> >
> > Update both to use a common implementation based on the
> previous
> > Error.pm loader.
> 
> All good feeedback, thanks. Incorporated into v2 which I'm about to submit.
> 
> > [...]
> >> +++ b/perl/Git/LoadCPAN.pm
> >> @@ -0,0 +1,74 @@
> > [...]
> >> +The Perl code in Git depends on some modules from the CPAN, but we
> >> +don't want to make those a hard requirement for anyone building from
> >> +source.
> >
> > not about this patch: have we considered making it a hard requirement?
> > Both Mail::Address and Error.pm are pretty widely available, and I
> > wonder if we could make the instructions in the INSTALL file say that
> > they are required dependencies to simplify things.
> 
> I can't remember when, but at some point this was discussed on list, and the
> consensus was that us using perl should be kept as a non-invasive
> implementation detail that would be as small of a pain as possible for users.

That would include the platform I'm maintaining, where perl is currently pretty 
handcuffed and blindfolded (including completion code misinterprets). CPAN 
isn't currently an option, but might be soon.

> It's easy for distros to package these modules, but for users building from
> source who know nothing about perl it can be a pain.

Know perl I do. Use it not, can I. ;-)

> I also think it's very useful to avoid the side-discussion about not using 
> some
> useful CPAN module in the future just because it's not widely used, but
> would be perfect for some use-case of ours.
> 
> > I admit part of my bias here is coming from the distro world, where we
> > have to do extra work to get rid of the FromCPAN embedded copies and
> > would be happier not to have to.
> 
> I think there's a very good argument to be made for inverting the
> NO_PERL_CPAN_FALLBACKS logic, but my soon to be submitted v2 keeps it
> off by default.

Cool, thanks.

Cheers,
Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(2112884442)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: Git should preserve modification times at least on request

[Randall S. Becker]

On February 21, 2018 6:13 PM, Peter Backes wrote:
> On Wed, Feb 21, 2018 at 11:44:13PM +0100, Ævar Arnfjörð Bjarmason wrote:
> > If it were added as a first-level feature to git it would present a
> > lot of UX confusion. E.g. you run "git add" and it'll be showing the
> > mtime somehow, or you get a formatted patch over E-Mail and it doesn't
> > only include the commit time but also times for individual files.
> 
> But that's pretty standard. patch format has timestamp fields for
precisely
> this purpose:
> 
> % echo a > x
> % echo b > y
> % diff -u x y
> --- x 2018-02-21 23:56:29.574029523 +0100
> +++ y 2018-02-21 23:56:31.430003389 +0100

May I suggest storing the date/time in UTC+0 in all cases. I can see
potential issues a couple of times a year where holes exist. I cannot even
fathom what would happen on a merge or edit of history.

Cheers,
Randall

RE: [BUG] Worktree prune complains about missing path

[Randall S. Becker]

On February 20, 2018 5:22 PM Eric Sunshine wrote:
> On Tue, Feb 20, 2018 at 3:36 PM, Randall S. Becker
> <rsbec...@nexbridge.com> wrote:
> > I’m a bit confused about this, as I thought I understood worktrees :(.
> >
> > /home/randall/nsgit/test/test dir.mytest: rm -rf dest.wt
> > /home/randall/nsgit/test/test dir.mytest/dest: git worktree prune -v
> > Removing worktrees/dest.wt: gitdir file points to non-existent
> > location
> >
> > It seems like one or two situations are a problem:
> > 1) I’m using a full path for the worktree.
> > 2) There’s a blank in my path – deliberate… tests, yanno.
> >
> > This is git 2.16.2. Could anyone shed some light on this?
> 
> This appears to be working as intended. "git worktree prune" is telling you
> that it is pruning the administrative data for the "dest.wt" worktree (reason:
> "worktree location no longer exists"), which you intentionally deleted before
> pruning. It's not clear what it is that you find confusing. There is not a lot
> more I can say without understanding what behavior you were expecting
> and how your expectation differs from the actual experience.

I should have been more clear here as to the issue. My bad. The git worktree 
prune operation does not remove all vestiges of the removed worktree. The 
following files are retained:

./logs/refs/heads/dest.wt
./refs/heads/dest.wt

So, now that I understand in hindsight, these are actually references to the 
worktree branch 'dest.wt' that obviously remains correctly and properly in git.

Adding:  git branch -D dest.wtto my test script cleared my (embarrassing) 
problem of my own doing.

> 
> (Also, please consider how easy or difficult it is for a reader to interpret 
> your
> pasted "sample session". The one provided is more confusing than necessary
> due to the command prompt bearing the same path information as the
> output of the "git worktree list" command, as well as unnecessary duplicated
> commands, such as "ls", and missing "cd" commands which do not help to
> illuminate what it is you are trying to get across. The pasted transcript also
> contains invalid code-points which render as oddball characters -- or not at 
> all
> -- which didn't help. Best would be to prepare a minimal example of shell
> commands to reproduce the behavior you're trying to illustrate.)

Good point. Again, my bad - very long day debugging. I wanted to show where I 
was in the directory so I sacrificed brevity for completeness and noise. My 
apologies.

So, no bug, just a buggy user.

Cheers,
Randall

[BUG] Worktree prune complains about missing path

[Randall S. Becker]

I’m a bit confused about this, as I thought I understood worktrees :(.

/home/randall/nsgit/test/test dir.mytest/dest git worktree list
/home/randall/nsgit/test/test dir.mytest/dest: git worktree list
/home/randall/nsgit/test/test dir.mytest/dest 4e901ca [master]
/home/randall/nsgit/test/test dir.mytest/dest.wt  4e901ca [dest.wt]

/home/randall/nsgit/test/test dir.mytest/dest: find . -name dest.wt
./.git/logs/refs/heads/dest.wt
./.git/refs/heads/dest.wt
./.git/worktrees/dest.wt
/home/randall/nsgit/test/test dir.mytest/dest/.git: cd worktrees/dest.wt
/home/randall/nsgit/test/test dir.mytest/dest/.git/worktrees/dest.wt: ls
HEAD  ORIG_HEAD  commondir  gitdir  index  logs

/home/randall/nsgit/test/test dir.mytest/dest/.git/worktrees/dest.wt: cat
gitdir
/home/randall/nsgit/test/test dir.mytest/dest.wt/.git

/home/randall/nsgit/test/test dir.mytest/dest/.git/worktrees/dest.wt: ls
HEAD  ORIG_HEAD  commondir  gitdir  index  logs

/home/randall/nsgit/test/test dir.mytest/dest/.git/worktrees/dest.wt: cd
../../../..
/home/randall/nsgit/test/test dir.mytest: rm -rf dest.wt
/home/randall/nsgit/test/test dir.mytest: cd dest
/home/randall/nsgit/test/test dir.mytest/dest: git worktree prune -v
Removing worktrees/dest.wt: gitdir file points to non-existent location

It seems like one or two situations are a problem:
1) I’m using a full path for the worktree. 
2) There’s a blank in my path – deliberate… tests, yanno.

This is git 2.16.2. Could anyone shed some light on this?

Cheers,
Randall

RE: Git should preserve modification times at least on request

[Randall S. Becker]

On February 19, 2018 4:58 PM Johannes wrote:
> On Mon, 19 Feb 2018, Peter Backes wrote:
> 
> > please ensure to CC me if you reply as I am not subscribed to the list.
> >
> > https://git.wiki.kernel.org/index.php/Git_FAQ#Why_isn.27t_Git_preservi
> > ng_modification_time_on_files.3F argues that git isn't preserving
> > modification times because it needs to ensure that build tools work
> > properly.
> >
> > I agree that modification times should not be restored by default,
> > because of the principle of least astonishment. But should it be
> > impossible? The principle of least astonishment does not mandate this;
> > it is not a paternalistic principle.
> >
> > Thus, I do not get at all
> > - why git doesn't *store* modification times, perhaps by default, but
> > at least on request
> > - why git doesn't restore modification times *on request*
> >
> > It is pretty annoying that git cannot, even if I know what I am doing,
> > and explicitly want it to, preserve the modification time.
> >
> > One use case: I have lots of file lying around in my build directory
> > and for some of them, the modification time in important information
> > to me. Those files are not at all used with the build tool. In
> > contrast to git pull, git pull --rebase needs those to be stashed. But
> > after the pull and unstash, the mtime is gone. Boo.
> >
> > Please provide options to store and restore modification times. It
> > shouldn't be hard to do, given that other metadata such as the mode is
> > already stored. It would make live so much easier. And the fact that
> > this has made into the FAQ clearly suggests that there are many others
> > who think so.
> 
> Since you already assessed that it shouldn't be hard to do, you probably
> want to put your money where your mouth is and come up with a patch, and
> then offer it up for discussion on this here mailing list.

Putting my large-production-user hat on, there are (at least) three
conditions that exist in this space:

1. Build systems - this typically need the file modification time to be set
to the time at which git touches a file (e.g., checkout). This permits build
systems to detect that files are modified (even if an older version is
checked out, make, for example, still needs to see the change to initiate a
build. My understanding is that current git behaviour is modeled on this use
case.

2. Commit linkage - in some environments, files that are checked out are set
to the timestamp of the commit rather than the original file time or the
checkout time. This permits a faster production resolution of when changes
were run through the system as a group. I have implemented this strategy
(somewhat grudgingly) in a few places. It is a possible desire for some
users. I particularly dislike this approach because merge/cherry-pick/rebase
can mess with the preceptive "when" of a change and if you are going to do
this, make sure that your metadata is suitably managed.

3. Original file times - as Peter asked, storing the original file time has
some legacy advantages. This emulates the behaviour of some legacy SCM
systems and makes people feel better about things. From an audit point of
view, this has value for systems other than git. In git, you use the
hash-object to figure out what the file really is, so there is no real audit
need anymore for timestamps, which can be spoofed at whim anyway. The
hash-object comment applies to 2 also. Same comment here for dealing with
non-touching but modifying. For example: what is the timestamp on a
merge-squash? I would contend that it is the time of the merge-squash, not
the original time. It could also be an interim term, when a conflict was
resolved.

Just remember that #2 and #3 break #1, unless you essentially rebuild from
scratch in every build (ant/maven models). With that said, I seen many repo
admins who want all of the above, so making them all available would make
their lives easier.

My $0.02. Cheers,
Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(2112884442)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

Git 2.16.2 on NonStop Test Status

[Randall S. Becker]

Just letting you know that we are one breakage reduced from 2.16.1. Now at 3
total (1308:23, 1404:52, 9001:134) - all of which were expected. Nice work.

Cheers,
Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(2112884442)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

On February 7, 2018 11:53 AM, Andreas Schwab wrote:
> On Feb 06 2018, "Randall S. Becker" <rsbec...@nexbridge.com> wrote:
> 
> > What I don't know - and it's not explicitly in the CVE - is just how
> > many other terminal types with similar vulnerabilities are out there,
> > but I'm suspecting it's larger than one would guess - mostly, it seems
> > like this particular sequence is intended to be used for writing
> > status line output (line 25?) instead of sticking it in a prompt. This
> > can be used prettifies a lengthy bash prompt to display the current
> > branch and repository at the bottom of the screen instead of in the
> > inline prompt, but that's the user's choice and not something git has
> > to deal with. There were some green-screen terminals with other weird
> > ESC sequences back in the day that could really get into trouble with
> > this, including loading/executing programs in terminal memory via
> > output - really. I'm sure it seemed like a good idea at the time, but I
can see
> how it could have been used for evil.
> 
> Do you also want to block "+++AT"?  :-)

Oh dear. Oh dear. You *do* know that actually could be bad. I wonder how
many git users are still using dial-up to clone/push. Of course, they would
probably not even see this message after trying to download it.

Chuckles,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

On February 5, 2018 3:43 PM, Jonathan Nieder wrote:
> 
> Salvatore Bonaccorso wrote[1]:
> 
> > the following vulnerability was published for git.
> >
> > CVE-2018-121[0]:
> > |client prints server sent ANSI escape codes to the terminal, allowing
> > |for unverified messages to potentially execute arbitrary commands
> >
> > Creating this bug to track the issue in the BTS. Apparently the CVE
> > was sssigned without notifying/discussing it with upstream, at least
> > according to [1].
> >
> > If you fix the vulnerability please also make sure to include the CVE
> > (Common Vulnerabilities & Exposures) id in your changelog entry.
> >
> > For further information see:
> >
> > [0] https://security-tracker.debian.org/tracker/CVE-2018-121
> > https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2018-121
> > [1] https://bugzilla.novell.com/show_bug.cgi?id=1079389#c1
> 
> Thanks.  Upstream was notified about this and we dropped the ball on
> passing it on to a more public forum.  Sorry about that.
> 
> I'd be interested in your advice on this.  There are cases where the user
may
> *want* ANSI escape codes to be passed through without change and other
> cases where the user doesn't want that.  Commands like "git diff" pass
their
> output through a pager by default, which itself may or may not sanitize
the
> output.
> 
> In other words, there are multiple components at play:
> 
>  1. A terminal.  IMHO, it is completely inexcusable these days for a
> terminal to allow arbitrary code execution by writing output to
> it.  If bugs of that kind still exist, I think we should fix them
> (and perhaps even make it a requirement in Debian policy to make
> the expectations clear for new terminals).
> 
> That said, for defense in depth, it can be useful to also guard
> against this kind of issue in other components.  In particular:
> 
>  2. A pager.  Are there clear guidelines for what it is safe and not
> safe for a pager to write to a terminal?
> 
> "less -R" tries to only allow ANSI "color" escape sequences
> through but I wouldn't be surprised if there are some cases it
> misses.
> 
>  3. Output formats.  Some git commands are designed for scripting
> and do not have a sensible way to sanitize their output without
> breaking scripts.  Fortunately, in the case of "git diff", git
> has a notion of a "binary patch" where everything is sanitized,
> at the cost of the output being unreadable to a human (email-safe
> characters but not something that a human can read at a glance).
> So if we know what sequences to avoid writing to stdout, then we
> can treat files with those sequences as binary.
> 
> Pointers welcome.

One possible (albeit brute force) approach, in dealing with the specifics of
this CVE, may be to explicitly translate ESC-] into BLANK-], leaving a
potential attack visible but ineffective. This only addresses the attack
vector documented in the particular CVE but it can be done efficiently. The
sequence does not appear significant in ANSI - the CVE documents the xterm
situation.  Checking very old termcap, the impact would be on unfiltering
emulations derived (this is a sample) from nec 5520, freedom 100, Sun
workstations sun-s/-e-s, fortune, etc. Based on the seemingly limited use of
this sequence, having a config item may be overkill, but it could be set
enabled by default.

What I don't know - and it's not explicitly in the CVE - is just how many
other terminal types with similar vulnerabilities are out there, but I'm
suspecting it's larger than one would guess - mostly, it seems like this
particular sequence is intended to be used for writing status line output
(line 25?) instead of sticking it in a prompt. This can be used prettifies a
lengthy bash prompt to display the current branch and repository at the
bottom of the screen instead of in the inline prompt, but that's the user's
choice and not something git has to deal with. There were some green-screen
terminals with other weird ESC sequences back in the day that could really
get into trouble with this, including loading/executing programs in terminal
memory via output - really. I'm sure it seemed like a good idea at the time,
but I can see how it could have been used for evil.

A more general solution might be to permit the configuration of a list of
blocked character sequences and apply those as a filter. Something like
core.filter-mask="\E]", "\EA".

Just my $0.02 ramblings.

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

On February 1, 2018 3:08 PM, Brandon Williams wrote:
> On 02/01, Randall S. Becker wrote:
> > On February 1, 2018 1:58 PM, Stefan Beller wrote:
> > > On Thu, Feb 1, 2018 at 10:48 AM, Jeff Hostetler
> > > <g...@jeffhostetler.com>
> > > wrote:
> > > >
> > > >
> > > > On 1/2/2018 7:18 PM, Brandon Williams wrote:
> > > >>
> > > >> Introduce git-serve, the base server for protocol version 2.
> > > >>
> > > >> Protocol version 2 is intended to be a replacement for Git's
> > > >> current wire protocol.  The intention is that it will be a
> > > >> simpler, less wasteful protocol which can evolve over time.
> > > >>
> > > >> Protocol version 2 improves upon version 1 by eliminating the
> > > >> initial ref advertisement.  In its place a server will export a
> > > >> list of capabilities and commands which it supports in a
> > > >> capability advertisement.  A client can then request that a
> > > >> particular command be executed by providing a number of
> > > >> capabilities and command specific parameters.  At the completion
> > > >> of a command, a client can request that another command be
> > > >> executed or can terminate the connection by sending a flush packet.
> > > >>
> > > >> Signed-off-by: Brandon Williams <bmw...@google.com>
> > > >> ---
> > > >>   .gitignore  |   1 +
> > > >>   Documentation/technical/protocol-v2.txt |  91 
> > > >>   Makefile|   2 +
> > > >>   builtin.h   |   1 +
> > > >>   builtin/serve.c |  30 
> > > >>   git.c   |   1 +
> > > >>   serve.c | 239
> > > >> 
> > > >>   serve.h |  15 ++
> > > >>   8 files changed, 380 insertions(+)
> > > >>   create mode 100644 Documentation/technical/protocol-v2.txt
> > > >>   create mode 100644 builtin/serve.c
> > > >>   create mode 100644 serve.c
> > > >>   create mode 100644 serve.h
> > > >>
> > > >> diff --git a/.gitignore b/.gitignore index 833ef3b0b..2d0450c26
> > > >> 100644
> > > >> --- a/.gitignore
> > > >> +++ b/.gitignore
> > > >> @@ -140,6 +140,7 @@
> > > >>   /git-rm
> > > >>   /git-send-email
> > > >>   /git-send-pack
> > > >> +/git-serve
> > > >>   /git-sh-i18n
> > > >>   /git-sh-i18n--envsubst
> > > >>   /git-sh-setup
> > > >> diff --git a/Documentation/technical/protocol-v2.txt
> > > >> b/Documentation/technical/protocol-v2.txt
> > > >> new file mode 100644
> > > >> index 0..b87ba3816
> > > >> --- /dev/null
> > > >> +++ b/Documentation/technical/protocol-v2.txt
> > > >> @@ -0,0 +1,91 @@
> > > >> + Git Wire Protocol, Version 2
> > > >> +==
> > > >> +
> > > >> +This document presents a specification for a version 2 of Git's
> > > >> +wire protocol.  Protocol v2 will improve upon v1 in the following
> ways:
> > > >> +
> > > >> +  * Instead of multiple service names, multiple commands will be
> > > >> +supported by a single service.
> > > >> +  * Easily extendable as capabilities are moved into their own
section
> > > >> +of the protocol, no longer being hidden behind a NUL byte and
> > > >> +limited by the size of a pkt-line (as there will be a single
> > > >> +capability per pkt-line).
> > > >> +  * Separate out other information hidden behind NUL bytes (e.g.
> agent
> > > >> +string as a capability and symrefs can be requested using
> > > >> + 'ls-refs')
> > > >> +  * Reference advertisement will be omitted unless explicitly
> > > >> + requested
> > > >> +  * ls-refs command to explicitly request some refs
> > > >> +
> > > >> + Detailed Design
> > > >> +=
> > > >> +
> > > >> +A client can request to speak protocol v2 by se

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

[Randall S. Becker]

On February 1, 2018 1:58 PM, Stefan Beller wrote:
> On Thu, Feb 1, 2018 at 10:48 AM, Jeff Hostetler 
> wrote:
> >
> >
> > On 1/2/2018 7:18 PM, Brandon Williams wrote:
> >>
> >> Introduce git-serve, the base server for protocol version 2.
> >>
> >> Protocol version 2 is intended to be a replacement for Git's current
> >> wire protocol.  The intention is that it will be a simpler, less
> >> wasteful protocol which can evolve over time.
> >>
> >> Protocol version 2 improves upon version 1 by eliminating the initial
> >> ref advertisement.  In its place a server will export a list of
> >> capabilities and commands which it supports in a capability
> >> advertisement.  A client can then request that a particular command
> >> be executed by providing a number of capabilities and command
> >> specific parameters.  At the completion of a command, a client can
> >> request that another command be executed or can terminate the
> >> connection by sending a flush packet.
> >>
> >> Signed-off-by: Brandon Williams 
> >> ---
> >>   .gitignore  |   1 +
> >>   Documentation/technical/protocol-v2.txt |  91 
> >>   Makefile|   2 +
> >>   builtin.h   |   1 +
> >>   builtin/serve.c |  30 
> >>   git.c   |   1 +
> >>   serve.c | 239
> >> 
> >>   serve.h |  15 ++
> >>   8 files changed, 380 insertions(+)
> >>   create mode 100644 Documentation/technical/protocol-v2.txt
> >>   create mode 100644 builtin/serve.c
> >>   create mode 100644 serve.c
> >>   create mode 100644 serve.h
> >>
> >> diff --git a/.gitignore b/.gitignore
> >> index 833ef3b0b..2d0450c26 100644
> >> --- a/.gitignore
> >> +++ b/.gitignore
> >> @@ -140,6 +140,7 @@
> >>   /git-rm
> >>   /git-send-email
> >>   /git-send-pack
> >> +/git-serve
> >>   /git-sh-i18n
> >>   /git-sh-i18n--envsubst
> >>   /git-sh-setup
> >> diff --git a/Documentation/technical/protocol-v2.txt
> >> b/Documentation/technical/protocol-v2.txt
> >> new file mode 100644
> >> index 0..b87ba3816
> >> --- /dev/null
> >> +++ b/Documentation/technical/protocol-v2.txt
> >> @@ -0,0 +1,91 @@
> >> + Git Wire Protocol, Version 2
> >> +==
> >> +
> >> +This document presents a specification for a version 2 of Git's wire
> >> +protocol.  Protocol v2 will improve upon v1 in the following ways:
> >> +
> >> +  * Instead of multiple service names, multiple commands will be
> >> +supported by a single service.
> >> +  * Easily extendable as capabilities are moved into their own section
> >> +of the protocol, no longer being hidden behind a NUL byte and
> >> +limited by the size of a pkt-line (as there will be a single
> >> +capability per pkt-line).
> >> +  * Separate out other information hidden behind NUL bytes (e.g. agent
> >> +string as a capability and symrefs can be requested using
> >> + 'ls-refs')
> >> +  * Reference advertisement will be omitted unless explicitly
> >> + requested
> >> +  * ls-refs command to explicitly request some refs
> >> +
> >> + Detailed Design
> >> +=
> >> +
> >> +A client can request to speak protocol v2 by sending `version=2` in
> >> +the side-channel `GIT_PROTOCOL` in the initial request to the server.
> >> +
> >> +In protocol v2 communication is command oriented.  When first
> >> +contacting
> >> a
> >> +server a list of capabilities will advertised.  Some of these
> >> capabilities
> >> +will be commands which a client can request be executed.  Once a
> >> +command has completed, a client can reuse the connection and request
> >> +that other commands be executed.
> >> +
> >> + Special Packets
> >> +-
> >> +
> >> +In protocol v2 these special packets will have the following semantics:
> >> +
> >> +  * '' Flush Packet (flush-pkt) - indicates the end of a message
> >> +  * '0001' Delimiter Packet (delim-pkt) - separates sections of a
> >> + message
> >
> >
> > Previously, a 0001 pkt-line meant that there was 1 byte of data
> > following, right?
> 
> No, the length was including the length field, so 0005 would indicate that
> there is one byte following, (+4 bytes of "0005" included)
> 
> > Does this change that and/or prevent 1 byte packets?  (Not sure if it
> > is likely, but the odd-tail of a packfile might get sent in a 0001
> > line, right?)  Or is it that 0001 is only special during the V2
> > negotiation stuff, but not during the packfile transmission?
> 
> 0001 is invalid in the current protocol v0.
> 
> >
> > (I'm not against having this delimiter -- I think it is useful, but
> > just curious if will cause problems elsewhere.)
> >
> > Should we also consider increasing the pkt-line limit to 5 hex-digits
> > while we're at it ?   That would let us have 1MB buffers if that would
> > help 

RE: Shawn Pearce has died

[Randall S. Becker]

On January 30, 2018 1:49 PM, Jeff King
@vger.kernel.org; sc...@gasch.org
> Subject: Re: Shawn Pearce has died
> On Mon, Jan 29, 2018 at 11:15:55PM -0800, Chris DiBona wrote:
> > That's a fantastic idea.  When is the contrib summit and is it open to
> > others? I could send someone ...
> 
> It's March 7th in Barcelona. Details are here:
> 
>   https://public-inbox.org/git/20180119001034.ga29...@sigill.intra.peff.net/
> 
> There will be GitHub video folks on premises the following day for the Git
> Merge main conference, but I'm looking into whether they'll be around to
> record a few interviews on the contributor summit day.

On behalf of git's NonStop platform team, ITUGLIB,  we want to express our 
sorrow for the loss of Shawn to the community, his friends, colleagues, and 
family. We take a small amount of solace in that his footprints will remain 
with us forever.

Sincerest Condolences,
Randall

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

RE: Missing ? wildcard character in gitignore documentation

[Randall S. Becker]

On January 29, 2018 6:30 AM, Jack F wrote:
> I have just noticed that the documentation for gitignore is missing
> documentation on using the ? to match any single character. I have included
> a example below with git version 2.14.1.
> 
> |11:05:09 j ~/Development/ls-ignore [master] $ git status On branch
> master Your branch is up-to-date with 'origin/master'. nothing to commit,
> working tree clean 11:05:11 j ~/Development/ls-ignore [master] $ cat
> .gitignore *~ node_modules yarn* 11:05:21 j ~/Development/ls-ignore
> [master] $ touch test.swo 11:05:31 j ~/Development/ls-ignore [master]?1 $
> git status On branch master Your branch is up-to-date with 'origin/master'.
> Untracked files: (use "git add ..." to include in what will be 
> committed)
> test.swo nothing added to commit but untracked files present (use "git add"
> to track) 11:05:35 j ~/Development/ls-ignore [master]?1 $ echo "*.sw?" >>
> .gitignore 11:05:40 j ~/Development/ls-ignore [master]≠1 $ cat .gitignore *~
> node_modules
> yarn* *.sw? 11:05:51 j ~/Development/ls-ignore [master]≠1 $ git status On
> branch master Your branch is up-to-date with 'origin/master'. Changes not
> staged for commit: (use "git add ..." to update what will be
> committed) (use "git checkout -- ..." to discard changes in working
> directory) modified: .gitignore no changes added to commit (use "git add"
> and/or "git commit -a")|
> 
> 
> 
> Noticed it when checking an npm package (ignore) that uses the
> documentation (https://git-scm.com/docs/gitignore) to determine its
> functionality. It is documented in https://git-scm.com/book/en/v2/Git-
> Basics-Recording-Changes-to-the-Repository#Ignoring-Files

The implication of support for ? is there through the following paragraph from 
the gitignore documentation:

"Otherwise, Git treats the pattern as a shell glob suitable for consumption 
by fnmatch(3)
with the FNM_PATHNAME flag: wildcards in the pattern will not match a / in 
the
pathname. For example, "Documentation/*.html" matches 
"Documentation/git.html"
but not "Documentation/ppc/ppc.html" or 
"tools/perf/Documentation/perf.html"."

Of course you have to go read fnmatch(3), so it might be good for expand on 
this here :).

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

So the point here is that the jars are still in the repository. They are 
deleted in your branch, but any objects depending on others (without a lot more 
information on your exact repository structure) may cause packed objects to be 
sent upstream. The delete is local to your branch, but the delete does not mean 
the objects are actually removed from your repository. To actually effect a 
removal, the objects would need to be no longer accessible, thus git gc would 
remove them permanently. That may be difficult depending on security on your 
upstream repository and what you are able to do there. So:

A--- B--- C

If A has no jars, B has the jars and has A as its parent, and C has no jars, 
but has B as its parent, then B is still accessible and the jars still exist in 
the repository but only not at the HEAD of your branch. Your tree may vary. How 
a push gets objects from your repository to your upstream depends on more 
information that I have but the point is that the jars still exist in a 
distributed sense. Your repository state and the upstream repository state do 
not need to be (and are likely not) identical.

> -Original Message-
> From: Basin Ilya [mailto:basini...@gmail.com]
> Sent: January 25, 2018 10:08 AM
> To: Randall S. Becker <rsbec...@nexbridge.com>; git@vger.kernel.org
> Subject: Re: pushing a delete-only commit consumes too much traffic
> 
> > Were the 60Mb of jars previously pushed in a commit that already existed
> on the upstream?
> yes
> 
> > Was the delete an actual removal of history or did you commit with the jars
> deleted, then pushed?
> I committed with the jars deleted
> 
> > Did you do a merge squash or delete branch to effect the removal.
> No
> 
> 
> 
> 
> On 25.01.2018 17:24, Randall S. Becker wrote:
> > On January 25, 2018 9:15 AM, Basin Ilya wrote:
> >
> >> I had a 60Mb worth of unneeded jar files in the project. I created a
> >> new branch and performed `git rm` on them. Now while I was pushing
> >> the change the counter of sent data reached 80Mb. Why is that?
> >
> > Can you provide more info? Were the 60Mb of jars previously pushed in a
> commit that already existed on the upstream? Was the delete an actual
> removal of history or did you commit with the jars deleted, then pushed? Did
> you do a merge squash or delete branch to effect the removal. More info
> please.
> >
> > Cheers,
> > Randall
> >
> > -- Brief whoami:
> >   NonStop developer since approximately NonStop(2112884442)
> >   UNIX developer since approximately 421664400
> > -- In my real life, I talk too much.
> >
> >
> >

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

[Randall S. Becker]

On January 25, 2018 9:15 AM, Basin Ilya wrote:

> I had a 60Mb worth of unneeded jar files in the project. I created a new
> branch and performed `git rm` on them. Now while I was pushing the change
> the counter of sent data reached 80Mb. Why is that?

Can you provide more info? Were the 60Mb of jars previously pushed in a commit 
that already existed on the upstream? Was the delete an actual removal of 
history or did you commit with the jars deleted, then pushed? Did you do a 
merge squash or delete branch to effect the removal. More info please.

Cheers,
Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(2112884442)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

On January 23, 2018 1:13 PM, Junio C Hamano wrote:
> 
> "Randall S. Becker" <rsbec...@nexbridge.com> writes:
> 
> >> IOW, I do not see it explained clearly why this change is needed on
> >> any single platform---so "that issue may be shared by others, too"
> >> is a bit premature thing for me to listen to and understand, as "that
> >> issue" is quite unclear to me.
> >
> > v4 might be a little better. The issue seems to be specific to NonStop
> > that it's PIPE mechanism needs to have setbuf(pipe,NULL) called for
> > git to be happy.  The default behaviour appears to be different on
> > NonStop from other platforms from our testing. We get hung up waiting
> > on pipes unless this is done.
> 
> I am afraid that that is not a "diagnosis" enough to allow us moving forward.
> We get hung up because...?  When the process that has the other end of
> pipe open exits, NonStop does not close the pipe properly?  Or NonStop
> does not flush the data buffered in the pipe?
> Would it help if a compat wrapper that does setbuf(fd, NULL) immediately
> before closing the fd, or some other more targetted mechanism, is used only
> on NonStop, for example?  Potentially megabytes of data can pass thru a
> pipe, and if the platform bug affects only at the tail end of the transfer,
> marking the pipe not to buffer at all at the beginning is too big a hammer to
> work it around.  With the explanation given so far, this still smells more 
> like
> "we have futzed around without understanding why, and this happens to
> work."  It may be good enough for your purpose of making progress (after
> all, I'd imagine that you'd need to work this around one way or another to
> hunt for and fix more issues on the platform), but it does not sound like "we
> know what the problem is, and this is the best workaround for that", which is
> what we want if it wants to become part of the official codebase.

As I feared, the test suite was unable to reproduce the issue without 
setbuf(NULL) - primary because the test structure ends up with both ends of the 
git dialogs on clone and fetch in the same CPU (even if different IPUs), which 
does not experience the issue and we can't loop-back through the platform's 
proprietary SSH. I am not comfortable releasing without it at this stage, but 
if you don't want to go forward with this fix, my team can run it for a few 
months internally in the hope that this works out for the better. The situation 
is timing related and is fine 99.98-ish% of the time. I really do want the 
setbuf present in any compiled versions that our community might get, primarily 
because I don't like sleepless nights chasing this down (again).

Cheers,
Randall

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

[Randall S. Becker]

> -Original Message-
> From: Todd Zullinger [mailto:t...@pobox.com]
> Sent: January 24, 2018 5:02 PM
> To: Junio C Hamano <gits...@pobox.com>
> Cc: randall.s.bec...@rogers.com; git@vger.kernel.org; Randall S. Becker
> <rsbec...@nexbridge.com>
> Subject: Re: [PATCH v4 1/4] Add tar extract install options override in
> installation processing.
> 
> Junio C Hamano wrote:
> > randall.s.bec...@rogers.com writes:
> >> +# Define TAR_EXTRACT_OPTIONS if you want to change the default
> >> +behaviour # from xvf to something else during installation. The
> >> +option only includes
>^^^
> Shouldn't this be xof?
> 
> >> +# "o" as xf are required.

Drats. Can this be changed here rather than reissuing? I will sign off on
the sticky finger typo.

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

[Randall S. Becker]

On January 24, 2018 4:18 PM, Junio C Hamano wrote:
> 
> "Randall S. Becker" <rsbec...@nexbridge.com> writes:
> 
> >> > +#ifdef __TANDEM
> >> > +#if !defined(_THREAD_SUPPORT_FUNCTIONS) &&
> >> !defined(_PUT_MODEL_)
> >> > +/* #include
> >> > +<floss.h(floss_read,floss_write,floss_fsync,floss_fork)>
> >> > +*/
> >> > +/* #include <floss.h(floss_fork)> */ #endif
> >>
> >> The above adds a conditional no-op?  That's confusing...
> >
> > We are trying to make PUT work with git on NonStop. I can't tell you
> > how much of a pain it is. This is a placeholder for others (outside
> > our group) to know where to muck. I can remove it if you don't want it
> there.
> 
> It is OK as long as it was done on purpose.  I was just making sure that
this
> was an unfinished WIP sent by mistake before proofreading.

Absolutely definitely positively on purpose and when it we get PUT working
in FLOSS, this is *so* going to happen. :-) 

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

[Randall S. Becker]

On January 24, 2018 3:36 PM, Junio C Hamano wrote:
> randall.s.bec...@rogers.com writes:
> 
> > From: "Randall S. Becker" <rsbec...@nexbridge.com>
> >
> > Add correct FLOSS (NonStop platform emulation) definitions into
> > git-compat-util.h to allow correct emulation of non-platform
> > behaviour. Also added NSIG definition that is not explicitly supplied
> > in signal.h on platform.
> >
> > Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
> > ---
> >  git-compat-util.h | 15 +++
> >  1 file changed, 15 insertions(+)
> >
> > diff --git a/git-compat-util.h b/git-compat-util.h index
> > 68b2ad531..fb3ef0dcf 100644
> > --- a/git-compat-util.h
> > +++ b/git-compat-util.h
> > @@ -378,6 +378,21 @@ static inline char *git_find_last_dir_sep(const
> > char *path)  #define find_last_dir_sep git_find_last_dir_sep  #endif
> >
> > +#ifdef __TANDEM
> > +#if !defined(_THREAD_SUPPORT_FUNCTIONS) &&
> !defined(_PUT_MODEL_)
> > +/* #include <floss.h(floss_read,floss_write,floss_fsync,floss_fork)>
> > +*/
> > +/* #include <floss.h(floss_fork)> */
> > +#endif
> 
> The above adds a conditional no-op?  That's confusing...

We are trying to make PUT work with git on NonStop. I can't tell you how
much of a pain it is. This is a placeholder for others (outside our group)
to know where to muck. I can remove it if you don't want it there.
 
> > +#include <floss.h(floss_execl,floss_execlp,floss_execv,floss_execvp)>
> > +#include <floss.h(floss_getpwuid)>
> > +#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

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

[Randall S. Becker]

On January 23, 2018 1:13 PM, Junio C Hamano wrote:
> "Randall S. Becker" <rsbec...@nexbridge.com> writes:
> 
> >> IOW, I do not see it explained clearly why this change is needed on
> >> any single platform---so "that issue may be shared by others, too"
> >> is a bit premature thing for me to listen to and understand, as "that
> >> issue" is quite unclear to me.
> >
> > v4 might be a little better. The issue seems to be specific to NonStop
> > that it's PIPE mechanism needs to have setbuf(pipe,NULL) called for
> > git to be happy.  The default behaviour appears to be different on
> > NonStop from other platforms from our testing. We get hung up waiting
> > on pipes unless this is done.
> 
> I am afraid that that is not a "diagnosis" enough to allow us moving forward.
> We get hung up because...?  When the process that has the other end of
> pipe open exits, NonStop does not close the pipe properly?  Or NonStop
> does not flush the data buffered in the pipe?
> Would it help if a compat wrapper that does setbuf(fd, NULL) immediately
> before closing the fd, or some other more targetted mechanism, is used only
> on NonStop, for example?  Potentially megabytes of data can pass thru a
> pipe, and if the platform bug affects only at the tail end of the transfer,
> marking the pipe not to buffer at all at the beginning is too big a hammer to
> work it around.  With the explanation given so far, this still smells more 
> like
> "we have futzed around without understanding why, and this happens to
> work."  It may be good enough for your purpose of making progress (after
> all, I'd imagine that you'd need to work this around one way or another to
> hunt for and fix more issues on the platform), but it does not sound like "we
> know what the problem is, and this is the best workaround for that", which is
> what we want if it wants to become part of the official codebase.

I am retesting without setbuf(NULL) but this is unlikely to be enlightening. 
The test cases do not adequately simulate the configuration in which my team 
originally encountered the problem. This requires a guarantee of the source and 
destination coming through different logical CPUs. We never encountered the 
issue in the test suite, only when end users got hold of it. We had two 
distinct problems, one which was the revent=0 related hang (already solved) and 
other was a stream flush problem. The two are related but distinct. The 
platform support group insisted that we should have the setbuf(NULL) in place 
for interprocess communications in the form used here - I'm worried about 
losing this, but completely aware that this is far too heavy for other 
platforms (hence the __TANDEM guard in wrapper.c). If the form of the wrapper 
should be different, I would be happy to comply.

I have a much longer explanation about the platform message stack structure, 
but that doesn't belong here. Happy to respond privately if requested.

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

RE: [Nit] Lots of enumerated type warnings

[Randall S. Becker]

On January 22, 2018 6:44 PM, Junio C Hamano wrote:
> 
> "Randall S. Becker" <rsbec...@nexbridge.com> writes:
> 
> > Here are a few examples, there are more:
> >
> > auto_crlf = git_config_bool(var, value);
> >   ^
> 
> The carets in your message do not align to what I think they are trying to
> point at, but I think the above is pointing at the '=' and wants to say
> "auto_crlf variable is enum, it gets assigned an integer returned from
> git_config_bool(), and I do not like that assignment".
> 
> For this one I tend to agree with the compiler, meaning that it is ugly to
> define "enum auto_crlf" in such a way that the first two values happen to
> match what a logically different "enum" (which is
> "boolean") assigns the two values to.  And this judgment does not change
> whether git_config_bool() actually returns an enum or an int (the code in
> reality returns the latter).
> 
> I do not think people would terribly mind a patch to turn the above
> into:
> 
>   auto_crlf = git_config_bool(var, value) ? AUTO_CRLF_FALSE :
> AUTO_CRLF_TRUE;
> 
> > "/home/jenkins/.jenkins/workspace/Build_Git/config.c", line 1147:
> > warning(272):
> >   enumerated type mixed with another type
> >
> > type = sha1_object_info(s->oid.hash, >size);
> >  ^
> 
> /* returns enum object_type or negative */ int sha1_object_info(const
> unsigned char *sha1, unsigned long *sizep)
> 
> The function has been like this forever, I suspect, and I would say "this
gives
> negative when error, or enum we know is non-negative" is quite a
> reasonable thing to do, but the enum has OBJ_BAD defined to be negative,
> so probably it is more kosher if sha1_object_info() is declared to return
> "enum object_type" instead of int.
> 
> > "/home/jenkins/.jenkins/workspace/Build_Git/diff.c", line 3618:
> > warning(272):
> >   enumerated type mixed with another type
> >
> > options->color_moved = diff_color_moved_default;
> >  ^
> 
> If color_moved field is declared to be an enum, the _default variable
should
> be, too.  I do not think it is such a controversial fix.

The basic idea of the request is whether to slowly take on this type of
change. It will likely take a bit of time, but I really don't like warnings,
so am willing to work on it. There are loads more like this that might need
discussion, so I'll be pretty conservative on this effort.

Cheers,
Randall

RE: [Nit] Lots of enumerated type warnings

[Randall S. Becker]

On January 22, 2018 5:41 PM, Junio C Hamano wrote:
> "Randall S. Becker" <rsbec...@nexbridge.com> writes:
> 
> > I'm seeing an increase in the enumerated type warnings coming from my
> > use of the c99 compiler for compiling git over time (loads more for
> > 2.16.0 compared to 2.3.7 when I took it on).
> 
> What exactly do these "warnings" complain about?  Without knowing that,
> the remainder of your question cannot be answered.
> 
> Does it complain against enum FOO {A,B,C,} saying that the comma after C
is
> not kosher in older C standard, for example?

Here are a few examples, there are more:

auto_crlf = git_config_bool(var, value);
  ^
"/home/jenkins/.jenkins/workspace/Build_Git/config.c", line 1147:
warning(272): 
  enumerated type mixed with another type

type = sha1_object_info(s->oid.hash, >size);
 ^
"/home/jenkins/.jenkins/workspace/Build_Git/diff.c", line 3618:
warning(272): 
  enumerated type mixed with another type

options->color_moved = diff_color_moved_default;
 ^
"/home/jenkins/.jenkins/workspace/Build_Git/diff.c", line 4108:
warning(272): 
  enumerated type mixed with another type

options->color_moved = 0;
 ^
"/home/jenkins/.jenkins/workspace/Build_Git/diff.c", line 4218:
warning(272): 
  enumerated type mixed with another type

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

[Randall S. Becker]

On January 22, 2018 5:36 PM, Junio C Hamano wrote:
> Torsten Bögershausen <tbo...@web.de> writes:
> 
> > On Fri, Jan 19, 2018 at 12:33:59PM -0500, randall.s.bec...@rogers.com
> wrote:
> >> From: "Randall S. Becker" <rsbec...@nexbridge.com>
> >>
> >> * wrapper.c: called setbuf(stream,0) to force pipe flushes not enabled by
> >>   default on the NonStop platform.
> >>
> >> Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
> >> ---
> >>  wrapper.c | 3 +++
> >>  1 file changed, 3 insertions(+)
> >>
> >> diff --git a/wrapper.c b/wrapper.c
> >> index d20356a77..671cbb4b4 100644
> >> --- a/wrapper.c
> >> +++ b/wrapper.c
> >> @@ -403,6 +403,9 @@ FILE *xfdopen(int fd, const char *mode)
> >>FILE *stream = fdopen(fd, mode);
> >>if (stream == NULL)
> >>die_errno("Out of memory? fdopen failed");
> >> +#ifdef __TANDEM
> >> +  setbuf(stream,0);
> >> +#endif
> >
> > Reading the commit message, I would have expected someting similar to
> >
> > #ifdef FORCE_PIPE_FLUSHES
> > setbuf(stream,0);
> > #endif
> >
> > (Because other systems may need the tweak as well, some day) Of course
> > you need to change that in the Makefile and config.mak.uname
> 
> I actually wouldn't have expected anything like that after reading the commit
> message.
> 
> First I thought it was describing only what it does (i.e. "let's use
> setbuf() to set the stream unbuffered on TANDEM"), which is a useless
> description that only says what it does which we can read from the diff, but
> "NonStop by default creates pipe that does not flush" is a potentially useful
> information the log message adds.
> But it is just "potentially"---we cannot read what exact problem the change is
> trying to address.  Making a pipe totally unbuffered is a heavy hammer that
> may not be an appropriate solution---it could be that we are missing calls to
> fflush() where we need and have been lucky because most of the systems
> we deal with do line-buffered by default, or something silly/implausible like
> that, and if that is the case, a more proper fix may be to add these missing
> fflush() to right places.
> 
> IOW, I do not see it explained clearly why this change is needed on any single
> platform---so "that issue may be shared by others, too"
> is a bit premature thing for me to listen to and understand, as "that issue" 
> is
> quite unclear to me.

v4 might be a little better. The issue seems to be specific to NonStop that 
it's PIPE mechanism needs to have setbuf(pipe,NULL) called for git to be happy. 
The default behaviour appears to be different on NonStop from other platforms 
from our testing. We get hung up waiting on pipes unless this is done. At the 
moment, this is platform-specific. Other parts of the discussion led to the 
conclusion that we should make this available to any platform using a new 
configuration option, but my objective is to get the NonStop port integrated 
with the main git code base and when my $DAYJOB permits it, spend the time 
adding the option. Note: __TANDEM is #define automatically emitted by the 
NonStop compilers. 

Does that help?

Sincerely,
Randall

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

[randall . s . becker]

From: "Randall S. Becker" <rsbec...@nexbridge.com>

Upgrade old options in config.mak.uname to currently supported
NonStop operating system versions (J06.21 and L17.xx).

Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
---
 config.mak.uname | 29 +
 1 file changed, 21 insertions(+), 8 deletions(-)

diff --git a/config.mak.uname b/config.mak.uname
index 685a80d13..d9f8d57e3 100644
--- a/config.mak.uname
+++ b/config.mak.uname
@@ -428,27 +428,37 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
# INLINE='' would just replace one set of warnings with another and
# still not compile in c89 mode, due to non-const array initializations.
CC = cc -c99
+   # Build down-rev compatible objects that don't use our new getopt_long.
+   ifeq ($(uname_R).$(uname_V),J06.21)
+   CC += -WRVU=J06.20
+   endif
+   ifeq ($(uname_R).$(uname_V),L17.02)
+   CC += -WRVU=L16.05
+   endif
# Disable all optimization, seems to result in bad code, with -O or -O2
# or even -O1 (default), /usr/local/libexec/git-core/git-pack-objects
# abends on "git push". Needs more investigation.
-   CFLAGS = -g -O0
+   CFLAGS = -g -O0 -Winline
# We'd want it to be here.
prefix = /usr/local
# Our's are in ${prefix}/bin (perl might also be in /usr/bin/perl).
-   PERL_PATH = ${prefix}/bin/perl
-   PYTHON_PATH = ${prefix}/bin/python
-
+   PERL_PATH = /usr/bin/perl
+   PYTHON_PATH = /usr/bin/python
+   RM = /bin/rm -f
# As detected by './configure'.
# Missdetected, hence commented out, see below.
#NO_CURL = YesPlease
# Added manually, see above.
NEEDS_SSL_WITH_CURL = YesPlease
+   NEEDS_CRYPTO_WITH_SSL = YesPlease
+   HAVE_DEV_TTY = YesPlease
HAVE_LIBCHARSET_H = YesPlease
HAVE_STRINGS_H = YesPlease
NEEDS_LIBICONV = YesPlease
NEEDS_LIBINTL_BEFORE_LIBICONV = YesPlease
NO_SYS_SELECT_H = UnfortunatelyYes
NO_D_TYPE_IN_DIRENT = YesPlease
+   NO_GETTEXT = YesPlease
NO_HSTRERROR = YesPlease
NO_STRCASESTR = YesPlease
NO_MEMMEM = YesPlease
@@ -458,8 +468,13 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
NO_MKDTEMP = YesPlease
# Currently libiconv-1.9.1.
OLD_ICONV = UnfortunatelyYes
-   NO_REGEX = YesPlease
+   NO_REGEX=NeedsStartEnd
NO_PTHREADS = UnfortunatelyYes
+   ifdef NO_PTHREADS
+   else # WIP, use Posix User Threads
+   PTHREAD_CFLAGS = -D_PUT_MODEL_ -I/usr/include
+   PTHREAD_LIBS = -lput
+   endif
 
# Not detected (nor checked for) by './configure'.
# We don't have SA_RESTART on NonStop, unfortunalety.
@@ -477,9 +492,7 @@ ifeq ($(uname_S),NONSTOP_KERNEL)
# RFE 10-120912-4693 submitted to HP NonStop development.
NO_SETITIMER = UnfortunatelyYes
SANE_TOOL_PATH = /usr/coreutils/bin:/usr/local/bin
-   SHELL_PATH = /usr/local/bin/bash
-   # as of H06.25/J06.14, we might better use this
-   #SHELL_PATH = /usr/coreutils/bin/bash
+   SHELL_PATH = /usr/coreutils/bin/bash
 endif
 ifneq (,$(findstring MINGW,$(uname_S)))
pathsep = ;
-- 
2.16.0.31.gf1a482c

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

[randall . s . becker]

From: "Randall S. Becker" <rsbec...@nexbridge.com>

Add correct FLOSS (NonStop platform emulation) definitions into
git-compat-util.h to allow correct emulation of non-platform
behaviour. Also added NSIG definition that is not explicitly
supplied in signal.h on platform.

Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
---
 git-compat-util.h | 15 +++
 1 file changed, 15 insertions(+)

diff --git a/git-compat-util.h b/git-compat-util.h
index 68b2ad531..fb3ef0dcf 100644
--- a/git-compat-util.h
+++ b/git-compat-util.h
@@ -378,6 +378,21 @@ static inline char *git_find_last_dir_sep(const char *path)
 #define find_last_dir_sep git_find_last_dir_sep
 #endif
 
+#ifdef __TANDEM
+#if !defined(_THREAD_SUPPORT_FUNCTIONS) && !defined(_PUT_MODEL_)
+/* #include <floss.h(floss_read,floss_write,floss_fsync,floss_fork)> */
+/* #include <floss.h(floss_fork)> */
+#endif
+#include <floss.h(floss_execl,floss_execlp,floss_execv,floss_execvp)>
+#include <floss.h(floss_getpwuid)>
+#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.16.0.31.gf1a482c

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

[randall . s . becker]

From: "Randall S. Becker" <rsbec...@nexbridge.com>

Call setbuf(stream,NULL) to force pipe flushes not enabled by
default on the NonStop platform in wrapper.c. This may be extended
in future to a configure option.

Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
---
 wrapper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/wrapper.c b/wrapper.c
index d20356a77..5b05a9162 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -403,6 +403,9 @@ FILE *xfdopen(int fd, const char *mode)
FILE *stream = fdopen(fd, mode);
if (stream == NULL)
die_errno("Out of memory? fdopen failed");
+#ifdef __TANDEM
+   setbuf(stream,NULL);
+#endif
return stream;
 }
 
-- 
2.16.0.31.gf1a482c

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

[randall . s . becker]

From: "Randall S. Becker" <rsbec...@nexbridge.com>

Fix missing intptr_t on NonStop in compat/regex/regcomp.c wrapped
using the __TANDEM guard define. This is done because
git-compat-util.h cannot be cleanly included into this file
without additional compile errors.

Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
---
 compat/regex/regcomp.c | 8 
 1 file changed, 8 insertions(+)

diff --git a/compat/regex/regcomp.c b/compat/regex/regcomp.c
index 51cd60baa..8bb4c966d 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.16.0.31.gf1a482c

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

[randall . s . becker]

From: "Randall S. Becker" <rsbec...@nexbridge.com>

Introduced TAR_EXTRACT_OPTIONS as a configuration option to change
the options of tar processing during extract. The default value is "o"
which synthesizes xof, by default.

Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
---
 Makefile | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/Makefile b/Makefile
index 1a9b23b67..78ee431b7 100644
--- a/Makefile
+++ b/Makefile
@@ -429,6 +429,10 @@ all::
 # running the test scripts (e.g., bash has better support for "set -x"
 # tracing).
 #
+# Define TAR_EXTRACT_OPTIONS if you want to change the default behaviour
+# from xvf to something else during installation. The option only includes
+# "o" as xf are required.
+#
 # When cross-compiling, define HOST_CPU as the canonical name of the CPU on
 # which the built Git will run (for instance "x86_64").
 
@@ -452,6 +456,7 @@ LDFLAGS =
 ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
 ALL_LDFLAGS = $(LDFLAGS)
 STRIP ?= strip
+TAR_EXTRACT_OPTIONS = o
 
 # Create as necessary, replace existing, make ranlib unneeded.
 ARFLAGS = rcs
@@ -2569,7 +2574,7 @@ install: all
 ifndef NO_GETTEXT
$(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(localedir_SQ)'
(cd po/build/locale && $(TAR) cf - .) | \
-   (cd '$(DESTDIR_SQ)$(localedir_SQ)' && umask 022 && $(TAR) xof -)
+   (cd '$(DESTDIR_SQ)$(localedir_SQ)' && umask 022 && $(TAR) 
x$(TAR_EXTRACT_OPTIONS)f -)
 endif
 ifndef NO_PERL
$(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)' install
-- 
2.16.0.31.gf1a482c

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

[Randall S. Becker]

On January 19, 2018 5:29 PM, I wrote:
> On January 19, 2018 4:27 PM, Jeff King wrote:
> > On Fri, Jan 19, 2018 at 12:34:04PM -0500, randall.s.bec...@rogers.com
> wrote:
> >
> > > From: "Randall S. Becker" <rsbec...@nexbridge.com>
> > >
> > > * t/lib-git-daemon.sh: fix incompatibilities with ksh traps not being
> > >   cleared automatically on platform. This caused tests to seem to fail
> > >   while actually succeeding.
> > >
> > > Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
> > > ---
> > >  t/lib-git-daemon.sh | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh index
> > > 987d40680..955beecd9 100644
> > > --- a/t/lib-git-daemon.sh
> > > +++ b/t/lib-git-daemon.sh
> > > @@ -68,6 +68,7 @@ start_git_daemon() {
> > >   test_skip_or_die $GIT_TEST_GIT_DAEMON \
> > >   "git daemon failed to start"
> > >   fi
> > > + trap '' EXIT
> > >  }
> >
> > I don't think this can be right. The way these traps are supposed to work 
> > is:
> >
> >   - as soon as test-lib.sh is loaded, we "trap die EXIT" to catch an
> > accidental death/exit from one of the scripts
> >
> >   - when test_done is called, we clear the trap (i.e., it is OK to exit
> > now because the script has given us a positive indication that all
> > tests have been run)
> >
> >   - while the child git-daemon is running, we'd want to clean up after
> > ourselves. So during start_git_daemon() we add our cleanup (followed
> > by the original "die", because shell traps don't push onto a stack).
> > And then at stop_git_daemon(), we restore the original die trap.
> >
> > But this patch means that while git-daemon is running, we have no trap at
> all!
> > That means that a failed test which causes us to exit would leave a
> > child daemon running.
> >
> > Furthermore, both of these functions now drop the 'die' trap entirely,
> > meaning the script would fail to notice premature exit from one of the
> > test snippets.
> >
> > So while this may be papering over a problem on NonStop, I think it's
> > breaking the intent of the traps.
> >
> > I'm not sure what the root of the problem is, but it sounds like ksh
> > may be triggering EXIT traps when we don't expect (during function
> returns?
> > Subshell exits? Other?)
> 
> The "unexpected" EXIT traps are exactly the issue we found when working
> with the platform support team. There was some discussion about what the
> right expectation was, and I was not able to have a change made to ksh on
> the platform. The problem may have a similar (identical?) root cause to the
> Perl exit issues we are also experiencing that is in their hands. I'm 
> currently
> retesting without this change (results in 36 hours ☹ ). Is there a preferred
> way you would like me to bypass this except on NonStop? I can add a check
> based on uname.

After running through the git test suite, it turns out that this particular 
need has gone away as of the latest OS releases. The test results without the 
trap '' EXIT are identical to that with the trap (6 breaks that look completion 
code handling-related on the platform). I'm going to drop the need for this and 
repackage the entire set of patches applying everyone's comments and removing 
this (4/6) and the GCC attribute (1/6) patch. This will be followed-up with 
generalizing the setbuf and tar patches for a broader audience, but I need a 
bit more time for that generalization.

Please accept my thanks and expect the updated set tomorrow, which will be 
sufficient to bring the NonStop NSE, NSX, and NSV platforms into the common 
code-base for git at long last.

Cheers,
Randall

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

[Randall S. Becker]

On January 20, 2018 3:34 PM, Ævar Arnfjörð Bjarmason
> On Sat, Jan 20 2018, Randall S. Becker jotted:
> 
> > I will reissue this particular patch shortly.
> 
> It makes sense to base that submission on the next branch instead of master.
> I have a patch queued up there which adds two new tar invocations.
> 
> Also re your commit message see the formatting guide in
> Documentation/SubmittingPatches, in particular: instead of:
> 
>  - Add a brief subject line
> 
>  - Just make the body be a normal paragraph instead of a bullet-point
>list with one item.

Got it. I've been swapping between contribution styles so got a little 
confused. I'm going to reissue all of the patches required for the NonStop port 
later tonight or tomorrow, once the test suite run is finished. I'll take 
everyone's comments into account for that. Thanks for your (and everyone 
else's) guidance.

Cheers,
Randall

-- Brief whoami:
  NonStop developer since approximately NonStop(2112884442)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

On January 20, 2018 9:25 AM, René Scharfe wrote:
> To: Randall S. Becker <rsbec...@nexbridge.com>; git@vger.kernel.org
> Subject: Re: [PATCH v2 2/6] Add tar extract install options override in
> installation processing.
> 
> Am 20.01.2018 um 14:44 schrieb Randall S. Becker:
> > On January 20, 2018 7:31 AM, René Scharfe wrote:
> >> Am 19.01.2018 um 18:34 schrieb randall.s.bec...@rogers.com:
> >>> From: "Randall S. Becker" <rsbec...@nexbridge.com>
> >>>
> >>> * Makefile: Add TAR_EXTRACT_OPTIONS to allow platform options to be
> >>> specified if needed. The default is xof.
> >>>
> >>> Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com> ---
> >>> Makefile | 6 +- 1 file changed, 5 insertions(+), 1
> >>> deletion(-)
> >>>
> >>> diff --git a/Makefile b/Makefile index 1a9b23b67..040e9eacd
> >>> 100644 --- a/Makefile +++ b/Makefile @@ -429,6 +429,9 @@ all:: #
> >>> running the test scripts (e.g., bash has better support for "set -x"
> >>> # tracing). # +# Define TAR_EXTRACT_OPTIONS if you want to change
> >>> the default +behaviour # from xvf to something else during
> >>> installation.
> >>
> >> "xof" instead of "xvf"?
> >
> > When I look at the parent commit, it says xof, so I wanted to preserve
> > existing behaviour by default. Our install process wants to see the
> > actual set of files, so we wanted to use xvof but that hardly seemed
> > of general interest. I was hoping an option to control it would be
> > agreeable.
> 
> Preserving the default is good. I meant that the default is "xof", but the
> added line implies it was "xvf" instead.
> 
> Seeing your actual use case confirms that my suggestion below would work
> for you.
> 
> >
> >>> +# # When cross-compiling, define HOST_CPU as the canonical name
> >>> of the
> >> CPU on
> >>> # which the built Git will run (for instance "x86_64").
> >>>
> >>> @@ -452,6 +455,7 @@ LDFLAGS = ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
> >>> ALL_LDFLAGS = $(LDFLAGS) STRIP ?= strip +TAR_EXTRACT_OPTIONS = xof
> >>>
> >>> # Create as necessary, replace existing, make ranlib unneeded.
> >>> ARFLAGS = rcs @@ -2569,7 +2573,7 @@ install: all ifndef NO_GETTEXT
> >>> $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(localedir_SQ)'
> >>> (cd po/build/locale && $(TAR) cf - .) | \ -   (cd
> >>> '$(DESTDIR_SQ)$(localedir_SQ)' && umask 022 && $(TAR) xof -) + (cd
> >>> '$(DESTDIR_SQ)$(localedir_SQ)' && umask 022 && $(TAR)
> >>> +$(TAR_EXTRACT_OPTIONS) -)
> >>
> >> Hmm.  TAR_EXTRACT_OPTIONS always needs to have f (or -f, or --file)
> >> at the end to go together with the following dash, meaning to extract
> >> from stdin. And x (or -x, or --extract) is probably needed in all
> >> cases as well.  So wouldn't it make more sense to only put the o (or
> >> -o, or --no-same-owner) into TAR_EXTRACT_OPTIONS and enforce x and
> f?
> >
> > This is a good suggestion, and I'd love to do that, if I could
> > guarantee a modern tar, which I can't. The platform comes with a
> > really old-school tar from some old (seemingly BSD4.3) epoch that only
> > takes one option set. There is a more modern tar that can be
> > optionally installed if the sysadmin decides to that takes a slightly
> > more modern set, which could support your request, and my team also
> > has a gnu port that is very modern. I can't control what customers are
> > choosing to have installed, unfortunately. Your point is well made and
> > I am completely on board with it, but it introduces a configuration
> > requirement.
> 
> Long options would be nice to nice to have, but are not my main point; I
> included them mainly to spare readers from firing up "man tar" to look up
> the meaning of the short ones.
> 
> I just meant to say that something like this here would make more sense
> because you always need x and f- anyway:
> 
>   TAR_EXTRACT_OPTIONS = o
> 
>   ... ${TAR} x${TAR_EXTRACT_OPTIONS}f -
> 
> > As with the broadening setbuf (patch 2/6) change, I would like to
> > consider this for the future, having a slightly different more complex
> > idea. I could introduce something like this:
> >
> > 1. HAS_ANCIENT_TAR=UnfortunatelyYes in config.mak.uname that disables
> > this capability all together 2. HAS_ANCIENT_TAR=AreYouKiddingMe
> > (joke) then set up TAR_EXTRACT_ADDITIONAL_OPTIONS above and beyond
> the
> > default, so --file, --no-same-owner would always be in effect for that
> > operation.
> >
> > The micro-project would also, logically, need to apply to other tar
> > occurrences throughout the code and potentially need a test case
> > written for it (not entirely sure what that would test, yet).
> > Is that a reasonable approach?
> 
> As long as old-school dash-less flags suffice for our purposes (including
> yours) we can just keep using that style everywhere and avoid adding more
> settings.  It would be a different matter if we needed features that have no
> short flag, or are only offered by certain tar implementations.

Points taken. I will reissue this particular patch shortly.

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

[Randall S. Becker]

On January 20, 2018 7:31 AM, René Scharfe wrote:
> Am 19.01.2018 um 18:34 schrieb randall.s.bec...@rogers.com:
> > From: "Randall S. Becker" <rsbec...@nexbridge.com>
> >
> > * Makefile: Add TAR_EXTRACT_OPTIONS to allow platform options to be
> >specified if needed. The default is xof.
> >
> > Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
> > ---
> >   Makefile | 6 +-
> >   1 file changed, 5 insertions(+), 1 deletion(-)
> >
> > diff --git a/Makefile b/Makefile
> > index 1a9b23b67..040e9eacd 100644
> > --- a/Makefile
> > +++ b/Makefile
> > @@ -429,6 +429,9 @@ all::
> >   # running the test scripts (e.g., bash has better support for "set -x"
> >   # tracing).
> >   #
> > +# Define TAR_EXTRACT_OPTIONS if you want to change the default
> > +behaviour # from xvf to something else during installation.
> 
> "xof" instead of "xvf"?

When I look at the parent commit, it says xof, so I wanted to preserve existing 
behaviour by default. Our install process wants to see the actual set of files, 
so we wanted to use xvof but that hardly seemed of general interest. I was 
hoping an option to control it would be agreeable.

> > +#
> >   # When cross-compiling, define HOST_CPU as the canonical name of the
> CPU on
> >   # which the built Git will run (for instance "x86_64").
> >
> > @@ -452,6 +455,7 @@ LDFLAGS =
> >   ALL_CFLAGS = $(CPPFLAGS) $(CFLAGS)
> >   ALL_LDFLAGS = $(LDFLAGS)
> >   STRIP ?= strip
> > +TAR_EXTRACT_OPTIONS = xof
> >
> >   # Create as necessary, replace existing, make ranlib unneeded.
> >   ARFLAGS = rcs
> > @@ -2569,7 +2573,7 @@ install: all
> >   ifndef NO_GETTEXT
> > $(INSTALL) -d -m 755 '$(DESTDIR_SQ)$(localedir_SQ)'
> > (cd po/build/locale && $(TAR) cf - .) | \
> > -   (cd '$(DESTDIR_SQ)$(localedir_SQ)' && umask 022 && $(TAR) xof -)
> > +   (cd '$(DESTDIR_SQ)$(localedir_SQ)' && umask 022 && $(TAR)
> > +$(TAR_EXTRACT_OPTIONS) -)
> 
> Hmm.  TAR_EXTRACT_OPTIONS always needs to have f (or -f, or --file) at the
> end to go together with the following dash, meaning to extract from stdin.
> And x (or -x, or --extract) is probably needed in all cases as well.  So 
> wouldn't
> it make more sense to only put the o (or -o, or
> --no-same-owner) into TAR_EXTRACT_OPTIONS and enforce x and f?

This is a good suggestion, and I'd love to do that, if I could guarantee a 
modern tar, which I can't. The platform comes with a really old-school tar from 
some old (seemingly BSD4.3) epoch that only takes one option set. There is a 
more modern tar that can be optionally installed if the sysadmin decides to 
that takes a slightly more modern set, which could support your request, and my 
team also has a gnu port that is very modern. I can't control what customers 
are choosing to have installed, unfortunately. Your point is well made and I am 
completely on board with it, but it introduces a configuration requirement.

As with the broadening setbuf (patch 2/6) change, I would like to consider this 
for the future, having a slightly different more complex idea. I could 
introduce something like this:

1. HAS_ANCIENT_TAR=UnfortunatelyYes in config.mak.uname that disables this 
capability all together
2. HAS_ANCIENT_TAR=AreYouKiddingMe (joke) then set up 
TAR_EXTRACT_ADDITIONAL_OPTIONS above and beyond the default, so --file, 
--no-same-owner would always be in effect for that operation.

The micro-project would also, logically, need to apply to other tar occurrences 
throughout the code and potentially need a test case written for it (not 
entirely sure what that would test, yet).

Is that a reasonable approach?

> 
> >   endif
> >   ifndef NO_PERL
> > $(MAKE) -C perl prefix='$(prefix_SQ)' DESTDIR='$(DESTDIR_SQ)'
> > install
> >

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

[Randall S. Becker]

On January 20, 2018 6:10 AM,  Torsten Bögershausen wrote:
> On Fri, Jan 19, 2018 at 12:33:59PM -0500, randall.s.bec...@rogers.com
> wrote:
> > From: "Randall S. Becker" <rsbec...@nexbridge.com>
> >
> > * wrapper.c: called setbuf(stream,0) to force pipe flushes not enabled by
> >   default on the NonStop platform.
> >
> > Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
> > ---
> >  wrapper.c | 3 +++
> >  1 file changed, 3 insertions(+)
> >
> > diff --git a/wrapper.c b/wrapper.c
> > index d20356a77..671cbb4b4 100644
> > --- a/wrapper.c
> > +++ b/wrapper.c
> > @@ -403,6 +403,9 @@ FILE *xfdopen(int fd, const char *mode)
> > FILE *stream = fdopen(fd, mode);
> > if (stream == NULL)
> > die_errno("Out of memory? fdopen failed");
> > +#ifdef __TANDEM
> > +   setbuf(stream,0);
> > +#endif
> 
> Reading the commit message, I would have expected someting similar to
> 
> #ifdef FORCE_PIPE_FLUSHES
>   setbuf(stream,0);
> #endif
> 
> (Because other systems may need the tweak as well, some day) Of course
> you need to change that in the Makefile and config.mak.uname
> 
> > return stream;
> >  }

I can definitely see the point. Would you be agreeable to expanding the scope 
of this as a separate patch after this one is applied? I would want to bring at 
least one more Not NonStop machine into the mix for testing, which is more than 
I can do this weekend .

Cheers,
Randall

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

[Randall S. Becker]

On January 20, 2018 2:15 AM, Junio C Hamano wrote:
> "Randall S. Becker" <rsbec...@nexbridge.com> writes:
> 
> > I’m still a bit perplexed by some behaviour seen today, and am looking
> > for a clean way to deal with it that the documentation does not make
> > clear. So, I’m asking in a different way. Suppose a graph of
> >
> > A---B---C---D---E
> > \  \   /
> >   \F—G/
> >
> 
> An ASCII art that is not drawn for fixed-width font is by definition
> understandable only by the person who drew it X-<.  I am guessing that F is a
> child of both A and B (but I am not sure, as I do not see a reason why it
> should even be a merge to begin with, so my guess is likely to be wrong), and
> E is a merge between D and G.

My bad... outlook... and user. 
> 
> IOW, I am guessing that the below is the equivalent of what you drew for
> those who look at the picture in fixed-width font:
> 
> A---B---C---D---E
>  \   \ /
>   .---F---G

As unintelligible, X-<, but you are probably correct.

> > When trying to perform a format-patch from B to E, I was seeing
> > commits B-A-F-G-E rather than what I wanted B-C-D-E.
> 
> Assuming that E is a merge, format-patch output should not show E anyway
> (i.e. think in terms of "git log --no-merges --reverse", instead of fearing 
> that
> format-patch is somehow more magical---it is not).  So if you want to show
> the comit B, C and D (meaning three patches, i.e. "diff A B", "diff B C", and
> "diff C D"), then you would do "format-patch A..D", not "format-patch A..E".
> If you meant that you are not interested in the change between A and B,
> then the range would be "B..D" instead of "A..D".  Ending the range at "E"
> means you want to see what is reachable from E, and unless you say you are
> not interested in G, you would get G, if you only say you are not interested 
> in
> A (or B), as G is not reachable from A (or B).

While the end point, E was the same regardless of which path, I was interested 
in submitting the patches along B..E. A is the parent of B and F and was 
included in the format-patch, which then forward through F and G then E.

> It is unclear how you told format-patch when "trying to perform a format-
> patch from B to E" from your description, but if you said "format-patch
> A^..E", it is likely that you would have seen all commits in the depicted part
> of the graph except for merge commits.

That seems to be the case. I used format-patch B..E with no other args. A was 
not specified but got drawn in. D-E was a merge so is that why that path wasn't 
selected? I'd still like to be able to include merges - is that a dream?

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

[Randall S. Becker]

I’m still a bit perplexed by some behaviour seen today, and am looking for a 
clean way to deal with it that the documentation does not make clear. So, I’m 
asking in a different way. Suppose a graph of

A---B---C---D---E
\  \   /
  \F—G/

When trying to perform a format-patch from B to E, I was seeing commits 
B-A-F-G-E rather than what I wanted B-C-D-E.  F and G were younger commits than 
C and D, which I assume (very likely wrongly) is why diff was giving 
preferential treatment to that path.

What I am trying to figure out is whether there is a clean way to force 
format-patch along the B-C-D-E path. If not, would it be worth starting up a 
small project to make this possible (not knowing exactly where to start), but I 
would envision something like: git format-patch –via=C B..E

I may be just missing something obvious (new to format-patch operations 
myself). 

Cheers,
Randall
P.S. Bad ideas happen when tests run for a long time 


-- Brief whoami:
  NonStop developer since approximately NonStop(2112884442)
  UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

On January 19, 2018 5:29 PM, I wrote:
> On January 19, 2018 4:27 PM, Jeff King wrote:
> > On Fri, Jan 19, 2018 at 12:34:04PM -0500, randall.s.bec...@rogers.com
> wrote:
> >
> > > From: "Randall S. Becker" <rsbec...@nexbridge.com>
> > >
> > > * t/lib-git-daemon.sh: fix incompatibilities with ksh traps not being
> > >   cleared automatically on platform. This caused tests to seem to fail
> > >   while actually succeeding.
> > >
> > > Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
> > > ---
> > >  t/lib-git-daemon.sh | 3 +++
> > >  1 file changed, 3 insertions(+)
> > >
> > > diff --git a/t/lib-git-daemon.sh b/t/lib-git-daemon.sh index
> > > 987d40680..955beecd9 100644
> > > --- a/t/lib-git-daemon.sh
> > > +++ b/t/lib-git-daemon.sh
> > > @@ -68,6 +68,7 @@ start_git_daemon() {
> > >   test_skip_or_die $GIT_TEST_GIT_DAEMON \
> > >   "git daemon failed to start"
> > >   fi
> > > + trap '' EXIT
> > >  }
> >
> > I don't think this can be right. The way these traps are supposed to work 
> > is:
> >
> >   - as soon as test-lib.sh is loaded, we "trap die EXIT" to catch an
> > accidental death/exit from one of the scripts
> >
> >   - when test_done is called, we clear the trap (i.e., it is OK to exit
> > now because the script has given us a positive indication that all
> > tests have been run)
> >
> >   - while the child git-daemon is running, we'd want to clean up after
> > ourselves. So during start_git_daemon() we add our cleanup (followed
> > by the original "die", because shell traps don't push onto a stack).
> > And then at stop_git_daemon(), we restore the original die trap.
> >
> > But this patch means that while git-daemon is running, we have no trap at
> all!
> > That means that a failed test which causes us to exit would leave a
> > child daemon running.
> >
> > Furthermore, both of these functions now drop the 'die' trap entirely,
> > meaning the script would fail to notice premature exit from one of the
> > test snippets.
> >
> > So while this may be papering over a problem on NonStop, I think it's
> > breaking the intent of the traps.
> >
> > I'm not sure what the root of the problem is, but it sounds like ksh
> > may be triggering EXIT traps when we don't expect (during function
> returns?
> > Subshell exits? Other?)
> 
> The "unexpected" EXIT traps are exactly the issue we found when working
> with the platform support team. There was some discussion about what the
> right expectation was, and I was not able to have a change made to ksh on
> the platform. The problem may have a similar (identical?) root cause to the
> Perl exit issues we are also experiencing that is in their hands. I'm 
> currently
> retesting without this change (results in 36 hours ☹ ). Is there a preferred
> way you would like me to bypass this except on NonStop? I can add a check
> based on uname.

The option that may work, if the tests that are currenting running until Sunday 
(sadly) fail miserably, is to use:

if [ `uname` = "NONSTOP_KERNEL" ]; then trap '' EXIT; fi

or perhaps to add a descriptive function along those lines. We have had two 
major operating system upgrades since the original case relating to ksh traps, 
so perhaps things might improve. Our baseline is that there are currently 6 
breaks (t1308#23, t1405#52, t9001#31/106/107/134), most of which have been 
traced back to perl completion codes.

Cheers,
Randall
P.S. I am happy to explain why the tests perform the at the rate they do on the 
development machines I have, if anyone is interested, although dissertations 
might be involved 

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

[Nit] Lots of enumerated type warnings

[Randall S. Becker]

So here a bit of a nit or nano-quibble that I have. Call it my "warnings
OCD" if you want. I'm seeing an increase in the enumerated type warnings
coming from my use of the c99 compiler for compiling git over time (loads
more for 2.16.0 compared to 2.3.7 when I took it on). What is the general
feeling on these? I would be willing do static casts rather than see the
warnings, mostly because I advocate in public that warnings are actually
future potential errors, so clean compiles are better. I don't see this
conflicting with anything in gcc. Is there a desire/need to clean up this
stuff? I can take a stab at gradually cleaning this up when $DAYJOB and
#FAMILY don't conflict.

Although, given the choice, I'd rather look into that whole --via concept
from a different thread ;-)

Cheers,
Randall

-- Brief whoami:
 NonStop developer since approximately 2112884442
 UNIX developer since approximately 421664400
-- In my real life, I talk too much.

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

[Randall S. Becker]

> -Original Message-
> From: randall.s.bec...@rogers.com [mailto:randall.s.bec...@rogers.com]
> Sent: January 19, 2018 6:00 PM
> To: git@vger.kernel.org
> Cc: Randall S. Becker <rsbec...@nexbridge.com>
> Subject: [PATCH v3 0/6] Force pipes to flush immediately on NonStop
> platform
> 
> From: "Randall S. Becker" <rsbec...@nexbridge.com>
> 
> * wrapper.c: called setbuf(stream,NULL) to force pipe flushes not
>   enabled by default on the NonStop platform. This applies only
>   to the NonStop platform guarded by #ifdef __TANDEM.
> 
> Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
> ---
>  wrapper.c | 3 +++
>  1 file changed, 3 insertions(+)
> 
> diff --git a/wrapper.c b/wrapper.c
> index d20356a77..671cbb4b4 100644
> --- a/wrapper.c
> +++ b/wrapper.c
> @@ -403,6 +403,9 @@ FILE *xfdopen(int fd, const char *mode)
>   FILE *stream = fdopen(fd, mode);
>   if (stream == NULL)
>   die_errno("Out of memory? fdopen failed");
> +#ifdef __TANDEM
> + setbuf(stream,NULL);
> +#endif
>   return stream;
>  }
> 
> --
> 2.16.0.31.gf1a482c

This is a replacement for the v2 patch based on Stefan's suggestions.
Cheers,
Randall

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

[randall . s . becker]

From: "Randall S. Becker" <rsbec...@nexbridge.com>

* wrapper.c: called setbuf(stream,NULL) to force pipe flushes not
  enabled by default on the NonStop platform. This applies only
  to the NonStop platform guarded by #ifdef __TANDEM.

Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
---
 wrapper.c | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/wrapper.c b/wrapper.c
index d20356a77..671cbb4b4 100644
--- a/wrapper.c
+++ b/wrapper.c
@@ -403,6 +403,9 @@ FILE *xfdopen(int fd, const char *mode)
FILE *stream = fdopen(fd, mode);
if (stream == NULL)
die_errno("Out of memory? fdopen failed");
+#ifdef __TANDEM
+   setbuf(stream,NULL);
+#endif
return stream;
 }
 
-- 
2.16.0.31.gf1a482c

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

[Randall S. Becker]

On January 19, 2018 5:43 PM, Ramsay Jones wrote:
> On 19/01/18 21:20, Jeff King wrote:
> > On Fri, Jan 19, 2018 at 08:28:48PM +, Ramsay Jones wrote:
> >
> >>> diff --git a/remote.c b/remote.c
> >>> index 4e93753e1..c18f9de7f 100644
> >>> --- a/remote.c
> >>> +++ b/remote.c
> >>> @@ -11,6 +11,10 @@
> >>>  #include "mergesort.h"
> >>>  #include "argv-array.h"
> >>>
> >>> +#if defined (__TANDEM)
> >>> +#define __attribute(a)
> >>> +#endif
> >>> +
> >>
> >> Hmm, the only use of __attribute() I can find is in compat/regex/.
> >> In particular, there is no use of __attribute() in regex.c.
> >> [__attribute__() is used in regex.c]
> >>
> >> Is this an old patch which is no longer required?
> >>
> >> puzzled.
> 
> heh, I only just noticed that I (twice) wrote regex.c when I meant remote.c
> instead. Hopefully, that didn't cause too much confusion!
> 
> > I'm puzzled, too. The actual gcc thing is __attribute__(), and we
> > already turn that into a noop via macro expansion if __GNUC__ is not
> > defined (in git-compat-util.h, but see below).
> >
> > __attribute(), without the trailing underscores, is used internally by
> > the regex compat code (but it also converts that into a noop on
> > non-GNUC platforms)>
> 
> Indeed.
> 
> > However the logic in git-compat-util is weird:
> >
> >   #if defined(__HP_cc) && (__HP_cc >= 61000)
> >   #define NORETURN __attribute__((noreturn))
> >   #define NORETURN_PTR
> >   #elif defined(__GNUC__) && !defined(NO_NORETURN)
> >   #define NORETURN __attribute__((__noreturn__))
> >   #define NORETURN_PTR __attribute__((__noreturn__))
> >   #elif defined(_MSC_VER)
> >   #define NORETURN __declspec(noreturn)
> >   #define NORETURN_PTR
> >   #else
> >   #define NORETURN
> >   #define NORETURN_PTR
> >   #ifndef __GNUC__
> >   #ifndef __attribute__
> >   #define __attribute__(x)
> >   #endif
> >   #endif
> >   #endif
> >
> > Most of the conditional is dealing with NORETURN, but then we stick
> > the __attribute()__ handling in the "else" block. Is it possible that
> > this platform triggers __HP_cc, but doesn't actually understand
> > __attribute__?
> 
> That seems unlikely. However, that conditional looks a mess ... ;-)

Very messy and confusing and it is working properly now, so... consider this 
patch gone ;-)

Cheers,
Randall

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

[Randall S. Becker]

On January 19, 2018 3:29 PM, Ramsay Jones wrote:
> On 19/01/18 17:34, randall.s.bec...@rogers.com wrote:
> > From: "Randall S. Becker" <rsbec...@nexbridge.com>
> >
> > * remote.c: force ignoring of GCC __attribute construct not supported
> >   by c99 by defining it as an empty CPP macro.
> >
> > Signed-off-by: Randall S. Becker <rsbec...@nexbridge.com>
> > ---
> >  remote.c | 4 
> >  1 file changed, 4 insertions(+)
> >
> > diff --git a/remote.c b/remote.c
> > index 4e93753e1..c18f9de7f 100644
> > --- a/remote.c
> > +++ b/remote.c
> > @@ -11,6 +11,10 @@
> >  #include "mergesort.h"
> >  #include "argv-array.h"
> >
> > +#if defined (__TANDEM)
> > +#define __attribute(a)
> > +#endif
> > +
> 
> Hmm, the only use of __attribute() I can find is in compat/regex/.
> In particular, there is no use of __attribute() in regex.c.
> [__attribute__() is used in regex.c]
> 
> Is this an old patch which is no longer required?
> 
> puzzled.

After investigation, this patch can be dropped. The __attribute__ fix from 
git-compat-utils.h is actually being picked up correctly now (unlike our 2.8.5 
port when it was required). I am suspecting that this was blocked by a 
configuration setting in config.mak.uname that got fixed when I got my hands on 
that file for a cleanup. The path through there is via #ifndef __GNUC__.

Cheers,
Randall