t9300: use test_cmp_bin instead of test_cmp to compare binary files by t-b · Pull Request #2 · git-for-windows/git

t-b · 2014-09-24T17:01:13Z

Already in junio/master as git/git@f9f3851.

test_cmp is intended to produce diff output for human consumption. The input in one instance in t9300-fast-import.sh are binary files, however. Use test_cmp_bin to compare the files. This was noticed because on Windows we have a special implementation of test_cmp in pure bash code (to ignore differences due to intermittent CR in actual output), and bash runs into an infinite loop due to the binary nature of the input. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>

t-b · 2014-09-25T18:30:04Z

@git-for-windows/owners
@git-for-windows/maintainers
Any objections?

sschuberth · 2014-09-25T18:54:54Z

Not from my side. At first I though this would be contained in v2.1.1, in which case we should have rather done a rebasing merge against upstream, but it's not in there. Also, it does not seem to fix any of our failing tests, but nevertheless I'm fine with merging.

t-b · 2014-09-25T19:34:08Z

T9300 fails here locally sometimes and sometimes not. With that patch it fails never.
I've no idea why that did not make it into v2.1.1.

dscho · 2014-09-25T20:56:34Z

No objections from my side, either! I believe it is obviously a correct change.

t9300: use test_cmp_bin instead of test_cmp to compare binary files

t-b · 2014-09-25T21:16:32Z

Thanks both. Merged!

t9300: use test_cmp_bin instead of test_cmp to compare binary files

The main loop in strbuf_utf8_replace() could summed up as: while ('src' is still valid) { 1) advance 'src' to copy ANSI escape sequences 2) advance 'src' to copy/replace visible characters } The problem is after #1, 'src' may have reached the end of the string (so 'src' points to NUL) and #2 will continue to copy that NUL as if it's a normal character. Because the output is stored in a strbuf, this NUL accounted in the 'len' field as well. Check after #1 and break the loop if necessary. The test does not look obvious, but the combination of %>>() should make a call trace like this show_log() pretty_print_commit() format_commit_message() strbuf_expand() format_commit_item() format_and_pad_commit() strbuf_utf8_replace() where %C(auto)%d would insert a color reset escape sequence in the end of the string given to strbuf_utf8_replace() and show_log() uses fwrite() to send everything to stdout (including the incorrect NUL inserted by strbuf_utf8_replace) Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

The intent of the new test case is to catch general breakages in the fsck_tag() function, not so much to test it extensively, trying to strike the proper balance between thoroughness and speed. While it *would* have been nice to test the code path where fsck_object() encounters an invalid tag object, this is not possible using git fsck: tag objects are parsed already before fsck'ing (and the parser already fails upon such objects). Even worse: we would not even be able write out invalid tag objects because git hash-object parses those objects, too, unless we resorted to really ugly hacks such as using something like this in the unit tests (essentially depending on Perl *and* Compress::Zlib): hash_invalid_object () { contents="$(printf '%s %d\0%s' "$1" ${#2} "$2")" && sha1=$(echo "$contents" | test-sha1) && suffix=${sha1#??} && mkdir -p .git/objects/${sha1%$suffix} && echo "$contents" | perl -MCompress::Zlib -e 'undef $/; print compress(<>)' \ > .git/objects/${sha1%$suffix}/$suffix && echo $sha1 } Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>

Indent is done with HTs, not a run of SPs. Signed-off-by: Junio C Hamano <gitster@pobox.com>

* jc/t9001-modernise: t9001: style modernisation phase #5 t9001: style modernisation phase #4 t9001: style modernisation phase #3 t9001: style modernisation phase #2 t9001: style modernisation phase #1

b6d8f30 (diff-raw format update take #2., 2005-05-23) started documenting the diff format, and it said ... (8) sha1 for "dst"; 0{40} if creation, unmerged or "look at work tree". (9) status, followed by similarlity index number only for C and R. (10) a tab or a NUL when '-z' option is used. ... because C and R _were_ the only ones that came with a number back then. This was corrected by ddafa7e (diff-helper: Fix R/C score parsing under -z flag., 2005-05-29) and we started saying "score" instead of "similarlity index" (because we can have other kind of score there), and stopped saying "only for C and R" (because Git is an ever evolving system). Later f345b0a (Add -B flag to diff-* brothers., 2005-05-30) introduced a new concept, "dissimilarity" score; it did not have to fix any documentation. The current text that says only C and R can have scores came independently from a5a323f (Add reference for status letters in documentation., 2008-11-02) and it was wrong from the day one. Noticed-by: Mike Hommey Signed-off-by: Junio C Hamano <gitster@pobox.com>

Signed-off-by: Junio C Hamano <gitster@pobox.com>

The collect_parents() function now is responsible for 1. parsing the commits given on the command line into a list of commits to be merged; 2. filtering these parents into independent ones; and 3. optionally calling fmt_merge_msg() via prepare_merge_message() to prepare an auto-generated merge log message, using fake contents that FETCH_HEAD would have had if these commits were fetched from the current repository with "git pull . $args..." Make "git merge FETCH_HEAD" to be the same as the traditional git merge "$(git fmt-merge-msg <.git/FETCH_HEAD)" $commits invocation of the command in "git pull", where $commits are the ones that appear in FETCH_HEAD that are not marked as not-for-merge, by making it do a bit more, specifically: - noticing "FETCH_HEAD" is the only "commit" on the command line and picking the commits that are not marked as not-for-merge as the list of commits to be merged (substitute for step #1 above); - letting the resulting list fed to step #2 above; - doing the step #3 above, using the contents of the FETCH_HEAD instead of fake contents crafted from the list of commits parsed in the step #1 above. Note that this changes the semantics. "git merge FETCH_HEAD" has always behaved as if the first commit in the FETCH_HEAD file were directly specified on the command line, creating a two-way merge whose auto-generated merge log said "merge commit xyz". With this change, if the previous fetch was to grab multiple branches (e.g. "git fetch $there topic-a topic-b"), the new world order is to create an octopus, behaving as if "git pull $there topic-a topic-b" were run. This is a deliberate change to make that happen, and can be seen in the changes to t3033 tests. Signed-off-by: Junio C Hamano <gitster@pobox.com>

The controlling tty-based heuristics to squelch progress output did not consider that the process may not be talking to a tty at all (e.g. sending the progress to sideband #2). This is a finishing touch to a topic that is already in 'master'. * lm/squelch-bg-progress: progress: treat "no terminal" as being in the foreground

A "rebase" replays changes of the local branch on top of something else, as such they are placed in stage #3 and referred to as "theirs", while the changes in the new base, typically a foreign work, are placed in stage #2 and referred to as "ours". Clarify the "checkout --ours/--theirs". * se/doc-checkout-ours-theirs: checkout: document subtlety around --ours/--theirs

When ac49f5c (rerere "remaining", 2011-02-16) split out a new helper function check_one_conflict() out of find_conflict() function, so that the latter will use the returned value from the new helper to update the loop control variable that is an index into active_cache[], the new variable incremented the index by one too many when it found a path with only stage #1 entry at the very end of active_cache[]. This "strange" return value does not have any effect on the loop control of two callers of this function, as they all notice that active_nr+2 is larger than active_nr just like active_nr+1 is, but nevertheless it puzzles the readers when they are trying to figure out what the function is trying to do. In fact, there is no need to do an early return. The code that follows after skipping the stage #1 entry is fully prepared to handle a case where the entry is at the very end of active_cache[]. Help future readers from unnecessary confusion by dropping an early return. We skip the stage #1 entry, and if there are stage #2 and stage git-for-windows#3 entries for the same path, we diagnose the path as THREE_STAGED (otherwise we say PUNTED), and then we skip all entries for the same path. Signed-off-by: Junio C Hamano <gitster@pobox.com>

When merge_recursive() decides what the correct blob object merge result for a path should be, it uses update_file_flags() helper function to write it out to a working tree file and then calls add_cacheinfo(). The add_cacheinfo() function in turn calls make_cache_entry() to create a new cache entry to replace the higher-stage entries for the path that represents the conflict. The make_cache_entry() function calls refresh_cache_entry() to fill in the cached stat information. To mark a cache entry as up-to-date, the data is re-read from the file in the working tree, and goes through convert_to_git() conversion to be compared with the blob object name the new cache entry records. It is important to note that this happens while the higher-stage entries, which are going to be replaced with the new entry, are still in the index. Unfortunately, the convert_to_git() conversion has a misguided "safer crlf" mechanism baked in, and looks at the existing cache entry for the path to decide how to convert the contents in the working tree file. If our side (i.e. stage#2) records a text blob with CRLF in it, even when the system is configured to record LF in blobs and convert them to CRLF upon checkout (and back to LF upon checkin), the "safer crlf" mechanism stops us doing so. This especially poses a problem during a renormalizing merge, where the merge result for the path is computed by first "normalizing" the blobs involved in the merge by using convert_to_working_tree() followed by convert_to_git() with "safer crlf" disabled. The merge result that is computed correctly and fed to add_cacheinfo() via update_file_flags() does _not_ match what refresh_cache_entry() sees by converting the working tree file via convert_to_git(). We can work this around by not refreshing the new cache entry in make_cache_entry() called by add_cacheinfo(). After add_cacheinfo() adds the new entry, we can call refresh_cache_entry() on that, knowing that addition of this new cache entry would have removed the stale cache entries that had CRLF in stage #2 that were carried over before the renormalizing merge started and will not interfere with the correct recording of the result. The test update was taken from a series by Torsten Bögershausen that attempted to fix this with a different approach. Signed-off-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> Reviewed-by: Torsten Bögershausen <tboegi@web.de>

How pathspec is used, with and without --interactive/--patch, is different. But this is not clear from the document. These changes hint the user to keep reading (to option #5) instead of stopping at #2 and assuming --patch/--interactive behaves the same way. And since all the options listed here always mention how the index is involved (or not) in the final commit, add that bit for #5 as well. This "on top of the index" is implied when you head over git-add(1), but if you just go straight to the "Interactive mode" and not read what git-add is for, you may miss it. Signed-off-by: Nguyễn Thái Ngọc Duy <pclouds@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>

When importing from multiple perforce paths - we may attempt to import a changelist that contains files from two (or more) of these depot paths. Currently, this results in multiple git commits - one containing the changes, and the other(s) as empty commit(s). This behavior was introduced in commit 1f90a64 ("git-p4: reduce number of server queries for fetches", 2015-12-19). Reproduction Steps: 1. Have a git repo cloned from a perforce repo using multiple depot paths (e.g. //depot/foo and //depot/bar). 2. Submit a single change to the perforce repo that makes changes in both //depot/foo and //depot/bar. 3. Run "git p4 sync" to sync the change from #2. Change is synced as multiple commits, one for each depot path that was affected. Using a set, instead of a list inside p4ChangesForPaths() ensures that each changelist is unique to the returned list, and therefore only a single commit is generated for each changelist. Reported-by: James Farwell <jfarwell@vmware.com> Signed-off-by: George Vanburgh <gvanburgh@bloomberg.net> Reviewed-by: Luke Diamand <luke@diamand.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>

We generate the squash commit message incrementally running a sed script once for each commit. It parses "This is a combination of <N> commits" from the first line of the existing message, adds one to <N>, and uses the result as the number of our current message. Since f2d1706 (i18n: rebase-interactive: mark comments of squash for translation, 2016-06-17), the first line may be localized, and sed uses a pretty liberal regex, looking for: /^#.*([0-9][0-9]*)/ The "[0-9][0-9]*" tries to match double digits, but it doesn't quite work. The first ".*" is greedy, so if you have: This is a combination of 10 commits. it will eat up "This is a combination of 1", leaving "0" to match the first "[0-9]" digit, and then skipping the optional match of "[0-9]*". As a result, the count resets every 10 commits, and a 15-commit squash would end up as: # This is a combination of 5 commits. # This is the 1st commit message: ... # This is the commit message #2: ... and so on .. # This is the commit message #10: ... # This is the commit message #1: ... # This is the commit message #2: ... etc, up to 5 ... We can fix this by making the ".*" less greedy. Instead of depending on ".*?" working portably, we can just limit the match to non-digit characters, which accomplishes the same thing. Reported-by: Brandon Tolsch <btolsch@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>

The changed-path Bloom filter is improved using ideas from an independent implementation. * sg/commit-graph-cleanups: commit-graph: simplify write_commit_graph_file() #2 commit-graph: simplify write_commit_graph_file() #1 commit-graph: simplify parse_commit_graph() #2 commit-graph: simplify parse_commit_graph() #1 commit-graph: clean up #includes diff.h: drop diff_tree_oid() & friends' return value commit-slab: add a function to deep free entries on the slab commit-graph-format.txt: all multi-byte numbers are in network byte order commit-graph: fix parsing the Chunk Lookup table tree-walk.c: don't match submodule entries for 'submod/anything'

t-b added a commit that referenced this pull request Sep 25, 2014

Merge pull request #2 from t-b/tb_more_use_of_test_cmp_bin

4261e45

t9300: use test_cmp_bin instead of test_cmp to compare binary files

t-b merged commit 4261e45 into git-for-windows:master Sep 25, 2014

t-b deleted the tb_more_use_of_test_cmp_bin branch September 25, 2014 21:16

t-b added a commit that referenced this pull request Oct 13, 2014

Merge pull request #2 from t-b/tb_more_use_of_test_cmp_bin

c3051df

t9300: use test_cmp_bin instead of test_cmp to compare binary files

dscho pushed a commit that referenced this pull request Mar 6, 2015

t9001: style modernisation phase #2

03335f2

Indent is done with HTs, not a run of SPs. Signed-off-by: Junio C Hamano <gitster@pobox.com>

dscho pushed a commit that referenced this pull request Mar 6, 2015

Post 2.3 cycle (batch #2)

3188ab3

Signed-off-by: Junio C Hamano <gitster@pobox.com>

ghost mentioned this pull request Jul 9, 2015

Unknown SSL protocol error in connection to github.com:443 #234

Closed

jmedemaUD mentioned this pull request Sep 1, 2015

git gui clones non-master default branch as master #345

Closed

DarwinJS mentioned this pull request Dec 14, 2015

Use of "icons\quicklaunch" install option, while executing under system account causes hang #570

Closed

PhilipOakley mentioned this pull request Jan 16, 2016

Git 2.6.2 and higher sending NTLM token instead of Kerberos when Negotiate is used #611

Closed

paladox mentioned this pull request Apr 6, 2016

Fix using windows path in git for windows #720

Closed

1 task

schittli mentioned this pull request Sep 17, 2020

Windows Setup » 'Choose the default editor used by Git': two small but useful suggestions #2818

Closed

desbest mentioned this pull request Nov 5, 2020

"failed to restrict file handles" while running git svn #2890

Closed

1 task

raghuit mentioned this pull request Dec 1, 2020

new issue #2917

Closed

1 task

rimrul mentioned this pull request Dec 11, 2020

exception by libre-core pull #2931

Closed

1 task

liu-sen mentioned this pull request Jan 15, 2021

failed to restrict file handles #2982

Closed

awsunit mentioned this pull request May 6, 2021

Failed to restrict file handles #3215

Closed

1 task

jonypeixoto mentioned this pull request Aug 11, 2023

warning: failed to restrict file handles #4554

Closed

1 task

venus-Liu mentioned this pull request Dec 25, 2023

git error #4748

Open

vivtiwary mentioned this pull request Jan 5, 2024

Issue in pulling or pushing codes for windows #4757

Closed

TomClabault mentioned this pull request Jun 17, 2024

warning: failed to restrict file handles (5) #5012

Closed

1 task

renzfan mentioned this pull request Jul 22, 2024

git pull failed #5069

Closed

mercy0424 mentioned this pull request Jul 24, 2024

git pull failed #5072

Closed

fatihforgemaster mentioned this pull request Feb 10, 2025

i think i have to report this #5412

Closed

ykabctao mentioned this pull request Feb 17, 2025

warning: failed to restrict file handles (5) #5428

Closed

LukaszBolbotCepheo mentioned this pull request Feb 18, 2025

warning: failed to restrict file handles (786) #5432

Closed

icebear-ux mentioned this pull request Aug 12, 2025

bug1 #5770

Closed

1 task

AwesomePhoenix-0 mentioned this pull request Sep 22, 2025

Bug when cloning a repositery in android studio #5834

Closed

1 task

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

t9300: use test_cmp_bin instead of test_cmp to compare binary files#2

t9300: use test_cmp_bin instead of test_cmp to compare binary files#2
t-b merged 1 commit intogit-for-windows:masterfrom
t-b:tb_more_use_of_test_cmp_bin

t-b commented Sep 24, 2014

Uh oh!

t-b commented Sep 25, 2014

Uh oh!

sschuberth commented Sep 25, 2014

Uh oh!

t-b commented Sep 25, 2014

Uh oh!

dscho commented Sep 25, 2014

Uh oh!

t-b commented Sep 25, 2014

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants

Conversation

t-b commented Sep 24, 2014

Uh oh!

t-b commented Sep 25, 2014

Uh oh!

sschuberth commented Sep 25, 2014

Uh oh!

t-b commented Sep 25, 2014

Uh oh!

dscho commented Sep 25, 2014

Uh oh!

t-b commented Sep 25, 2014

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

4 participants