git-hash

Difference between PowerShell's echo and CMD's echo

安稳与你 — Thu, 04 Feb 2021 22:45:46 +0000

Difference between PowerShell's echo and CMD's echo 安稳与你 2021-02-05 06:45:46

问题

I get the following in PowerShell:

D:\> echo "Apple Pie" | git hash-object --stdin
157cb7be4778a9cfad23b6fb514e364522167053

D:\> "Apple Pie" | git hash-object --stdin
157cb7be4778a9cfad23b6fb514e364522167053

but in CMD.exe:

C:\>echo "Apple Pie" | git hash-object --stdin
bb3918d5053fea31fc9a58fae1e5bdeabe3ec647

In a PluralSight video, I see a different value from what seems to be a Mac console:

What is the exact value piped from echo in each case?

I get a different hash if I go to one of those online SHA1 generators and enter the string Apple Pie. From those I get:

8d69b7365f59237d3fb052c1f2f15ea33457fe51

回答1:

As far as I understand :

Using CMD :

echo Apple Pie|git hash-object --stdin

return the same think as the following in PowerShell

"Apple Pie" | git hash-object --stdin

That is to say :

157cb7be4778a9cfad23b6fb514e364522167053

@Mofi seems to be right, you can reproduce the CMD result in Powershell using :

'"Apple Pie" ' | git hash-object --stdin

To explain the Mac OS one : To obtain 157cb7be4778a9cfad23b6fb514e364522167053 the real list of chars that is hashed is 'Apple Pie\r\n' (with carage return line feed), in Mac or linux like command line it's 'Apple Pie\r'.

If you want to test this : put 'Apple Pie' in a text file with a cariage return and save it as a Windows text style (CR+LF), and use git hash-object yourfile.txt. Then save it in Linux style (LF) and test again, you will find your two hashes.

The part about \r\n.

"Apple Pie" | where {$_.length -eq 9} shows that the string is exactly 9 characters long

For me it's because in your case the pipe is between two PowerShell parts, the pipe transmit an object. When the pipe is between PowerShell and an external EXE then the \r\n are added. Here is a way to test that with a small exe file written in C# :

using System;
namespace C_Param
{
  class Program
  {
    static void Main(string[] args)
    {
      string line = Console.In.ReadToEnd();
      foreach (char character in line){
        Console.WriteLine(String.Format("{0:X2}", Convert.ToByte(character)));
      }
    }
  }
}

The result in a PowerShell console is :

"Apple Pie" | .\C_Param.exe
41
70
70
6C
65
20
50
69
65
0D
0A

The result in a CMD console is :

echo "Apple Pie" | .\C_Param.exe
22
41
70
70
6C
65
20
50
69
65
22
20
0D
0A

QED ?

来源：https://stackoverflow.com/questions/61153475/difference-between-powershells-echo-and-cmds-echo

标签

powershell

cmd

hash

sha1

git-hash

How does git compute file hashes?

别说谁变了你拦得住时间么 — Mon, 16 Dec 2019 19:27:47 +0000

How does git compute file hashes? 别说谁变了你拦得住时间么 2019-12-17 03:27:47

问题

The SHA1 hashes stored in the tree objects (as returned by git ls-tree) do not match the SHA1 hashes of the file content (as returned by sha1sum)

$ git cat-file blob 4716ca912495c805b94a88ef6dc3fb4aff46bf3c | sha1sum
de20247992af0f949ae8df4fa9a37e4a03d7063e  -

How does git compute file hashes? Does it compress the content before computing the hash?

回答1:

Git prefixes the object with "blob ", followed by the length (as a human-readable integer), followed by a NUL character

$ echo -e 'blob 14\0Hello, World!' | shasum 8ab686eafeb1f44702738c8b0f24f2567c36da6d

Source: http://alblue.bandlem.com/2011/08/git-tip-of-week-objects.html

回答2:

I am only expanding on the answer by @Leif Gruenwoldt and detailing what is in the reference provided by @Leif Gruenwoldt

Do It Yourself..

Step 1. Create an empty text document (name does not matter) in your repository

Step 2. Stage and Commit the document

Step 3. Identify the hash of the blob by executing git ls-tree HEAD

Step 4. Find the blob's hash to be e69de29bb2d1d6434b8b29ae775ad8c2e48c5391

Step 5. Snap out of your surprise and read below

How does GIT compute its commit hashes

    Commit Hash (SHA1) = SHA1("blob " + <size_of_file> + "\0" + <contents_of_file>)

The text blob⎵ is a constant prefix and \0 is also constant and is the NULL character. The <size_of_file> and <contents_of_file> vary depending on the file.

See: What is the file format of a git commit object?

And thats all folks!

But wait!, did you notice that the <filename> is not a parameter used for the hash computation? Two files could potentially have the same hash if their contents are same indifferent of the date and time they were created and their name. This is one of the reasons Git handles moves and renames better than other version control systems.

Do It Yourself (Ext)

Step 6. Create another empty file with a different filename in the same directory

Step 7. Compare the hashes of both your files.

Note:

The link does not mention how the tree object is hashed. I am not certain of the algorithm and parameters however from my observation it probably computes a hash based on all the blobs and trees (their hashes probably) it contains

回答3:

git hash-object

This is a quick way to verify your test method:

s='abc'
printf "$s" | git hash-object --stdin
printf "blob $(printf "$s" | wc -c)\0$s" | sha1sum

Output:

f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f
f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f  -

where sha1sum is in GNU Coreutils.

Then it comes down to understanding the format of each object type. We have already covered the trivial blob, here are the others:

commit: What is the file format of a git commit object?
tree: What is the internal format of a git tree object?
tag: How is a Git Tag Object SHA1 Created?

回答4:

Based on Leif Gruenwoldt answer, here is a shell function substitute to git hash-object :

git-hash-object () { # substitute when the `git` command is not available
    local type=blob
    [ "$1" = "-t" ] && shift && type=$1 && shift
    # depending on eol/autocrlf settings, you may want to substitute CRLFs by LFs
    # by using `perl -pe 's/\r$//g'` instead of `cat` in the next 2 commands
    local size=$(cat $1 | wc -c | sed 's/ .*$//')
    ( echo -en "$type $size\0"; cat "$1" ) | sha1sum | sed 's/ .*$//'
}

Test:

$ echo 'Hello, World!' > test.txt
$ git hash-object test.txt
8ab686eafeb1f44702738c8b0f24f2567c36da6d
$ git-hash-object test.txt
8ab686eafeb1f44702738c8b0f24f2567c36da6d

回答5:

I needed this for some unit tests in Python 3 so thought I'd leave it here.

def git_blob_hash(data):
    if isinstance(data, str):
        data = data.encode()
    data = b'blob ' + str(len(data)).encode() + b'\0' + data
    h = hashlib.sha1()
    h.update(data)
    return h.hexdigest()

I stick to \n line endings everywhere but in some circumstances Git might also be changing your line endings before calculating this hash so you may need a .replace('\r\n', '\n') in there too.

来源：https://stackoverflow.com/questions/7225313/how-does-git-compute-file-hashes

标签

How does git compute file hashes?

女生的网名这么多〃 — Mon, 16 Dec 2019 19:27:13 +0000

How does git compute file hashes? 女生的网名这么多〃 2019-12-17 03:27:13

问题

The SHA1 hashes stored in the tree objects (as returned by git ls-tree) do not match the SHA1 hashes of the file content (as returned by sha1sum)

$ git cat-file blob 4716ca912495c805b94a88ef6dc3fb4aff46bf3c | sha1sum
de20247992af0f949ae8df4fa9a37e4a03d7063e  -

How does git compute file hashes? Does it compress the content before computing the hash?

回答1:

Git prefixes the object with "blob ", followed by the length (as a human-readable integer), followed by a NUL character

$ echo -e 'blob 14\0Hello, World!' | shasum 8ab686eafeb1f44702738c8b0f24f2567c36da6d

Source: http://alblue.bandlem.com/2011/08/git-tip-of-week-objects.html

回答2:

I am only expanding on the answer by @Leif Gruenwoldt and detailing what is in the reference provided by @Leif Gruenwoldt

Do It Yourself..

Step 1. Create an empty text document (name does not matter) in your repository

Step 2. Stage and Commit the document

Step 3. Identify the hash of the blob by executing git ls-tree HEAD

Step 4. Find the blob's hash to be e69de29bb2d1d6434b8b29ae775ad8c2e48c5391

Step 5. Snap out of your surprise and read below

How does GIT compute its commit hashes

    Commit Hash (SHA1) = SHA1("blob " + <size_of_file> + "\0" + <contents_of_file>)

The text blob⎵ is a constant prefix and \0 is also constant and is the NULL character. The <size_of_file> and <contents_of_file> vary depending on the file.

See: What is the file format of a git commit object?

And thats all folks!

Do It Yourself (Ext)

Step 6. Create another empty file with a different filename in the same directory

Step 7. Compare the hashes of both your files.

Note:

回答3:

git hash-object

This is a quick way to verify your test method:

s='abc'
printf "$s" | git hash-object --stdin
printf "blob $(printf "$s" | wc -c)\0$s" | sha1sum

Output:

f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f
f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f  -

where sha1sum is in GNU Coreutils.

Then it comes down to understanding the format of each object type. We have already covered the trivial blob, here are the others:

commit: What is the file format of a git commit object?
tree: What is the internal format of a git tree object?
tag: How is a Git Tag Object SHA1 Created?

回答4:

Based on Leif Gruenwoldt answer, here is a shell function substitute to git hash-object :

git-hash-object () { # substitute when the `git` command is not available
    local type=blob
    [ "$1" = "-t" ] && shift && type=$1 && shift
    # depending on eol/autocrlf settings, you may want to substitute CRLFs by LFs
    # by using `perl -pe 's/\r$//g'` instead of `cat` in the next 2 commands
    local size=$(cat $1 | wc -c | sed 's/ .*$//')
    ( echo -en "$type $size\0"; cat "$1" ) | sha1sum | sed 's/ .*$//'
}

Test:

$ echo 'Hello, World!' > test.txt
$ git hash-object test.txt
8ab686eafeb1f44702738c8b0f24f2567c36da6d
$ git-hash-object test.txt
8ab686eafeb1f44702738c8b0f24f2567c36da6d

回答5:

I needed this for some unit tests in Python 3 so thought I'd leave it here.

def git_blob_hash(data):
    if isinstance(data, str):
        data = data.encode()
    data = b'blob ' + str(len(data)).encode() + b'\0' + data
    h = hashlib.sha1()
    h.update(data)
    return h.hexdigest()

I stick to \n line endings everywhere but in some circumstances Git might also be changing your line endings before calculating this hash so you may need a .replace('\r\n', '\n') in there too.

来源：https://stackoverflow.com/questions/7225313/how-does-git-compute-file-hashes

标签

How does git compute file hashes?

谁说我不能喝 — Mon, 16 Dec 2019 19:27:10 +0000

How does git compute file hashes? 谁说我不能喝 2019-12-17 03:27:10

问题

The SHA1 hashes stored in the tree objects (as returned by git ls-tree) do not match the SHA1 hashes of the file content (as returned by sha1sum)

$ git cat-file blob 4716ca912495c805b94a88ef6dc3fb4aff46bf3c | sha1sum
de20247992af0f949ae8df4fa9a37e4a03d7063e  -

How does git compute file hashes? Does it compress the content before computing the hash?

回答1:

Git prefixes the object with "blob ", followed by the length (as a human-readable integer), followed by a NUL character

$ echo -e 'blob 14\0Hello, World!' | shasum 8ab686eafeb1f44702738c8b0f24f2567c36da6d

Source: http://alblue.bandlem.com/2011/08/git-tip-of-week-objects.html

回答2:

I am only expanding on the answer by @Leif Gruenwoldt and detailing what is in the reference provided by @Leif Gruenwoldt

Do It Yourself..

Step 1. Create an empty text document (name does not matter) in your repository

Step 2. Stage and Commit the document

Step 3. Identify the hash of the blob by executing git ls-tree HEAD

Step 4. Find the blob's hash to be e69de29bb2d1d6434b8b29ae775ad8c2e48c5391

Step 5. Snap out of your surprise and read below

How does GIT compute its commit hashes

    Commit Hash (SHA1) = SHA1("blob " + <size_of_file> + "\0" + <contents_of_file>)

The text blob⎵ is a constant prefix and \0 is also constant and is the NULL character. The <size_of_file> and <contents_of_file> vary depending on the file.

See: What is the file format of a git commit object?

And thats all folks!

Do It Yourself (Ext)

Step 6. Create another empty file with a different filename in the same directory

Step 7. Compare the hashes of both your files.

Note:

回答3:

git hash-object

This is a quick way to verify your test method:

s='abc'
printf "$s" | git hash-object --stdin
printf "blob $(printf "$s" | wc -c)\0$s" | sha1sum

Output:

f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f
f2ba8f84ab5c1bce84a7b441cb1959cfc7093b7f  -

where sha1sum is in GNU Coreutils.

Then it comes down to understanding the format of each object type. We have already covered the trivial blob, here are the others:

commit: What is the file format of a git commit object?
tree: What is the internal format of a git tree object?
tag: How is a Git Tag Object SHA1 Created?

回答4:

Based on Leif Gruenwoldt answer, here is a shell function substitute to git hash-object :

git-hash-object () { # substitute when the `git` command is not available
    local type=blob
    [ "$1" = "-t" ] && shift && type=$1 && shift
    # depending on eol/autocrlf settings, you may want to substitute CRLFs by LFs
    # by using `perl -pe 's/\r$//g'` instead of `cat` in the next 2 commands
    local size=$(cat $1 | wc -c | sed 's/ .*$//')
    ( echo -en "$type $size\0"; cat "$1" ) | sha1sum | sed 's/ .*$//'
}

Test:

$ echo 'Hello, World!' > test.txt
$ git hash-object test.txt
8ab686eafeb1f44702738c8b0f24f2567c36da6d
$ git-hash-object test.txt
8ab686eafeb1f44702738c8b0f24f2567c36da6d

回答5:

I needed this for some unit tests in Python 3 so thought I'd leave it here.

def git_blob_hash(data):
    if isinstance(data, str):
        data = data.encode()
    data = b'blob ' + str(len(data)).encode() + b'\0' + data
    h = hashlib.sha1()
    h.update(data)
    return h.hexdigest()

I stick to \n line endings everywhere but in some circumstances Git might also be changing your line endings before calculating this hash so you may need a .replace('\r\n', '\n') in there too.

来源：https://stackoverflow.com/questions/7225313/how-does-git-compute-file-hashes

标签

Git objects SHA-1 are file contents or file names?

生来就可爱ヽ(ⅴ＜●) — Sat, 07 Dec 2019 02:01:32 +0000

Git objects SHA-1 are file contents or file names? 生来就可爱ヽ(ⅴ＜●) 2019-12-07 10:01:32

问题

I am confused with how a file's actual contents are stored in .git.

For e.g. Version 1 is the actual text content in test.txt. When I commit (first commit) it to the repo, git returns a SHA-1 for that file which is located in .git\objects\0c\15af113a95643d7c244332b0e0b287184cd049.

When I open the file 15af113a95643d7c244332b0e0b287184cd049 in a text editor, it's all garbage, something like this

x+)JMU074f040031QÐKÏ,ÉLÏË/Je¨}ºõw[Éœ„ÇR ñ·Î}úyGª*±8#³¨,1%>9?¯$5¯D¯¤¢„áôÏ3%³þú>š~}Ž÷*ë²-¶ç¡êÊòR“KâKòãs+‹sô

But I'm not sure whether this garbage represents the encrypted form of the text Version 1 or it's represented by the SHA-1 15af113a95643d7c244332b0e0b287184cd049.

回答1:

The correct answer to the question in the subject line:

Git objects SHA-1 are file contents or file names?

is probably "neither", since you were referring to the contents of the loose object file, rather than the original file—and even if you were referring to the original file, that's still not quite right.

A loose object, in Git, is a plain file. The name of the file is constructed from the object's hash ID. The object's hash ID, in turn, is constructed by computing a hash of the object's contents with a prefix header attached.

The prefixed header depends on the object type. There are four types: blob, commit, tag, and tree. The header consists of the a zero-terminated byte string composed of the type name as an ASCII (or equivalently, UTF-8) byte string, followed by a space, followed by a decimalized representation of the size of the object in bytes, followed by an ASCII NUL (b'\x00' in Python, if you prefer modern Python notation, or '\0' if you prefer C).

After the header come the actual object contents. So, for a file containing the byte string b'hello\n', the data to be hashed consist of b'blob 6\0hello\n:

$ echo 'hello' | git hash-object -t blob --stdin
ce013625030ba8dba906f756967f9e9ca394464a
$ python3
[...]
>>> import hashlib
>>> s = b'blob 6\0hello\n'
>>> hashlib.sha1(s).hexdigest()
'ce013625030ba8dba906f756967f9e9ca394464a'

Hence, the file name that would be used to store this file is (derived from) ce013625030ba8dba906f756967f9e9ca394464a. As a loose object, it becomes .git/objects/ce/013625030ba8dba906f756967f9e9ca394464a.

The contents of that file, however, are the zlib-compressed form of b'blob 6\0hello\n' (with, apparently, level=1—the default is currently 6 and the result does not match at that level; it's not clear whether Git's zlib deflate exactly matches Python's, but using level 1 did work here):

$ echo 'hello' | git hash-object -w -t blob --stdin
ce013625030ba8dba906f756967f9e9ca394464a
$ vis .git/objects/ce/013625030ba8dba906f756967f9e9ca394464a
x\^AK\M-J\M-IOR0c\M-HH\M-M\M-I\M-I\M-g\^B\000\^]\M-E\^D\^T$

(note that the final $ is the shell prompt again; now back to Python3)

>>> import zlib
>>> zlib.compress(s, 1)
b'x\x01K\xca\xc9OR0c\xc8H\xcd\xc9\xc9\xe7\x02\x00\x1d\xc5\x04\x14'
>>> import vis
>>> print(vis.vis(zlib.compress(s, 1)))
x\^AK\M-J\M-IOR0c\M-HH\M-M\M-I\M-I\M-g\^B\^@\^]\M-E\^D\^T

where vis.py is:

def vischr(byte):
    "encode characters the way vis(1) does by default"
    if byte in b' \t\n':
        return chr(byte)
    # control chars: \^X; del: \^?
    if byte < 32 or byte == 127:
        return r'\^' + chr(byte ^ 64)
    # printable characters, 32..126
    if byte < 128:
        return chr(byte)
    # meta characters: prefix with \M^ or \M-
    byte -= 128
    if byte < 32 or byte == 127:
        return r'\M^' + chr(byte ^ 64)
    return r'\M-' + chr(byte)

def vis(bytestr):
    "same as vis(1)"
    return ''.join(vischr(c) for c in bytestr)

(vis produces an invertible but printable encoding of binary files; it was my 1993-ish answer to problems with cat -v).

Note that the names of files stored in a Git repository (under a commit) appear only as path name components stored in individual tree objects. Computing the hash ID of a tree object is nontrivial; I have Python code that does this in my public "scripts" repository under githash.py.

回答2:

Git Magic mentions:

By the way, the files within .git/objects are compressed with zlib so you should not stare at them directly. Filter them through zpipe -d, or type (using git cat-file):

$ git cat-file -p .git/objects/0c/15af113a95643d7c244332b0e0b287184cd049

With zpipe:

$ ./zpipe -d < .git/objects/0c/15af113a95643d7c244332b0e0b287184cd049

Note: for zpipe, I had to compile zpipe.c first:

sudo apt-get install zlib1g-dev
cd /usr/share/doc/zlib1g-dev/examples
sudo gunzip zpipe.c.gz
sudo gcc -o zpipe zpipe.c -lz

Then:

$ /usr/share/doc/zlib1g-dev/examples/zpipe -d < /usr/share/doc/zlib1g-dev/examples/zpipe -d <

You will get a result like:

vonc@VONCAVN7:/mnt/d/git/seec$ /usr/share/doc/zlib1g-dev/examples/zpipe -d < .git/objects/0d/b6225927ef60e21138a9762c41ea0db714ca0d
blob 2142 <full content there...>

You see a header composed of the type and content size, followed by the actual content.

See "Understanding Git Internals" from Jeff Kunkle, slide 8, for an illustration of a blob actual content:

来源：https://stackoverflow.com/questions/44475891/git-objects-sha-1-are-file-contents-or-file-names

标签

git

git-hash

Git objects SHA-1 are file contents or file names?

徘徊边缘 — Thu, 05 Dec 2019 09:02:14 +0000

Git objects SHA-1 are file contents or file names? 徘徊边缘 2019-12-05 17:02:14

I am confused with how a file's actual contents are stored in .git.

When I open the file 15af113a95643d7c244332b0e0b287184cd049 in a text editor, it's all garbage, something like this

x+)JMU074f040031QÐKÏ,ÉLÏË/Je¨}ºõw[Éœ„ÇR ñ·Î}úyGª*±8#³¨,1%>9?¯$5¯D¯¤¢„áôÏ3%³þú>š~}Ž÷*ë²-¶ç¡êÊòR“KâKòãs+‹sô

But I'm not sure whether this garbage represents the encrypted form of the text Version 1 or it's represented by the SHA-1 15af113a95643d7c244332b0e0b287184cd049.

The correct answer to the question in the subject line:

Git objects SHA-1 are file contents or file names?

After the header come the actual object contents. So, for a file containing the byte string b'hello\n', the data to be hashed consist of b'blob 6\0hello\n:

$ echo 'hello' | git hash-object -t blob --stdin
ce013625030ba8dba906f756967f9e9ca394464a
$ python3
[...]
>>> import hashlib
>>> s = b'blob 6\0hello\n'
>>> hashlib.sha1(s).hexdigest()
'ce013625030ba8dba906f756967f9e9ca394464a'

$ echo 'hello' | git hash-object -w -t blob --stdin
ce013625030ba8dba906f756967f9e9ca394464a
$ vis .git/objects/ce/013625030ba8dba906f756967f9e9ca394464a
x\^AK\M-J\M-IOR0c\M-HH\M-M\M-I\M-I\M-g\^B\000\^]\M-E\^D\^T$

(note that the final $ is the shell prompt again; now back to Python3)

>>> import zlib
>>> zlib.compress(s, 1)
b'x\x01K\xca\xc9OR0c\xc8H\xcd\xc9\xc9\xe7\x02\x00\x1d\xc5\x04\x14'
>>> import vis
>>> print(vis.vis(zlib.compress(s, 1)))
x\^AK\M-J\M-IOR0c\M-HH\M-M\M-I\M-I\M-g\^B\^@\^]\M-E\^D\^T

where vis.py is:

def vischr(byte):
    "encode characters the way vis(1) does by default"
    if byte in b' \t\n':
        return chr(byte)
    # control chars: \^X; del: \^?
    if byte < 32 or byte == 127:
        return r'\^' + chr(byte ^ 64)
    # printable characters, 32..126
    if byte < 128:
        return chr(byte)
    # meta characters: prefix with \M^ or \M-
    byte -= 128
    if byte < 32 or byte == 127:
        return r'\M^' + chr(byte ^ 64)
    return r'\M-' + chr(byte)

def vis(bytestr):
    "same as vis(1)"
    return ''.join(vischr(c) for c in bytestr)

(vis produces an invertible but printable encoding of binary files; it was my 1993-ish answer to problems with cat -v).

Git Magic mentions:

By the way, the files within .git/objects are compressed with zlib so you should not stare at them directly. Filter them through zpipe -d, or type (using git cat-file):

$ git cat-file -p .git/objects/0c/15af113a95643d7c244332b0e0b287184cd049

With zpipe:

$ ./zpipe -d < .git/objects/0c/15af113a95643d7c244332b0e0b287184cd049

Note: for zpipe, I had to compile zpipe.c first:

sudo apt-get install zlib1g-dev
cd /usr/share/doc/zlib1g-dev/examples
sudo gunzip zpipe.c.gz
sudo gcc -o zpipe zpipe.c -lz

Then:

$ /usr/share/doc/zlib1g-dev/examples/zpipe -d < /usr/share/doc/zlib1g-dev/examples/zpipe -d <

You will get a result like:

vonc@VONCAVN7:/mnt/d/git/seec$ /usr/share/doc/zlib1g-dev/examples/zpipe -d < .git/objects/0d/b6225927ef60e21138a9762c41ea0db714ca0d
blob 2142 <full content there...>

You see a header composed of the type and content size, followed by the actual content.

See "Understanding Git Internals" from Jeff Kunkle, slide 8, for an illustration of a blob actual content:

来源：https://stackoverflow.com/questions/44475891/git-objects-sha-1-are-file-contents-or-file-names

标签

git

git-hash

Telling if a Git commit is a Merge/Revert commit

南笙酒味 — Thu, 28 Nov 2019 18:50:45 +0000

Telling if a Git commit is a Merge/Revert commit 南笙酒味 2019-11-29 02:50:45

I am writing a script that requires checking whether a particular commit is a Merge/Revert commit or not, and I am wondering if there is a git trick for that.

What I came up with so far (and I definitely don't want to depend on the commit message here) is to check HASH^2 and see if I don't get an error, is there a better way?

Figuring out if something is a merge is easy. That's all commits with more than one parent. To check for that, you can do, for example

$ git cat-file -p $commit_id

If there's more than one `parent' line in the output, you found a merge.

For reverts it's not as easy. Generally reverts are just normal commits that happen to apply the diff of a previous commit in reverse, effectively removing the changes that commit introduced. There're not special otherwise.

If a revert was created with git revert $commit, then git usually generates a commit message indication the revert and what commit it reverted. However, it's quite possible to do reverts in other ways, or to just change the commit message of a commit generated by git revert.

Looking for those generated revert commit message might already be a good enough heuristic for what you're trying to achieve. If not, you'd have to actually look through other commits, comparing their diffs against each other, looking of one is the exact reverse operation of another. But even that isn't a good solution. Often enough reverts are slightly different than just the reverse of the commit they're reverting, for example to accomodate for code changes that happened between the commit and the revert.

Dave

The following instruction will dump out only the parent hashes. Less filtering needed...

git show --no-patch --format="%P" <commit hash>

The answer using git cat-file is using a git "plumbing" command, which is generally better for building scripts as the output format is not likely to change. The ones using git show and git rev-parse may need to change over time as they are using porcelain commands.

The bash function I've been using for a long time uses git rev-list:

gitismerge () {
    local sha="$1"
    msha=$(git rev-list -1 --merges ${sha}~1..${sha})
    [ -z "$msha" ] && return 1
    return 0
}

The list of porcelain/plumbing commands can be found in the docs for the top level git command.

This code uses git-rev-list with a specific gitrevisions query ${sha}~1..${sha} in a way that prints a SHA's second parent if it exists, or nothing if it is not present, which is the exact definition of a merge commit.

Specifically, SHA~1..SHA means include commits that are reachable from SHA but exclude those that are reachable SHA~1, which is the first parent of SHA.

The results are stored in $msha and tested for emptiness using bash [ -z "$msha" ] failing (returning 1) if empty, or passing (returning 0) if non-empty.

One way to test for a merge commit:

$ test -z $(git rev-parse --verify $commit^2 2> /dev/null) || echo MERGE COMMIT

As for git revert commits, I agree with @rafl that the most realistic approach is to look for the revert message boilerplate in the commit message; if someone changed it, detecting so would be very involved.

Easy way to test for merge commit:

git show --summary HEAD | grep -q ^Merge:

This will return 0 for merge commits, 1 for non-merge commits. Replace HEAD by your desired commit to test.

Example usage:

if git show --summary some-branch | grep -q ^Merge: ; then
    echo "some-branch is a merge"
fi

Yet another way to find a commit's parents:

git show -s --pretty=%p <commit>

Use %P for full hash. This prints how many parents HEAD has:

git show -s --pretty=%p HEAD | wc -w

来源：https://stackoverflow.com/questions/3824050/telling-if-a-git-commit-is-a-merge-revert-commit

标签

How does Git create unique commit hashes, mainly the first few characters?

烈酒焚心 — Thu, 28 Nov 2019 18:48:50 +0000

How does Git create unique commit hashes, mainly the first few characters? 烈酒焚心 2019-11-29 02:48:50

问题

I find it hard to wrap my head around how Git creates fully unique hashes that aren't allowed to be the same even in the first 4 characters. I'm able to call commits in Git Bash using only the first four characters. Is it specifically decided in the algorithm that the first characters are "ultra"-unique and will not ever conflict with other similar hashes, or does the algorithm generate every part of the hash in the same way?

回答1:

Git uses the following information to generate the sha-1:

The source tree of the commit (which unravels to all the subtrees and blobs)
The parent commit sha1
The author info (with timestamp)
The committer info (right, those are different!, also with timestamp)
The commit message

(on the complete explanation; look here).

Git does NOT guarantee that the first 4 characters will be unique. In chapter 7 of the Pro Git Book it is written:

Git can figure out a short, unique abbreviation for your SHA-1 values. If you pass --abbrev-commit to the git log command, the output will use shorter values but keep them unique; it defaults to using seven characters but makes them longer if necessary to keep the SHA-1 unambiguous:

So Git just makes the abbreviation as long as necessary to remain unique. They even note that:

Generally, eight to ten characters are more than enough to be unique within a project.

As an example, the Linux kernel, which is a pretty large project with over 450k commits and 3.6 million objects, has no two objects whose SHA-1s overlap more than the first 11 characters.

So in fact they just depend on the great improbability of having the exact same (X first characters of a) sha.

回答2:

Apr. 2017: Beware that after the all shattered.io episode (where a SHA1 collision was achieved by Google), the 20-byte format won't be there forever.

A first step for that is to replace unsigned char sha1[20] which is hard-code all over the Git codebase by a generic object whose definition might change in the future (SHA2?, Blake2, ...)

See commit e86ab2c (21 Feb 2017) by brian m. carlson (bk2204).

Convert the remaining uses of unsigned char [20] to struct object_id.

That is an example of an ongoing effort started with commit 5f7817c (13 Mar 2015) by brian m. carlson (bk2204), for v2.5.0-rc0, in cache.h:

/* The length in bytes and in hex digits of an object name (SHA-1 value). */
#define GIT_SHA1_RAWSZ 20
#define GIT_SHA1_HEXSZ (2 * GIT_SHA1_RAWSZ)

struct object_id {
    unsigned char hash[GIT_SHA1_RAWSZ];
};

And don't forget that, even with SHA1, the 4 first characters are no longer enough to guarantee uniqueness, as I explain in "How much of a git sha is generally considered necessary to uniquely identify a change in a given codebase?".

Update Dec. 2017 with Git 2.16 (Q1 2018): this effort to support an alternative SHA is underway: see "Why doesn't Git use more modern SHA?".

You will be able to use another hash: SHA1 is no longer the only one for Git.

Update 2018-2019: the choice has been made in Git 2.19+: SHA-256.
See "hash-function-transition".

This is not yet active (meaning git 2.21 is still using SHA1), but the code is being done to support in the future SHA-256.

来源：https://stackoverflow.com/questions/34764195/how-does-git-create-unique-commit-hashes-mainly-the-first-few-characters

标签

Get the current git hash in a Python script

北城余情 — Thu, 28 Nov 2019 08:01:53 +0000

Get the current git hash in a Python script 北城余情 2019-11-28 16:01:53

I would like to include the current git hash in the output of a Python script (as a the version number of the code that generated that output).

How can I access the current git hash in my Python script?

Greg Hewgill

The git describe command is a good way of creating a human-presentable "version number" of the code. From the examples in the documentation:

With something like git.git current tree, I get:
[torvalds@g5 git]$ git describe parent
v1.0.4-14-g2414721
i.e. the current head of my "parent" branch is based on v1.0.4, but since it has a few commits on top of that, describe has added the number of additional commits ("14") and an abbreviated object name for the commit itself ("2414721") at the end.

From within Python, you can do something like the following:

import subprocess
label = subprocess.check_output(["git", "describe"]).strip()

guaka

No need to hack around getting data from the git command yourself. GitPython is a very nice way to do this and a lot of other git stuff. It even has "best effort" support for Windows.

After pip install gitpython you can do

import git
repo = git.Repo(search_parent_directories=True)
sha = repo.head.object.hexsha

Yuji 'Tomita' Tomita

This post contains the command, Greg's answer contains the subprocess command.

import subprocess

def get_git_revision_hash():
    return subprocess.check_output(['git', 'rev-parse', 'HEAD'])

def get_git_revision_short_hash():
    return subprocess.check_output(['git', 'rev-parse', '--short', 'HEAD'])

numpy has a nice looking multi-platform routine in its setup.py:

import os
import subprocess

# Return the git revision as a string
def git_version():
    def _minimal_ext_cmd(cmd):
        # construct minimal environment
        env = {}
        for k in ['SYSTEMROOT', 'PATH']:
            v = os.environ.get(k)
            if v is not None:
                env[k] = v
        # LANGUAGE is used on win32
        env['LANGUAGE'] = 'C'
        env['LANG'] = 'C'
        env['LC_ALL'] = 'C'
        out = subprocess.Popen(cmd, stdout = subprocess.PIPE, env=env).communicate()[0]
        return out

    try:
        out = _minimal_ext_cmd(['git', 'rev-parse', 'HEAD'])
        GIT_REVISION = out.strip().decode('ascii')
    except OSError:
        GIT_REVISION = "Unknown"

    return GIT_REVISION

If subprocess isn't portable and you don't want to install a package to do something this simple you can also do this.

import pathlib

def get_git_revision(base_path):
    git_dir = pathlib.Path(base_path) / '.git'
    with (git_dir / 'HEAD').open('r') as head:
        ref = head.readline().split(' ')[-1].strip()

    with (git_dir / ref).open('r') as git_hash:
        return git_hash.readline().strip()

I've only tested this on my repos but it seems to work pretty consistantly.

来源：https://stackoverflow.com/questions/14989858/get-the-current-git-hash-in-a-python-script

标签

python

git

git-hash

Telling if a Git commit is a Merge/Revert commit

核能气质少年 — Wed, 27 Nov 2019 09:08:01 +0000

Telling if a Git commit is a Merge/Revert commit 核能气质少年 2019-11-27 17:08:01

问题

I am writing a script that requires checking whether a particular commit is a Merge/Revert commit or not, and I am wondering if there is a git trick for that.

What I came up with so far (and I definitely don't want to depend on the commit message here) is to check HASH^2 and see if I don't get an error, is there a better way?

回答1:

Figuring out if something is a merge is easy. That's all commits with more than one parent. To check for that, you can do, for example

$ git cat-file -p $commit_id

If there's more than one `parent' line in the output, you found a merge.

回答2:

The following instruction will dump out only the parent hashes. Less filtering needed...

git show --no-patch --format="%P" <commit hash>

回答3:

The bash function I've been using for a long time uses git rev-list:

gitismerge () {
    local sha="$1"
    msha=$(git rev-list -1 --merges ${sha}~1..${sha})
    [ -z "$msha" ] && return 1
    return 0
}

The list of porcelain/plumbing commands can be found in the docs for the top level git command.

Specifically, SHA~1..SHA means include commits that are reachable from SHA but exclude those that are reachable SHA~1, which is the first parent of SHA.

The results are stored in $msha and tested for emptiness using bash [ -z "$msha" ] failing (returning 1) if empty, or passing (returning 0) if non-empty.

回答4:

One way to test for a merge commit:

$ test -z $(git rev-parse --verify $commit^2 2> /dev/null) || echo MERGE COMMIT

回答5:

Easy way to test for merge commit:

git show --summary HEAD | grep -q ^Merge:

This will return 0 for merge commits, 1 for non-merge commits. Replace HEAD by your desired commit to test.

Example usage:

if git show --summary some-branch | grep -q ^Merge: ; then
    echo "some-branch is a merge"
fi

回答6:

Yet another way to find a commit's parents:

git show -s --pretty=%p <commit>

Use %P for full hash. This prints how many parents HEAD has:

git show -s --pretty=%p HEAD | wc -w

来源：https://stackoverflow.com/questions/3824050/telling-if-a-git-commit-is-a-merge-revert-commit

标签