I am using the github windows app. I seem to be having problems with it showing what has changed and what hasn't. Before I commit it correctly shows only the changed lines, but after I commit, it shows that all the lines have changed in the file. Any way to get it to stop this?
It is quite annoying and any help would be appreciated.
ps, i made sure that their are no line ending issues.
This is usual core.autocrlf issue (different setting in your clients and definitely wrong in Github client) - read "Formatting and Whitespace" topic and core.autocrlf part of it carefully
PS: you can test my statement using differ, which can ignore EOL-difference in compared files
Related
I have a problem with Gitlens extension. Firstly, Gitlens or Git History extension is working fine on any other project except the this Laravel project. My problem is, can`t see the file history or line history in this project.
On the other hand, there is no problem in the git log (Git History Extension) as seen in screenshot;
But I can't compare any files with their any version (every commit seems like in the ss). I have no idea what the problem is about.
Lastly, I don't think the problem is about extension settings because other projects do not have this problem. Is there a any chance to fix this issue without resetting git history?
I am answering after 3 months, maybe it works for someone. As I mentioned in the title, surely there is no problem about extension settings for this specific project. The problem is just about git files. Maybe, I damaged some git files while moving the project on my desktop :)
So, there is no chance to fix this issue without resetting git history or starting fresh with git, if you`re having the same problem.
Do not play with git files, it`s no joke!
I've got a similar issue. My problem is in using symbolic links for folders.
I have this folder symlink for my repos.
C:\>dir
Directory of C:\
27.09.2018 21:07 <JUNCTION> repos [C:\Users\Qwerty\repos]
(GitLens v11)
The top editor is opened via C:\repos
The bottom editor via C:\Users\Qwerty\repos
You can see that some git features still work (yellow), but others don't.
However, this is very strange, because in my other repos, I have never observed such issues.
Also notice below that it is still possible to invoke the same action via a git lens popup and then it is possible to use the Prev Next Revision buttons.
Anyway, after more testing, I actually observe the same thing in my other repos. I assume that something must have changed between versions as I only observe these issues for last maybe 2-3 months. I even submitted a ticket that GitLens stopped working in v12.0.0 and later versions https://github.com/gitkraken/vscode-gitlens/issues/1979
The buttons completely disappeared and even the commit information
v11
v12
And Now actually, after having reopened my repo via original path and after updating GitLens back to v12.0.6 I see that it is working properly!
Bottom editor is opened via C:\repos symlink.
I am using Git for Windows (version 2.15, but the same issue occurs in 2.14 and I think older versions as well) and I noticed a rather annoying behavior: When I perform some basic git operations*), the modification date of the .git/objects/pack/pack-*.pack file changes. The file itself remains unchanged, but the last modification date field gets updated, which causes my backup software to think the file was changed and needs to be added to my differential backup. Because my .pack files are rather large, this increases the size of my daily backups significantly. Is there a way to prevent this behavior? That is, keep the pack file completely unchanged, including its metadata, until I perform a git gc or git repack?
Unfortunately, I wasn't able to pinpoint which operation causes this behavior. When it happened today, I only used git status, git log, git add, git mv and git commit and nothing else and the date/time got changed, but when I tried to replicate the behavior on my yesterday's backup, the date change didn't occur. I guess next time I will run Process Monitor and watch accesses to the file, but in the meanwhile, does anyone have an idea of what might be causing this problem? Thanks.
Instead of referencing your Git repo itself for your backup program to process (with the date issue), you could have:
a task which does a git bundle of your repo (that generates only one file)
your backup program would back up only that one file.
That way, you bypass entirely the modification date issue for those pack files.
You can either save and keep only one copy of a full bundle of the repo.
Or make incremental bundles.
In the end it turns out that Edward Thomson's answer explains why no "real" solution is possible. However, to facilitate my needs, I wrote a simple Windows command-line application which scans through a tree of directories, locates possible Git repositories, locates their packfiles and changes the date/time of each .pack file to that of the respective .idx file. So far it seems to run OK. I did not encounter any garbage collection issues yet, anyway. I did not release the tool yet, because I rather suspect no one else cares, but if someone is interested, I can upload it somewhere.
Apparently, someone is interested. So the program is released as of now. Not on GitHub, but still as open source, under the 3-clause BSD license. Download the binaries here: https://www.pepak.net/files/git/gitpacksync-0.01.zip
and the source code here: https://www.pepak.net/files/git/gitpacksync-0.01-source.zip
If you try to disable this then you would be prone to see subtle bugs where objects that are still in use will disappear from your repository.
You had trouble pinpointing the exact operation because every operation that adds files will do it.
This is very much intentional - Git refreshes the timestamps of objects in the database (updating the timestamp on either loose objects or packfiles) to know when an object was last written. Whenever you create a new commit, it will update the timestamp on all the files that contain objects hat were referenced.
This is important as it helps the tools that remove data (like prune) avoid race conditions: an object may be dereferenced and then re-referenced. Prune will also look at the timestamp, so by touching the file, it will not be eligible for garbage collection.
This might be a bug but I've never seen a bug in Git before, and I can't find any mention of this issue on the intertubes, so for now I'll assume user stupidity.
I use Git a great deal so I've set up an alias to bring up a birds-eye view of the git log: alias gl='git log --pretty=oneline --abbrev-commit'. So when I'm juggling between different branches, I'll frequently type gl to pull up the log, then q to exit. I find this super convenient.
But today I've noticed something strange: it looks like the most recent two commits are excluded from this view. Here's sample output from gl for one of my active projects:
b6e802d Location autocomplete; major refactoring and cleanup
d0cecdf Admin can download CSV of all users
0149ea2 Changed some verbiage on terms, privacy and profile page
5c0bdff Changed the link for find coach to go to the coaches page
But if I output gl to a file like gl > gitlog.txt, the first few lines are:
5e57f97 City autocomplete supported in mobile navbar search
df43a02 Add firstname & lastname to admin's users CSV download
b6e802d Location autocomplete; major refactoring and cleanup
d0cecdf Admin can download CSV of all users
0149ea2 Changed some verbiage on terms, privacy and profile page
5c0bdff Changed the link for find coach to go to the coaches page
Note that the top 2 lines in the latter are not present in the former.
If I open up the normal git log, all commits are visible as expected.
EDIT: I just discovered that I can work around this for now by piping (redundantly, I think) to less: gl | less shows all commits as expected.
I never noticed this happening before now (ie. the past couple weeks); I've recently updated to a newer Git version, could that be related? Has anyone else seen this happen? What should I do to figure out what's going on here? I don't even know where to start. Does this look like a bug?
Numbers:
Mac OSX 10.9.5
Git 2.2.1
Are any other numbers relevant?
Thanks for reading!
This isn't a complete answer, but I just made a couple observations:
This is only happening with one particular repository. The git log works fine on other projects.
I've added several more commits in the last day or two, and all of those commits are excluded. So it's not that the latest 2 commits are hidden so much as that every commit after a certain one are being excluded.
The earliest commit being hidden begins with the following line:
Add firstname & lastname to admin's users CSV download
Given the behavior of the error, I think there's a bug with Git's log printout that causes some commits to be hidden if a commit message contains &. So the lesson for me, for now, is to not use & in Git commit messages.
Just reproduced this behaviour happening with an old git version (2.6.x), but I updated it (2.19.1) and it was then fixed.
I'm seriously about to stop coding and become a carpenter. This problem has had me stressed out for quite some time now and there doesn't seem to be any clear solution, other than forcing non-windows machines to use the file permissions windows seems to inflict.
Let's begin with the scenario. I have 2 development machines, one running Windows7, the other Mac OSX. They both are using Eclipse and EGit, and both have cloned the same project from a remote repo. That's where the similarities end, because my windows machine has a nasty habit of retaining a file mode of 644 (r-xr--r--) on its local repo, while the mode on the Mac defaults to a cool 775 (rwxrwxr--x).
So the problem's obviously the file permissions - GIT reports there are files that have changed due to differences in file modes and not actual content. The solution seemed obvious, run the following commands:
git config core.filemode false
git config --global core.filemode false
...which worked like a charm, except when committing and merging resolved conflicts.
For example, say files A, B and C exist on both the Windows and Mac repos. Next, let's change the file mode for these 3 files on the Mac machine so that the developer can edit them. Now change some of the contents in file A. Because we're ignoring the file modes (thanks to the commands above) only file A will be committed and pushed, ready for the Windows machine to fetch, merge and enjoy...
Now, let's edit file A again on the Mac and on the Windows machines, effectively causing a potential conflict, and let the Windows machine commit and push file A first. Then, when the Mac user commits their changes to file A and fetches the latest changes from the remote repo, a conflict is obviously created.
After resolving the conflict on the Mac machine and adding file A back to their local repo, committing that merge includes the previously ignored files B and C, and thus highlighting my problem! Why are the previously ignored files being included in this merge commit? This doesn't seem to be a Mac / Windows problem exclusively, as this problem can be recreated both ways...
This probably wouldn't matter if there were only 3 files, but this project I'm referring to includes thousands, and all these up and down push and pulls are insane. Am I missing something really obvious? Any help will be greatly appreciated!
So after a long and often frustrating run with trying to get Windows and Mac OS machines to like each other when comparing notes and changes over Git, it seems to just be the functionality of Git itself that's driven me mad, and a better understanding of how to better use Git seems to be the final answer.
Originally, I wanted to know how to continue ignoring file-mode changes (which Windows seemed to love updating with its own idea of what permissions and modes should be) while I was resolving conflicts created from updates to the files from someone else. Short answer: you can't. It's just the way Git works.
So how would you deal with this situation when it came up? Short answer again: use branching.
In my original way of using Git, I was continually working on my master branch on my local repo - bad idea already - so all my work would be committed there and all conflict resolution would need to be handled there too, forcing all files to be compared again and all permissions and file modes to come into question.
With branching, you work on another branch, commit to that branch, pull updates to your master branch, and merge you other branch with your master branch after that. Suddenly no more conflicts on the master from the remote repo, and you're winning!
Commands to do this (creating a branch from currently selected branch):
git branch newbranch
To checkout your new branch:
git checkout newbranch
To merge your new branch with your master branch (after you've committed to your newbranch, switch to the master first):
git checkout master
git merge newbranch
Hope this helps someone! -:)
well tbh, I'm not sure how you arrived at your conclusion since the obvious problem is git is not ignoring the file mode changes. This happens to us here too.
if you set that flag it seems to make no difference in some cases and still uses file modes to determine changed files.
that has to be a bug in git, what else could it be?
possibly your answer does not explain the rationale, therefore I dont think it's the correct answer, it's a workaround.
the correct answer is that git doesnt use filemode when it's told not to, it's obviously ignoring that and doing it anyway.
can you explain otherwise.
Here's the scenario I'm currently running into:
Programmer A (Using a Mac Version of Dreamweaver) edits file client.php and commits that file to the production branch of Project Foo's repository
Programmer B (Using a Windows Version of Dreamweaver) edits file client.php to fix a bug in the that file. He then does a cp clientInfo.php ../prod-branch/clientInfo.php to take that bug-fix from his working copy to the production branch.
Programmer B then does an svn diff ../prod-branch/clientInfo.php to see what svn says his changes were only to discover that svn says he's changed every line in the file!
Now, this is what I believe is happening:
When the file gets edited by Mac, Dreamweaver on Mac replaces all the Windows newline characters with Mac newline characters so that it's readable in Dreamweaver. In short, Dreamweaver has altered every line in the file. Now, once the commit is done, svn sees that every line of the file has changed and marks this fact down. When the windows programmer makes a change and the newline characters get changed again, svn thinks that, again, every line has changed.
My question is this: How can we prevent this from happening? I know there's no way to undo the damage that's already been done, but I want to prevent this from happening in the future.
You need to use the "svn:eol-style" property on all text files. Usually setting it to "native" will suffice
Dreamweaver has an option to set which line break type it uses. Edit (on Mac: Dreamweaver ) -> Preferences, Code Format, Line break type.
Get your users to have the same setting, and things should play a little better together. It would be better, of course, if you can set your source control to ignore line break differences.
svn:eol-style is a property that can be set centrally in the repository and should sort out your problem.
Check out the chapter on New Line Sequences in the Subversion book.
The solution to this problem is the svn:eol-style property. When this property is set to a valid value, Subversion uses it to determine what special processing to perform on the file so that the file's line ending style isn't flip-flopping with every commit that comes from a different operating system. The valid values are: