git/lockfile.c, branch v2.50.0

treewide: remove unnecessary includes of cache.h

2023-03-21T17:56:53Z

The last several commits were geared at replacing the include of cache.h in strbuf.c with an include of git-compat-util.h. Unfortunately, I had to drop a patch moving some functions from cache.h to object-name.h, due to excessive conflicts with other in-flight topics. However, even without that patch, the series of patches so far allows us to modify a number of C files to replace an include of cache.h with git-compat-util.h. Do that to reduce our dependencies. (If we could have kept our object-name.h patch in this series, it would have also let us reduce the includes in checkout.c and fmt-merge-msg.c in addition to strbuf.c). Just to ensure that nothing else was bringing in cache.h, all of the affected files have been checked to ensure that gcc -E -I. $SOURCE_FILE | grep '"cache.h"' found no hits and that make DEVELOPER=1 ${OBJECT_FILE_FOR_SOURCE_FILE} successfully compiles without warnings. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

abspath.h: move absolute path functions from cache.h

2023-03-21T17:56:52Z

This is another step towards letting us remove the include of cache.h in strbuf.c. It does mean that we also need to add includes of abspath.h in a number of C files. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

treewide: be explicit about dependence on gettext.h

2023-03-21T17:56:51Z

Dozens of files made use of gettext functions, without explicitly including gettext.h. This made it more difficult to find which files could remove a dependence on cache.h. Make C files explicitly include gettext.h if they are using it. However, while compat/fsmonitor/fsm-ipc-darwin.c should also gain an include of gettext.h, it was left out to avoid conflicting with an in-flight topic. Signed-off-by: Elijah Newren Signed-off-by: Junio C Hamano

lockfile.c: introduce 'hold_lock_file_for_update_mode'

2020-04-27T18:27:36Z

We use 'hold_lock_file_for_update' (and the '_timeout') variant to acquire a lock when updating references, the commit-graph file, and so on. In particular, the commit-graph machinery uses this to acquire a temporary file that is used to write a non-split commit-graph. In a subsequent commit, an issue in the commit-graph machinery produces graph files that have a different permission based on whether or not they are part of a multi-layer graph will be addressed. To do so, the commit-graph machinery will need a version of 'hold_lock_file_for_update' that takes the permission bits from the caller. Introduce such a function in this patch for both the 'hold_lock_file_for_update' and 'hold_lock_file_for_update_timeout' functions, and leave the existing functions alone by inlining their definitions in terms of the new mode variants. Note that, like in the previous commit, 'hold_lock_file_for_update_mode' is not guarenteed to set the given mode, since it may be modified by both the umask and 'core.sharedRepository'. Note also that even though the commit-graph machinery only calls 'hold_lock_file_for_update', that this is defined in terms of 'hold_lock_file_for_update_timeout', and so both need an additional mode parameter here. Signed-off-by: Taylor Blau Signed-off-by: Junio C Hamano

Replace all die("BUG: ...") calls by BUG() ones

2018-05-06T10:06:13Z

In d8193743e08 (usage.c: add BUG() function, 2017-05-12), a new macro was introduced to use for reporting bugs instead of die(). It was then subsequently used to convert one single caller in 588a538ae55 (setup_git_env: convert die("BUG") to BUG(), 2017-05-12). The cover letter of the patch series containing this patch (cf 20170513032414.mfrwabt4hovujde2@sigill.intra.peff.net) is not terribly clear why only one call site was converted, or what the plan is for other, similar calls to die() to report bugs. Let's just convert all remaining ones in one fell swoop. This trick was performed by this invocation: sed -i 's/die("BUG: /BUG("/g' $(git grep -l 'die("BUG' \*.c) Signed-off-by: Johannes Schindelin Signed-off-by: Junio C Hamano

tempfile: auto-allocate tempfiles on heap

2017-09-06T08:19:54Z

The previous commit taught the tempfile code to give up ownership over tempfiles that have been renamed or deleted. That makes it possible to use a stack variable like this: struct tempfile t; create_tempfile(&t, ...); ... if (!err) rename_tempfile(&t, ...); else delete_tempfile(&t); But doing it this way has a high potential for creating memory errors. The tempfile we pass to create_tempfile() ends up on a global linked list, and it's not safe for it to go out of scope until we've called one of those two deactivation functions. Imagine that we add an early return from the function that forgets to call delete_tempfile(). With a static or heap tempfile variable, the worst case is that the tempfile hangs around until the program exits (and some functions like setup_shallow_temporary rely on this intentionally, creating a tempfile and then leaving it for later cleanup). But with a stack variable as above, this is a serious memory error: the variable goes out of scope and may be filled with garbage by the time the tempfile code looks at it. Let's see if we can make it harder to get this wrong. Since many callers need to allocate arbitrary numbers of tempfiles, we can't rely on static storage as a general solution. So we need to turn to the heap. We could just ask all callers to pass us a heap variable, but that puts the burden on them to call free() at the right time. Instead, let's have the tempfile code handle the heap allocation _and_ the deallocation (when the tempfile is deactivated and removed from the list). This changes the return value of all of the creation functions. For the cleanup functions (delete and rename), we'll add one extra bit of safety: instead of taking a tempfile pointer, we'll take a pointer-to-pointer and set it to NULL after freeing the object. This makes it safe to double-call functions like delete_tempfile(), as the second call treats the NULL input as a noop. Several callsites follow this pattern. The resulting patch does have a fair bit of noise, as each caller needs to be converted to handle: 1. Storing a pointer instead of the struct itself. 2. Passing the pointer instead of taking the struct address. 3. Handling a "struct tempfile *" return instead of a file descriptor. We could play games to make this less noisy. For example, by defining the tempfile like this: struct tempfile { struct heap_allocated_part_of_tempfile { int fd; ...etc } *actual_data; } Callers would continue to have a "struct tempfile", and it would be "active" only when the inner pointer was non-NULL. But that just makes things more awkward in the long run. There aren't that many callers, so we can simply bite the bullet and adjust all of them. And the compiler makes it easy for us to find them all. Signed-off-by: Jeff King Signed-off-by: Junio C Hamano

lockfile: LOCK_REPORT_ON_ERROR

2016-12-07T19:31:59Z

The "libify sequencer" topic stopped passing the die_on_error option to hold_locked_index(), and this lost an error message from "git merge --ff-only $commit" when there are competing updates in progress. The command still exits with a non-zero status, but that is not of much help for an interactive user. The last thing the command says is "Updating $from..$to". We used to follow it with a big error message that makes it clear that "merge --ff-only" did not succeed. What is sad is that we should have noticed this regression while reviewing the change. It was clear that the update to the checkout_fast_forward() function made a failing hold_locked_index() silent, but the only caller of the checkout_fast_forward() function had this comment: if (checkout_fast_forward(from, to, 1)) - exit(128); /* the callee should have complained already */ + return -1; /* the callee should have complained already */ which clearly contradicted the assumption X-<. Add a new option LOCK_REPORT_ON_ERROR that can be passed instead of LOCK_DIE_ON_ERROR to the hold_lock*() family of functions and teach checkout_fast_forward() to use it to fix this regression. After going thourgh all calls to hold_lock*() family of functions that used to pass LOCK_DIE_ON_ERROR but were modified to pass 0 in the "libify sequencer" topic "git show --first-parent 2a4062a4a8", it appears that this is the only one that has become silent. Many others used to give detailed report that talked about "there may be competing Git process running" but with the series merged they now only give a single liner "Unable to lock ...", some of which may have to be tweaked further, but at least they say something, unlike the one this patch fixes. Reported-by: Robbie Iannucci Signed-off-by: Junio C Hamano

lockfile: improve error message when lockfile exists

2016-03-01T18:16:46Z

A common mistake leading a user to see this message is to launch "git commit", let the editor open (and forget about it), and try again to commit. The previous message was going too quickly to "a git process crashed" and to the advice "remove the file manually". This patch modifies the message in two ways: first, it considers that "another process is running" is the norm, not the exception, and it explicitly hints the user to look at text editors. The message is 2 lines longer, but this is not a problem since experienced users do not see the message often. Helped-by: Moritz Neeb Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

lockfile: mark strings for translation

2016-03-01T18:16:45Z

Signed-off-by: Matthieu Moy Signed-off-by: Junio C Hamano

lockfile: remove function "hold_lock_file_for_append"

2015-08-28T18:32:01Z

With 77b9b1d (add_to_alternates_file: don't add duplicate entries, 2015-08-10) the last caller of function "hold_lock_file_for_append" has been removed, so we can remove the function as well. Signed-off-by: Ralf Thielow Acked-by: Jeff King Signed-off-by: Junio C Hamano