In my commit-msg hook git passes commented lines from amend prompt to the script hook.
msg="$(cat "$1")"
When I am doing git commit --amend the output of the msg is
GRP-0903 CHANGE OTHER - Enhance commit-msg hook to restrict commit messages # Please enter the commit message for your changes. Lines starting # with '#' will be ignored, and an empty message aborts the commit. # # Date: Sat Jan 28 19:41:37 2023 +0400 # # On branch fix/GRP-0903-Button-icons-visibility-issue # Your branch is up to date with 'origin/fix/GRP-0903-Button-icons-visibility-issue'. # # Changes to be committed: # modified: .husky/commit-msg # deleted: tools/git-hooks/pre-commit.sh #
This is my original commit message - GRP-0903 CHANGE OTHER - Enhance commit-msg hook to restrict commit messages. The rest is coming from the amending prompt.
This is the content of my editor when I am using amend.
GRP-0988 CHANGE OTHER - Enhance commit-msg hook to restrict commit messages
# Please enter the commit message for your changes. Lines starting
# with '#' will be ignored, and an empty message aborts the commit.
#
# Date: Sat Jan 28 19:41:37 2023 +0400
#
# On branch fix/GRP-0903-Button-icons-visibility-issue
# Your branch is up to date with 'origin/fix/GRP-0903-Button-icons-visibility-issue'.
#
# Changes to be committed:
# modified: .husky/commit-msg
# deleted: tools/git-hooks/pre-commit.sh
#
When I do a normal commit without amending, it works fine.
How can I make git pass only commit message to the hook ?
I'm not aware of a way to get the message directly without the template, but you could emulate this by greping the commented out lines away instead of calling cat $1:
msg="$(grep -v '^#' $1)"
Related
With
git reflog
output log look like this
8b388bc (HEAD -> master) HEAD#{0}: commit (amend): tempppp22222
7c33c70 (tag: v2.0) HEAD#{1}: commit: tempppp
76702b2 (origin/master, origin/HEAD) HEAD#{2}: reset: moving to HEAD^
fc1ea9d HEAD#{3}: commit (amend): temp2
0bc8223 (tag: v1.0) HEAD#{4}: reset: moving to 0bc8223
but when I try
git reflog | grep "HEAD#{1}"
the output look like this
7c33c70 HEAD#{1}: commit: tempppp
Can someone tell me why the tag name is missing?
git reflog --help:
OPTIONS
Options for show
git reflog show accepts any of the options accepted by git log.
git log --help:
OPTIONS
--no-decorate, --decorate[=short|full|auto|no]
Print out the ref names of any commits that are shown. If short is specified, the ref name prefixes refs/heads/, refs/tags/ and refs/remotes/ will not be printed. If full is specified, the full ref name (including prefix) will be printed. If auto is specified, then if the output is going to a terminal, the ref names are shown as if short were given, otherwise no ref names are shown. The option --decorate is short-hand for --decorate=short. Default to configuration value of log.decorate if configured, otherwise, auto.
TL;DR: use --decorate
I am using 'git log' on the windows7 command line and it is very slow.
I tried: Git/Bash is extremely slow in Windows 7 x64
but this did not help. How can i speed things up?
Check if the issue persists with the latest Git for Windows Git 2.20.1
And Git 2.21 (Q1 2019) will improve the speed for a particular form of git log:
git log -G<regex> looked for a hunk in the "git log -p" patch output that contained a string that matches the given pattern.
Optimize this code to ignore binary files, which by default will not show any hunk that would match any pattern (unless textconv or the --text option is in effect, that is).
See commit e0e7cb8 (14 Dec 2018) by Thomas Braun (t-b).
(Merged by Junio C Hamano -- gitster -- in commit ecdc7cb, 14 Jan 2019)
log -G: ignore binary files
The -G<regex> option of log looks for the differences whose patch text contains added/removed lines that match regex.
Currently -G looks also into patches of binary files (which according to LibXDiff) is binary as well.
This has a couple of issues:
It makes the pickaxe search slow.
In a proprietary repository of the author with only ~5500 commits and a total .git size of ~300MB:
searching takes ~13 seconds
$time git log -Gwave > /dev/null
real 0m13,241s
user 0m12,596s
sys 0m0,644s
whereas when we ignore binary files with this patch it takes ~4s:
$time ~/devel/git/git log -Gwave > /dev/null
real 0m3,713s
user 0m3,608s
sys 0m0,105s
which is a speedup of more than fourfold.
The internally used algorithm for generating patch text is based on
xdiff and its states in LibXDiff:
The output format of the binary patch file is proprietary
(and binary) and it is basically a collection of copy and insert
commands [..]
which means that the current format could change once the internal algorithm is changed as the format is not standardized.
In addition the git binary patch format used for preparing patches for git apply is different from the xdiff format as can be seen by comparing.
git log -p -a
commit 6e95bf4bafccf14650d02ab57f3affe669be10cf
Author: A U Thor <author#example.com>
Date: Thu Apr 7 15:14:13 2005 -0700
modify binary file
diff --git a/data.bin b/data.bin
index f414c84..edfeb6f 100644
--- a/data.bin
+++ b/data.bin
## -1,2 +1,4 ##
a
a^#A
+a
+a^#A
with git log --binary
commit 6e95bf4bafccf14650d02ab57f3affe669be10cf
Author: A U Thor <author#example.com>
Date: Thu Apr 7 15:14:13 2005 -0700
modify binary file
diff --git a/data.bin b/data.bin
index f414c84bd3aa25fa07836bb1fb73db784635e24b..edfeb6f501[..]
GIT binary patch
literal 12
QcmYe~N#Pgn0zx1O01)N^ZvX%Q
literal 6
NcmYe~N#Pgn0ssWg0XP5v
which seems unexpected.
To resolve these issues this patch makes -G<regex> ignore binary files by default.
Textconv filters are supported and also -a/--text for getting the old and broken behaviour back.
The -S<block of text> option of log looks for differences that changes the number of occurrences of the specified block of text (i.e. addition/deletion) in a file. As we want to keep the current behaviour, add a test to ensure it stays that way.
The command git diff "??/??/15 - 12:34" "??/??/?? - 03:21" throws an error. It seems that : is the culprit.
The client that handles git for me, didn't throw and error with the colon in the commit name, but git Bash for Windows won't let me get access to the commit using the command line options. I've tried ':' or ":" or \: and none of those options worked.
How would someone use a colon on the command line or how would someone escape the colon character?
* EDIT *
Here's a copy of the output from git log --oneline
9c34cd9 git merge
f1195c7 09/04/2015 - 15:05
db38edb 09/03/15 - 17:28
c20dea6 09/02/15 - 19:43
e33cd9c 08/28/15 - 00:12
48692a9 08/26/15 - 16:02
8072375 08/25/15 - 19:58
c6babf3 08/25/15 - 12:12
ff6afbf 08/14/15 - 19:43
a0ccc60 08/08/15 - 13:43
9b446ae 08/04/15 - 16:11
34a7dfe 08/02/15 - 21:09
f6005ba 07/31/15 - 16:12
18dc958 07/31/15 - 16:11
3d4c7fb 07/31/15 - 13:48
c6c9ef9 07/25/15 - 22:42
9fd46df 07/25/15 - 15:23
78fa4ed 07/20/15 - 12:27
af399b7 07/16/15 - 17:00
33fbd24 07/14/15 - 17:46
458bb5e 07/14/15 - 12:32
418a92d 07-13-15 - EOD
72b1408 07/13/15 - 17:43
a6bc32f Merge https://github.com/halcyonsystems/amelia
ec27a81 new file: assets/css/main.css
new file: assets/im2ff9bc3 Initial commit
From the help page (git help diff):
NAME
git-diff - Show changes between commits, commit and working tree, etc
SYNOPSIS
git diff [options] [<commit>] [--] [<path>...]
git diff [options] --cached [<commit>] [--] [<path>...]
git diff [options] <commit> <commit> [--] [<path>...]
git diff [options] <blob> <blob>
git diff [options] [--no-index] [--] <path> <path>
So you can specify two different path options. If those are timestamps you have to get them into the right syntax. See git help revisions:
<refname>#{<date>}, e.g. master#{yesterday}, HEAD#{5 minutes ago}
A ref followed by the suffix # with a date specification enclosed in a brace pair (e.g. {yesterday}, {1 month 2 weeks 3 days 1 hour 1 second ago} or {1979-02-26
18:30:00}) specifies the value of the ref at a prior point in time. This suffix may only be used immediately following a ref name and the ref must have an existing log
($GIT_DIR/logs/<ref>). Note that this looks up the state of your local ref at a given time; e.g., what was in your local master branch last week. If you want to look at
commits made during certain times, see --since and --until.
This works well for a single file as refname.
If you want to really diff all the changes in your full repo between two times, see this question and this question
Update based on the update of the question and clarifications in the comments:
As the dates appear in the first line of the commit message, you first have to search for the matching date (=commit message) in your repository to determine the unique checksum that identifies the respective commit just as Wumpus explained in the comments:
git log --oneline --grep='07/25/15 - 22:42'
This should work in your case. In the general case where the date or the search string cannot be found in the first line of the commit message use:
git log --grep='07/25/15 - 22:42'
If you have multiple branches and don't know on which branch the respective commit is to be found, add the --all switch.
On the output you will find the checksum, e.g. 3d4c7fb. This is the unique identifier which you can then feed into git diff. Note that the full checksum is actually a bit longer, but abbreviations are fine as long as they are unambiguous. Usually the first four to six digits are sufficient, depending on the amount of commits done in the past.
As Wumpus already said: This is awful. Do not add the commit date to the log message. It is redundant and therefore meaningless: git already maintains two dates for each commit: The author date and the commit date. For the first commit of a changeset these two are identical. During operations that integrate one commit onto a different branch (and generating a new commit checksum), the commit date represents the timestamp of the operation while the author date remains the same old. As I explained above you can refer to a file at a certain timestamp with filename#{timestamp}. See git help revisions to learn about the details of what you can do with the syntax. It's neat and quite flexible.
I am trying to make a diff between local and remote git branches using the following command:
git diff --ignore-space-at-eol -b -w --minimal remotes/branch/master > diff.patch
Everything is ok except I see in the patch file output such as
diff --git a/src/game/AccountMgr.cpp b/src/game/AccountMgr.cpp
index a271c8a..6f363c6 100644
--- a/src/game/AccountMgr.cpp
+++ b/src/game/AccountMgr.cpp
diff --git a/src/game/AccountMgr.h b/src/game/AccountMgr.h
index d406496..405fa32 100644
--- a/src/game/AccountMgr.h
+++ b/src/game/AccountMgr.h
...
Seems there are no changes in such files. How can I remove such files from the diff?
Note that the same git diff --ignore-space-at-eol can have the reverse bug: show no change where there is one:
See commit 044fb19, commit a5229cc (09 Jul 2016) by Johannes Schindelin (dscho).
(Merged by Junio C Hamano -- gitster -- in commit f2cfb8f, 25 Jul 2016)
git version
git version 2.9.2.windows.1
printf "a\nb\nc\n" >pre
printf "a\nbX\nc\n" >post
git diff --no-index --patience --ignore-space-at-eol pre post
(empty!?)
Git 2.10+ (Q3 2016) will fix that:
diff: fix a double off-by-one with --ignore-space-at-eol
When comparing two lines, ignoring any whitespace at the end, we first try to match as many bytes as possible and break out of the loop only upon mismatch, to let the remainder be handled by the code shared with the other whitespace-ignoring code paths.
When comparing the bytes, however, we incremented the counters always,
even if the bytes did not match.
And because we fall through to the space-at-eol handling at that point, it is as if that mismatch never happened.
See "xdiff/xutils.c"
Seems a bug in an outdated msys git version. Update to the latest fixed the problem.
I and my collegues are having terrible trouble getting git to behave properly with certain files on our Windows repostiory clones. The clones have been made by cloning a repository which originates on an OSX machine. We have set autocrlf to true, but the problem is that we reguarly find files that git thinks are changed even though we never touch them (we don't even open them in an editor.
The following output illustrates the issue: any ideas where I am going wrong?
$ git status
# On branch master
# Your branch is behind 'origin/master' by 27 commits, and can be fast-forwarded.
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: Web Applications/webclient/language/en/lang_copyitems.ini
#
no changes added to commit (use "git add" and/or "git commit -a")
Administrator#windows-dev ~/Documents/Workspace/prestige.git
$ git diff "Web Applications/webclient/language/en/lang_copyitems.ini"
diff --git a/Web Applications/webclient/language/en/lang_copyitems.ini b/Web Applications/webclient/language/
index 800c188..ed11c0e 100644
--- a/Web Applications/webclient/language/en/lang_copyitems.ini
+++ b/Web Applications/webclient/language/en/lang_copyitems.ini
## -1,12 +1,12 ##
-<EF><BB><BF> [Header]
- Description=Language strings for 'copyitems.php'
-
- [Messages]
- 300=Copy
- 301=Close
- 302=COPY STORIES
- 303=Name
- 304=In Queue
- 305=New Name
- 306=Items to Copy
- 308=This item has mandatory metadata fields that are not correctly set. Click any part of this messag
+<EF><BB><BF> [Header]
+ Description=Language strings for 'copyitems.php'
+
+ [Messages]
+ 300=Copy
+ 301=Close
+ 302=COPY STORIES
+ 303=Name
+ 304=In Queue
+ 305=New Name
+ 306=Items to Copy
+ 308=This item has mandatory metadata fields that are not correctly set. Click any part of this messag
Administrator#windows-dev ~/Documents/Workspace/prestige.git
$ git checkout HEAD "Web Applications/webclient/language/en/lang_copyitems.ini"
Administrator#windows-dev ~/Documents/Workspace/prestige.git
$ git status
# On branch master
# Your branch is behind 'origin/master' by 27 commits, and can be fast-forwarded.
#
# Changed but not updated:
# (use "git add <file>..." to update what will be committed)
# (use "git checkout -- <file>..." to discard changes in working directory)
#
# modified: Web Applications/webclient/language/en/lang_copyitems.ini
#
The problem with this settings, as illustrated by the GitHub guide is an automatic conversion is done during the checkout of the repository...
That means you do not need to open a file to trigger any change.
Is it not possible to keep autocrlf to false, and open those Windows files in editors able to respect the return line characters?
Note (illustrated here), if you need the conversion, except for some files, you could add a .gitattributes in the parent directory, with a:
myFile -crlf
In the file you set attributes to a path (or a pattern), or unset them (with the minus sign).
The crlf attribute is the attribute which tells if a file is affected by the core.autocrlf options. If you unset it, Git won’t mess with the line endings in the file
To solve this problem on my Windows 7 machine using git 1.7.3.1, I had to set the core.filemode option to false.
git config -e --local