I'm merging two branches and getting so many merge conflicts like
CONFLICT (add/add): Merge conflict in pika/static/ckeditor/ckeditor/plugins/a11yhelp/dialogs/a11yhelp.js
Auto-merging pika/static/ckeditor/ckeditor/plugins/a11yhelp/dialogs/a11yhelp.js
that they do not fit into my putty terminal. So I aborted the merge and run some git diff commands.
git diff origin/dev-kasitesivu_py_3.7..origin/dev-kasitesivu -- pika/static/ckeditor/ckeditor/plugins/a11yhelp/dialogs/a11yhelp.js
diff --git a/pika/static/ckeditor/ckeditor/plugins/a11yhelp/dialogs/a11yhelp.js b/pika/static/ckeditor/ckeditor/plugins/a11yhelp/dialogs/a11yhelp.js
old mode 100644
new mode 100755
For a huge amount of files the only change seems to be mode as above (I don't know what it means). I tried to copy the files from the directory running the branch that I want to merge, but git status did not show anything changed. Neither does linux diff-commad.
How can I resolve the conflicts ?
The linux diff command compares file lines. i.e. the contents of the file. Your conflict is one of file permissions. You must select which permissions the files actually need to have. 755 is usually set on directories, but may have been set on the files in your case, by some other process or perhaps a sgid sticky bit.
You should be able to resolve your issue by setting the file permissions on the affected files to the permissions in old mode. Like:
for x in those_files; do chmod 0644 $x; done
Or something of that nature.
Related
I have recenlty changed system and few files started appearing in git diff. Its due to mode change and am ok with that for now.
I am wondering why git diff displaying mode 755, when it supposed to 775. In below screen all linux command says it is 775, but git diff says it is 755.
OS is Ubuntu 22.04.
Git only stores one bit (as in binary digit) of "mode" information per ordinary file: "executable" (+x) or "not executable" (-x). This single bit of mode information is, however, stored as mode 100755 (+x) or mode 100644 (-x).
It's no coincidence that 100755 corresponds to a Linux 0755 file mode: in fact, the 100 part is from S_IFREG in <sys/stat.h>. Likewise 100644 corresponds to a file whose mode is 0644 or rw-r--r--. In the distant past, Git did store more mode bits per file. But this was discovered to be a mistake, so now Git stores only the one mode bit—but uses the same encoding it used back when it stored more bits.
The actual file permission bits that you'll find on disk will depend on your umask setting, not on the mode 100755 setting. If you have umask 022, Git will create executable files with mode 0755 or rwxr-xr-x. If you change your umask to 002, Git will create such files with mode 0775 or rwxrwxr-x. But the old and/or new mode as shown in git diff output will always be either 100644 or 100755, and that means -x or +x respectively.
When storing a file (blob) in Git, there are only two possible file modes: 644 or 755. That is, Git stores only the executable bit, and if it is set, it stores the latter, and if not, it stores the former. Thus, for diffs, Git will only reflect whether the executable bit is set and will always use one of those two modes.
In the working tree, Git uses the umask to set permissions, which explains why your files are actually 775.
I have a project in which there is a .sh file and it has to be in the executable mode once pulled by the others. Now, I already changed its permissions on my local machine. However I want it to be pushed/pulled as executable as well, so that the other users do not have to run chmod command all the time.
I have been informed about two possibile solutions: .gitattributes and git update-index --chmod=+x script.sh, however I am not sure what exactly should I follow, given my condition.
I've seen this post here and this answer there, and I am thinking which one would suit my case more. I want this process to be done automatically, not by the user everytime, added.
Any thoughts?
Since you've tagged this question with linux, you can just check the file in. Now that you've changed it on your computer:
% chmod +x script.sh
Git will notice that the file has changed:
% git status
On branch old2
Changes not staged for commit:
(use "git add <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
modified: script.sh
And you can diff to see that the file is, in fact, now executable:
% git diff foo.sh
diff --git a/foo.sh b/foo.sh
old mode 100644
new mode 100755
Mode 100644 reflects a non-executable file, and mode 100755 reflects an executable file, similar to the Unix file permission bits. (Had you changed the file in addition to changing the permissions, you would also see the changes.)
When you check this in and your collaborators pull your changes, the file will be made executable for them, too.
Note that this does not work automatically on systems that do not have the notion of an execute bit (ie, Windows), and in that case, you will need to do something with update-index.
Note also that this relies on your system to have configured core.filemode being set correctly. This value should be set to true on all non-Windows systems.
% git config core.filemode
true
If, for some reason, that command returns false and you are on a non-Windows computer, run:
% git config core.filemode true
to re-enable it.
You have to decide which is fit for you. Two methods those you given above they can acceptable and they almost the same.
You should know how to give working permissions to executable files. In Linux, true way to do it is "chmod". Also you can sue git hooks as well. For doing in normal method I preferred this:
git add file.sh #this could be py file or something
git update-index --chmod=+x file.sh #make it executable
git commit -m "here the commit" #commit it
git push #push it
So if you want to do it another way you should try this:
#!/usr/bin/bash
chmod +x file.sh
And you can run it. But before the run it, you should give working permissions to your script that you made for giving working permissions to other scripts :)
Or you can give the permissions dynamically:
su -c 'chmod +x file.sh'
In this way, you should give the working permission for one time and it runs.
Did you consider Git hooks?
Maybe this could be solution for you
.git/hooks/post-checkout:
#!/bin/sh
chmod +x script.sh
Here you can find more about Git hooks.
I was on version 100, with local changes.
I did an svn up to reach HEAD (which is revision 200). Then I was ill adviced to revert back to revision 150, with my local changes, in command: svn merge -r HEAD:150 .
Now I actually want to go back to revision 200 with my local changes. svn up doesn't do anything, because I appear to still have file missings. I know because a file A.cpp was in revision 200 but not in my local working copy.
If I do svn status, I see a bizzare "D" in front of A.cpp. they seem to think I want to delete this file I don't even own.
What state am I in now, and how do I fix it?
In brief, your current checked out repo is messed up - it has a combination of your changes as well as a set of uncommitted changes to go back from HEAD -> r150. If you committed at this point, it would have the effect of removing all the changes that happened from 150:HEAD, and then adding in your changes.
If trying to do a re-merge: svn merge -r 150:HEAD . doesn't work (and generally it won't), then I would suggest the following:
assuming you have your current workspace <currws>
checkout a second copy of the workspace, at revision 150: svn co -r 150 <svn url> <newws>. This will give you a directory <newws>
(cd <currws>; tar cf - --exclude .svn .) | (cd <newws>; tar xf -). This will take all the files & directories from <currws> and copy them into <newws>.
Take inventory of the new directory - it should now contain copies of only your changes - some of these may need to be SVN added to the workspace; or if you have deletes, they will need to be re-deleted on the <newws>. You can pre-remove all the files/folders from new-ws prior to the tar, and anything that appears after the tar with a ! indicates a file that you removed with your changes, anything with a ? is a file that needs adding, and the remainder should be M entries.
Bring the new workspace up to HEAD - svn up <newws> should work in this case.
verify that everything's working and that it only contains your changes.
make a patch file, get it code reviewed and then commit it.
I'm pretty sure this will get you back on-track; although I don't have a tree to check against with the spotty network connectivity I have.
I have a large list of active files in my Git repository. One change I made was deleting a large number of images across a number of directories. I want to commit that change immediately but I don't want to include all active files and I don't want to manually type out git rm myfile.png for every single image.
So essentially what I want to do is run git rm on all active files ending in .png. I'm trying to accomplish this by piping the results of git status into git rm but I'm having trouble isolating the file name and getting this to work as I'd like.
Is this a proper use of piping and if so what syntax do I need?
Any help is appreciated, thanks.
If you already removed the files, you can type:
git add -u
And they will be removed from git repository.
From git help add:
-u, --update
Only match <filepattern> against already tracked files in the index
rather than the working tree. That means that it will never stage
new files, but that it will stage modified new contents of tracked
files and that it will remove files from the index if the
corresponding files in the working tree have been removed.
On Linux, I need to know which files were added/modified/moved/deleted after compiling and installing an application from source code, ie. the command-line, Linux equivalent to the venerale InCtrl5.
Is there a utility that does this, or a set of commands that I could run and would show me the changes?
Thank you.
Edit: The following commands are sort of OK, but I don't need to know the line numbers on which changes occured or that "./.." were updated:
# ls -aR /tmp > b4.txt
# touch /tmp/test.txt
# ls -aR /tmp > after.txt
# diff -u b4.txt after.txt
If you only need to know which files were touched, then you can use find for this:
touch /tmp/MARK
# install application here
find / -newercm /tmp/MARK
This will show you all files whose contents or metadata have changed since you touched /tmp/MARK (including newly added files).
I would personally use something like Mercurial (version control) to do this.
The main reason, is that it is not only effective but it is also clean, since it will only add a hidden directory to the top of the tree where you want to check these changes.
Let's say that you need to know what files changed in /etc/. So before installation (you need to have mercurial installed) you add the directory to mercurial:
cd /etc
hg init
hg add
hg ci -m "adding all files in /etc/ to track them down"
The above will effectively "add" all the files to track them. To verify nothing has changed:
hg st
Should return no files.
If you (or the installation) modifies a file, you should see something like this:
hg st
M foo.sh
The "M" before the file states the given file was modified.
For new files you would see a ? before the file like:
? bar.sh
After you are done and no longer want Mercurial, simple remove the hidden directory:
cd /etc
rm -rf .hg