|
Nothing devisive: we think that one of the best posts in a while. Well, I wouldn't go that far. Why not? Be positive. I up-voted him. Shouldn't we, at least, have talked it over?
Hey - you two . . . knock it off . . . I'm trying to get some work done.
[edit]Modified while I wasn't looking . . . [/edit]
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
modified 15-Oct-20 12:34pm.
|
|
|
|
|
Reminds me of an old maybe-not-so-KSS joke...I forget exactly how it goes...the gist of it is this:
Two female coworkers, on a business trip, are sharing a motel room together. As they're getting ready to go to bed, one of them wants to come out of the proverbial closet, but doesn't quite know how to say it, so she starts with "look, I'll be frank"...the other interrupts her, saying "no, if you don't mind, I'd like to be Frank..."
|
|
|
|
|
Keep a Sybil tongue in your head!
If you can't laugh at yourself - ask me and I will do it for you.
|
|
|
|
|
"I dropped my toothpaste", he said, crestfallen.
|
|
|
|
|
That reminds of an amusing, older movie : "Short Circuit". There is a character in it who constantly butchers common expressions. One of his statements is, "I am standing beside myself," said in a faux-Indian accent which enhances the humor factor, I think.
"They have a consciousness, they have a life, they have a soul! Damn you! Let the rabbits wear glasses! Save our brothers! Can I get an amen?"
|
|
|
|
|
|
We think we might be multiple; that's being frank.
..sound great, but feeding all of them..
Bastard Programmer from Hell 
"If you just follow the bacon Eddy, wherever it leads you, then you won't have to think about politics." -- Some Bell.
|
|
|
|
|
|
Isn't that self-contradicting? If "it's really as easy as pi", then the question should be "why SHOULD you let advanced math intimidate you", not "why SHOULDN'T you [...]"
|
|
|
|
|
Can't we all just transcend these nuances ?
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
I can. But I write software for a living. I appreciate correctness.
|
|
|
|
|
Pi transcend . . . transcendental ?
I guess you just missed it.
| Ravings en masse^ |
|---|
| "The difference between genius and stupidity is that genius has its limits." - Albert Einstein | | "If you are searching for perfection in others, then you seek disappointment. If you seek perfection in yourself, then you will find failure." - Balboos HaGadol Mar 2010 |
|
|
|
|
|
Concentrate on Pi (the tasty one) 
yes I know 'e' is missing
|
|
|
|
|
Don't be so picky... we are speaking about maths, not about language  
M.D.V.
If something has a solution... Why do we have to worry about?. If it has no solution... For what reason do we have to worry about?
Help me to understand what I'm saying, and I'll explain it better to you
Rating helpful answers is nice, but saying thanks can be even nicer.
|
|
|
|
|
It may be an urban legend but I can believe it...
A county in Texas decided that PI was too complicated and difficult to remember so passed a local law that, from now on, PI would be equal to exactly 3.
- I would love to change the world, but they won’t give me the source code.
|
|
|
|
|
I thought it was Arkansas. But same difference.
To err is human to really mess up you need a computer
|
|
|
|
|
Any good book on urban legends can tell you a dozen other places where it happened.
("Well, if it isn't true, it sure is a d**n good lie!")
|
|
|
|
|
Obviously run by Professor Frink[^]! 
"These people looked deep within my soul and assigned me a number based on the order in which I joined."
- Homer
|
|
|
|
|
Yea, I know this isn't the place to ask technical questions about this annoying 'feature' but can anyone recommend a good place to ask and actually get a meaningful answer from someone who knows? It seems to be a bug or a 'misfeature'.
For those who are interested, here is the issue:-
This is Windows 10 2004 and I added a path to the Windows Search search scope. The path contains archived dev projects. Let's say it's "D:\Data\Devstuff\Archive\". It contains subfolders (40-50 folders, one subfolder per project). Mostly C# but Python, TypeScript and other stuff. Most of the folders do not have ".git" subfolders but a few do.
I recently noticed that all the folders that have a ".git" subfolder (e.g. like this: "D:\Data\Devstuff\Archive\PythonHelloWorld\.git\") have been excluded from the Windows search search scope. So "D:\Data\Devstuff\Archive\" is included but "D:\Data\Devstuff\Archive\PythonHelloWorld\" (and any other subfolder of "D:\Data\Devstuff\Archive\" that has a ".git" subfolder) is listed in the excluded section. It wasn't me who did this; Windows did it all by itself at some point fairly recently! Not sure when, though.
After some experimentation:
(1) It's definitely the existence of a .git subfolder that causes its immediate parent folder to be excluded from the search/index scope.
(2) The ".vs" subfolder has no such effect.
(3) It's not a path length issue. The same thing happens no matter how deep the offending folder is.
(4) Manually removing the exclusions simply results in them being added back in by Windows.
(5) Rebuilding Windows Search (forcing a complete rebuild of its database and settings) from scratch doesn't cure the problem.
(6) I tried adding an exclusion rule via the registry to exclude "file:///*\.git\" (i.e. all ".git" folders) in the hope that this would allow the parent folder to be indexed but it had no effect. The parent folder was still removed from the search scope.
(7) By fiddling around with the registry to manually force folders with ".git" subfolders to be included, it is possible to hang the Windows Search service. The only cure is to allow Windows Search to remove the folders containing ".git" subfolders (usually be letting it rebuild from scratch).
On the face of it this seems to be a strangely hardcoded attempt to prevent ".git" folders being needlessly indexed but it seems to have gone awry in that it excludes the parent folders that simply contain the ".git" subfolders (and of course it then excludes any other subfolders, including the ones containing code that I want to be indexed).
Any ideas?
modified 15-Oct-20 9:41am.
|
|
|
|
|
Quote: .gitignore file anywhere? not sure if you mentioned that in your post. I know you can ignore files and folders using a .gitignore file in a visual studio solution, etc.
All the folders that contain a ".git" subfolder have a .gitignore file but such files have no meaning to Windows Search.
Just to confirm, I deleted the .gitignore file from "D:\Data\Devstuff\Archive\PythonHelloWorld\" and when I added "D:\Data\Devstuff\Archive\PythonHelloWorld\" to the Windows Search search scope via the UI, it just disappeared. I looked in the registry and the folder is now listed as a non-included folder. In other words, Windows Search saw me add it and then just disappeared it, and will not now index or search it.
|
|
|
|
|
markrlondon wrote: it excludes the parent folders that simply contain the ".git" subfolders (and of course it then excludes any other subfolders, including the ones containing code that I want to be indexed).
In a folder such as "D:\Data\Devstuff\Archive\PythonHelloWorld\" (which has a ".git" subfolder), if I add the "D:\Data\Devstuff\Archive\PythonHelloWorld\PythonHelloWorld\" subfolder (where all the code is located) manually to the Windows Search search scope then it is indexed and searched correctly. This is because the ".git" folder is at "D:\Data\Devstuff\Archive\PythonHelloWorld\.git\" and so Windows Search does not perceive it to be a problem for "D:\Data\Devstuff\Archive\PythonHelloWorld\PythonHelloWorld\".
|
|
|
|
|
If these are just archives, why not rename the .git things to .gat or something. Then, if you ever need to unarchive for use, restore the correct name.
Or maybe Microsoft will fix the problem. Someday. At a later date. TBD 
|
|
|
|
|
GenJerDan wrote: If these are just archives, why not rename the .git things to .gat or something. Then, if you ever need to unarchive for use, restore the correct name.
A good idea. That does seem to work.
In my earlier experimentation I tried temporarily removing the ".git" folder but I didn't think to rename it. Doh. And, indeed, renaming it does allow the folder in which it lives to be indexed and searched. So it seems from this that it is a hardcoded issue to do with ".git" folders.
GenJerDan wrote: Or maybe Microsoft will fix the problem. Someday. At a later date. TBD
To be fair, I expect they will fix it, if only because it will annoy their own in-house users of Git! 
However, it would help to be able to bring it to their attention. I just wish I knew where to do this in a manner that will allow it to be understood and treated seriously.
|
|
|
|
|
markrlondon wrote: In my earlier experimentation I tried temporarily removing the ".git" folder but I didn't think to rename it. Doh. And, indeed, renaming it does allow the folder in which it lives to be indexed and searched. So it seems from this that it is a hardcoded issue to do with ".git" folders.
Ah, after some further experimentation it's not just any ".git" folder: It would seem that the ".git" folder must have some real Git files in it, although I've not gone to the effort of figuring out which ones.
So it looks like Windows Search is trying (and failing) to do hardcoded clever things with the contents of ".git" folders. Which, I know from experience, is entirely unnecessary since no knowledge of Git is needed to correctly index the current status of a project managed by Git.
|
|
|
|
|
One lovable thing about git is that you never know which files will be in your directories. That in none of your business, sort of 
For tl;dr people: Indexing makes very little sense in a directory tree where git pulls away the rug under your feet, maybe a dozen of times (or more) every working day.
A little more detail:
Open a command window in your git project directory. Checkout branch xxx, list the files. Checkout branch yyy, list the files. The two sets of files may be completely disjunct, non-overlapping (or only partially overlapping). You haven't done any cd at all, not deleted or created any file. Yet the dir command gives two very different results.
Open another command window, and cd to the same project directory. Which set of files will you see there, if you do a dir command?
Go back to the first command window, and checkout branch xxx. Return to the second command window and repeat the dir command. Some, maybe all the files you just saw a few seconds ago, have disappeared, and another set has appeared. In that window, there is no indication of any command causing the change.
It would look just the same if you - rather than checking out another git branch - in the first window had actually deleted some files and created some new ones. Usually you would consider that as really deleting info, and building new info, a semantically significant thing. But in git, when you check out another branch, the info is not deleted, it is just hidden. No new info is created, it is just pulled out from hiding.
How should the indexing handle this? Indexing is performed - on which files? Those that git has hidden? After indexing is complete, you check out another branch, so some of those files that were visible are now hiddden. How would you handle a search that gives a hit in now hidden files? As if they were deleted? Or as if they are visible? How should this hit be reported to the user?
Consider git project directories to be managed by git, neither by yourself nor Windows. (It took me quite some frustration before I learned to never have two command windows open in the same git project directory, in particular if you work on 2+ branches!)
If the git delevelopers want to provide an indexing and searching mechanisms tailored to the .git direcory and file strucutres, so it can report a hit e.g. indicating which branches the file are found in (whether checked out or not): Fine. But don't expect that every OS shall interpret .git structures (nor any other application's privately defined structures).
|
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
