My company has a policy that all checkins to a particular project must follow a specific multi-line template for git commits. How can I most simply create a single commit message that has multiple lines from the command line in Windows?
This is almost exactly a duplicate of "Add line break to git commit -m from command line" except that this question is specific to Windows/cmd.exe, while that question is related to bash.
Either create a file that contains your commit message in the right format and use git commit -F <message_file>, after which you can continually edit and reuse that same file, or create a template file and use git commit -t <template_file> to open your editor with the pre-cooked template to be filled in. The second option can be made permanent by setting the commit.template configuration variable, so you don't need to use the -t ... bit on every commit. See the git commit manual page (git help commit, if your git is installed correctly, or search online) for more information.
You can create multiline commit message like this:
C:\> git commit -m "Line 1"^
More?
More? "Line 2"^
More?
More? "Line 3"
Note, that the circumflex character is only on odd lines.
git commit -m "Subject" -m "Description..."
You can also use interactive rebase and then reword for editing the commit's message.
Type git commit -m "doesnt really matter whats here" and then git rebase -i HEAD~1, replace pick with r or reword, save and then edit the message.
Related
I'd like to be able to occasionally use a different editor when writing commit messages. I've found plenty of answers on how to change the default editor, but I don't want to change that - VIM is normally fine. What I'd like is some option like git commit --editor=<editor_name> where <editor_name> is the editor I want to use when writing the commit message for that commit only.
The only thing I've found that is similar to what I'd like is opening a new file with <editor_name> <newcommitfilename>, write message, save and close file, then use git commit -F <newcommitfilename>.
Is there an easier way to achieve this?
Thanks!
All Git commands use the form:
git <verb>
You may insert options before the verb, e.g.,
git -c core.pager=cat show
The -c option in particular takes a configuration item name, such as core.pager, core.editor, user.name, and so on, and a value, joined with an equals sign = like this.
Since your goal is to use a particular editor, git -c core.editor=whatever commit does the trick.
As several commenters noted, there are other ways to do this. For the editor in particular, the environment variable $GIT_EDITOR overrides core.editor, so:
GIT_EDITOR=nano git commit
runs git commit with GIT_EDTIOR set to nano for the duration of the one command (assuming POSIX-style shell).
I want to merge a remote repository to a new repository on GitHub. I have tried the following bash commands:
git init
git commit --allow-empty -m "Initial dummy commit"
git remote add --fetch old_a <OldA repo URL>
git merge old_a/master --allow-unrelated-histories
After executing the last command, this screen pops up:
Here bash is asking me to enter a commit message. But typing appears to be prohibited everywhere except in the yellow line. Not only that, I can't even terminate this prompt if I want to go back to the command line. There seems no way to break out other than closing bash itself. So how do I proceed from here?
PS: I have already tried to change my default git editor to vim using the following commands:
git config --global core.editor vim
As well as,
export EDITOR="vim"
But both of these commands didn't work.
This is not an issue, all you need to do is
Press Insert Key and then Enter Key. This will allow you to type a message
Once you have done that Press Esace (Esc) then :wq to exit
I tend to stash changes without remembering why I stash them.
I do make it a point to git stash push -m most of the time, but if there's a fire drill or something else that knocks me out of flow, I may forget and lose time trying to recover.
Is there a way to imitate the behavior of git commit (minus the -m) for git stash where vim pops up and abandons the operation if the message is empty?
AFAIK there's no config option for this. You'll have to write an alias in your .gitconfig and train yourself to use it.
For example, I have two stash aliases git pop and git save. (You can see I didn't get the memo about git stash save being deprecated). These are both for convenience, and to change the default behavior to something I find more useful.
save = stash save -k -u
pop = stash pop
Unfortunately git stash push -m doesn't bring up an editor, if you need to write more than a few words to describe what you were doing consider a branch instead. We can fix this by writing a little shell function and passing the argument to -m using "$#" to ensure messages with spaces are a single argument.
savem = "!f() { git save -m \"$#\"; }; f"
Now you can write git savem 'remember to remember what this was'.
$ git savem 'remember to remember what this was'
Saved working directory and index state On issue/45: remember to remember what this was
And if you forget, you'll get the normal git-stash usage message. You can snazz up the alias to provide a custom usage message if you like.
$ git savem
usage: git stash list [<options>]
or: git stash show [<stash>]
...
To me it makes sense to consider using a branch for this. It seems like you want to keep the changes. Branches can be named so it’s easier to recall what was being worked on. These can be local or pushed to remote in case it wasn’t a drill.
$ git branch topic/wip
If you want continue work on master yo can do a
$ git checkout master
Not pretty but could be achieved using bash + vipe in moreutils
msg="$(< /dev/null vipe)";
[[ -z "$msg" ]] || git stash -m "$msg"
I have several repos that have been converted from SVN. Each time I attempt to run git rebase -i master, the message defaults to noop. When saving, I get Successfully rebased and updated refs/heads/master which seems suggest it has done something, but all commits are still present.
I did find this question but the solution doesn't appear to apply to OsX.
I also tried git rebase -i HEAD~3 on a project with 3 commits, but I get:
fatal: Needed a single revision
Using rebase -i HEAD~2 will and rebases correctly, but I need to squash these to a single commit with the init commit date.
Interestingly, the rebase consistently misses the earliest commit on each project. In each it it the only commit not assigned to my user (it is a system commit), so I wonder if that is related.
The question cited has a possible answer: Setting the shell variable IFS (what characters are interpreted as separating "words" in shell lines, in this case separating arguments) makes two arguments interpreted as one (obviously unknown), and the (internal) command fails with the cited result.
See to what (if anything) IFS is set (echo $IFS). Try (unset IFS; git rebase -i HEAD~3) (the parentesis are required here in bash(1), OS X shell could be different, but I doubt it).
In my repository, which has mixed line endings.
I am using Mac OS X, and git 1.8.3.1
I would like to renormalize this repository so that every file has line endings that agree with the .gitattributes file.
To this end, I have checked out the latest change:
git checkout origin/develop
git reset --hard
git rm -rf .
git rm --cached -rf .
rm .git/index
git checkout HEAD .gitattributes
git reset --hard
git status
Now, git rm --cached -rf . will cause an error, but I am being very paranoid with the above command. (On my machine, those commands were on one line, ignoring exit codes)
I repeat the command many times. (Ie, UP; ENTER; UP; ENTER; UP; ENTER;...)
Most of the time, I have a clean check out, which is not what I am expecting.
However, roughly once every ten times, I find that I get three files (which seem to be correctly renormalized). The remaining times there is no renormalization.
The output of such a file that gets renormalized (Ie, is 'modified') is:
$ file source/RemoveDuplications.cs
source/RemoveDuplications.cs: UTF-8 Unicode (with BOM) C++ program text, with CRLF line terminators
My git attributes file has a fair number of entries, but the relevant one is here:
* text=auto
*.cs text eol=crlf
What might be going wrong here?
It looks like what you are doing may be overly complex. You shouldn't need to remove all files from the repo or delete the index by hand. Have you tried:
git rm --cached -r . # remove everything from the index
git reset --hard # replace files w/ corrected line endings
git add . # stage all changes
git commit -m "Normalize line endings"
If this isn't working for you I'd re-check the values of your core.autocrlf and .gitattributes. You may need to clear those, reset your shell, check out the repo again and then reset them to get the behavior you want.
Here are some other resources that might help:
Github - dealing w/ line endings
A similar question here with multiple answers to consider
A good post about the pros/cons of this approach vs git filter-branch
You could always use something like a sed script to edit the files and then recommit them to see if this keeps happening. If you do this from the command line, you should, using the proper regex, be able to pull out any hidden characters that might be causing your problem.