timeless <timeless@mozdev.org> [Wed, 03 Feb 2016 15:18:29 +0000] rev 28025
blackbox: flush output file descriptor
Without this, when there are multiple ui views, each blackbox
will have its own file handle, and the logging will be in
a really bad order.
Also, because of the way blackbox works, it never closes its
file handles, which means the last output before exit is
often lost.
timeless <timeless@mozdev.org> [Wed, 03 Feb 2016 18:15:18 +0000] rev 28024
tests: change blackbox test to work cross platform
While it is not easy to make a file 000 on Windows, you can
emulate most of the behaviors by replacing the file with a directory.
Also corrects test description to properly indicate that failing to
read from the log is fatal.
Siddharth Agarwal <sid0@fb.com> [Mon, 01 Feb 2016 20:28:32 -0800] rev 28023
merge: document checkignored and checkunknown configs again
These options were undocumented for 3.7 because of an issue found during the
freeze (see rev 7cb7264cfd52). This issue has now been fixed, so we can
document these options again.
Siddharth Agarwal <sid0@fb.com> [Wed, 03 Feb 2016 13:12:06 -0800] rev 28022
rebase: respect checkunknown and checkignored in more cases
checkunknown and checkignored are currently respected for updates and regular
merges, but not for certain kinds of rebases. To be precise, they aren't
respected for rebases when:
(1) we're rebasing while currently on the destination commit, and
(2) an untracked or ignored file F is currently in the working copy, and
(3) the same file F is in a source commit, and
(4) F has different contents in the source commit.
This happens because rebases set force to True when calling merge.update.
Setting force to True makes a lot of sense in general, but it turns out the
force option is overloaded: there's a deprecated '--force' option in merge that
allows you to merge in outstanding changes, including changes in untracked
files. We use the 'mergeforce' parameter to tell those two cases apart.
I think the behavior during rebases when checkunknown is 'abort' (the default)
is wrong -- we should abort on or overwrite differing untracked files, not try
to merge them in. However that currently breaks rebases by aborting in the
middle -- we need better handling for that case before we can change the
default.
Siddharth Agarwal <sid0@fb.com> [Wed, 03 Feb 2016 13:11:34 -0800] rev 28021
test-merge-force: add tests for merge.checkunknown=warn
In an upcoming patch we're going to change the behavior of some merges with
merge.checkunknown=warn or ignore -- ensure that the behavior of the deprecated
'merge --force' remains the same.
Siddharth Agarwal <sid0@fb.com> [Mon, 01 Feb 2016 20:28:32 -0800] rev 28020
merge: tell _checkunknownfiles about whether this was merge --force
In an upcoming patch we'll have different behavior here for when 'merge
--force' is used as opposed to when other kinds of force operations are
performed, like rebases.
Siddharth Agarwal <sid0@fb.com> [Mon, 01 Feb 2016 20:28:32 -0800] rev 28019
merge: add missing doc for 'labels' parameter
Siddharth Agarwal <sid0@fb.com> [Mon, 01 Feb 2016 20:28:32 -0800] rev 28018
merge: move abort/warn checks up to the top level of _checkunknownfiles
In upcoming patches, we're also going to do these checks when force is True.
Martin von Zweigbergk <martinvonz@google.com> [Fri, 05 Feb 2016 21:09:32 -0800] rev 28017
match: rename "narrowmatcher" to "subdirmatcher" (API)
I keep mistaking "narrowmatcher" for narrowhg's
narrowmatcher. "subdirmatcher" seems more to the point anyway.
timeless <timeless@mozdev.org> [Wed, 03 Feb 2016 18:59:35 +0000] rev 28016
tests: relax test-devel-warnings to reduce false positives
This test is interested in warning output, so
glob away line numbers and hashes as they aren't relevant
to its core.
Matt Mackall <mpm@selenic.com> [Sun, 07 Feb 2016 00:49:31 -0600] rev 28015
merge with stable
Jun Wu <quark@fb.com> [Tue, 19 Jan 2016 18:20:13 +0000] rev 28014
chgserver: create new process group after fork (issue5051)
This is to make SIGTSTP work. Before the patch, the server process group is
considered "orphaned" and will ignore SIGTSTP, SIGTTIN, SIGTTOU, according to
POSIX. See the comment above `will_become_orphaned_pgrp` in `kernel/exit.c`
from Linux 4.3 for details.
SIGTSTP is important if chgserver runs some ncurses commend like `commit -i`.
Ncurses has its own SIGTSTP handler which will do the following:
1. Clean the screen
2. Stop itself by resending SIGTSTP to itself
3. Restore the screen
If SIGTSTP is ignored, step 2 will be a noop, which means the process cannot
be suspended properly.
In order to make things work, chg client needs to forward SIGTSTP and SIGCONT
to server as well.