aboutsummaryrefslogtreecommitdiffstats
path: root/git-gui
diff options
context:
space:
mode:
Diffstat (limited to 'git-gui')
0 files changed, 0 insertions, 0 deletions
generated by cgit v1.2.3 (git 2.39.1) at 2025-12-27 11:21:17 +0000
y: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-02-22http: allow custom index-pack argsJonathan Tan3-13/+18 Currently, when fetching, packfiles referenced by URIs are run through index-pack without any arguments other than --stdin and --keep, no matter what arguments are used for the packfile that is inline in the fetch response. As a preparation for ensuring that all packs (whether inline or not) use the same index-pack arguments, teach the http subsystem to allow custom index-pack arguments. http-fetch has been updated to use the new API. For now, it passes --keep alone instead of --keep with a process ID, but this is only temporary because http-fetch itself will be taught to accept index-pack parameters (instead of using a hardcoded constant) in a subsequent commit. Signed-off-by: Jonathan Tan <jonathantanmy@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-15The third batchJunio C Hamano1-0/+30 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-15The second batchJunio C Hamano1-0/+29 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-14ci/install-depends: attempt to fix "brew cask" stuffJunio C Hamano1-4/+4 We run "git pull" against "$cask_repo"; clarify that we are expecting not to have any of our own modifications and running "git pull" to merely update, by passing "--ff-only" on the command line. Also, the "brew cask install" command line triggers an error message that says: Error: Calling brew cask install is disabled! Use brew install [--cask] instead. In addition, "brew install caskroom/cask/perforce" step triggers an error that says: Error: caskroom/cask was moved. Tap homebrew/cask instead. Attempt to see if blindly following the suggestion in these error messages gets us into a better shape. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-11Documentation/git-clone.txt: document race with --localTaylor Blau1-0/+4 When running 'git clone --local', the operation may fail if another process is modifying the source repository. Document that this race condition is known to hopefully help anyone who may run into it. Suggested-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-11gettext.c: remove/reword a mostly-useless commentÆvar Arnfjörð Bjarmason1-79/+15 Mostly remove the comment I added 5e9637c6297 (i18n: add infrastructure for translating Git with gettext, 2011-11-18). Since then we had a fix in 9c0495d23e6 (gettext.c: detect the vsnprintf bug at runtime, 2013-12-01) so we're not running with the "set back to C locale" hack on any modern system. So having more than 1/4 of the file taken up by a digression about a glibc bug that mostly doesn't happen to anyone anymore is just a needless distraction. Shorten the comment to make a brief mention of the bug, and where to find more info by looking at the git history for this now-removed comment. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-11Makefile: remove a warning about old GETTEXT_POISON flagÆvar Arnfjörð Bjarmason1-3/+0 Remove a migratory warning I added in 6cdccfce1e0 (i18n: make GETTEXT_POISON a runtime option, 2018-11-08) to give anyone using that option in their builds a heads-up about the change from compile-time to runtime introduced in that commit. It's been more than 2 years since then, anyone who ran into this is likely to have made a change as a result, so removing this is long overdue. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-11docs: rephrase and clarify the git status --short formatbrian m. carlson1-8/+20 The table describing the porcelain format in git-status(1) is helpful, but it's not completely clear what the three sections mean, even to some contributors. As a result, users are unable to find how to detect common cases like merge conflicts programmatically. Let's improve this situation by rephrasing to be more explicit about what each of the sections in the table means, to tell users in plain language which cases are occurring, and to describe what "unmerged" means. Signed-off-by: brian m. carlson <sandals@crustytoothpaste.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-09doc: remove "directory cache" from man pagesUtku Gultopu2-6/+4 "directory cache" (or "directory cache index", "cache") are obsolete terms which have been superseded by "index". Keeping them in the documentation may be a source of confusion. This commit replaces them with the current term, "index", on man pages. Signed-off-by: Utku Gultopu <ugultopu@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-09t5516: loosen "not our ref" error checkJeff King1-1/+3 Commit 014ade7484 (upload-pack: send ERR packet for non-tip objects, 2019-04-13) added a test that greps the output of a failed fetch to make sure that upload-pack sent us the ERR packet we expected. But checking this is racy; despite the argument in that commit, the client may still be sending a "done" line after the server exits, causing it to die() on a failed write() and never see the ERR packet at all. This fails quite rarely on Linux, but more often on macOS. However, it can be triggered reliably with: diff --git a/fetch-pack.c b/fetch-pack.c index 876f90c759..cf40de9092 100644 --- a/fetch-pack.c +++ b/fetch-pack.c @@ -489,6 +489,7 @@ static int find_common(struct fetch_negotiator *negotiator, done: trace2_region_leave("fetch-pack", "negotiation_v0_v1", the_repository); if (!got_ready || !no_done) { + sleep(1); packet_buf_write(&req_buf, "done\n"); send_request(args, fd[1], &req_buf); } This is a real user-visible race that it would be nice to fix, but it's tricky to do so: the client would have to speculatively try to read an ERR packet after hitting a write() error. And at least for this error, it's specific to v0 (since v2 does not enforce reachability at all). So let's loosen the test to avoid annoying racy failures. If we eventually do the read-after-failed-write thing, we can tighten it. And if not, v0 will grow increasingly obsolete as servers support v2, so the utility of this test will decrease over time anyway. Note that we can still check stderr to make sure upload-pack bailed for the reason we expected. It writes a similar message to stderr, and because the server side is just another process connected by pipes, we'll reliably see it. This would not be the case for git://, or for ssh servers that do not relay stderr (e.g., GitHub's custom endpoint does not). Helped-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-09t4129: fix setfacl-related permissions failureAdam Dinwoodie1-1/+1 When running this test in Cygwin, it's necessary to remove the inherited access control lists from the Git working directory in order for later permissions tests to work as expected. As such, fix an error in the test script so that the ACLs are set for the working directory, not a nonexistent subdirectory. Signed-off-by: Adam Dinwoodie <adam@dinwoodie.org> Reviewed-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-07git-send-email.txt: mention less secure app access with GmailVasyl Vavrychuk1-1/+5 Google may have changed Gmail security and now less secure app access needs to be explicitly enabled if two-factor authentication is not in place, otherwise send-email fails with: 5.7.8 Username and Password not accepted. Learn more at 5.7.8 https://support.google.com/mail/?p=BadCredentials Document steps required to make this work. Signed-off-by: Vasyl Vavrychuk <vvavrychuk@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> [dl: Clean up commit message and incorporate suggestions into patch.] Signed-off-by: Denton Liu <liu.denton@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-07for-each-repo: do nothing on empty configDerrick Stolee2-0/+13 'git for-each-repo --config=X' should return success without calling any subcommands when the config key 'X' has no value. The current implementation instead segfaults. A user could run into this issue if they used 'git maintenance start' to initialize their cron schedule using 'git for-each-repo --config=maintenance.repo ...' but then using 'git maintenance unregister' to remove the config option. (Note: 'git maintenance stop' would remove the config _and_ remove the cron schedule.) Add a simple test to ensure this works. Use 'git help --no-such-option' as the potential subcommand to ensure that we will hit a failure if the subcommand is ever run. Reported-by: Andreas Bühmann <dev@uuml.de> Helped-by: Eric Sunshine <sunshine@sunshineco.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-07SubmittingPatches: tighten wording on "sign-off" procedureJunio C Hamano1-1/+1 The text says "if you can certify DCO then you add a Signed-off-by trailer". But it does not say anything about people who cannot or do not want to certify. A natural reading may be that if you do not certify, you must not add the trailer, but it shouldn't hurt to be overly explicit. Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-06The first batch in 2.31 cycleJunio C Hamano3-2/+34 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-06mergetool--lib: fix '--tool-help' to correctly show available toolsPhilippe Blain2-2/+15 Commit 83bbf9b92e (mergetool--lib: improve support for vimdiff-style tool variants, 2020-07-29) introduced a regression in the output of `git mergetool --tool-help` and `git difftool --tool-help` [1]. In function 'show_tool_names' in git-mergetool--lib.sh, we loop over the supported mergetools and their variants and accumulate them in the variable 'variants', separating them with a literal '\n'. The code then uses 'echo $variants' to turn these '\n' into newlines, but this behaviour is not portable, it just happens to work in some shells, like dash(1)'s 'echo' builtin. For shells in which 'echo' does not turn '\n' into newlines, the end result is that the only tools that are shown are the existing variants (except the last variant alphabetically), since the variants are separated by actual newlines in '$variants' because of the several 'echo' calls in mergetools/{bc,vimdiff}::list_tool_variants. Fix this bug by embedding an actual line feed into `variants` in show_tool_names(). While at it, replace `sort | uniq` by `sort -u`. To prevent future regressions, add a simple test that checks that a few known tools are correctly shown (let's avoid counting the total number of tools to lessen the maintenance burden when new tools are added or if '--tool-help' learns additional logic, like hiding tools depending on the current platform). [1] https://lore.kernel.org/git/CADtb9DyozjgAsdFYL8fFBEWmq7iz4=prZYVUdH9W-J5CKVS4OA@mail.gmail.com/ Reported-by: Philippe Blain <levraiphilippeblain@gmail.com> Based-on-patch-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-06t4129: don't fail if setgid is set in the test directoryMatheus Tavares1-2/+7 The last test of t4129 creates a directory and expects its setgid bit (g+s) to be off. But this makes the test fail when the parent directory has the bit set, as setgid's state is inherited by newly created subdirectories. One way to solve this problem is to allow the presence of this bit when comparing the return of `test_modebits` with the expected value. But then we may have the same problem in the future when other tests start using `test_modebits` on directories (currently t4129 is the only one) and forget about setgid. Instead, let's make the helper function more robust with respect to the state of the setgid bit in the test directory by removing this bit from the returning value. There should be no problem with existing callers as no one currently expects this bit to be on. Note that the sticky bit (+t) and the setuid bit (u+s) are not inherited, so we don't have to worry about those. Reported-by: Kevin Daudt <me@ikke.info> Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-06builtin/*: update usage formatZheNing Hu7-61/+61 According to the guidelines in parse-options.h, we should not end in a full stop or start with a capital letter. Fix old error and usage messages to match this expectation. Signed-off-by: ZheNing Hu <adlternative@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-06parse-options: format argh like error messagesJunio C Hamano1-3/+3 "Keep it homogeneous across the repository" is in general a guideline that can be used to converge to a good practice, but we can be a bit more prescriptive in this case. Just like the messages we give die(_("...")) are formatted without the final full stop and without the initial capitalization, most of the argument help text are already formatted that way, and we want to encourage that as the house style. Noticed-by: ZheNing Hu <adlternative@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: ZheNing Hu <adlternative@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-06p7519: allow running without watchman prereqTaylor Blau1-1/+6 p7519 measures the performance of the fsmonitor code. To do this, it uses the installed copy of Watchman. If Watchman isn't installed, a noop integration script is installed in its place. When in the latter mode, it is expected that the script should not write a "last update token": in fact, it doesn't write anything at all since the script is blank. Commit 33226af42b (t/perf/fsmonitor: improve error message if typoing hook name, 2020-10-26) made sure that running 'git update-index --fsmonitor' did not write anything to stderr, but this is not the case when using the empty Watchman script, since Git will complain that: $ which watchman watchman not found $ cat .git/hooks/fsmonitor-empty $ git -c core.fsmonitor=.git/hooks/fsmonitor-empty update-index --fsmonitor warning: Empty last update token. Prior to 33226af42b, the output wasn't checked at all, which allowed this noop mode to work. But, 33226af42b breaks p7519 when running it without a 'watchman(1)' on your system. Handle this by only checking that the stderr is empty only when running with a real watchman executable. Otherwise, assert that the error message is the expected one when running in the noop mode. Signed-off-by: Taylor Blau <me@ttaylorr.com> Acked-by: Nipunn Koorapati <nipunn@dropbox.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-05maintenance: use Windows scheduled tasksDerrick Stolee3-1/+226 Git's background maintenance uses cron by default, but this is not available on Windows. Instead, integrate with Task Scheduler. Tasks can be scheduled using the 'schtasks' command. There are several command-line options that can allow for some advanced scheduling, but unfortunately these seem to all require authenticating using a password. Instead, use the "/xml" option to pass an XML file that contains the configuration for the necessary schedule. These XML files are based on some that I exported after constructing a schedule in the Task Scheduler GUI. These options only run background maintenance when the user is logged in, and more fields are populated with the current username and SID at run-time by 'schtasks'. Since the GIT_TEST_MAINT_SCHEDULER environment variable allows us to specify 'schtasks' as the scheduler, we can test the Windows-specific logic on other platforms. Thus, add a check that the XML file written by Git is valid when xmllint exists on the system. Since we use a temporary file for the XML files sent to 'schtasks', we prefix the random characters with the frequency so it is easier to examine the proper file during tests. Instead of an exact match on the 'args' file, we 'grep' for the arguments other than the filename. There is a deficiency in the current design. Windows has two kinds of applications: GUI applications that start by "winmain()" and console applications that start by "main()". Console applications are attached to a new Console window if they are not already associated with a GUI application. This means that every hour the scheudled task launches a command window for the scheduled tasks. Not only is this visually obtrusive, but it also takes focus from whatever else the user is doing! A simple fix would be to insert a GUI application that acts as a shim between the scheduled task and Git. This is currently possible in Git for Windows by setting the <Command> tag equal to C:\Program Files\Git\git-bash.exe with options "--hide --no-needs-console --command=cmd\git.exe" followed by the arguments currently used. Since git-bash.exe is not included in Windows builds of core Git, I chose to leave out this feature. My plan is to submit a small patch to Git for Windows that converts the use of git.exe with this use of git-bash.exe in the short term. In the long term, we can consider creating this GUI shim application within core Git, perhaps in contrib/. Co-authored-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-05maintenance: use launchctl on macOSDerrick Stolee3-1/+286 The existing mechanism for scheduling background maintenance is done through cron. The 'crontab -e' command allows updating the schedule while cron itself runs those commands. While this is technically supported by macOS, it has some significant deficiencies: 1. Every run of 'crontab -e' must request elevated privileges through the user interface. When running 'git maintenance start' from the Terminal app, it presents a dialog box saying "Terminal.app would like to administer your computer. Administration can include modifying passwords, networking, and system settings." This is more alarming than what we are hoping to achieve. If this alert had some information about how "git" is trying to run "crontab" then we would have some reason to believe that this dialog might be fine. However, it also doesn't help that some scenarios just leave Git waiting for a response without presenting anything to the user. I experienced this when executing the command from a Bash terminal view inside Visual Studio Code. 2. While cron initializes a user environment enough for "git config --global --show-origin" to show the correct config file information, it does not set up the environment enough for Git Credential Manager Core to load credentials during a 'prefetch' task. My prefetches against private repositories required re-authenticating through UI pop-ups in a way that should not be required. The solution is to switch from cron to the Apple-recommended [1] 'launchd' tool. [1] https://developer.apple.com/library/archive/documentation/MacOSX/Conceptual/BPSystemStartup/Chapters/ScheduledJobs.html The basics of this tool is that we need to create XML-formatted "plist" files inside "~/Library/LaunchAgents/" and then use the 'launchctl' tool to make launchd aware of them. The plist files include all of the scheduling information, along with the command-line arguments split across an array of <string> tags. For example, here is my plist file for the weekly scheduled tasks: <?xml version="1.0" encoding="UTF-8"?> <!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd"> <plist version="1.0"><dict> <key>Label</key><string>org.git-scm.git.weekly</string> <key>ProgramArguments</key> <array> <string>/usr/local/libexec/git-core/git</string> <string>--exec-path=/usr/local/libexec/git-core</string> <string>for-each-repo</string> <string>--config=maintenance.repo</string> <string>maintenance</string> <string>run</string> <string>--schedule=weekly</string> </array> <key>StartCalendarInterval</key> <array> <dict> <key>Day</key><integer>0</integer> <key>Hour</key><integer>0</integer> <key>Minute</key><integer>0</integer> </dict> </array> </dict> </plist> The schedules for the daily and hourly tasks are more complicated since we need to use an array for the StartCalendarInterval with an entry for each of the six days other than the 0th day (to avoid colliding with the weekly task), and each of the 23 hours other than the 0th hour (to avoid colliding with the daily task). The "Label" value is currently filled with "org.git-scm.git.X" where X is the frequency. We need a different plist file for each frequency. The launchctl command needs to be aligned with a user id in order to initialize the command environment. This must be done using the 'launchctl bootstrap' subcommand. This subcommand is new as of macOS 10.11, which was released in September 2015. Before that release the 'launchctl load' subcommand was recommended. The best source of information on this transition I have seen is available at [2]. The current design does not preclude a future version that detects the available fatures of 'launchctl' to use the older commands. However, it is best to rely on the newest version since Apple might completely remove the deprecated version on short notice. [2] https://babodee.wordpress.com/2016/04/09/launchctl-2-0-syntax/ To remove a schedule, we must run 'launchctl bootout' with a valid plist file. We also need to 'bootout' a task before the 'bootstrap' subcommand will succeed, if such a task already exists. The need for a user id requires us to run 'id -u' which works on POSIX systems but not Windows. Further, the need for fully-qualitifed path names including $HOME behaves differently in the Git internals and the external test suite. The $HOME variable starts with "C:\..." instead of the "/c/..." that is provided by Git in these subcommands. The test therefore has a prerequisite that we are not on Windows. The cross- platform logic still allows us to test the macOS logic on a Linux machine. We can verify the commands that were run by 'git maintenance start' and 'git maintenance stop' by injecting a script that writes the command-line arguments into GIT_TEST_MAINT_SCHEDULER. An earlier version of this patch accidentally had an opening "<dict>" tag when it should have had a closing "</dict>" tag. This was caught during manual testing with actual 'launchctl' commands, but we do not want to update developers' tasks when running tests. It appears that macOS includes the "xmllint" tool which can verify the XML format. This is useful for any system that might contain the tool, so use it whenever it is available. We strive to make these tests work on all platforms, but Windows caused some headaches. In particular, the value of getuid() called by the C code is not guaranteed to be the same as `$(id -u)` invoked by a test. This is because `git.exe` is a native Windows program, whereas the utility programs run by the test script mostly utilize the MSYS2 runtime, which emulates a POSIX-like environment. Since the purpose of the test is to check that the input to the hook is well-formed, the actual user ID is immaterial, thus we can work around the problem by making the the test UID-agnostic. Another subtle issue is the $HOME environment variable being a Windows-style path instead of a Unix-style path. We can be more flexible here instead of expecting exact path matches. Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Co-authored-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Eric Sunshine <sunshine@sunshineco.com> Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04completion: add proper public __git_completeFelipe Contreras2-8/+46 When __git_complete was introduced, it was meant to be temporarily, while a proper guideline for public shell functions was established (tentatively _GIT_complete), but since that never happened, people in the wild started to use __git_complete, even though it was marked as not public. Eight years is more than enough wait, let's mark this function as public, and make it a bit more user-friendly. So that instead of doing: __git_complete gk __gitk_main The user can do: __git_complete gk gitk And instead of: __git_complete gf _git_fetch Do: __git_complete gf git_fetch Backwards compatibility is maintained. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04test: completion: add tests for __git_completeFelipe Contreras1-0/+8 Even though the function was marked as not public, it's already used in the wild. We should at least test basic functionality. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04completion: bash: improve function detectionFelipe Contreras1-1/+1 1. We should quote the argument 2. We don't need two redirections 3. A safeguard for arguments (-a) would be good Suggested-by: René Scharfe <l.s.r@web.de> Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04completion: bash: add __git_have_func helperFelipe Contreras1-3/+7 This makes the code more readable, and also will help when new code wants to do similar checks. Signed-off-by: Felipe Contreras <felipe.contreras@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04rebase: verify commit parameterRené Scharfe1-1/+3 If the user specifies a base commit to switch to, check if it actually references a commit right away to avoid getting confused later on when it turns out to be an invalid object. Reported-by: LeSeulArtichaut <leseulartichaut@gmail.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04revision: trace topo-walk statisticsDerrick Stolee1-0/+31 We trace statistics about the effectiveness of changed-path Bloom filters since 42e50e78 (revision.c: add trace2 stats around Bloom filter usage, 2020-04-06). Add similar tracing for the topo-walk algorithm that uses generation numbers to limit the walk size. This information can help investigate and describe benefits to heuristics and other changes. The information that is printed is in JSON format and can be formatted nicely to present as follows: { "count_explort_walked":2603, "count_indegree_walked":2603, "count_topo_walked":473 } Each of these values count the number of commits are visited by each of the three "stages" of the topo-walk as detailed in b4542418 (revision.c: generation-based topo-order algorithm, 2018-11-01). Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04hash-lookup: rename from sha1-lookupMartin Ågren14-25/+25 Change all remnants of "sha1" in hash-lookup.c and .h and rename them to reflect that we're not just able to handle SHA-1 these days. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04sha1-lookup: rename `sha1_pos()` as `hash_pos()`Martin Ågren8-15/+15 Rename this function to reflect that we're not just able to handle SHA-1 these days. There are a few instances of "sha1" left in sha1-lookup.[ch] after this, but those will be addressed in the next commit. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04object-file.c: rename from sha1-file.cMartin Ågren4-7/+7 Drop the last remnant of "sha1" in this file and rename it to reflect that we're not just able to handle SHA-1 these days. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04object-name.c: rename from sha1-name.cMartin Ågren4-11/+11 Generalize the last remnants of "sha" and "sha1" in this file and rename it to reflect that we're not just able to handle SHA-1 these days. We need to update one test to check for an updated error string. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Reviewed-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04pack-format.txt: document sizes at start of delta dataMartin Ågren1-1/+16 We document the delta data as a set of instructions, but forget to document the two sizes that precede those instructions: the size of the base object and the size of the object to be reconstructed. Fix this omission. Rather than cramming all the details about the encoding into the running text, introduce a separate section detailing our "size encoding" and refer to it. Reported-by: Ross Light <ross@zombiezen.com> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04t6016: move to lib-log-graph.sh frameworkAntonio Russo1-187/+167 t6016 manually reconstructs git log --graph output by using the reported commit hashes from `git rev-parse`. Each tag is converted into an environment variable manually, and then `echo`-ed to an expected output file, which is in turn compared to the actual output. The expected output is difficult to read and write, because, e.g., each line of output must be prefaced with echo, quoted, and properly escaped. Additionally, the test is sensitive to trailing whitespace, which may potentially be removed from graph log output in the future. In order to reduce duplication, ease troubleshooting of failed tests by improving readability, and ease the addition of more tests to this file, port the operations to `lib-log-graph.sh`, which is already used in several other tests, e.g., t4215. Give all merges a simple commit message, and use a common `check_graph` macro taking a heredoc of the expected output which does not required extensive escaping. Signed-off-by: Antonio Russo <aerusso@aerusso.net> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04t1300: don't needlessly work with `core.foo` configsMartin Ågren1-30/+30 We use various made-up config keys in the "core" section for no real reason. Change them to work in the "section" section instead and be careful to also change "cores" to "sections". Make sure to also catch "Core", "CoReS" and similar. There are a few instances that actually want to work with a real "core" config such as `core.bare` or `core.editor`. After this, it's clearer that they work with "core" for a reason. Reported-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04t1300: remove duplicate test for `--file no-such-file`Martin Ågren1-6/+2 We test that we can handle `git config --file symlink` and the error case of `git config --file symlink-to-missing-file`. For good measure, we also throw in a test to check that we correctly handle referencing a missing regular file. But we have such a test earlier in this script. They both check that we fail to use `--file no-such-file --list`. Drop the latter of these and keep the one that is in the general area where we test `--file` and `GIT_CONFIG`. The one we're dropping also checks that we can't even get a specific key from the missing file -- let's make sure we check that in the test we keep. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04t1300: remove duplicate test for `--file ../foo`Martin Ågren1-4/+0 We have two tests for checking that we can handle `git config --file ../other-config ...`. One, using `--file`, was introduced in 65807ee697 ("builtin-config: Fix crash when using "-f <relative path>" from non-root dir", 2010-01-26), then another, using `GIT_CONFIG`, came about in 270a34438b ("config: stop using config_exclusive_filename", 2012-02-16). The latter of these was then converted to use `--file` in f7e8714101 ("t: prefer "git config --file" to GIT_CONFIG", 2014-03-20). Both where then simplified in a5db0b77b9 ("t1300: extract and use test_cmp_config()", 2018-10-21). These two tests differ slightly in the order of the options used, but other than that, they are identical. Let's drop one. As noted in f7e8714101, we do still have a test for `GIT_CONFIG` and it shares the implementation with `--file`. Signed-off-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04gitmodules.txt: fix 'GIT_WORK_TREE' variable namePhilippe Blain1-15/+15 'gitmodules.txt' is a guide about the '.gitmodules' file that describes submodule properties, and that file must exist at the root of the repository. This was clarified in e5b5c1d2cf (Document clarification: gitmodules, gitattributes, 2008-08-31). However, that commit mistakenly uses the non-existing environment variable 'GIT_WORK_DIR' to refer to the root of the repository. Fix that by using the correct variable, 'GIT_WORK_TREE'. Take the opportunity to modernize and improve the formatting of that guide, and fix a grammar mistake. Signed-off-by: Philippe Blain <levraiphilippeblain@gmail.com> Acked-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2021-01-04doc: fix some typosThomas Ackermann6-7/+7 Signed-off-by: Thomas Ackermann <th.acker@arcor.de> Acked-by: Martin Ågren <martin.agren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-12-27Git 2.30v2.30.0Junio C Hamano2-12/+9 Signed-off-by: Junio C Hamano <gitster@pobox.com> 2020-12-27l10n: zh_CN: for git v2.30.0 l10n round 1 and 2Jiang Xin1-2475/+2588 Translate 71 new messages (5037t0f0u) for git 2.30.0. Reviewed-by: 依云 <lilydjwg@gmail.com> Signed-off-by: Jiang Xin <worldhello.net@gmail.com> 2020-12-25l10n: zh_TW.po: v2.30.0 round 2 (1 untranslated)pan934121-2744/+2602 Signed-off-by: pan93412 <pan93412@gmail.com> 2020-12-23l10n: pl.po: add translation and set team leaderArusekk2-8992/+22386 Signed-off-by: Arusekk <arek_koz@o2.pl> 2020-12-23Git 2.30-rc2v2.30.0-rc2Junio C Hamano2-1/+6 Signed-off-by: Junio C Hamano <gitster@pobox.com>