This repository has been archived by the owner on Nov 9, 2017. It is now read-only.
(invalid) #427
Closed
(invalid) #427
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
UI consistency improvements. * nf/mergetool-prompt: difftool/mergetool: make the form of yes/no questions consistent
Fix a broken test. * ls/p4-lfs-test-fix-2.7.0: t9824: fix wrong reference value t9824: fix broken &&-chain in a subshell
Recent update to Git LFS broke "git p4" by changing the output from its "lfs pointer" subcommand. * ls/p4-lfs: git-p4: fix Git LFS pointer parsing travis-ci: express Linux/OS X dependency versions more clearly travis-ci: update Git-LFS and P4 to the latest version
* js/close-packs-before-gc: t5510: run auto-gc in the foreground
* ls/travis-submitting-patches: Documentation: add setup instructions for Travis CI
Some multi-byte encoding can have a backslash byte as a later part of one letter, which would confuse "highlight" filter used in gitweb. * sk/gitweb-highlight-encoding: gitweb: apply fallback encoding before highlight
Code cleanup. * nd/remove-unused: wrapper.c: delete dead function git_mkstemps() dir.c: remove dead function fnmatch_icase()
Code cleanup. * sg/test-lib-simplify-expr-away: test-lib: simplify '--option=value' parsing
Code fixup. * jk/fix-attribute-macro-in-2.5: remote.c: spell __attribute__ correctly
Code cleanup. * rt/string-list-lookup-cleanup: string_list: use string-list API in unsorted_string_list_lookup()
Doc update. * sb/config-exit-status-list: config doc: improve exit code listing
* ew/normal-to-e: .mailmap: update to my shorter email address
* rn/glossary-typofix: Documentation: fix typo 'In such these cases'
* sb/clean-test-fix: t7300: mark test with SANITY
Doc update. * ew/doc-split-pack-disables-bitmap: pack-objects: warn on split packs disabling bitmaps
* sb/misc-cleanups: submodule-config: don't shadow `cache` config.c: drop local variable credential-cache, send_request: close fd when done bundle: don't leak an fd in case of early return abbrev_sha1_in_line: don't leak memory notes: don't leak memory in git_config_get_notes_strategy
This commit starts the rebase of 5433917 to 90b4299
Assumes file names in git tree objects are UTF-8 encoded. On most unix systems, the system encoding (and thus the TCL system encoding) will be UTF-8, so file names will be displayed correctly. On Windows, it is impossible to set the system encoding to UTF-8. Changing the TCL system encoding (via 'encoding system ...', e.g. in the startup code) is explicitly discouraged by the TCL docs. Change gitk and git-gui functions dealing with file names to always convert from and to UTF-8. Signed-off-by: Karsten Blees <blees@dcon.de>
At least for cross-platform projects, it makes sense to hide the files starting with a dot, as this is the behavior on Unix/MacOSX. However, at least Eclipse has problems interpreting the hidden flag correctly, so the default is to hide only the .git/ directory. The config setting core.hideDotFiles therefore supports not only 'true' and 'false', but also 'dotGitOnly'. [jes: clarified the commit message, made git init respect the setting by marking the .git/ directory only after reading the config, and added documentation, and rebased on top of current junio/next] Signed-off-by: Erik Faye-Lund <kusmabite@gmail.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
If we use 'eval exec $opt $cmdp $args' to execute git command, tcl engine will convert the output of the git comand with the rule system default code page to unicode. But cp936 -> unicode conversion implicitly done by exec is not reversible. So we have to use git_read instead. Bug report and an original reproducer by Cloud Chou: msysgit#302 Karsten Blees writes this code patch. Cloud Chou find the reason of the bug. Thanks-to: dscho Thanks-to: patthoyts Signed-off-by: Karsten Blees <blees@dcon.de> Original-test-by: Cloud Chou <515312382@qq.com> Signed-off-by: Cloud Chou <515312382@qq.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This is on Windows only, of course. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
With msysGit the .git directory is supposed to be hidden, unless it is a bare git repository. Test this. Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net>
This reverts commit a9fa11f.
Make use of the new environment variable GIT_ASK_YESNO to support the recently implemented fallback in case unlink, rename or rmdir fail for files in use on Windows. The added dialog will present a yes/no question to the the user which will currently be used by the windows compat layer to let the user retry a failed file operation. Signed-off-by: Heiko Voigt <hvoigt@hvoigt.net>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
On Windows, there are dramatic problems when a command line grows beyond PATH_MAX, which is restricted to 8191 characters on XP and later (according to http://support.microsoft.com/kb/830473). Work around this by just cutting off the command line at that length (actually, at a space boundary) in the hope that only negative refs are chucked: gitk will then do unnecessary work, but that is still better than flashing the gitk window and exiting with exit status 5 (which no Windows user is able to make sense of). The first fix caused Tcl to fail to compile the regexp, see msysGit issue 427. Here is another fix without using regexp, and using a more relaxed command line length limit to fix the original issue 387. Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com> Signed-off-by: Pat Thoyts <patthoyts@users.sourceforge.net> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
Make sure the helper does not crash when blank username and password is provided. If the helper can save such credentials, it should be able to read them back. Signed-off-by: Jakub Bereżański <kuba@berezanscy.pl>
Git for Windows now ships with the new Git icon from git-scm.com. Use that icon file if it exists instead of the old procedurally drawn one. This patch was sent upstream but so far no decision on its inclusion was made, so commit it to our fork. Signed-off-by: Sebastian Schuberth <sschuberth@gmail.com>
This fixes #723 Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This change lets us spawn .bat scripts whose paths contain spaces. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git commit --amend preserves the author details unless --reset-author is given. git-gui discards the author details on amend. Fix by reading the author details along with the commit message, and setting the appropriate environment variables required for preserving them. Reported long ago in the mailing list[1]. [1] http://article.gmane.org/gmane.comp.version-control.git/243921 Signed-off-by: Orgad Shaneh <orgad.shaneh@audiocodes.com>
This topic branch increases the precision of the version recorded in the resources of the .exe files from major/minor to include also the micro version and the patch level. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git-gui: Do not reset author details on amend
When --reference or --depth are unused, the current git-submodule.sh results in empty "" arguments appended to the end of the argv array inside git submodule--helper clone. This is not caught because the argc count is not checked today. Fix git-submodule.sh to only pass an argument when --reference or --depth are used, preventing the addition of two empty string arguments on the tail of the argv array. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Extra unused arguments to git submodule--helper clone subcommand were being silently ignored. Add a check to the argc count after options handling to ensure that no extra arguments were left on the argv array. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
git submodule--helper clone usage stated that paths were added after the [--] argument. The actual implementation required use of --path argument and only supports one path at a time. Update the usage string to match the current implementation. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The git submodule--helper clone command will fail with a segmentation fault when given a null url or null path variable. Since these are required for proper functioning of the submodule--helper clone subcommand, add checks to prevent running and fail gracefully when missing. Update the usage string to reflect the requirement that the --url and --path "options" are required. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Reviewed-by: Stefan Beller <sbeller@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
We introduce a way to send custom HTTP headers with all requests. This allows us, for example, to send an extra token from build agents for temporary access to private repositories. (This is the use case that triggered this patch.) This feature can be used like this: git -c http.extraheader='Secret: sssh!' fetch $URL $REF Note that `curl_easy_setopt(..., CURLOPT_HTTPHEADER, ...)` takes only a single list, overriding any previous call. This means we have to collect _all_ of the headers we want to use into a single list, and feed it to cURL in one shot. Since we already unconditionally set a "pragma" header when initializing the curl handles, we can add our new headers to that list. For callers which override the default header list (like probe_rpc), we provide `http_copy_default_headers()` so they can do the same trick. Big thanks to Jeff King and Junio Hamano for their outstanding help and patient reviews. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Lars Schneider noticed that the configuration introduced to test the
extra HTTP headers cannot be used with Apache 2.2 (which is still
actively maintained, as pointed out by Junio Hamano).
To let the tests pass with Apache 2.2 again, let's substitute the
offending <RequireAll> and `expr` by using old school RewriteCond
statements.
As RewriteCond does not allow testing for *non*-matches, we simply match
the desired case first and let it pass by marking the RewriteRule as
'[L]' ("last rule, do not process any other matching RewriteRules after
this"), and then have another RewriteRule that matches all other cases
and lets them fail via '[F]' ("fail").
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Tested-by: Lars Schneider <larsxschneider@gmail.com>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To test that extra HTTP headers are passed correctly, t5551 verifies that a fetch succeeds when two required headers are passed, and that the fetch does not succeed when those headers are not passed. However, this test would also succeed if the configuration required only one header. As Apache's configuration is notoriously tricky (this developer frequently requires StackOverflow's help to understand Apache's documentation), especially when still supporting the 2.2 line, let's just really make sure that the test verifies what we want it to verify. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Reviewed-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
Due to the way that the git-submodule code works, it clears all local git environment variables before entering submodules. This is normally a good thing since we want to clear settings such as GIT_WORKTREE and other variables which would affect the operation of submodule commands. However, GIT_CONFIG_PARAMETERS is special, and we actually do want to preserve these settings. However, we do not want to preserve all configuration as many things should be left specific to the parent project. Add a git submodule--helper function, sanitize-config, which shall be used to sanitize GIT_CONFIG_PARAMETERS, removing all key/value pairs except a small subset that are known to be safe and necessary. Replace all the calls to clear_local_git_env with a wrapped function that filters GIT_CONFIG_PARAMETERS using the new helper and then restores it to the filtered subset after clearing the rest of the environment. Signed-off-by: Jacob Keller <jacob.keller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The "git -c var=value" option stuffs the config value into $GIT_CONFIG_PARAMETERS, so that sub-processes can see it. When the config is later read via git_config() or similar, we parse it back out of that variable. The parsing end is a little bit picky; it assumes that each entry was generated with sq_quote_buf(), and that there is no extraneous whitespace. On the generating end, we are careful to append to an existing $GIT_CONFIG_PARAMETERS variable if it exists. However, our test for "should we add a space separator" is too liberal: it will add one even if the environment variable exists but is empty. As a result, you might end up with: GIT_CONFIG_PARAMETERS=" 'core.foo=bar'" which the parser will choke on. This was hard to trigger in older versions of git, since we only set the variable when we had something to put into it (though you could certainly trigger it manually). But since 14111fc (git: submodule honor -c credential.* from command line, 2016-02-29), the submodule code will unconditionally put the $GIT_CONFIG_PARAMETERS variable into the environment of any operation in the submodule, whether it is empty or not. So any of those operations which themselves use "git -c" will generate the unparseable value and fail. We can easily fix it by catching this case on the generating side. While we're adding a test, let's also check that multiple layers of "git -c" work, which was previously not tested at all. Reported-by: Shin Fan <shinfan@google.com> Signed-off-by: Jeff King <peff@peff.net> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Tested-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Commit 14111fc (git: submodule honor -c credential.* from command line, 2016-02-29) accidentally wrote $HTTP_URL. It happened to work because we ended up with "credential..helper", which we treat the same as "credential.helper", applying it to all URLs. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Right now we test only the cloning case, but there are other interesting cases (e.g., fetching). Let's pull the setup bits into their own test, which will make things flow more logically once we start adding more tests which use the setup. Let's also introduce some whitespace to the clone-test to split the two parts: making sure it fails without our cmdline config, and that it succeeds with it. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Commit 14111fc (git: submodule honor -c credential.* from command line, 2016-02-29) taught git-submodule.sh to save the sanitized value of $GIT_CONFIG_PARAMETERS when clearing the environment for a submodule. However, it failed to export the result, meaning that it had no effect for any sub-programs. We didn't catch this in our initial tests because we checked only the "clone" case, which does not go through the shell script at all. Provoking "git submodule update" to do a fetch demonstrates the bug. Noticed-by: Lars Schneider <larsxschneider@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
These functions should be used by any code which spawns a submodule process, which may happen in submodule.c (e.g., for spawning fetch). Let's move them there and make them public so that submodule--helper can continue to use them. Since they're now public, let's also provide a basic overview of their intended use. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Before 14111fc (git: submodule honor -c credential.* from command line, 2016-02-29), it was sufficient for code which spawned a process in a submodule to just set the child process's "env" field to "local_repo_env" to clear the environment of any repo-specific variables. That commit introduced a more complicated procedure, in which we clear most variables but allow through sanitized config. For C code, we used that procedure only for cloning, but not for any of the programs spawned by submodule.c. As a result, things like "git fetch --recurse-submodules" behave differently than "git clone --recursive"; the former will not pass through the sanitized config. We can fix this by using prepare_submodule_repo_env() everywhere in submodule.c. Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
The point of having a whitelist of command-line config
options to pass to submodules was two-fold:
1. It prevented obvious nonsense like using core.worktree
for multiple repos.
2. It could prevent surprise when the user did not mean
for the options to leak to the submodules (e.g.,
http.sslverify=false).
For case 1, the answer is mostly "if it hurts, don't do
that". For case 2, we can note that any such example has a
matching inverted surprise (e.g., a user who meant
http.sslverify=true to apply everywhere, but it didn't).
So this whitelist is probably not giving us any benefit, and
is already creating a hassle as people propose things to put
on it. Let's just drop it entirely.
Note that we still need to keep a special code path for
"prepare the submodule environment", because we still have
to take care to pass through $GIT_CONFIG_PARAMETERS (and
block the rest of the repo-specific environment variables).
We can do this easily from within the submodule shell
script, which lets us drop the submodule--helper option
entirely (and it's OK to do so because as a "--" program, it
is entirely a private implementation detail).
Signed-off-by: Jeff King <peff@peff.net>
Signed-off-by: Junio C Hamano <gitster@pobox.com>
Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
* jk/submodule-c-credential: submodule: stop sanitizing config options submodule: use prepare_submodule_repo_env consistently submodule--helper: move config-sanitizing to submodule.c submodule: export sanitized GIT_CONFIG_PARAMETERS t5550: break submodule config test into multiple sub-tests t5550: fix typo in $HTTPD_URL git_config_push_parameter: handle empty GIT_CONFIG_PARAMETERS git: submodule honor -c credential.* from command line quote: implement sq_quotef() submodule: fix segmentation fault in submodule--helper clone submodule: fix submodule--helper clone usage submodule: check argc count for git submodule--helper clone submodule: don't pass empty string arguments to submodule--helper clone Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
To support this developer's use case of allowing build agents token-based access to private repositories, we introduced the http.extraheader feature, allowing extra HTTP headers to be sent along with every HTTP request. This patch verifies that we can configure these extra HTTP headers via the command-line for use with `git submodule update`, too. Example: git -c http.extraheader="Secret: Sauce" submodule update --init Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
Update tests for "http.extraHeaders=<header>" to be portable back to Apache 2.2 (the original depended on <RequireAll/> which is a more recent feature). * js/http-custom-headers: submodule: ensure that -c http.extraheader is heeded t5551: make the test for extra HTTP headers more robust tests: adjust the configuration for Apache 2.2 Rebased-and-signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
A recent fix by Stefan Beller forces `git submodule` to use absolute paths all around. This, however, breaks our tests because all of a sudden, a relative path that was just barely within the maximal path size now extends it as an absolute path. A brief test on this developer's Windows 10 showed, though, that the claim that "SetCurrentDirectoryW doesn't support long paths" does not hold up to reality: simply lifting the limitation still works, and even better: it lets t7413 pass (and it does not pass with Stefan's patch). Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de>
This test was added to verify the behaviour of merge when a merge server is spawned. Because file handles are inherited by child processes, the index.lock is also inherited and - on win32 - can't be released until the child has stopped. Signed-off-by: Ben Wijen <ben@wijen.net>
When testing a merge driver which spawns a merge server (for future merges)
I got the following error:
Rename from 'xxx/.git/index.lock' to 'xxx/.git/index' failed. Should I try again? (y/n)
Only after I stop the merge server the lock is released.
This is caused by windows handle inheritance.
Starting childs with bInheritHandles==FALSE does not work,
because no file handles would be inherited,
not even the hStdXxx handles in STARTUPINFO.
Opening every file with O_NOINHERIT does not work,
Since it is used by git-upload-pack for example,
which expects inherited handles.
This leaves us with only creating temp files with the O_NOINHERIT flag.
Which (currently) only used by lock_file which is exactly what we want.
Signed-off-by: Ben Wijen <ben@wijen.net>
Prevent child processes from inheriting a handle to index.lock
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
(invalid)