svn commit from bash script without opening the editor - bash

I try to write a bash script which should commit to a svn repo. Everything works fine until the point where I try to commit. The commit command opens the editor and the script ends with an error that the commit message was left in svn-commit.tmp
I try a couple of things but none will work
commit_msg="$1"
svn commit -m "$commit_msg"
and
commit_msg="$1"
svn commit -m '$commit_msg'
and
commit_msg=$1
svn commit -m '$commit_msg'
and all with the -q and --non-interactiveoperators. Even svn commit -m "woohoo" opens the editor and the script ends with the error.
Any ideas why it is impossible to commit within a bash script without opening the editor?

You should use the --non-interactive option on the svn command:
svn commit --non-interactive -m '$commit_msg'

After I tried svn ci instead of svn commit, everything was fine. My first thought was a buggy version of svn. Asking the Great Dump (aka Google) I found the solution:: In my .bash_profile was a code snippt that forced the svn commit always to open the editor while svn ci worked as expected.
I don't know exactly where the code snippet came from, but windows users have to fight a lot of mysterious behaviours.
Thanks all for your help.

Related

difference between git --git-dir checkout and git checkout

git checkout acts differently for using option --git-dir.
Commands :
inside_gitdir$ git checkout remote/branch
outside_gitdir$ git --git-dir=/path/.git checkout remote/branch
Here command 1 works well and checking out. but the command 2 shows to move files like :
error: The following untracked working tree files would be overwritten by checkout:
someFiles
Please move or remove them before you can switch branches.
Aborting
I thought both the commands are running in same way. But,
Why am i getting this error in second command not in first ?
What is the difference of using --git-dir option ?
I ran into the same issue.
It seems to work if you do: git --git-dir=/path/.git --work-tree=/path/ checkout remote/branch

Git for Windows "No tags file" Response from "git diff" Command

Git version: 2.14.2.2
Whenever I run git diff on a repository I am greeted with the response No tags file. I have tried running the command on multiple repositories, multiple consoles (Cmd, PowerShell, MINGW64, Visual Studio Command Prompt) and all have the same response.
Strangely, the git log command also fails. Many other commands work, however, such as git status, git pull, etc. It seems to be only log and diff.
I have uninstalled Git entirely and reinstalled. Restarted my system. Tried referencing the git.exe directly (which yields the exact same response). Nothing is working and I have not seen this error anywhere else. I compared my user configs with those of a colleague and they are identical.
Some portion of the command executes properly, because if I supply two commit hashes, and I intentionally break one, the response I receive is:
It seems like another program may be hijacking the git diff command. I believe this because I'm not sure "No tags file" is even a possible Git response. Not sure what else it would be.
To make things even more confusing- my ultimate goal is to run the git diff within the context of an msbuild and it DOES EXECUTE CORRECTLY. Now, I could be satisfied with this, but I need to modify the diff command slightly, and running a full build each time is not productive, nor easy to troubleshoot. There is a task within the build script that runs an Exec command and it has no issues performing the diff. I'm also able to execute a Diff Against Current within SourceTree, which to the best of my knowledge, runs a git diff behind the scenes.
Any help would be very much appreciated.
:: Edits ::
Various commands:
git diff HEAD~1 HEAD
git diff master~1 master
git diff <commit-hash-1> <commit-hash-2>
git log HEAD~1..HEAD
git log master~1..master
git log <commit-hash-1>..<commit-hash-2>
Output:
Every one of the commands above returns the same No tags file response, in all of my repos.
Cat Head:
cd .git
cat HEAD
ls -R refs
Output:
New Repo:
mkdir testrepo
cd testrepo
git init
echo "file1" > file1.txt
git add .
git commit -m "initial commit of file1.txt"
echo "Hi there!" > file2.txt
git add .
git commit -m "added file2.txt"
git log
git diff HEAD~1 HEAD
Output:
git config -e:
git config --global -e:
::Edits 2::
I uninstalled all of my diffing/source control tools (SourceTree, Git, SVN, WinMerge, KDiff). Installed the portable version of Git. Opened CMD to a repo, put in full path to the git.exe portable and it still returned the No tags file response.
I also reviewed all of my path variables for: git, vim, ming, mintty and anything else that seemed suspect, but didn't find any.
I have restarted after performing all steps, and yet the problem persists.
::Edits 3::
I have a different user on my laptop, switched to that user and the git diff works properly, so clearly there is something with my main user that is conflicting. Will continue to look into my User directory for issues.
Here are the steps I'd take in this situation:
Try the following and check the response:
git diff HEAD~1 HEAD
git diff master~1 master
git diff <commit-hash-1> <commit-hash-2>
Try the same with log:
git log HEAD~1..HEAD
git log master~1..master
git log <commit-hash-1>..<commit-hash-2>
I'm actually guessing that your refs are messed up, which means that the direct hashes might work, but the HEAD and/or master one may not.
Look into the .git/refs folder
From the main repo folder:
cd .git
cat HEAD
ls -R refs
Hopefully, HEAD is pointing to a branch, and if master is checked out, cat HEAD output should look like:
ref: refs/heads/master
Then, the ls -R refs, should show a heads folder, with files for each of your local branches (i.e. master and possibly others). You also likely have refs/remotes and refs/tags directories.
If any of these things are radically different or missing, that could be your issue...
Since you have reinstalled git, create a brand new repo and try the same commands:
mkdir testrepo
cd testrepo
git init
echo "file1" > file1.txt
git add .
git commit -m "initial commit of file1.txt"
echo "Hi there!" > file2.txt
git add .
git commit -m "added file2.txt"
git log
git diff HEAD~1 HEAD
If this last one works, then git is likely working okay, but some tool you have is messing things up.
Post your config from git config -e and git config --global -e - maybe we can see something?
When googling for the "No tags file" message, the first results I get all talk about vi.
I do not understand why git would try to execute vi when running git diff or git log, could it be that your system is configured to use vi as a pager ?
# some possible places which could influence that :
echo $PAGER
echo $GIT_PAGER
git config --get core.pager
When digging in the documentation for less, I found that less can use a ctags file, to spot "the file that contains this tag".
So you can also look at the list of variables that influence the behavior of less :
# from bash :
# env will list all the defined environment variables
env
# the ones that impact 'less' should contain "LESS" in their names :
env | grep LESS

Watch for file changes and add changes to github?

On OSX I want to create a script that 'when a file changes, automatically runs
git add [FILES CHANGED];
git commit -m "Changing ${file names}";
git push -u origin master"
I understand there is fswatch, however, this keeps a process running.
Maybe I can try running "git status" and if != "On branch master
nothing to commit, working directory clean" then automatically push to Github?
I know this is an old thread, but I was also looking for an alternative solution and found rerun2. Perhaps it will also be useful to somebody else.
https://github.com/tartley/rerun2
From Tartley's readme:
It runs COMMAND every time there's a filesystem modify event within
your current directory (recursive). For example, it can re-run tests
every time you hit 'save' in your editor. Or it can re-generate
rendered output (html, SVG, etc) every time you save the source (e.g.
Markdown or GraphViz dot).
COMMAND needs to be a single parameter to rerun, hence if it contains
spaces, either quote the whole thing:
rerun "ls ~"
or escape them:
rerun ls\ ~
How to implement:
If you take your code, and put it inside an update.sh script:
#!/usr/bin/env bash
git add -u
git commit -m "Automatic update of modified files" && git push
Make it executable:
chmod u+x gitpush.sh
Create an alias to make things easier:
alias gitpush=/path/to/gitpush.sh:
Open the terminal, got to the directory you want to watch and run the command:
rerun gitpush
Now it will execute gitpush everytime files changes in that directory.
If you're willing to give up automatically responding to file modifications, you could just periodically run (e.g., via a crontab entry or something):
git add -u
git commit -m "Automatic update of modified files" && git push
The git add -u will stage any modified files, and "git commit" will only be successful if there are modifications to commit.
If you also want to pick up new files, you could use git add -A instead.

How to call Git Bash from Windows and preserve autocrlf

I have automated python scripts for git versioning system. It works on linux, but I have some problems on windows. I will go directly to the core of the problem...
There are sources ended by LF (not CRLF) and Windows Git Bash can handle it perfectly (checkout as Windows style and commit as unix style).
When I open Git Bash and type "git status" I get
your branch is up-to-date.....nothing to commit, working directory clean
When I open cmd.exe and I write "git status"
....
modified: example.h
modified: example.cpp
....
the modification is just because cmd.exe does not handle autocrlf. the monification is just in line endings.
I tried a workaround:
c:\myrepo>echo git status|"C:\Program Files (x86)\Git\bin\sh.exe" --login -i
output:
Welcome to Git (version 1.9.2-preview20140411)
Run 'git help git' to display the help index.
Run 'git help <command>' to display help for specific commands.
xxx#yy /c/myrepo (master)
$ git status
On branch master
Your branch is up-to-date with 'origin/master'.
nothing to commit, working directory clean
xxx#yy /c/myrepo (master)
$
xxx#yy4 /c/myrepo (master)
$ logout
This almost solves my issue, but there is an annoying welcome message which makes my script not working.
Another workaround could be without --login -i:
c:\myrepo>echo git status|"C:\Program Files (x86)\Git\bin\sh.exe"
output:
....
modified: example.h
modified: example.cpp
....
The command without --login -i solves the welcome issue, but it does not autoclrf.
I could delete welcome mesage file , but I want my project to be usable after checkout without deleting anything in system.
Is there some painless solution?

Git-bash tab completion: "fatal: Not a git repository: '.git'" (Windows)

I'm using git on windows with the git bash and every time I want to autocomplete a filename in a git command I get fatal: Not a git repository: '.git' posted between my already typed characters and the completed ones.
It looks like this:
$ git diff a
<using tab>
$ git diff afatal: Not a git repository: '.git'
pp.js
I can still make the command properly by just pressing enter as expected. But it really starts to get on my nerves.
Any suggestions?
The problem was an extra .git-folder in my src folder. The repository was initialized on the folder above (src/..) and this seemed to mess with git. After the removal of the extra .git folder the problem disappered.
I just discoverd the solution. I had an extra .git directory in my src-folder which seemed to mess with git (the repository was initialised on the folder above).
After I removed the extra .git folder the problem disappered.
It can depends on the msysgit version you are using:
I just tested a tab completion on a git diff on W7 64bits, with the latest msysgit1.8.3, and it worked just fine.
Don't forget that, in addition to the msysgit version, you will have issues with tab completion due to the old bash 3.1 included in mysysgit.
And the completion can be slow on Windows.
As the OP Zeeker mentions below, the completion git-completion.bash is based on a proper git repo path detection.
# __gitdir accepts 0 or 1 arguments (i.e., location)
# returns location of .git repo
__gitdir () {
...
}
And in Zeeker's case, an extra .git folder was in the src folder, which means any completion was based from the wrong folder, which, for git diff, proved fatal.
git add seems to work though.
git-bash completion for git commands is controlled by the /etc/git-completion.bash. To fix run git-bash as administrator, then:
cd /etc
mv /etc/git-completion.bash /etc/git-completion.bash.orig
Then create a new one from the contents of https://github.com/git/git/blob/master/contrib/completion/git-completion.bash

Resources