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)"
My thought is that, in order to automatically fetch updates only if upstream has pushed some commits, I should check its hashes.
2 ways, I could do is that to check the logs or use rev-list something like below:
# this fetches top 30 commits from forked repo
git rev-list -n 30 main
# this also does the same but not limited to 30
git log --format='%H'
I'm finding it difficult to compare the hashes as I'm failing to fetch more than 1 commit from forked repo.
Explained my approach below:
git remote add upstream https://github.com/upstream/upstream.git
git fetch upstream --tags
upstream_commit="$(git rev-parse upstream/main)"
echo "Upstream commit: ${upstream_commit}"
# This should store 30 recent commit hashes as an array AFAIK
forked_commits=($(git rev-list -n 30 main))
# another I tried to put forloop is this:
# for forked_commit in "$forked_commits[#]"; do
for forked_commit in $(git log --format='%H'); do
# but prints only the top most element and exits the loop
echo "$forked_commit"
if [ "$upstream_commit" == "$forked_commit" ]; then
has_new_commits=false
else
# since I've added my commits on top, if condition fails and this always returns true
has_new_commits=true
fi
done
if [ "${has_new_commits}" ]; then
git checkout main
git rebase upstream/main
git push -f origin main
echo "Rebase successful!"
else
echo "No commits to be synced!"
fi
Ok, I did many mistake that were minor.
Array stuff didn't work. I was supposed to put them directly within the forloop.
Next mistake I never validated them properly. i.e., even if the hash was found, it never exited.
Using [ $has_new_commits ]; then is wrong. I should be using [ $has_new_commits == "true"]; then instead.
Corrected code:
git remote add upstream https://github.com/upstream_repo/upstream.git
git fetch upstream --tags
upstream_commit="$(git rev-parse upstream/main)"
for forked_commit in $(git rev-list -n 20 main); do
if [ $upstream_commit != $forked_commit ]; then
has_new_commits=true
continue
else
has_new_commits=false
break
fi
done
if [ $has_new_commits == "true" ]; then
echo "New commits found!"
else
echo "No commits to be synced!"
fi
So I have this little bash script to output a csv file that shows all my commit history from a specific month.
function make-git-report() {
if [ "$1" != "" ]
then
local month=$1
else
local month=$(date +%m)
fi
local year=$(date +%Y)
local nextYear=$year
local nextMonth=$((month+1))
if [ "$nextMonth" = "13" ]
then
local nextMonth="01"
local nextYear=$((year+1))
fi
local start="$year-$month-01"
local end="$nextYear-$nextMonth-01"
rm -f log.csv
git --no-pager log \
--author="Evert" \
--since="$start" \
--before="$end" \
--branches --remotes --tags --no-decorate --no-merges \
--pretty=format:'§"%ch";"%an";"%s";' --stat | \
grep -v \| | tr -s "\n\n" | tr "\n" '"' | tr "§" "\n" > templog.csv
echo "\nDate;Author;Message;Changes" >> templog.csv
tac templog.csv > log.csv
rm -f templog.csv
}
But I just realized that if a branch is deleted during that month, and it was only merged using a squash merge, then a lot of commits will not show up in my csv file.
I've understood that git reflog will somehow still contain that missing data, but I'm not sure how to merge that information into the output from git log while graciously avoiding things like duplicate entries and maybe more unwanted results that I now can't think of.
Can anybody give me a little hint, a push in the right direction, on how to solve this?
You can't use the reflog to reliably get information about deleted branches :
the log gets updated only if you see the commit at all
e.g : if you take 2 days off, your local repo will have no trace of what happened during those two days ...
two clones of the same repo will not have the same reflog
the reflog will also contain information about rebased/cherry-picked commit (and possibly add duplicate information on the log you are trying to build ?)
the reflog for HEAD will stay around, but reflog for specific branches/remote branches will get deleted if said branch is deleted too
etc ...
I guess you describe a workflow based around a known git central service (github ? gitlab ? azure devops ? ...) where your branches get merged via pull requests.
Each of these services keep a link to the branch of its pull requests :
a generic way to see that is to run git ls-remote, and see what refs are listed (you should see a list of refs/pull/xxx/... or refs/merge-requests/xxx/... or ...)
and read the documentation for said service
You can fetch these pull requests :
# with this refspec : all pull requests will be stored under origin/pull/*,
# as if they were remote branches
git fetch origin +refs/pull/*:refs/remotes/origin/pull/*
# or you may choose to store them in a different set of refs :
git fetch origin +refs/pull/*:refs/pull/*
You may also use the API of said service to check the state of a pull request.
Combining the information above, you may choose, pull request by pull request, whether you should add pull/xyz/head to the list of refs in your git log command or not.
note that, if your branch are squash merged, the "merge commits" will actually not be merge commits, so you would have to choose another way than --no-merges to exclude them from your log (for example : print the commits sha and skip the ones that are known to be a merge request result)
I'm writing an automated script to process staged/unstaged files for a pre-commit hook.
I would like to be able to know if a file is marked as deleted by git ("D " or " D" in git status --porcelain -- {filename}) so that I can remove it from the list. I would like to do so through the GitPython API if possible.
Previously attempted steps:
I couldn't find in the documentation any reference to "delete" that related to this use case
Using dir(item) where item is a Diffable from repo.index.diff(None) reveals the following members:
['NULL_BIN_SHA', 'NULL_HEX_SHA', '__class__', '__delattr__', '__dir__', '__doc__', '__eq__', '__format__', '__ge__', '__getattribute__', '__gt__', '__hash__', '__init__', '__init_subclass__', '__le__', '__lt__', '__module__', '__ne__', '__new__', '__reduce__', '__reduce_ex__', '__repr__', '__setattr__', '__sizeof__', '__slots__', '__str__', '__subclasshook__', '_handle_diff_line', '_index_from_patch_format', '_index_from_raw_format', '_pick_best_path', 'a_blob', 'a_mode', 'a_path', 'a_rawpath', 'b_blob', 'b_mode', 'b_path', 'b_rawpath', 'change_type', 'copied_file', 'deleted_file', 'diff', 'new_file', 'raw_rename_from', 'raw_rename_to', 're_header', 'rename_from', 'rename_to', 'renamed', 'renamed_file', 'score']
out of which deleted_file seems to be the only sensible candidate - but it doesn't seem to reflect the result of git status --porcelain since all deleted files in git status are set to deleted_file=False (same as non-deleted ones).
For now I am relying on git directly to assert if a file is deleted or not:
def _is_deleted(path: str):
files = _gitstatus()
return 'D' in files[path]
#lru_cache(maxsize=1)
def _gitstatus():
child = subprocess.Popen(["git", "status", "--porcelain"], stdout=subprocess.PIPE, stderr=subprocess.PIPE)
out, err = [stream.decode('utf-8') if stream is not None else '' for stream in child.communicate()]
if child.returncode != 0:
raise Exception(err)
files = {
line[3:]: tuple(line[0:2])
for line in out.split('\n')
}
return files
but I'd much prefer using the GitPython API if possible. Any idea how to achieve the equivalent result of the above function?
Would this answer your question?
This is using the GitPython library, it's a bit involved but you can get the similar result to as git status using the Repo.index.diff(). This function is similar if not the same as the git.diff.Diff and you can see how to filter files on the docs there.
from git import Repo
repo = Repo()
if repo.is_dirty():
index = repo.index
for obj in index.diff(None).iter_change_type('D'):
print('File path', obj.b_path)
print('Change type', obj.change_type)
print('Is deleted', obj.deleted_file)
(git-test) ➜ (01/09 20:18) /tmp/git-test git:(master) ✗ git status
On branch master
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: test.txt
Untracked files:
(use "git add <file>..." to include in what will be committed)
git-test.py
no changes added to commit (use "git add" and/or "git commit -a")
(git-test) ➜ (01/09 20:19) /tmp/git-test git:(master) ✗ python git-test.py
File path test.txt
Change type D
Is deleted True
Updated to show Untracked, Staged and Deleted files
from git import Repo
repo = Repo()
if repo.is_dirty():
index = repo.index
print('Untracked files', repo.untracked_files)
print('Staged files', [item.a_path for item in repo.index.diff('HEAD')])
for obj in index.diff(None):
print('File path', obj.b_path)
print('Change type', obj.change_type)
print('Is deleted', obj.deleted_file)
(git-test) ➜ (02/09 13:58) /tmp/git-test git:(master) ✗ git status
On branch master
Changes to be committed:
(use "git reset HEAD <file>..." to unstage)
new file: test-2.txt
Changes not staged for commit:
(use "git add/rm <file>..." to update what will be committed)
(use "git checkout -- <file>..." to discard changes in working directory)
deleted: test.txt
Untracked files:
(use "git add <file>..." to include in what will be committed)
.idea/
git-test.py
(git-test) ➜ (02/09 13:58) /tmp/git-test git:(master) ✗ python git-test.py
Untracked files ['.idea/.gitignore', '.idea/git-test.iml', '.idea/misc.xml', '.idea/modules.xml', '.idea/vcs.xml', 'git-test.py']
Staged files ['test-2.txt']
File path test.txt
Change type D
Is deleted True
From the command line, I would use :
git diff --name-status to get the status of tracked files compared to the index,
git diff --staged --name-status to get the status of staged files compared to the current commit.
I think you can extract the same information from GitPython's diff api :
hcommit = repo.head.commit
hcommit.diff() # diff tree against index
hcommit.diff('HEAD~1') # diff tree against previous tree
hcommit.diff(None) # diff tree against working tree
index = repo.index
index.diff() # diff index against itself yielding empty diff
index.diff(None) # diff index against working copy
index.diff('HEAD') # diff index against current HEAD tree
git diff would be index.diff(None), git diff --staged would be index.diff('HEAD') or hcommit.diff().
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