summaryrefslogtreecommitdiff
path: root/builtin
AgeCommit message (Collapse)AuthorFilesLines
2021-10-15pkt-line.[ch]: remove unused packet_read_line_buf()Libravatar Ævar Arnfjörð Bjarmason1-2/+2
This function was added in 4981fe750b1 (pkt-line: share buffer/descriptor reading implementation, 2013-02-23), but in 01f9ec64c8a (Use packet_reader instead of packet_read_line, 2018-12-29) the code that was using it was removed. Since it's being removed we can in turn remove the "src" and "src_len" arguments to packet_read(), all the remaining users just passed a NULL/NULL pair to it. That function is only a thin wrapper for packet_read_with_status() which still needs those arguments, but for the thin packet_read() convenience wrapper we can do away with it for now. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-10-12Merge branch 'da/difftool-dir-diff-symlink-fix' into maintLibravatar Junio C Hamano1-0/+2
"git difftool --dir-diff" mishandled symbolic links. * da/difftool-dir-diff-symlink-fix: difftool: fix symlink-file writing in dir-diff mode
2021-10-12Merge branch 'jk/clone-unborn-head-in-bare' into maintLibravatar Junio C Hamano1-16/+17
"git clone" from a repository whose HEAD is unborn into a bare repository didn't follow the branch name the other side used, which is corrected. * jk/clone-unborn-head-in-bare: clone: handle unborn branch in bare repos
2021-10-12Merge branch 'en/stash-df-fix' into maintLibravatar Junio C Hamano1-3/+17
"git stash", where the tentative change involves changing a directory to a file (or vice versa), was confused, which has been corrected. * en/stash-df-fix: stash: restore untracked files AFTER restoring tracked files stash: avoid feeding directories to update-index t3903: document a pair of directory/file bugs
2021-10-12Merge branch 'en/am-abort-fix' into maintLibravatar Junio C Hamano1-1/+2
When "git am --abort" fails to abort correctly, it still exited with exit status of 0, which has been corrected. * en/am-abort-fix: am: fix incorrect exit status on am fail to abort t4151: add a few am --abort tests git-am.txt: clarify --abort behavior
2021-10-12Merge branch 'ps/update-ref-batch-flush' into maintLibravatar Junio C Hamano1-4/+10
"git update-ref --stdin" failed to flush its output as needed, which potentially led the conversation to a deadlock. * ps/update-ref-batch-flush: t1400: avoid SIGPIPE race condition on fifo update-ref: fix streaming of status updates
2021-10-12Merge branch 'tb/pack-finalize-ordering' into maintLibravatar Junio C Hamano3-30/+35
The order in which various files that make up a single (conceptual) packfile has been reevaluated and straightened up. This matters in correctness, as an incomplete set of files must not be shown to a running Git. * tb/pack-finalize-ordering: pack-objects: rename .idx files into place after .bitmap files pack-write: split up finish_tmp_packfile() function builtin/index-pack.c: move `.idx` files into place last index-pack: refactor renaming in final() builtin/repack.c: move `.idx` files into place last pack-write.c: rename `.idx` files after `*.rev` pack-write: refactor renaming in finish_tmp_packfile() bulk-checkin.c: store checksum directly pack.h: line-wrap the definition of finish_tmp_packfile()
2021-10-12Merge branch 'so/diff-index-regression-fix' into maintLibravatar Junio C Hamano1-3/+3
Recent "diff -m" changes broke "gitk", which has been corrected. * so/diff-index-regression-fix: diff-index: restore -c/--cc options handling
2021-10-12Merge branch 'tk/fast-export-anonymized-tag-fix' into maintLibravatar Junio C Hamano1-0/+1
The output from "git fast-export", when its anonymization feature is in use, showed an annotated tag incorrectly. * tk/fast-export-anonymized-tag-fix: fast-export: fix anonymized tag using original length
2021-10-12Merge branch 'sg/column-nl' into maintLibravatar Junio C Hamano1-1/+1
The parser for the "--nl" option of "git column" has been corrected. * sg/column-nl: column: fix parsing of the '--nl' option
2021-10-12Merge branch 'rs/branch-allow-deleting-dangling' into maintLibravatar Junio C Hamano1-1/+1
"git branch -D <branch>" used to refuse to remove a broken branch ref that points at a missing commit, which has been corrected. * rs/branch-allow-deleting-dangling: branch: allow deleting dangling branches with --force
2021-10-12Merge branch 'mt/quiet-with-delayed-checkout' into maintLibravatar Junio C Hamano1-1/+1
The delayed checkout code path in "git checkout" etc. were chatty even when --quiet and/or --no-progress options were given. * mt/quiet-with-delayed-checkout: checkout: make delayed checkout respect --quiet and --no-progress
2021-10-12Merge branch 'jk/commit-edit-fixup-fix' into maintLibravatar Junio C Hamano1-2/+3
"git commit --fixup" now works with "--edit" again, after it was broken in v2.32. * jk/commit-edit-fixup-fix: commit: restore --edit when combined with --fixup
2021-10-12Merge branch 'en/pull-conflicting-options' into maintLibravatar Junio C Hamano2-12/+45
"git pull" had various corner cases that were not well thought out around its --rebase backend, e.g. "git pull --ff-only" did not stop but went ahead and rebased when the history on other side is not a descendant of our history. The series tries to fix them up. * en/pull-conflicting-options: pull: fix handling of multiple heads pull: update docs & code for option compatibility with rebasing pull: abort by default when fast-forwarding is not possible pull: make --rebase and --no-rebase override pull.ff=only pull: since --ff-only overrides, handle it first pull: abort if --ff-only is given and fast-forwarding is impossible t7601: add tests of interactions with multiple merge heads and config t7601: test interaction of merge/rebase/fast-forward flags and options
2021-10-12Merge branch 'jt/push-negotiation-fixes' into maintLibravatar Junio C Hamano2-1/+4
Bugfix for common ancestor negotiation recently introduced in "git push" codepath. * jt/push-negotiation-fixes: fetch: die on invalid --negotiation-tip hash send-pack: fix push nego. when remote has refs send-pack: fix push.negotiate with remote helper
2021-10-12Merge branch 'ab/pack-stdin-packs-fix' into maintLibravatar Junio C Hamano1-3/+20
Input validation of "git pack-objects --stdin-packs" has been corrected. * ab/pack-stdin-packs-fix: pack-objects: fix segfault in --stdin-packs option pack-objects tests: cover blindspots in stdin handling
2021-10-12Merge branch 'jc/prefix-filename-allocates' into maintLibravatar Junio C Hamano1-1/+1
Leakfix. * jc/prefix-filename-allocates: hash-object: prefix_filename() returns allocated memory these days
2021-10-12Merge branch 'rs/show-branch-simplify' into maintLibravatar Junio C Hamano1-10/+5
Code cleanup. * rs/show-branch-simplify: show-branch: simplify rev_is_head()
2021-10-12Merge branch 'ab/gc-log-rephrase' into maintLibravatar Junio C Hamano1-1/+1
A pathname in an advice message has been made cut-and-paste ready. * ab/gc-log-rephrase: gc: remove trailing dot from "gc.log" line
2021-10-12Merge branch 'rs/xopen-reports-open-failures' into maintLibravatar Junio C Hamano11-37/+12
Error diagnostics improvement. * rs/xopen-reports-open-failures: use xopen() to handle fatal open(2) failures xopen: explicitly report creation failures
2021-10-12Merge branch 'js/maintenance-launchctl-fix' into maintLibravatar Junio C Hamano1-21/+70
"git maintenance" scheduler fix for macOS. * js/maintenance-launchctl-fix: maintenance: skip bootout/bootstrap when plist is registered maintenance: create `launchctl` configuration using a lock file
2021-10-12Merge branch 'ab/rebase-fatal-fatal-fix' into maintLibravatar Junio C Hamano1-1/+1
Error message fix. * ab/rebase-fatal-fatal-fix: rebase: emit one "fatal" in "fatal: fatal: <error>"
2021-10-12Merge branch 'ab/ls-remote-packet-trace' into maintLibravatar Junio C Hamano1-0/+2
Debugging aid fix. * ab/ls-remote-packet-trace: ls-remote: set packet_trace_identity(<name>)
2021-10-12Merge branch 'cb/builtin-merge-format-string-fix' into maintLibravatar Junio C Hamano1-3/+5
Code clean-up. * cb/builtin-merge-format-string-fix: builtin/merge: avoid -Wformat-extra-args from ancient Xcode
2021-10-12Merge branch 'en/merge-strategy-docs' into maintLibravatar Junio C Hamano1-1/+1
Documentation updates. * en/merge-strategy-docs: Update error message and code comment merge-strategies.txt: add coverage of the `ort` merge strategy git-rebase.txt: correct out-of-date and misleading text about renames merge-strategies.txt: fix simple capitalization error merge-strategies.txt: avoid giving special preference to patience algorithm merge-strategies.txt: do not imply using copy detection is desired merge-strategies.txt: update wording for the resolve strategy Documentation: edit awkward references to `git merge-recursive` directory-rename-detection.txt: small updates due to merge-ort optimizations git-rebase.txt: correct antiquated claims about --rebase-merges
2021-09-23difftool: fix symlink-file writing in dir-diff modeLibravatar David Aguilar1-0/+2
The difftool dir-diff mode handles symlinks by replacing them with their readlink(2) values. This allows diff tools to see changes to symlinks as if they were regular text diffs with the old and new path values. This is analogous to what "git diff" displays when symlinks change. The temporary diff directories that are created initially contain symlinks because they get checked-out using a temporary index that retains the original symlinks as checked-in to the repository. A bug was introduced when difftool was rewritten in C that made difftool write the readlink(2) contents into the pointed-to file rather than the symlink itself. The write was going through the symlink and writing to its target rather than writing to the symlink path itself. Replace symlinks with raw text files by unlinking the symlink path before writing the readlink(2) content into them. When 18ec800512 (difftool: handle modified symlinks in dir-diff mode, 2017-03-15) added handling for modified symlinks this bug got recorded in the test suite. The tests included the pointed-to symlink target paths. These paths were being reported because difftool was erroneously writing to them, but they should have never been reported nor written. Correct the modified-symlinks test cases by removing the target files from the expected output. Add a test to ensure that symlinks are written with the readlink(2) values and that the target files contain their original content. Reported-by: Alan Blotz <work@blotz.org> Helped-by: Đoàn Trần Công Danh <congdanhqx@gmail.com> Signed-off-by: David Aguilar <davvid@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-20clone: handle unborn branch in bare reposLibravatar Jeff King1-16/+17
When cloning a repository with an unborn HEAD, we'll set the local HEAD to match it only if the local repository is non-bare. This is inconsistent with all other combinations: remote HEAD | local repo | local HEAD ----------------------------------------------- points to commit | non-bare | same as remote points to commit | bare | same as remote unborn | non-bare | same as remote unborn | bare | local default So I don't think this is some clever or subtle behavior, but just a bug in 4f37d45706 (clone: respect remote unborn HEAD, 2021-02-05). And it's easy to see how we ended up there. Before that commit, the code to set up the HEAD for an empty repo was guarded by "if (!option_bare)". That's because the only thing it did was call install_branch_config(), and we don't want to do so for a bare repository (unborn HEAD or not). That commit put the handling of unborn HEADs into the same block, since those also need to call install_branch_config(). But the unborn case has an additional side effect of calling create_symref(), and we want that to happen whether we are bare or not. This patch just pulls all of the "figure out the default branch" code out of the "!option_bare" block. Only the actual config installation is kept there. Note that this does mean we might allocate "ref" and not use it (if the remote is empty but did not advertise an unborn HEAD). But that's not really a big deal since this isn't a hot code path, and it keeps the code simple. The alternative would be handling unborn_head_target separately, but that gets confusing since its memory ownership is tangled up with the "ref" variable. There's just one new test, for the case we're fixing. The other ones in the table are handled elsewhere (the unborn non-bare case just above, and the actually-born cases in t5601, t5606, and t5609, as they do not require v2's "unborn" protocol extension). Signed-off-by: Jeff King <peff@peff.net> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-10am: fix incorrect exit status on am fail to abortLibravatar Elijah Newren1-1/+2
Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-10stash: restore untracked files AFTER restoring tracked filesLibravatar Elijah Newren1-3/+3
If a user deletes a file and places a directory of untracked files there, then stashes all these changes, the untracked directory of files cannot be restored until after the corresponding file in the way is removed. So, restore changes to tracked files before restoring untracked files. There is no counterpart problem to worry about with the user deleting an untracked file and then add a tracked one in its place. Git does not track untracked files, and so will not know the untracked file was deleted, and thus won't be able to stash the removal of that file. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-10stash: avoid feeding directories to update-indexLibravatar Elijah Newren1-0/+14
When a file is removed from the cache, but there is a file of the same name present in the working directory, we would normally treat that file in the working directory as untracked. However, in the case of stash, doing that would prevent a simple 'git stash push', because the untracked file would be in the way of restoring the deleted file. git stash, however, blindly assumes that whatever is in the working directory for a deleted file is wanted and passes that path along to update-index. That causes problems when the working directory contains a directory with the same name as the deleted file. Add some code for this special case that will avoid passing directory names to update-index. Signed-off-by: Elijah Newren <newren@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-09pack-objects: rename .idx files into place after .bitmap filesLibravatar Ævar Arnfjörð Bjarmason1-1/+2
In preceding commits the race of renaming .idx files in place before .rev files and other auxiliary files was fixed in pack-write.c's finish_tmp_packfile(), builtin/repack.c's "struct exts", and builtin/index-pack.c's final(). As noted in the change to pack-write.c we left in place the issue of writing *.bitmap files after the *.idx, let's fix that issue. See 7cc8f971085 (pack-objects: implement bitmap writing, 2013-12-21) for commentary at the time when *.bitmap was implemented about how those files are written out, nothing in that commit contradicts what's being done here. Note that this commit and preceding ones only close any race condition with *.idx files being written before their auxiliary files if we're optimistic about our lack of fsync()-ing in this are not tripping us over. See the thread at [1] for a rabbit hole of various discussions about filesystem races in the face of doing and not doing fsync() (and if doing fsync(), not doing it properly). We may want to fsync the containing directory once after renaming the *.idx file into place, but that is outside the scope of this series. 1. https://lore.kernel.org/git/8735qgkvv1.fsf@evledraar.gmail.com/ Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-09pack-write: split up finish_tmp_packfile() functionLibravatar Ævar Arnfjörð Bjarmason1-2/+5
Split up the finish_tmp_packfile() function and use the split-up version in pack-objects.c in preparation for moving the step of renaming the *.idx file later as part of a function change. Since the only other caller of finish_tmp_packfile() was in bulk-checkin.c, and it won't be needing a change to its *.idx renaming, provide a thin wrapper for the old function as a static function in that file. If other callers end up needing the simpler version it could be moved back to "pack-write.c" and "pack.h". Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-09builtin/index-pack.c: move `.idx` files into place lastLibravatar Taylor Blau1-2/+2
In a similar spirit as preceding patches to `git repack` and `git pack-objects`, fix the identical problem in `git index-pack`. Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-09index-pack: refactor renaming in final()Libravatar Ævar Arnfjörð Bjarmason1-25/+23
Refactor the renaming in final() into a helper function, this is similar in spirit to a preceding refactoring of finish_tmp_packfile() in pack-write.c. Before e37d0b8730b (builtin/index-pack.c: write reverse indexes, 2021-01-25) it probably wasn't worth it to have this sort of helper, due to the differing "else if" case for "pack" files v.s. "idx" files. But since we've got "rev" as well now, let's do the renaming via a helper, this is both a net decrease in lines, and improves the readability, since we can easily see at a glance that the logic for writing these three types of files is exactly the same, aside from the obviously differing cases of "*final_name" being NULL, and "make_read_only_if_same" being different. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-09builtin/repack.c: move `.idx` files into place lastLibravatar Taylor Blau1-1/+1
In a similar spirit as the previous patch, fix the identical problem from `git repack` (which invokes `pack-objects` with a temporary location for output, and then moves the files into their final locations itself). Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-09pack-write: refactor renaming in finish_tmp_packfile()Libravatar Ævar Arnfjörð Bjarmason1-2/+5
Refactor the renaming in finish_tmp_packfile() into a helper function. The callers are now expected to pass a "name_buffer" ending in "pack-OID." instead of the previous "pack-", we then append "pack", "idx" or "rev" to it. By doing the strbuf_setlen() in rename_tmp_packfile() we reuse the buffer and avoid the repeated allocations we'd get if that function had its own temporary "struct strbuf". This approach of reusing the buffer does make the last user in pack-object.c's write_pack_file() slightly awkward, since we needlessly do a strbuf_setlen() before calling strbuf_release() for consistency. In subsequent changes we'll move that bitmap writing code around, so let's not skip the strbuf_setlen() now. The previous strbuf_reset() idiom originated with 5889271114a (finish_tmp_packfile():use strbuf for pathname construction, 2014-03-03), which in turn was a minimal adjustment of pre-strbuf code added in 0e990530ae (finish_tmp_packfile(): a helper function, 2011-10-28). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Taylor Blau <me@ttaylorr.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-07hash-object: prefix_filename() returns allocated memory these daysLibravatar Junio C Hamano1-1/+1
Back when a1be47e4 (hash-object: fix buffer reuse with --path in a subdirectory, 2017-03-20) was written, the prefix_filename() helper used a static piece of memory to the caller, making the caller responsible for copying it, if it wants to keep it across another call to the same function. Two callers of the prefix_filename() in hash-object were made to xstrdup() the value obtained from it. But in the same series, when e4da43b1 (prefix_filename: return newly allocated string, 2017-03-20) changed the rule to gave the caller possession of the memory, we forgot to revert one of the xstrdup() changes, allowing the returned value to leak. Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-07diff-index: restore -c/--cc options handlingLibravatar Sergey Organov1-3/+3
This fixes 19b2517f (diff-merges: move specific diff-index "-m" handling to diff-index, 2021-05-21). That commit disabled handling of all diff for merges options in diff-index on an assumption that they are unused. However, it later appeared that -c and --cc, even though undocumented and not being covered by tests, happen to have had particular effect on diff-index output. Restore original -c/--cc options handling by diff-index. Signed-off-by: Sergey Organov <sorganov@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-03update-ref: fix streaming of status updatesLibravatar Patrick Steinhardt1-4/+10
When executing git-update-ref(1) with the `--stdin` flag, then the user can queue updates and, since e48cf33b61 (update-ref: implement interactive transaction handling, 2020-04-02), interactively drive the transaction's state via a set of transactional verbs. This interactivity is somewhat broken though: while the caller can use these verbs to drive the transaction's state, the status messages which confirm that a verb has been processed is not flushed. The caller may thus be left hanging waiting for the acknowledgement. Fix the bug by flushing stdout after writing the status update. Add a test which catches this bug. Signed-off-by: Patrick Steinhardt <ps@pks.im> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-09-02gc: remove trailing dot from "gc.log" lineLibravatar Ævar Arnfjörð Bjarmason1-1/+1
Remove the trailing dot from the warning we emit about gc.log. It's common for various terminal UX's to allow the user to select "words", and by including the trailing dot a user wanting to select the path to gc.log will need to manually remove the trailing dot. Such a user would also probably need to adjust the path if it e.g. had spaces in it, but this should address this very common case. Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Suggested-by: Jan Judas <snugar.i@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-31fast-export: fix anonymized tag using original lengthLibravatar Tal Kelrich1-0/+1
Commit 7f4075949686 (fast-export: tighten anonymize_mem() interface to handle only strings, 2020-06-23) changed the interface used in anonymizing strings, but failed to update the size of annotated tag messages to match the new anonymized string. As a result, exporting tags having messages longer than 13 characters would create output that couldn't be parsed by fast-import, as the data length indicated was larger than the data output. Reset the message size when anonymizing, and add a tag with a "long" message to the test. Signed-off-by: Tal Kelrich <hasturkun@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-27branch: allow deleting dangling branches with --forceLibravatar René Scharfe1-1/+1
git branch only allows deleting branches that point to valid commits. Skip that check if --force is given, as the caller is indicating with it that they know what they are doing and accept the consequences. This allows deleting dangling branches, which previously had to be reset to a valid start-point using --force first. Reported-by: Ulrich Windl <Ulrich.Windl@rz.uni-regensburg.de> Helped-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Helped-by: Junio C Hamano <gitster@pobox.com> Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-27show-branch: simplify rev_is_head()Libravatar René Scharfe1-10/+5
Only one of the callers of rev_is_head() provides two hashes to compare. Move that check there and convert it to struct object_id. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-26checkout: make delayed checkout respect --quiet and --no-progressLibravatar Matheus Tavares1-1/+1
The 'Filtering contents...' progress report from delayed checkout is displayed even when checkout and clone are invoked with --quiet or --no-progress. Furthermore, it is displayed unconditionally, without first checking whether stdout is a tty. Let's fix these issues and also add some regression tests for the two code paths that currently use delayed checkout: unpack_trees.c:check_updates() and builtin/checkout.c:checkout_worktree(). Signed-off-by: Matheus Tavares <matheus.bernardino@usp.br> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-26column: fix parsing of the '--nl' optionLibravatar SZEDER Gábor1-1/+1
'git column's '--nl' option can be used to specify a "string to be printed at the end of each line" (quoting the man page), but this option and its mandatory argument has been parsed as OPT_INTEGER since the introduction of the command in 7e29b8254f (Add column layout skeleton and git-column, 2012-04-21). Consequently, any non-number argument is rejected by parse-options, and any number other than 0 leads to segfault: $ printf "%s\n" one two |git column --mode=plain --nl=foo error: option `nl' expects a numerical value $ printf "%s\n" one two |git column --mode=plain --nl=42 Segmentation fault (core dumped) $ printf "%s\n" one two |git column --mode=plain --nl=0 one two Parse this option as OPT_STRING. Signed-off-by: SZEDER Gábor <szeder.dev@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-25use xopen() to handle fatal open(2) failuresLibravatar René Scharfe11-37/+12
Add and apply a semantic patch for using xopen() instead of calling open(2) and die() or die_errno() explicitly. This makes the error messages more consistent and shortens the code. Signed-off-by: René Scharfe <l.s.r@web.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-24rebase: emit one "fatal" in "fatal: fatal: <error>"Libravatar Ævar Arnfjörð Bjarmason1-1/+1
The die() routine adds a "fatal: " prefix, there is no reason to add another one. Fixes code added in e65123a71d0 (builtin rebase: support `git rebase <upstream> <switch-to>`, 2018-09-04). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-24ls-remote: set packet_trace_identity(<name>)Libravatar Ævar Arnfjörð Bjarmason1-0/+2
Set packet_trace_identity() for ls-remote. This replaces the generic "git" identity in GIT_TRACE_PACKET=<file> traces to "ls-remote", e.g.: [...] packet: upload-pack> version 2 [...] packet: upload-pack> agent=git/2.32.0-dev [...] packet: ls-remote< version 2 [...] packet: ls-remote< agent=git/2.32.0-dev Where in an "git ls-remote file://<path>" dialog ">" is the sender (or "to the server") and "<" is the recipient (or "received by the client"). Signed-off-by: Ævar Arnfjörð Bjarmason <avarab@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-24maintenance: skip bootout/bootstrap when plist is registeredLibravatar Derrick Stolee1-9/+45
On macOS, we use launchctl to manage the background maintenance schedule. This uses a set of .plist files to describe the schedule, but these files are also registered with 'launchctl bootstrap'. If multiple 'git maintenance start' commands run concurrently, then they can collide replacing these schedule files and registering them with launchctl. To avoid extra launchctl commands, do a check for the .plist files on disk and check if they are registered using 'launchctl list <name>'. This command will return with exit code 0 if it exists, or exit code 113 if it does not. We can test this behavior using the GIT_TEST_MAINT_SCHEDULER environment variable. Signed-off-by: Derrick Stolee <dstolee@microsoft.com> Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>
2021-08-24maintenance: create `launchctl` configuration using a lock fileLibravatar Johannes Schindelin1-17/+30
When two `git maintenance` processes try to write the `.plist` file, we need to help them with serializing their efforts. The 150ms time-out value was determined from thin air. Signed-off-by: Johannes Schindelin <johannes.schindelin@gmx.de> Signed-off-by: Junio C Hamano <gitster@pobox.com>