Recently, I made a PR to a newly started open source repo in GitHub, where a collaborator pointed out that the tab size I used for tabs does not match the other PRs in that repo. I was confused because I preserved the orginal indentation as it'd been and furthermore, the indent style was not spaces but tabs.
Because the Files changed tab in my PR really had its data-tab-size attribute set to 8, while 3 other PRs had its data-tab-size set to 4, I thought there must be some reason behind it; I searched online and found that .editorconfig of the repo is responsible for the shown tab size; however, I did not modify that file; moreover, the files in my PR and the other PRs were of the same file type(markdown), in the same directory, and using tabs for the indentation for the code blocks.
I wonder what causes the peculiar inconsistency in the tab size in the PR UI.
Related
Changed lines were not highlighted with gutter indicators near the line number (e.g., orange and green) as normal. The changed/new file was not labeld with a "M" or "U" badge in the file tree (Explorer). The file was displayed as a modified file in the source contral panel though.
Old repositories do not have this issue, but newly cloned repos have this issue.
This issue is the same as the one reported in this Github issue, but the solution there did not work for me.
I am currently having an issue with the automatic indentation when pushing my code to Github.
I currently have my tab settings to be using spaces on VS Code (tabs set to 2 spaces), yet Github is displaying a massive jump in the organization of the code.
Below are examples of what I am experiencing:
My code looks on VS Code:
My code in Github:
Settings that I have manipulated (tabs to spaces setup on VS Code):
At this point, I don't even know if my settings are set up properly.
You need to set your preferred tab size in github as well.
Go to your Settings (under your icon in the upper right of any repository page),
Appearance/Tab size preferences <== set to 2.
So it is a guthub issue, I think github interprets a tab as 8 spaces by default for some reason.
Whenever I push or manually upload code to github extra whitespace will appear in the committed code. I'm using prettier and eslint, I've tried pushing with both enabled and disabled, and with prettier only enabled.
Code as shown on GitHub:
User Settings:
Workspace Settings:
Do you use tabs instead of spaces? Most editors allow you (like you’ve shown) to customize what a tab character shows as (e.g. 8 spaces). My assumption is that your setting is smaller than what GitHub uses for its display. GitHub doesn’t modify your code.
so setting "prettier.useTabs" to false resolves the issue, you would think that the code being pushed and code being displayed would be the same perhaps this is an issue to push to prettier's git repo but i digress, thanks for the feedback.
Is there a way in GitHub to list all commits that affects a subdirectory (i.e. anyfile or directory in its hierarchy), without having to check out the entire repo?
Just to clarify, you are not looking for the latest change, but all changes made to a folder in a branch. Because latest change is always visible on the grayish bar:
All changes made to the folder can be checked by clicking the History button right above the area I have circled with red. That ends up at this page: https://github.com/jonasblunck/ccm/commits/master/installation which is filtered for that folder. Compare it with https://github.com/jonasblunck/ccm/commits/master that contains all commits to master.
Everything is good in Eclipse, indenting is fine. Then I put my code on github
and for some reason the indenting was a mess. I am not sure what is going on?
Thanks
If those indentation issues are reflected back in your code after a git push to GitHub, you either have:
a hook removing spaces before tab (as in "Make git automatically remove trailing whitespace before committing")
or a filter content driver declared ina .gitattributes file (as in "Can git automatically switch between spaces and tabs?")
Those are the two automatic mechanisms that could explain a change during the git commit.
But if your code looks fine locally after the git push, but looks not fine on GitHub, then you must have a combination of space and tabs correctly rendered locally, and rendered differently on GitHub.
As mentioned in "Indentation issue using sublime text 2":
The problem is not hard tabs, the problem is mixing spaces and tabs for indentation.
I got this working in eclipse:
Eclipse Settings:
Preferences : Java -> Code Style -> Formatter
Create new profile
Update profile indent settings:
Update Existing Java Source:
(Toolbar) Source : Correct Indentation
Check file, you should see all indentations use spaces, not tabs