summaryrefslogtreecommitdiff
Commit message (Collapse)AuthorAgeFilesLines
* lockfile: change lock_file::filename into a strbufMichael Haggerty2014-10-018-52/+47
| | | | | | | | | | | | | | | | For now, we still make sure to allocate at least PATH_MAX characters for the strbuf because resolve_symlink() doesn't know how to expand the space for its return value. (That will be fixed in a moment.) Another alternative would be to just use a strbuf as scratch space in lock_file() but then store a pointer to the naked string in struct lock_file. But lock_file objects are often reused. By reusing the same strbuf, we can avoid having to reallocate the string most times when a lock_file object is reused. Helped-by: Torsten Bögershausen <tboegi@web.de> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* commit_lock_file(): use a strbuf to manage temporary spaceMichael Haggerty2014-10-011-5/+7
| | | | | | | | Avoid relying on the filename length restrictions that are currently checked by lock_file(). Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* try_merge_strategy(): use a statically-allocated lock_file objectMichael Haggerty2014-10-011-7/+7
| | | | | | | | | | Even the one lockfile object needn't be allocated each time the function is called. Instead, define one statically-allocated lock_file object and reuse it for every call. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* try_merge_strategy(): remove redundant lock_file allocationMichael Haggerty2014-10-011-1/+0
| | | | | | | | | | | | | By the time the "if" block is entered, the lock_file instance from the main function block is no longer in use, so re-use that one instead of allocating a second one. Note that the "lock" variable in the "if" block shadowed the "lock" variable at function scope, so the only change needed is to remove the inner definition. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* struct lock_file: declare some fields volatileMichael Haggerty2014-10-012-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | The function remove_lock_file_on_signal() is used as a signal handler. It is not realistic to make the signal handler conform strictly to the C standard, which is very restrictive about what a signal handler is allowed to do. But let's increase the likelihood that it will work: The lock_file_list global variable and several fields from struct lock_file are used by the signal handler. Declare those values "volatile" to (1) force the main process to write the values to RAM promptly, and (2) prevent updates to these fields from being reordered in a way that leaves an opportunity for a jump to the signal handler while the object is in an inconsistent state. We don't mark the filename field volatile because that would prevent the use of strcpy(), and it is anyway unlikely that a compiler re-orders a strcpy() call across other expressions. So in practice it should be possible to get away without "volatile" in the "filename" case. Suggested-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* lockfile: avoid transitory invalid statesMichael Haggerty2014-10-013-11/+28
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Because remove_lock_file() can be called any time by the signal handler, it is important that any lock_file objects that are in the lock_file_list are always in a valid state. And since lock_file objects are often reused (but are never removed from lock_file_list), that means we have to be careful whenever mutating a lock_file object to always keep it in a well-defined state. This was formerly not the case, because part of the state was encoded by setting lk->filename to the empty string vs. a valid filename. It is wrong to assume that this string can be updated atomically; for example, even strcpy(lk->filename, value) is unsafe. But the old code was even more reckless; for example, strcpy(lk->filename, path); if (!(flags & LOCK_NODEREF)) resolve_symlink(lk->filename, max_path_len); strcat(lk->filename, ".lock"); During the call to resolve_symlink(), lk->filename contained the name of the file that was being locked, not the name of the lockfile. If a signal were raised during that interval, then the signal handler would have deleted the valuable file! We could probably continue to use the filename field to encode the state by being careful to write characters 1..N-1 of the filename first, and then overwrite the NUL at filename[0] with the first character of the filename, but that would be awkward and error-prone. So, instead of using the filename field to determine whether the lock_file object is active, add a new field "lock_file::active" for this purpose. Be careful to set this field only when filename really contains the name of a file that should be deleted on cleanup. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* git_config_set_multivar_in_file(): avoid call to rollback_lock_file()Michael Haggerty2014-10-011-0/+1
| | | | | | | | | After commit_lock_file() is called, then the lock_file object is necessarily either committed or rolled back. So there is no need to call rollback_lock_file() again in either of these cases. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* dump_marks(): remove a redundant call to rollback_lock_file()Michael Haggerty2014-10-011-3/+1
| | | | | | | | | | When commit_lock_file() fails, it now always calls rollback_lock_file() internally, so there is no need to call that function here. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* api-lockfile: document edge casesMichael Haggerty2014-10-011-6/+14
| | | | | | | | | | | | | * Document the behavior of commit_lock_file() when it fails, namely that it rolls back the lock_file object and sets errno appropriately. * Document the behavior of rollback_lock_file() when called for a lock_file object that has already been committed or rolled back, namely that it is a NOOP. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* commit_lock_file(): rollback lock file on failure to renameMichael Haggerty2014-10-011-1/+6
| | | | | | | | | If rename() fails, call rollback_lock_file() to delete the lock file (in case it is still present) and reset the filename field to the empty string so that the lockfile object is left in a valid state. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* close_lock_file(): if close fails, roll backMichael Haggerty2014-10-012-13/+22
| | | | | | | | | | | | | | | | | | If closing an open lockfile fails, then we cannot be sure of the contents of the lockfile, so there is nothing sensible to do but delete it. This change also insures that the lock_file object is left in a defined state in this error path (namely, unlocked). The only caller that is ultimately affected by this change is try_merge_strategy() -> write_locked_index(), which can call close_lock_file() via various execution paths. This caller uses a static lock_file object which previously could have been reused after a failed close_lock_file() even though it was still in locked state. This change causes the lock_file object to be unlocked on failure, thus fixing this error-handling path. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* commit_lock_file(): die() if called for unlocked lockfile objectMichael Haggerty2014-10-012-1/+5
| | | | | | | | | | | | It was previously a bug to call commit_lock_file() with a lock_file object that was not active (an illegal access would happen within the function). It was presumably never done, but this would be an easy programming error to overlook. So before continuing, do a consistency check that the lock_file object really is locked. Helped-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* commit_lock_file(): inline temporary variableMichael Haggerty2014-10-011-3/+5
| | | | | Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* remove_lock_file(): call rollback_lock_file()Michael Haggerty2014-10-011-6/+2
| | | | | | | | It does just what we need. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* lock_file(): exit early if lockfile cannot be openedMichael Haggerty2014-10-011-12/+11
| | | | | | | | | | This is a bit easier to read than the old version, which nested part of the non-error code in an "if" block. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* prepare_index(): declare return value to be (const char *)Michael Haggerty2014-10-011-2/+2
| | | | | | | | | | | Declare the return value to be const to make it clear that we aren't giving callers permission to write over the string that it points at. (The return value is the filename field of a struct lock_file, which can be used by a signal handler at any time and therefore shouldn't be tampered with.) Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* delete_ref_loose(): don't muck around in the lock_file's filenameMichael Haggerty2014-10-011-6/+9
| | | | | | | | | | | | It's bad manners. Especially since there could be a signal during the call to unlink_or_warn(), in which case the signal handler will see the wrong filename and delete the reference file, leaving the lockfile behind. So make our own copy to work with. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* cache.h: define constants LOCK_SUFFIX and LOCK_SUFFIX_LENMichael Haggerty2014-10-013-8/+14
| | | | | | | | There are a few places that use these values, so define constants for them. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* lockfile.c: document the various states of lock_file objectsMichael Haggerty2014-10-011-0/+42
| | | | | | | | | Document the valid states of lock_file objects, how they get into each state, and how the state is encoded in the object's fields. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* lock_file(): always initialize and register lock_file objectMichael Haggerty2014-10-011-9/+16
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | The purpose of this change is to make the state diagram for lock_file objects simpler and deterministic. If locking fails, lock_file() sometimes leaves the lock_file object partly initialized, but sometimes not. It sometimes registers the object in lock_file_list, but sometimes not. This makes the state diagram for lock_file objects effectively indeterministic and hard to reason about. A future patch will also change the filename field into a strbuf, which needs more involved initialization, so it will become even more important that the state of a lock_file object is well-defined after a failed attempt to lock. The ambiguity doesn't currently have any ill effects, because lock_file objects cannot be removed from the lock_file_list anyway. But to make it easier to document and reason about the code, make this behavior consistent: *always* initialize the lock_file object and *always* register it in lock_file_list the first time it is used, regardless of whether an error occurs. While we're at it, make sure that all of the lock_file fields are initialized to values appropriate for an unlocked object; the caller is only responsible for making sure that on_list is set to zero before the first time it is used. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* hold_lock_file_for_append(): release lock on errorsMichael Haggerty2014-10-011-2/+2
| | | | | | | | | | If there is an error copying the old contents to the lockfile, roll back the lockfile before exiting so that the lockfile is not held until process cleanup. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* lockfile: unlock file if lockfile permissions cannot be adjustedMichael Haggerty2014-10-011-0/+1
| | | | | | | | | | | | | If the call to adjust_shared_perm() fails, lock_file returns -1, which to the caller looks like any other failure to lock the file. So in this case, roll back the lockfile before returning so that the lock file is deleted immediately and the lockfile object is left in a predictable state (namely, unlocked). Previously, the lockfile was retained until process cleanup in this situation. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rollback_lock_file(): set fd to -1Michael Haggerty2014-10-011-2/+1
| | | | | | | | | | | | | When rolling back the lockfile, call close_lock_file() so that the lock_file's fd field gets set back to -1. This keeps the lock_file object in a valid state, which is important because these objects are allowed to be reused. It also makes it unnecessary to check whether the file has already been closed, because close_lock_file() takes care of that. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rollback_lock_file(): exit early if lock is not activeMichael Haggerty2014-10-011-6/+7
| | | | | | | | | Eliminate a layer of nesting. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* rollback_lock_file(): do not clear filename redundantlyMichael Haggerty2014-10-011-1/+1
| | | | | | | | | | It is only necessary to clear the lock_file's filename field if it was not already clear. Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* close_lock_file(): exit (successfully) if file is already closedMichael Haggerty2014-10-012-2/+6
| | | | | | Suggested-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* api-lockfile: revise and expand the documentationMichael Haggerty2014-10-011-54/+167
| | | | | | | | | | | Document a couple more functions and the flags argument as used by hold_lock_file_for_update() and hold_lock_file_for_append(). Reorganize the document to make it more accessible. Helped-by: Jonathan Nieder <jrnieder@gmail.com> Helped-by: Junio Hamano <gitster@pobox.com> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* unable_to_lock_die(): rename function from unable_to_lock_index_die()Michael Haggerty2014-10-014-6/+6
| | | | | | | | | | | This function is used for other things besides the index, so rename it accordingly. Suggested-by: Jeff King <peff@peff.net> Signed-off-by: Michael Haggerty <mhagger@alum.mit.edu> Reviewed-by: Ronnie Sahlberg <sahlberg@google.com> Reviewed-by: Jonathan Nieder <jrnieder@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* Sync with 2.1.2Junio C Hamano2014-09-292-1/+22
|\ | | | | | | | | * maint: Git 2.1.2
| * Git 2.1.2v2.1.2Junio C Hamano2014-09-294-3/+24
| | | | | | | | Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * Merge branch 'jk/fsck-exit-code-fix' into maintJunio C Hamano2014-09-293-9/+87
| |\ | | | | | | | | | | | | | | | | | | | | | | | | "git fsck" failed to report that it found corrupt objects via its exit status in some cases. * jk/fsck-exit-code-fix: fsck: return non-zero status on missing ref tips fsck: exit with non-zero status upon error from fsck_obj()
| * \ Merge branch 'ta/config-add-to-empty-or-true-fix' into maintJunio C Hamano2014-09-294-7/+41
| |\ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git config --add section.var val" used to lose existing section.var whose value was an empty string. * ta/config-add-to-empty-or-true-fix: config: avoid a funny sentinel value "a^" make config --add behave correctly for empty and NULL values
| * \ \ Merge branch 'mk/reachable-protect-detached-head' into maintJunio C Hamano2014-09-292-0/+25
| |\ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Reachability check (used in "git prune" and friends) did not add a detached HEAD as a starting point to traverse objects still in use. * mk/reachable-protect-detached-head: reachable.c: add HEAD to reachability starting commits
| * \ \ \ Merge branch 'mb/fast-import-delete-root' into maintJunio C Hamano2014-09-292-1/+109
| |\ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | An attempt to remove the entire tree in the "git fast-import" input stream caused it to misbehave. * mb/fast-import-delete-root: fast-import: fix segfault in store_tree() t9300: test filedelete command
| * \ \ \ \ Merge branch 'jk/index-pack-threading-races' into maintJunio C Hamano2014-09-291-2/+31
| |\ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | When receiving an invalid pack stream that records the same object twice, multiple threads got confused due to a race. * jk/index-pack-threading-races: index-pack: fix race condition with duplicate bases
| * \ \ \ \ \ Merge branch 'jk/send-pack-many-refspecs' into maintJunio C Hamano2014-09-295-2/+153
| |\ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git push" over HTTP transport had an artificial limit on number of refs that can be pushed imposed by the command line length. * jk/send-pack-many-refspecs: send-pack: take refspecs over stdin
| * \ \ \ \ \ \ Merge branch 'so/rebase-doc' into maintJunio C Hamano2014-09-291-6/+3
| |\ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | * so/rebase-doc: Documentation/git-rebase.txt: <upstream> must be given to specify <branch> Documentation/git-rebase.txt: -f forces a rebase that would otherwise be a no-op
* | \ \ \ \ \ \ \ Merge branch 'jt/itimer-autoconf'Junio C Hamano2014-09-292-1/+15
|\ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | setitmer(2) and related API elements can be configured from Makefile but autoconf did not know about it. * jt/itimer-autoconf: autoconf: check for setitimer() autoconf: check for struct itimerval git-compat-util.h: add missing semicolon after struct itimerval
| * | | | | | | | | autoconf: check for setitimer()jt/itimer-autoconfJonas 'Sortie' Termansen2014-08-291-0/+6
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Makefile has provisions for this case, so let's detect it in the configure script as well. Signed-off-by: Jonas 'Sortie' Termansen <sortie@maxsi.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | autoconf: check for struct itimervalJonas 'Sortie' Termansen2014-08-291-0/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The Makefile has provisions for this case, so let's detect it in the configure script as well. Signed-off-by: Jonas 'Sortie' Termansen <sortie@maxsi.org> Signed-off-by: Jacob Keller <jacob.e.keller@intel.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | git-compat-util.h: add missing semicolon after struct itimervalJonas 'Sortie' Termansen2014-08-291-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This hasn't been a problem in practice as almost all systems have the setitimer() API (or it is provided by git in the case of mingw). This code wasn't used in any default circumstances, as the build system never sets NO_STRUCT_ITIMERVAL - this breakage only occured if the user asked for it. We repair this case so we can rely on it in the following commits. Signed-off-by: Jonas 'Sortie' Termansen <sortie@maxsi.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | | | Merge branch 'jc/test-lazy-prereq'Junio C Hamano2014-09-292-4/+0
|\ \ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Test-script clean-up. * jc/test-lazy-prereq: tests: drop GIT_*_TIMING_TESTS environment variable support
| * | | | | | | | | | tests: drop GIT_*_TIMING_TESTS environment variable supportjc/test-lazy-prereqJunio C Hamano2014-06-132-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Two tests (t3302 and t3419) used to have their own environment variable to trigger expensive tests without enabling expensive tests in other scripts; a user could set GIT_NOTES_TIMING_TESTS but not GIT_TEST_LONG and run the whole test suite and trigger expensive tests only in t3302 but not other tests. The same for GIT_PATCHID_TIMING_TESTS in t3419. While this may have seemed a good flexibility, in reality if you are concentrating on a single test (e.g. t3302), you can just run that single test with the GIT_TEST_LONG to trigger expensive tests. It does not seem worth forcing other people who may want to come up with their own expensive tests to invent new environment variables by keeping this convention. Drop them. Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | | | | Merge branch 'sb/merge-recursive-copy-paste-fix'Junio C Hamano2014-09-291-5/+1
|\ \ \ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | "git merge-recursive" had a small bug that could have made it mishandle "one side deleted, the other side did not touch it" in a rare corner case, where the other side actually did touch to cause the blob object names to be different but both blobs before and after the change normalize to the same (e.g. correcting mistake to check in a blob with CRLF line endings by replacing it with another blob that records the same contents with LF line endings). * sb/merge-recursive-copy-paste-fix: merge-recursive: remove stale commented debugging code merge-recursive: fix copy-paste mistake
| * | | | | | | | | | | merge-recursive: remove stale commented debugging codesb/merge-recursive-copy-paste-fixStefan Beller2014-09-231-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Signed-off-by: Stefan Beller <stefanbeller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | | | merge-recursive: fix copy-paste mistakeStefan Beller2014-09-231-1/+1
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | The following issue was found by scan.coverity.com (ID: 1049510), and claimed to be likely a copy-paste mistake. Introduced in 331a1838b (2010-07-02, Try normalizing files to avoid delete/modify conflicts when merging), which is quite a long time ago, so I'm rather unsure if it's of any impact or just went unnoticed. The line after the changed line has a comparison of 'o.len' to 'a.len', so we should assume the lengths may be different. I'd be happy to have a test for this bug(?) attached to t6031-merge-recursive.sh, but I did not manage to come up with a test in a reasonable amount of time. Signed-off-by: Stefan Beller <stefanbeller@gmail.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | | | | | Merge branch 'pr/use-default-sigpipe-setting'Junio C Hamano2014-09-293-1/+50
|\ \ \ \ \ \ \ \ \ \ \ \ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | We used to get confused when a process called us with SIGPIPE ignored; we do want to die with SIGPIPE when the output is not read by default, and do ignore the signal when appropriate. * pr/use-default-sigpipe-setting: mingw.h: add dummy functions for sigset_t operations unblock and unignore SIGPIPE
| * | | | | | | | | | | | mingw.h: add dummy functions for sigset_t operationspr/use-default-sigpipe-settingJohannes Sixt2014-09-222-3/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Windows does not have POSIX-like signals, and so we ignore all operations on the non-existent signal mask machinery. Do not turn sigemptyset into a function, but leave it a macro that erases the code in the argument because it is used to set sa_mask of a struct sigaction, but our dummy in mingw.h does not have that member. Signed-off-by: Johannes Sixt <j6t@kdbg.org> Signed-off-by: Junio C Hamano <gitster@pobox.com>
| * | | | | | | | | | | | unblock and unignore SIGPIPEPatrick Reynolds2014-09-182-0/+44
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Blocked and ignored signals -- but not caught signals -- are inherited across exec. Some callers with sloppy signal-handling behavior can call git with SIGPIPE blocked or ignored, even non-deterministically. When SIGPIPE is blocked or ignored, several git commands can run indefinitely, ignoring EPIPE returns from write() calls, even when the process that called them has gone away. Our specific case involved a pipe of git diff-tree output to a script that reads a limited amount of diff data. In an ideal world, git would never be called with SIGPIPE blocked or ignored. But in the real world, several real potential callers, including Perl, Apache, and Unicorn, sometimes spawn subprocesses with SIGPIPE ignored. It is easier and more productive to harden git against this mistake than to clean it up in every potential parent process. Signed-off-by: Patrick Reynolds <patrick.reynolds@github.com> Signed-off-by: Junio C Hamano <gitster@pobox.com>
* | | | | | | | | | | | | Update draft release notes to 2.2Junio C Hamano2014-09-291-0/+12
| | | | | | | | | | | | |
View Lorry Controller Status