When I ran the command git pull all updated files are shown and their paths are relative to .git file.
But due to some reason I am seeing ... in file path. Am I am unable to do to the path as linux has . and .. according to my knowledge which represents current and previous directory resp.
Attaching my output
$ git pull
remote: Enumerating objects: 72, done.
remote: Counting objects: 100% (72/72), done.
remote: Compressing objects: 100% (37/37), done.
remote: Total 43 (delta 28), reused 7 (delta 4), pack-reused 0
Unpacking objects: 100% (43/43), done.
From ssh://gitlab-master.xyz.com:12051/projectx/santor
234243..434323 master -> origin/master
989894..324342 branch-xyz -> origin/branch-xyz
Updating 480026d82..e87fa34343
Fast-forward
.../modules/files/text/jump/jumps.yaml | 3476 +++++++++++++++++++++++++++++++++++++++++++++++
.../modules/files/text/drink/jumps.yaml | 228 +++-
It doesn't have a general specified meaning. This is just a way for Git to display an abbreviated path when the whole thing would break screen formatting.
It doesn't mean anything in the file path.
It does mean something in the Git output: that Git isn't printing part of the path.
When Git produces git diff --stat output like this, it needs to print various file names, but it has a limited amount of columnar space in which to print them. So it uses compression tricks. One of these is to leave out parts of the pathname, representing the left-out part with .... That is what you are seeing here.
Related
How can i get the last merged branch name in git from the remote
Tried
git log --first-parent --merges -1 --oneline
But not getting the branch name
Please help
In general, you cannot.
A merge commit may have, as its commit message, text of the form merge branch foo or merge branch foo of someurl, but to read that message, you must obtain the commit from the remote. Even so, there's no guarantee that branch foo exists any more, or that the name means anything if it does exist. Merging really works by commit hash IDs, not by branch names; branch names may evanesce.
If you think you need a branch name here, you are probably doing something wrong. Branch names do make sense here in other version control systems, but in Git, depending on them is unwise.
Here is the command you need to give (change the branch name from origin/master to whichever branch you're checking merges for):
git log --merges origin/master --oneline --grep='^Merge' -1 | grep -oe "[^']*[^']" | sed -n 2p
I had quite a bit of a hard time trying to solve this issue.
I had to get this information for my CircleCi pipeline, and to solve my problem I used the GitHub cli.
Specifically the pr list command: https://cli.github.com/manual/gh_pr_list
The following command gives you all the information of the last PR you merged into main
gh pr list -s merged -B main -L 1
Then you need to manipulate the string and get only the branch name. Which is the text before "MERGED"
I took it splitting the string and taking the penultimate element.
From documentation, in order to use git ls-tree you need to pass the hash of a tree object. What if I want to obtain the same output of git ls-tree starting from a commit object.
I can obviously do it with something like this:
git ls-tree $(git cat-file -p my_commit | grep -oP "(?<=tree ).*")
But I feel like I am reinventing the wheel. Is there a git command that already does this?
No, git ls-tree takes a tree-ish object.
The "-ish" suffix here is important. Per the Cambridge Dictionary:
-ish suffix (QUITE)
used to form adjectives to give the meaning to some degree; fairly:
He had a sort of reddish beard.
She was oldish - about 60, I'd say.
We'll start at sevenish (= about seven o'clock).
In this case, "tree-ish" means like a tree. A tree, of course, is like a tree. But a commit is also like a tree since it has exactly one tree component; that means that you can unambiguously refer to that tree by simply using the commit itself.
So, just do git ls-tree <commit-ish>.
We develop in a mixed environment - some people work on Macs and some work on Linux. This has proven to be a bit of a challenge at times, as those people who work on Linux are used to having their filesystems be case sensitive, so there's no issue committing (accidentally or otherwise) multiple files differing just by case. (e.g. FileName.ext versus filename.ext)
However, when the people on Macs go to check out the repository, having a case-insensitive filesystem means that the two files - differing only in case - overwrite each other and cause general havoc.
I know that there are various git settings to help people on case-insensitive filesystems work better with case changes (e.g. core.ignorecase), but these don't solve the issue where there's two different files in the repository, only differing by case.
I realize that the only way to fix it is to make sure the Linux people don't commit the two files differing only in case in the first place. -- Is there some setting in git which will pop up a warning or error if a user on a case-sensitive filesystem attempts to commit file(s) which would be confused with each other on a case-insensitive filesystem?
There's nothing built in (although there should be, no doubt). What you can do is provide a pre-commit hook that verifies that all names are OK and prevents the commit if not.
This hook only needs to be run on the Linux box (although making it work on Linux and Mac is easy, it's just Windows with its default impoverished toolbox that is problematic). You might want to add it to a side branch and give the Linux folks instructions on setting it up.
You may want to check branch names as well, as in git pre-commit or update hook for stopping commit with branch names having Case Insensitive match. (Interesting: the answer on this question is my own; I had forgotten it.)
First, let's write a "check for case conflict" function. This is just a matter of sorting with case-folding (so that "helloworld" and "helloWorld" are placed adjacent to each other), then using uniq -di to print any duplicate (after case-folding) strings, but no non-duplicates:
sort -f | uniq -di
If this produces any output, these are the "bad names". Let's capture the output in a temporary file and check its size, so we can print them to standard output as well:
#! /bin/sh
TF=$(mktemp)
trap "rm -f $TF" 0 1 2 3 15
checkstdin() {
sort -f | uniq -di > $TF
test -s $TF || return 0 # if $TF is empty, we are good
echo "non-unique (after case folding) names found!" 1>&2
cat $TF 1>&2
return 1
}
Now we just need to use it on files that will be committed, and perhaps on branch names as well. The former are listed with git ls-files, so:
git ls-files | checkstdin || {
echo "ERROR - file name collision, stopping commit" 1>&2
exit 1
}
You can fancy this up to use git diff-index --cached -r --name-only --diff-filter=A HEAD to check only added files, allowing existing case collisions to continue, and/or try to check things across many branches and/or commits, but that gets difficult.
Combine the above two fragments into one script (and test) and then simply copy it to an executable file named .git/hooks/pre-commit.
Checking branch names is a bit trickier. This really should happen when you create the branch name, rather than when you commit to it, and it's impossible to do a really good job on the client—it has to be done on a centralized server that has a proper global view.
Here is a way to do it on the server in a pre-receive script, in shell script rather than in Python (as in the linked answer). We still need the checkstdin function though, and you might want to do it in an update hook rather than a pre-receive hook, since you don't need to reject the entire push, just the one branch name.
NULLSHA=0000000000000000000000000000000000000000 # 40 0s
# Verify that the given branch name $1 is unique,
# even IF we fold all existing branch names' cases.
# To be used on any proposed branch creation (we won't
# look at existing branches).
check_new_branch_name() {
(echo "$1"; git for-each-ref --format='%(refname:short)' refs/heads) |
checkstdin || {
echo "ERROR: new branch name $1 is not unique after case-folding" 1>&2
exit 1 # or set overall failure status
}
}
while read oldsha newsha refname; do
... any other checks ...
case $oldsha,$refname in
$NULLSHA,refs/heads/*) check_new_branch_name ${refname#refs/heads/};;
esac
... continue with any other checks ...
done
I'm new to Git.
My problem is, with a shell script (running in Windows) I need to save the Git Push commands to an output file.
So far i've something like this:
echo -e "\n6) ${GREEN}Starting Push.${NC}"
git push -v >> logs/logPush.log
if grep -q -w -i "Rejected" logs/logPush.log ;
then
echo "${RED}A conflict has been detected. Exiting.${NC}"
read
exit
else
:
fi
But it always generates a blank file. The Pull works just fine tho...
Does anyone know how to make the output file receive the whole information that it appears on the terminal:
Counting objects: 5, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (3/3), done.
Writing objects: 100% (3/3), 289 bytes | 0 bytes/s, done.
Total 3 (delta 2), reused 0 (delta 0)
To ssh:repository
42be914..ead1f82 master -> master
updating local tracking ref 'refs/remotes/origin/master'
Redirect stderr to the file as well:
git push -v >> logs/logPush.log 2>&1
It looks like git push has the --porcelain option for this purpose:
--porcelain
Produce machine-readable output. The output status line for each ref will be tab-separated and sent to stdout instead of stderr.
The full symbolic names of the refs will be given.
A UNIX shell provides two output streams by default -- stdout and stderr.
This is often useful because when you redirect output to something else, you still want errors to go to the screen.
$ cat nosuchfile | grep something
cat: nosuchfile: No such file or directory
This is what I wanted. I didn't want cat: nosuchfile: No such file or directory to be fed into grep.
As you know, you can redirect stdout using > and |.
You can redirect stderr using 2>:
$ cat nosuchfile > outfile 2>errormessage
A common idiom is:
$ somecommand > output 2>&1
Here &1 refers to the file descriptor used by stdout. So you're telling the shell to send stderr to the same place as stdout.
You can use 2>&1 to send stderr to your output file. Or you can use what you've learned here to make sense of the git documentation re --porcelain, or design some other solution, for example sending stderr to a second file where appropriate.
I guess that the exit status of git push will indicate whether it was successful or not. You should use it rather than parsing the log:
if ! git push -v >> logs/logPush.log 2>&1
then
echo "${RED}Failed to push. Exiting.${NC}"
read
exit
fi
I've used 2>&1 to redirect stderr to stdout, so the log would contain both outputs - this is optional.
If the command fails, it's not necessarily indicative of a conflict, so I modified the error message to something more generic.
I'm trying to validate if two zip packages are equivalent. I can not rely on md5sum. When I extract the two packages, and do a md5sum diff between all the files in the packages, there is no difference, and all files have equivalent md5sums. But the zip packages themselves have different md5sum values. My question is: How can I validate that two zip packages are equivalent?
When you list the archive's content with
unzip -v archive.zip
you get a list of files with these column headings
Length Method Size Cmpr Date Time CRC-32 Name
Depending on what you consider equivalent (e.g. Size, CRC, Name), you can extract the relevant columns for both archives, sort them and do a diff over the output.
without unzipping the file you can use zipinfo
e.g:
ipinfo 5.zip
Archive: 5.zip 158 bytes 1 file
drwxr-xr-x 3.0 unx 0 bx stor 18-Nov-13 07:23 501/
1 file, 0 bytes uncompressed, 0 bytes compressed: 0.0%