git status shows unexisting untracked file - linux

I don't know if this question should be moved to ServerFault or it belongs here!
Working on a remote Unix server, I created a file file_x.php using FileZilla.
I'm using GIT on the terminal.
When I do git status, it shows me this :
On branch master
Untracked files:
(use "git add <file>..." to include in what will be committed)
some_other_file1.php
some_other_file2.php
file_x.php
^
|__ Note this weird blank space
The problem : I wanted to delete this file, I tried from FileZilla but this didn't work, it shows me there is no such file or directory ! But the file is always there!
So I tried :
rm -rf file_x.php # This didn't work
sudo rm -rf file_x.php # I'm not from the sudoers
git checkout file_x.php # This didn't do a thing !
git clear -f # This didn't do a thing !
git rm file_x.php
==> fatal: pathspec 'file_x.php' did not match any files
My question, what does this mean ? and how do I remove this file ?

You have to escape the space:
rm \ file_x.php

Related

rsyncing git project folder

I need to rsync a git project folder and I'm using the follow rsync flags -r -a -v -u -W but when I run git status on the destination folder it does not match with git status on the source (I get modified/deleted files that were not actually touched).
Why is this happening? And how to make it work as intended?
From rsync manual:
-u, --update skip files that are newer on the receiver
So it may skip files...
Use git
Anyway, there is no need for rsync when you have the source dir versioned.
Clone the folder
cd /my/destination
git clone /my/source/repo
Sync the folder
cd /my/destination/repo
git fetch
The usual rsync command I use is
rsync --archive --delete --verbose src-dir/ dst-dir/
This makes dst-dir an exact mirror of src-dir. This will pick up everything, including your .git subdir and untracked files.

git diff on two remote servers (outside git git --no-index)

Is it possible to use the command git diff --no-index on two remote servers through ssh.
I want to use the output of the command git diff but on a non repository . Between two remote ssh directory .
I've never bridged a diff command across servers, but effectively...you'd just be using diff. git diff uses whatever system-specified diff tool you have available to compare different versions, and since --no-index would allow you to compare across non-versioned files, diff is your best bet.
You can try this:
# Get the working tree from repo 1:
git archive --format=zip --remote=ssh://<user>#<host>/repo1/<repo1 name> <tag or HEAD> > archive1.zip
# Get the working tree from repo 2:
git archive --format=zip --remote=ssh://<user>#<host>/repo2/<repo2 name> <tag or HEAD> > archive2.zip
mkdir tmpdir tmpdir2
(cd tmpdir; git init .)
# Unzip archive1 into tmpdir, make a temporary git repo out of it:
(cd tmpdir; unzip ../archive1.zip ; git add .; git commit -a -m "archive1")
# Move the .git directory to tmpdir2:
mv tmpdir/.git tmpdir2
# Unzip archive2 into tmpdir2, and compare:
(cd tmpdir2; unzip ../archive2.zip ; git diff ) > git-diff.txt
# Cleanup:
rm -rf tmpdir tmpdir2 archive1.zip archive2.zip

finding the name of git branch from remote server

i am trying to find the name of git branch on remote server using a shell script. I put the following command in a script under the bin directory.
git symbolic-ref --short HEAD
When I execute the script using ssh from another machine
ssh -i keyfile.pem user#ipaddress 'bash -s' /path/to/the/script
I get an error
fatal: Not a git repository (or any of the parent directories): .git
Not sure where I am doing wrong. Any help would be appreciated.
Thanks.
Your call to git is using the wrong working directory (likely your home directory).
In your script, either cd to the path containing the git directory or specify the -C option with git:
git -C /path/to/git/checkout symbolic-ref --short HEAD
The -C option allows you to overwrite the working directory:
-C <path>
Run as if git was started in <path> instead of the current working directory. When
multiple -C options are given, each subsequent non-absolute -C <path> is interpreted
relative to the preceding -C <path>.

git alias not receiving parameters

I've been trying to create a new alias that send files to staging area, and at the same time it commit with a message.
I've tried this:
git config --global alias.stagecomm '!git add -A && git commit -m $1'
When I try to run:
git stagecomm "Commit"
It says that it didn't match any files known to git.
Try with a sh: edit your git config --global --edit and type:
!sh -c 'git add -A && git commit -m $1'
Another option: define a script (even on Windows) without extension, called git-stagecomm
In it, put your commands:
git add -A
git commit -m $1
If that script is in your path, you will be able to call it with git stagecomm "mymessage"
Any script called git-xxx will be executed by the git bash, as git xxx.
No alias needed there.
That being said, you could also type (without alias)
git commit -am "My message"
See git commit man page.
-a
--all
Tell the command to automatically stage files that have been modified and deleted, but new files you have not told Git about are not affected.
That would not take new files though.

Script for root to git pull as another user

I have a script that I would like to have do a git pull inside another user's git directory. This script is run by the root user. For example:
cd /home/username/GitProject
sudo -u username -i git pull
When I run this, I get:
fatal: Not a git repository (or any of the parent directories): .git
Is there a way to have my script do a git pull as username?
Try without the -i option to sudo. That option is documented as first changing to the target user's home directory, which undoes the directory change you so carefully do before that. Alternatively, use the appropriate options to git to specify the directory, something like this:
sudo -u username -i git --git-dir=/home/username/GitProject/.git --work-tree=/home/username/GitProject pull
This can be done without sudo. This assumes you have password-less ssh keys since you are talking about a script. Here's the failure:
# git clone <user>#<host>:/path/to/repo
Cloning into 'repo'...
Permission denied (publickey).
fatal: The remote end hung up unexpectedly
This shows that ~ properly expands to the user's homedir:
# MYUSER=somebody
# su - $MYUSER -c "echo ~"
/home/somebody
And here's the actual command used to clone into the home directory along with some extra proofs:
# su - $MYUSER -c "git clone <user>#<host>:/path/to/repo"
Cloning into 'repo'...
remote: Counting objects: 13, done.
<..>
# ls -l /home/$MYUSER/repo/.git/config
-rw-r--r-- 1 somebody somebody 275 Nov 8 23:55 /home/somebody/repo/.git/config
# su - $MYUSER -c "cd ~/repo; git remote -v"
origin <user>#<host>:/path/to/repo (fetch)
origin <user>#<host>:/path/to/repo (push)
# su - $MYUSER -c "cd ~/repo; git pull"
Already up-to-date.

Resources