In the latest update of Visual Studio Code, I noticed that the source control git message feature started ignoring white space in my git template. Is there a way to revert to previous behavior?
Further Detail
In the past for git, I had a template commit message file similar to the following:
#
# Various Billing codes: I'd un-comment the one I need at the time
# Billed to Project 1
Billed to Project 2
#Billed to Project 3
With this, I would simply type my subject in place of the pound and continue from there. Visual studio Code used to include the two initial white spaces in its message box. I'd get this:
_
Billed to Project 2
Where the underscore is where I begin typing. Now it is simply:
Billed to Project 2
This is particularly frustrating since the billing codes exceed the 50 character subject limit, and it wants to display its warning each time. I personally like the 50 character subject limit and a 78 character line limit, so I don't want to disable that feature. And, I can't change the billing code as it is company standard. Any thoughts into getting my precious white spaces back?
Thanks in advance.
This was a bug in VS Code. It should be fixed in VS Code 1.38+
Related
I have an annoying problem and can't seem to figure out what's causing it. On my machine when I try to use Update Model from Database... on Edmx file in EF Database first approach the autogenerated model has blank lines between properties. This doesn't seem to occure on other developers machines even though we have same versions of VS , extensions etc.
Problem is that even when I add for example one new table the refresh automatically adds blank lines for all mapped tables. Later all of this is visible as conflict during merge operations in GIT.
Would really appreciate any help since I did't find a single shred of information on this issue anywhere and this really disrupts work.
I checked the files (Model.tt on my machine and my friends) using Notepad++ comparer and it said there are no differences but the encoding is different. When I copied Model.tt manually and did the update the blank lines were gone.... Must be some kind of quirk.
Posting as an answer since I wasted few hours on this and someone might have simmilar problem.
What worked for me
💡Turns out it was how my OS was ending lines
Working in Windows. Earlier disabled "auto carriage returns (CR) + line feeds (LF) line endings" in global Git configuration, reenabled:
git config --global core.autocrlf true
FYI 'nix/Mac ends lines w/ LFs only, Windows end lines w/ CRs + LFs
Opened up *DataModel.tt and *DataModel.Context.tt in Notepad++
Edit > EOL Conversions > Windows (CR LF) > Save
Refresh EDMX
Looking for a better terminal-based solution, sounds like dos2unix will come in to play at some point. Will amend this as soon as I've ironed this out.
Here's a rather advanced question for true ClearCase experts:
I frequently perform a rebase on a ClearCase snapshot view that has just a very limited number of small changes in few files (e.g. file1.c, file2.c, file3.c).
I do it with the following on the UNIX command line:
cleartool rebase -recommended -complete
Sometimes, while this command runs, out of the blue, and for no exlained reasons (yet), I get prompted for manual input to solve some "merge" conflicts. But they make no sense to me, as they happen in file(s) that I NEVER EVER TOUCHED -- and which ONLY ONE OTHER DEVELOPER EVER TOUCHES.
The "merge" prompts I see when this scenario happens during a rebase look usually like:
"Do you want INSERTION from file x? [yes/no]"
or
"Do you want DELETION from file y? [yes/no]"
or
"Do you want CHANGES from file z? [yes/no]".
Etc.
I have no clue why these "conflicts" are happening. Additionally, it's really hard (see impossible) to make good decisions because the details are shown with a very narrow number of columns, and there's hardly any way to guess right. Using graphical merging is not an option here because this is meant for an automation script that should ideally never ask for user input.
What I do know about this scenario is:
We have a team of 6 developers. 5 of us usually work the same limited number of files... say file1.c, file2.c, file.3.c
I work on a child development stream on these three files. And when I'm done, I normally deliver up to the default parent stream.
On the occasions where the "merge conflicts" on rebase happened, it's always on a totally DIFFERENT FILE -- one that is ONLY EVER TOUCHED by JUST ONE other developer in the team (it's a module that HE owns, NO ONE EVER TOUCHES THAT FILE BUT HIM). Let's call him developer #6.
When this strange "merge conflict" on rebase happens, I've usually been working for an extended time in my own development child stream (always with a snapshot view), and I've done a couple rebases (at least 3) to bring other changes ALL made by other developers (in file1.c, file2.c and file3.c) and which I needed to complete my work.
But, the other developer (#6), the ONLY ONE working on banana.c, had made changes to that file, in at least two of the three rebases activities that were created in the snapshot view of my child development stream.
Again, I repeat, I NEVER touched banana.c, and none of the 5 other developers ever did, except for the guy (#6) who owns the banana.c module.
And there, it happened - ClearCase asked me for manual input to solve a "merge" conflict with banana.c when doing "cleartool rebase -recommended -complete".
How can this be possible???
How can a file require "merging" when doing rebase if there is ONLY EVER one single developer making changes to it?
It's as if ClearCase got confused between different versions of banana.c in at least two of the three rebase activities automatically created in my stream (which both modified banana.c) and prompted me for "merge conflict" resolution (even though I never ever touched banana.c and only one developer (#6) ever did modify that file).
.
.
.
UPDATE: AUGUST 31ST 2015
Here's a log from an occurrence of the problem on August 28th 2015
Needs Merge "/view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp" to /main/MAIN_INT_STREAM/SUB_STREAM/CHECKEDOUT from /main/MAIN_INT_STREAM/SUB_STREAM/MY_DEV_STREAM/37 base /main/
MAIN_INT_STREAM/SUB_STREAM/150
********************************
<<< file 1: /view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp##/main/MYDYNAMICVIEW/SUB_STREAM/150
>>> file 2: /view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp##/main/MYDYNAMICVIEW/SUB_STREAM/MY_DEV_STREAM/37
>>> file 3: /view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp
********************************
...CUT FOR BREVITY...
*** Automatic: Applying DELETION from file 3 [deleting base line 123]
...CUT FOR BREVITY...
*** Automatic: Applying INSERT from file 3 [lines 123-124]
...CUT FOR BREVITY...
*** Automatic: Applying CHANGE from file 3 [lines 1329-1335]
...CUT FOR BREVITY...
*** No Automatic Decision Possible
merge: Warning: *** Aborting...
Missing charsets in String to FontSet conversion
Missing charsets in String to FontSet conversion
Missing charsets in String to FontSet conversion
Cannot convert string "-misc-kochi mincho-medium-r-normal--0-*-*-*-*-*-*-*" to type FontSet
...GMERGE POPPED HERE...
Moved contributor "/view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp" to "/view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp.contrib".
Output of merge is in "/view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp".
Recorded merge of "/view/MYDYNAMICVIEW/vobs/DIRLEVEL1/DIRLEVEL2/SOMEFILE.cpp".
I never touched SOMEFILE.cpp - only ONE other developer ever changes it- why does it require a merge?
My net impression at the moment is that ClearCase's automatic merge is doing a bad job.
Could it be a good idea to think of using the "-qall" or "-qntrivial" options to disable ALL/MOST automatic merging -- and do EVERY/MOST merge manually? (or with an external tool?)
1 & 2 How can this be possible???
This "Do you want the CHANGE made in file 2? [yes] no" message only appears when 2 contributors differ from the base contributor.
In that case, a cleartool lsvtree (not with -graph, since you don't have X-Window server) might help seeing the version involved, and trying to make some cleartool diff to see the difference (compared to the base contributor)
3/: that is one example where, if possible, working collaboratively on the same stream/branch (instead of working each developer in one own's stream) would be better.
Regarding the update of August 2015, the key error message is:
Missing charsets in String to FontSet conversion
See technote "Using GUI results in "Missing charsets in String to FontSet conversion" warning"
Possible causes include:
An improper setting of the locale variable. For example it may be set to UTF-8.
The file of interest is the Linux/palette, which defines the actual fonts used in the environment. This file is read to determine the fonts that can be displayed in the ClearCase GUI.
The palette file does not contain the correct fontset.
This issue was identified as a product defect and logged under APAR PK30799.
Don't ask why, but I'm using VS2003 and need to see what changes have taken place in all the files in my project between a certain date and now. I see how I can do that, namely by right-clicking on each file and selecting "Compare Versions" then selecting By Date and the date for the version to compare with the latest. This is good; what would be (much) better is if I could generate a report whereby it would show me something like:
The line "*Sit on a potato pan Otis*" was removed from BachBestsMozart.cs.
The line "*Any enterprise requiring new duds is likely a dud itself*" was added to CheapSunglasses.cs
(etc.)
...but hopefully ignore unimportant differences, such as formatting, comments, etc.
Does such a possibility exist, or am I doomed to open each file, one by one?
UPDATE
I ended up having to compare them all, one by one, eyeballing them. At least it's better than VS2010 is acting for me right now:
Awedly (I am awed, but not in a good way), the "Compare" functionality in VS2010 doesn't hold a candle to that in VS2003!
In VS2003, I can select a Target Version based on a date to compare with the current version - so, if I pick 2/13/2013, I may end up comparing files dated recently (today or whenever the file was last modified) and one modified on 2/13/2013, or 2/1/2013, or whenever the last modification prior to the date I selected took place.
In VS2010, it looks like I should be able to do that, but the combo box for the comparison file is grayed out/inacessible! Heavens to Murgatroid!!!
Or maybe this is just related to the problem I'm having where I can't update anything in the Package Manager - even trying to update Nuget gives me a can't load library err msg; and the package console is "read only" for me, too... I wish there were a "repair" functionality built into VS that would check up on missing or corrupt DLLs and replace them...
I am working with .docx files containing several drawing canvases with images inserted and some lines and arrows drawn in Word 2010. I am using 2010 format with no compatibility mode.
Word inserts an o:gfxdata attribute into each v:shape and v:group element and fills it with ascii encoded something. From what I have read it may be a copy of the VML describing the v:shape or v:group. I don't know if I just don't know what to look for, but I cannot determine what this data is for as its removal has no apparent effect on my ability to read or edit the document in Word 2003, 2007, or 2010.
It does swell the document.xml to almost twice the (apparent) necessary size. This considerably slows OpenTBS' processing so I would like to remove it, if possible. Does anyone know of a way to tell Word 2010 to quit saving this extra data? Or what it is for? I have really struggled to find any documentation on it beyond this post.
Edit:
Here is a sample .docx. The document.xml is ~141KB and OpenTBS takes an average of 10.35 seconds to create a file that includes this as a subtemplate 21 times. If I remove all of the o:ogfxdata attributes, the file size is reduced to ~37KB and OpenTBS takes only 2.99 seconds to produce the same file.
Edit 2:
After further investigation, it appears the removal of the o:gfxdata may cause Word 2003 with an older Compatibilty Pack installed, to object to the file with the following error:
"This is a pre-release version of the Compatibility Pack and can open
pre-release Office 2007 files only. Do you want to check for a newer
version of the Compatibility Pack?"
I have been able to open the file by installing a newer compatibility pack - though it prompts the user about the incompatibility and converts the file in order to open it. This does not damage my file, but it is something to look out for.
Attribute o:ogfxdata is poorly documented in the web.
According to your investigations, it's some kind of compatibility extra information.
You can delete those attributes in your template using OpenTBS.
The cleaning can be done once on your template without any merging, and then save the cleaned template as a new template. Or you can perform the cleaning each time you open the template.
Cleaning the DOCX file:
while ($x = clsTbsXmlLoc::FindStartTagHavingAtt($TBS->Source, 'o:gfxdata', 0) ) {
$x->ReplaceAtt('o:gfxdata', '');
$TBS->Source = str_replace(' o:gfxdata=""', '', $TBS->Source);
}
Note that the class clsTbsXmlLoc is provided with OpenTBS and is undocumented.
The code should work since OpenTBS 1.8.0. (which is currently in stable beta version).
I've noticed that since attributes o:gfxdata are deleted, they do not come back immediately when you edit the docx.
Our perforce admin limits "max-row" scans so that my first idea of running the following will not work:
All changes including integrates into a branch at particular label time 1
All changes including integrates into a branch at particular earlier label time 2
Subtract time 2 changes from time 1 to get the new changes with comments.
Is there an alternative way of getting the same result without having such a massive query(when perforce contains 7yrs of history and -i triggers a scan back to the dawn of history)
Based on Gregs comments added this comment:
Basically the point is to see what bugs got fixed in a particular release branch between 2 labels(or more commonly, some old label and today).
I wish to simplify(speedup) way too complex script that we currently have which looks at changes that went into a release branch, it follows files that went into them at least 2 branches up in order to printout all the changeset comments from the original change(the interim merge comments tend to just say something like merge123 etc instead of description of the actual change comments, so we need to walk up the tree to the original comment as well), script finally outputs something like below(we put quality center IDs into changeset comments):
qualityCenterId123 - fixed some bug
in gui qcId124 - fixed some other
bug qcId125 - fixed some other bug
merge123
UPDATE based on comments:
Problem with Toby's approach is that most of the changes into the code branch came via integrations, -i would include those change, but as stated that explodes the query to such a degree that due the load on perforce server our admin won't allow it to run. So this is why I am looking for an alternative approach to get the same result.
I can't see an easy answer to this, but do have a couple more suggestions that perhaps may help point in the right direction.
Persuade your admin to raise the maxscan rows limit. If he is nervous that this will lead to problems with the whole user base, just get him to add you to a new user group (e.g. "Scripting"), and set the limits for just that group. That will have the effect that only members of that group can use the upper limits, and you can then negotiate for suitable times to run the script. You could even do it overnight.
Have a look at the P4 admin guide and see if any of the hints on scripting will help - e.g. maybe a tighter view on the data will limit the query enough to not break the maxscanrows limits.
How's your SQL? You may be able to construct an efficient query using the P4Report tool.
Try asking the question on the Perforce mailing list. It's a very active list that has a lot of very experienced people who are very helpful. See this link for the sign-up page. There's a good chance that they will suggest some good approaches.
Probably too late for yoru existing labels, but consider using the job system to track work. Perforce has inbuilt query tools to track what jobs have made it into different branches. It does require a working-practice change for your team, however.
Sorry I can't provide a more specific answer.
Are your labels more than simply the most recent changelist when they were created? Eg did you really need to record specific files in client workspaces? If not you can very easily compare the two changelists closest to labels.
Say the closest change to your first label date is 23000 and your closes change to your second label date is 25000 then
p4 changes //depot/PATHTOMYCODE/...#23000,#25000
will give you all changes to your code path between these two changelists.
Won't a normal Label-diff do what you want?
From P4V, Tools->Diff. Select the two labels
From P4Win, right click label, select diff files in 2 labels
From command line, p4 diff2 //codeline/...#label1 //codeline/...#label2
Or am I missing exactly what you are after?
Further suggestion after Ville's comment on the above
If you are only after the info per changelist, rather than per file, then try "p4 interchanges" from the command line. This will give you just the summary of what changes in one branch have not happened in another, and you can supply a revision range to limit it to the labels you need.
Do "p4 help interchanges" from command line for details.
Unfortunately the interchanges command is not yet exposed in P4V or P4Win.
Toby Allen's Answer is the best approach if your labels are simple changelists.
If the labels are more complicated, then I think you need to look at all the files in each label and where their versions differ, find the changelist where the version changed.
You can get the file and version lists with:
p4 fstat -Of //...#MyLabel
EDIT:
Consider two complex labels:
VERSION_A:
//depot/file_A.cpp#4
//depot/file_B.cpp#7
//depot/file_C.cpp#1
VERSION_B:
//depot/file_A.cpp#6
//depot/file_B.cpp#5
//depot/file_C.cpp#4
In this example, the labels do not describe a particular changelist, the head change for each file may be different.
If you can have labels like this, then you can run the p4 fstat command on each label and then find the differences. In this example, file_A.cpp has changed twice and file_C.cpp has changed 3 times. file_B.cpp is older in the second label, so it can be ignored.
So now you need to look at the changes that involved these versions:
file_A.cpp#5
file_A.cpp#6
file_C.cpp#2
file_C.cpp#3
file_C.cpp#4
Those changes can be retrieved with p4 filelog, so you want to run something like this:
p4 filelog file_A.cpp#6
p4 filelog file_C.cpp#4
Then you need to remove any duplicates and any history for earlier versions.
Like I said, you only need this if you have messy lables. If there's any way to make your labels represent changelists, you should use Toby Allen's answer.