The concept is defined and "used" by the flag code, but it is neither persisted
nor set anywhere yet. We currently focus on defining the semantic of the
attribute. More to come in the next changesets
Check the inline documentation for details.
Alphare |
hg-reviewers |
The concept is defined and "used" by the flag code, but it is neither persisted
nor set anywhere yet. We currently focus on defining the semantic of the
attribute. More to come in the next changesets
Check the inline documentation for details.
Automatic diff as part of commit; lint not applicable. |
Automatic diff as part of commit; unit tests not applicable. |
Nice! I'd love an experimental UI for this if this is the last py2 release, but even if it's just used in the background so that rebasing/amending added files stops dropping these bits, it would be a major benefit.
I glossed over the rust code, so if someone familiar with it could make a pass, I'd appreciate it.
mercurial/dirstate.py | ||
---|---|---|
295–296 | Is there a reason we don't need a similar elif for exec in the symlink case above? (What if there's a symlink fallback, but not exec fallback?) Also, is symlink and exec mutually exclusive? I'd think not for the platforms where it's read from the filesystem, but maybe that's sanitized away somewhere? | |
mercurial/pure/parsers.py | ||
291 | /True is/ True if/ (same issue below for symlink function) | |
324 | This cast ends up masking out the None, which is not what has_fallback_exec seems to expect. Or am I misunderstanding? (Same comment for symlink below) |
In D11686#179283, @mharbison72 wrote:Nice! I'd love an experimental UI for this if this is the last py2 release,
I am not sure 6.0 would be the last py2 release since we still do not have python3 packaging for TortoiseHG …
but even if it's just used in the background so that rebasing/amending added files stops dropping these bits, it would be a major benefit.
I do not think we will have the time to do more than implement basic flag semantic in 6.0. Putting them to use will have to wait until 6.1 am I afraid.
I glossed over the rust code, so if someone familiar with it could make a pass, I'd appreciate it.
mercurial/cext/parsers.c | ||
---|---|---|
512 | This is the getter of the has_fallback_xxx property. So the name is legitimate. | |
mercurial/dirstate.py | ||
295–296 | The "FS" code return l regarless of the x status if this is a symlink. The logic you comment comply with that. If we have a symlink_fallback but no symlink_flag, we still need to check for x. However if we have fallback for both but non set, we know we have no flag. | |
mercurial/pure/parsers.py | ||
324 | good catch, thanks. | |
rust/hg-core/src/dirstate/entry.rs | ||
25 | Yes they should. I remember thinking about it, but apparently then forgot about that. Fixing it. |
Path | Packages | |||
---|---|---|---|---|
M | mercurial/cext/parsers.c (96 lines) | |||
M | mercurial/cext/util.h (4 lines) | |||
M | mercurial/dirstate.py (23 lines) | |||
M | mercurial/pure/parsers.py (84 lines) | |||
M | rust/hg-core/src/dirstate/entry.rs (50 lines) | |||
M | rust/hg-cpython/src/dirstate/item.rs (65 lines) |
static const int dirstate_flag_has_meaningful_data = 1 << 3; | static const int dirstate_flag_has_meaningful_data = 1 << 3; | ||||
static const int dirstate_flag_has_file_mtime = 1 << 4; | static const int dirstate_flag_has_file_mtime = 1 << 4; | ||||
static const int dirstate_flag_has_directory_mtime = 1 << 5; | static const int dirstate_flag_has_directory_mtime = 1 << 5; | ||||
static const int dirstate_flag_mode_exec_perm = 1 << 6; | static const int dirstate_flag_mode_exec_perm = 1 << 6; | ||||
static const int dirstate_flag_mode_is_symlink = 1 << 7; | static const int dirstate_flag_mode_is_symlink = 1 << 7; | ||||
static const int dirstate_flag_expected_state_is_modified = 1 << 8; | static const int dirstate_flag_expected_state_is_modified = 1 << 8; | ||||
static const int dirstate_flag_all_unknown_recorded = 1 << 9; | static const int dirstate_flag_all_unknown_recorded = 1 << 9; | ||||
static const int dirstate_flag_all_ignored_recorded = 1 << 10; | static const int dirstate_flag_all_ignored_recorded = 1 << 10; | ||||
static const int dirstate_flag_fallback_exec = 1 << 11; | |||||
static const int dirstate_flag_has_fallback_exec = 1 << 12; | |||||
static const int dirstate_flag_fallback_symlink = 1 << 13; | |||||
static const int dirstate_flag_has_fallback_symlink = 1 << 14; | |||||
extern PyTypeObject dirstateItemType; | extern PyTypeObject dirstateItemType; | ||||
#define dirstate_tuple_check(op) (Py_TYPE(op) == &dirstateItemType) | #define dirstate_tuple_check(op) (Py_TYPE(op) == &dirstateItemType) | ||||
#ifndef MIN | #ifndef MIN | ||||
#define MIN(a, b) (((a) < (b)) ? (a) : (b)) | #define MIN(a, b) (((a) < (b)) ? (a) : (b)) | ||||
#endif | #endif | ||||
/* VC9 doesn't include bool and lacks stdbool.h based on my searching */ | /* VC9 doesn't include bool and lacks stdbool.h based on my searching */ |
use cpython::exc; | use cpython::exc; | ||||
use cpython::ObjectProtocol; | |||||
use cpython::PyBytes; | use cpython::PyBytes; | ||||
use cpython::PyErr; | use cpython::PyErr; | ||||
use cpython::PyNone; | use cpython::PyNone; | ||||
use cpython::PyObject; | use cpython::PyObject; | ||||
use cpython::PyResult; | use cpython::PyResult; | ||||
use cpython::Python; | use cpython::Python; | ||||
use cpython::PythonObject; | use cpython::PythonObject; | ||||
use hg::dirstate::DirstateEntry; | use hg::dirstate::DirstateEntry; | ||||
} | } | ||||
@property | @property | ||||
def mtime(&self) -> PyResult<i32> { | def mtime(&self) -> PyResult<i32> { | ||||
Ok(self.entry(py).get().mtime()) | Ok(self.entry(py).get().mtime()) | ||||
} | } | ||||
@property | @property | ||||
def has_fallback_exec(&self) -> PyResult<bool> { | |||||
match self.entry(py).get().get_fallback_exec() { | |||||
Some(_) => Ok(true), | |||||
None => Ok(false), | |||||
} | |||||
} | |||||
@property | |||||
def fallback_exec(&self) -> PyResult<Option<bool>> { | |||||
match self.entry(py).get().get_fallback_exec() { | |||||
Some(exec) => Ok(Some(exec)), | |||||
None => Ok(None), | |||||
} | |||||
} | |||||
@fallback_exec.setter | |||||
def set_fallback_exec(&self, value: Option<PyObject>) -> PyResult<()> { | |||||
match value { | |||||
None => {self.entry(py).get().set_fallback_exec(None);}, | |||||
Some(value) => { | |||||
if value.is_none(py) { | |||||
self.entry(py).get().set_fallback_exec(None); | |||||
} else { | |||||
self.entry(py).get().set_fallback_exec( | |||||
Some(value.is_true(py)?) | |||||
); | |||||
}}, | |||||
} | |||||
Ok(()) | |||||
} | |||||
@property | |||||
def has_fallback_symlink(&self) -> PyResult<bool> { | |||||
match self.entry(py).get().get_fallback_symlink() { | |||||
Some(_) => Ok(true), | |||||
None => Ok(false), | |||||
} | |||||
} | |||||
@property | |||||
def fallback_symlink(&self) -> PyResult<Option<bool>> { | |||||
match self.entry(py).get().get_fallback_symlink() { | |||||
Some(symlink) => Ok(Some(symlink)), | |||||
None => Ok(None), | |||||
} | |||||
} | |||||
@fallback_symlink.setter | |||||
def set_fallback_symlink(&self, value: Option<PyObject>) -> PyResult<()> { | |||||
match value { | |||||
None => {self.entry(py).get().set_fallback_symlink(None);}, | |||||
Some(value) => { | |||||
if value.is_none(py) { | |||||
self.entry(py).get().set_fallback_symlink(None); | |||||
} else { | |||||
self.entry(py).get().set_fallback_symlink( | |||||
Some(value.is_true(py)?) | |||||
); | |||||
}}, | |||||
} | |||||
Ok(()) | |||||
} | |||||
@property | |||||
def tracked(&self) -> PyResult<bool> { | def tracked(&self) -> PyResult<bool> { | ||||
Ok(self.entry(py).get().tracked()) | Ok(self.entry(py).get().tracked()) | ||||
} | } | ||||
@property | @property | ||||
def p1_tracked(&self) -> PyResult<bool> { | def p1_tracked(&self) -> PyResult<bool> { | ||||
Ok(self.entry(py).get().p1_tracked()) | Ok(self.entry(py).get().p1_tracked()) | ||||
} | } |
Why are these called *_get_has_*? Is it a convention or just accidental?