{"state":{"revisions":[{"id":"7788","callsign":"HG","title":"rust-node: binary Node ID and conversion utilities","author":"gracinet","summary":"The choice of type makes sure that a `Node` has the exact\nwanted size. We'll use a different type for prefixes.\n\nAdded dependency: hexadecimal conversion relies on the\n`hex` crate.\n\nThe fact that sooner or later Mercurial is going to need\nto change its hash sizes has been taken strongly in\nconsideration:\n\n- the hash length is a constant, but that is not directly\n  exposed to callers. Changing the value of that constant\n  is the only thing to do to change the hash length (even\n  in unit tests)\n- the code could be adapted to support several sizes of hashes,\n  if that turned out to be useful. To that effect, only the\n  size of a given `Node` is exposed in the public API.\n- callers not involved in initial computation, I\/O and FFI\n  are able to operate without a priori assumptions on the hash\n  size. The traits `FromHex` and `ToHex` have not been directly\n  implemented, so that the doc-comments explaining these\n  restrictions would stay really visible in `cargo doc`","testPlan":"","lineCount":"201","dependsOn":["7787"],"reviewers":["kevincox","martinvonz"],"ccs":["martinvonz","durin42","kevincox","mercurial-devel"],"actions":[{"type":"inline","comment":"Finally used the `hex` crate here too.","replyTo":"116132","isNewFile":"1","line":"39","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/node.rs","diffId":"19323","author":"gracinet","id":"117162","dateCreated":"1579724876","dateModified":"1579724876"},{"type":"inline","comment":"Well it's become a public method in the new `Node` struct.\n`NodePrefix` will be another user.\n\nI tend to prefer encapsulation over where it's used for these choices. This way, there's no tempation for nodemap.rs to play with the binary data directly.\n\n","replyTo":"116625","isNewFile":"1","line":"41","lineLength":"10","path":"rust\/hg-core\/src\/revlog\/node.rs","diffId":"19323","author":"gracinet","id":"117161","dateCreated":"1579724876","dateModified":"1579724876"},{"type":"inline","comment":"Yes, `hex` is nice, it's able to produce arrays without further copies and does length checks. Its error type does not repeat the input string, though, which in my experience is really very useful to understand problems when they occur.\n\n`hex` does not support hexadecimal string representations with odd numbers of\ndigits, which will be easy to work around in the next patch.","replyTo":"116624","isNewFile":"1","line":"31","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/node.rs","diffId":"19323","author":"gracinet","id":"117160","dateCreated":"1579724876","dateModified":"1579724876"},{"type":"inline","comment":"ah yes, sorry must have been a rebase artifact","replyTo":"116623","isNewFile":"1","line":"111","lineLength":"0","path":"rust\/hg-core\/src\/dirstate\/dirs_multiset.rs","diffId":"19323","author":"gracinet","id":"117159","dateCreated":"1579724876","dateModified":"1579724876"},{"type":"comment","comment":"As the new commit description explains, I've done all I could to make the change of hash format easier\n\nI should add that my other colleagues at Octobus seem also to be involved in the improvement of hashing, there's no risk we would forget this one.","author":"gracinet","id":"117158","dateCreated":"1579724876","dateModified":"1579724876"},{"type":"update","diffId":"19521","author":"gracinet","id":"117150","dateCreated":"1579723881","dateModified":"1579723881"},{"type":"comment","comment":">>! In D7788#116756, @gracinet wrote:\n> @durin42 @martinvonz we might have a nice path forward with this, with the suggestion of @kevincox to make `Node` a truly defined type, not just an alias, with a private member for the bytes.\n\nSounds good. I think I would have preferred that anyway.\n","author":"martinvonz","id":"117012","dateCreated":"1579632857","dateModified":"1579632857"},{"type":"comment","comment":"@durin42 @martinvonz we might have a nice path forward with this, with the suggestion of @kevincox to make `Node` a truly defined type, not just an alias, with a private member for the bytes.\n\nIndeed I find it important to know if a node information is complete or merely a prefix. With a truly defined type, the assumption that it's 20 bytes long would be completely encapsulated in the `Node` type. It would then be very easy (much easier than with Python code) to change it to something else, whether that'd be a longer bag of bytes, or a struct with two values, an enum with alternatives for sha-1 or sha-2 etc.\n\n\n","author":"gracinet","id":"116756","dateCreated":"1579526276","dateModified":"1579526276"},{"type":"comment","comment":"Yes, I'd appreciate not adding any assumptions that nodes are 20 bytes.","author":"durin42","id":"116740","dateCreated":"1579389482","dateModified":"1579389482"},{"type":"inline","comment":"Oh, I think @durin42 and others were trying to remove the assumption that nodeids are 20 bytes (so we can use other hashes and hash lengths).","replyTo":null,"isNewFile":"1","line":"14","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/node.rs","diffId":"19323","author":"martinvonz","id":"116739","dateCreated":"1579388240","dateModified":"1579388240"},{"type":"inline","comment":"This feels like something that will only be used in nodemap.rs, so put it there instead? Or do you think (or know) that it will be used elsewhere soon?","replyTo":null,"isNewFile":"1","line":"41","lineLength":"10","path":"rust\/hg-core\/src\/revlog\/node.rs","diffId":"19323","author":"martinvonz","id":"116625","dateCreated":"1579310694","dateModified":"1579310694"},{"type":"inline","comment":"Or even use `hex::decode()` from the `hex` crate? Can also use `hex::encode()` in `node_to_hex` if we're okay with that.","replyTo":"116131","isNewFile":"1","line":"31","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/node.rs","diffId":"19323","author":"martinvonz","id":"116624","dateCreated":"1579310694","dateModified":"1579310694"},{"type":"inline","comment":"please revert unrelated change","replyTo":null,"isNewFile":"1","line":"111","lineLength":"0","path":"rust\/hg-core\/src\/dirstate\/dirs_multiset.rs","diffId":"19323","author":"martinvonz","id":"116623","dateCreated":"1579310694","dateModified":"1579310694"},{"type":"reject","author":"martinvonz","id":"116622","dateCreated":"1579310694","dateModified":"1579310694"},{"type":"inline","comment":"If we want to avoid a number of allocations we can do:\n\n```\npub fn node_to_hex(n: &Node) -> String {\n    let mut r = String::with_capacity(n.len() * 2);\n    for byte in n {\n        write!(r, \"{:02x}\", byte).unwrap();\n    }\n    debug_assert_eq!(r.len(), n.len() * 2);\n    r\n}\n```\n\nThe generated code for `write!()` doesn't look great but if hex printing shows up in benchmarks it would be trivial to write a custom hex-formatter.","replyTo":null,"isNewFile":"1","line":"39","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/node.rs","diffId":"19323","author":"kevincox","id":"116132","dateCreated":"1579171819","dateModified":"1579171819"},{"type":"inline","comment":"I find progressing through the string easier to understand than this slicing. WDYT.\n\n```\n    for byte in node.iter_mut() {\n        *byte = u8::from_str_radix(&hex[..2], 16)?;\n        hex = &hex[2..];\n    }\n```","replyTo":null,"isNewFile":"1","line":"31","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/node.rs","diffId":"19323","author":"kevincox","id":"116131","dateCreated":"1579171819","dateModified":"1579171819"},{"type":"inline","comment":"I would recommend making this a proper type because almost no one should be poking at the bytes of the hash.\n\n```\nstruct Node([u8; 20]);\n```\n\nYou can make the field `pub` if necessary.","replyTo":null,"isNewFile":"1","line":"14","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/node.rs","diffId":"19323","author":"kevincox","id":"116130","dateCreated":"1579171819","dateModified":"1579171819"},{"type":"accept","author":"kevincox","id":"116129","dateCreated":"1579171819","dateModified":"1579171819"},{"type":"update","diffId":"19323","author":"gracinet","id":"115983","dateCreated":"1579132023","dateModified":"1579132023"},{"type":"update","diffId":"19037","author":"gracinet","id":"114454","dateCreated":"1578338705","dateModified":"1578338705"}],"dateCreated":"1578338705","dateModified":"1579724876","status":"Needs Review"},{"id":"7972","callsign":"HG","title":"recover: don't verify by default","author":"valentin.gatienbaron","summary":"The reason is:\n- it's not that hard to trigger interrupted transactions: just run out\n  of disk space\n- it takes forever to verify on large repos. Before --no-verify, I\n  told people to C-c hg recover when the progress bar showed up. Now I\n  tell them to pass --no-verify.\n- I don't remember a single case where the verification step was\n  useful\n\nThis is technically a change of behavior. Perhaps this would be better\nsuited for tweakdefaults?","testPlan":"","lineCount":"16","dependsOn":["7971"],"reviewers":[],"ccs":["pulkit","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":"I also have experience with C-c thing. Will a config option which enables `--no-verify` by default will work for you?","author":"pulkit","id":"117156","dateCreated":"1579724038","dateModified":"1579724038"},{"type":"update","diffId":"19520","author":"valentin.gatienbaron","id":"117143","dateCreated":"1579722551","dateModified":"1579722551"}],"dateCreated":"1579722551","dateModified":"1579724038","status":"Needs Review"},{"id":"7971","callsign":"HG","title":"recover: fix typos","author":"valentin.gatienbaron","summary":"","testPlan":"","lineCount":"8","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19519","author":"valentin.gatienbaron","id":"117138","dateCreated":"1579722548","dateModified":"1579722548"}],"dateCreated":"1579722548","dateModified":"1579722551","status":"Needs Review"},{"id":"7794","callsign":"HG","title":"rust-nodemap: generic NodeTreeVisitor","author":"gracinet","summary":"This iterator will help avoid code duplication when we'll\nimplement `insert()`, in which we will need to\ntraverse the node tree, and to remember the visited blocks.\n\nThe iterator converts the three variants of `Element` into the\nboolean `leaf` and `Option<Revision>` instead of just emitting the\nvariant it's seen. The motivation is to avoid a dead match arm\nin the future `insert()`.","testPlan":"","lineCount":"55","dependsOn":["7793"],"reviewers":["kevincox"],"ccs":["martinvonz","durin42","kevincox","mercurial-devel"],"actions":[{"type":"inline","comment":"There will only be a valid result if this is a leaf, so it might be better to combine `leaf` and `opt` into one `Option<Option<Revision>>` so the caller cannot mistake a `opt=None` for \"missing\" when `leaf=false`.","replyTo":null,"isNewFile":"1","line":"264","lineLength":"5","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19327","author":"martinvonz","id":"117136","dateCreated":"1579720724","dateModified":"1579720724"},{"type":"inline","comment":"I would prefer making this a struct so that you can name the fields. You can still pattern match the fields if you want to.","replyTo":null,"isNewFile":"1","line":"254","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19327","author":"kevincox","id":"116113","dateCreated":"1579169804","dateModified":"1579169804"},{"type":"reject","author":"kevincox","id":"116112","dateCreated":"1579169804","dateModified":"1579169804"},{"type":"update","diffId":"19327","author":"gracinet","id":"115987","dateCreated":"1579132062","dateModified":"1579132062"},{"type":"update","diffId":"19043","author":"gracinet","id":"114502","dateCreated":"1578338742","dateModified":"1578338742"}],"dateCreated":"1578338742","dateModified":"1579720724","status":"Needs Revision"},{"id":"7819","callsign":"HG","title":"rust-nodemap: core implementation for shortest","author":"gracinet","summary":"In this implementation, we just make `lookup()` return also the number\nof steps that have been needed to come to a conclusion from the\nnodetree data, and `validate_candidate()` takes care of the special\ncases related to `NULL_NODE`.\n\nThis way of doing minimizes code duplication, but it means that\nthe comparatively slower finding of first non zero nybble will run\nfor all calls to `find()` where it is not needed.\n\nStill running on the file generated for the mozilla-central repository,\nit seems indeed that we now get more ofter 320 ns than 310. The odds that\nthis could have a significant impact on real life Mercurial performance\nare still looking low. Let's wait for actual benchmark runs to see if\nan optimization is needed here.","testPlan":"","lineCount":"153","dependsOn":["7798"],"reviewers":["kevincox"],"ccs":["martinvonz","durin42","kevincox","mercurial-devel"],"actions":[{"type":"inline","comment":"I'm fine with either. We'll expose it as \"shortest\" in the python API anyway, I assume. Feel free to change as far as I'm concerned.","replyTo":"117133","isNewFile":"1","line":"575","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19331","author":"martinvonz","id":"117134","dateCreated":"1579718361","dateModified":"1579718361"},{"type":"inline","comment":"I have personally nothing against this, and actually find this `shortest` not to be clear, but\u2026 it's also the name in the C implementation and the Python API, IIRC.\n\n@martinvonz I see you subscribed, what do you think ?\n\n","replyTo":"116157","isNewFile":"1","line":"575","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19331","author":"gracinet","id":"117133","dateCreated":"1579717731","dateModified":"1579717731"},{"type":"inline","comment":"s\/cand\/candidate\/? I prefer to avoid unusual abbreviations.","replyTo":null,"isNewFile":"1","line":"243","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19331","author":"martinvonz","id":"117131","dateCreated":"1579717365","dateModified":"1579717365"},{"type":"inline","comment":"can the explicit lifetime be dropped?","replyTo":null,"isNewFile":"1","line":"59","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19331","author":"martinvonz","id":"117130","dateCreated":"1579717365","dateModified":"1579717365"},{"type":"inline","comment":"`unique_bin_prefix_len`?","replyTo":null,"isNewFile":"1","line":"766","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19331","author":"kevincox","id":"116158","dateCreated":"1579177496","dateModified":"1579177496"},{"type":"inline","comment":"How about `unique_bin_prefix_len`?","replyTo":null,"isNewFile":"1","line":"575","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19331","author":"kevincox","id":"116157","dateCreated":"1579177496","dateModified":"1579177496"},{"type":"inline","comment":"Can you describe the return value in the doc comment.","replyTo":null,"isNewFile":"1","line":"337","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19331","author":"kevincox","id":"116156","dateCreated":"1579177496","dateModified":"1579177496"},{"type":"accept","author":"kevincox","id":"116155","dateCreated":"1579177496","dateModified":"1579177496"},{"type":"update","diffId":"19331","author":"gracinet","id":"115991","dateCreated":"1579132108","dateModified":"1579132108"},{"type":"update","diffId":"19139","author":"gracinet","id":"115016","dateCreated":"1578668657","dateModified":"1578668657"}],"dateCreated":"1578668657","dateModified":"1579718361","status":"Needs Review"},{"id":"7970","callsign":"HG","title":"crecord: fix a concatenation of bytes and str on py3","author":"spectral","summary":"","testPlan":"","lineCount":"3","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19518","author":"spectral","id":"117125","dateCreated":"1579716273","dateModified":"1579716273"}],"dateCreated":"1579716273","dateModified":"1579716273","status":"Needs Review"},{"id":"7969","callsign":"HG","title":"exchange: check the `ui.clonebundleprefers` form while processing (issue6257)","author":"mharbison72","summary":"Otherwise the clone command will emit a long stacktrace if there is no `=`\ncharacter.","testPlan":"","lineCount":"17","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19517","author":"mharbison72","id":"117119","dateCreated":"1579713297","dateModified":"1579713297"}],"dateCreated":"1579713297","dateModified":"1579713297","status":"Needs Review"},{"id":"7968","callsign":"HG","title":"tests: move non-collapse test out of test-rebase-collapse","author":"martinvonz","summary":"The test case was added in 76630fbbf4fa (test-rebase-collapse: Add\ntest for rebase regression introduced in 12309c09d19a, 2012-01-23). I\nthink `hg rebase --collapse` was involved in either the regression or\nin the fix that caused the regression, but the test that was added\ndoesn't use `--collapse`, so it doesn't seem to belong in\ntest-rebase-collapse.t. The test case is about copies, so I moved it\nto test-rebase-rename.t.","testPlan":"","lineCount":"111","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19516","author":"martinvonz","id":"117112","dateCreated":"1579712841","dateModified":"1579712841"}],"dateCreated":"1579712841","dateModified":"1579712841","status":"Needs Review"},{"id":"7932","callsign":"HG","title":"[RFC]debugbackups: introduce command to interact with strip backups","author":"pulkit","summary":"This vendors backups extension from hg-experimental.\n\nListing backups and having some utility to apply them is nice. I know we have\nobsmarkers now, but this will help a lot of end users who still uses strip until\nwe get evolve out of experimental.\n\nThis is RFC because:\n\n* I am not sure whether we want this in core\n* I copied the code from hg-experimental and looks like there is some code\ndeduplication which needs to be done","testPlan":"","lineCount":"169","dependsOn":[],"reviewers":[],"ccs":["durin42","mercurial-devel"],"actions":[{"type":"comment","comment":"I'm +1 on having this functionality in core, FYI.","author":"durin42","id":"117110","dateCreated":"1579711231","dateModified":"1579711231"},{"type":"update","diffId":"19436","author":"pulkit","id":"116591","dateCreated":"1579285511","dateModified":"1579285511"}],"dateCreated":"1579285511","dateModified":"1579711232","status":"Needs Review"},{"id":"7791","callsign":"HG","title":"rust-nodemap: NodeMap trait with simplest implementor","author":"gracinet","summary":"We're defining here only a small part of the immutable\nmethods it will have at the end. This is so we can\nfocus in the following changesets on the needed abstractions\nfor a mutable append-only serializable version.\n\nThe first implementor exposes the actual lookup\nalgorithm in its simplest form. It will have to be expanded\nto account for the missing methods, and the special cases\nrelated to NULL_NODE.","testPlan":"","lineCount":"181","dependsOn":["7790"],"reviewers":["kevincox"],"ccs":["Alphare","martinvonz","durin42","kevincox","mercurial-devel"],"actions":[{"type":"inline","comment":"How about something like this then?\n\n```\ntype BlockSource = Box<dyn Deref<Target = [Block]> + Send>;\ntype ByteSource = Box<dyn Deref<Target = [u8]> + Send>;\n```\n\nI won't insist, so up to you if you think it helps.","replyTo":"117064","isNewFile":"1","line":"150","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19324","author":"martinvonz","id":"117103","dateCreated":"1579710197","dateModified":"1579710197"},{"type":"inline","comment":"About `Send`, without it we can't expose `NodeTree` to the Python layer, IIRC","replyTo":"117023","isNewFile":"1","line":"150","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19324","author":"gracinet","id":"117065","dateCreated":"1579705816","dateModified":"1579705816"},{"type":"inline","comment":"I've looked into trait alias while working on this, for the exact same reason, and went through most you guys are saying about that.\n\nSeems that this is complicated for the language because they'd like to have the\npossibility to `impl` it.","replyTo":"117022","isNewFile":"1","line":"150","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19324","author":"gracinet","id":"117064","dateCreated":"1579705816","dateModified":"1579705816"},{"type":"inline","comment":">I didn't know about trait aliases, but I think you can already do this:\n> `trait Thing : Deref<Target = [Block]> + Send  {}`\n\nUsing an empty supertrait will not work because fat pointers have different metadata.\nhttps:\/\/play.rust-lang.org\/?version=nightly&mode=debug&edition=2018&gist=4f1d374e426c9791cbf73421160dc7c3\n\n> It's one instance right now. It's 7 instances of Box<dyn Deref<...>> at the end of the series...\n\nAh true, that is indeed verbose, but manageable. Unfortunately, from a language perspective, I think that a type macro would be our only choice, but my opinion is that 1) it's ugly and more code to maintain and 2) I'm not even sure it would work. ","replyTo":"117045","isNewFile":"1","line":"150","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19324","author":"Alphare","id":"117052","dateCreated":"1579686236","dateModified":"1579686236"},{"type":"inline","comment":"> Alas, trait aliases are not stable: rust#55628.\n\nI didn't know about trait aliases, but I think you can already do this:\n\n```\ntrait Thing : Deref<Target = [Block]> + Send  {}\n```\n\n> ... since this is a single occurrence in a private field, I find it reasonable.\n\nIt's one instance right now. It's 7 instances of `Box<dyn Deref<...>>` at the end of the series...","replyTo":"117044","isNewFile":"1","line":"150","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19324","author":"martinvonz","id":"117045","dateCreated":"1579645621","dateModified":"1579645621"},{"type":"inline","comment":"> I find Deref<Target = [Block]> + Send hard to understand. I think it would be helpful to name it. Could we at least define an alias for it?\n\nAlas, trait aliases are not stable: [[ https:\/\/github.com\/rust-lang\/rust\/issues\/55628 | rust#55628 ]]. \n\nOn a more subjective note, I find this syntax quite readable as it is (as readable as Rust usually is), and since this is a single occurrence in a private field, I find it reasonable.\n","replyTo":"117022","isNewFile":"1","line":"150","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19324","author":"Alphare","id":"117044","dateCreated":"1579645035","dateModified":"1579645035"},{"type":"inline","comment":"I understand that you picked this interface because it works well for the caller, but it feel a little weird to always return `None` or `Some(rev)` where `rev` is one of the function inputs. It's practically a boolean-valued function. Do the callers get much harder to read if you actually make it boolean-valued?","replyTo":null,"isNewFile":"1","line":"153","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19324","author":"martinvonz","id":"117024","dateCreated":"1579642974","dateModified":"1579642974"},{"type":"inline","comment":"Do we need `Send`? Maybe it later when you need it (unless you actually need it now and I'm just mistaken, of course).","replyTo":null,"isNewFile":"1","line":"150","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19324","author":"martinvonz","id":"117023","dateCreated":"1579642974","dateModified":"1579642974"},{"type":"inline","comment":"I find `Deref<Target = [Block]> + Send` hard to understand. I think it would be helpful to name it. Could we at least define an alias for it?\n\nPerhaps it's even better to define a trait for it and add named methods on that, but if those methods would just be `len()` and `index()` it probably doesn't make any sense to define the trait.","replyTo":null,"isNewFile":"1","line":"150","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19324","author":"martinvonz","id":"117022","dateCreated":"1579642974","dateModified":"1579642974"},{"type":"inline","comment":"I don't think the `<'_>` is necessary.","replyTo":null,"isNewFile":"1","line":"205","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19324","author":"kevincox","id":"116105","dateCreated":"1579169333","dateModified":"1579169333"},{"type":"inline","comment":"Can you please add doc-comments for this? I find that documenting trait methods is especially important.","replyTo":null,"isNewFile":"1","line":"37","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19324","author":"kevincox","id":"116104","dateCreated":"1579169333","dateModified":"1579169333"},{"type":"accept","author":"kevincox","id":"116103","dateCreated":"1579169333","dateModified":"1579169333"},{"type":"update","diffId":"19324","author":"gracinet","id":"115984","dateCreated":"1579132039","dateModified":"1579132039"},{"type":"update","diffId":"19134","author":"gracinet","id":"115010","dateCreated":"1578668607","dateModified":"1578668607"},{"type":"update","diffId":"19040","author":"gracinet","id":"114478","dateCreated":"1578338723","dateModified":"1578338723"}],"dateCreated":"1578338723","dateModified":"1579710197","status":"Needs Review"},{"id":"7898","callsign":"HG","title":"merge: don't call update hook when using in-memory context","author":"martinvonz","summary":"I'm pretty sure many hook implementors will assume that they can\ninspect the working copy and\/or dirstate parents when the hook is\ncalled, so I don't think we should call the hook when using an\nin-memory context. The new behavior matches that of the preupdate\nhook.","testPlan":"","lineCount":"2","dependsOn":[],"reviewers":[],"ccs":["pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D7898#117079, @pulkit wrote:\n> Do we have user-facing documentation for these behavior? I tried to find documentation related to hooks but was unable to find any.\n\nYes, `hg help config.hooks`. But even without reading that, it seems pretty obvious to me that we shouldn't run the \"update\" hook when not updating the working copy.","author":"martinvonz","id":"117102","dateCreated":"1579709749","dateModified":"1579709749"},{"type":"comment","comment":"Do we have user-facing documentation for these behavior? I tried to find documentation related to hooks but was unable to find any.","author":"pulkit","id":"117079","dateCreated":"1579707080","dateModified":"1579707080"},{"type":"update","diffId":"19334","author":"martinvonz","id":"116011","dateCreated":"1579137672","dateModified":"1579137672"}],"dateCreated":"1579137672","dateModified":"1579709749","status":"Needs Review"},{"id":"7787","callsign":"HG","title":"rust-nodemap: building blocks for nodetree structures","author":"gracinet","summary":"This is similar to `nodetreenode` in `revlog.c`. We give it\na higher level feeling for ease of handling in Rust context\nand provide tools for tests and debugging.\n\nThe encoding choice is dictated by our ultimate goal in this\nseries, that is to make an append-only persistent version of\n`nodetree`: the 0th Block must be adressed from other Blocks.","testPlan":"","lineCount":"162","dependsOn":[],"reviewers":["kevincox"],"ccs":["martinvonz","durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19504","author":"gracinet","id":"117083","dateCreated":"1579707730","dateModified":"1579707730"},{"type":"comment","comment":"These are done, thanks for the remarks.","author":"gracinet","id":"117082","dateCreated":"1579707272","dateModified":"1579707272"},{"type":"update","diffId":"19503","author":"gracinet","id":"117080","dateCreated":"1579707244","dateModified":"1579707244"},{"type":"inline","comment":"yes, and valency is actually almost incorrect actually in that case, it turns out","replyTo":"116937","isNewFile":"1","line":"8","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19322","author":"gracinet","id":"117062","dateCreated":"1579704793","dateModified":"1579704793"},{"type":"inline","comment":"right, I've must have spent too much of my life using XML libraries, I suppose ;-)","replyTo":"116938","isNewFile":"1","line":"96","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19322","author":"gracinet","id":"117060","dateCreated":"1579704727","dateModified":"1579704727"},{"type":"comment","comment":"@martinvonz \n\n> Just a few nits here, but it looks like we're expecting an update on this series anyway, so maybe you can address them.\n\nNo problem with these. I'll be doing a swipe on the whole series today and will include them.","author":"gracinet","id":"117059","dateCreated":"1579704727","dateModified":"1579704727"},{"type":"inline","comment":"Could you call it `element` instead? I think it's a little obvious what that means. `elt` is at least not an abbreviation I'm familiar with.","replyTo":null,"isNewFile":"1","line":"96","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19322","author":"martinvonz","id":"116938","dateCreated":"1579629724","dateModified":"1579629724"},{"type":"inline","comment":"i think s\/valency\/arity\/ is a more common term for it","replyTo":null,"isNewFile":"1","line":"8","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19322","author":"martinvonz","id":"116937","dateCreated":"1579629724","dateModified":"1579629724"},{"type":"inline","comment":"s\/endianity\/endianness\/ (same further down)","replyTo":null,"isNewFile":"1","line":"36","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19322","author":"martinvonz","id":"116936","dateCreated":"1579629724","dateModified":"1579629724"},{"type":"comment","comment":"Just a few nits here, but it looks like we're expecting an update on this series anyway, so maybe you can address them.","author":"martinvonz","id":"116935","dateCreated":"1579629724","dateModified":"1579629724"},{"type":"inline","comment":"So, that gives formatting with braces, hence for consistency I changed the `block!` macro, too.\n\nI didn't keep the hexadecimal formatting, because it'd now lead to lots of `\\\"` making the tests less readable. \n\nAn upside of this is that it's now really consistent with `block!`. A downside is that someone using it for real debugging with input given in hexadecimal would presumably have to mentally convert hexadecimal nybbles to their decimal form.\nIt would have been a bit of a drag in the intiial development effort, but I don't think\nthat'll be a problem in the future: : either it'll be on small data or with diffrent tools anyway.\n\n","replyTo":"115819","isNewFile":"1","line":"111","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19133","author":"gracinet","id":"115993","dateCreated":"1579132558","dateModified":"1579132558"},{"type":"update","diffId":"19322","author":"gracinet","id":"115982","dateCreated":"1579132016","dateModified":"1579132016"},{"type":"inline","comment":"Nice, thanks for the tip","replyTo":"115814","isNewFile":"1","line":"111","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19133","author":"gracinet","id":"115819","dateCreated":"1579097959","dateModified":"1579097959"},{"type":"inline","comment":"Yes, I suppose `read` and `write` feel like I\/O. Will do.","replyTo":"115813","isNewFile":"1","line":"92","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19133","author":"gracinet","id":"115818","dateCreated":"1579097959","dateModified":"1579097959"},{"type":"comment","comment":"@kevincox thanks for the review!","author":"gracinet","id":"115817","dateCreated":"1579097959","dateModified":"1579097959"},{"type":"inline","comment":"You can use this helper: https:\/\/doc.rust-lang.org\/std\/fmt\/struct.Formatter.html#method.debug_map","replyTo":null,"isNewFile":"1","line":"111","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19133","author":"kevincox","id":"115814","dateCreated":"1579096943","dateModified":"1579096943"},{"type":"inline","comment":"I would call these `get` and `set`. ","replyTo":null,"isNewFile":"1","line":"92","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19133","author":"kevincox","id":"115813","dateCreated":"1579096943","dateModified":"1579096943"},{"type":"accept","author":"kevincox","id":"115812","dateCreated":"1579096943","dateModified":"1579096943"},{"type":"update","diffId":"19133","author":"gracinet","id":"115009","dateCreated":"1578668584","dateModified":"1578668584"},{"type":"update","diffId":"19036","author":"gracinet","id":"114448","dateCreated":"1578338699","dateModified":"1578338699"}],"dateCreated":"1578338699","dateModified":"1579707730","status":"Needs Review"},{"id":"7967","callsign":"HG","title":"exchange: recognize changegroup3 bundles in `getbundlespec()`","author":"mharbison72","summary":"Previously, `hg bundle --spec $bundle` complained that changegroup3 didn't have\na known bundlespec and suggested upgrading the client, even if the same binary\ngenerated the bundle.","testPlan":"","lineCount":"28","dependsOn":[],"reviewers":[],"ccs":["marmoute","pulkit","joerg.sonnenberger","mercurial-devel"],"actions":[{"type":"inline","comment":"I\u2019m not sure now. I think I went this way because I\u2019m pretty sure it complained when I tried to generate a bzip2-v3 bundle.  And since 01 is mapped to v2 and the error message is talking about finding a bundlespec, it seemed like v2 was the only option.  But maybe something is missing elsewhere too.  @marmoute?","replyTo":"117054","isNewFile":"1","line":"321","lineLength":"0","path":"mercurial\/exchange.py","diffId":"19502","author":"mharbison72","id":"117057","dateCreated":"1579698258","dateModified":"1579698258"},{"type":"inline","comment":"Should not this be `v3`? I believe this is what @joerg.sonnenberger is also trying to point out on IRC.","replyTo":null,"isNewFile":"1","line":"321","lineLength":"0","path":"mercurial\/exchange.py","diffId":"19502","author":"pulkit","id":"117054","dateCreated":"1579697239","dateModified":"1579697239"},{"type":"update","diffId":"19502","author":"mharbison72","id":"117047","dateCreated":"1579649502","dateModified":"1579649502"}],"dateCreated":"1579649502","dateModified":"1579698258","status":"Needs Review"},{"id":"7966","callsign":"HG","title":"remotefilelog: only prefetch history in linkrevfixup","author":"pulkit","summary":"The linknode is part of the history, not the data, no need to force prefetch\nthe blobs.\n\nThe commit is copied from\nhttps:\/\/github.com\/facebookexperimental\/eden\/commit\/03b66077798c33d7acc2d39ce6496d919bd7d11c","testPlan":"","lineCount":"4","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19500","author":"pulkit","id":"117033","dateCreated":"1579643946","dateModified":"1579643946"}],"dateCreated":"1579643946","dateModified":"1579643946","status":"Needs Review"},{"id":"6734","callsign":"HG","title":"git: RFC of a new extension to _directly_ operate on git repositories","author":"durin42","summary":"This is _extremely_ rough, but I feel like it's a worthwhile proof of\nconcept to help us push interfaces in the direction required to just\nmake this work for real.\n\nThis is based in part of work I did years ago in hgit, but it's mostly\nnew code since I'm using pygit2 instead of dulwich and the hg storage\ninterfaces have improved. Some cleanup of old hgit code by Pulkit,\nwhich I greatly appreciate.\n\ntest-git-interop.t does not cover a whole lot of cases, but it\npasses. It includes status, diff, making a new commit, and `hg\nannotate` working on the git repository.\n\nThis is _not_ production quality code: this is an experimental hack to\ntry and push us towards this approach over the hg-git approach. Known\ntechnical debt lurking in this implementation:\n\n * Writing bookmarks just totally ignores transactions.\n * Manifest recursion is probably wrong.\n * Manifest writing should be cleaned up to split mutable and\n   immutable manifest contexts.\n * The way progress is threaded down into the gitstore is awful.\n * Ideally we'd find a way to incrementally reindex DAGs. I'm not sure\n   how to do that efficiently, so we might need a \"known only fast-forwards\"\n   mode on the DAG indexer for use on `hg commit` and friends.\n\nTests currently require git 2.24 as far as I'm aware: `git status` has\nsome changed output that I didn't try and handle in a compatible way.","testPlan":"","lineCount":"1672","dependsOn":[],"reviewers":[],"ccs":["tom.prince","sheehan","rom1dep","JordiGH","hollisb","mjpieters","mercurial-devel"],"actions":[{"type":"update","diffId":"18757","author":"durin42","id":"112766","dateCreated":"1576530296","dateModified":"1576530296"},{"type":"update","diffId":"18756","author":"durin42","id":"112764","dateCreated":"1576529162","dateModified":"1576529162"},{"type":"update","diffId":"17007","author":"durin42","id":"103275","dateCreated":"1570656534","dateModified":"1570656534"},{"type":"update","diffId":"16858","author":"durin42","id":"102404","dateCreated":"1570307321","dateModified":"1570307321"},{"type":"update","diffId":"16714","author":"durin42","id":"101589","dateCreated":"1569883603","dateModified":"1569883603"},{"type":"update","diffId":"16704","author":"durin42","id":"101527","dateCreated":"1569873515","dateModified":"1569873515"},{"type":"update","diffId":"16622","author":"durin42","id":"101068","dateCreated":"1569449675","dateModified":"1569449675"},{"type":"update","diffId":"16554","author":"durin42","id":"100646","dateCreated":"1568644017","dateModified":"1568644017"},{"type":"update","diffId":"16525","author":"durin42","id":"100466","dateCreated":"1568325121","dateModified":"1568325121"},{"type":"update","diffId":"16387","author":"durin42","id":"99617","dateCreated":"1567711232","dateModified":"1567711232"},{"type":"update","diffId":"16293","author":"durin42","id":"99134","dateCreated":"1566482645","dateModified":"1566482645"},{"type":"update","diffId":"16228","author":"durin42","id":"98813","dateCreated":"1565988863","dateModified":"1565988863"}],"dateCreated":"1565988863","dateModified":"1579643248","status":"Needs Review"},{"id":"7965","callsign":"HG","title":"py3: catch AttributeError too with ImportError","author":"pulkit","summary":"Looks like py3 raises AttributeError instead of ImportError. This is caught on\nwindows.","testPlan":"","lineCount":"8","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19499","author":"pulkit","id":"117026","dateCreated":"1579643245","dateModified":"1579643245"}],"dateCreated":"1579643245","dateModified":"1579643245","status":"Needs Review"},{"id":"7962","callsign":"HG","title":"lfs: fix the stall and corruption issue when concurrently uploading blobs","author":"mharbison72","summary":"We've avoided the issue up to this point by gating worker usage with an\nexperimental config.  See 10e62d5efa73, and the thread linked there for some of\nthe initial diagnosis, but essentially some data was being read from the blob\nbefore an error occurred and `keepalive` retried, but didn't rewind the file\npointer.  So the leading data was lost from the blob on the server, and the\nconnection stalled, trying to send more data than available.\n\nIn trying to recreate this, I was unable to do so uploading from Windows to\nCentOS 7.  But it reproduced every time going from CentOS 7 to another CentOS 7\nover https.\n\nI found recent fixes in the FaceBook repo to address this[1][2].  The commit\nmessage for the first is:\n\n    The KeepAlive HTTP implementation is bugged in it's retry logic, it supports\n    reading from a file pointer, but doesn't support rewinding of the seek cursor\n    when it performs a retry. So it can happen that an upload fails for whatever\n    reason and will then 'hang' on the retry event.\n\n    The sequence of events that get triggered are:\n     - Upload file A, goes OK. Keep-Alive caches connection.\n     - Upload file B, fails due to (for example) failing Keep-Alive, but LFS file\n       pointer has been consumed for the upload and fd has been closed.\n     - Retry for file B starts, sets the Content-Length properly to the expected\n       file size, but since file pointer has been consumed no data will be uploaded,\n       causing the server to wait for the uploaded data until either client or\n       server reaches a timeout, making it seem as our mercurial process hangs.\n\n    This is just a stop-gap measure to prevent this behavior from blocking Mercurial\n    (LFS has retry logic). A proper solutions need to be build on top of this\n    stop-gap measure: for upload from file pointers, we should support fseek() on\n    the interface. Since we expect to consume the whole file always anyways, this\n    should be safe. This way we can seek back to the beginning on a retry.\n\nI ported those two patches, and it works.  But I see that `url._sendfile()` does\na rewind on `httpsendfile` objects[3], so maybe it's better to keep this all in\none place and avoid a second seek.  We may still want the first FaceBook patch\nas extra protection for this problem in general.  The other two uses of\n`httpsendfile` are in the wire protocol to upload bundles, and to upload\nlargefiles.  Neither of these appear to use a worker, and I'm not sure why\nworkers seem to trigger this, or if this could have happened without a worker.\n\nSince `httpsendfile` already has a `close()` method, that is dropped.  That\nclass also explicitly says there's no `__len__` attribute, so that is removed\ntoo.  The override for `read()` is necessary to avoid the progressbar usage per\nfile.\n\n[1] https:\/\/github.com\/facebookexperimental\/eden\/commit\/c350d6536d90c044c837abdd3675185644481469\n[2] https:\/\/github.com\/facebookexperimental\/eden\/commit\/77f0d3fd0415e81b63e317e457af9c55c46103ee\n[3] https:\/\/www.mercurial-scm.org\/repo\/hg\/file\/5.2.2\/mercurial\/url.py#l176","testPlan":"","lineCount":"31","dependsOn":["7961"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"Even though this talks about fixing corruption, I don't *think* we need this in the next release.  We've lived with this problem for 2 years now.  But somebody who really understands how all of the URL request handling and keepalive stuff works should probably take a look before then.  I still don't know that this *can't* happen without using workers (or if it is possible in other usage contexts), so we may still want to shore things up there.","author":"mharbison72","id":"117011","dateCreated":"1579632210","dateModified":"1579632210"},{"type":"update","diffId":"19496","author":"mharbison72","id":"116995","dateCreated":"1579631878","dateModified":"1579631878"}],"dateCreated":"1579631878","dateModified":"1579632210","status":"Needs Review"},{"id":"7963","callsign":"HG","title":"lfs: enable workers by default","author":"mharbison72","summary":"With the stall issue seemingly fixed, there's no reason not to use workers.  The\nsetting is left for now to keep the test output deterministic, and in case other\nissues come up.  If none do, this can be converted to a developer setting for\nusage with the tests.","testPlan":"","lineCount":"9","dependsOn":["7962"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19497","author":"mharbison72","id":"117004","dateCreated":"1579631882","dateModified":"1579631882"}],"dateCreated":"1579631882","dateModified":"1579631883","status":"Needs Review"},{"id":"7961","callsign":"HG","title":"lfs: add a method to the local blobstore to convert OIDs to file paths","author":"mharbison72","summary":"This is less ugly than passing an open callback to the `httpsendfile`\nconstuctor.","testPlan":"","lineCount":"15","dependsOn":["7960"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19495","author":"mharbison72","id":"116987","dateCreated":"1579631875","dateModified":"1579631875"}],"dateCreated":"1579631875","dateModified":"1579631878","status":"Needs Review"},{"id":"7960","callsign":"HG","title":"httpconnection: allow `httpsendfile` subclasses to suppress the progressbar","author":"mharbison72","summary":"This will be neccessary for LFS, which manages the progressbar outside of the\nfile.","testPlan":"","lineCount":"5","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19494","author":"mharbison72","id":"116979","dateCreated":"1579631871","dateModified":"1579631871"}],"dateCreated":"1579631871","dateModified":"1579631875","status":"Needs Review"},{"id":"7789","callsign":"HG","title":"rust-revlog: a trait for the revlog index","author":"gracinet","summary":"As explained in the doc comment, this is the minimum needed\nfor our immediate concern, which is to implement a nodemap\nin Rust.\n\nThe trait will be later implemented in `hg-cpython` by the\nindex Python object implemented in C, thanks to exposition\nof the corresponding functions as a capsule.\n\nThe `None` return cases in `node()` match what the `index_node()`\nC function does.","testPlan":"","lineCount":"12","dependsOn":["7788"],"reviewers":["martinvonz"],"ccs":["martinvonz","durin42","kevincox","mercurial-devel"],"actions":[{"type":"reject","author":"martinvonz","id":"116939","dateCreated":"1579629794","dateModified":"1579629794"},{"type":"comment","comment":"> The None return cases in node() match what the index_node()\n> C function does.\n\nYou mean the code on https:\/\/www.mercurial-scm.org\/repo\/hg\/file\/fdaa4233dc18\/mercurial\/cext\/revlog.c#l388? Line 394 there returns nullid, so does that really match? Why not return the nullid when given nullrev as input?","author":"martinvonz","id":"116628","dateCreated":"1579311057","dateModified":"1579311057"},{"type":"update","diffId":"19038","author":"gracinet","id":"114462","dateCreated":"1578338711","dateModified":"1578338711"}],"dateCreated":"1578338711","dateModified":"1579629794","status":"Needs Revision"},{"id":"7790","callsign":"HG","title":"rust-node: handling binary Node prefix","author":"gracinet","summary":"Parallel to the inner signatures of the nodetree functions in\nrevlog.c, we'll have to handle prefixes of `Node` in binary\nform.\n\nThere's a complication due to the fact that we'll be sometimes\ninterested in prefixes with an odd number of hexadecimal digits,\nwhich translates in binary form by a last byte in which only the\nhighest weight 4 bits are considered.\n\nThere are a few candidates for inlining here, but we refrain from\nsuch premature optimizations, letting the compiler decide.","testPlan":"","lineCount":"149","dependsOn":["7789"],"reviewers":[],"ccs":["martinvonz","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D7790#116757, @gracinet wrote:\n> @martinvonz in this code, we're in competition with the C implementation, which does something similar.\n> \n> Switching to a full u8 per nybble is more than a few minutes, it means changing the ownership model completely. Also, it introduces a new allocation and a copy instead of merely taking a reference.\n\nDepends on the definition of `NodePrefixRef`. I don't think there would be any extra allocation if you define it like this:\n\n```\npub enum NodePrefixRef<'a> {\n    Full(&'a Node),\n    Prefix(&'a NodePrefix),\n}\n```\n\n> \n> So, it's more work and has performance impact that we have no means to measure. \n> \n> The odd\/even thing is not *that* complicated. It's very bad for readability in the C code, but it's nicely encapsulated in the Rust case and fully tested. I'd be more comfortable trying what you're suggesting once we have real-life measurements.\n\nSure, please revisit it when you can do measurements.","author":"martinvonz","id":"116933","dateCreated":"1579629357","dateModified":"1579629357"},{"type":"inline","comment":"Why not use `(len + 1) \/ 2` as capacity?","replyTo":null,"isNewFile":"1","line":"79","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/node.rs","diffId":"19039","author":"martinvonz","id":"116932","dateCreated":"1579629336","dateModified":"1579629336"},{"type":"inline","comment":"What does the `&*` do? Specifically, what's different if you drop that part?","replyTo":null,"isNewFile":"1","line":"136","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/node.rs","diffId":"19039","author":"martinvonz","id":"116931","dateCreated":"1579629336","dateModified":"1579629336"},{"type":"inline","comment":"Is this lifetime parameter needed?","replyTo":null,"isNewFile":"1","line":"89","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/node.rs","diffId":"19039","author":"martinvonz","id":"116930","dateCreated":"1579629336","dateModified":"1579629336"},{"type":"comment","comment":"@martinvonz in this code, we're in competition with the C implementation, which does something similar.\n\nSwitching to a full u8 per nybble is more than a few minutes, it means changing the ownership model completely. Also, it introduces a new allocation and a copy instead of merely taking a reference.\n\nSo, it's more work and has performance impact that we have no means to measure. \n\nThe odd\/even thing is not *that* complicated. It's very bad for readability in the C code, but it's nicely encapsulated in the Rust case and fully tested. I'd be more comfortable trying what you're suggesting once we have real-life measurements.","author":"gracinet","id":"116757","dateCreated":"1579526723","dateModified":"1579526723"},{"type":"inline","comment":"Did you consider using a full u8 for each nibble instead? It seems like that would be simpler. I'd appreciate it if you could spend a few minutes to try that (if you haven't already).","replyTo":null,"isNewFile":"1","line":"62","lineLength":"2","path":"rust\/hg-core\/src\/revlog\/node.rs","diffId":"19039","author":"martinvonz","id":"116638","dateCreated":"1579320986","dateModified":"1579320986"},{"type":"update","diffId":"19039","author":"gracinet","id":"114470","dateCreated":"1578338717","dateModified":"1578338717"}],"dateCreated":"1578338717","dateModified":"1579629357","status":"Needs Review"},{"id":"7944","callsign":"HG","title":"localrepo: handle ValueError during repository opening","author":"indygreg","summary":"Python 3.8 can raise ValueError on attempt of an I\/O operation\nagainst an illegal path. This was causing test-remotefilelog-gc.t\nto fail on Python 3.8.\n\nThis commit teaches repository opening to handle ValueError\nand re-raise an Abort on failure.\n\nAn arguably better solution would be to implement this logic\nin the vfs layer. But that seems like a bag of worms and I don't\nwant to go down that rabbit hole. Until users report uncaught\nValueError exceptions in the wild, I think it is fine to patch\nthis at the only occurrence our test harness is finding it.","testPlan":"","lineCount":"5","dependsOn":["7942"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19448","author":"indygreg","id":"116692","dateCreated":"1579382304","dateModified":"1579382304"}],"dateCreated":"1579382304","dateModified":"1579614802","status":"Needs Review"},{"id":"7942","callsign":"HG","title":"py3: make test-http-bad-server.t conditional on Python 3.6+","author":"indygreg","summary":"I'm not sure what's going on here, but we need to limit these lines\nto a Python 3.6 version range check because Python 3.5's behavior\nis subtly different. We already had some lines conditional on\nPython 3.5+ and 3.6+. I guess whoever made this test pass on 3.6+\nforgot to test on 3.5+.\n\nWith this change, the test harness is clean on Python 3.5 on Linux\non my machine.","testPlan":"","lineCount":"10","dependsOn":["7941"],"reviewers":["pulkit"],"ccs":["mjpieters","mercurial-devel"],"actions":[{"type":"accept","author":"pulkit","id":"116764","dateCreated":"1579528946","dateModified":"1579528946"},{"type":"update","diffId":"19446","author":"indygreg","id":"116676","dateCreated":"1579333363","dateModified":"1579333363"}],"dateCreated":"1579333363","dateModified":"1579614802","status":"Accepted"},{"id":"7869","callsign":"HG","title":"rust-dirs-multiset: add `DirsChildrenMultiset`","author":"Alphare","summary":"In a future patch, this structure will be needed to store information needed by\nthe (also upcoming) `IgnoreMatcher`.","testPlan":"","lineCount":"163","dependsOn":["7866"],"reviewers":["kevincox"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19383","author":"Alphare","id":"116317","dateCreated":"1579211410","dateModified":"1579211410"},{"type":"update","diffId":"19358","author":"Alphare","id":"116163","dateCreated":"1579178927","dateModified":"1579178927"},{"type":"inline","comment":"\"suffix\" isn't clear to me. Maybe `split_dir_from_file`? That's a bit wordy but I feel that it gets the point across. Or `split_file_name`.","replyTo":null,"isNewFile":"1","line":"197","lineLength":"0","path":"rust\/hg-core\/src\/utils\/hg_path.rs","diffId":"19319","author":"kevincox","id":"116162","dateCreated":"1579178812","dateModified":"1579178812"},{"type":"accept","author":"kevincox","id":"116161","dateCreated":"1579178812","dateModified":"1579178812"},{"type":"update","diffId":"19353","author":"Alphare","id":"116118","dateCreated":"1579170125","dateModified":"1579170125"},{"type":"update","diffId":"19319","author":"Alphare","id":"115974","dateCreated":"1579125363","dateModified":"1579125363"},{"type":"inline","comment":"This should probably be a helper on `HgPath`? It would be much easier to understand what it is doing if it had a name.","replyTo":null,"isNewFile":"1","line":"86","lineLength":"0","path":"rust\/hg-core\/src\/utils\/files.rs","diffId":"19261","author":"kevincox","id":"115933","dateCreated":"1579100779","dateModified":"1579100779"},{"type":"inline","comment":"I would put this check into a helper function.","replyTo":null,"isNewFile":"1","line":"170","lineLength":"0","path":"rust\/hg-core\/src\/dirstate\/dirs_multiset.rs","diffId":"19261","author":"kevincox","id":"115932","dateCreated":"1579100779","dateModified":"1579100779"},{"type":"accept","author":"kevincox","id":"115931","dateCreated":"1579100779","dateModified":"1579100779"},{"type":"update","diffId":"19261","author":"Alphare","id":"115623","dateCreated":"1579023229","dateModified":"1579023229"}],"dateCreated":"1579023229","dateModified":"1579614588","status":"Needs Review"},{"id":"7866","callsign":"HG","title":"rust-pathauditor: add Rust implementation of the `pathauditor`","author":"Alphare","summary":"It does not offer the same flexibility as the Python implementation, but\nshould check incoming paths just as well.","testPlan":"","lineCount":"401","dependsOn":[],"reviewers":["kevincox"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19351","author":"Alphare","id":"116116","dateCreated":"1579170108","dateModified":"1579170108"},{"type":"update","diffId":"19317","author":"Alphare","id":"115972","dateCreated":"1579125346","dateModified":"1579125346"},{"type":"inline","comment":"I think that's a good idea indeed, but I would prefer to do it in another patch.","replyTo":"115939","isNewFile":"1","line":"54","lineLength":"0","path":"rust\/hg-core\/src\/utils\/path_auditor.rs","diffId":"19258","author":"Alphare","id":"115966","dateCreated":"1579122338","dateModified":"1579122338"},{"type":"inline","comment":"You can just use https:\/\/doc.rust-lang.org\/std\/primitive.u8.html#method.is_ascii_digit","replyTo":null,"isNewFile":"1","line":"72","lineLength":"0","path":"rust\/hg-core\/src\/utils\/path_auditor.rs","diffId":"19258","author":"kevincox","id":"115941","dateCreated":"1579104460","dateModified":"1579104460"},{"type":"inline","comment":"Should this be `std::path::is_separator(*c as char)`?.\n\nIf not please add a comment explaining why.","replyTo":null,"isNewFile":"1","line":"53","lineLength":"0","path":"rust\/hg-core\/src\/utils\/path_auditor.rs","diffId":"19258","author":"kevincox","id":"115940","dateCreated":"1579104460","dateModified":"1579104460"},{"type":"inline","comment":"It would be nice to have this in a helper function in path to get a component iterator.","replyTo":null,"isNewFile":"1","line":"54","lineLength":"0","path":"rust\/hg-core\/src\/utils\/path_auditor.rs","diffId":"19258","author":"kevincox","id":"115939","dateCreated":"1579104460","dateModified":"1579104460"},{"type":"accept","author":"kevincox","id":"115938","dateCreated":"1579104460","dateModified":"1579104460"},{"type":"update","diffId":"19258","author":"Alphare","id":"115599","dateCreated":"1579023206","dateModified":"1579023206"}],"dateCreated":"1579023206","dateModified":"1579614588","status":"Needs Review"},{"id":"7887","callsign":"HG","title":"nodemap: add a flag to dump the details of the docket","author":"marmoute","summary":"We are about to add more information to the docket. We first introduce a way to\ndebug its content.","testPlan":"","lineCount":"19","dependsOn":["7886"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19432","author":"marmoute","id":"116586","dateCreated":"1579284434","dateModified":"1579284434"},{"type":"update","diffId":"19305","author":"marmoute","id":"115861","dateCreated":"1579100151","dateModified":"1579100151"}],"dateCreated":"1579100151","dateModified":"1579614587","status":"Needs Review"},{"id":"7867","callsign":"HG","title":"rust-hg-path: add useful methods to `HgPath`","author":"Alphare","summary":"This changeset introduces the use of the `pretty_assertions` crate for easier\nto read test output.","testPlan":"","lineCount":"123","dependsOn":["7866"],"reviewers":["kevincox","pulkit"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"accept","author":"pulkit","id":"116819","dateCreated":"1579608523","dateModified":"1579608523"},{"type":"accept","author":"kevincox","id":"116402","dateCreated":"1579254243","dateModified":"1579254243"},{"type":"update","diffId":"19382","author":"Alphare","id":"116315","dateCreated":"1579211395","dateModified":"1579211395"},{"type":"inline","comment":"Fair enough.","replyTo":"116216","isNewFile":"1","line":"169","lineLength":"0","path":"rust\/hg-core\/src\/utils\/hg_path.rs","diffId":"19352","author":"Alphare","id":"116267","dateCreated":"1579198941","dateModified":"1579198941"},{"type":"inline","comment":"I don't think we should have this method. It provides us no way to ensure that the invariants of this type are upheld. It is slightly more typing but I think we should recommend converting to a slice, doing the mutation, then converting back to `HgPath` then we can at least to validation (possibly only in debug builds) in the constructor.","replyTo":null,"isNewFile":"1","line":"169","lineLength":"0","path":"rust\/hg-core\/src\/utils\/hg_path.rs","diffId":"19352","author":"kevincox","id":"116216","dateCreated":"1579189895","dateModified":"1579189895"},{"type":"reject","author":"kevincox","id":"116215","dateCreated":"1579189895","dateModified":"1579189895"},{"type":"update","diffId":"19352","author":"Alphare","id":"116117","dateCreated":"1579170114","dateModified":"1579170114"},{"type":"accept","author":"kevincox","id":"116101","dateCreated":"1579168806","dateModified":"1579168806"},{"type":"update","diffId":"19318","author":"Alphare","id":"115973","dateCreated":"1579125352","dateModified":"1579125352"},{"type":"inline","comment":"It would be nice to have a `trim_trailing_slash` helper.","replyTo":null,"isNewFile":"1","line":"189","lineLength":"0","path":"rust\/hg-core\/src\/utils\/hg_path.rs","diffId":"19259","author":"kevincox","id":"115930","dateCreated":"1579100383","dateModified":"1579100383"},{"type":"accept","author":"kevincox","id":"115929","dateCreated":"1579100383","dateModified":"1579100383"},{"type":"update","diffId":"19259","author":"Alphare","id":"115607","dateCreated":"1579023213","dateModified":"1579023213"}],"dateCreated":"1579023213","dateModified":"1579608523","status":"Accepted"},{"id":"7937","callsign":"HG","title":"python-zstandard: blacken at 80 characters","author":"indygreg","summary":"I made this change upstream and it will make it into the next\nrelease of python-zstandard. I figured I'd send it Mercurial's\nway because it will allow us to drop this directory from the black\nexclusion list.\n\n# skip-blame blackening","testPlan":"","lineCount":"717","dependsOn":[],"reviewers":["mharbison72"],"ccs":["mharbison72","mercurial-devel"],"actions":[{"type":"comment","comment":"\"contrib\/examples\/fix.hgrc\" also skips \"contrib\/python-zstandard\/**\".  It seems like the intent of this is to allow local edits to python-zstandard (or we wouldn't start checking the format), so maybe it should be covered by fix too?","author":"mharbison72","id":"116778","dateCreated":"1579534127","dateModified":"1579534127"},{"type":"reject","author":"mharbison72","id":"116777","dateCreated":"1579534127","dateModified":"1579534127"},{"type":"update","diffId":"19441","author":"indygreg","id":"116640","dateCreated":"1579326846","dateModified":"1579326846"}],"dateCreated":"1579326846","dateModified":"1579534127","status":"Needs Revision"},{"id":"7940","callsign":"HG","title":"py3: make flush() line optional","author":"indygreg","summary":"This line only appears on Python 3.5, not on 2.7 or 3.6+. Why, I have\nno clue. I suspect a weird regression in the bowels of Python's\nI\/O system.\n\nOur test format doesn't support combining conditionals. So I add\npyexactXY checks to check for an exact major.minor Python version.\nSadly, this won't be the only test requiring an exception for\nPython 3.5.","testPlan":"","lineCount":"12","dependsOn":[],"reviewers":["pulkit"],"ccs":["mercurial-devel"],"actions":[{"type":"inline","comment":"Reviewing later patches, I see that `(py3 no-py3.6)` can be used for this.","replyTo":null,"isNewFile":"1","line":"114","lineLength":"0","path":"tests\/test-ssh-proto.t","diffId":"19444","author":"pulkit","id":"116766","dateCreated":"1579529000","dateModified":"1579529000"},{"type":"accept","author":"pulkit","id":"116758","dateCreated":"1579528720","dateModified":"1579528720"},{"type":"update","diffId":"19444","author":"indygreg","id":"116660","dateCreated":"1579333360","dateModified":"1579333360"}],"dateCreated":"1579333360","dateModified":"1579529000","status":"Accepted"},{"id":"7941","callsign":"HG","title":"py3: wallpaper over demand importer differences on Python 3.5","author":"indygreg","summary":"For some reason, Python 3.5 and only Python 3.5's demand importer\nis importing extra parent modules. This is causing test output\non 3.5 to diverge.\n\nWhile I'm not thrilled about the divergence in behavior, I don't\nthink it is critical enough to warrant fixing in code. So this\ncommit teaches our test to recognize the divergent behavior on\nPython 3.5.\n\nBecause the test format doesn't support conditional exit codes and\nwe were already inside an #if (it also doesn't allow nested #ifs),\nI added a `|| false` to normalize the exit code. The actual exit\ncode shouldn't matter here, as we have tests for that elsewhere.","testPlan":"","lineCount":"46","dependsOn":["7940"],"reviewers":["pulkit"],"ccs":["pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"> I added a `|| false` to normalize the exit code.\ns\/false\/true in flight\n\n","author":"pulkit","id":"116762","dateCreated":"1579528891","dateModified":"1579528891"},{"type":"accept","author":"pulkit","id":"116761","dateCreated":"1579528891","dateModified":"1579528891"},{"type":"update","diffId":"19445","author":"indygreg","id":"116668","dateCreated":"1579333362","dateModified":"1579333362"}],"dateCreated":"1579333362","dateModified":"1579528891","status":"Accepted"},{"id":"7914","callsign":"HG","title":"rust-matchers: implement `visit_children_set` for `FileMatcher`","author":"Alphare","summary":"As per the removed inline comment, this will become useful in a future patch\nin this series as the `IncludeMatcher` is introduced.","testPlan":"","lineCount":"152","dependsOn":["7910"],"reviewers":[],"ccs":["martinvonz","durin42","kevincox","mercurial-devel"],"actions":[{"type":"inline","comment":"Alphare pointed out to me out of band that the Python code already does the same, so I agree that it makes sense to just copy that for now. I'm sorry that I didn't think of checking that before. It would have been even better to fix the Python version first and then copy the good code to Rust, but I'm still fine with doing that later.\n\nPS. I haven't actually reviewed this code. I'll do that next week (and Monday is a holiday for me).","replyTo":"116575","isNewFile":"1","line":"166","lineLength":"0","path":"rust\/hg-core\/src\/matchers.rs","diffId":"19388","author":"martinvonz","id":"116747","dateCreated":"1579458578","dateModified":"1579458578"},{"type":"inline","comment":"How about we just replace the implementation by `VisitChildrenSet::Recursive`then? That's easy to maintain and makes it functionally correct. It's usually fast enough too.","replyTo":"116546","isNewFile":"1","line":"166","lineLength":"0","path":"rust\/hg-core\/src\/matchers.rs","diffId":"19388","author":"martinvonz","id":"116575","dateCreated":"1579282231","dateModified":"1579282231"},{"type":"inline","comment":"I don't feel like this is an issue of code quality. This is (probably) an issue of performance, and I have a good incentive for making this code go faster in the future. I don't think this is necessary for now since this is a minor optimization compared to the other ones that are pending.","replyTo":"116539","isNewFile":"1","line":"166","lineLength":"0","path":"rust\/hg-core\/src\/matchers.rs","diffId":"19388","author":"Alphare","id":"116546","dateCreated":"1579279912","dateModified":"1579279912"},{"type":"inline","comment":"Yes, code quality is never urgent. The problem is that there isn't much incentive for people to clean it up after. So I'd really prefer to not queue this without the cleanup.","replyTo":"116401","isNewFile":"1","line":"166","lineLength":"0","path":"rust\/hg-core\/src\/matchers.rs","diffId":"19388","author":"martinvonz","id":"116539","dateCreated":"1579277283","dateModified":"1579277283"},{"type":"inline","comment":"Agreed. In much of this series there exist opportunities for caching\/making things run in parallel, etc. With the freeze approaching really fast, I prefer to prioritize getting correct - albeit sub-optimal - code in rather than risking missing the deadline. \nMy benchmarks of the entire series show an improvement in bare `hg status`  in all supported repositories (read: that don't have back-references in their `.hgignore patterns), and no measurable slowdown in others.","replyTo":"116399","isNewFile":"1","line":"166","lineLength":"0","path":"rust\/hg-core\/src\/matchers.rs","diffId":"19388","author":"Alphare","id":"116401","dateCreated":"1579252622","dateModified":"1579252622"},{"type":"inline","comment":"This will often be called repeatedly, so isn't it better to calculate a map of each parent directory to its `VisitChildrenSet` value upfront (in `FilesMatcher::new()`)?","replyTo":null,"isNewFile":"1","line":"166","lineLength":"0","path":"rust\/hg-core\/src\/matchers.rs","diffId":"19388","author":"martinvonz","id":"116399","dateCreated":"1579242927","dateModified":"1579242927"},{"type":"update","diffId":"19388","author":"Alphare","id":"116338","dateCreated":"1579212722","dateModified":"1579212722"},{"type":"update","diffId":"19387","author":"Alphare","id":"116332","dateCreated":"1579212591","dateModified":"1579212591"}],"dateCreated":"1579212591","dateModified":"1579458579","status":"Needs Review"},{"id":"7894","callsign":"HG","title":"nodemap: introduce an option to use mmap to read the nodemap mapping","author":"marmoute","summary":"The performance and memory benefit is much greater if we don't have to copy all\nthe data in memory for each information. So we introduce an option (on by\ndefault) to read the data using mmap.\n\nThis changeset is the last one definition the API for index support nodemap\ndata. (they have to be able to use the mmaping).","testPlan":"","lineCount":"78","dependsOn":["7893"],"reviewers":[],"ccs":["gracinet","martinvonz","mercurial-devel"],"actions":[{"type":"update","diffId":"19435","author":"marmoute","id":"116589","dateCreated":"1579284475","dateModified":"1579284475"},{"type":"comment","comment":">>! In D7894#116540, @martinvonz wrote:\n>>>! In D7894#116407, @marmoute wrote:\n>>>>! In D7894#116397, @martinvonz wrote:\n>>> How much does this patch help performance?\n>>> \n>>> I would also like to see performance numbers (even just rough ones) for the Rust version. Sorry about a possibly stupid question, but why will this on-disk nodemap be faster than building it from the index? Is it that the file is smaller and thus faster to read? Or is it more the building of the tree than the reading that's slow? You mentioned you use some private repo for testing this. How large is the `00changelog.n` file in that repo and how large is `00changelog.i`?\n>> \n>> This save hundreds of milli second at initialization of large repositories. The repositories we are looking at are about 2 millions revisions. (but this will help smaller repository too). Mozilla try is a public repository in that range. It 00changelog.i is 103MB\n> \n> And 00changelog.n?\n\n```\n106973952 bytes for changelog.i\n 83123200 bytes for the nodemap rawfiles\n```\n\n>> The information in the .i files is just a flat list of node. So anything that need a mapping needs to build it. Building a mapping for millions of revision is slow. (I think Georges mentionned 300ms to build the mozilla-try nodemap). The nodemap we write on disk is directly usage as such. So we just need to mmap the files (mostly instant is the repository have been busy recently, eg: on server) and directly query the data from disk.\n> \n> Ah, that's what I was wondering. I was wondering while reviewing this series if your plan was to lazily from disk but I didn't see any mention of that. I guess this mmap business should have been that a hint :)\n\nYes, so everythign we are doing is not so really \"serialization\" since we never actualy \"deserialize\" it in practice.\n\n","author":"marmoute","id":"116543","dateCreated":"1579278637","dateModified":"1579278637"},{"type":"comment","comment":">>! In D7894#116407, @marmoute wrote:\n>>>! In D7894#116397, @martinvonz wrote:\n>> How much does this patch help performance?\n>> \n>> I would also like to see performance numbers (even just rough ones) for the Rust version. Sorry about a possibly stupid question, but why will this on-disk nodemap be faster than building it from the index? Is it that the file is smaller and thus faster to read? Or is it more the building of the tree than the reading that's slow? You mentioned you use some private repo for testing this. How large is the `00changelog.n` file in that repo and how large is `00changelog.i`?\n> \n> This save hundreds of milli second at initialization of large repositories. The repositories we are looking at are about 2 millions revisions. (but this will help smaller repository too). Mozilla try is a public repository in that range. It 00changelog.i is 103MB\n\nAnd 00changelog.n?\n\n> \n> The information in the .i files is just a flat list of node. So anything that need a mapping needs to build it. Building a mapping for millions of revision is slow. (I think Georges mentionned 300ms to build the mozilla-try nodemap). The nodemap we write on disk is directly usage as such. So we just need to mmap the files (mostly instant is the repository have been busy recently, eg: on server) and directly query the data from disk.\n\nAh, that's what I was wondering. I was wondering while reviewing this series if your plan was to lazily from disk but I didn't see any mention of that. I guess this mmap business should have been that a hint :)","author":"martinvonz","id":"116540","dateCreated":"1579277694","dateModified":"1579277694"},{"type":"comment","comment":">>! In D7894#116397, @martinvonz wrote:\n> How much does this patch help performance?\n> \n> I would also like to see performance numbers (even just rough ones) for the Rust version. Sorry about a possibly stupid question, but why will this on-disk nodemap be faster than building it from the index? Is it that the file is smaller and thus faster to read? Or is it more the building of the tree than the reading that's slow? You mentioned you use some private repo for testing this. How large is the `00changelog.n` file in that repo and how large is `00changelog.i`?\n\nThis save hundreds of milli second at initialization of large repositories. The repositories we are looking at are about 2 millions revisions. (but this will help smaller repository too). Mozilla try is a public repository in that range. It 00changelog.i is 103MB\n\nThe information in the .i files is just a flat list of node. So anything that need a mapping needs to build it. Building a mapping for millions of revision is slow. (I think Georges mentionned 300ms to build the mozilla-try nodemap). The nodemap we write on disk is directly usage as such. So we just need to mmap the files (mostly instant is the repository have been busy recently, eg: on server) and directly query the data from disk. We will get more data once the latest version of this series and the latest version of the Rust series (from @gracinet) are connected again. But this greatly boost many operation (small operation, discovery, etc).","author":"marmoute","id":"116408","dateCreated":"1579256751","dateModified":"1579256751"},{"type":"comment","comment":"How much does this patch help performance?\n\nI would also like to see performance numbers (even just rough ones) for the Rust version. Sorry about a possibly stupid question, but why will this on-disk nodemap be faster than building it from the index? Is it that the file is smaller and thus faster to read? Or is it more the building of the tree than the reading that's slow? You mentioned you use some private repo for testing this. How large is the `00changelog.n` file in that repo and how large is `00changelog.i`?","author":"martinvonz","id":"116397","dateCreated":"1579239974","dateModified":"1579239974"},{"type":"update","diffId":"19312","author":"marmoute","id":"115922","dateCreated":"1579100209","dateModified":"1579100209"}],"dateCreated":"1579100209","dateModified":"1579284476","status":"Needs Review"},{"id":"7893","callsign":"HG","title":"nodemap: update the index with the newly written data (when appropriate)","author":"marmoute","summary":"If we are to use mmap to read the nodemap data, and if the python code is\nresponsible for the IO, we need to refresh the mmap after each write and provide\nit back to the index.\n\nWe start this dance without the mmap first.","testPlan":"","lineCount":"6","dependsOn":["7892"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19311","author":"marmoute","id":"115914","dateCreated":"1579100201","dateModified":"1579100201"}],"dateCreated":"1579100201","dateModified":"1579284468","status":"Needs Review"},{"id":"7892","callsign":"HG","title":"nodemap: never read more than the expected data amount","author":"marmoute","summary":"Since we are tracking this number we can use it to detect corrupted rawdata file\nand to only read the correct amount of data when possible.","testPlan":"","lineCount":"7","dependsOn":["7891"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19310","author":"marmoute","id":"115906","dateCreated":"1579100194","dateModified":"1579100194"}],"dateCreated":"1579100194","dateModified":"1579284462","status":"Needs Review"},{"id":"7891","callsign":"HG","title":"nodemap: write new data from the expected current data length","author":"marmoute","summary":"If the amount of data in the file exceed the expect amount, we will overwrite\nthe extra data. This is a simple way to be safer.","testPlan":"","lineCount":"3","dependsOn":["7890"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19309","author":"marmoute","id":"115898","dateCreated":"1579100188","dateModified":"1579100188"}],"dateCreated":"1579100188","dateModified":"1579284457","status":"Needs Review"},{"id":"7890","callsign":"HG","title":"nodemap: double check the source docket when doing incremental update","author":"marmoute","summary":"In theory, the index will have the information we expect it to have. However by\nsecurity, it seems safer to double check that the incremental data are generated\nfrom the data currently on disk.","testPlan":"","lineCount":"50","dependsOn":["7889"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19308","author":"marmoute","id":"115890","dateCreated":"1579100176","dateModified":"1579100176"}],"dateCreated":"1579100176","dateModified":"1579284453","status":"Needs Review"},{"id":"7889","callsign":"HG","title":"nodemap: track the total and unused amount of data in the rawdata file","author":"marmoute","summary":"We need to keep that information around:\n\n* total data will allow transaction to start appending new information without\n  confusing other reader.\n\n* unused data will allow to detect when we should regenerate new rawdata file.","testPlan":"","lineCount":"61","dependsOn":["7888"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19434","author":"marmoute","id":"116588","dateCreated":"1579284447","dateModified":"1579284447"},{"type":"update","diffId":"19307","author":"marmoute","id":"115879","dateCreated":"1579100168","dateModified":"1579100168"}],"dateCreated":"1579100168","dateModified":"1579284448","status":"Needs Review"},{"id":"7888","callsign":"HG","title":"nodemap: track the maximum revision tracked in the nodemap","author":"marmoute","summary":"We need a simple way to detect when the on disk data contains less revision\nthan the index we read from disk. The docket file is meant for this, we just had\nto start tracking that data.\n\nWe should also try to detect strip operation, but we will deal with this in\nlater changesets. Right now we are focusing on defining the API for index\nsupporting persistent nodemap.","testPlan":"","lineCount":"28","dependsOn":["7887"],"reviewers":["indygreg"],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19433","author":"marmoute","id":"116587","dateCreated":"1579284441","dateModified":"1579284441"},{"type":"update","diffId":"19306","author":"marmoute","id":"115869","dateCreated":"1579100159","dateModified":"1579100159"}],"dateCreated":"1579100159","dateModified":"1579284441","status":"Needs Review"},{"id":"7886","callsign":"HG","title":"nodemap: introduce append-only incremental update of the persisten data","author":"marmoute","summary":"Rewriting the full nodemap for each transaction has a cost we would like to\navoid. We introduce a new way to write persistent nodemap data by adding new\ninformation at the end for file. Any new and updated block as added at the end\nof the file. The last block is the new root node.\n\nWith this method, some of the block already on disk get \"dereferenced\" and\nbecome dead data. In later changesets, We'll start tracking the amount of dead\ndata to eventually re-generate a full nodemap.","testPlan":"","lineCount":"117","dependsOn":["7885"],"reviewers":[],"ccs":["martinvonz","mercurial-devel"],"actions":[{"type":"inline","comment":"There are no C code (and is non planned). This should be `the C path` or `the cext policy`.","replyTo":"116395","isNewFile":"1","line":"53","lineLength":"0","path":"tests\/test-persistent-nodemap.t","diffId":"19304","author":"marmoute","id":"116406","dateCreated":"1579256384","dateModified":"1579256384"},{"type":"inline","comment":"Which patch introduced the C code? I have not looked at all patches yet, but I thought the idea was that this entire stack was just pure Python and then you'd add a Rust version (not C) in a separate series.","replyTo":null,"isNewFile":"1","line":"53","lineLength":"0","path":"tests\/test-persistent-nodemap.t","diffId":"19304","author":"martinvonz","id":"116395","dateCreated":"1579239324","dateModified":"1579239324"},{"type":"update","diffId":"19304","author":"marmoute","id":"115853","dateCreated":"1579100144","dateModified":"1579100144"}],"dateCreated":"1579100144","dateModified":"1579284425","status":"Needs Review"},{"id":"7885","callsign":"HG","title":"nodemap: keep track of the docket for loaded data","author":"marmoute","summary":"To perform incremental update of the on disk data, we need to keep tracks of\nsome aspect of that data.","testPlan":"","lineCount":"21","dependsOn":["7884"],"reviewers":["indygreg"],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19431","author":"marmoute","id":"116585","dateCreated":"1579284420","dateModified":"1579284420"},{"type":"update","diffId":"19303","author":"marmoute","id":"115844","dateCreated":"1579100137","dateModified":"1579100137"}],"dateCreated":"1579100137","dateModified":"1579284421","status":"Needs Review"},{"id":"7884","callsign":"HG","title":"nodemap: introduce an explicit class\/object for the docket","author":"marmoute","summary":"We are about to add more information to this docket, having a clear location to\nstock them in memory will help.","testPlan":"","lineCount":"50","dependsOn":["7883"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19302","author":"marmoute","id":"115836","dateCreated":"1579100130","dateModified":"1579100130"}],"dateCreated":"1579100130","dateModified":"1579284414","status":"Needs Review"},{"id":"7883","callsign":"HG","title":"nodemap: keep track of the ondisk id of nodemap blocks","author":"marmoute","summary":"If we are to incrementally update the files, we need to keep some details about\nthe data we read.","testPlan":"","lineCount":"9","dependsOn":["7847"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19301","author":"marmoute","id":"115828","dateCreated":"1579100124","dateModified":"1579100124"}],"dateCreated":"1579100124","dateModified":"1579284409","status":"Needs Review"},{"id":"7847","callsign":"HG","title":"nodemap: provide the on disk data to indexes who support it","author":"marmoute","summary":"Time to start defining the API and prepare the rust index support. We provide\na method to do so. We use a distinct method instead of passing them in the\nconstructor because we will need this method anyway later (to refresh the mmap\nonce we update the data on disk).","testPlan":"","lineCount":"18","dependsOn":["7846"],"reviewers":["indygreg"],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19430","author":"marmoute","id":"116584","dateCreated":"1579284404","dateModified":"1579284404"},{"type":"update","diffId":"19184","author":"marmoute","id":"115290","dateCreated":"1578928066","dateModified":"1578928066"}],"dateCreated":"1578928066","dateModified":"1579284405","status":"Needs Review"},{"id":"7846","callsign":"HG","title":"nodemap: all check that revision and nodes match in the nodemap","author":"marmoute","summary":"More check is always useful.","testPlan":"","lineCount":"21","dependsOn":["7845"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19300","author":"marmoute","id":"115826","dateCreated":"1579100110","dateModified":"1579100110"},{"type":"update","diffId":"19183","author":"marmoute","id":"115282","dateCreated":"1578928058","dateModified":"1578928058"}],"dateCreated":"1578928058","dateModified":"1579284398","status":"Needs Review"},{"id":"7845","callsign":"HG","title":"nodemap: add basic checking of the on disk nodemap content","author":"marmoute","summary":"The simplest check it so verify we have all the revision we needs, and nothing\nmore.","testPlan":"","lineCount":"53","dependsOn":["7844"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19429","author":"marmoute","id":"116583","dateCreated":"1579284392","dateModified":"1579284392"},{"type":"update","diffId":"19299","author":"marmoute","id":"115825","dateCreated":"1579100103","dateModified":"1579100103"},{"type":"update","diffId":"19182","author":"marmoute","id":"115274","dateCreated":"1578928051","dateModified":"1578928051"}],"dateCreated":"1578928051","dateModified":"1579284393","status":"Needs Review"},{"id":"7844","callsign":"HG","title":"nodemap: code to parse a serialized nodemap","author":"marmoute","summary":"We now have code to read back what we serialized. This will be put to use in\nlater changesets.","testPlan":"","lineCount":"30","dependsOn":["7843"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19298","author":"marmoute","id":"115824","dateCreated":"1579100096","dateModified":"1579100096"},{"type":"update","diffId":"19181","author":"marmoute","id":"115266","dateCreated":"1578928042","dateModified":"1578928042"}],"dateCreated":"1578928042","dateModified":"1579284385","status":"Needs Review"},{"id":"7843","callsign":"HG","title":"nodemap: move the iteratio inside the Block object","author":"marmoute","summary":"Having the iteration inside the serialization function does not help\nreadability. Now that we have a `Block` object, let us move that code there.","testPlan":"","lineCount":"5","dependsOn":["7842"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19297","author":"marmoute","id":"115823","dateCreated":"1579100091","dateModified":"1579100091"},{"type":"update","diffId":"19180","author":"marmoute","id":"115258","dateCreated":"1578928036","dateModified":"1578928036"}],"dateCreated":"1578928036","dateModified":"1579284380","status":"Needs Review"},{"id":"7842","callsign":"HG","title":"nodemap: use an explicit \"Block\" object in the reference implementation","author":"marmoute","summary":"This will help us to introduce some test around the data currently written on\ndisk.","testPlan":"","lineCount":"12","dependsOn":["7841"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19296","author":"marmoute","id":"115822","dateCreated":"1579100086","dateModified":"1579100086"},{"type":"update","diffId":"19179","author":"marmoute","id":"115250","dateCreated":"1578928030","dateModified":"1578928030"}],"dateCreated":"1578928030","dateModified":"1579284375","status":"Needs Review"},{"id":"7841","callsign":"HG","title":"nodemap: add a optional `nodemap_add_full` method on indexes","author":"marmoute","summary":"This method can be used to obtains serialized data for a full nodemap. The end\ngoal is for some index implementation to managed the nodemap serialization them\nselves (eg: the rust implementation)","testPlan":"","lineCount":"13","dependsOn":["7840"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19295","author":"marmoute","id":"115821","dateCreated":"1579100081","dateModified":"1579100081"},{"type":"update","diffId":"19178","author":"marmoute","id":"115242","dateCreated":"1578928023","dateModified":"1578928023"}],"dateCreated":"1578928023","dateModified":"1579284370","status":"Needs Review"},{"id":"7840","callsign":"HG","title":"nodemap: add a (python) index class for persistent nodemap testing","author":"marmoute","summary":"Using the persistent nodemap require a compeling performance boost and an\nexisting implementation. The benefit of the persistent nodemap for pure python\ncode is unclear and we don't have a C implementation for it. Yet we would like\nto actually start testing it in more details and define an API for using that\npersistent nodemap.\n\nWe introduce a new `devel` config option to use an index class dedicated to\nNodemap Testing. This feature is \"pure\" only because having using a pure-python\nindex with the `cext` policy proved more difficult than I would like.\n\nThere is nothing going on in that class for now, but the coming changeset will\nchange that.","testPlan":"","lineCount":"45","dependsOn":["7839"],"reviewers":["indygreg"],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19428","author":"marmoute","id":"116582","dateCreated":"1579284363","dateModified":"1579284363"},{"type":"update","diffId":"19186","author":"marmoute","id":"115322","dateCreated":"1578938706","dateModified":"1578938706"},{"type":"update","diffId":"19177","author":"marmoute","id":"115233","dateCreated":"1578928016","dateModified":"1578928016"}],"dateCreated":"1578928016","dateModified":"1579284364","status":"Needs Review"},{"id":"7839","callsign":"HG","title":"nodemap: deleted older raw data file when creating a new ones","author":"marmoute","summary":"When we write new full files, it replace an older one with a different name. We\nadd the associated cleanup for the older file to be removed after the\ntransaction.\n\nWe delete all file matching the expected pattern to give use extra chance to\ndelete orphan files we might have failed to delete earlier.\n\nNote: eventually we won't rewrite all data for each transaction. This is coming\nin later changesets.","testPlan":"","lineCount":"38","dependsOn":["7838"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19294","author":"marmoute","id":"115820","dateCreated":"1579100071","dateModified":"1579100071"},{"type":"update","diffId":"19176","author":"marmoute","id":"115230","dateCreated":"1578928005","dateModified":"1578928005"},{"type":"update","diffId":"19159","author":"marmoute","id":"115172","dateCreated":"1578762213","dateModified":"1578762213"}],"dateCreated":"1578762213","dateModified":"1579284355","status":"Needs Review"},{"id":"7838","callsign":"HG","title":"nodemap: use an intermediate \"docket\" file to carry small metadata","author":"marmoute","summary":"This intermediate file will make mmapping, transaction and content validation\neasier. (Most of this usefulness will arrive gradually in later changeset). In\nparticular it will become very useful to append new data are the end of raw file\ninstead of rewriting on the file on each transaction.\n\nSee in code comments for details.","testPlan":"","lineCount":"84","dependsOn":["7837"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19175","author":"marmoute","id":"115228","dateCreated":"1578927999","dateModified":"1578927999"},{"type":"update","diffId":"19158","author":"marmoute","id":"115164","dateCreated":"1578762206","dateModified":"1578762206"}],"dateCreated":"1578762206","dateModified":"1579284350","status":"Needs Review"},{"id":"7837","callsign":"HG","title":"nodemap: only use persistent nodemap for non-inlined revlog","author":"marmoute","summary":"Revlog are inlined while they are small (to avoid having too many file to deal\nwith). The persistent nodemap will only provides a significant boost for large\nenough revlog index. So it does not make sens to add an extra file to store\nnodemap for small revlog.\n\nWe could consider inclining the nodemap data inside the revlog itself, but the\nbenefit is unclear so let it be an adventure for another time.","testPlan":"","lineCount":"3","dependsOn":["7836"],"reviewers":["indygreg"],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19427","author":"marmoute","id":"116581","dateCreated":"1579284344","dateModified":"1579284344"},{"type":"update","diffId":"19174","author":"marmoute","id":"115227","dateCreated":"1578927993","dateModified":"1578927993"},{"type":"update","diffId":"19157","author":"marmoute","id":"115155","dateCreated":"1578762199","dateModified":"1578762199"}],"dateCreated":"1578762199","dateModified":"1579284345","status":"Needs Review"},{"id":"7836","callsign":"HG","title":"nodemap: add a function to read the data from disk","author":"marmoute","summary":"This changeset is small and mostly an excuse to introduce an API function\nreading the data from disk.","testPlan":"","lineCount":"30","dependsOn":["7835"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19426","author":"marmoute","id":"116580","dateCreated":"1579284337","dateModified":"1579284337"},{"type":"update","diffId":"19173","author":"marmoute","id":"115226","dateCreated":"1578927985","dateModified":"1578927985"},{"type":"update","diffId":"19156","author":"marmoute","id":"115147","dateCreated":"1578762192","dateModified":"1578762192"}],"dateCreated":"1578762192","dateModified":"1579284338","status":"Needs Review"},{"id":"7835","callsign":"HG","title":"nodemap: write nodemap data on disk","author":"marmoute","summary":"Let us start writing data on disk (so that we can read it from there later).\nThis series of changeset is going to focus first on having data on disk and\nupdating it.\n\nRight now the data is written right next to the revlog data, in the store. We\nmight move it to cache (with proper cache validation mechanism) later, but for\nnow revlog have a storevfs instance and it is simpler to us it. The right\nlocation for this data is not the focus of this series.","testPlan":"","lineCount":"55","dependsOn":["7834"],"reviewers":["indygreg"],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19425","author":"marmoute","id":"116579","dateCreated":"1579284331","dateModified":"1579284331"},{"type":"update","diffId":"19185","author":"marmoute","id":"115321","dateCreated":"1578938683","dateModified":"1578938683"},{"type":"update","diffId":"19172","author":"marmoute","id":"115225","dateCreated":"1578927978","dateModified":"1578927978"},{"type":"update","diffId":"19155","author":"marmoute","id":"115138","dateCreated":"1578762184","dateModified":"1578762184"}],"dateCreated":"1578762184","dateModified":"1579284331","status":"Needs Review"},{"id":"7834","callsign":"HG","title":"nodemap: have some python code serializing a nodemap","author":"marmoute","summary":"This python code aims to be as \"simple\" as possible. It is a reference\nimplementation of the data we are going to serialize on disk (and possibly,\nlater a way for pure python install to make sure the on disk data are up to\ndate).\n\nIt is not optimized for performance and rebuild the full data structure from\nthe index every time.\n\nThis is a stepping stone toward a persistent nodemap on disk.","testPlan":"","lineCount":"197","dependsOn":[],"reviewers":["martinvonz"],"ccs":["martinvonz","mjpieters","mercurial-devel"],"actions":[{"type":"update","diffId":"19424","author":"marmoute","id":"116577","dateCreated":"1579284325","dateModified":"1579284325"},{"type":"comment","comment":"As stated yesterday, I'll have limited screen exposure time available for the next couple of day. I am going to ignore any minor nits during that time. (Am I happy to look at them afterward and follow up).\n\nRight now, I have only identified the `s\/**args\/**opts\/` as non nits. I am sending an updated version that update that part. If any remains, please highlight any other major complains about this patch that is worth blocking the rest of the series.","author":"marmoute","id":"116576","dateCreated":"1579284297","dateModified":"1579284297"},{"type":"comment","comment":">>! In D7834#116533, @marmoute wrote:\n> Can you clarify which change you are actually requesting (I see mostly nits).\n> \n> So far I see the `**args` \u2192 `**opts` change but I might be missing others.\n\nI'd prefer if you go through them all.","author":"martinvonz","id":"116534","dateCreated":"1579276473","dateModified":"1579276473"},{"type":"comment","comment":"Can you clarify which change you are actually requesting (I see mostly nits).\n\nSo far I see the `**args` \u2192 `**opts` change but I might be missing others.","author":"marmoute","id":"116533","dateCreated":"1579275565","dateModified":"1579275565"},{"type":"inline","comment":"No good reason for this to not be `opts`. I'll rename it.","replyTo":"116393","isNewFile":"1","line":"2084","lineLength":"0","path":"mercurial\/debugcommands.py","diffId":"19171","author":"marmoute","id":"116404","dateCreated":"1579256314","dateModified":"1579256314"},{"type":"inline","comment":"could you also rename `args` to `opts`? or is there a reason to not follow the same convention we follow everywhere (?) else?","replyTo":null,"isNewFile":"1","line":"2084","lineLength":"0","path":"mercurial\/debugcommands.py","diffId":"19171","author":"martinvonz","id":"116393","dateCreated":"1579239153","dateModified":"1579239153"},{"type":"inline","comment":"The test case still passes with that change, though....","replyTo":"116329","isNewFile":"1","line":"112","lineLength":"6","path":"mercurial\/revlogutils\/nodemap.py","diffId":"19171","author":"martinvonz","id":"116337","dateCreated":"1579212611","dateModified":"1579212611"},{"type":"inline","comment":"no, we need the value of block to be updated after each iteration otherwise the next iteration would not descend to the level it just created.","replyTo":"116303","isNewFile":"1","line":"112","lineLength":"6","path":"mercurial\/revlogutils\/nodemap.py","diffId":"19171","author":"marmoute","id":"116329","dateCreated":"1579211521","dateModified":"1579211521"},{"type":"inline","comment":"`serialize_value()`?","replyTo":null,"isNewFile":"1","line":"155","lineLength":"0","path":"mercurial\/revlogutils\/nodemap.py","diffId":"19171","author":"martinvonz","id":"116306","dateCreated":"1579211050","dateModified":"1579211050"},{"type":"inline","comment":"and this could be `_serialize_block()`","replyTo":null,"isNewFile":"1","line":"145","lineLength":"0","path":"mercurial\/revlogutils\/nodemap.py","diffId":"19171","author":"martinvonz","id":"116305","dateCreated":"1579211050","dateModified":"1579211050"},{"type":"inline","comment":"as mentioned above, i think `_serialize_tree()` would be a clearer name (it matches how you described it in the docstring)","replyTo":null,"isNewFile":"1","line":"121","lineLength":"0","path":"mercurial\/revlogutils\/nodemap.py","diffId":"19171","author":"martinvonz","id":"116304","dateCreated":"1579211050","dateModified":"1579211050"},{"type":"inline","comment":"Would it work to replace these lines by the following?\n\n```\n        new = {}\n        block[_to_int(current_hex[level])] = new\n        _insert_into_block(index, level + 1, new, other_rev, other_hex)\n        _insert_into_block(index, level + 1, new, current_rev, current_hex)\n```","replyTo":null,"isNewFile":"1","line":"112","lineLength":"6","path":"mercurial\/revlogutils\/nodemap.py","diffId":"19171","author":"martinvonz","id":"116303","dateCreated":"1579211050","dateModified":"1579211050"},{"type":"inline","comment":"nit: will `rev, entry in enumerate(index)` help? (i know we don't care about speed)","replyTo":null,"isNewFile":"1","line":"85","lineLength":"0","path":"mercurial\/revlogutils\/nodemap.py","diffId":"19171","author":"martinvonz","id":"116302","dateCreated":"1579211050","dateModified":"1579211050"},{"type":"inline","comment":"s\/nn\/n\/\ns\/key\/keys\/\ns\/Value\/Values\/","replyTo":null,"isNewFile":"1","line":"81","lineLength":"0","path":"mercurial\/revlogutils\/nodemap.py","diffId":"19171","author":"martinvonz","id":"116301","dateCreated":"1579211050","dateModified":"1579211050"},{"type":"inline","comment":"s\/store\/stores\/","replyTo":null,"isNewFile":"1","line":"79","lineLength":"0","path":"mercurial\/revlogutils\/nodemap.py","diffId":"19171","author":"martinvonz","id":"116300","dateCreated":"1579211050","dateModified":"1579211050"},{"type":"inline","comment":"nit: maybe \"... involution (is its own inverse)\" because i don't think most people know what an involution is\n\nAlso, you could rename the function to `encode_rev()`. You could then do:\n\n```\n# encode_rev is its own inverse\ndecode_rev = encode_rev\n```\n\nOr not even define that since it's not used","replyTo":null,"isNewFile":"1","line":"66","lineLength":"0","path":"mercurial\/revlogutils\/nodemap.py","diffId":"19171","author":"martinvonz","id":"116299","dateCreated":"1579211050","dateModified":"1579211050"},{"type":"inline","comment":"nit: replace \"rev-0\" by \"rev 0\" so it's not interpreted as subtraction","replyTo":null,"isNewFile":"1","line":"57","lineLength":"0","path":"mercurial\/revlogutils\/nodemap.py","diffId":"19171","author":"martinvonz","id":"116298","dateCreated":"1579211050","dateModified":"1579211050"},{"type":"inline","comment":"nit: call it `serialize()` to match the description? or maybe `serialize_index()` and rename `_dump_trie()` to `_serialize_trie()`","replyTo":null,"isNewFile":"1","line":"47","lineLength":"2","path":"mercurial\/revlogutils\/nodemap.py","diffId":"19171","author":"martinvonz","id":"116297","dateCreated":"1579211050","dateModified":"1579211050"},{"type":"reject","author":"martinvonz","id":"116296","dateCreated":"1579211050","dateModified":"1579211050"},{"type":"update","diffId":"19171","author":"marmoute","id":"115224","dateCreated":"1578927969","dateModified":"1578927969"},{"type":"update","diffId":"19154","author":"marmoute","id":"115130","dateCreated":"1578762177","dateModified":"1578762177"}],"dateCreated":"1578762177","dateModified":"1579284325","status":"Needs Review"},{"id":"7931","callsign":"HG","title":"rust-status: use bare hg status fastpath from Python","author":"Alphare","summary":"This change also adds a test case for subrepos.\nRepeating the benchmark information from the `hg-core` commit:\n\nOn the Netbeans repository:\nC: 840ms\nRust+C: 556ms\n\nMozilla Central with the one pattern that causes a fallback removed:\nC: 2.315s\nRust+C: 1.700s","testPlan":"","lineCount":"82","dependsOn":["7930"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19423","author":"Alphare","id":"116568","dateCreated":"1579280022","dateModified":"1579280022"}],"dateCreated":"1579280022","dateModified":"1579280023","status":"Needs Review"},{"id":"7930","callsign":"HG","title":"rust-status: update rust-cpython bridge to account for the changes in core","author":"Alphare","summary":"","testPlan":"","lineCount":"264","dependsOn":["7929"],"reviewers":[],"ccs":["kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19422","author":"Alphare","id":"116561","dateCreated":"1579280015","dateModified":"1579280015"}],"dateCreated":"1579280015","dateModified":"1579280023","status":"Needs Review"},{"id":"7929","callsign":"HG","title":"rust-status: add bare `hg status` support in hg-core","author":"Alphare","summary":"A lot of performance remains to be gained, most notably by doing more things\nin parallel, but also by caching, not falling back to Python but switching\nto another regex engine, etc..\n\nI have measured on multiple repositories that this change, when in combination\nwith the next two patches, improve bare `hg status` performance, and has no\nobservable impact when falling back (because it does so early).\n\nOn the Netbeans repository:\nC: 840ms\nRust+C: 556ms\n\nMozilla Central with the one pattern that causes a fallback removed:\nC: 2.315s\nRust+C: 1.700 s","testPlan":"","lineCount":"366","dependsOn":["7928"],"reviewers":[],"ccs":["kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19421","author":"Alphare","id":"116553","dateCreated":"1579280009","dateModified":"1579280009"}],"dateCreated":"1579280008","dateModified":"1579280015","status":"Needs Review"},{"id":"7928","callsign":"HG","title":"rust-status: add function for sequential traversal of the working directory","author":"Alphare","summary":"This change also introduces helper structs to make things clearer.","testPlan":"","lineCount":"274","dependsOn":["7927"],"reviewers":[],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19417","author":"Alphare","id":"116526","dateCreated":"1579275219","dateModified":"1579275219"}],"dateCreated":"1579275219","dateModified":"1579280009","status":"Needs Review"},{"id":"7927","callsign":"HG","title":"rust-status: add util for listing a directory","author":"Alphare","summary":"I debated moving it to utils, but it is not used anywhere else for now, and\nits skip behavior is pretty specific to status.","testPlan":"","lineCount":"29","dependsOn":["7926"],"reviewers":[],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19416","author":"Alphare","id":"116518","dateCreated":"1579275212","dateModified":"1579275212"}],"dateCreated":"1579275212","dateModified":"1579279998","status":"Needs Review"},{"id":"7926","callsign":"HG","title":"rust-dependencies: update rayon","author":"Alphare","summary":"This is just to make sure we use the latest version and also makes it easier\nto peruse the docs.","testPlan":"","lineCount":"172","dependsOn":["7925"],"reviewers":[],"ccs":["martinvonz","mercurial-devel"],"actions":[{"type":"comment","comment":"I have no problem with the patch itself, but could you add a few words about the motivation? Even if that's just \"no particular reason, I just like us to stay up to date\".","author":"martinvonz","id":"116542","dateCreated":"1579278383","dateModified":"1579278383"},{"type":"update","diffId":"19415","author":"Alphare","id":"116511","dateCreated":"1579275206","dateModified":"1579275206"}],"dateCreated":"1579275206","dateModified":"1579279993","status":"Needs Review"},{"id":"7925","callsign":"HG","title":"rust-matchers: add `IgnoreMatcher`","author":"Alphare","summary":"This is a big change but all of the pieces call each other, so it makes sense\nto have this all in one patch.","testPlan":"","lineCount":"383","dependsOn":["7924"],"reviewers":[],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19420","author":"Alphare","id":"116550","dateCreated":"1579279987","dateModified":"1579279987"},{"type":"update","diffId":"19404","author":"Alphare","id":"116445","dateCreated":"1579258809","dateModified":"1579258809"}],"dateCreated":"1579258809","dateModified":"1579279988","status":"Needs Review"},{"id":"7924","callsign":"HG","title":"rust-matchers: add `build_regex_match` function","author":"Alphare","summary":"This function will be used to help build the upcoming `IncludeMatcher`.","testPlan":"","lineCount":"53","dependsOn":["7923"],"reviewers":[],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19419","author":"Alphare","id":"116549","dateCreated":"1579279981","dateModified":"1579279981"},{"type":"update","diffId":"19403","author":"Alphare","id":"116437","dateCreated":"1579257720","dateModified":"1579257720"}],"dateCreated":"1579257720","dateModified":"1579279981","status":"Needs Review"},{"id":"7923","callsign":"HG","title":"rust-matchers: add functions to get roots, dirs and parents from patterns","author":"Alphare","summary":"These functions will be used to help build the upcoming `IncludeMatcher`.","testPlan":"","lineCount":"151","dependsOn":["7922"],"reviewers":["kevincox"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19418","author":"Alphare","id":"116547","dateCreated":"1579279975","dateModified":"1579279975"},{"type":"inline","comment":"Please describe the return value.","replyTo":null,"isNewFile":"1","line":"311","lineLength":"0","path":"rust\/hg-core\/src\/matchers.rs","diffId":"19402","author":"kevincox","id":"116537","dateCreated":"1579277154","dateModified":"1579277154"},{"type":"inline","comment":"I'm confused by the \"for each\" since this only returns one tuple.","replyTo":null,"isNewFile":"1","line":"250","lineLength":"0","path":"rust\/hg-core\/src\/matchers.rs","diffId":"19402","author":"kevincox","id":"116536","dateCreated":"1579277154","dateModified":"1579277154"},{"type":"reject","author":"kevincox","id":"116535","dateCreated":"1579277154","dateModified":"1579277154"},{"type":"update","diffId":"19402","author":"Alphare","id":"116429","dateCreated":"1579257714","dateModified":"1579257714"}],"dateCreated":"1579257714","dateModified":"1579279975","status":"Needs Review"},{"id":"7922","callsign":"HG","title":"rust-matchers: add function to generate a regex matcher function","author":"Alphare","summary":"This function will be used to help build the upcoming `IncludeMatcher`. While\nRe2 is still used and behind a feature flag, this function returns an error\nmeant for fallback in the default case.","testPlan":"","lineCount":"36","dependsOn":["7921"],"reviewers":[],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19401","author":"Alphare","id":"116421","dateCreated":"1579257708","dateModified":"1579257708"}],"dateCreated":"1579257708","dateModified":"1579279969","status":"Needs Review"},{"id":"7921","callsign":"HG","title":"rust-dirs-multiset: improve temporary error message","author":"Alphare","summary":"While we wait on a future patch that could verify that the paths passed to\n`DirsMultiset` have been audited, we still need to handle this error.\nThis patch makes it easier to bubble up and makes the error clearer.\n\nAlso, this patch introduces the `subslice_index` function that could be useful\nfor other - albeit niche - purposes.","testPlan":"","lineCount":"56","dependsOn":["7914"],"reviewers":[],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19400","author":"Alphare","id":"116413","dateCreated":"1579257703","dateModified":"1579257703"}],"dateCreated":"1579257703","dateModified":"1579279964","status":"Needs Review"},{"id":"7910","callsign":"HG","title":"rust-re2: add wrapper for calling Re2 from Rust","author":"Alphare","summary":"This assumes that Re2 is installed following Google's guide. I am not sure\nhow we want to integrate it in the project, but I think a follow-up patch would\nbe more appropriate for such work.\nAs it stands, *not* having Re2 installed results in a compilation error, which\nis a problem as it breaks install compatibility. Hence, this is gated behind\na non-default `with-re2` compilation feature.","testPlan":"","lineCount":"228","dependsOn":["7909"],"reviewers":["kevincox"],"ccs":["durin42","kevincox","mjpieters","mercurial-devel"],"actions":[{"type":"accept","author":"kevincox","id":"116482","dateCreated":"1579273684","dateModified":"1579273684"},{"type":"update","diffId":"19399","author":"Alphare","id":"116409","dateCreated":"1579257692","dateModified":"1579257692"},{"type":"update","diffId":"19386","author":"Alphare","id":"116323","dateCreated":"1579211442","dateModified":"1579211442"},{"type":"comment","comment":"While I think the rust regex crate is heavily inspired by RE2 and uses a fairly compatible syntax I don't think there is a goal to be 100% compatible and I would be surprised if there weren't any differences. What I am trying to say is that if we are going to change engines we may as well change to `regex`. If we are using `RE2` for backwards compatibility then this change makes sense.","author":"kevincox","id":"116221","dateCreated":"1579190765","dateModified":"1579190765"},{"type":"comment","comment":">>! In D7910#116208, @kevincox wrote:\n> Does mercurial currently use RE2? If not then can you explain why we don't just use the rust `regex` crate?\n\nWe have support for using re2 iff the correct Python bindings are installed. That said, I thought the rust regex crate would be compatible with re2? If we can't use that, we should document why so that future hackers (like me) don't try and simplify....","author":"durin42","id":"116214","dateCreated":"1579189432","dateModified":"1579189432"},{"type":"inline","comment":"This is never freed. Should we add a `Drop` implementation in rust?","replyTo":null,"isNewFile":"1","line":"22","lineLength":"0","path":"rust\/hg-core\/src\/re2\/rust_re2.cpp","diffId":"19360","author":"kevincox","id":"116210","dateCreated":"1579189337","dateModified":"1579189337"},{"type":"reject","author":"kevincox","id":"116209","dateCreated":"1579189336","dateModified":"1579189336"},{"type":"comment","comment":"Does mercurial currently use RE2? If not then can you explain why we don't just use the rust `regex` crate?","author":"kevincox","id":"116208","dateCreated":"1579189272","dateModified":"1579189272"},{"type":"accept","author":"kevincox","id":"116207","dateCreated":"1579189272","dateModified":"1579189272"},{"type":"update","diffId":"19360","author":"Alphare","id":"116167","dateCreated":"1579182899","dateModified":"1579182899"}],"dateCreated":"1579182899","dateModified":"1579279955","status":"Needs Review"},{"id":"7909","callsign":"HG","title":"rust-filepatterns: add support for `include` and `subinclude` patterns","author":"Alphare","summary":"This prepares a future patch for `IncludeMatcher` on the road to bare\n`hg status` support.","testPlan":"","lineCount":"130","dependsOn":["7908"],"reviewers":["kevincox"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19385","author":"Alphare","id":"116319","dateCreated":"1579211436","dateModified":"1579211436"},{"type":"inline","comment":"You would have to make sure you return a Vec on both arms. You will probably want `inner_pats.into_iter().collect()` on one branch and `vec![entry]` on the other branch. ","replyTo":"116265","isNewFile":"1","line":"462","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19357","author":"kevincox","id":"116279","dateCreated":"1579203641","dateModified":"1579203641"},{"type":"inline","comment":"The `match` arms would be incompatible. Or maybe I'm missing something.","replyTo":"116187","isNewFile":"1","line":"462","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19357","author":"Alphare","id":"116265","dateCreated":"1579198883","dateModified":"1579198883"},{"type":"inline","comment":"How about:\n\n```\nif !p.is_empty() {\n  p.push(b'\/');\n}\nOk(p)\n```","replyTo":null,"isNewFile":"1","line":"525","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19357","author":"kevincox","id":"116189","dateCreated":"1579188622","dateModified":"1579188622"},{"type":"inline","comment":"I don't see anywhere where this returns `None`. Should this just be `.map()` or `.flat_map()`?","replyTo":null,"isNewFile":"1","line":"456","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19357","author":"kevincox","id":"116188","dateCreated":"1579188622","dateModified":"1579188622"},{"type":"inline","comment":"I would write this as `Some(Ok(match syntax { .. }))` as the last expression of this map. Then instead of `res.extend()` and `res.push()` you just return the vecs.","replyTo":null,"isNewFile":"1","line":"462","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19357","author":"kevincox","id":"116187","dateCreated":"1579188622","dateModified":"1579188622"},{"type":"reject","author":"kevincox","id":"116186","dateCreated":"1579188622","dateModified":"1579188622"},{"type":"comment","comment":"Note to reviewers: this stack is part of the larger series of getting a full Rust dirstate.status which is most of the performance hit in bare hg status. More patches are coming, but I figured I would send the patches as I go to help with review timing.","author":"Alphare","id":"116154","dateCreated":"1579177165","dateModified":"1579177165"},{"type":"update","diffId":"19357","author":"Alphare","id":"116145","dateCreated":"1579174385","dateModified":"1579174385"}],"dateCreated":"1579174385","dateModified":"1579257684","status":"Needs Review"},{"id":"7908","callsign":"HG","title":"rust-filepatterns: improve API and robustness for pattern files parsing","author":"Alphare","summary":"Within the next few patches we will be using this new API.","testPlan":"","lineCount":"312","dependsOn":["7871"],"reviewers":["kevincox"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19384","author":"Alphare","id":"116318","dateCreated":"1579211430","dateModified":"1579211430"},{"type":"inline","comment":"Oops. My mistake. But I think we agree that readability is the top priority (until profiles say otherwise)","replyTo":"116281","isNewFile":"1","line":"237","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19356","author":"kevincox","id":"116288","dateCreated":"1579206915","dateModified":"1579206915"},{"type":"inline","comment":"I might be using godbolt wrong but it looks like you are using different versions of rustc. When using 1.40 for both sides, I don't see any clear win on either side... but I'm not fluent in assembly either. As I'm sure you'll agree, this function is unlikely to show up in future profiles anyway. ","replyTo":"116274","isNewFile":"1","line":"237","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19356","author":"Alphare","id":"116281","dateCreated":"1579205942","dateModified":"1579205942"},{"type":"inline","comment":"Can you move this condition into a `.filter()`?","replyTo":null,"isNewFile":"1","line":"227","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19356","author":"kevincox","id":"116275","dateCreated":"1579202149","dateModified":"1579202149"},{"type":"inline","comment":"If you think it' is clearer that's fine. But I'm curious where \"Rust might optimize iterators better than for loops\" comes from. I did a quick test and it looks like the for loop actually generates slightly better code https:\/\/rust.godbolt.org\/z\/vFAWyZ","replyTo":"116271","isNewFile":"1","line":"237","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19356","author":"kevincox","id":"116274","dateCreated":"1579202149","dateModified":"1579202149"},{"type":"accept","author":"kevincox","id":"116273","dateCreated":"1579202149","dateModified":"1579202149"},{"type":"inline","comment":"For now this is pretty specific, but it might need to be moved later when more code paths use it.","replyTo":"116183","isNewFile":"1","line":"250","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19356","author":"Alphare","id":"116272","dateCreated":"1579200083","dateModified":"1579200083"},{"type":"inline","comment":"I'm not sure I agree. On the basis that \"Rust might optimize iterators better than for loops\" I vote to keep it that way.","replyTo":"116185","isNewFile":"1","line":"237","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19356","author":"Alphare","id":"116271","dateCreated":"1579200083","dateModified":"1579200083"},{"type":"inline","comment":"Indeed. Also added a comment to explain the reasoning.","replyTo":"116184","isNewFile":"1","line":"220","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19356","author":"Alphare","id":"116270","dateCreated":"1579200083","dateModified":"1579200083"},{"type":"inline","comment":"Personally I think this would be more clear as a `for` loop.","replyTo":null,"isNewFile":"1","line":"237","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19356","author":"kevincox","id":"116185","dateCreated":"1579187879","dateModified":"1579187879"},{"type":"inline","comment":"It might be clearer to do `bytes.iter().take_while(|b| b == sep).count()`","replyTo":null,"isNewFile":"1","line":"220","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19356","author":"kevincox","id":"116184","dateCreated":"1579187879","dateModified":"1579187879"},{"type":"inline","comment":"Should this be part of HgPathBuf  or is this normalization specific to the file pattern matching in some way?","replyTo":null,"isNewFile":"1","line":"250","lineLength":"0","path":"rust\/hg-core\/src\/filepatterns.rs","diffId":"19356","author":"kevincox","id":"116183","dateCreated":"1579187879","dateModified":"1579187879"},{"type":"update","diffId":"19356","author":"Alphare","id":"116143","dateCreated":"1579174043","dateModified":"1579174043"},{"type":"update","diffId":"19355","author":"Alphare","id":"116121","dateCreated":"1579170142","dateModified":"1579170142"}],"dateCreated":"1579170142","dateModified":"1579257680","status":"Needs Review"},{"id":"7871","callsign":"HG","title":"rust-utils: add util for canonical path","author":"Alphare","summary":"","testPlan":"","lineCount":"134","dependsOn":["7870"],"reviewers":["kevincox"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19359","author":"Alphare","id":"116164","dateCreated":"1579178936","dateModified":"1579178936"},{"type":"update","diffId":"19354","author":"Alphare","id":"116119","dateCreated":"1579170136","dateModified":"1579170136"},{"type":"update","diffId":"19349","author":"Alphare","id":"116098","dateCreated":"1579167253","dateModified":"1579167253"},{"type":"update","diffId":"19321","author":"Alphare","id":"115981","dateCreated":"1579125377","dateModified":"1579125377"},{"type":"accept","author":"kevincox","id":"115942","dateCreated":"1579104595","dateModified":"1579104595"},{"type":"update","diffId":"19263","author":"Alphare","id":"115639","dateCreated":"1579023244","dateModified":"1579023244"}],"dateCreated":"1579023244","dateModified":"1579257676","status":"Needs Review"},{"id":"7870","callsign":"HG","title":"rust-utils: add `Escaped` trait","author":"Alphare","summary":"This will be used as a general interface for displaying things to the user.\nThe upcoming `IncludeMatcher` will use it to store its patterns in a\nuser-displayable string.","testPlan":"","lineCount":"57","dependsOn":["7869"],"reviewers":["kevincox"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"I think it's better. Maybe still a little vauge but I'll let subject experts make that decision.","author":"kevincox","id":"116160","dateCreated":"1579178650","dateModified":"1579178650"},{"type":"accept","author":"kevincox","id":"116159","dateCreated":"1579178650","dateModified":"1579178650"},{"type":"update","diffId":"19348","author":"Alphare","id":"116097","dateCreated":"1579167114","dateModified":"1579167114"},{"type":"inline","comment":"Oh nice!","replyTo":"115936","isNewFile":"1","line":"146","lineLength":"0","path":"rust\/hg-core\/src\/utils.rs","diffId":"19262","author":"Alphare","id":"115980","dateCreated":"1579125373","dateModified":"1579125373"},{"type":"comment","comment":">>! In D7870#115935, @kevincox wrote:\n> I'm not convinced PrettyPrint is the best name. I might call it something more to do with escaping instead of \"pretty\". However I can't think of anything great.\n\nYeah, I am not convinced either. I've sent a new patch, maybe that's better?","author":"Alphare","id":"115979","dateCreated":"1579125373","dateModified":"1579125373"},{"type":"update","diffId":"19320","author":"Alphare","id":"115976","dateCreated":"1579125370","dateModified":"1579125370"},{"type":"inline","comment":"```\nwrite!(acc, \"\\\\x{:x}\", self).unwrap();\n```","replyTo":null,"isNewFile":"1","line":"146","lineLength":"0","path":"rust\/hg-core\/src\/utils.rs","diffId":"19262","author":"kevincox","id":"115936","dateCreated":"1579101391","dateModified":"1579101391"},{"type":"comment","comment":"I'm not convinced PrettyPrint is the best name. I might call it something more to do with escaping instead of \"pretty\". However I can't think of anything great.","author":"kevincox","id":"115935","dateCreated":"1579101391","dateModified":"1579101391"},{"type":"accept","author":"kevincox","id":"115934","dateCreated":"1579101391","dateModified":"1579101391"},{"type":"update","diffId":"19262","author":"Alphare","id":"115631","dateCreated":"1579023236","dateModified":"1579023236"}],"dateCreated":"1579023236","dateModified":"1579257672","status":"Needs Review"},{"id":"7733","callsign":"HG","title":"hgext: initial version of fastexport extension","author":"joerg.sonnenberger","summary":"","testPlan":"","lineCount":"906","dependsOn":[],"reviewers":["durin42"],"ccs":["durin42","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":"I only did a light pass, but looks good to me.\n\nAny plans for a fast-export importer as well?","author":"durin42","id":"114754","dateCreated":"1578511846","dateModified":"1578511846"},{"type":"accept","author":"durin42","id":"114753","dateCreated":"1578511846","dateModified":"1578511846"},{"type":"update","diffId":"18949","author":"joerg.sonnenberger","id":"113840","dateCreated":"1577477533","dateModified":"1577477533"}],"dateCreated":"1577477533","dateModified":"1579230427","status":"Needs Review"},{"id":"7177","callsign":"HG","title":"rebase: introduce optional parent mapping","author":"joerg.sonnenberger","summary":"Consider the following DAG:\n\n  C   C'\n  |\\ \/|\n  A B D\n\nwith the goal of rebasing C to C' while switching the A parent to D.\nOut of the box, rebase will fail here as it doesn't know which parent of\nC to rewrite. With the new --parentmap option, this can be specified\nexplicitly. Use cases for this functionality are dealing with manual\nrebases without obsolescence markers, e.g. git-style forced commits.","testPlan":"","lineCount":"94","dependsOn":[],"reviewers":["martinvonz"],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"I personally haven't queued this yet because I don't really like the UI. Some things I recently worked on made me realize that `hg graft` doesn't currently preserve merges, but we could probably easily add a `--preserve-merges` option to it, so `hg co D; hg graft --base B --preserve-merges` would take care of the case in the commit message.","author":"martinvonz","id":"116330","dateCreated":"1579212527","dateModified":"1579212527"},{"type":"comment","comment":"I changed the commit message to indent the graph by two spaces. That way it renders better here in Phabricator.","author":"martinvonz","id":"105323","dateCreated":"1572413915","dateModified":"1572413915"},{"type":"update","diffId":"17411","author":"joerg.sonnenberger","id":"105313","dateCreated":"1572292928","dateModified":"1572292928"},{"type":"update","diffId":"17410","author":"joerg.sonnenberger","id":"105307","dateCreated":"1572279428","dateModified":"1572279428"}],"dateCreated":"1572279427","dateModified":"1579212527","status":"Needs Review"},{"id":"7865","callsign":"HG","title":"rust-fmt: run cargo fmt","author":"Alphare","summary":"","testPlan":"","lineCount":"9","dependsOn":[],"reviewers":["pulkit"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"reject","author":"pulkit","id":"116219","dateCreated":"1579190240","dateModified":"1579190240"},{"type":"comment","comment":"This one fails to apply. Please rebase and resend.","author":"pulkit","id":"116218","dateCreated":"1579190070","dateModified":"1579190070"},{"type":"accept","author":"pulkit","id":"115667","dateCreated":"1579036350","dateModified":"1579036350"},{"type":"update","diffId":"19257","author":"Alphare","id":"115592","dateCreated":"1579023198","dateModified":"1579023198"}],"dateCreated":"1579023198","dateModified":"1579211388","status":"Needs Revision"},{"id":"7907","callsign":"HG","title":"rebase: always be graft-like, not merge-like, also for merges","author":"martinvonz","summary":"Rebase works by updating to a commit and then grafting changes on\ntop. However, before this patch, it would actually merge in changes\ninstead of grafting them in in some cases. That is, it would use the\ncommon ancestor as base instead of using one of the parents. That\nseems wrong to me, so I'm changing it so `defineparents()` always\nreturns a value for `base`.\n\nThis fixes the bad behavior in test-rebase-newancestor.t, which was\nintroduced in 65f215ea3e8e (tests: add test for rebasing merges with\nancestors of the rebase destination, 2014-11-30).\n\nThe difference in test-rebase-dest.t is because the files in the tip\nrevision were A, D, E, F before this patch and A, D, F, G after it. I\nthink both files should ideally be there.","testPlan":"","lineCount":"133","dependsOn":["7906"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19377","author":"martinvonz","id":"116268","dateCreated":"1579199034","dateModified":"1579199034"},{"type":"update","diffId":"19343","author":"martinvonz","id":"116079","dateCreated":"1579162215","dateModified":"1579162215"}],"dateCreated":"1579162215","dateModified":"1579199034","status":"Needs Review"},{"id":"7631","callsign":"HG","title":"absorb: allowing committed changes to be absorbed into their ancestors","author":"rdamazio","summary":"Like before, absorb continues to not touch the working directory, so any\nworking directory changes are preserved, even if the working directory parent\nchanges underneath (for instance, because the current revision was replaced\nwhen changes were absorbed into it).\n\nThis can also be combined with --interactive to absorb just part of a\ncommit into its parents.\n\nThis initial implementation has the shortcoming that it does not do anything\nwith the absorbed commit:\n- With obsmarkers, this means the user still needs to evolve, rebase or prune\n  manually\n- Without obsmarkers, the old commits would not be stripped at all because\n  their child was not replaced","testPlan":"","lineCount":"613","dependsOn":[],"reviewers":[],"ccs":["mharbison72","martinvonz","pulkit","quark","mercurial-devel"],"actions":[{"type":"inline","comment":"That's true in cmd.exe, but msys doesn't seem to care.  (That said, I thought check-code enforced quoting around `^`.)","replyTo":"115318","isNewFile":"1","line":"63","lineLength":"0","path":"tests\/test-absorb-rev.t","diffId":"19048","author":"mharbison72","id":"116260","dateCreated":"1579193370","dateModified":"1579193370"},{"type":"inline","comment":"nit: I think I've heard that `^` needs to be quoted on Windows, so maybe `-s '.^+.'`","replyTo":null,"isNewFile":"1","line":"63","lineLength":"0","path":"tests\/test-absorb-rev.t","diffId":"19048","author":"martinvonz","id":"115318","dateCreated":"1578936681","dateModified":"1578936681"},{"type":"inline","comment":"Maybe I'm also misunderstanding what this patch does in that case. `hg absorb -r A` will not obsolete A? I would think it definitely should do that. Perhaps the successors or the absorbed commit should be all the nodes absorbed into as well as any potential leftovers (which were not absorbed).","replyTo":"115301","isNewFile":"1","line":"993","lineLength":"0","path":"hgext\/absorb.py","diffId":"18728","author":"martinvonz","id":"115317","dateCreated":"1578936681","dateModified":"1578936681"},{"type":"comment","comment":">>! In D7631#112604, @rdamazio wrote:\n>>>! In D7631#112414, @quark wrote:\n>> `--rev` seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like `--source`, `--from`, `--target`?\n> \n> Done. Used `--source` to match `rebase`.\n\nSorry I didn't notice until now, but `--source` makes me think it will behave like `hg rebase --source` and absorb from the given commit and all its descendants. I would have preferred `--from` (and maybe a `--into` for choosing which commits to absorb into in the future).","author":"martinvonz","id":"115316","dateCreated":"1578936681","dateModified":"1578936681"},{"type":"inline","comment":"I locally added some `hg log --graph` calls before and after absorb call to understand what happens. It will be nice to add them as it will make things easier for others to understand.","replyTo":null,"isNewFile":"1","line":"72","lineLength":"0","path":"tests\/test-absorb-rev.t","diffId":"19048","author":"pulkit","id":"115302","dateCreated":"1578931522","dateModified":"1578931522"},{"type":"inline","comment":"Sorry, I misunderstood the patch earlier. `rewriteutil.precheck` on target rev is not very helpful as we are not obsolete-ing that in this rev, but we are re-writing it's ancestors. So, if target-rev is a head, and `evolution.alloworphans=False` is set, it will still create orphans.\n\nNot sure what's the best way forward, maybe we should do `rewriteutil.precheck` for the parent instead until we start obsoleting this rev.","replyTo":"113171","isNewFile":"1","line":"993","lineLength":"0","path":"hgext\/absorb.py","diffId":"18728","author":"pulkit","id":"115301","dateCreated":"1578931522","dateModified":"1578931522"},{"type":"inline","comment":"I suspect other places may want something similar (e.g. it'd make sense in `rebase --dest`, so I changed revsingle to add the behavior.","replyTo":"114395","isNewFile":"1","line":"1141","lineLength":"0","path":"hgext\/absorb.py","diffId":"18873","author":"rdamazio","id":"114545","dateCreated":"1578358005","dateModified":"1578358005"},{"type":"comment","comment":">>! In D7631#114393, @mharbison72 wrote:\n>>>! In D7631#112604, @rdamazio wrote:\n>>>>! In D7631#112414, @quark wrote:\n>>> `--rev` seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like `--source`, `--from`, `--target`?\n>> \n>> Done. Used `--source` to match `rebase`.\n> \n> Is `--exact` from `hg fold` a better model?  I don't feel strongly; I only mention it because `hg rebase -s` will take that revision and its descendants, so it's more like \"stack\" in my mind.  I'm not sure how many other commands have `-s` off the top of my head, but @martinvonz \n> mentioned adding that to `hg fix` (probably in IRC), and I think mentioned the word \"stack\" in that context.  So I might not be the only one to get slightly tripped up by that.\n\nIMHO no, needing `--exact` is actually confusing to almost every user we've talked to, and they'd instead expect that to be the default behavior, with \"fold up to this commit\" being the one that needs a specific flag.\n\n>> I'm assuming no fundamental objections then? Removing the \"RFC\" part so it gets a proper review then.\n> \n> I like it.\n\nThanks","author":"rdamazio","id":"114544","dateCreated":"1578358005","dateModified":"1578358005"},{"type":"update","diffId":"19048","author":"rdamazio","id":"114541","dateCreated":"1578357966","dateModified":"1578357966"},{"type":"inline","comment":"Should it abort if multiple revisions are given, instead of picking the latest?","replyTo":null,"isNewFile":"1","line":"1141","lineLength":"0","path":"hgext\/absorb.py","diffId":"18873","author":"mharbison72","id":"114395","dateCreated":"1577996461","dateModified":"1577996461"},{"type":"comment","comment":">>! In D7631#112604, @rdamazio wrote:\n>>>! In D7631#112414, @quark wrote:\n>> `--rev` seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like `--source`, `--from`, `--target`?\n> \n> Done. Used `--source` to match `rebase`.\n\nIs `--exact` from `hg fold` a better model?  I don't feel strongly; I only mention it because `hg rebase -s` will take that revision and its descendants, so it's more like \"stack\" in my mind.  I'm not sure how many other commands have `-s` off the top of my head, but @martinvonz \nmentioned adding that to `hg fix` (probably in IRC), and I think mentioned the word \"stack\" in that context.  So I might not be the only one to get slightly tripped up by that.\n\n> I'm assuming no fundamental objections then? Removing the \"RFC\" part so it gets a proper review then.\n\nI like it.\n","author":"mharbison72","id":"114394","dateCreated":"1577996461","dateModified":"1577996461"},{"type":"update","diffId":"18873","author":"rdamazio","id":"113351","dateCreated":"1576740998","dateModified":"1576740998"},{"type":"inline","comment":"s\/--rev\/--source","replyTo":null,"isNewFile":"1","line":"5","lineLength":"0","path":"relnotes\/next","diffId":"18843","author":"pulkit","id":"113262","dateCreated":"1576655750","dateModified":"1576655750"},{"type":"inline","comment":"s\/--rev\/--source","replyTo":null,"isNewFile":"1","line":"1113","lineLength":"0","path":"hgext\/absorb.py","diffId":"18843","author":"pulkit","id":"113261","dateCreated":"1576655750","dateModified":"1576655750"},{"type":"update","diffId":"18843","author":"rdamazio","id":"113172","dateCreated":"1576644411","dateModified":"1576644411"},{"type":"inline","comment":"Done. Notice that *technically* the user could do such an absorb while in the middle of a merge, but it sounds like a bad idea and inviting troubles, so I'm letting it also disallow that case. I'll be surprised if anyone even notices.","replyTo":"112977","isNewFile":"1","line":"993","lineLength":"0","path":"hgext\/absorb.py","diffId":"18728","author":"rdamazio","id":"113171","dateCreated":"1576644173","dateModified":"1576644173"},{"type":"comment","comment":"> Can you describe the feature a bit in the commit message. Specific things which I feel are missing:\n\nDone\n\n> Also, it will be nice if you add an entry in releasenotes.\n\nDone\n","author":"rdamazio","id":"113170","dateCreated":"1576644173","dateModified":"1576644173"},{"type":"update","diffId":"18841","author":"rdamazio","id":"113166","dateCreated":"1576644148","dateModified":"1576644148"},{"type":"inline","comment":"need to do more checks here about being public commit etc. `rewriteutil.precheck` should help.","replyTo":null,"isNewFile":"1","line":"993","lineLength":"0","path":"hgext\/absorb.py","diffId":"18728","author":"pulkit","id":"112977","dateCreated":"1576585756","dateModified":"1576585756"},{"type":"inline","comment":"`hg status|diff` should be a better command here.","replyTo":null,"isNewFile":"1","line":"73","lineLength":"0","path":"tests\/test-absorb-rev.t","diffId":"18728","author":"pulkit","id":"112976","dateCreated":"1576585756","dateModified":"1576585756"},{"type":"comment","comment":"Can you describe the feature a bit in the commit message. Specific things which I feel are missing:\n\n* what happens to wdir changes\n* what happens if source is a commit is not a head\n\nI understand them but after reading the tests, so might be worth to add them to description.\n\nAlso, it will be nice if you add an entry in releasenotes.","author":"pulkit","id":"112975","dateCreated":"1576585756","dateModified":"1576585756"},{"type":"update","diffId":"18728","author":"rdamazio","id":"112605","dateCreated":"1576304726","dateModified":"1576304726"},{"type":"comment","comment":">>! In D7631#112414, @quark wrote:\n> `--rev` seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like `--source`, `--from`, `--target`?\n\nDone. Used `--source` to match `rebase`.\n\nI'm assuming no fundamental objections then? Removing the \"RFC\" part so it gets a proper review then.\n\n","author":"rdamazio","id":"112604","dateCreated":"1576303338","dateModified":"1576303338"},{"type":"update","diffId":"18726","author":"rdamazio","id":"112598","dateCreated":"1576303328","dateModified":"1576303328"},{"type":"comment","comment":"`--rev` seems ambiguous since there might be different kinds of revisions to specify - target and revisions to edit. Maybe something like `--source`, `--from`, `--target`?","author":"quark","id":"112414","dateCreated":"1576261313","dateModified":"1576261313"},{"type":"update","diffId":"18666","author":"rdamazio","id":"112231","dateCreated":"1576216539","dateModified":"1576216539"}],"dateCreated":"1576216539","dateModified":"1579193370","status":"Needs Review"},{"id":"7796","callsign":"HG","title":"rust-nodemap: input\/output primitives","author":"gracinet","summary":"These allow to initiate a `NodeTree` from an immutable opaque\nsequence of bytes, which could be passed over from Python\n(extracted from a `PyBuffer`) or directly mmapped from a file.\n\nConversely, we can consume\na `NodeTree`, extracting the bytes that express what\nhas been added to the immutable part, together with the\noriginal immutable part.\nThis gives callers the choice to start a new Nodetree.\nAfter writing to disk, some would prefer to reread for\nbest guarantees (very cheap if mmapping), some others will\nfind it more convenient to grow the memory that was considered\nimmutable in the `NodeTree` and continue from there.\n\nIn `load_bytes`, we anticipate a bit on the file format for\nthe final version, allowing an offset for fixed data at the\nbeginning of the file.\n\nThis is enough to build examples running on real data and\nstart gathering performance hints.","testPlan":"","lineCount":"117","dependsOn":["7795"],"reviewers":["kevincox"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"Maybe what we should do is keep the test I proposed, but change the definition of `BLOCK_SIZE` to be based upon the number of contained `i32` instead of `size_of`.","author":"kevincox","id":"116198","dateCreated":"1579188938","dateModified":"1579188938"},{"type":"comment","comment":"Ah yes. So my test would be ineffective.\n\nThe problem that IIUC padding is not guaranteed to be initialized, and in rust all values need to be initialized. So if you cast a type with padding to a `u8` it is undefined behaviour.\n\nSo we would need a test that shows that the type is the same size as the sum of the contained `i32`s.","author":"kevincox","id":"116195","dateCreated":"1579188861","dateModified":"1579188861"},{"type":"comment","comment":"@kevincox (replying hastily because I'm also finishing something unrelated today).\nDoesn't `mem::size_of` guarantee to take any padding into account? At least that's what the doc seems to say: https:\/\/doc.rust-lang.org\/std\/mem\/fn.size_of.html\n","author":"gracinet","id":"116165","dateCreated":"1579179250","dateModified":"1579179250"},{"type":"inline","comment":"I thought about this more and I think I am okay doing it this way. It seems like this should be well defined as long as there is no padding. However on that note I would want to add a check that there is no padding as expected. I would also like to ensure that this fails to compile if there is ever padding, even in release mode. I think this can be accomplished by something like:\n\n```\nlet _: [u8; 4 * BLOCK_SIZE] = std::mem::transmute([Block::new(); 4]);\n```\n\nI would probably want to repeat this check near any code that is relying on this invariant.\n","replyTo":"116139","isNewFile":"1","line":"268","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19329","author":"kevincox","id":"116152","dateCreated":"1579176628","dateModified":"1579176628"},{"type":"inline","comment":"This is a weird API. Why does new take a buffer and an offset? Can it take either a slice or just remove the offset parameter and always have the buffer start at 0? It is very strange to be passing in data that we own but isn't ever used.","replyTo":null,"isNewFile":"1","line":"433","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19329","author":"kevincox","id":"116141","dateCreated":"1579173840","dateModified":"1579173840"},{"type":"inline","comment":"If someone panics between the `from_raw_parts` and `mem::forget` this is a double free. Right now I think this can't happen but it is completely possible that the code changes between then and now. I would prefer using `Vec::from_raw_parts` to make sure that there is only one `Vec` alive with that pointer at a time. This risks a leak in the face of panic but I think that is much better.","replyTo":null,"isNewFile":"1","line":"272","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19329","author":"kevincox","id":"116140","dateCreated":"1579173840","dateModified":"1579173840"},{"type":"inline","comment":"This makes me uncomfortable. There is really no guarantee that there is no padding around `Block` or `RawElement`. If there is any padding this is UB. I would much prefer one of:\n\n1. Store growable as a set of bytes and convert on get\/set.\n2. Add a method that outputs the bytes to any `Write`. In theory this will be slower but it is probably immaterial (especially if there is no padding). ","replyTo":null,"isNewFile":"1","line":"268","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19329","author":"kevincox","id":"116139","dateCreated":"1579173840","dateModified":"1579173840"},{"type":"reject","author":"kevincox","id":"116138","dateCreated":"1579173840","dateModified":"1579173840"},{"type":"update","diffId":"19329","author":"gracinet","id":"115989","dateCreated":"1579132082","dateModified":"1579132082"},{"type":"update","diffId":"19137","author":"gracinet","id":"115013","dateCreated":"1578668637","dateModified":"1578668637"},{"type":"update","diffId":"19045","author":"gracinet","id":"114518","dateCreated":"1578338757","dateModified":"1578338757"}],"dateCreated":"1578338757","dateModified":"1579188939","status":"Needs Revision"},{"id":"7798","callsign":"HG","title":"rust-nodemap: special case for prefixes of NULL_NODE","author":"gracinet","summary":"We have to behave as though NULL_NODE was stored in the node tree,\nalthough we don't store it.","testPlan":"","lineCount":"42","dependsOn":["7797"],"reviewers":["kevincox"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"accept","author":"kevincox","id":"116153","dateCreated":"1579176960","dateModified":"1579176960"},{"type":"update","diffId":"19330","author":"gracinet","id":"115990","dateCreated":"1579132101","dateModified":"1579132101"},{"type":"update","diffId":"19138","author":"gracinet","id":"115014","dateCreated":"1578668649","dateModified":"1578668649"},{"type":"update","diffId":"19047","author":"gracinet","id":"114534","dateCreated":"1578338770","dateModified":"1578338770"}],"dateCreated":"1578338770","dateModified":"1579176960","status":"Needs Review"},{"id":"7795","callsign":"HG","title":"rust-nodemap: insert method","author":"gracinet","summary":"In this implementation, we are in direct competition\nwith the C version: this Rust version will have a clear\nstartup advantage because it will read the data from disk,\nbut the insertion happens all in memory for both.","testPlan":"","lineCount":"272","dependsOn":["7794"],"reviewers":["kevincox"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"inline","comment":"Should these be `#[cfg(test)]`? We can always remove it later if there is a valid production use but it makes new users think twice.","replyTo":null,"isNewFile":"1","line":"504","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19328","author":"kevincox","id":"116137","dateCreated":"1579172517","dateModified":"1579172517"},{"type":"inline","comment":"nybble is very vague. Is this deepest_nibble or something?","replyTo":null,"isNewFile":"1","line":"306","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19328","author":"kevincox","id":"116136","dateCreated":"1579172517","dateModified":"1579172517"},{"type":"inline","comment":"I don't quite understand. You have the immutable copy and the mutable copy but that is WAI right?","replyTo":null,"isNewFile":"1","line":"273","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19328","author":"kevincox","id":"116135","dateCreated":"1579172517","dateModified":"1579172517"},{"type":"inline","comment":"It looks like this return value could use some abstraction but maybe its best to wait until there are more users?","replyTo":null,"isNewFile":"1","line":"268","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19328","author":"kevincox","id":"116134","dateCreated":"1579172517","dateModified":"1579172517"},{"type":"accept","author":"kevincox","id":"116133","dateCreated":"1579172517","dateModified":"1579172517"},{"type":"update","diffId":"19328","author":"gracinet","id":"115988","dateCreated":"1579132070","dateModified":"1579132070"},{"type":"update","diffId":"19044","author":"gracinet","id":"114510","dateCreated":"1578338750","dateModified":"1578338750"}],"dateCreated":"1578338750","dateModified":"1579172517","status":"Needs Review"},{"id":"7793","callsign":"HG","title":"rust-nodemap: mutable NodeTree data structure","author":"gracinet","summary":"Thanks to the previously indexing abstraction,\nthe only difference in the lookup algorithm is that we\ndon't need the special case for an empty NodeTree any more.\n\nWe've considered making the mutable root an `Option<Block>`,\nbut that leads to unpleasant checks and `unwrap()` unless we\nabstract it as typestate patterns (`NodeTree<Immutable>` and\n`NodeTree<Mutated>`) which seem exaggerated in that\ncase.\n\nThe initial copy of the root block is a very minor\nperformance penalty, given that it typically occurs just once\nper transaction.","testPlan":"","lineCount":"82","dependsOn":["7792"],"reviewers":["kevincox"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"inline","comment":"I would use https:\/\/doc.rust-lang.org\/std\/fmt\/struct.Formatter.html#method.debug_struct for consistency unless you really want to avoid printing the struct name.","replyTo":null,"isNewFile":"1","line":"249","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19326","author":"kevincox","id":"116111","dateCreated":"1579169708","dateModified":"1579169708"},{"type":"inline","comment":"This strikes me as a weird name. The fact that it is an adjective rather than a noun is a hint. Can you rename to answer \"Growable what?\"","replyTo":null,"isNewFile":"1","line":"158","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19326","author":"kevincox","id":"116110","dateCreated":"1579169708","dateModified":"1579169708"},{"type":"accept","author":"kevincox","id":"116109","dateCreated":"1579169708","dateModified":"1579169708"},{"type":"update","diffId":"19326","author":"gracinet","id":"115986","dateCreated":"1579132055","dateModified":"1579132055"},{"type":"update","diffId":"19136","author":"gracinet","id":"115012","dateCreated":"1578668620","dateModified":"1578668620"},{"type":"update","diffId":"19042","author":"gracinet","id":"114494","dateCreated":"1578338736","dateModified":"1578338736"}],"dateCreated":"1578338736","dateModified":"1579169708","status":"Needs Review"},{"id":"7792","callsign":"HG","title":"rust-nodemap: abstracting the indexing","author":"gracinet","summary":"In the forthcoming mutable implementation, we'll have to visit\nnode trees that are more complex than a single slice, although\nthe algorithm will still be expressed in simple indexing terms.\n\nWe still refrain using `#[inline]` indications as being\npremature optimizations, but we strongly hope the compiler will\nindeed inline most of the glue.","testPlan":"","lineCount":"21","dependsOn":["7791"],"reviewers":["kevincox"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"inline","comment":"I don't think this variable helps readability. I would just repeat `self.len()`.","replyTo":null,"isNewFile":"1","line":"192","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19325","author":"kevincox","id":"116108","dateCreated":"1579169456","dateModified":"1579169456"},{"type":"inline","comment":"I would add a `self.is_empty()` helper. It's good practice for anything that has a `.len()`.","replyTo":null,"isNewFile":"1","line":"193","lineLength":"0","path":"rust\/hg-core\/src\/revlog\/nodemap.rs","diffId":"19325","author":"kevincox","id":"116107","dateCreated":"1579169456","dateModified":"1579169456"},{"type":"accept","author":"kevincox","id":"116106","dateCreated":"1579169456","dateModified":"1579169456"},{"type":"update","diffId":"19325","author":"gracinet","id":"115985","dateCreated":"1579132049","dateModified":"1579132049"},{"type":"update","diffId":"19135","author":"gracinet","id":"115011","dateCreated":"1578668614","dateModified":"1578668614"},{"type":"update","diffId":"19041","author":"gracinet","id":"114486","dateCreated":"1578338729","dateModified":"1578338729"}],"dateCreated":"1578338729","dateModified":"1579169456","status":"Needs Review"},{"id":"7829","callsign":"HG","title":"rebase: remove some now-unused parent arguments","author":"martinvonz","summary":"","testPlan":"","lineCount":"14","dependsOn":["7828"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19347","author":"martinvonz","id":"116096","dateCreated":"1579162714","dateModified":"1579162714"},{"type":"update","diffId":"19149","author":"martinvonz","id":"115092","dateCreated":"1578725230","dateModified":"1578725230"}],"dateCreated":"1578725230","dateModified":"1579162715","status":"Needs Review"},{"id":"7828","callsign":"HG","title":"rebase: remove some redundant setting of dirstate parents","author":"martinvonz","summary":"Since we're now setting the dirstate parents to its correct values\nfrom the beginning (right after `merge.update()`), we usually don't\nneed to set them again before committing. The only case we need to\ncare about is when committing collapsed commits. So we can remove the\n`setparents()` calls just before committing and add one only for the\ncollapse case.","testPlan":"","lineCount":"4","dependsOn":["7827"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19346","author":"martinvonz","id":"116094","dateCreated":"1579162712","dateModified":"1579162712"},{"type":"comment","comment":"I'll rebase this on top of the series with D7859, which should make the test impact go away.","author":"martinvonz","id":"115647","dateCreated":"1579023266","dateModified":"1579023266"},{"type":"plan-changes","author":"martinvonz","id":"115645","dateCreated":"1579023266","dateModified":"1579023266"},{"type":"update","diffId":"19148","author":"martinvonz","id":"115084","dateCreated":"1578725229","dateModified":"1578725229"}],"dateCreated":"1578725229","dateModified":"1579162713","status":"Needs Review"},{"id":"7827","callsign":"HG","title":"rebase: don't use rebased node as dirstate p2 (BC)","author":"martinvonz","summary":"When rebasing a node, we currently use the rebased node as p2 in the\ndirstate until just before we commit it (we then change to the desired\nparents). This p2 is visible to the user when the rebase gets\ninterrupted because of merge conflicts. That can be useful to the user\nas a reminder of which commit is currently being rebased, but I\nbelieve it's incorrect for a few reasons:\n\n * I think the dirstate parents should be the ones that will be set\n   when the commit is created.\n\n * I think having two parents means that you're merging those two\n   commits, but when rebasing, you're generally grafting, not merging.\n\n * When rebasing a merge commit, we should use the two desired parents\n   as dirstate parents (and we clearly can't have the rebased node as\n   a third dirstate parent).\n\n * `hg graft` (and `hg update --merge`) sets only one parent and `hg\n   rebase` should be consistent with that.\n\nI realize that this is a somewhat large user-visible change, but I\nthink it's worth it because it will simplify things quite a bit.","testPlan":"","lineCount":"46","dependsOn":["7826"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19345","author":"martinvonz","id":"116093","dateCreated":"1579162710","dateModified":"1579162710"},{"type":"update","diffId":"19147","author":"martinvonz","id":"115076","dateCreated":"1578725227","dateModified":"1578725227"}],"dateCreated":"1578725227","dateModified":"1579162710","status":"Needs Review"},{"id":"7826","callsign":"HG","title":"rebase: stop relying on having two parents to resume rebase","author":"martinvonz","summary":"I'm about to make it so we don't have two parents when a rebase is\ninterrupted (unless we're just rebasing on a merge commit). The code\nfor detecting if we're resuming a rebase relied on having two parents,\nso this patch rewrites that to instead set a boolean when we resume.\n\nNote that `self.resume` in the new condition implies `not\nself.inmemory` (rebase cannot be resumed in memory), so that's why\nthat part can be omitted.","testPlan":"","lineCount":"5","dependsOn":["7824"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19344","author":"martinvonz","id":"116090","dateCreated":"1579162707","dateModified":"1579162707"},{"type":"update","diffId":"19146","author":"martinvonz","id":"115068","dateCreated":"1578725226","dateModified":"1578725226"}],"dateCreated":"1578725226","dateModified":"1579162708","status":"Needs Review"},{"id":"7824","callsign":"HG","title":"tests: add test of rebase with conflict in merge commit","author":"martinvonz","summary":"It doesn't seem like we had any tests of this. I think it's pretty\nweird that the two parents we're merging are not the working copy\nparents during the conflict resolution.","testPlan":"","lineCount":"71","dependsOn":["7907"],"reviewers":[],"ccs":["pulkit","mercurial-devel"],"actions":[{"type":"inline","comment":"I made more arguments for changing it in the next patch (D7827). See if those can convince you :)\n\nI'm not sure what you mean about not having correct conflicts. Related to that, I think it's actually weird (with how it's currently done) how you would not see any changes made between the merge base and the rebase base. So if there had been commits between `A` and `C` here and we were rebasing from `C`, we would not see those changes in the working copy. That's of course correct, but the dirstate's two parents suggest, IMO, that we're merging the two commits, so we should see those changes.\n\nI can see the value in having the thing you're grafting in as a working copy parent because it makes it appear in the `hg log` output as a reminder. However, I don't think that's what the purpose of the dirstate parent should be. We could perhaps add another  mechanism for showing the commit that's being rebased, and maybe also the base (which is generally not the merge base).\n","replyTo":"115194","isNewFile":"1","line":"460","lineLength":"0","path":"tests\/test-rebase-conflicts.t","diffId":"19144","author":"martinvonz","id":"115325","dateCreated":"1578939365","dateModified":"1578939365"},{"type":"inline","comment":"I think it will be weird to have current parents as 7 and 8. Rebase copies commit, so if there is a merge commit, it copies it instead of recreating one. Also if we have 7 and 8 as parents, we might not have correct conflicts.","replyTo":null,"isNewFile":"1","line":"460","lineLength":"0","path":"tests\/test-rebase-conflicts.t","diffId":"19144","author":"pulkit","id":"115194","dateCreated":"1578919684","dateModified":"1578919684"},{"type":"update","diffId":"19144","author":"martinvonz","id":"115052","dateCreated":"1578725223","dateModified":"1578725223"}],"dateCreated":"1578725223","dateModified":"1579162706","status":"Needs Review"},{"id":"7906","callsign":"HG","title":"rebase: define base in only place in defineparents()","author":"martinvonz","summary":"Just a little refactoring to prepare for the next patch.","testPlan":"","lineCount":"20","dependsOn":["7905"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19342","author":"martinvonz","id":"116071","dateCreated":"1579162214","dateModified":"1579162214"}],"dateCreated":"1579162214","dateModified":"1579162215","status":"Needs Review"},{"id":"7905","callsign":"HG","title":"rebase: move some variables after an error cases where they're not needed","author":"martinvonz","summary":"","testPlan":"","lineCount":"17","dependsOn":["7904"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19341","author":"martinvonz","id":"116064","dateCreated":"1579162212","dateModified":"1579162212"}],"dateCreated":"1579162212","dateModified":"1579162214","status":"Needs Review"},{"id":"7904","callsign":"HG","title":"rebase: clarify a little by calculating a set in Python instead of in revset","author":"martinvonz","summary":"By calculating the set in Python, we can give it a name, which helps\nreadability.","testPlan":"","lineCount":"3","dependsOn":["7902"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19340","author":"martinvonz","id":"116056","dateCreated":"1579162211","dateModified":"1579162211"}],"dateCreated":"1579162211","dateModified":"1579162212","status":"Needs Review"},{"id":"7902","callsign":"HG","title":"merge: introduce a clean_update() for that use-case","author":"martinvonz","summary":"In the same vein as the previous patch.","testPlan":"","lineCount":"16","dependsOn":["7901"],"reviewers":["durin42"],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19338","author":"martinvonz","id":"116042","dateCreated":"1579137681","dateModified":"1579137681"}],"dateCreated":"1579137681","dateModified":"1579162211","status":"Needs Review"},{"id":"7901","callsign":"HG","title":"merge: introduce a revert_to() for that use-case","author":"martinvonz","summary":"I find it hard to understand what value to pass for all the arguments\nto `merge.update()`. I would like to introduce functions that are more\nspecific to each use-case. We already have `graft()`. This patch\nintroduces a `revert_to()` and uses it in some places to show that it\nworks.","testPlan":"","lineCount":"34","dependsOn":["7900"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19337","author":"martinvonz","id":"116034","dateCreated":"1579137678","dateModified":"1579137678"}],"dateCreated":"1579137678","dateModified":"1579137681","status":"Needs Review"},{"id":"7900","callsign":"HG","title":"merge: avoid a negation in the definition of updatedirstate","author":"martinvonz","summary":"We only use `partial` in one place: the definition of\n`updatedirstate`. Let's simplify that a little.","testPlan":"","lineCount":"7","dependsOn":["7899"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19336","author":"martinvonz","id":"116026","dateCreated":"1579137676","dateModified":"1579137676"}],"dateCreated":"1579137676","dateModified":"1579137678","status":"Needs Review"},{"id":"7899","callsign":"HG","title":"merge: define updatedirstate a little earlier and reuse it","author":"martinvonz","summary":"","testPlan":"","lineCount":"4","dependsOn":["7898"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"19335","author":"martinvonz","id":"116019","dateCreated":"1579137674","dateModified":"1579137674"}],"dateCreated":"1579137674","dateModified":"1579137676","status":"Needs Review"},{"id":"7797","callsign":"HG","title":"rust-nodemap: pure Rust example","author":"gracinet","summary":"To run, use `cargo run --release --example nodemap`\n\nThis demonstrates that simple scenarios entirely written\nin Rust can content themselves with `NodeTree<T>`.\n\nThe example mmaps both the nodemap file and the revlog index.\nWe had of course to include an implementation of `RevlogIndex`\ndirectly, which isn't much at this stage. It felt a bit\nprematurate to include it in the lib.\n\nHere are some first performance measurements, obtained with\nthis example, on a clone of mozilla-central with 440000\nchangesets:\n\n  (create) Nodemap constructed in RAM in 153.638305ms\n  (query CAE63161B68962) found in 22.362us: Ok(Some(269489))\n  (bench) Did 3 queries in 36.418\u00b5s (mean 12.139\u00b5s)\n  (bench) Did 50 queries in 184.318\u00b5s (mean 3.686\u00b5s)\n  (bench) Did 100000 queries in 31.053461ms (mean 310ns)\n\nTo be fair, even between bench runs, results tend to depend whether\nthe file is still in kernel caches, and it's not so easy to\nget back to a real cold start. The worst we've seen was in the\n50us ballpark.\n\nIn any busy server setting, the pages would always be in RAM.\n\nWe hope it's good enough not to be significantly slower on any\nconcrete Mercurial operation than the C nodetree when fully in RAM,\nand of course this implementation has the serious headstart advantage\nof persistence.","testPlan":"","lineCount":"316","dependsOn":["7796"],"reviewers":[],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"19046","author":"gracinet","id":"114526","dateCreated":"1578338763","dateModified":"1578338763"}],"dateCreated":"1578338763","dateModified":"1579132093","status":"Needs Review"},{"id":"7730","callsign":"HG","title":"rebase: make sure pruning does not confuse rebase (issue6180)","author":"khanchi97","summary":"Before this patch, if a user is rebasing a stack of commits and\nhit a conflict in between and decided to drop that commit (the commit\nwhich is being rebased but hit conflict) and pruned it, now what\n`hg rebase --continue` does is: skip that dropped commit and move\non to rebase the next commit and gets confused here because wdir\nhas two parents which is because while we skipped that dropped\ncommit wdir had two parents and we didn't update that to one parent.\n\nChanges in test file demonstrate the fixed behavior.","testPlan":"","lineCount":"11","dependsOn":["7728"],"reviewers":["martinvonz"],"ccs":["pulkit","mercurial-devel"],"actions":[{"type":"inline","comment":"Actually, doesn't this need to be `wctx.setparents()` (which you can do now that D7822 has been queued) in order to work with in-memory rebase? Maybe time to add a test case with in-memory rebase?","replyTo":null,"isNewFile":"1","line":"600","lineLength":"0","path":"hgext\/rebase.py","diffId":"19283","author":"martinvonz","id":"115947","dateCreated":"1579106322","dateModified":"1579106322"},{"type":"inline","comment":"No need, I've already sent D7827","replyTo":"115783","isNewFile":"1","line":"597","lineLength":"0","path":"hgext\/rebase.py","diffId":"18939","author":"martinvonz","id":"115944","dateCreated":"1579106125","dateModified":"1579106125"},{"type":"inline","comment":"I will look into it.","replyTo":"114713","isNewFile":"1","line":"597","lineLength":"0","path":"hgext\/rebase.py","diffId":"18939","author":"khanchi97","id":"115783","dateCreated":"1579093511","dateModified":"1579093511"},{"type":"comment","comment":">>! In D7730#114953, @pulkit wrote:\n> Unrelated to the fix, we need better way to skip commits during rebasing. Pruning manually is not a good option, IIRC git rebase have a `--skip` flag.\n\nYeah, that's a good idea. We should also have --skip flag to skip the commit on which rebase got interrupted.","author":"khanchi97","id":"115781","dateCreated":"1579093387","dateModified":"1579093387"},{"type":"update","diffId":"19283","author":"khanchi97","id":"115766","dateCreated":"1579084952","dateModified":"1579084952"},{"type":"comment","comment":"Unrelated to the fix, we need better way to skip commits during rebasing. Pruning manually is not a good option, IIRC git rebase have a `--skip` flag.","author":"pulkit","id":"114953","dateCreated":"1578579692","dateModified":"1578579692"},{"type":"inline","comment":"I think it's incorrect that rebase sets two parents while the merge is being resolved, but that's out of scope for this patch.","replyTo":null,"isNewFile":"1","line":"597","lineLength":"0","path":"hgext\/rebase.py","diffId":"18939","author":"martinvonz","id":"114713","dateCreated":"1578505063","dateModified":"1578505063"},{"type":"inline","comment":"Should this be `self.wctx.parents()` to work with in-memory rebase?","replyTo":null,"isNewFile":"1","line":"598","lineLength":"0","path":"hgext\/rebase.py","diffId":"18939","author":"martinvonz","id":"114712","dateCreated":"1578505063","dateModified":"1578505063"},{"type":"comment","comment":"Ping.","author":"khanchi97","id":"114663","dateCreated":"1578483218","dateModified":"1578483218"},{"type":"update","diffId":"18939","author":"khanchi97","id":"113800","dateCreated":"1577466343","dateModified":"1577466343"}],"dateCreated":"1577466343","dateModified":"1579106324","status":"Needs Review"},{"id":"7728","callsign":"HG","title":"rebase: add test to demonstrate issue6180","author":"khanchi97","summary":"It will be fixed in next patch.","testPlan":"","lineCount":"58","dependsOn":[],"reviewers":[],"ccs":["pulkit","mercurial-devel"],"actions":[{"type":"update","diffId":"19282","author":"khanchi97","id":"115765","dateCreated":"1579084940","dateModified":"1579084940"},{"type":"inline","comment":"You don't need to redefine it.","replyTo":null,"isNewFile":"1","line":"438","lineLength":"0","path":"tests\/test-rebase-conflicts.t","diffId":"18937","author":"pulkit","id":"114951","dateCreated":"1578579588","dateModified":"1578579588"},{"type":"comment","comment":"Ping.","author":"khanchi97","id":"114662","dateCreated":"1578483193","dateModified":"1578483193"},{"type":"update","diffId":"18937","author":"khanchi97","id":"113781","dateCreated":"1577465814","dateModified":"1577465814"}],"dateCreated":"1577465814","dateModified":"1579084940","status":"Needs Review"},{"id":"7630","callsign":"HG","title":"absorb: make the absorbed changeset be automatically \"evolved\"","author":"rdamazio","summary":"When a committed changeset is absorbed, this will make it so it's not used for\ncomputing the absorption, but is still recreated at the destination.","testPlan":"","lineCount":"58","dependsOn":["7631"],"reviewers":[],"ccs":["pulkit","martinvonz","mercurial-devel"],"actions":[{"type":"comment","comment":">> This results in an empty commit which is not similar to what rebase or evolve will generally result in after `D7631` unless `ui.allowemptycommit=True` is set. I think good behavior is to obsolete the absorbed changeset in favour of either it's parent or one of the revs in which it was absorbed. \n> \n> I made a related comment on the parent patch before I realized that this patch adds obsmarker handling. My suggestion there was to mark all the commits that got absorbed into as successors, and if there's anything left in the absorbed commit, that would be yet another successor. Would that work?\n\nYep, that sounds good.\n","author":"pulkit","id":"115320","dateCreated":"1578937060","dateModified":"1578937078"},{"type":"comment","comment":">>! In D7630#112603, @rdamazio wrote:\n> Sorry for the upload mess (though it's arguably a `phabsend` bug :) ). Tried uploading the \"right\" way now.\n\nI reported that as https:\/\/bz.mercurial-scm.org\/show_bug.cgi?id=6241.\n\n>>! In D7630#115300, @pulkit wrote:\n> This results in an empty commit which is not similar to what rebase or evolve will generally result in after `D7631` unless `ui.allowemptycommit=True` is set. I think good behavior is to obsolete the absorbed changeset in favour of either it's parent or one of the revs in which it was absorbed. \n\nI made a related comment on the parent patch before I realized that this patch adds obsmarker handling. My suggestion there was to mark all the commits that got absorbed into as successors, and if there's anything left in the absorbed commit, that would be yet another successor. Would that work?","author":"martinvonz","id":"115319","dateCreated":"1578936945","dateModified":"1578936945"},{"type":"comment","comment":"This results in an empty commit which is not similar to what rebase or evolve will generally result in after `D7631` unless `ui.allowemptycommit=True` is set. I think good behavior is to obsolete the absorbed changeset in favour of either it's parent or one of the revs in which it was absorbed. ","author":"pulkit","id":"115300","dateCreated":"1578931057","dateModified":"1578931057"},{"type":"update","diffId":"19049","author":"rdamazio","id":"114543","dateCreated":"1578357967","dateModified":"1578357967"},{"type":"update","diffId":"18874","author":"rdamazio","id":"113354","dateCreated":"1576741000","dateModified":"1576741000"},{"type":"update","diffId":"18844","author":"rdamazio","id":"113173","dateCreated":"1576644413","dateModified":"1576644413"},{"type":"update","diffId":"18842","author":"rdamazio","id":"113169","dateCreated":"1576644149","dateModified":"1576644149"},{"type":"update","diffId":"18729","author":"rdamazio","id":"112606","dateCreated":"1576304727","dateModified":"1576304727"},{"type":"comment","comment":"Sorry for the upload mess (though it's arguably a `phabsend` bug :) ). Tried uploading the \"right\" way now.","author":"rdamazio","id":"112603","dateCreated":"1576303334","dateModified":"1576303334"},{"type":"update","diffId":"18727","author":"rdamazio","id":"112600","dateCreated":"1576303329","dateModified":"1576303329"},{"type":"comment","comment":">>! In D7630#112243, @rdamazio wrote:\n> (on mobile) I think it was `hg phabsend -r .+.^`\n\nOhh, that makes some sense that phabsend might do it backwards if you pass the revisions backwards, but that's still clearly a bug. I'll report it in bugzilla if it's not already there. I'll manually update the parent\/child relationship on these reviews for now.\n","author":"martinvonz","id":"112244","dateCreated":"1576220268","dateModified":"1576220268"},{"type":"comment","comment":"(on mobile) I think it was `hg phabsend -r .+.^`\n\n  - {F454947, layout=link}","author":"rdamazio","id":"112243","dateCreated":"1576219938","dateModified":"1576219938"},{"type":"inline","comment":"Oh, it's added in D7631, which is marked as a *child* of this review. How did that happen? `hg phabsend` should set the relationships automatically. How did you run that command? Just `hg phabsend .^::.` or  similar? Or did you manually mark D7631 as a child?","replyTo":"112239","isNewFile":"1","line":"67","lineLength":"0","path":"tests\/test-absorb-rev.t","diffId":"18665","author":"martinvonz","id":"112241","dateCreated":"1576219632","dateModified":"1576219632"},{"type":"inline","comment":"`hg absorb` has a `-r` flag? Did you forgot to upload some ancestors of this commit?","replyTo":null,"isNewFile":"1","line":"67","lineLength":"0","path":"tests\/test-absorb-rev.t","diffId":"18665","author":"martinvonz","id":"112239","dateCreated":"1576217462","dateModified":"1576217462"},{"type":"update","diffId":"18665","author":"rdamazio","id":"112225","dateCreated":"1576216538","dateModified":"1576216538"}],"dateCreated":"1576216538","dateModified":"1578937060","status":"Needs Review"},{"id":"7574","callsign":"HG","title":"hg-core: add utils::path to project","author":"indygreg","summary":"This module was vendored in the previous commit but was not integrated into\nthe project. This commit performs that integration.\n\nAs part of this, we have to add a handful of new dependencies. The new\ndependencies all seem quite reasonable. The versions taken were the exact\nones used by the upstream project.","testPlan":"","lineCount":"309","dependsOn":[],"reviewers":["pulkit"],"ccs":["Alphare","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"This one fails to apply with conflicts in `Cargo.lock`.","author":"pulkit","id":"115314","dateCreated":"1578933699","dateModified":"1578933699"},{"type":"reject","author":"pulkit","id":"115313","dateCreated":"1578933699","dateModified":"1578933699"},{"type":"accept","author":"pulkit","id":"115309","dateCreated":"1578933323","dateModified":"1578933323"},{"type":"inline","comment":"I actually wasn't aware of `anyhow` before writing this patch. And I have to say that I really like `anyhow` because it is simpler than other crates in this space while offering much of the same functionality.\n\nI think it is inevitable that we'll want to use a crate like `anyhow` for more advanced error handling. If nothing else, it can help cut down on boilerplate code around error handling.","replyTo":"111442","isNewFile":"1","line":"12","lineLength":"0","path":"rust\/hg-core\/Cargo.toml","diffId":"18534","author":"indygreg","id":"113657","dateCreated":"1577124884","dateModified":"1577124884"},{"type":"inline","comment":"Should we adopt this crate for error handling?\n\nI feel like our current solution - although it might need a refactor - is good at forcing the programmer to provide context with finer-grained errors that what you are required to do with `anyhow`.  I actually like `anyhow` better than more involved crates, but we will need to have a good \"error hygiene\" if you will.\n\nThis seems like a better place to discuss this than the previous patch.","replyTo":null,"isNewFile":"1","line":"12","lineLength":"0","path":"rust\/hg-core\/Cargo.toml","diffId":"18534","author":"Alphare","id":"111442","dateCreated":"1575888850","dateModified":"1575888850"},{"type":"update","diffId":"18534","author":"indygreg","id":"111325","dateCreated":"1575749869","dateModified":"1575749869"}],"dateCreated":"1575749869","dateModified":"1578933699","status":"Needs Revision"},{"id":"7575","callsign":"HG","title":"hg-core: vendor Facebook's configparser crate","author":"indygreg","summary":"I added a number of files from https:\/\/github.com\/facebookexperimental\/eden\nat commit b745b4421b8a8b130d2094b598cedf65655410ec. Files are unmodified from\ntheir original versions. However, the paths are different: I've put all\nfiles in the same directory. And I've removed some files we don't care about\n(such as the C++ bindings and CMake rules). Notably missing is the\nauto-generated parser.rs and the Python script to generate it. We will\nbe able to generate this file automatically at build time (unlike\nFacebook, which is constrained by not using Cargo or something).\n\nThe added files are not part of the hg-core project yet. Things will be\nincorporated in future commits.\n\nI haven't extensively audited the added code for functional correctness\nand compatibility. But I did skim it and it seems to be a highly compatible\nconfig parsing implementation. The most suspect code I found was around\nconfig file path handling. There are references to \"tupperware,\" which\nappears to be a Facebook-specific thing. We will want to clean this up\nat some point...","testPlan":"","lineCount":"2319","dependsOn":["7574"],"reviewers":[],"ccs":["pulkit","Alphare","quark","durin42","kevincox","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":"The C bindings need to be dropped in this patch. Queued the previous patches, many thanks for importing things!","author":"pulkit","id":"115312","dateCreated":"1578933475","dateModified":"1578933475"},{"type":"inline","comment":"+1, I'm not sure what the use case for this would be in core.","replyTo":"111444","isNewFile":"1","line":"1","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/c_api.rs","diffId":"18545","author":"durin42","id":"111896","dateCreated":"1576086289","dateModified":"1576086289"},{"type":"inline","comment":"My bad, it looks like you took care of it in a future patch.","replyTo":"111445","isNewFile":"1","line":"226","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18545","author":"Alphare","id":"111457","dateCreated":"1575896534","dateModified":"1575896534"},{"type":"inline","comment":"`pest` is really cool.","replyTo":null,"isNewFile":"1","line":"63","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/spec.pest","diffId":"18545","author":"Alphare","id":"111449","dateCreated":"1575891512","dateModified":"1575891512"},{"type":"inline","comment":"Is this hack still needed as of `1.34.2`?","replyTo":null,"isNewFile":"1","line":"595","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18545","author":"Alphare","id":"111448","dateCreated":"1575891512","dateModified":"1575891512"},{"type":"inline","comment":"Our current strategy is to assume config files to be in local encoding, not UTF-8. This makes sense from Facebook's perspective, but now as an upstream solution (see previous work on `HgPath`).","replyTo":null,"isNewFile":"1","line":"413","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18545","author":"Alphare","id":"111447","dateCreated":"1575891512","dateModified":"1575891512"},{"type":"inline","comment":"+1","replyTo":"111406","isNewFile":"1","line":"262","lineLength":"1","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18535","author":"Alphare","id":"111446","dateCreated":"1575891512","dateModified":"1575891512"},{"type":"inline","comment":"This function looks very Facebook specific, I don't think we want to include it at all.","replyTo":null,"isNewFile":"1","line":"226","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18545","author":"Alphare","id":"111445","dateCreated":"1575891512","dateModified":"1575891512"},{"type":"inline","comment":"Do we need bindings to C ? I don't see what the use-case is at this stage of the Rust development.","replyTo":null,"isNewFile":"1","line":"1","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/c_api.rs","diffId":"18545","author":"Alphare","id":"111444","dateCreated":"1575891512","dateModified":"1575891512"},{"type":"update","diffId":"18545","author":"indygreg","id":"111411","dateCreated":"1575774205","dateModified":"1575774205"},{"type":"comment","comment":"Thank you for the feedback, @quark! You enlightened me to a few issues I missed during my very quick perusal.\n\nI agree that doing away with the auto-generated `parser.rs` feels like a better solution. I may revise this series yet again...","author":"indygreg","id":"111408","dateCreated":"1575760222","dateModified":"1575760222"},{"type":"inline","comment":"You might want to revert D13875655 for the directory include feature, which has some test changes.","replyTo":null,"isNewFile":"1","line":"72","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/config.rs","diffId":"18535","author":"quark","id":"111407","dateCreated":"1575760006","dateModified":"1575760006"},{"type":"inline","comment":"You might want to respect `$PAGER`. We ignored it to reduce support burden for mis-configuration. ","replyTo":null,"isNewFile":"1","line":"262","lineLength":"1","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18535","author":"quark","id":"111406","dateCreated":"1575760006","dateModified":"1575760006"},{"type":"inline","comment":"You might want to remove these lines.","replyTo":null,"isNewFile":"1","line":"141","lineLength":"3","path":"rust\/hg-core\/src\/configparser\/hg.rs","diffId":"18535","author":"quark","id":"111405","dateCreated":"1575760006","dateModified":"1575760006"},{"type":"inline","comment":"You might want to follow this and remove the generated code.","replyTo":null,"isNewFile":"1","line":"103","lineLength":"4","path":"rust\/hg-core\/src\/configparser\/generate_parser.py","diffId":"18535","author":"quark","id":"111404","dateCreated":"1575760006","dateModified":"1575760006"},{"type":"update","diffId":"18535","author":"indygreg","id":"111333","dateCreated":"1575749870","dateModified":"1575749870"}],"dateCreated":"1575749870","dateModified":"1578933475","status":"Needs Review"},{"id":"7576","callsign":"HG","title":"hg-core: add configparser to library","author":"indygreg","summary":"This commit contains all the changes to the recently-imported\nRust code to make it work with our Rust library and pass our\nlinting tests.\n\nWe rename lib.rs to mod.rs to reflect it being a sub-module instead\nof a full library. We add this module to our lib.rs. We add various\npackage dependencies to Cargo.toml. We make a handful of Rust code\nupdates to reflect the new symbol locations. Finally, we add a\nparser.rs containing the boilerplate for generating a config file\nparser from the spec.pest file.\n\nAs part of adding the dependencies, some versions changed slightly\nfrom the upstream Cargo.toml, as we already had referenced a more\nmodern crate version.","testPlan":"","lineCount":"305","dependsOn":["7582"],"reviewers":[],"ccs":["Alphare","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"I'm a little lost on the state of this. It looks like we need to downgrade the required Rust version?","author":"durin42","id":"114846","dateCreated":"1578513514","dateModified":"1578513514"},{"type":"inline","comment":"I know it doesn't matter at all, but the timing of this issue is just too funny not to share: https:\/\/github.com\/tokio-rs\/bytes\/issues\/340","replyTo":"111969","isNewFile":"1","line":"14","lineLength":"0","path":"rust\/hg-core\/Cargo.toml","diffId":"18547","author":"Alphare","id":"112098","dateCreated":"1576180674","dateModified":"1576180674"},{"type":"inline","comment":"I wonder about this dependency. It uses 4 `usize` for every slice of bytes, and adds some overhead, albeit minimal, that I am trying to justify.\nAre we looking at reaping the benefits down the line? The crate itself is good quality, maintained by the Tokio people, so I'm not *too* worried about it being pre-1.0, but do we need this? ","replyTo":null,"isNewFile":"1","line":"14","lineLength":"0","path":"rust\/hg-core\/Cargo.toml","diffId":"18547","author":"Alphare","id":"111969","dateCreated":"1576140492","dateModified":"1576140492"},{"type":"inline","comment":"\"The current minimum required Rust version is 1.36\". This disqualifies this crate from being used in `hg-core` right now. Good news is that it is supposed to offer improvements over existing `std` types like `Mutex` and the like, so it's nothing that would be hard to replace. \n\nAlso, I've seen complaints online about the lack of benchmarks of `parking_lot` against `std` types to back-up their claims for performance. I have not looked into it myself.","replyTo":null,"isNewFile":"1","line":"19","lineLength":"0","path":"rust\/hg-core\/Cargo.toml","diffId":"18547","author":"Alphare","id":"111455","dateCreated":"1575896446","dateModified":"1575896446"},{"type":"update","diffId":"18547","author":"indygreg","id":"111419","dateCreated":"1575774207","dateModified":"1575774207"},{"type":"update","diffId":"18541","author":"indygreg","id":"111381","dateCreated":"1575759414","dateModified":"1575759414"},{"type":"update","diffId":"18536","author":"indygreg","id":"111341","dateCreated":"1575749872","dateModified":"1575749872"}],"dateCreated":"1575749872","dateModified":"1578513515","status":"Needs Review"},{"id":"7786","callsign":"HG","title":"update: add --abort option in hg update command (issue4404)","author":"khanchi97","summary":"Here is, what --abort option is basically doing:\n1) hg resolve --unmark, then\n2) hg resolve --all --tool :local\n3) hg up <original ctx> --tool :local\n\nWhere,\nstep 1) is to mark all the files conflicted as unresolved (marking *all*\nfiles to make sure that it also mark the files which might have been\nresolved by user in meantime)\n\nstep 2) resolve all the conflicting files using `--tool :local`\n\nstep 3) update to the revision where it was checkedout before running the\nhg update, using `--tool :local`\n\nUse of `--tool :local` while updating to old revision (step3) make sure that\nit will not hit merge conflict at the time of update. And since we are using\nthe same tool (:local) as we used at the time of resolution (step2) it makes\nsure that we have exact changes in working directory as it was before IIUC.\n\nAdded tests demonstrate the behaviour of new flag.","testPlan":"","lineCount":"97","dependsOn":[],"reviewers":["mharbison72"],"ccs":["mharbison72","mercurial-devel"],"actions":[{"type":"comment","comment":"This looks like a respin of D6735.  Can you take a look at my comments in there about subrepos, and incorporate the appropriate tests?  (I also didn't side by side compare the existing tests, so I'm not sure if there are things tested in that revision that aren't tested here.)","author":"mharbison72","id":"114439","dateCreated":"1578121196","dateModified":"1578121196"},{"type":"reject","author":"mharbison72","id":"114437","dateCreated":"1578121196","dateModified":"1578121196"},{"type":"update","diffId":"19034","author":"khanchi97","id":"114431","dateCreated":"1578063940","dateModified":"1578063940"}],"dateCreated":"1578063940","dateModified":"1578121197","status":"Needs Revision"},{"id":"6735","callsign":"HG","title":"update: added support for --abort flag(issue4404)","author":"taapas1128","summary":"This patch adds functionality to abort a conflicted\nupdate. A new function `hg.abortupdate()` is added for\nthe purpose which has a helper function\n`hg._unmarkandresolvelocal()` which deals with the\nconflicts occured.\n\nResults are shown in tests.","testPlan":"","lineCount":"210","dependsOn":[],"reviewers":["durin42","mharbison72"],"ccs":["durin42","mharbison72","pulkit","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":"Here's a case I stumbled upon that is a problem.  It looks like it thinks it isn't in the middle of an update, but .hgsubstate isn't put back to the pre-update state.\n\n```\ndiff --git a\/tests\/test-subrepo.t b\/tests\/test-subrepo.t\n--- a\/tests\/test-subrepo.t\n+++ b\/tests\/test-subrepo.t\n@@ -1027,10 +1027,38 @@ filesystem (see also issue4583))\n   > [extensions]\n   > fakedirstatewritetime = $TESTDIR\/fakedirstatewritetime.py\n   > EOF\n+  $ hg -R repo st -S\n+  ? s\/b\n+  $ hg -R repo diff -S\n+  $ hg -R repo log -r .\n+  changeset:   0:c4018e9aea1b\n+  user:        test\n+  date:        Thu Jan 01 00:00:00 1970 +0000\n+  summary:     1\n+\n+  $ cat repo\/.hgsubstate\n+  f7b1eb17ad24730a1651fccd46c43826d1bbc2ac s\n   $ hg -R repo update\n   b: untracked file differs\n   abort: untracked files in working directory differ from files in requested revision (in subrepository \"s\")\n   [255]\n+  $ hg -R repo update --abort\n+  abort: no update in progress\n+  [255]\n+  $ hg -R repo diff -S\n+  diff -r c4018e9aea1b .hgsubstate\n+  --- a\/.hgsubstate Thu Jan 01 00:00:00 1970 +0000\n+  +++ b\/.hgsubstate Thu Jan 01 00:00:00 1970 +0000\n+  @@ -1,1 +1,1 @@\n+  -f7b1eb17ad24730a1651fccd46c43826d1bbc2ac s\n+  +cc505f09a8b2644adffa368adb4abc6f70d07bc0 s\n+  $ hg -R repo log -r .\n+  changeset:   0:c4018e9aea1b\n+  user:        test\n+  date:        Thu Jan 01 00:00:00 1970 +0000\n+  summary:     1\n+\n+\n   $ cat >> repo\/.hg\/hgrc <<EOF\n   > [extensions]\n   > fakedirstatewritetime = !\n```\n\nAnother good way to induce this .hgsubstate issue is to `hg pull -u` on a repo, where the remote subrepo isn't available.  You don't need http for this- you can just rename the remote subrepo.","author":"mharbison72","id":"100642","dateCreated":"1568603671","dateModified":"1568603671"},{"type":"comment","comment":"Oops, meant to flag changes needed too.","author":"mharbison72","id":"100435","dateCreated":"1568266462","dateModified":"1568266462"},{"type":"reject","author":"mharbison72","id":"100434","dateCreated":"1568266462","dateModified":"1568266462"},{"type":"comment","comment":">>! In D6735#100392, @durin42 wrote:\n> This looks good to me. Does anyone else have comments? @mharbison72 are you happy with the subrepo test coverage?\n\nI forgot about this, thanks for the reminder.  @taapas1128 is correct- the subrepos aren't being initialized as subrepos (i.e. there's no .hgsub file).  I'll try to play with this more Friday or over the weekend.","author":"mharbison72","id":"100433","dateCreated":"1568266403","dateModified":"1568266403"},{"type":"comment","comment":"@durin42 I don't think the subrepos are properly initialized in the tests. I would be updating them soon.","author":"taapas1128","id":"100416","dateCreated":"1568219239","dateModified":"1568219239"},{"type":"comment","comment":"This looks good to me. Does anyone else have comments? @mharbison72 are you happy with the subrepo test coverage?","author":"durin42","id":"100392","dateCreated":"1568215450","dateModified":"1568215450"},{"type":"accept","author":"durin42","id":"100391","dateCreated":"1568215450","dateModified":"1568215450"},{"type":"inline","comment":"@mharbison72 Have a look. I have updated the diff.","replyTo":"98964","isNewFile":"1","line":"2092","lineLength":"0","path":"tests\/test-merge-tools.t","diffId":"16251","author":"taapas1128","id":"99147","dateCreated":"1566483696","dateModified":"1566483696"},{"type":"update","diffId":"16294","author":"taapas1128","id":"99144","dateCreated":"1566483618","dateModified":"1566483618"},{"type":"inline","comment":"When you add more tests, please include some with 1 dirty subrepo, and then another where the first subrepo is already merged\/resolved, and the second subrepo is dirty and pending a merge\/resolve.  If it simplifies the initial implementation to detect a dirty subrepo and then abort the `--abort` before it starts, that seems fine.","replyTo":"98944","isNewFile":"1","line":"2092","lineLength":"0","path":"tests\/test-merge-tools.t","diffId":"16251","author":"mharbison72","id":"98964","dateCreated":"1566232323","dateModified":"1566232323"},{"type":"inline","comment":"this line is not required.","replyTo":null,"isNewFile":"1","line":"992","lineLength":"0","path":"mercurial\/hg.py","diffId":"16262","author":"pulkit","id":"98962","dateCreated":"1566228426","dateModified":"1566228426"},{"type":"comment","comment":"Nice start! If I remember correctly, the mergestate stores the local version of the file. We can use that directly instead.","author":"pulkit","id":"98961","dateCreated":"1566228426","dateModified":"1566228426"},{"type":"update","diffId":"16262","author":"taapas1128","id":"98945","dateCreated":"1566135118","dateModified":"1566135118"},{"type":"inline","comment":"I have created a separate file will add more tests.","replyTo":"98873","isNewFile":"1","line":"2092","lineLength":"0","path":"tests\/test-merge-tools.t","diffId":"16251","author":"taapas1128","id":"98944","dateCreated":"1566133737","dateModified":"1566133737"},{"type":"update","diffId":"16261","author":"taapas1128","id":"98942","dateCreated":"1566133621","dateModified":"1566133621"},{"type":"inline","comment":"we need to hide this, maybe use more low level APIs. I haven't look at code in details, will try to look soon.","replyTo":null,"isNewFile":"1","line":"2129","lineLength":"0","path":"tests\/test-merge-tools.t","diffId":"16251","author":"pulkit","id":"98874","dateCreated":"1566070139","dateModified":"1566070139"},{"type":"inline","comment":"I suggest taking `update --abort` tests in a new file as we will need to extensively test that.","replyTo":null,"isNewFile":"1","line":"2092","lineLength":"0","path":"tests\/test-merge-tools.t","diffId":"16251","author":"pulkit","id":"98873","dateCreated":"1566070139","dateModified":"1566070139"},{"type":"update","diffId":"16251","author":"taapas1128","id":"98867","dateCreated":"1566069370","dateModified":"1566069370"},{"type":"update","diffId":"16250","author":"taapas1128","id":"98866","dateCreated":"1566058705","dateModified":"1566058705"},{"type":"update","diffId":"16249","author":"taapas1128","id":"98861","dateCreated":"1566058419","dateModified":"1566058419"}],"dateCreated":"1566058419","dateModified":"1578121196","status":"Needs Revision"},{"id":"7722","callsign":"HG","title":"rust-discovery: simplifying add_missing_revisions()","author":"gracinet","summary":"with the removal of the various ensure() it's become\nclear that this doesn't have error cases any more, and we didn't\nneed the full match at the end.","testPlan":"","lineCount":"21","dependsOn":["7721"],"reviewers":["Alphare"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"accept","author":"Alphare","id":"114426","dateCreated":"1578045432","dateModified":"1578045432"},{"type":"update","diffId":"18930","author":"gracinet","id":"113731","dateCreated":"1577195430","dateModified":"1577195430"}],"dateCreated":"1577195430","dateModified":"1578045432","status":"Needs Review"},{"id":"7721","callsign":"HG","title":"rust-discovery: postponing random generator init","author":"gracinet","summary":"This is an example of the benefits we get with the\ntypestape pattern: we can cleanly postpone the\nseeding and initialisation of the random generator.\n\nThis makes the `default()` method a bit cheaper. Its point\nis that its output is a placeholder not meand to be really used,\nbut if that happened, it would now be with the knowledge that\nthe seed hasn't been initialized (and possible seeding after\nmorphing into a discovery with undecided set)","testPlan":"","lineCount":"41","dependsOn":["7720"],"reviewers":["Alphare"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"accept","author":"Alphare","id":"114425","dateCreated":"1578045385","dateModified":"1578045385"},{"type":"update","diffId":"18929","author":"gracinet","id":"113723","dateCreated":"1577195423","dateModified":"1577195423"}],"dateCreated":"1577195423","dateModified":"1578045385","status":"Needs Review"},{"id":"7720","callsign":"HG","title":"rust-discovery: moved some methods to the wrapper enum","author":"gracinet","summary":"In the primary switch to the typestate pattern, these\nmethods have been kept on the `WithUndecided` struct, that\nhad most of the original methods of `PartialDiscovery`, so\nthat the change would be readable.\n\nBut we feel it makes more sense to have them on the wrapper\nenum.\n\n`common_heads` would also be a candidate for a last stage method,\nwe wouldn't need that lenghty warning docstring that it's not\nrelevant if `is-complete` is `true`","testPlan":"","lineCount":"44","dependsOn":["7719"],"reviewers":["Alphare"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"accept","author":"Alphare","id":"114424","dateCreated":"1578045272","dateModified":"1578045272"},{"type":"update","diffId":"18928","author":"gracinet","id":"113715","dateCreated":"1577195416","dateModified":"1577195416"}],"dateCreated":"1577195416","dateModified":"1578045272","status":"Needs Review"},{"id":"7719","callsign":"HG","title":"rust-discovery: children cache as typestate transition","author":"gracinet","summary":"As of 8c9a6adec67a, we were actually using\nthe children cache right away in `add_missing_revisions`,\nthe method that also triggers the undecided set computation\n(see that changeset description for the corresponding\nperformance discussion).\n\nThis means we don't need a third typestate for the children\ncache: `WithUndecided` can always have it.\n\nIt is clear that `compute_children_cache` does not have\nto be tied to the `WithUndecided` struct anymore. We may\nmove it to `hg::dagops` in a later move.","testPlan":"","lineCount":"63","dependsOn":["7718"],"reviewers":["Alphare"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"accept","author":"Alphare","id":"114423","dateCreated":"1578045124","dateModified":"1578045124"},{"type":"update","diffId":"18927","author":"gracinet","id":"113706","dateCreated":"1577195409","dateModified":"1577195409"}],"dateCreated":"1577195409","dateModified":"1578045124","status":"Needs Review"},{"id":"7718","callsign":"HG","title":"rust-directory: simplify bidirectional sampling","author":"gracinet","summary":"Thanks to the typestate pattern, we don't have a\ncomplicated management of borrows to perform in\nthat method with the early return condition and\nthe comment was just obsolete.","testPlan":"","lineCount":"9","dependsOn":["7717"],"reviewers":["Alphare"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"accept","author":"Alphare","id":"114422","dateCreated":"1578044870","dateModified":"1578044870"},{"type":"update","diffId":"18926","author":"gracinet","id":"113698","dateCreated":"1577195401","dateModified":"1577195401"}],"dateCreated":"1577195401","dateModified":"1578044870","status":"Needs Review"},{"id":"7717","callsign":"HG","title":"rust-discovery: restoring add_missing cheap early return","author":"gracinet","summary":"In case the iterator of missing revisions argument turns out\nto be empty, we need to refrain from computing the undecided\nset. This way, we'll benefit from subsequent add_common_revisions\nuntil there is an actually meaningful add_missing_revisions.\n\nTo do this with the typestate pattern, that means the early\nreturn has to happen before potential transition into an\nWithUndecided","testPlan":"","lineCount":"23","dependsOn":["7716"],"reviewers":["Alphare"],"ccs":["durin42","kevincox","mjpieters","mercurial-devel"],"actions":[{"type":"accept","author":"Alphare","id":"114421","dateCreated":"1578044801","dateModified":"1578044801"},{"type":"update","diffId":"18925","author":"gracinet","id":"113690","dateCreated":"1577195395","dateModified":"1577195395"}],"dateCreated":"1577195395","dateModified":"1578044801","status":"Needs Review"},{"id":"7716","callsign":"HG","title":"rust-discovery: partial switch to typestate pattern","author":"gracinet","summary":"The `PartialDiscovery` object owns two data fields that are\nlazily evaluated: the set of undecided revisions, and the\nchildren cache. That laziness is known to be essential for\nperformance.\n\nIn the previous version, we were using `Option<T>`, which led\nus to methods such as `ensure_undecided()` followed by calls to\n`self.undecided.as_ref().unwrap()`, as it was the simplest way\nto avoid reference sharing problems, but that wasn't\nsatisfying. Human readers knew that panicking was indeed\nimpossible, but that wasn't enforced by the compiler.\n\nWe had something similar yet less pervasive with the early\nrelease of `target_heads`.\n\nThe reviewer, Kevin Cox, then suggested to use a code pattern\nknown as typestate: different types to represent the successive\nstages, with the second one always having an undecided set.\n\nThis is what we are doing here.  Now we have two state types:\n`OnlyCommon` and `WithUndecided`.\nOnly the first has the `target_heads` member; only the second\nhas the `undecided` member.\n\nIt makes the code a bit longer, because we have to make\n`PartialDiscovery` a wrapper enum for identical consumption\nwithin hg-cpython and reexpose the public interface.\nBut it makes the inner code more focused, clearer and\nbetter checked by the compiler. A few further simplifications\nwill be made in following changesets thanks to this.\n\nA key point that we didn't know how to solve\nin the first version was the in-place mutation of that wrapper\nenum, provided by the `mutate_undecided()` method.\n\nThis is partial because we don't address the children cache.\nWe'll do that in a follow-up also.\n\nAlso some methods and doc-comments have been kept on the inner\nstructs for readability of this changesets, but they will\nbe factorized on the wrapper enum in a next move","testPlan":"","lineCount":"381","dependsOn":[],"reviewers":["martinvonz"],"ccs":["martinvonz","Alphare","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"I'm gonna give it a try, yes. About the namings, I'm thinking of `<Cheap>` and `<Expensive>`. It doesn't describe the contents, but it's really clear about the intent.","author":"gracinet","id":"114210","dateCreated":"1577622485","dateModified":"1577622485"},{"type":"comment","comment":">>! In D7716#114043, @gracinet wrote:\n> @martinvonz yes, I've thinked of it after I made this one, but somehow I thought this was enough for a first try.\n\nIt seems like it would be a lot of churn to take this patch and then a follow-up that rewrites it. I'd be much happier to take a patch that cleaner version right away (and it sounds like we both think it would be cleaner).\n\n> \n> Yes, we could have `PartialDiscovery<Start>`,  and `PartialDiscovery<Computed>`, with  `Start` being a pure marker,  and `Computed` actually holding the undecided set and the children cache (anticipating on a later changeset), that would be more elegant and it would better organize the boiler plate.\n> \n> Don't hesitate if you come up with better namings.\n\nI haven't even reviewed in enough detail to know what the states represent, so I don't have any suggestions yet :)","author":"martinvonz","id":"114044","dateCreated":"1577486308","dateModified":"1577486308"},{"type":"comment","comment":"@martinvonz yes, I've thinked of it after I made this one, but somehow I thought this was enough for a first try.\n\nYes, we could have `PartialDiscovery<Start>`,  and `PartialDiscovery<Computed>`, with  `Start` being a pure marker,  and `Computed` actually holding the undecided set and the children cache (anticipating on a later changeset), that would be more elegant and it would better organize the boiler plate.\n\nDon't hesitate if you come up with better namings.","author":"gracinet","id":"114043","dateCreated":"1577485532","dateModified":"1577485532"},{"type":"comment","comment":"Did you consider encoding the state in a type parameter to `PartialDiscovery`? I think that would make the call sites simpler. See the last variation on http:\/\/cliffle.com\/blog\/rust-typestate\/ for what I mean.","author":"martinvonz","id":"113817","dateCreated":"1577468534","dateModified":"1577468534"},{"type":"reject","author":"martinvonz","id":"113816","dateCreated":"1577468534","dateModified":"1577468534"},{"type":"comment","comment":"@durin42 this Diffrential and its descendants are what I've told you about in our latest chat: implementing suggestions by @kevincox for a much cleaner an robust code.\nI intend to provide the upcoming rust-nodemap series using the same kind of pattern. I believe @Alphare wants to clean up Dirstate related code in similar ways.","author":"gracinet","id":"113739","dateCreated":"1577196081","dateModified":"1577196081"},{"type":"update","diffId":"18924","author":"gracinet","id":"113682","dateCreated":"1577195389","dateModified":"1577195389"}],"dateCreated":"1577195389","dateModified":"1577622485","status":"Needs Revision"},{"id":"6846","callsign":"HG","title":"packaging: script the building of a MacOS installer using a custom python","author":"mharbison72","summary":"The intent here is to get away from relying on system python (which is going\naway in 10.16), so that an installer can easily be built to work on multiple\nversions of the OS.  10.9 was chosen as the minimum platform here because that's\nthe SDK needed to notarize, and also what the binary python installer targets.\nA lot of this was adapted from the script that builds the TortoiseHg DMG.\n\nThere's a useful thg customization (not duplicated here), which extends\n`sys.path` to include $HOME\/Library\/Python\/2.7\/lib\/python\/site-packages, because\nthere's no way to add to the bundled python after the app is signed.  As it\nstands now, this installation won't see that, but does see\n$HOME\/.local\/lib\/python2.7\/site-packages, and the bundled `pip` will install\nthere with `--user`.  It does seem like only seeing the second `--user` location\nwill get confusing, especially since the current behavior is that\n`pip install --user ...` just works for `pip` in PATH.\n\nThe prerequisite is to have python3 to run the script, and a working python2\nwith docutils installed to feed to the script.  (The latter is used to build and\ninstall the documentation for Mercurial without polluting the python distro to\nbe packaged, so maybe we can use python3 there.)\n\nThe general flow is to download, build and install OpenSSL off to the side, and\nthen use that to download, build and install Python to a separate staging area.\nThe certifi package is bundled for the root certificates.  I'm not an expert in\nwhat OpenSSL compilation options should be used, so if there's a way to tighten\nthings up, let me know.\n\nI don't like how the other packaging scripts assume an existing path on the\nsystem, so this uses the build directory to stage the Python and OpenSSL builds.\nThe existing system python installer stages in `build\/mercurial`, but this\nbuilds Mercurial into the staged python directory.  (That path includes version\ninfo, so it shouldn't be much to add python3 support and build both at the same\ntime.)  I also wasn't sure where to stash the downloads (they seem somewhat\nuseful to cache), so I stuffed them into the packages directory (which gets\nclobbered by `make clean`).\n\nTo distinguish from the system python installer (and with an eye towards\npython3), `-py2.7` is added after the Mercurial version to the file name.\nAltogether, this takes about 10 minutes to build on a 2018 Mac Mini.\n\nThere's additional followup work to do, in addition to the obvious py3 support-\nthe readme still mentions depending on system python, and this could probably be\ndriven by the makefile as a separate target.  It should be trivial to sign the\nbinaries and installer, and slightly less trivial to notarize the *.pkg, but\ndefinitely doable.  The files in the final *.pkg can be listed like so:\n\n    pkgutil --payload-files dist\/Mercurial-*.pkg\n\nLooking at that, there's probably a bunch of junk that can be removed:\n\n    - include\/\n    - distutils\/tests\/\n    - lib-tk\/test\/\n    - ctypes\/test\/,\n    - unittest\n    - test\n    - lib2to3\n    - idle\n    - pydoc\n\nI didn't see config options for that, and maybe it isn't worth it.  The\ninstaller ends up around 39MB.","testPlan":"","lineCount":"364","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D6846#100478, @mharbison72 wrote:\n> This seems to work (though the shebang line hack is painful)- until the original python build directory is deleted.  Then a lot of things complain about unsupported hash type for md5 and sha{1,224,256,384,512}.  Other modules like `json` can be imported with the installed python executable.  I grepped around for the build directory, and it is in a bunch of *.so files (though this could be `__FILE__` for all I know).  Any ideas?\n\nSo, the problem here is that openssl libraries are being built and installed with the temporary install path, and the `_ssl.so` module is expecting to find them there.  I tried a custom Setup.local that statically links `_ssl.so` against openssl before configuring python, but the build summary said dependencies were missing to build `_ssl` (among other things).  For some reason, the resulting build still seemed to be able to talk to https servers.  `help(_ssl)` said it was builtin, whereas `help(_ssl)` on the original build mentioned openssl (IIRC).\n\nThe `_ssl.so` module in the thg app has `@executable_path` in the library name, so that's why that works.  I also tried messing with `@rpath`, but I can't get that working either.  I'm not sure what else to try.","author":"mharbison72","id":"100512","dateCreated":"1568414255","dateModified":"1568414255"},{"type":"comment","comment":"This seems to work (though the shebang line hack is painful)- until the original python build directory is deleted.  Then a lot of things complain about unsupported hash type for md5 and sha{1,224,256,384,512}.  Other modules like `json` can be imported with the installed python executable.  I grepped around for the build directory, and it is in a bunch of *.so files (though this could be `__FILE__` for all I know).  Any ideas?","author":"mharbison72","id":"100478","dateCreated":"1568327294","dateModified":"1568327294"},{"type":"update","diffId":"16526","author":"mharbison72","id":"100472","dateCreated":"1568326880","dateModified":"1568326880"}],"dateCreated":"1568326880","dateModified":"1577555735","status":"Needs Review"},{"id":"7450","callsign":"HG","title":"INCOMPLETE pyoxidizer","author":"indygreg","summary":"","testPlan":"","lineCount":"493","dependsOn":["7449"],"reviewers":[],"ccs":["mharbison72","martinvonz","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"`main.rs` and the Cargo files already exist, so this fails to apply.","author":"martinvonz","id":"113107","dateCreated":"1576623391","dateModified":"1576623391"},{"type":"inline","comment":"For some reason, this caused it to complain about not being able to find hgdemandimport with pyoxidizer v0.4.0-58-gc7d9c79.  I commented it out, and now I can get basic commands running.  I can live with that for now (though I saw the comment about external templates elsewhere, so maybe it needs to work eventually).\n\nCC: @martinvonz ","replyTo":null,"isNewFile":"1","line":"26","lineLength":"0","path":"rust\/hgcli\/pyoxidizer.bzl","diffId":"18201","author":"mharbison72","id":"109445","dateCreated":"1573949878","dateModified":"1573949878"},{"type":"update","diffId":"18201","author":"indygreg","id":"109438","dateCreated":"1573939307","dateModified":"1573939307"}],"dateCreated":"1573939307","dateModified":"1577122954","status":"Needs Review"},{"id":"7449","callsign":"HG","title":"rust: vendor pyembed crate","author":"indygreg","summary":"We want to use PyOxidizer to produce machine native executables\nfor running Mercurial. This commit starts the process of doing\nthat.\n\nUnder the hood, PyOxidizer uses a \"pyembed\" crate to manage an\nembedded Python interpreter. This crate needs to be vendored\nbecause it relies on a patched version of the rust-cpython\ncrate.\n\nThis commit vendors the pyembed crate associated with version\n0.3 of PyOxidizer.","testPlan":"","lineCount":"2558","dependsOn":[],"reviewers":[],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"update","diffId":"18200","author":"indygreg","id":"109432","dateCreated":"1573939306","dateModified":"1573939306"}],"dateCreated":"1573939306","dateModified":"1577122930","status":"Needs Review"},{"id":"7628","callsign":"HG","title":"config: move reading of defaultrc\/ files from ui to rcutil","author":"martinvonz","summary":"For PyOxidizer, we'll need to read the default configs using the\n`resources` module. This prepares for putting that call in rcutil.","testPlan":"","lineCount":"13","dependsOn":[],"reviewers":[],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"inline","comment":"Do you think it would be better to change the return type to expose a `resource` type, which the caller can resolve accordingly? Or maybe do away with leaving it up to the caller to open and read paths? It just feels weird for some I\/O to be performed in this function while some I\/O is deferred to the caller.\n\nBut I don't have this code paged in, so maybe my comment is off base.","replyTo":null,"isNewFile":"1","line":"102","lineLength":"0","path":"mercurial\/rcutil.py","diffId":"18658","author":"indygreg","id":"113597","dateCreated":"1577122093","dateModified":"1577122093"},{"type":"comment","comment":"The patch seems functionally correct. But I have a question about whether this is the desired approach. See inline comment.","author":"indygreg","id":"113596","dateCreated":"1577122093","dateModified":"1577122093"},{"type":"update","diffId":"18658","author":"martinvonz","id":"112188","dateCreated":"1576194272","dateModified":"1576194272"}],"dateCreated":"1576194272","dateModified":"1577122094","status":"Needs Review"},{"id":"7629","callsign":"HG","title":"config: read defaultrc\/ using `resources` module if available","author":"martinvonz","summary":"Similar to an earlier patch for `hg help`. Here we also needed a way\nof listing resources\/files in a package\/directory, so I added that to\nthe resourceutil module.\n\nTested by running `$PYTHON .\/hg config --debug` for each $PYTHON in\n{python2, python3.6, python3.7}.","testPlan":"","lineCount":"52","dependsOn":["7628"],"reviewers":["indygreg"],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"18872","author":"martinvonz","id":"113345","dateCreated":"1576734395","dateModified":"1576734395"},{"type":"update","diffId":"18810","author":"martinvonz","id":"113005","dateCreated":"1576592456","dateModified":"1576592456"},{"type":"update","diffId":"18685","author":"martinvonz","id":"112370","dateCreated":"1576224096","dateModified":"1576224096"},{"type":"update","diffId":"18659","author":"martinvonz","id":"112196","dateCreated":"1576194274","dateModified":"1576194274"}],"dateCreated":"1576194274","dateModified":"1577122044","status":"Needs Review"},{"id":"7515","callsign":"HG","title":"pytype: [WIP] suppress various warnings inline to get a clean run","author":"mharbison72","summary":"This depends on D7295 and D7384, which in turn was applied to 4222b9d5d4fb.  I\nmade no attempt to keep it under 80 columns or blacken it.  But it seems useful\nto share now, because it is so time consuming to get this far, and presumably\nmuch of this will entail actual fixes.  These things were flagged by pytype\n2019.12.06 under WSL.\n\nThe following bundlerepo warnings were fixed with assertions, but those\nassertions fire when running the testsuite for some reason:\n\n    line 256, in __init__: No attribute 'ui' on bundlerepository [attribute-error]\n    line 260, in __init__: No attribute 'ui' on bundlerepository [attribute-error]\n    line 292, in __init__: No attribute 'ui' on bundlerepository [attribute-error]\n    line 292, in __init__: No attribute 'vfs' on bundlerepository [attribute-error]\n    line 330, in _writetempbundle: No attribute 'vfs' on bundlerepository [attribute-error]\n      Called from (traceback):\n        line 290, in __init__\n    line 341, in _writetempbundle: No attribute 'vfs' on bundlerepository [attribute-error]\n      Called from (traceback):\n        line 290, in __init__\n    line 378, in _consumemanifest: No attribute '_cgunpacker' on bundlerepository [attribute-error]\n    line 379, in _consumemanifest: No attribute '_cgunpacker' on bundlerepository [attribute-error]\n    line 380, in _consumemanifest: No attribute '_cgunpacker' on bundlerepository [attribute-error]\n    line 382, in _consumemanifest: No attribute '_cgunpacker' on bundlerepository [attribute-error]\n    line 406, in file: No attribute '_cgfilespos' on bundlerepository [attribute-error]\n    line 412, in file: No attribute 'unfiltered' on bundlerepository [attribute-error]\n    line 413, in file: No attribute 'svfs' on bundlerepository [attribute-error]\n    line 413, in file: No attribute 'file' on super [attribute-error]\n    line 420, in close: No attribute '_bundlefile' on bundlerepository [attribute-error]\n    line 422, in close: No attribute 'vfs' on bundlerepository [attribute-error]\n    line 441, in setparents: No attribute 'setparents' on super [attribute-error]\n    line 441, in setparents: No attribute 'ui' on bundlerepository [attribute-error]\n    line 443, in setparents: No attribute 'ui' on bundlerepository [attribute-error]","testPlan":"","lineCount":"478","dependsOn":["7384","7295"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"Still not a queue-able thing.  But this adds in the errors that are being suppressed so others can try to fix some of this without the ~10-15minute wait for failures.  It looks like there is a recurring issue with converting exceptions to bytes for printing.  Also, a few things seem to have gotten fixed in logcmdutil and patch since last time, though I'm slightly concerned that it missed issues that it previously flagged in hgweb\/server.py.  The only difference I'm aware of is running a new version of pytype, and running under WSL instead of on a Mac.","author":"mharbison72","id":"113052","dateCreated":"1576605144","dateModified":"1576605144"},{"type":"plan-changes","author":"mharbison72","id":"113051","dateCreated":"1576605144","dateModified":"1576605144"},{"type":"update","diffId":"18818","author":"mharbison72","id":"113048","dateCreated":"1576604623","dateModified":"1576604623"},{"type":"comment","comment":"Adjusting this to stay out of the review queue.  While most of the files only had a handful of errors (and a few could be removed from the blacklist), the few added had a bunch of errors.  I didn't see any obvious fixes, and ran out of time Friday to individually suppress them.\n\nI'm assuming we will fix the problems, and then apply the suppressions in narrow categories rather than a monolithic commit like this.","author":"mharbison72","id":"110472","dateCreated":"1574556845","dateModified":"1574556845"},{"type":"plan-changes","author":"mharbison72","id":"110471","dateCreated":"1574556845","dateModified":"1574556845"},{"type":"update","diffId":"18368","author":"mharbison72","id":"110454","dateCreated":"1574556477","dateModified":"1574556477"}],"dateCreated":"1574556477","dateModified":"1576605144","status":"Changes Planned"},{"id":"7118","callsign":"HG","title":"rust-dirstatemap: remove additional lookups in traverse","author":"Alphare","summary":"We use the same trick as the Python implementation.","testPlan":"","lineCount":"3","dependsOn":[],"reviewers":["martinvonz"],"ccs":["martinvonz","yuja","mercurial-devel"],"actions":[{"type":"reject","author":"martinvonz","id":"112391","dateCreated":"1576260856","dateModified":"1576260856"},{"type":"comment","comment":">>! In D7118#111784, @Alphare wrote:\n>>>! In D7118#111735, @martinvonz wrote:\n>> What's the state of this patch? The description makes it sound like it's a Rust patch, but it only modifies Python code.\n> \n> It only impacts the rust module policy, I figured the name was not a bad idea. Maybe I'm wrong?\n> \n> I also did not find Yuya's suggestion to work, but I may have understood it wrong.\n\nI think Yuya's suggestion was to make the diff be this:\n\n```\ndiff --git a\/mercurial\/dirstate.py b\/mercurial\/dirstate.py\n--- a\/mercurial\/dirstate.py\n+++ b\/mercurial\/dirstate.py\n@@ -909,7 +909,7 @@ class dirstate(object):\n         matchfn = match.matchfn\n         matchalways = match.always()\n         matchtdir = match.traversedir\n-        dmap = self._map\n+        dmap = self._map._map\n         listdir = util.listdir\n         lstat = os.lstat\n         dirkind = stat.S_IFDIR\n```\n\nObviously, you'd need to make some adjustments to allow that, at least renaming `_rustmap` to `_map`. The commit message should also change then.\n\nI don't remember what the point of the nested `_map`s was (perhaps to make it possible to replace the inner `_map`?). Hopefully we're not breaking that by directly accessing the inner `_map`.","author":"martinvonz","id":"112034","dateCreated":"1576169183","dateModified":"1576169183"},{"type":"comment","comment":">>! In D7118#111735, @martinvonz wrote:\n> What's the state of this patch? The description makes it sound like it's a Rust patch, but it only modifies Python code.\n\nIt only impacts the rust module policy, I figured the name was not a bad idea. Maybe I'm wrong?\n\nI also did not find Yuya's suggestion to work, but I may have understood it wrong.","author":"Alphare","id":"111784","dateCreated":"1576053454","dateModified":"1576053454"},{"type":"comment","comment":"What's the state of this patch? The description makes it sound like it's a Rust patch, but it only modifies Python code.","author":"martinvonz","id":"111735","dateCreated":"1576002609","dateModified":"1576002609"},{"type":"update","diffId":"18564","author":"Alphare","id":"111639","dateCreated":"1575991575","dateModified":"1575991575"},{"type":"update","diffId":"18040","author":"Alphare","id":"108352","dateCreated":"1573553026","dateModified":"1573553026"},{"type":"comment","comment":">   >> +++ b\/mercurial\/dirstate.py\n>   >> @@ -919,6 +919,9 @@\n>   >>\n>   >>   matchalways = match.always()\n>   >>   matchtdir = match.traversedir\n>   >>   dmap = self._map\n>   >>\n>   >> +        if rustmod is not None:\n>   >> +            dmap = self._map._rustmap\n>   >\n>   > If it's the same trick, can't it be abstracted away? `if rustmod` seems weird.\n>   \n>   The main issue I faced is that Python classes built from `rust-cpython` cannot be subclassed, so we have to resort to an additional level of indirection. IIRC, the main reason was that there was no way of enforcing a subclass to call `super()` which would result in the Rust class not being initialized properly. Or maybe I'm missing the point?\n\nI mean there could be a unified `self._map._map` call if we need to take\nthe internal map from both py dirstatemap and rust dirstatemap.","author":"yuja","id":"104848","dateCreated":"1571402444","dateModified":"1571402444"},{"type":"comment","comment":">>! In D7118#104834, @yuja wrote:\n>> +++ b\/mercurial\/dirstate.py\n>> @@ -919,6 +919,9 @@\n>>          matchalways = match.always()\n>>          matchtdir = match.traversedir\n>>          dmap = self._map\n>> +        if rustmod is not None:\n>> +            dmap = self._map._rustmap\n> \n> If it's the same trick, can't it be abstracted away? `if rustmod` seems weird.\n\nThe main issue I faced is that Python classes built from `rust-cpython` cannot be subclassed, so we have to resort to an additional level of indirection. IIRC, the main reason was that there was no way of enforcing a subclass to call `super()` which would result in the Rust class not being initialized properly. Or maybe I'm missing the point? ","author":"Alphare","id":"104847","dateCreated":"1571401479","dateModified":"1571401479"},{"type":"comment","comment":"> +++ b\/mercurial\/dirstate.py\n> @@ -919,6 +919,9 @@\n>          matchalways = match.always()\n>          matchtdir = match.traversedir\n>          dmap = self._map\n> +        if rustmod is not None:\n> +            dmap = self._map._rustmap\n\nIf it's the same trick, can't it be abstracted away? `if rustmod` seems weird.","author":"yuja","id":"104834","dateCreated":"1571395637","dateModified":"1571395637"},{"type":"update","diffId":"17200","author":"Alphare","id":"104371","dateCreated":"1571233728","dateModified":"1571233728"}],"dateCreated":"1571233728","dateModified":"1576260856","status":"Needs Revision"},{"id":"7517","callsign":"HG","title":"filemerge: byteify the open() mode","author":"mharbison72","summary":"This is actually `pycompat.open()`, so it need bytes.  It regressed recently on\ndefault.\n\nVSCode flagged some invalid mode to open() the other day, but I don't remember\nwhere.  That's what got me searching in this area.  I'm almost certain that it\nwas the other way (i.e. saying open doesn't take bytes), but I can't find that\nnow.","testPlan":"","lineCount":"2","dependsOn":[],"reviewers":[],"ccs":["durin42","dlax","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D7517#111885, @durin42 wrote:\n> I'm a little fuzzy on this: should I see some test failures? or...?\n\nIt looks like not.  I glossed over the fact that `pycompat.sysstr()` will simply return `str` if given one, before trying to decode it.  So it will take either `bytes` or `str`.\n\nI looks like the VSCode complaint about passing bytes as the mode is only flagged when used in a context manager (several lines below), even though clicking through to the definition brings it to pycompat.  I don't remember if this particular thing was flagged by static analysis, or it just caught my eye because 99% of the modes in other uses (outside tests\/, contrib\/ and setup.py) are bytes.  But the latest version of PyCharm isn't complaining, nor is pytype.  So I can abandon it if you'd prefer.","author":"mharbison72","id":"111939","dateCreated":"1576105135","dateModified":"1576105135"},{"type":"comment","comment":"I'm a little fuzzy on this: should I see some test failures? or...?","author":"durin42","id":"111885","dateCreated":"1576085615","dateModified":"1576085615"},{"type":"comment","comment":">>! In D7517#110547, @dlax wrote:\n>> This is actually pycompat.open(), so it need bytes.\n> \n> I don't understand why this is needed. The default value for \"mode\" as bytes comes from a407f9009392, but I don't understand the rationale.\n\nThe reason for explicitly marking the mode there was that `sysstr(mode)` was already in place.  So that didn't change anything- `mode` was already required to be bytes.\n\n> Shouldn't we instead change all calls to `pycompat.open()` to use a native str for `mode`? (and drop `sysstr(mode)` in `pycompat.open()`).\n\nI suspect the byte `mode` was done to be consistent with the file name being bytes?  I agree with the first point though- I\u2019d much rather this be an explicit call to `pycompat.open()` so that it\u2019s clear that it isn\u2019t the builtin function.  I noticed that *attr() builtins are similarly replaced, but I didn\u2019t look inside to see what they were about. (I\u2019m assuming they\u2019re also about bytes -> str.)\n\n","author":"mharbison72","id":"110548","dateCreated":"1574604482","dateModified":"1574604482"},{"type":"comment","comment":"> This is actually pycompat.open(), so it need bytes.\n\nI don't understand why this is needed. The default value for \"mode\" as bytes comes from a407f9009392, but I don't understand the rationale.\nShouldn't we instead change all calls to `pycompat.open()` to use a native str for `mode`? (and drop `sysstr(mode)` in `pycompat.open()`).","author":"dlax","id":"110547","dateCreated":"1574596272","dateModified":"1574596272"},{"type":"update","diffId":"18381","author":"mharbison72","id":"110530","dateCreated":"1574574316","dateModified":"1574574316"}],"dateCreated":"1574574316","dateModified":"1576105135","status":"Needs Review"},{"id":"7582","callsign":"HG","title":"hg-core: run rustfmt on configparser","author":"indygreg","summary":"The vendored code doesn't follow modern rustfmt's conventions.\nThis commit runs rustfmt so it does.\n\n# skip-blame rustfmt","testPlan":"","lineCount":"615","dependsOn":["7575"],"reviewers":["Alphare","durin42"],"ccs":["quark","durin42","kevincox","mjpieters","mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"111901","dateCreated":"1576086321","dateModified":"1576086321"},{"type":"accept","author":"Alphare","id":"111527","dateCreated":"1575897405","dateModified":"1575897405"},{"type":"update","diffId":"18546","author":"indygreg","id":"111413","dateCreated":"1575774206","dateModified":"1575774206"},{"type":"comment","comment":"We actually ran rustfmt, but it's an older version (rustfmt 1.3.0-stable (d334502 2019-06-09)) and I verified the code still formats under that particular version of rustfmt with empty `rustfmt.toml`. In other words, rustfmt itself seems to change over time.","author":"quark","id":"111410","dateCreated":"1575761535","dateModified":"1575761535"},{"type":"update","diffId":"18543","author":"indygreg","id":"111392","dateCreated":"1575759424","dateModified":"1575759424"}],"dateCreated":"1575759424","dateModified":"1576086321","status":"Accepted"},{"id":"7119","callsign":"HG","title":"rust-dirstatemap: remove additional lookup in dirstate.matches","author":"Alphare","summary":"We use the same trick as the Python implementation","testPlan":"","lineCount":"3","dependsOn":["7118"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"18565","author":"Alphare","id":"111640","dateCreated":"1575991581","dateModified":"1575991581"},{"type":"update","diffId":"18041","author":"Alphare","id":"108356","dateCreated":"1573553032","dateModified":"1573553032"},{"type":"update","diffId":"17201","author":"Alphare","id":"104381","dateCreated":"1571233735","dateModified":"1571233735"}],"dateCreated":"1571233735","dateModified":"1575991585","status":"Needs Review"},{"id":"7577","callsign":"HG","title":"hg-core: implement Mercurial's config file discovery logic","author":"indygreg","summary":"The imported Facebook code for locating Mercurial config files\ndiffered from what Mercurial itself does. This commit modifies the\nlogic to match what Mercurial currently does.\n\nAs part of this, we added some crate dependencies. We could probably\navoid these dependencies if we want. But these crates are quite popular\nand useful and I imagine we'll end up using them eventually.\n\nWe should probably add some test coverage of this code...","testPlan":"","lineCount":"148","dependsOn":["7576"],"reviewers":["kevincox","Alphare"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"accept","author":"Alphare","id":"111521","dateCreated":"1575896924","dateModified":"1575896924"},{"type":"inline","comment":"I believe this can just be `.flatten()`.","replyTo":null,"isNewFile":"1","line":"145","lineLength":"0","path":"rust\/hg-core\/src\/configparser\/config.rs","diffId":"18544","author":"kevincox","id":"111453","dateCreated":"1575894221","dateModified":"1575894221"},{"type":"accept","author":"kevincox","id":"111452","dateCreated":"1575894221","dateModified":"1575894221"},{"type":"update","diffId":"18544","author":"indygreg","id":"111399","dateCreated":"1575759436","dateModified":"1575759436"},{"type":"update","diffId":"18537","author":"indygreg","id":"111349","dateCreated":"1575749873","dateModified":"1575749873"}],"dateCreated":"1575749873","dateModified":"1575896925","status":"Needs Review"},{"id":"7542","callsign":"HG","title":"mail: don't complain about a multi-word email.method","author":"jcristau","summary":"I want to be able to set email.method to \"ssh relay \/usr\/sbin\/sendmail\"\nwithout needing an extra trivial shell script.\nThis works fine since we pass the full command to a shell, except for\nvalidateconfig trying to find it in $PATH.","testPlan":"","lineCount":"5","dependsOn":[],"reviewers":[],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"doh.  Right you are.","author":"jcristau","id":"110909","dateCreated":"1575384698","dateModified":"1575384698"},{"type":"plan-changes","author":"jcristau","id":"110908","dateCreated":"1575384698","dateModified":"1575384698"},{"type":"comment","comment":"> +        command = procutil.shellsplit(method)\n> +        if not (command and procutil.findexe(command[0])):\n\nThis condition is correct, but `command[0]` would raise IndexError if\n`not command`.\n\nMaybe we'll need a helper function that does `shellsplit()` and returns\n`command[0]` or `b''`.\n\n> -                _(b'%r specified as email transport, but not in PATH') % method\n> +                _(b'%r specified as email transport, but not in PATH') % command[0]","author":"yuja","id":"110907","dateCreated":"1575377757","dateModified":"1575377757"},{"type":"update","diffId":"18420","author":"jcristau","id":"110812","dateCreated":"1575294675","dateModified":"1575294675"}],"dateCreated":"1575294675","dateModified":"1575384698","status":"Changes Planned"},{"id":"7384","callsign":"HG","title":"commands: necessary annotations and suppresssions to pass pytype","author":"durin42","summary":"As with other places, there are some places where our types are just\ntoo complicated for pytype, so we put some suppressions in place.","testPlan":"","lineCount":"24","dependsOn":["7296"],"reviewers":["dlax"],"ccs":["dlax","mercurial-devel"],"actions":[{"type":"update","diffId":"18171","author":"durin42","id":"109261","dateCreated":"1573854923","dateModified":"1573854923"},{"type":"inline","comment":"`revs` is always a `smartset.baseset` per af9c73f26371 so there should be no attribute error. Or is it because `logcmdutil.getlinerangerevs()` has no type annotation (whereas `logcmdutil.getrevs()` has some)?","replyTo":null,"isNewFile":"1","line":"4742","lineLength":"0","path":"mercurial\/commands.py","diffId":"18162","author":"dlax","id":"109205","dateCreated":"1573839647","dateModified":"1573839647"},{"type":"update","diffId":"18162","author":"durin42","id":"109201","dateCreated":"1573839083","dateModified":"1573839083"},{"type":"comment","comment":"I still want to keep the annotations I added. :)","author":"durin42","id":"109194","dateCreated":"1573838661","dateModified":"1573838661"},{"type":"comment","comment":"D7430 makes this changes unnecessary I think.","author":"dlax","id":"109165","dateCreated":"1573816122","dateModified":"1573816122"},{"type":"reject","author":"dlax","id":"109163","dateCreated":"1573816122","dateModified":"1573816122"},{"type":"inline","comment":"By all means!","replyTo":"108589","isNewFile":"1","line":"1127","lineLength":"0","path":"mercurial\/commands.py","diffId":"18071","author":"durin42","id":"108819","dateCreated":"1573766153","dateModified":"1573766153"},{"type":"update","diffId":"18099","author":"durin42","id":"108777","dateCreated":"1573765800","dateModified":"1573765800"},{"type":"inline","comment":"This one is sad. I think this can be sorted out by replacing the `try:\/finally:` with a context manager. (Can send a patch, if it sounds good to you.)","replyTo":null,"isNewFile":"1","line":"1127","lineLength":"0","path":"mercurial\/commands.py","diffId":"18071","author":"dlax","id":"108589","dateCreated":"1573724725","dateModified":"1573724725"},{"type":"update","diffId":"18071","author":"durin42","id":"108529","dateCreated":"1573703495","dateModified":"1573703495"}],"dateCreated":"1573703495","dateModified":"1574556477","status":"Needs Review"},{"id":"7295","callsign":"HG","title":"pytype: add a (very slow) test that executes pytype","author":"durin42","summary":"This doesn't actually pass yet, but I wanted to share it early so\nothers can play with pytype.","testPlan":"","lineCount":"38","dependsOn":["7384"],"reviewers":["indygreg"],"ccs":["mharbison72","dlax","indygreg","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D7295#110254, @mharbison72 wrote:\n>>>! In D7295#107482, @indygreg wrote:\n>> Since type checking is slow (but there are state files we can reuse to speed things up), we'll need to figure out how to make this work in CI. But I have no doubt we can figure something out. Out of curiosity, how long does pytype take to run in a clean source directory, without any state files?\n> \n> It takes 15-20 minutes on a 2018 Mac mini.  In addition to the disabled files here, I've disabled:\n> \n>     mercurial\/httppeer.py\n>     mercurial\/repoview.py\n>     mercurial\/localrepo.py\n>     mercurial\/revlog.py\n>     mercurial\/merge.py\n>     mercurial\/testing\/storage.py\n> \n> But I've also added back these, and sprinkled various disable comments around:\n> \n>     mercurial\/bundlerepo.py\n>     mercurial\/error.py\n>     mercurial\/exchange.py\n>     mercurial\/policy.py\n>     mercurial\/pycompat.py\n>     mercurial\/scmwindows.py\n>     mercurial\/windows.py\n>     mercurial\/wireprotoframing.py\n> \n> Even with the state files, it seems to take 10-15 minutes or so.\n\nOoh, can you send your extra suppressions? For the most part I've been tackling this as a side project when I'm waiting on compiles.\n\nAs to doing individual files: that's well and good, and might be a viable approach for mypy. That said, my sense has been that mypy is faster and significantly less useful, since we don't get cross-file analysis of what's going on. I _think_ pytype gets faster as we add more annotations, so my rough thought thus far as been to try and get some subset of the codebase clean, transitively, and then try to start stamping some types on important functions and interfaces to constrain things. Where I'd _really_ like to get is to be able to migrate the `@command` decorators and friends to use strings instead of bytes, and be able to recommend typechecking as a way for extension authors to clean things up, but that'll take a while.","author":"durin42","id":"110437","dateCreated":"1574531296","dateModified":"1574531296"},{"type":"comment","comment":">>! In D7295#107482, @indygreg wrote:\n> Since type checking is slow (but there are state files we can reuse to speed things up), we'll need to figure out how to make this work in CI. But I have no doubt we can figure something out. Out of curiosity, how long does pytype take to run in a clean source directory, without any state files?\n\nIt takes 15-20 minutes on a 2018 Mac mini.  In addition to the disabled files here, I've disabled:\n\n    mercurial\/httppeer.py\n    mercurial\/repoview.py\n    mercurial\/localrepo.py\n    mercurial\/revlog.py\n    mercurial\/merge.py\n    mercurial\/testing\/storage.py\n\nBut I've also added back these, and sprinkled various disable comments around:\n\n    mercurial\/bundlerepo.py\n    mercurial\/error.py\n    mercurial\/exchange.py\n    mercurial\/policy.py\n    mercurial\/pycompat.py\n    mercurial\/scmwindows.py\n    mercurial\/windows.py\n    mercurial\/wireprotoframing.py\n\nEven with the state files, it seems to take 10-15 minutes or so.","author":"mharbison72","id":"110254","dateCreated":"1574462605","dateModified":"1574462605"},{"type":"update","diffId":"18242","author":"durin42","id":"109676","dateCreated":"1574187225","dateModified":"1574187225"},{"type":"inline","comment":"Needs a trailing slash here.","replyTo":null,"isNewFile":"1","line":"22","lineLength":"0","path":"tests\/test-check-pytype.t","diffId":"18104","author":"mharbison72","id":"109670","dateCreated":"1574180889","dateModified":"1574180889"},{"type":"update","diffId":"18104","author":"durin42","id":"108811","dateCreated":"1573765830","dateModified":"1573765830"},{"type":"update","diffId":"18072","author":"durin42","id":"108536","dateCreated":"1573703500","dateModified":"1573703500"},{"type":"comment","comment":"This can't land per commit message, so setting status accordingly.\n\nI'm extremely supportive of adding type checking, whether it be pytype or mypy. I don't think it matters much. And TBH I wouldn't be surprised if we end up with both once we drop Python 2 support and start using inline annotations heavily!\n\nAs for how to start testing, I think we should do this like Python 3 and try to make individual files \"clean.\" Maintain a list of clean files and we ratchet from there.\n\nSince type checking is slow (but there are state files we can reuse to speed things up), we'll need to figure out how to make this work in CI. But I have no doubt we can figure something out. Out of curiosity, how long does pytype take to run in a clean source directory, without any state files?","author":"indygreg","id":"107482","dateCreated":"1573231954","dateModified":"1573231954"},{"type":"reject","author":"indygreg","id":"107481","dateCreated":"1573231954","dateModified":"1573231954"},{"type":"update","diffId":"17665","author":"durin42","id":"106664","dateCreated":"1573081192","dateModified":"1573081192"}],"dateCreated":"1573081192","dateModified":"1574556477","status":"Needs Review"},{"id":"7258","callsign":"HG","title":"makefile: use Python 3 by default outside of Windows (BC)","author":"indygreg","summary":"I think the time has come. My main reason for wanting to do this is\nto force Mercurial developers to use Python 3 in their day-to-day work.\nThis should help flush out any remaining Python 3 bugs.\n\nIf this change is too controversial, we can revert it before the next\nrelease.\n\n.. bc::\n\n   Makefile now uses `python3` instead of `python` by default on\n   non-Windows platforms. This means Mercurial will be built and\n   run with Python 3 instead of Python 2.7 by default.\n\n   To continue using Python 2, set the PYTHON variable. e.g.\n   `make install PYTHON=python2.7`.","testPlan":"","lineCount":"11","dependsOn":[],"reviewers":["martinvonz","mharbison72"],"ccs":["yuja","mharbison72","durin42","dlax","martinvonz","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D7258#109923, @indygreg wrote:\n> I seriously question whether we need a `Makefile` at all [on Windows]: our `Makefile` is just a glorified shell script and isn't doing much in terms of dependency management. I'm tempted to move the packaging targets to `contrib\/packaging` and replace the remaining build targets with a `build.py` script.\n\nThat seems OK to me.  I like being able to mindlessly run the same commands on any platform.  But in practice I only ever run `make clean` and `make local` everywhere, and `make install-bin` on unix systems.  Maybe a python script could handle that everywhere.  And I'd be fine with the packaging targets elsewhere in any case.\n\n>>! In D7258#109927, @indygreg wrote:\n> I just uploaded a compromise patch that ignores Windows for now.\n\nThanks!","author":"mharbison72","id":"109928","dateCreated":"1574396524","dateModified":"1574396524"},{"type":"comment","comment":"I just uploaded a compromise patch that ignores Windows for now.","author":"indygreg","id":"109927","dateCreated":"1574395820","dateModified":"1574395820"},{"type":"update","diffId":"18278","author":"indygreg","id":"109924","dateCreated":"1574395772","dateModified":"1574395772"},{"type":"comment","comment":"I seriously question whether we need a `Makefile` at all [on Windows]: our `Makefile` is just a glorified shell script and isn't doing much in terms of dependency management. I'm tempted to move the packaging targets to `contrib\/packaging` and replace the remaining build targets with a `build.py` script.","author":"indygreg","id":"109923","dateCreated":"1574395609","dateModified":"1574395609"},{"type":"comment","comment":"> To continue using Python 2, set the PYTHON variable. e.g.\n> `make install PYTHON=python2.7` or\n> `make install PYTHON=py.exe -2`.\n\nThe \"py -2\" part needs to be quoted.\n\nI'm not super excited to deal with this on Windows just yet, but I can't dispute the rationale.  There are two traps for anybody dealing with this on Windows to be aware of:\n\n1. Running `.\/hg debuginstall` will still run py2, even if it was built with py3.  I assume this is the shebang line, and also an issue on other platforms.\n2. Running `.\/hg.exe debuginstall` will run py3, but since that python isn't in $PATH, it complains that it can't find python37.dll and exits.\n\nI know @durin42 took a whack at #1; I'm not sure if there's something we can do about #2.  (I realize I could just edit $PATH, but it seems that the point of py.exe is to keep python.exe off of $PATH so that multiple installs can be managed.  IIRC, it's not added to $PATH by default on installation.)  Maybe we can just copy the dll to the local directory as part of setup.py?","author":"mharbison72","id":"109922","dateCreated":"1574394544","dateModified":"1574394544"},{"type":"accept","author":"mharbison72","id":"109921","dateCreated":"1574394544","dateModified":"1574394544"},{"type":"comment","comment":"This is ready for re-review. Please take a look @durin42.","author":"indygreg","id":"109920","dateCreated":"1574391834","dateModified":"1574391834"},{"type":"update","diffId":"18277","author":"indygreg","id":"109919","dateCreated":"1574391762","dateModified":"1574391762"},{"type":"update","diffId":"18276","author":"indygreg","id":"109915","dateCreated":"1574391718","dateModified":"1574391718"},{"type":"comment","comment":">>! In D7258#107444, @indygreg wrote:\n> I've seen `ifeq($(OS),Windows_NT)` used a lot. Although `OS` may be something else under msys. I'm away from my Windows machine until Sunday. I'll send a revision once I've had time to test on Windows.\n\nI can confirm that this is the correct environment variable under msys on Windows 7 and 10, and it works in the makefile as suggested.","author":"mharbison72","id":"107494","dateCreated":"1573232388","dateModified":"1573232388"},{"type":"comment","comment":"I've seen `ifeq($(OS),Windows_NT)` used a lot. Although `OS` may be something else under msys. I'm away from my Windows machine until Sunday. I'll send a revision once I've had time to test on Windows.","author":"indygreg","id":"107444","dateCreated":"1573230899","dateModified":"1573230899"},{"type":"plan-changes","author":"indygreg","id":"107443","dateCreated":"1573230899","dateModified":"1573230899"},{"type":"comment","comment":">     ifeq ($(shell uname -o), Msys)\n>     PYTHON?=py -2\n>     else\n>     PYTHON?=python3\n>     endif\n\nPerhaps, `ifeq($(OS),Windows_NT)` would work. My .profile had one.","author":"yuja","id":"107174","dateCreated":"1573224885","dateModified":"1573224885"},{"type":"comment","comment":">>! In D7258#106995, @durin42 wrote:\n>>>! In D7258#106949, @mharbison72 wrote:\n>> This will break Windows by default, because py3 is still named `python.exe`.  Alternately, I've been using using `PYTHON=\"py -3\"` to invoke `make`.\n> \n> I'm not sure what we should do here. We probably can't change the default only for Windows somehow? (My make-fu is not awesome)\n\n    ifeq ($(shell uname -o), Msys)\n    PYTHON?=py -2\n    else\n    PYTHON?=python3\n    endif\n\nGenerally I just test `uname`, but that prints \"MINGW32_NT-6.2\" on Windows 10 and \"MINGW32_NT-6.1\" on Win7.\n\n>> \n>> The command issued to the buildbot will need to explicitly use `PYTHON=\"py -2\"` to keep that happy.  Probably also need to invoke `run-tests.py` with the right python too, so that `$PYTHON` is correct.  It looks like the shebang lines are already `$PYTHON`, through some aren't quoted.\n> \n> Okay, I'll see about wiring that up tonight or tomorrow then. I believe that's the only (other) thing blocking this?\n\nI think that's correct.  I vaguely recall that some test helpers were run like `.\/foo.py` at one point, which works on Windows because the registered file handler for *.py is python2.  But that's more of an issue with py3 porting, and shouldn't block this.  And maybe it was fixed with all of the $PYTHON work you did.\n\n","author":"mharbison72","id":"106996","dateCreated":"1573176080","dateModified":"1573176080"},{"type":"comment","comment":">>! In D7258#106949, @mharbison72 wrote:\n> This will break Windows by default, because py3 is still named `python.exe`.  Alternately, I've been using using `PYTHON=\"py -3\"` to invoke `make`.\n\nI'm not sure what we should do here. We probably can't change the default only for Windows somehow? (My make-fu is not awesome)\n\n> \n> The command issued to the buildbot will need to explicitly use `PYTHON=\"py -2\"` to keep that happy.  Probably also need to invoke `run-tests.py` with the right python too, so that `$PYTHON` is correct.  It looks like the shebang lines are already `$PYTHON`, through some aren't quoted.\n\nOkay, I'll see about wiring that up tonight or tomorrow then. I believe that's the only (other) thing blocking this?\n\n> \n> CC @durin42\n\n","author":"durin42","id":"106995","dateCreated":"1573158555","dateModified":"1573158555"},{"type":"comment","comment":"This will break Windows by default, because py3 is still named `python.exe`.  Alternately, I've been using using `PYTHON=\"py -3\"` to invoke `make`.\n\nThe command issued to the buildbot will need to explicitly use `PYTHON=\"py -2\"` to keep that happy.  Probably also need to invoke `run-tests.py` with the right python too, so that `$PYTHON` is correct.  It looks like the shebang lines are already `$PYTHON`, through some aren't quoted.\n\nCC @durin42","author":"mharbison72","id":"106950","dateCreated":"1573144562","dateModified":"1573144562"},{"type":"comment","comment":">>! In D7258#106380, @martinvonz wrote:\n> All tests except for `test-check-py3-compat.t` pass on py3 (on Linux), right?\n\nYes, tests are clean on Python 3.6 and 3.7. See https:\/\/ci.hg.gregoryszorc.com\/.","author":"indygreg","id":"106704","dateCreated":"1573113816","dateModified":"1573113816"},{"type":"comment","comment":"All tests except for `test-check-py3-compat.t` pass on py3 (on Linux), right?","author":"martinvonz","id":"106380","dateCreated":"1573066343","dateModified":"1573066343"},{"type":"accept","author":"martinvonz","id":"106379","dateCreated":"1573066343","dateModified":"1573066343"},{"type":"update","diffId":"17627","author":"indygreg","id":"106370","dateCreated":"1573065798","dateModified":"1573065798"}],"dateCreated":"1573065798","dateModified":"1574396524","status":"Accepted"},{"id":"7296","callsign":"HG","title":"pycompat: kludge around pytype being confused by __new__","author":"durin42","summary":"Credit to Yuya for the idea of annotating the class as though it was a\ncallable. I honestly didn't expect this to work, but it does!\n\nWe annotate this awkwardly on a name alias of the type because putting\nthe annotation directly on the `class ...:` line as a comment breaks\nblack and I don't want to go down that rabbit hole.","testPlan":"","lineCount":"17","dependsOn":[],"reviewers":["indygreg","dlax"],"ccs":["yuja","mjpieters","dlax","indygreg","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D7296#109684, @dlax wrote:\n> Looking closer at the error above, it mentions `bytestr.__init__`, not `__new__` (and there is in fact no type annotation for `__new__` in [typeshed](https:\/\/github.com\/python\/typeshed\/blob\/34d68ab0a2117a08fa221d3a10884f35cacf2cdc\/stdlib\/2and3\/builtins.pyi#L559)). \n\nhttps:\/\/github.com\/python\/typeshed\/issues\/2630","author":"dlax","id":"109688","dateCreated":"1574194446","dateModified":"1574194446"},{"type":"inline","comment":"Now the `type: ` is missing, so the comment is ignored.\n\nAdding it, `pytype mercurial\/pycompat.py` gives:\n```\nmercurial\/pycompat.py\", line 305, in <module>: Invalid type comment: Callable[[Union[bytes, str]], bytestr] [invalid-type-comment]\n  Name 'bytestr' is not defined\n```\nhence the kind of trick I suggested in my first comment on this line.","replyTo":null,"isNewFile":"1","line":"305","lineLength":"0","path":"mercurial\/pycompat.py","diffId":"18243","author":"dlax","id":"109687","dateCreated":"1574194206","dateModified":"1574194206"},{"type":"comment","comment":">>! In D7296#109683, @durin42 wrote:\n>>>! In D7296#109672, @dlax wrote:\n>> Sorry, still not ok afaict :\/\n> \n> So, I tried fixing this and it actually made things worse? dagparser.py no longer typechecks if I correct the syntax? Try the pytype invocation from the test at the end of the series and you'll see what I mean.\n\nOk, trying `pytype mercurial\/dagparser.py` I get a couple of those errors:\n```\nFile \"...\/mercurial\/dagparser.py\", line 172, in parsedag: Function bytestr.__init__ was called with the wrong arguments [wrong-arg-types]\n  Expected: (self, ints: Iterable[int])\n  Actually passed: (self, ints: str)\n```\n\nMy point was that we need to keep \"mercurial\/pycompat.py\" passing pytype before considering modules it depends on. Once the missing `type: ` is added and bytestr <-> _bytestr trick applied, it's okay but the error in dagparser.py persists...\nLooking closer at the error above, it mentions `bytestr.__init__`, not `__new__` (and there is in fact no type annotation for `__new__` in [typeshed](https:\/\/github.com\/python\/typeshed\/blob\/34d68ab0a2117a08fa221d3a10884f35cacf2cdc\/stdlib\/2and3\/builtins.pyi#L559)). So I suspect the \"Callable\" trick is not enough and we'd need a workaround similar to da925257 by @yuja . ","author":"dlax","id":"109686","dateCreated":"1574194206","dateModified":"1574194206"},{"type":"comment","comment":">>! In D7296#109672, @dlax wrote:\n> Sorry, still not ok afaict :\/\n\nSo, I tried fixing this and it actually made things worse? dagparser.py no longer typechecks if I correct the syntax? Try the pytype invocation from the test at the end of the series and you'll see what I mean.","author":"durin42","id":"109683","dateCreated":"1574187658","dateModified":"1574187658"},{"type":"update","diffId":"18243","author":"durin42","id":"109678","dateCreated":"1574187647","dateModified":"1574187647"},{"type":"inline","comment":"same here about missing `]`.","replyTo":null,"isNewFile":"1","line":"414","lineLength":"0","path":"mercurial\/pycompat.py","diffId":"18240","author":"dlax","id":"109674","dateCreated":"1574181559","dateModified":"1574181559"},{"type":"inline","comment":"`]` is still at the wrong place, I think. Should be `Callable[[Union[bytes, str]], bytestr]`.\nThen I still get the \"Name 'bytestr' is not defined\" error mentioned above.","replyTo":null,"isNewFile":"1","line":"305","lineLength":"0","path":"mercurial\/pycompat.py","diffId":"18240","author":"dlax","id":"109673","dateCreated":"1574181559","dateModified":"1574181559"},{"type":"comment","comment":"Sorry, still not ok afaict :\/","author":"dlax","id":"109672","dateCreated":"1574181559","dateModified":"1574181559"},{"type":"reject","author":"dlax","id":"109671","dateCreated":"1574181559","dateModified":"1574181559"},{"type":"update","diffId":"18240","author":"durin42","id":"109659","dateCreated":"1574180082","dateModified":"1574180082"},{"type":"comment","comment":"@durin42 I just queued most of the remaining patches in this series. This one still needs your attention, it appears.","author":"indygreg","id":"109571","dateCreated":"1574135272","dateModified":"1574135272"},{"type":"inline","comment":"A `]` is missing before `, bytestr`. Then, it's also missing `typing` imports.\nBut, even with this, I get:\n\n```\nInvalid type comment: Callable[[Union[bytes, str]], bytestr] [invalid-type-comment]\n  Name 'bytestr' is not defined\n```\n\nI'm able to make this pass with:\n```\nbytestr = _bytestr\nbytestr = bytestr  # type: Callable[[Union[bytes, str]], bytestr]\n```\n\n","replyTo":null,"isNewFile":"1","line":"294","lineLength":"0","path":"mercurial\/pycompat.py","diffId":"18170","author":"dlax","id":"109308","dateCreated":"1573896532","dateModified":"1573896532"},{"type":"reject","author":"dlax","id":"109307","dateCreated":"1573896532","dateModified":"1573896532"},{"type":"update","diffId":"18170","author":"durin42","id":"109260","dateCreated":"1573854911","dateModified":"1573854911"},{"type":"comment","comment":"black complains because inline comments have only one space before (esp. the first one produces a parse error).\nLGTM otherwise.","author":"dlax","id":"109206","dateCreated":"1573840061","dateModified":"1573840061"},{"type":"update","diffId":"18163","author":"durin42","id":"109203","dateCreated":"1573839171","dateModified":"1573839171"},{"type":"update","diffId":"18161","author":"durin42","id":"109198","dateCreated":"1573839068","dateModified":"1573839068"},{"type":"comment","comment":"Rather `class bytestr(bytes):  # type: Callable[[Union[bytes, str], bytestr]` as @yuya suggested in D7380.","author":"dlax","id":"109159","dateCreated":"1573815818","dateModified":"1573815818"},{"type":"reject","author":"dlax","id":"109157","dateCreated":"1573815818","dateModified":"1573815818"},{"type":"comment","comment":"```\nclass bytestr(bytes):  # type: (Union[bytes,str]) -> bytestr\n  [...]\n```\n\nDoes this work?","author":"dlax","id":"108595","dateCreated":"1573729523","dateModified":"1573729523"},{"type":"update","diffId":"18066","author":"durin42","id":"108497","dateCreated":"1573703466","dateModified":"1573703466"},{"type":"comment","comment":"I'm going to mark for revisions until we know more so this doesn't show up in the reviewable list.","author":"indygreg","id":"107463","dateCreated":"1573231683","dateModified":"1573231683"},{"type":"reject","author":"indygreg","id":"107462","dateCreated":"1573231683","dateModified":"1573231683"},{"type":"comment","comment":"I've filed a bug with the pytype team, I'll report back.","author":"durin42","id":"106946","dateCreated":"1573142864","dateModified":"1573142864"},{"type":"comment","comment":"This one makes me sad because of potential performance regressions due to call overhead. I'd almost rather rip out Python 2 support rather than land this. But I could be convinced if pytypes is as cool as you say...\n\nIs there no way to annotate the types here without the call overhead? Could we do something like an `if False` trick to define a `def bytestr()` with the proper annotations? Surely there's got to be a way...","author":"indygreg","id":"106892","dateCreated":"1573115914","dateModified":"1573115914"},{"type":"update","diffId":"17672","author":"durin42","id":"106678","dateCreated":"1573082663","dateModified":"1573082663"}],"dateCreated":"1573082663","dateModified":"1574194446","status":"Needs Review"},{"id":"7416","callsign":"HG","title":"procutil: support for obtaining an importlib.abc.ResourceReader","author":"indygreg","summary":"Python 3.7's importing mechanism offers a new \"resource reader\"\nAPI that allows module loaders to provide an object which can be\nused for obtaining information and data about \"resources\" in a\nPython package. This API is the new recommended way for modules\nto load data for non-module entities, such as text files and\nother support files residing next to sources. This functionality\nis similar to pkg_resources (which has existed for a long time)\nand importlib.abc.ResourceLoader, which was introduced in Python 3\nand is deprecated in favor of ResourceReader.\n\nUsing a \"resource reader\" is a superior approach to pkg_resources\nbecause it is newer and faster. And both are superior to __file__\nbased filesystem reading because they allow the storage of\nresources in places that aren't the filesystem. This allows things\nlike embedding resources in zip files or single file binaries.\n\nThis commit introduces a \"resource reader\" API into the procutil\nmodule.\n\nWe introduce an importlib.abc.ResourceReader compatible class\nwhich can load resources from the filesystem.\n\nWe introduce another class that wraps an existing ResourceReader\nso callers don't need to worry about bytes\/str differences.\n\nFinally, there is a new \"resourcereader()\" that returns a\nResourceReader for a given Python package. The idea is that\ncode will call ``pycompat.resourcereader(__package__)`` (or\nsimilar) to obtain an object conforming to\nimportlib.abc.ResourceReader then from there on, things will\nlook like they would as if the code were Python 3.7 native.\n\nThe ultimate goal is to remove the dependence on __file__\nand util.datapath so non-module data file access is abstract\nand doesn't need to be serviced by a traditional filesystem.\n\nThe new code will return bad results for py2exe and macOS\napplication builds because resource files live in immediate\nsubdirectories of the binary instead of next to the source.\nThis will be addressed in future commits.\n\n# no-check-commit because we must use foo_bar naming","testPlan":"","lineCount":"123","dependsOn":[],"reviewers":[],"ccs":["martinvonz","mercurial-devel"],"actions":[{"type":"comment","comment":"@martinvonz do you want to pick up this series or do you want me to rebase it on top of `packageutil`? If you leave it up to me, I'm not sure when I'll get around to it. (I'd prefer to focus my time on shoring up PyOxidizer.)\n\nIf you do pick this up, an alternative to this approach would be to vendor `importlib_resources` (https:\/\/importlib-resources.readthedocs.io\/en\/latest\/index.html) or consider using its code\/approach instead of rolling so much of a custom solution. That being said, I feel like I already wrote enough of the code to support the modern resources API and Mercurial would require sufficient changes for things to work in the domain of `bytes` that importing `importlib_resources` doesn't seem worthwhile.\n\nIf you do take this series, something to consider for templates is the implication for users wanting to edit templates. If templates are embedded in the binary, how do users define their own custom versions of the build-in templates? We already have a permissions problem when the provided templates are read-only and the user can't edit them in place. But with PyOxidizer, if templates are embedded in the binary, the user won't even have access to their raw content! We would likely need to supply an `hg debugextracttemplates` command or something to allow the user to obtain a copy of the embedded templates.","author":"indygreg","id":"109391","dateCreated":"1573932443","dateModified":"1573932443"},{"type":"plan-changes","author":"indygreg","id":"109038","dateCreated":"1573790504","dateModified":"1573790504"},{"type":"update","diffId":"18139","author":"indygreg","id":"109004","dateCreated":"1573790317","dateModified":"1573790317"}],"dateCreated":"1573790317","dateModified":"1573932443","status":"Changes Planned"},{"id":"7422","callsign":"HG","title":"rust: remove hgcli project","author":"indygreg","summary":"This code is a logical precursor to PyOxidizer, which we will soon\nintroduce to provide similar functionality.","testPlan":"","lineCount":"517","dependsOn":[],"reviewers":[],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"We'll want to hold off on this until PyOxidizer is ready.","author":"indygreg","id":"109094","dateCreated":"1573794123","dateModified":"1573794123"},{"type":"plan-changes","author":"indygreg","id":"109093","dateCreated":"1573794123","dateModified":"1573794123"},{"type":"update","diffId":"18146","author":"indygreg","id":"109070","dateCreated":"1573793998","dateModified":"1573793998"}],"dateCreated":"1573793998","dateModified":"1573794124","status":"Changes Planned"},{"id":"7419","callsign":"HG","title":"help: port to ResourceReader API","author":"indygreg","summary":"Previous commits introduced a mechanism to obtain an\nimportlib.abc.ResourceReader for Mercurial resource data.\n\nThis commit ports I\/O in the help system to use this API.\nBy doing so, we abstract I\/O away from the help system and\nallow help files to be served from something that isn't\na traditional filesystem.","testPlan":"","lineCount":"18","dependsOn":["7418"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"I have other patches to attempt to do similar things for templating and rc.d files if there is interest in reviving this series.","author":"indygreg","id":"109044","dateCreated":"1573790615","dateModified":"1573790615"},{"type":"plan-changes","author":"indygreg","id":"109043","dateCreated":"1573790615","dateModified":"1573790615"},{"type":"update","diffId":"18142","author":"indygreg","id":"109028","dateCreated":"1573790325","dateModified":"1573790325"}],"dateCreated":"1573790325","dateModified":"1573790615","status":"Changes Planned"},{"id":"7418","callsign":"HG","title":"procutil: teach resourcereader() to handle exe relative resources","author":"indygreg","summary":"Mercurial distributions like those produced with py2exe store\ntheir data\/resource files relative to the executable. For\nexample, in our Windows distributions, help files are in\nthe help\/ directory relative to hg.exe.\n\nIn a future world where we are using the ResourceReader API\nfor accessing package resources, we need a way to provide\na ResourceReader for these pieces of data without breaking\nthese Mercurial distributions.\n\nThis commit introduces logic into resourcereader() which will\nreturn a filesystem-based ResourceReader if resources are\nrelative to the executable and we are requesting resources for\nthe \"mercurial\" package.\n\nIdeally we wouldn't need to do this and would instead change\npackaging. However, various downstream consumers may be sensitive\nto changes in the on-disk layout of Mercurial installs. I'm\nunwilling to cross this bridge at this time. I think it is more\nimportant to get things working with the ResourceReader API first.\nThen we can tackle better resource packaging\/installation.\n\nIt is also likely that we'll need more logic to handle additional\npackages\/resources. For example, help resources are always in a\nhelp\/ directory and map cleanly, but templates resources are in a\nTemplates\/ directory and there are case-sensitivity concerns.\nOur initial target for using the resource reading API is help.\nSo we can defer on additional complexity.","testPlan":"","lineCount":"8","dependsOn":["7417"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"The commit message on this one is probably a bit out of date, since packaging has changed some since I initially authored this commit.","author":"indygreg","id":"109042","dateCreated":"1573790569","dateModified":"1573790569"},{"type":"plan-changes","author":"indygreg","id":"109041","dateCreated":"1573790569","dateModified":"1573790569"},{"type":"update","diffId":"18141","author":"indygreg","id":"109020","dateCreated":"1573790322","dateModified":"1573790322"}],"dateCreated":"1573790322","dateModified":"1573790570","status":"Changes Planned"},{"id":"7417","callsign":"HG","title":"procutil: extract executable-relative resources test","author":"indygreg","summary":"We'll want to test for this in the new resource reading API.","testPlan":"","lineCount":"6","dependsOn":["7416"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"plan-changes","author":"indygreg","id":"109039","dateCreated":"1573790518","dateModified":"1573790518"},{"type":"update","diffId":"18140","author":"indygreg","id":"109012","dateCreated":"1573790319","dateModified":"1573790319"}],"dateCreated":"1573790319","dateModified":"1573790519","status":"Changes Planned"},{"id":"7257","callsign":"HG","title":"[RFC] repoview: add a \"filter\" that just disallows walking to heads","author":"martinvonz","summary":"This can let us find bugs where we think it shouldn't matter whether\nwe're using an unfiltered or filtered repo. We could then get a repo\nthat is using this new \"filter\" and if the code ends up trying to walk\nthe graph towards the changelog children, we would notice that.","testPlan":"","lineCount":"30","dependsOn":[],"reviewers":["durin42"],"ccs":["durin42","marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":"I'm a big fan of this idea. I'd probably land it if there were some obvious usecases as child patches. :)","author":"durin42","id":"108443","dateCreated":"1573686616","dateModified":"1573686616"},{"type":"accept","author":"durin42","id":"108442","dateCreated":"1573686616","dateModified":"1573686616"},{"type":"comment","comment":">>! In D7257#108377, @marmoute wrote:\n> Can you elaborate on what this changeset is about ? the description is a bit\u2026 short;-)\n\nDone.","author":"martinvonz","id":"108379","dateCreated":"1573597314","dateModified":"1573597314"},{"type":"comment","comment":"Can you elaborate on what this changeset is about ? the description is a bit\u2026 short;-)","author":"marmoute","id":"108377","dateCreated":"1573596371","dateModified":"1573596371"},{"type":"update","diffId":"18048","author":"martinvonz","id":"108373","dateCreated":"1573594402","dateModified":"1573594402"},{"type":"update","diffId":"17625","author":"martinvonz","id":"106360","dateCreated":"1573059703","dateModified":"1573059703"}],"dateCreated":"1573059703","dateModified":"1573686616","status":"Needs Review"},{"id":"7149","callsign":"HG","title":"export: use unfiltered repo if we're exporting the working copy parent","author":"martinvonz","summary":"Same reasoning as in the previous patch. `hg export` drops from 0.180s\nto 0.140s.","testPlan":"","lineCount":"5","dependsOn":["7148"],"reviewers":["durin42"],"ccs":["marmoute","mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"108439","dateCreated":"1573686494","dateModified":"1573686494"},{"type":"update","diffId":"18047","author":"martinvonz","id":"108371","dateCreated":"1573594374","dateModified":"1573594374"},{"type":"comment","comment":"Do you have performance number for this?","author":"marmoute","id":"105045","dateCreated":"1571780532","dateModified":"1571780532"},{"type":"update","diffId":"17370","author":"martinvonz","id":"105031","dateCreated":"1571766921","dateModified":"1571766921"}],"dateCreated":"1571766921","dateModified":"1573686494","status":"Accepted"},{"id":"7148","callsign":"HG","title":"annotate: use unfiltered repo if we're annotating the working copy","author":"martinvonz","summary":"Same reasoning as in the previous patch. Speeds up `hg blame\nmercurial\/phases.py` from 0.365s to 0.304s.","testPlan":"","lineCount":"5","dependsOn":[],"reviewers":["durin42"],"ccs":["marmoute","mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"108437","dateCreated":"1573686482","dateModified":"1573686482"},{"type":"update","diffId":"18046","author":"martinvonz","id":"108369","dateCreated":"1573594373","dateModified":"1573594373"},{"type":"comment","comment":"Do you have performance number for this ?","author":"marmoute","id":"105043","dateCreated":"1571780515","dateModified":"1571780515"},{"type":"update","diffId":"17369","author":"martinvonz","id":"105023","dateCreated":"1571766919","dateModified":"1571766919"}],"dateCreated":"1571766919","dateModified":"1573686482","status":"Accepted"},{"id":"7221","callsign":"HG","title":"hghave: fix bytes\/string issue on Python 3","author":"durin42","summary":"","testPlan":"","lineCount":"2","dependsOn":[],"reviewers":["pulkit"],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"This has already been pushed as https:\/\/www.mercurial-scm.org\/repo\/hg-committed\/rev\/c3bca833cb92","author":"pulkit","id":"108165","dateCreated":"1573472172","dateModified":"1573472172"},{"type":"accept","author":"pulkit","id":"105995","dateCreated":"1572945328","dateModified":"1572945328"},{"type":"update","diffId":"17536","author":"durin42","id":"105893","dateCreated":"1572902431","dateModified":"1572902431"}],"dateCreated":"1572902431","dateModified":"1573472172","status":"Accepted"},{"id":"7189","callsign":"HG","title":"git: use bytes in command name, not unicode","author":"maho","summary":"","testPlan":"","lineCount":"2","dependsOn":["7188"],"reviewers":[],"ccs":["durin42","mercurial-devel"],"actions":[{"type":"comment","comment":"Thanks, I've folded this into my initial patch so I won't break Python 3!\n\nI'm hoping to come back to this topic soon and get an initial version of the git extension landed - mostly I want to clean up how manifests\/trees work and then I think it's worth landing.","author":"durin42","id":"106368","dateCreated":"1573063581","dateModified":"1573063581"},{"type":"update","diffId":"17443","author":"maho","id":"105469","dateCreated":"1572626358","dateModified":"1572626358"}],"dateCreated":"1572626358","dateModified":"1573063582","status":"Needs Review"},{"id":"7187","callsign":"HG","title":"py3: fix fsmonitor error message formatting under Python3","author":"touilleMan","summary":"The watchmanclient.Unavailable exception got an invalid __str__\nmethod resulting in a crash when watchman is not available.\nThis fix also solve tests\/test-install.t.","testPlan":"","lineCount":"8","dependsOn":[],"reviewers":["indygreg"],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"inline","comment":"There's no `__bytes__` on Python 2. So we'll want to preserve an implementation for Python 2.\n\nThis is typically something like `__str__ = encoding.strmethod(__bytes__)`","replyTo":null,"isNewFile":"1","line":"26","lineLength":"0","path":"hgext\/fsmonitor\/watchmanclient.py","diffId":"17435","author":"indygreg","id":"105538","dateCreated":"1572628941","dateModified":"1572628941"},{"type":"reject","author":"indygreg","id":"105537","dateCreated":"1572628941","dateModified":"1572628941"},{"type":"update","diffId":"17435","author":"touilleMan","id":"105456","dateCreated":"1572624986","dateModified":"1572624986"},{"type":"update","diffId":"17434","author":"touilleMan","id":"105451","dateCreated":"1572624852","dateModified":"1572624852"}],"dateCreated":"1572624852","dateModified":"1572628941","status":"Needs Revision"},{"id":"7188","callsign":"HG","title":"git: force using bytes in command name","author":"maho","summary":"","testPlan":"","lineCount":"2","dependsOn":["6734"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"17442","author":"maho","id":"105464","dateCreated":"1572626352","dateModified":"1572626352"}],"dateCreated":"1572626352","dateModified":"1572626714","status":"Needs Review"},{"id":"7176","callsign":"HG","title":"rebase: allow rebasing obsolete commit without successor","author":"martinvonz","summary":"When trying to rebase an obsolete whose successors are also all\nobsolete, we would skip it and tell the user that it would have caused\ndivergence. That is not correct. We could just change the message, but\nI don't see any harm in rebasing such commits. It even seems like a\nreasonable way to make it not obsolete. So this patch makes that type\nof rebase allowed.","testPlan":"","lineCount":"9","dependsOn":["7175"],"reviewers":[],"ccs":["marmoute","khanchi97","mercurial-devel"],"actions":[{"type":"comment","comment":"That is not necessarly True, If the changeset is pruned, but successors of a public changeset, rebasing it would create phase-divergence. @khanchi97 fixed similar cases in September.\n\nOverall, we should migrate the rebase code to use the `precheck` logic in rewrite util (and make sure things are well covered there).\n\nOne can read more about current Sushil work in this area here: https:\/\/www.mercurial-scm.org\/wiki\/CEDPrecheckPlan.","author":"marmoute","id":"105351","dateCreated":"1572465579","dateModified":"1572465579"},{"type":"update","diffId":"17409","author":"martinvonz","id":"105299","dateCreated":"1572050933","dateModified":"1572050933"}],"dateCreated":"1572050933","dateModified":"1572465579","status":"Needs Review"},{"id":"7175","callsign":"HG","title":"tests: add test showing incorrect note about not rebasing extinct commit","author":"martinvonz","summary":"If all successors are obsolete, then rebasing the commit will not\ncause divergence.","testPlan":"","lineCount":"8","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"17408","author":"martinvonz","id":"105293","dateCreated":"1572050931","dateModified":"1572050931"}],"dateCreated":"1572050931","dateModified":"1572050933","status":"Needs Review"},{"id":"7146","callsign":"HG","title":"[RFC] grep: add config option to grep PWD by default","author":"pulkit","summary":"This is motivated by a disscussion on IRC.\n\nTODO: need to add tests, register config option and add docs.\n\nTests are not ran on this yet.","testPlan":"","lineCount":"3","dependsOn":[],"reviewers":[],"ccs":["mharbison72","durin42","jeffpc","JordiGH","mercurial-devel"],"actions":[{"type":"comment","comment":"I lean towards searching the whole repo by default, for the reasons that Jordi listed, especially consistency with other hg commands.\n\nI almost never `hg grep` from the command line, and typically search in TortoiseHg instead.  But there, I always want it to search everything by default, unless I start passing `-X`.  (I realize a change here doesn't mean it has to change in thg, just relaying my typical usage and expectations.)\n\nI do think a config option to swap the default is reasonable, if for no other reason than $PWD is chosen for the default, and I can still get the behavior I'd expect.","author":"mharbison72","id":"105051","dateCreated":"1571799054","dateModified":"1571799054"},{"type":"comment","comment":"(Note that post-5.2 is probably too late to make this tweak, so there's some urgency in this discussion.)","author":"durin42","id":"105005","dateCreated":"1571764000","dateModified":"1571764000"},{"type":"comment","comment":"Huh, this behavior of `git grep` surprises me, but not _that_ much.\n\nWe do already print PWD-relative paths if `tweakdefaults` is active, right?","author":"durin42","id":"105004","dateCreated":"1571763976","dateModified":"1571763976"},{"type":"comment","comment":"I'm the instigator of the IRC discussion, so I'll summarize my reasoning here as well.\n\nBased on years of working on various sw projects, I've concluded that about 90% of the time I want to grep $PWD and the remaining 10% of the time I want to grep the whole repo.  (It is possible that my usage is very weird, but I'm pretty sure I'm not the only one.)\n\nWhile I agree that consistency is important, usability is also important.  If the common operation is to grep the $PWD (and that is what happens if you run `grep -R` or `git grep` or many other \"grepping\" tools), then it should be the default for \"hg grep\".\n\nI realize that the new \"hg grep\" behavior hasn't even made it into a release yet, and therefore usage data is essentially non-existent.","author":"jeffpc","id":"105002","dateCreated":"1571761441","dateModified":"1571761441"},{"type":"comment","comment":"I will repeat my position as stated on IRC. I am against this change because,\n\n# it's inconsistent with shelve, commit, addremove, status, diff and all other operations that by default work on the entire repo\n# it's difficult to go from this proposed default to grepping the entire repo \n# it's easy and natural for the user to add this dot themselves\n# there's no permanent consequence if the user accidentally greps the whole repo; only a little bit of extra output and some CPU wasted\n# there's already a way to change this default: `alias.grep = grep -I .`","author":"JordiGH","id":"105000","dateCreated":"1571760648","dateModified":"1571760818"},{"type":"update","diffId":"17365","author":"pulkit","id":"104994","dateCreated":"1571760399","dateModified":"1571760399"}],"dateCreated":"1571760399","dateModified":"1571799054","status":"Needs Review"},{"id":"7135","callsign":"HG","title":"copies: filter out file already in parent in duplicatecopies()","author":"martinvonz","summary":"I noticed that duplicatecopies() can end up marking a file as a copy\neven if the file already exists in the parent. At least when using\noverlayworkingctx for creating the commit, it ended up in the commit's\n\"files\" field, which means it showed as a modified in `hg status\n--change .`. It doesn't seem like we produced any such commit in core,\nbut we did end up producing some empty commits, as can be seen in the\nupdated tests.","testPlan":"","lineCount":"43","dependsOn":[],"reviewers":[],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D7135#104907, @martinvonz wrote:\n>>>! In D7135#104894, @yuja wrote:\n>>> --- a\/tests\/test-issue1175.t\n>>> +++ b\/tests\/test-issue1175.t\n>>> @@ -82,7 +82,6 @@\n>>>    continue: hg graft --continue\n>>>    $ hg graft --continue\n>>>    grafting 1:5974126fad84 \"b1\"\n>>> -  warning: can't find ancestor for 'b' copied from 'a'!\n>>>    $ hg log -f b -T 'changeset:   {rev}:{node|short}\\nsummary:     {desc}\\n\\n'\n>>>    changeset:   3:376d30ccffc0\n>>>    summary:     b1\n>> \n>> This test was added at a43fdf33a6be, which might need bad copy information.\n> \n> Ah, so maybe the bug used to be incorrectly suppressed by the logic for finding the source in an old version. Thanks for digging that up. I somehow didn't think to check.\n> \n>> \n>>> --- a\/mercurial\/copies.py\n>>> +++ b\/mercurial\/copies.py\n>>> @@ -810,10 +810,11 @@\n>>>          # of the function is much faster (and is required for carrying copy\n>>>          # metadata across the rebase anyway).\n>>>          exclude = pathcopies(repo[fromrev], repo[skiprev])\n>>> +    pctx = wctx.p1()\n>>>      for dst, src in pycompat.iteritems(pathcopies(repo[fromrev], repo[rev])):\n>>>          if dst in exclude:\n>>>              continue\n>>> -        if dst in wctx:\n>>> +        if dst in wctx and dst not in pctx:\n>>>              wctx[dst].markcopied(src)\n>> \n>> Seems fine as we don't support `hg rm b; hg cp a b` case.\n> \n> Yes, exactly. I should have mentioned that.\n\nI was working on something unrelated just now and it turned out to be a little related to this. I was reminded that we have `hg cp --force` to \"forcibly copy over an existing managed file\". If you don't use that and try to copy onto an existing file, you'll get this hint: \"'hg copy --force' to replace the file by recording a copy\". It sounds like the plan was to allow you to copy a file onto an existing one to record it as a copy. We also have tests in `test-copy.t` showing the status of that. So I think I should rethink this patch.","author":"martinvonz","id":"104909","dateCreated":"1571465574","dateModified":"1571465574"},{"type":"plan-changes","author":"martinvonz","id":"104908","dateCreated":"1571465574","dateModified":"1571465574"},{"type":"comment","comment":">>! In D7135#104894, @yuja wrote:\n>> --- a\/tests\/test-issue1175.t\n>> +++ b\/tests\/test-issue1175.t\n>> @@ -82,7 +82,6 @@\n>>    continue: hg graft --continue\n>>    $ hg graft --continue\n>>    grafting 1:5974126fad84 \"b1\"\n>> -  warning: can't find ancestor for 'b' copied from 'a'!\n>>    $ hg log -f b -T 'changeset:   {rev}:{node|short}\\nsummary:     {desc}\\n\\n'\n>>    changeset:   3:376d30ccffc0\n>>    summary:     b1\n> \n> This test was added at a43fdf33a6be, which might need bad copy information.\n\nAh, so maybe the bug used to be incorrectly suppressed by the logic for finding the source in an old version. Thanks for digging that up. I somehow didn't think to check.\n\n> \n>> --- a\/mercurial\/copies.py\n>> +++ b\/mercurial\/copies.py\n>> @@ -810,10 +810,11 @@\n>>          # of the function is much faster (and is required for carrying copy\n>>          # metadata across the rebase anyway).\n>>          exclude = pathcopies(repo[fromrev], repo[skiprev])\n>> +    pctx = wctx.p1()\n>>      for dst, src in pycompat.iteritems(pathcopies(repo[fromrev], repo[rev])):\n>>          if dst in exclude:\n>>              continue\n>> -        if dst in wctx:\n>> +        if dst in wctx and dst not in pctx:\n>>              wctx[dst].markcopied(src)\n> \n> Seems fine as we don't support `hg rm b; hg cp a b` case.\n\nYes, exactly. I should have mentioned that.","author":"martinvonz","id":"104907","dateCreated":"1571462097","dateModified":"1571462097"},{"type":"comment","comment":"> --- a\/tests\/test-issue1175.t\n> +++ b\/tests\/test-issue1175.t\n> @@ -82,7 +82,6 @@\n>    continue: hg graft --continue\n>    $ hg graft --continue\n>    grafting 1:5974126fad84 \"b1\"\n> -  warning: can't find ancestor for 'b' copied from 'a'!\n>    $ hg log -f b -T 'changeset:   {rev}:{node|short}\\nsummary:     {desc}\\n\\n'\n>    changeset:   3:376d30ccffc0\n>    summary:     b1\n\nThis test was added at a43fdf33a6be, which might need bad copy information.\n\n> --- a\/mercurial\/copies.py\n> +++ b\/mercurial\/copies.py\n> @@ -810,10 +810,11 @@\n>          # of the function is much faster (and is required for carrying copy\n>          # metadata across the rebase anyway).\n>          exclude = pathcopies(repo[fromrev], repo[skiprev])\n> +    pctx = wctx.p1()\n>      for dst, src in pycompat.iteritems(pathcopies(repo[fromrev], repo[rev])):\n>          if dst in exclude:\n>              continue\n> -        if dst in wctx:\n> +        if dst in wctx and dst not in pctx:\n>              wctx[dst].markcopied(src)\n\nSeems fine as we don't support `hg rm b; hg cp a b` case.","author":"yuja","id":"104894","dateCreated":"1571461776","dateModified":"1571461776"},{"type":"update","diffId":"17344","author":"martinvonz","id":"104863","dateCreated":"1571433874","dateModified":"1571433874"}],"dateCreated":"1571433874","dateModified":"1571465574","status":"Changes Planned"},{"id":"6929","callsign":"HG","title":"ci: add comment about block duration pricing","author":"indygreg","summary":"We can make things even cheaper if we remove the block duration\nfrom the spot request. I added a TODO to track this.","testPlan":"","lineCount":"7","dependsOn":["6928"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"plan-changes","author":"indygreg","id":"104754","dateCreated":"1571280747","dateModified":"1571280747"},{"type":"update","diffId":"16725","author":"indygreg","id":"101642","dateCreated":"1569904868","dateModified":"1569904868"}],"dateCreated":"1569904868","dateModified":"1571280747","status":"Changes Planned"},{"id":"6928","callsign":"HG","title":"ci: fetch explicit attributes","author":"indygreg","summary":"Now that we store the launch configuration in the job record\nand this launch configuration can be several KB large, we need\nto be careful about the data that we retrieve during queries, as\nthe overhead for fetching data we don't care about can be large.\n\nLet's fetch an explicit list of fields when rendering the main\nweb UI.","testPlan":"","lineCount":"21","dependsOn":["6927"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"plan-changes","author":"indygreg","id":"104753","dateCreated":"1571280738","dateModified":"1571280738"},{"type":"update","diffId":"16722","author":"indygreg","id":"101632","dateCreated":"1569902254","dateModified":"1569902254"}],"dateCreated":"1569902254","dateModified":"1571280738","status":"Changes Planned"},{"id":"6927","callsign":"HG","title":"ci: report cost to run each job","author":"indygreg","summary":"The spot instance request contains details on the cost to run\nthe instance. Let's record the hourly cost to run an instance\nin DynamoDB so we can use it to calculate the total compute cost\nto run a single job.\n\nAnd now that we store it, expose it in the web interface so there\nis visibility.","testPlan":"","lineCount":"37","dependsOn":["6926"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"plan-changes","author":"indygreg","id":"104752","dateCreated":"1571280729","dateModified":"1571280729"},{"type":"update","diffId":"16724","author":"indygreg","id":"101640","dateCreated":"1569904864","dateModified":"1569904864"},{"type":"update","diffId":"16721","author":"indygreg","id":"101624","dateCreated":"1569902253","dateModified":"1569902253"}],"dateCreated":"1569902253","dateModified":"1571280729","status":"Changes Planned"},{"id":"6925","callsign":"HG","title":"ci: track spot instance state, randomly assign availability zone","author":"indygreg","summary":"The previous implementation of spot instance requests was too\nnaive.\n\nI observed the CI system making spot instance requests that were\nexpiring due to insufficient capacity. And the web UI wasn't\nmaking this obvious.\n\nThis commit improves the scheduling of spot instances a little.\n\nFirst, we randomize the availability zone that the spot instance\nrequest is assigned to. I noticed all spot requests were being\nassigned to us-west-2c. Why, I'm not sure. The EC2 docs say\nAmazon will assign an availability zone randomly. But it was\nalways assigning the same zone without capacity. Choosing a\nrandom availability zone seems more robust.\n\nWe also update job state accounting to store the spot instance\nrequest ID and the number of spot instance requests. This will\nhelp us inspect the spot instance request after it has been\ncreated (functionality for doing so will be introduced in a\nsubsequent commit). We also update the execution state to\nreflect that a spot instance has been requested. This will give\nusers more context and can be used to influence behavior should\nwe want to try launching another instance at a later time.","testPlan":"","lineCount":"52","dependsOn":["6924"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"plan-changes","author":"indygreg","id":"104751","dateCreated":"1571280721","dateModified":"1571280721"},{"type":"comment","comment":"Oops.","author":"indygreg","id":"104750","dateCreated":"1571280714","dateModified":"1571280714"},{"type":"reclaim","author":"indygreg","id":"104749","dateCreated":"1571280714","dateModified":"1571280714"},{"type":"abandon","author":"indygreg","id":"104747","dateCreated":"1571280685","dateModified":"1571280685"},{"type":"update","diffId":"16719","author":"indygreg","id":"101608","dateCreated":"1569902247","dateModified":"1569902247"}],"dateCreated":"1569902247","dateModified":"1571280721","status":"Changes Planned"},{"id":"6926","callsign":"HG","title":"ci: retry expired spot instance requests","author":"indygreg","summary":"EC2 spot instance requests can fail. Often the root cause is no\navailability of spot instances in the given availability zone.\n\nThis commit teaches our CI system to recognize when a spot instance\nrequest has failed and to retry it.\n\nTo do this, we create a pair of new Lambda functions, \"spot instance\nrequest monitor\" and \"start job.\" The former is invoked periodically\nvia CloudWatch Event. It scans all jobs waiting on a spot instance\nrequest. If the spot instance request is cancelled, it calls into\nthe \"start job\" function, which simply calls an internal API for\ntrying to start a job given a job ID.\n\nOur strategy for retrying spot instance requests is to try to use\nthe \"next\" availability zone for the given region. We will cycle\nthrough availability zones until a spot instance request is\nacted on. In my testing, this always works. Although it could\ntake several minutes to cycle through all availability zones and\nfor an availability zone to have instance availability.\n\nThere are definitely other strategies we could try. For example,\nwe could try another AWS region. Or we could launch an on-demand\ninstance after N failures. Or we could launch a difference EC2\ninstance type - one with hopefully more availability. Or we could\nuse spot fleet requests (which allow launching from multiple\ninstance types). The easiest is probably to launch an on-demand\ninstance. But until we need this functionality, I'm inclined to\nnot build it, as I like the consistency of always using spot\ninstances.","testPlan":"","lineCount":"341","dependsOn":["6925"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"plan-changes","author":"indygreg","id":"104748","dateCreated":"1571280699","dateModified":"1571280699"},{"type":"update","diffId":"16723","author":"indygreg","id":"101639","dateCreated":"1569904860","dateModified":"1569904860"},{"type":"update","diffId":"16720","author":"indygreg","id":"101616","dateCreated":"1569902250","dateModified":"1569902250"}],"dateCreated":"1569902250","dateModified":"1571280700","status":"Changes Planned"},{"id":"6924","callsign":"HG","title":"ci: store job start parameters in DynamoDB","author":"indygreg","summary":"This makes it vastly easier to retry or retrigger a job,\nsince the instance launch state will be stored in the\ndatabase instead of in an ad-hoc SQS message.","testPlan":"","lineCount":"52","dependsOn":["6922"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"plan-changes","author":"indygreg","id":"104746","dateCreated":"1571280675","dateModified":"1571280675"},{"type":"update","diffId":"16718","author":"indygreg","id":"101600","dateCreated":"1569902245","dateModified":"1569902245"}],"dateCreated":"1569902245","dateModified":"1571280675","status":"Changes Planned"},{"id":"6922","callsign":null,"title":"ci: implement a \"try server\"","author":"indygreg","summary":"This commit implements a new CI component which allows privileged users\nto upload Mercurial bundles and have automation run against them. The\nfunctionality is similar to what exists in `contrib\/automation\/automation.py`\nfor running tests on remote AWS infrastructure. The big difference is\nmost of the heavy work is handled by the CI system instead of by the\nclient invoking AWS APIs directly. This makes it easier to scale and\ndoesn't require the user to have substantial privileges for an AWS\naccount.\n\nThis commit also introduces a client-side `ci.py` command line tool\nfor interacting with the CI system. This tool provides a `try`\nsub-command for generating a Mercurial bundle and directly invoking\na Lambda function with it.","testPlan":"","lineCount":"547","dependsOn":["6906"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"plan-changes","author":"indygreg","id":"104745","dateCreated":"1571280658","dateModified":"1571280658"},{"type":"update","diffId":"16854","author":"indygreg","id":"102379","dateCreated":"1570302289","dateModified":"1570302289"},{"type":"update","diffId":"16853","author":"indygreg","id":"102374","dateCreated":"1570300567","dateModified":"1570300567"},{"type":"update","diffId":"16717","author":"indygreg","id":"101597","dateCreated":"1569902243","dateModified":"1569902243"},{"type":"comment","comment":"This is less polished than the commit implementing the CI system. And it exposes some cracks in the design of the CI system (such as a missing abstraction for controlling what to run). But it does work.\n\nI still need to flush out how users are created, as getting credentials to the requesting user could be a bit annoying. We probably also want to configure MFA requirements to help mitigate abuse of the access keys. But it's a start and I'm potentially comfortable with this running during the Sprint to give people a way to quickly run tests.","author":"indygreg","id":"101492","dateCreated":"1569805112","dateModified":"1569805112"},{"type":"plan-changes","author":"indygreg","id":"101491","dateCreated":"1569805112","dateModified":"1569805112"},{"type":"update","diffId":"16696","author":"indygreg","id":"101484","dateCreated":"1569804812","dateModified":"1569804812"}],"dateCreated":"1569804812","dateModified":"1571280658","status":"Changes Planned"},{"id":"6906","callsign":"HG","title":"ci: implement a new CI system for Mercurial","author":"indygreg","summary":"tl;dr a new CI system built on top of AWS using mostly serverless\ntechnology is implemented. It can be seen at\nhttps:\/\/ci.hg.gregoryszorc.com\/\n\nMercurial's existing CI infrastructure is under-loved. This commit\nimplements an in-repository CI system for Mercurial.\n\nMy main motiviation for doing this is that the transition to Python 3\nwill require a substantial investment in CI and I think this is a good\nopportunity to revisit how the project currently does CI. The existing\nCI system is rooted in CI technology from yesterday and I think we can\niterate faster going forward by implementing CI in the main repository\non top of infrastructure that anyone can stand up if they have a credit\ncard.\n\nEverything in the new CI system is built on top of AWS. There are no\npersistent EC2 instances: all compute is ephemeral in \"serverless\"\nLambda functions or performed on EC2 instances spun up to run\nindividual jobs.\n\nI rejected building on top of existing CI platforms like Azure Pipelines\nor GitHub Actions because a) support for Mercurial is poor b) they don't\nprovide enough CPU horsepower to run Mercurial's test harness quickly c)\nif you want to buy enough CPU horsepower to do so, you need to run\npersistent servers which end up sitting around idle most of the time,\naccruing large bills. Standing up a basic CI system built on top of\nsimple event triggers (such as database row insertions triggering the\nlaunch of an EC2 instance to run a job) is not a lot of lines of code,\nsurprisingly. And the benefits we get from containing the entire stack\nand having everything be open source can be substantial.\n\nThe code in this commit is currently running at\nhttps:\/\/ci.hg.gregoryszorc.com\/ and is running out of an AWS account\nI currently have chained up to my personal AWS account. That includes\nbilling: I'm currently running this out of my own pocket. I'm fine\nwith that for now. But we'll probably want to move account ownership\nand billing to the official Mercurial Project at some point. Although\nif you catch me in a generous mood, I may foot the bill semi-permanently.\nAlthough it would be great to get the 501(c)(3) tax status hooked up\nso I can write off the expense. That may mean transferring account\nownership to the Mercurial Project. We can discuss offline...\n\nA lot of functionality is very rough around the edges. And there's a\nlot that could be implemented. The web interface in particular is\nrather primitive (I'm not great at web development). But it gets the\njob done. I've already found the functionality very useful for tracking\ndown Python 3 issues.\n\nThis is a lot of code to review at once. I suggest starting by reading\nthe added README.rst. Most of the business logic lives in the Lambda\nfunctions in ci.py. I tried to isolate the Terraform logic to\nper-component files to make everything easier to grok.","testPlan":"","lineCount":"2154","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"Since nobody seems to have plans to review this, I'll hold off on requesting review at this time.","author":"indygreg","id":"104744","dateCreated":"1571280642","dateModified":"1571280642"},{"type":"plan-changes","author":"indygreg","id":"104743","dateCreated":"1571280642","dateModified":"1571280642"},{"type":"update","diffId":"16716","author":"indygreg","id":"101596","dateCreated":"1569902241","dateModified":"1569902241"},{"type":"update","diffId":"16697","author":"indygreg","id":"101493","dateCreated":"1569814272","dateModified":"1569814272"},{"type":"update","diffId":"16695","author":"indygreg","id":"101482","dateCreated":"1569787039","dateModified":"1569787039"},{"type":"update","diffId":"16682","author":"indygreg","id":"101395","dateCreated":"1569784074","dateModified":"1569784074"},{"type":"update","diffId":"16678","author":"indygreg","id":"101379","dateCreated":"1569775804","dateModified":"1569775804"},{"type":"update","diffId":"16677","author":"indygreg","id":"101376","dateCreated":"1569731073","dateModified":"1569731073"},{"type":"update","diffId":"16675","author":"indygreg","id":"101365","dateCreated":"1569729041","dateModified":"1569729041"}],"dateCreated":"1569729041","dateModified":"1571280642","status":"Changes Planned"},{"id":"7106","callsign":"HG","title":"fuzz: restrict dirs fuzzer to only 40k of input","author":"durin42","summary":"Experimentally one very long path of this size shouldn't blow the RAM\nbudget in the fuzzer environment, and it's not really exciting to\ndiscover that building the dirs dict for one stupidly long path uses a\nton of RAM.","testPlan":"","lineCount":"7","dependsOn":[],"reviewers":[],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"comment","comment":"The concern is basically that the fuzzer will figure out something dumb, like `'a\/' * 40000 + 'b'` which consumes around a gig of memory. I don't think this is a serious OOM vector, since any such manifest would also be inordinately large?\n\nMaybe I'm being an optimist.","author":"durin42","id":"104320","dateCreated":"1571199399","dateModified":"1571199399"},{"type":"comment","comment":"If we blow stupid amounts of memory in the `dirs` internals, perhaps we should be enforcing a length limit in the implementation instead of burying our head in the sand by not triggering it via fuzzing.\n\nIf we need to teach the fuzzer to only send small input so we don't trigger exceptions, fine. But if this is an OOM vector, I'd like to fix it. What do you think?","author":"indygreg","id":"104296","dateCreated":"1571190901","dateModified":"1571190901"},{"type":"update","diffId":"17174","author":"durin42","id":"104215","dateCreated":"1571147881","dateModified":"1571147881"}],"dateCreated":"1571147881","dateModified":"1571199400","status":"Needs Review"},{"id":"7026","callsign":"HG","title":"treemanifest: move out of experimental","author":"pulkit","summary":"In recent sprint, we discussed that treemanifest should be moved out of\nexperimental. The feature has been used inside Google, Facebook in some forms\nand was used inside Yandex too for narrow clones.\n\nThere is an issue with diffing of large treemanifests and to fix that some\nPython code needs to be rewritted in C\/Rust. This I think is not a blocker for\ntaking treemanifest out of experimental.\n\nThis patch renames config `experimental.treemanifest` to `storage.treemanifest`.","testPlan":"","lineCount":"59","dependsOn":[],"reviewers":["durin42"],"ccs":["marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":"That sounds fine","author":"durin42","id":"104286","dateCreated":"1571179604","dateModified":"1571179604"},{"type":"comment","comment":"the storage session is more about small configuration of the storage \nsystem without impact on the repository. The `format` section is more \nappropriate for things that deeply impact the repository format.\n\nSo this should probably at least lives in the `format` as \n`format.use-tree-manifest`.\n\nHowever, this is also the first \"scheme\" change we get. repository using \ntree-manifest will never be able to push to a repository not using it. \nThat make `tree-manifest` different from anything that live in the \n`format` section right now.\n\nSo maybe: `format.manifest-scheme=tree-manifest` ?","author":"marmoute","id":"103128","dateCreated":"1570594672","dateModified":"1570594672"},{"type":"update","diffId":"16976","author":"pulkit","id":"103083","dateCreated":"1570568597","dateModified":"1570568597"}],"dateCreated":"1570568597","dateModified":"1571179604","status":"Needs Review"},{"id":"6987","callsign":"HG","title":"debugstrip: add debugstrip to core","author":"navaneeth.suresh","summary":"Until now, `strip` was bootstrapped as an extension. This patch adds\n`debugstrip` on core. For the users who are still used to `strip`\nextension, we will preserve that name.","testPlan":"","lineCount":"362","dependsOn":[],"reviewers":["durin42"],"ccs":["pulkit","marmoute","mjpieters","mercurial-devel"],"actions":[{"type":"update","diffId":"17120","author":"navaneeth.suresh","id":"103852","dateCreated":"1570917594","dateModified":"1570917594"},{"type":"inline","comment":"the documentation should be left as it is.","replyTo":null,"isNewFile":"1","line":"3","lineLength":"0","path":"hgext\/strip.py","diffId":"16914","author":"pulkit","id":"103145","dateCreated":"1570629357","dateModified":"1570629357"},{"type":"inline","comment":"What is going on here? IT seems like the same code with a different formatting.","replyTo":null,"isNewFile":"1","line":"24","lineLength":"10","path":"hgext\/strip.py","diffId":"16914","author":"marmoute","id":"102942","dateCreated":"1570496789","dateModified":"1570496789"},{"type":"inline","comment":"Why do we need that much code to remain into `hgext\/strip.py`. What I would expect to see is a very small file that only register debugstrip as `strip`.","replyTo":null,"isNewFile":"1","line":"1","lineLength":"46","path":"hgext\/strip.py","diffId":"16914","author":"marmoute","id":"102941","dateCreated":"1570496789","dateModified":"1570496789"},{"type":"comment","comment":"@durin42 Done,","author":"navaneeth.suresh","id":"102681","dateCreated":"1570384371","dateModified":"1570384371"},{"type":"update","diffId":"16914","author":"navaneeth.suresh","id":"102677","dateCreated":"1570384085","dateModified":"1570384085"},{"type":"inline","comment":"One or two is fine, you can leave the majority on the legacy extension flavor. We want some using each so we don't have to add a new test to test one of them.","replyTo":"102399","isNewFile":"1","line":"5646","lineLength":"0","path":"mercurial\/commands.py","diffId":"16856","author":"durin42","id":"102414","dateCreated":"1570309334","dateModified":"1570309334"},{"type":"inline","comment":"i see. do i need to replace `strip` by `debugstrip` on every occurrence in tests? otherwise, i would have to revert the changes in the tests and keep the extension as it is.","replyTo":"102397","isNewFile":"1","line":"5646","lineLength":"0","path":"mercurial\/commands.py","diffId":"16856","author":"navaneeth.suresh","id":"102399","dateCreated":"1570306240","dateModified":"1570306240"},{"type":"inline","comment":"debugstrip please (and put it in debugcommands)\n\nand Gregory points out we need a strip extension that preserves the old `strip` name for users that are used to that","replyTo":null,"isNewFile":"1","line":"5646","lineLength":"0","path":"mercurial\/commands.py","diffId":"16856","author":"durin42","id":"102397","dateCreated":"1570305353","dateModified":"1570305353"},{"type":"reject","author":"durin42","id":"102396","dateCreated":"1570305353","dateModified":"1570305353"},{"type":"update","diffId":"16856","author":"navaneeth.suresh","id":"102389","dateCreated":"1570304463","dateModified":"1570304463"}],"dateCreated":"1570304463","dateModified":"1570917594","status":"Needs Review"},{"id":"6659","callsign":"HG","title":"graft: split graft code into seperate functions","author":"taapas1128","summary":"This patch splits the code into of `commands.graft()` into `cmdutil.finishgraft()`\nwhich deals with the execution of graft once `revs` are generated and `cmdutil.continuegraftstate()` which updates opts from `graftstate` file\nwhen graft is continued from an interrupted state.","testPlan":"","lineCount":"164","dependsOn":[],"reviewers":["durin42"],"ccs":["pulkit","durin42","martinvonz","mercurial-devel"],"actions":[{"type":"inline","comment":"I meant near line 3477 on this side.","replyTo":"98466","isNewFile":"1","line":"3431","lineLength":"0","path":"mercurial\/cmdutil.py","diffId":"16120","author":"pulkit","id":"103414","dateCreated":"1570725840","dateModified":"1570725840"},{"type":"comment","comment":"Turned out I have an unsubmitted comment. Also, the codebase was recently formatted, so these patches will need to be rebased. https:\/\/www.mercurial-scm.org\/pipermail\/mercurial-devel\/2019-October\/134537.html should help","author":"pulkit","id":"103413","dateCreated":"1570725840","dateModified":"1570725840"},{"type":"comment","comment":"@durin42 done.","author":"taapas1128","id":"101982","dateCreated":"1570189477","dateModified":"1570189477"},{"type":"update","diffId":"16791","author":"taapas1128","id":"101978","dateCreated":"1570189414","dateModified":"1570189414"},{"type":"inline","comment":"This function is still mutating the opts parameter. You could fix that by doing opts=dict(opts) on the first line if you want, or otherwise making a copy.","replyTo":null,"isNewFile":"1","line":"3497","lineLength":"0","path":"mercurial\/cmdutil.py","diffId":"16155","author":"durin42","id":"100394","dateCreated":"1568215633","dateModified":"1568215633"},{"type":"reject","author":"durin42","id":"100393","dateCreated":"1568215633","dateModified":"1568215633"},{"type":"inline","comment":"I havent removed `opts` from argument yet.","replyTo":"98467","isNewFile":"1","line":"3495","lineLength":"0","path":"mercurial\/cmdutil.py","diffId":"16120","author":"taapas1128","id":"98491","dateCreated":"1565281319","dateModified":"1565281319"},{"type":"update","diffId":"16155","author":"taapas1128","id":"98480","dateCreated":"1565280643","dateModified":"1565280643"},{"type":"inline","comment":"the function name is not correct with respect to what it does, maybe something like `getopts` or something. Also, we no longer update the `opts`, so we can drop that as argument and also need to update the function description.","replyTo":null,"isNewFile":"1","line":"3495","lineLength":"0","path":"mercurial\/cmdutil.py","diffId":"16120","author":"pulkit","id":"98467","dateCreated":"1565215755","dateModified":"1565215755"},{"type":"inline","comment":"let's initialize `graftstate` only where we need it.","replyTo":null,"isNewFile":"1","line":"3431","lineLength":"0","path":"mercurial\/cmdutil.py","diffId":"16120","author":"pulkit","id":"98466","dateCreated":"1565215755","dateModified":"1565215755"},{"type":"comment","comment":"@martinvonz @durin42 Have a look I ve updated the patch.","author":"taapas1128","id":"98259","dateCreated":"1564920985","dateModified":"1564920985"},{"type":"update","diffId":"16120","author":"taapas1128","id":"98255","dateCreated":"1564920829","dateModified":"1564920829"},{"type":"comment","comment":"I agree with Martin's request for changes here.","author":"durin42","id":"98139","dateCreated":"1564684592","dateModified":"1564684592"},{"type":"reject","author":"durin42","id":"98138","dateCreated":"1564684592","dateModified":"1564684592"},{"type":"inline","comment":"I think we generally avoid having functions mutate inputs and instead make them return the new value. The usual reason for mutating instead is for speed, but that should not be an issue here. The side-effect is especially non-obvious (when looking at call site) since the function has a return value (if it had not had one, the reader would probably assume there must be some side-effect).","replyTo":null,"isNewFile":"1","line":"3495","lineLength":"13","path":"mercurial\/cmdutil.py","diffId":"15987","author":"martinvonz","id":"98125","dateCreated":"1564681341","dateModified":"1564681341"},{"type":"comment","comment":"I just found a comment I wrote a while ago and forgot to submit. Sorry.","author":"martinvonz","id":"98124","dateCreated":"1564681341","dateModified":"1564681341"},{"type":"update","diffId":"15987","author":"taapas1128","id":"97536","dateCreated":"1563732299","dateModified":"1563732299"},{"type":"update","diffId":"15978","author":"taapas1128","id":"97495","dateCreated":"1563631467","dateModified":"1563631467"},{"type":"update","diffId":"15973","author":"taapas1128","id":"97449","dateCreated":"1563481207","dateModified":"1563481207"}],"dateCreated":"1563481207","dateModified":"1570725840","status":"Needs Review"},{"id":"7025","callsign":"HG","title":"rewriteutil: add configurable check to disallow obsoleting someone else cset","author":"pulkit","summary":"One of the things about obsolete markers (especially prune markers) is that\nsharing them can lead to cases where you loose your data. The best example is\nthat someone else prune your changeset and you pull from them and your commit\ndisappears locally.\n\nThere are two parts of solving the above mentioned problem:\n\n1) disallow obsoleting changesets which are not authored by you unless some\nconfig or force is passed\n2) notifying the end user and creating a journal of obsolete markers which the\nuser recieves on their cset from someone else\n\nThis patch tries to tackle the first one.","testPlan":"","lineCount":"11","dependsOn":[],"reviewers":[],"ccs":["marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":"This should probably be controled by a config option instead of a keyword argument to this function (we want the control of this to be unified)\n\nI would prefer a prompt than an abort.\n\nWe talked about the pre-checking topic with Sushil on Sunday. The result of the discussion is synthetised in this plan page: https:\/\/www.mercurial-scm.org\/wiki\/CEDPrecheckPlan ","author":"marmoute","id":"103169","dateCreated":"1570636646","dateModified":"1570636646"},{"type":"update","diffId":"16971","author":"pulkit","id":"103045","dateCreated":"1570562721","dateModified":"1570562721"}],"dateCreated":"1570562721","dateModified":"1570636647","status":"Needs Review"},{"id":"6876","callsign":"HG","title":"phabricator: support automatically obsoleting old revisions of pulled commits","author":"mharbison72","summary":"This is basically an import of the `pullcreatemarkers` extension[1] from the FB\nrepo, with minor adjustments to `getmatchingdiff()` to work with modern hg.\nSince this is very phabricator specific, it makes more sense to me to bundle it\ninto the existing extension.  It wasn't very obvious from the old name what\nfunctionality was provided, and it may make sense to do this in other scenarios\nbesides `hg pull`.\n\nThere are two use cases that I can see- first, ensuring that old revisions are\ncleaned up for a contributor (I seem to recall something I submitted recently\nneeded to be explicitly pruned, though most submissions do clean up\nautomatically).  Second, any `hg phabread | hg import -` would otherwise need to\nbe manually cleaned up.  The latter is annoying enough that I tend not to grab\nthe code and try it when reviewing.\n\nIt is currently guarded by a config option (off by default), because @marmoute\nexpressed concerns about duplicate marker creation if the pushing reviewer also\ncreates a marker.  I don't think that's possible here, since the obsolete\nrevisions are explicitly excluded.  But maybe there are other reasons someone\nwouldn't want older revisions obsoleted.  The config name reflects the fact that\nI'm not sure if other things like import should get this too.\n\nI suspect that we could wrap a function deeper in the pull sequence to improve\nboth the code and the UX.  For example, when pulling an obsolete marker, it can\nprint out a warning that the working directory parent is obsolete, but that\ndoesn't happen here.  (It won't happen with this test.  It *should* without the\n`--bypass` option, but doesn't.)  It should also be possible to not have to\nquery the range of new revisions, and maybe it can be added to the existing\ntransaction.\n\n[1] https:\/\/bitbucket.org\/facebook\/hg-experimental\/src\/default\/hgext3rd\/pullcreatemarkers.py","testPlan":"","lineCount":"69","dependsOn":[],"reviewers":[],"ccs":["pulkit","sheehan","Kwan","mercurial-devel","marmoute"],"actions":[{"type":"inline","comment":"Right, and this is probably the typical case. (The `phabimport` alias I have imports as secret to prevent accidental push.)  But secret is visible to the user, and benefits from the cleanup.  Archived isn\u2019t visible (IIUC), so it probably doesn\u2019t need to be obsoleted too- especially if we\u2019re worried about marker growth.\n\n(I\u2019m also not sure how well thg handles archived, and that probably needs to be squared away first if we opt to archive instead of obsolete here.)","replyTo":"102970","isNewFile":"1","line":"216","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"mharbison72","id":"102982","dateCreated":"1570536765","dateModified":"1570536765"},{"type":"inline","comment":"I see. So maybe this should only obsolete things that have no precursors, and warn (and ignore) things that do.  That means it doesn\u2019t clean up if the reviewer accidentally forgets to import with `\u2014obsolete`, but that\u2019s easy enough to fix with a copy\/paste command if A and A' are identified in the output.","replyTo":"102971","isNewFile":"1","line":"187","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"mharbison72","id":"102981","dateCreated":"1570536765","dateModified":"1570536765"},{"type":"inline","comment":"User  A phasend a patch\n\n  - User A phasend a changeset `A` as D1337\n  - User B phabimport D1337, rebase (as `A'`) and pushes\n  - User A fix critical bug in D1337 and amend it as `A''`\n  - User A pull the **old** version of D1337 without the fix.\n\nIf we obsolete the **new** version of D1337 (`A''`), we are silently dropping the fix to the critical bug.\n\nIf markers were properly exchange, the evolution machinery would detect the divergence, warn the user and be able to automatically solve it. Preserving the fix to the criticial bug.\n\n","replyTo":"102947","isNewFile":"1","line":"187","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102971","dateCreated":"1570529823","dateModified":"1570529823"},{"type":"inline","comment":"Thing could be in `secret` phase too.","replyTo":"102944","isNewFile":"1","line":"216","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102970","dateCreated":"1570529823","dateModified":"1570529823"},{"type":"inline","comment":"I do mean **after** locking (sorry)","replyTo":"102945","isNewFile":"1","line":"225","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102969","dateCreated":"1570529823","dateModified":"1570529823"},{"type":"inline","comment":"It looks like, based on the loop where it's used, it will obsolete \/\/all\/\/ (non public) commits that match.  The only way I can think of where that happens is if I `phabimport` someone else's patches, they make updates, and then I `phabimport` again.  That's why I was wondering aloud about doing this on import, but if the eventual pull cleans it all up, that may be sufficient for the use case I had in mind.  I don't see how a developer would do that on their own commits with amend and friends.\n\nDo you have any ideas to detect phase divergence?  And can that even happen if we're ignoring public commits?","replyTo":"102927","isNewFile":"1","line":"187","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"mharbison72","id":"102947","dateCreated":"1570508435","dateModified":"1570508435"},{"type":"inline","comment":"I wonder if it would be better in some txn hook.  And then it could (I think) share the existing transaction and lock.","replyTo":"102929","isNewFile":"1","line":"192","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"mharbison72","id":"102946","dateCreated":"1570508435","dateModified":"1570508435"},{"type":"inline","comment":"You mean \/\/after\/\/ locking, correct?","replyTo":"102928","isNewFile":"1","line":"225","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"mharbison72","id":"102945","dateCreated":"1570508435","dateModified":"1570508435"},{"type":"inline","comment":"Agreed.\n\nI saw mention of the archived phase the other day; how would that (and other special phases) play here?","replyTo":"102926","isNewFile":"1","line":"216","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"mharbison72","id":"102944","dateCreated":"1570508435","dateModified":"1570508435"},{"type":"comment","comment":">>! In D6876#102925, @marmoute wrote:\n> The feature seens pretty usful, but is also a potential foot-gun\/data-loss engine. I think it is useful to take the feature, but maybe with proper documentaiton warning and turned of by efaut. I made a couple of comment about the implementation.\n\nI basically agree with the inline comments.  This was an import with minimal changes as a baseline, and I didn't want to spend time making a bunch of follow ups until I gauged interest in this.\n\nAlternately, if there's concern over obsolete marker growth, should this use the archived phase instead?  Since the use case is mostly around stuff a developer imports locally, I don't see much value in those markers being exchangeable.  The only potential hole I see is if someone has pushed this to a non publishing repo before pulling.  Then everyone else could pull the (not obsoleted) commit.  But then \/\/they\/\/ would archive it on pull too, instead of N developers potentially creating N markers for the same commit.","author":"mharbison72","id":"102943","dateCreated":"1570508435","dateModified":"1570508435"},{"type":"inline","comment":"It would probably make sense to wrap the pull exchange logic instead. It would catch more instance and could reuse the same transaction.","replyTo":null,"isNewFile":"1","line":"192","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102929","dateCreated":"1570495381","dateModified":"1570495381"},{"type":"inline","comment":"We should do the computation before locking to avoid other process updating the repo under our feet.","replyTo":null,"isNewFile":"1","line":"225","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102928","dateCreated":"1570495381","dateModified":"1570495381"},{"type":"inline","comment":"So, this only checks the diff number, right ? So in theory, we could obsolete a later version of this, silently dropping change (instead of detecting potential phase-divergence)","replyTo":null,"isNewFile":"1","line":"187","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102927","dateCreated":"1570495381","dateModified":"1570495381"},{"type":"inline","comment":"This should be `non public()` instead of `draft()` these could be draft.","replyTo":null,"isNewFile":"1","line":"216","lineLength":"0","path":"hgext\/phabricator.py","diffId":"16604","author":"marmoute","id":"102926","dateCreated":"1570495381","dateModified":"1570495381"},{"type":"comment","comment":"The feature seens pretty usful, but is also a potential foot-gun\/data-loss engine. I think it is useful to take the feature, but maybe with proper documentaiton warning and turned of by efaut. I made a couple of comment about the implementation.","author":"marmoute","id":"102925","dateCreated":"1570495381","dateModified":"1570495381"},{"type":"comment","comment":"@sheehan this might be of interest to you.","author":"pulkit","id":"102116","dateCreated":"1570282533","dateModified":"1570282533"},{"type":"update","diffId":"16604","author":"mharbison72","id":"100947","dateCreated":"1569388644","dateModified":"1569388644"}],"dateCreated":"1569388644","dateModified":"1570536765","status":"Needs Review"},{"id":"5064","callsign":"HG","title":"style: run black on a subset of mercurial","author":"mjpieters","summary":"This applied black to the 20 smallest files in mercurial\/:\n\n    ls -S1 mercurial\/*.py | tail -n20 | xargs black","testPlan":"","lineCount":"597","dependsOn":[],"reviewers":["indygreg","durin42"],"ccs":["mharbison72","av6","mercurial-devel"],"actions":[{"type":"comment","comment":"Per mailing list thread, I've sent out https:\/\/phab.mercurial-scm.org\/D5539 to show what yapf would want to do.","author":"durin42","id":"81884","dateCreated":"1547065835","dateModified":"1547065835"},{"type":"comment","comment":">>! In D5064#78994, @mharbison72 wrote:\n>>>! In D5064#78990, @durin42 wrote:\n>> \n>> Does anyone strongly object, or do we want to embrace black and the formatting changes it implies?\n> \n> Is there a fix extension configuration (and I guess precommit hook- I've never used it) for this?  If so, maybe it should go on the ContributingChanges page.\n\nMy plan was to put an `hg fix` configuration in contrib and mention it in ContributingChanges. I'd advise against a hook for this, but if someone else wanted to write one I'd at least drop it in contrib as an example...","author":"durin42","id":"79401","dateCreated":"1543527970","dateModified":"1543527970"},{"type":"comment","comment":">>! In D5064#78990, @durin42 wrote:\n> \n> Does anyone strongly object, or do we want to embrace black and the formatting changes it implies?\n\nIs there a fix extension configuration (and I guess precommit hook- I've never used it) for this?  If so, maybe it should go on the ContributingChanges page.","author":"mharbison72","id":"78995","dateCreated":"1543343465","dateModified":"1543343465"},{"type":"comment","comment":">>! In D5064#78780, @mjpieters wrote:\n>>>! In D5064#78545, @av6 wrote:\n>> I look at the changes and see nitpicks at best. On the one hand, black proved better than any linter that we can already write consistent code. On the other, if black were a linter... I'd switch to flake8, which at least is [[ https:\/\/www.mercurial-scm.org\/repo\/evolve\/file\/tip\/setup.cfg#l1 | configurable ]].\n> \n> The whole **point** of black is that it is not configurable. Configurable means you still have to argue about style and decide on a configuration.\n\nYep. I find I care less about style decisions when the computer is able to make them for me: eg I prefer ' to \", but since black can fix that and I don't have to type the \" myself, I don't really care.\n\nDoes anyone strongly object, or do we want to embrace black and the formatting changes it implies?","author":"durin42","id":"78990","dateCreated":"1543333753","dateModified":"1543333753"},{"type":"comment","comment":">>! In D5064#78545, @av6 wrote:\n> I look at the changes and see nitpicks at best. On the one hand, black proved better than any linter that we can already write consistent code. On the other, if black were a linter... I'd switch to flake8, which at least is [[ https:\/\/www.mercurial-scm.org\/repo\/evolve\/file\/tip\/setup.cfg#l1 | configurable ]].\n\nThe whole **point** of black is that it is not configurable. Configurable means you still have to argue about style and decide on a configuration.","author":"mjpieters","id":"78780","dateCreated":"1542721643","dateModified":"1542721643"},{"type":"comment","comment":"I look at the changes and see nitpicks at best. On the one hand, black proved better than any linter that we can already write consistent code. On the other, if black were a linter... I'd switch to flake8, which at least is [[ https:\/\/www.mercurial-scm.org\/repo\/evolve\/file\/tip\/setup.cfg#l1 | configurable ]].","author":"av6","id":"78546","dateCreated":"1542177684","dateModified":"1542177684"},{"type":"inline","comment":"I'm surprised by this result. I'd like to think the reformatting tool would be smarter than this.","replyTo":null,"isNewFile":"1","line":"18","lineLength":"0","path":"mercurial\/mergeutil.py","diffId":"12135","author":"indygreg","id":"78536","dateCreated":"1542158446","dateModified":"1542158446"},{"type":"comment","comment":"Where do we stand on the intent to mass reformat the code base?\n\nI'm not super thrilled at some of black's decisions (like using double quotes for all strings and merging imports into the same line which leads to excessive code churn later). But the exact style doesn't matter as much as having it be consistent. So I'm willing to go with black if we feel it's the best tool for the job. I'm not sure what the alternatives are these days.","author":"indygreg","id":"78535","dateCreated":"1542158446","dateModified":"1542158446"},{"type":"update","diffId":"12135","author":"mjpieters","id":"76341","dateCreated":"1539524510","dateModified":"1539524510"},{"type":"inline","comment":"I think we'll want to send this chunk as a separate commit, as it is a policy change. I'd be happy to accept that patch today.","replyTo":null,"isNewFile":"0","line":"43","lineLength":"0","path":"contrib\/check-commit","diffId":"12059","author":"indygreg","id":"76072","dateCreated":"1539436980","dateModified":"1539436980"},{"type":"update","diffId":"12059","author":"mjpieters","id":"75974","dateCreated":"1539434351","dateModified":"1539434351"},{"type":"update","diffId":"12047","author":"mjpieters","id":"75925","dateCreated":"1539431766","dateModified":"1539431766"},{"type":"comment","comment":"The `import` parentheses collapsing is described here: https:\/\/github.com\/ambv\/black#parentheses. The behavior is not configurable.\n\n","author":"mjpieters","id":"75836","dateCreated":"1539425573","dateModified":"1539425573"},{"type":"update","diffId":"12030","author":"mjpieters","id":"75830","dateCreated":"1539425250","dateModified":"1539425250"}],"dateCreated":"1539425250","dateModified":"1570377937","status":"Needs Review"},{"id":"6738","callsign":"HG","title":"unshelve: add --unresolved flag to unshelve mergestate with unresolved files","author":"navaneeth.suresh","summary":"`hg unshelve --unresolved` will get the user back to the old unresolved merge by\nthe following steps:\n\nStep 1: If the user has committed new changesets after shelving the changes,\nthey must update the working directory to one of the merge parents.\n\nStep 2: Change parents of dirstate to `p1` and `p2`.\n\nStep 3: In order to restore our partially resolved state, we will write from\ndata stored in changeset extras.\n\nStep 4: We now have a state in which files marked as resolved might have\nconflicts. But, we will apply the changes in shelve on the top of this so that we\ncan get our old unresolved merge again by the usual unshelve mechanism.\n\nThe usual rebase step is avoided on unresolved shelve changesets.\n\n`$ hg unshelve --unresolved` will abort when:\n\n1. The working directory is dirty.\n2. If there is an ongoing merge.\n3. If the working directory is not at either p1 or p2.\n\n(`p1`, `p2` are the parents of the unresolved shelve changeset)","testPlan":"","lineCount":"352","dependsOn":["6737"],"reviewers":[],"ccs":["pulkit","mercurial-devel"],"actions":[{"type":"update","diffId":"16815","author":"navaneeth.suresh","id":"102122","dateCreated":"1570283700","dateModified":"1570283700"},{"type":"inline","comment":"Yes. This was because we are not storing the local version of the files. So, it will be `None` as returned while reading the mergestate. So, it should throw an `AssertionError`. We can get rid of this only when we store the local versions of the files in future.","replyTo":"100438","isNewFile":"1","line":"754","lineLength":"0","path":"mercurial\/shelve.py","diffId":"16254","author":"navaneeth.suresh","id":"102090","dateCreated":"1570222380","dateModified":"1570222380"},{"type":"update","diffId":"16808","author":"navaneeth.suresh","id":"102072","dateCreated":"1570221980","dateModified":"1570221980"},{"type":"inline","comment":"Did you manage to find why that error comes up?","replyTo":"99223","isNewFile":"1","line":"754","lineLength":"0","path":"mercurial\/shelve.py","diffId":"16254","author":"pulkit","id":"100438","dateCreated":"1568267240","dateModified":"1568267240"},{"type":"inline","comment":"Then we are somehow parsing or building the records in not correct way.","replyTo":"98993","isNewFile":"1","line":"754","lineLength":"0","path":"mercurial\/shelve.py","diffId":"16254","author":"pulkit","id":"99223","dateCreated":"1566743141","dateModified":"1566743141"},{"type":"inline","comment":"i had tried to support it earlier. but, it throws the following error. i think it's okay to use the latest format only since, we haven't stored any mergestate using the previous format. the repo won't get corrupted.\n\n```\n+  Traceback (most recent call last):\n+    File \"\/tmp\/hgtests.TEheee\/install\/bin\/hg\", line 43, in <module>\n+      dispatch.run()\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/dispatch.py\", line 99, in run\n+      status = dispatch(req)\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/dispatch.py\", line 225, in dispatch\n+      ret = _runcatch(req) or 0\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/dispatch.py\", line 376, in _runcatch\n+      return _callcatch(ui, _runcatchfunc)\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/dispatch.py\", line 384, in _callcatch\n+      return scmutil.callcatch(ui, func)\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/scmutil.py\", line 167, in callcatch\n+      return func()\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/dispatch.py\", line 367, in _runcatchfunc\n+      return _dispatch(req)\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/dispatch.py\", line 1021, in _dispatch\n+      cmdpats, cmdoptions)\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/dispatch.py\", line 756, in runcommand\n+      ret = _runcommand(ui, options, cmd, d)\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/dispatch.py\", line 1030, in _runcommand\n+      return cmdfunc()\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/dispatch.py\", line 1018, in <lambda>\n+      d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/util.py\", line 1682, in check\n+      return func(*args, **kwargs)\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/commands.py\", line 6229, in unshelve\n+      return shelvemod.dounshelve(ui, repo, *shelved, **opts)\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/shelve.py\", line 1090, in dounshelve\n+      restoreunresolvedshelve(ui, repo, shelvectx, basename)\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/shelve.py\", line 754, in restoreunresolvedshelve\n+      ms._writerecords(_decodemergerecords(records))\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/merge.py\", line 452, in _writerecords\n+      self._writerecordsv1(records)\n+    File \"\/tmp\/hgtests.TEheee\/install\/lib\/python\/mercurial\/merge.py\", line 460, in _writerecordsv1\n+      assert lrecords[0] == RECORD_LOCAL\n+  AssertionError\n+  [1]\n```","replyTo":"98953","isNewFile":"1","line":"754","lineLength":"0","path":"mercurial\/shelve.py","diffId":"16254","author":"navaneeth.suresh","id":"98993","dateCreated":"1566307227","dateModified":"1566307227"},{"type":"inline","comment":"we should write both the versions, `_writerecords()` should be used.","replyTo":null,"isNewFile":"1","line":"754","lineLength":"0","path":"mercurial\/shelve.py","diffId":"16254","author":"pulkit","id":"98953","dateCreated":"1566227441","dateModified":"1566227441"},{"type":"update","diffId":"16254","author":"navaneeth.suresh","id":"98891","dateCreated":"1566074352","dateModified":"1566074352"}],"dateCreated":"1566074352","dateModified":"1570283700","status":"Needs Review"},{"id":"6737","callsign":"HG","title":"shelve: add --unresolved flag to shelve mergestate with unresolved files","author":"navaneeth.suresh","summary":"Until now, `shelve` used to abort on trying to `shelve` a mergestate.\nThis patch adds an `--unresolved` flag to `shelve` and use the changeset\nextras to store the mergestate.\n\nAfter shelving, and the working directory is updated to `p1()`.\n\n`hg shelve` will abort when:\n\n1. No merge is active on calling with `--unresolved`.\n2. No unresolved files found in active merge on calling with `--unresolved`.\n3. Merge is active on calling without `--unresolved`.","testPlan":"","lineCount":"198","dependsOn":["6966"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"16814","author":"navaneeth.suresh","id":"102121","dateCreated":"1570283658","dateModified":"1570283658"},{"type":"update","diffId":"16807","author":"navaneeth.suresh","id":"102071","dateCreated":"1570221958","dateModified":"1570221958"},{"type":"update","diffId":"16253","author":"navaneeth.suresh","id":"98885","dateCreated":"1566074328","dateModified":"1566074328"}],"dateCreated":"1566074328","dateModified":"1570283658","status":"Needs Review"},{"id":"6966","callsign":"HG","title":"shelve: add method for storing mergestate in changeset extras","author":"navaneeth.suresh","summary":"We store mergestate records in `.hg\/merge`. This patch adds a method\nof storage in changeset extras. This will help in the exchange of\nmergestate records to other repos. Also, this can be used by\n`shelve --unresolved` to store the mergestate records.\n\nIt uses the storage format supported for hg versions 3.7 or later. For the\ntime being, I have omitted the storage of the content of the local version","testPlan":"","lineCount":"25","dependsOn":[],"reviewers":[],"ccs":["martinvonz","mercurial-devel"],"actions":[{"type":"update","diffId":"16813","author":"navaneeth.suresh","id":"102118","dateCreated":"1570283559","dateModified":"1570283559"},{"type":"inline","comment":"`''.join(a,b)` can be written more simply as `a + b`","replyTo":null,"isNewFile":"1","line":"476","lineLength":"0","path":"mercurial\/shelve.py","diffId":"16806","author":"martinvonz","id":"102113","dateCreated":"1570248876","dateModified":"1570248876"},{"type":"inline","comment":"This seems surprising in this method. Consider moving it out.","replyTo":null,"isNewFile":"1","line":"478","lineLength":"0","path":"mercurial\/shelve.py","diffId":"16806","author":"martinvonz","id":"102112","dateCreated":"1570248876","dateModified":"1570248876"},{"type":"inline","comment":"need a `r''` prefix here for py3?","replyTo":null,"isNewFile":"1","line":"475","lineLength":"0","path":"mercurial\/shelve.py","diffId":"16806","author":"martinvonz","id":"102111","dateCreated":"1570248876","dateModified":"1570248876"},{"type":"inline","comment":"Most of these seem unused. I would prefer if they were added in a later patch where they are used","replyTo":null,"isNewFile":"1","line":"73","lineLength":"39","path":"mercurial\/shelve.py","diffId":"16806","author":"martinvonz","id":"102110","dateCreated":"1570248876","dateModified":"1570248876"},{"type":"inline","comment":"Seems unused","replyTo":null,"isNewFile":"1","line":"61","lineLength":"0","path":"mercurial\/shelve.py","diffId":"16806","author":"martinvonz","id":"102109","dateCreated":"1570248876","dateModified":"1570248876"},{"type":"update","diffId":"16806","author":"navaneeth.suresh","id":"102066","dateCreated":"1570221844","dateModified":"1570221844"}],"dateCreated":"1570221844","dateModified":"1570283608","status":"Needs Review"},{"id":"6958","callsign":"HG","title":"hg: move hg script to be a template that gets filled in via make","author":"durin42","summary":"Right now this is only handling the interpreter path, but we could do\nmore. I tried to add the hg rule as a dependency of everything that\nmight need it to work, but I didn't test all the packaging rules.","testPlan":"","lineCount":"26","dependsOn":[],"reviewers":["indygreg"],"ccs":["mharbison72","indygreg","mercurial-devel"],"actions":[{"type":"inline","comment":"Any sane way to get this to strip $(DESTDIR) from the lead?  (Or maybe just override it via another parameter.)  That would solve one of the issues with the custom Mac install builder (D6846), but probably causes a problem running `contrib\/genosxversion.py` (which wants to exec `hg`).","replyTo":null,"isNewFile":"1","line":"50","lineLength":"0","path":"Makefile","diffId":"16794","author":"mharbison72","id":"102055","dateCreated":"1570217362","dateModified":"1570217362"},{"type":"comment","comment":"Changes are coming.","author":"indygreg","id":"102001","dateCreated":"1570204190","dateModified":"1570204190"},{"type":"reject","author":"indygreg","id":"102000","dateCreated":"1570204190","dateModified":"1570204190"},{"type":"update","diffId":"16794","author":"durin42","id":"101994","dateCreated":"1570202914","dateModified":"1570202914"}],"dateCreated":"1570202914","dateModified":"1570217362","status":"Needs Revision"},{"id":"6709","callsign":"HG","title":"config: add --registered flag to show all known configs","author":"navaneeth.suresh","summary":"This patch fixes one of the issues in `issue6014`. This adds a\n`--registered` flag to `hg showconfig` to show all known config\noptions.\n\nI will be sending a series of patches following this to adding defaults\nand experimental\/devel\/debug statuses, displaying the outputs in a\nuser-friendly format, etc.","testPlan":"","lineCount":"781","dependsOn":[],"reviewers":["av6","marmoute","durin42"],"ccs":["durin42","mharbison72","yuja","pulkit","marmoute","av6","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":"Now I understand that this patch does an enormous number of changes. I've split this patch into three. Will be working on each of them separately from now on.","author":"navaneeth.suresh","id":"102052","dateCreated":"1570217161","dateModified":"1570217161"},{"type":"update","diffId":"16800","author":"navaneeth.suresh","id":"102029","dateCreated":"1570210766","dateModified":"1570210766"},{"type":"comment","comment":">>! In D6709#100698, @av6 wrote:\n> \n> And to make the review process easier, I propose doing this in 3 or 4 patches:\n> \n> - adding `--registered`: will simply show all registered options in key=value format\n> - adding defaults and experimental\/devel\/debug statuses to `showconfig --debug` output (this one can be split into two)\n> - showing config options in a human-friendly format\n\n+1. I also agree that splitting it into patches will help ease the discussion and review.\n\n","author":"pulkit","id":"100702","dateCreated":"1568721257","dateModified":"1568721257"},{"type":"comment","comment":">>! In D6709#100698, @av6 wrote:\n>>>! In D6709#100618, @marmoute wrote:\n>>>>! In D6709#99199, @av6 wrote:\n>>> I'm strongly -1 on adding qualifiers straight to the keys. The primary usage scenario here is scripts (as explained in issue6014) -- regular users lived without this feature for years and didn't care (enough to file a bug) about getting all config options, or their default values, \/\/or\/\/ the experimental status (they could and still can read it in hg help config). `--registered` is needed for things like shell completions, and the output needs to be clear and parseable (and consistent with what regular showconfig shows).\n>> \n>> I disagree that the primary use is script only. As a suer I have wanted this for a long time and I am happy to finally have a way to get this data without grepping the source.\n> \n> Oh, now I see what you wanted from this patch. But you want it as a developer who works with and on hg, not just as a user (hopefully regular users don't have to grep the source). This distinction makes things easier to design, because we now have simply two (plus one) cases:\n\nI have talked with regular user who also crave for it because their keep wondering what's the exact form of the option their are looking for.\n\n> - `--registered` will simply extend the list of config options to walk from options found somewhere in system\/user\/repo config files to every config option ever registered (excluding experimental\/devel\/debug ones unless `-v` is given\/\/*\/\/)\n> - existing `--debug` mode of showconfig will show the `(EXPERIMENTAL)` and `(default: x)` information in addition to what it shows now and can be used with `--registered` (and registered but unset options can have \"<registered>\" source, similar to the existing \"<tweakdefaults>\" source)\n> - anyone can still use `-T` to access key, value, defaultvalue, source and status in whatever format they want, and `--registered` will work as expected from its name (i.e. just iterating over a different set of config options)\n> \n> \/\/*\/\/ This is still not great, because if you set an experimental config option and run showconfig with no flags, it will be in the output. With `--registered` as it is implemented right now it won't be shown without `-v`. We should either show any options when they are set  regardless of what status they have, or not require `-v` at all.\n> \n> Making one flag do one thing is good UI. That's why I want `--registered` alone to not modify any output of showconfig. Doing only one thing is also easier for help text to explain and for users to understand (even without reading help text, just based on the name of the flag).\n\nThat is an interesting point. I'll have to think about it for a bit.\n\n> \n> And to make the review process easier, I propose doing this in 3 or 4 patches:\n> \n> - adding `--registered`: will simply show all registered options in key=value format\n> - adding defaults and experimental\/devel\/debug statuses to `showconfig --debug` output (this one can be split into two)\n> - showing config options in a human-friendly format\n\n","author":"marmoute","id":"100701","dateCreated":"1568711401","dateModified":"1568711401"},{"type":"comment","comment":">>! In D6709#100618, @marmoute wrote:\n>>>! In D6709#99199, @av6 wrote:\n>> I'm strongly -1 on adding qualifiers straight to the keys. The primary usage scenario here is scripts (as explained in issue6014) -- regular users lived without this feature for years and didn't care (enough to file a bug) about getting all config options, or their default values, \/\/or\/\/ the experimental status (they could and still can read it in hg help config). `--registered` is needed for things like shell completions, and the output needs to be clear and parseable (and consistent with what regular showconfig shows).\n> \n> I disagree that the primary use is script only. As a suer I have wanted this for a long time and I am happy to finally have a way to get this data without grepping the source.\n\nOh, now I see what you wanted from this patch. But you want it as a developer who works with and on hg, not just as a user (hopefully regular users don't have to grep the source). This distinction makes things easier to design, because we now have simply two (plus one) cases:\n\n- `--registered` will simply extend the list of config options to walk from options found somewhere in system\/user\/repo config files to every config option ever registered (excluding experimental\/devel\/debug ones unless `-v` is given\/\/*\/\/)\n- existing `--debug` mode of showconfig will show the `(EXPERIMENTAL)` and `(default: x)` information in addition to what it shows now and can be used with `--registered` (and registered but unset options can have \"<registered>\" source, similar to the existing \"<tweakdefaults>\" source)\n- anyone can still use `-T` to access key, value, defaultvalue, source and status in whatever format they want, and `--registered` will work as expected from its name (i.e. just iterating over a different set of config options)\n\n\/\/*\/\/ This is still not great, because if you set an experimental config option and run showconfig with no flags, it will be in the output. With `--registered` as it is implemented right now it won't be shown without `-v`. We should either show any options when they are set  regardless of what status they have, or not require `-v` at all.\n\nMaking one flag do one thing is good UI. That's why I want `--registered` alone to not modify any output of showconfig. Doing only one thing is also easier for help text to explain and for users to understand (even without reading help text, just based on the name of the flag).\n\nAnd to make the review process easier, I propose doing this in 3 or 4 patches:\n\n- adding `--registered`: will simply show all registered options in key=value format\n- adding defaults and experimental\/devel\/debug statuses to `showconfig --debug` output (this one can be split into two)\n- showing config options in a human-friendly format","author":"av6","id":"100698","dateCreated":"1568710692","dateModified":"1568710692"},{"type":"comment","comment":">>! In D6709#100618, @marmoute wrote:\n> \n>>>! In D6709#99199, @av6 wrote:\n>> I'm strongly -1 on adding qualifiers straight to the keys. The primary usage scenario here is scripts (as explained in issue6014) -- regular users lived without this feature for years and didn't care (enough to file a bug) about getting all config options, or their default values, \/\/or\/\/ the experimental status (they could and still can read it in hg help config). `--registered` is needed for things like shell completions, and the output needs to be clear and parseable (and consistent with what regular showconfig shows).\n> \n> I disagree that the primary use is script only. As a suer I have wanted this for a long time and I am happy to finally have a way to get this data without grepping the source.\n> \n>> Even adding \"(default: x)\" to values already complicates the parsing process to get multiple config options in a script. Yeah, a script can get individual values one by one, but it can take ages because of the start-up time (again, this is important for interactive scripts like shell completions).\n> \n> May we should drop the `(default: x)` part unless --verbose is specified. That would make sense to me. Since experimental\/devel\/debug(\/deprecated?) only appears with --verbose that might work just fine for you ?\n\nAlternatively, what if we just dropped the `(default: x)`, `(EXPERIMENTAL)`, and whatever else complicates parsing if HGPLAIN is set?\n","author":"mharbison72","id":"100630","dateCreated":"1568554404","dateModified":"1568554404"},{"type":"inline","comment":"Theses should be flagged `(EXPERIMENTAL)`","replyTo":null,"isNewFile":"1","line":"672","lineLength":"74","path":"tests\/test-config.t","diffId":"16306","author":"marmoute","id":"100628","dateCreated":"1568552850","dateModified":"1568552850"},{"type":"inline","comment":"We should get a dedicated attribute form them too. Something like `(DEVELOPER)` or `(DEBUG)`","replyTo":null,"isNewFile":"1","line":"630","lineLength":"23","path":"tests\/test-config.t","diffId":"16306","author":"marmoute","id":"100627","dateCreated":"1568552850","dateModified":"1568552850"},{"type":"inline","comment":"the `(EXPERIMENTAL)` flag should be at the end:\n\n```\ncensor.policy=abort (EXPERIMENTAL)\n```\n\nIn addition this `(default: None)` display looks wrong. \"None\" is an internal python value with no meaning in our config interface to the user. People cannot use \"None\" is their config file to mean an underlying `None` python reference, so we should not display that to them.","replyTo":null,"isNewFile":"1","line":"553","lineLength":"0","path":"tests\/test-config.t","diffId":"16306","author":"marmoute","id":"100626","dateCreated":"1568552850","dateModified":"1568552850"},{"type":"inline","comment":"This should be flag (EXPERIMENTAL).","replyTo":null,"isNewFile":"1","line":"391","lineLength":"0","path":"tests\/test-config.t","diffId":"16306","author":"marmoute","id":"100625","dateCreated":"1568552850","dateModified":"1568552850"},{"type":"inline","comment":"This empty default is a bit strange. Maybe we want to explicitly quote empty string ? Or maybe this default value should be None and not \"\") or use `<empty>` or something. @av6  what do you think ?","replyTo":null,"isNewFile":"1","line":"244","lineLength":"0","path":"tests\/test-config.t","diffId":"16306","author":"marmoute","id":"100624","dateCreated":"1568552850","dateModified":"1568552850"},{"type":"inline","comment":"This are unrelated (and maybe unwanted) changes from the transformation I flagged earlier.\n\nIf we really want them, they should be in their own changesets. But I don't think we do. ","replyTo":null,"isNewFile":"1","line":"5","lineLength":"0","path":"tests\/test-basic.t","diffId":"16306","author":"marmoute","id":"100623","dateCreated":"1568552850","dateModified":"1568552850"},{"type":"inline","comment":"Here is an example the possible inconsistency introduced by explicite section matching: not all experimental item will be tagged experimental.\n\nFormatting wise, happening `(EXPERIMENTAL)` like that to the name seems weird and does not match what we are doing of other `(EXPERIMENTAL)` flag, (eg: command --flag)","replyTo":null,"isNewFile":"1","line":"841","lineLength":"0","path":"mercurial\/ui.py","diffId":"16306","author":"marmoute","id":"100622","dateCreated":"1568552850","dateModified":"1568552850"},{"type":"inline","comment":"small feedback: We should probably not rely on hardcoded section name and rely on attributes on the config items only, it would be more robust.","replyTo":null,"isNewFile":"1","line":"835","lineLength":"0","path":"mercurial\/ui.py","diffId":"16306","author":"marmoute","id":"100621","dateCreated":"1568552850","dateModified":"1568552850"},{"type":"inline","comment":"This part seems fishy as it seems to apply to all `hg config` run, not only `--registered` one. I don't think we want that outside of `--registered`, transforming the config content the user put explicitly is likely to confuses them. In addition, we might end up transformation non-boolean value that happens to match these entry.\n\nInstead we should simply use transform boolean to 'yes', 'no' when we meet them. I suggest adding a `formatconfigvalue(value)` function that would do so and that we could use instead of `pycompat.bytestr(value)` in various places.","replyTo":null,"isNewFile":"1","line":"1896","lineLength":"0","path":"mercurial\/commands.py","diffId":"16306","author":"marmoute","id":"100620","dateCreated":"1568552850","dateModified":"1568552850"},{"type":"inline","comment":"Two feedbacks\n\nFirst, this does not seems the right location to do this transformation. The method is expected to return the default value of a config. In case of a list, we should return a list, not transform it to text. If you need to transform the list to text for display purpose, this should happens at the layers responsible for display.\n\nSecond, the code parsing list at https:\/\/www.mercurial-scm.org\/repo\/hg\/file\/tip\/mercurial\/config.py#l203 show that list formatting can get a bit more complicated. Since the list can be space separated (as used here, any value containings spaces will be need to be quoted (and quote within it escaped\u2026).\n\nThis could be handled by `formatconfigvalue` function discussed earlier.","replyTo":null,"isNewFile":"1","line":"796","lineLength":"0","path":"mercurial\/ui.py","diffId":"16306","author":"marmoute","id":"100619","dateCreated":"1568552850","dateModified":"1568552850"},{"type":"comment","comment":"Sorry for the late review. I though this diff was taken while I was in vacation\/unstacking-post-vacation. I just recently reappeared on my rader. I made multiple comments about the implementation, its output, and unexpected output changes. \n\n>>! In D6709#99199, @av6 wrote:\n> I'm strongly -1 on adding qualifiers straight to the keys. The primary usage scenario here is scripts (as explained in issue6014) -- regular users lived without this feature for years and didn't care (enough to file a bug) about getting all config options, or their default values, \/\/or\/\/ the experimental status (they could and still can read it in hg help config). `--registered` is needed for things like shell completions, and the output needs to be clear and parseable (and consistent with what regular showconfig shows).\n\nI disagree that the primary use is script only. As a suer I have wanted this for a long time and I am happy to finally have a way to get this data without grepping the source.\n\n> Even adding \"(default: x)\" to values already complicates the parsing process to get multiple config options in a script. Yeah, a script can get individual values one by one, but it can take ages because of the start-up time (again, this is important for interactive scripts like shell completions).\n\nMay we should drop the `(default: x)` part unless --verbose is specified. That would make sense to me. Since experimental\/devel\/debug(\/deprecated?) only appears with --verbose that might work just fine for you ?\n\n> Let's add a test to this patch that demonstrates that scripts can \/\/easily\/\/ use this new functionality. Something like `$ hg showconfig --registered -T '{name}={value}\\n' | egrep '^(color|diff)'`. Notice how this uses -T, which is recommended, but people writing scripts in the wild may not even use, and extra things in the output (i.e. anything other than just key and value) will trip their scripts up. Maaaybe if we put a strongly worded note in hg help showconfig about scripting and usage of -T, maybe then adding \"(EXPERIMENTAL)\" would make sense. But I think the current format of adding it to the key is weird and it would be better to add it to the end of the line, similar to what experimental CLI flags have in the output of `hg help -v command` (if at all, because, again, that is not how regular showconfig behaves and we do have both defaults and experimental statuses in hg help config).\n\n+1 for changing the place where it appears.\n\n> Sorry for coming up with this new condition only now, but I thought everyone was already on the same page.\n\n","author":"marmoute","id":"100618","dateCreated":"1568552850","dateModified":"1568552850"},{"type":"reject","author":"marmoute","id":"100617","dateCreated":"1568552850","dateModified":"1568552850"},{"type":"inline","comment":"Let's change this to `hg showconfig cmdserver --registered --verbose -T '{name}={value}\\n'`, no grep. cmdserver section has a variety of options, including experimental ones, plus that would test showing config sections by name with --registered.","replyTo":null,"isNewFile":"1","line":"962","lineLength":"0","path":"tests\/test-config.t","diffId":"16306","author":"av6","id":"100480","dateCreated":"1568347933","dateModified":"1568347933"},{"type":"comment","comment":"I'll be okay with this too, once we get rid of `(EXPERIMENTAL)` everywhere.","author":"av6","id":"100479","dateCreated":"1568347933","dateModified":"1568347933"},{"type":"comment","comment":"I'm okay with this as-is. Barring an objection in a week or so I'll queue it.\n\n(It's also possible I've missed something important when I read through the extensive review history here. Apologies if true, but please restate your concerns if you still have them on the current version of the patch.)","author":"durin42","id":"100389","dateCreated":"1568215355","dateModified":"1568215355"},{"type":"accept","author":"durin42","id":"100388","dateCreated":"1568215355","dateModified":"1568215355"},{"type":"comment","comment":"@av6 I have updated the tests. @marmoute can we just get rid of `(EXPERIMENTAL)` in the output? If we want to do that, changes have to be made in `ui.walkregisteredconfig()`. But, that's a hack which appends to either name or value and as @av6 mentioned, the user will see it on using with `-T` which they might not wanted.","author":"navaneeth.suresh","id":"99203","dateCreated":"1566632254","dateModified":"1566632254"},{"type":"update","diffId":"16306","author":"navaneeth.suresh","id":"99201","dateCreated":"1566632048","dateModified":"1566632048"},{"type":"comment","comment":"I'm strongly -1 on adding qualifiers straight to the keys. The primary usage scenario here is scripts (as explained in issue6014) -- regular users lived without this feature for years and didn't care (enough to file a bug) about getting all config options, or their default values, \/\/or\/\/ the experimental status (they could and still can read it in hg help config). `--registered` is needed for things like shell completions, and the output needs to be clear and parseable (and consistent with what regular showconfig shows).\n\nEven adding \"(default: x)\" to values already complicates the parsing process to get multiple config options in a script. Yeah, a script can get individual values one by one, but it can take ages because of the start-up time (again, this is important for interactive scripts like shell completions).\n\nLet's add a test to this patch that demonstrates that scripts can \/\/easily\/\/ use this new functionality. Something like `$ hg showconfig --registered -T '{name}={value}\\n' | egrep '^(color|diff)'`. Notice how this uses -T, which is recommended, but people writing scripts in the wild may not even use, and extra things in the output (i.e. anything other than just key and value) will trip their scripts up. Maaaybe if we put a strongly worded note in hg help showconfig about scripting and usage of -T, maybe then adding \"(EXPERIMENTAL)\" would make sense. But I think the current format of adding it to the key is weird and it would be better to add it to the end of the line, similar to what experimental CLI flags have in the output of `hg help -v command` (if at all, because, again, that is not how regular showconfig behaves and we do have both defaults and experimental statuses in hg help config).\n\nSorry for coming up with this new condition only now, but I thought everyone was already on the same page.","author":"av6","id":"99199","dateCreated":"1566624258","dateModified":"1566624258"},{"type":"reject","author":"av6","id":"99198","dateCreated":"1566624258","dateModified":"1566624258"},{"type":"comment","comment":">>! In D6709#99166, @av6 wrote:\n> @marmoute did you want this flag marked as experimental or am I misremembering?\n\n@av6 @marmoute told me to add `EXPERIMENTAL` in the output of the config options which are experimental but, not come under the section experimental.\nThere are 28 of them. For example, `sparse.missingwarning(EXPERIMENTAL)=yes (default: None)`. We had this conversation in IRC. I think you are\nreferring to that.","author":"navaneeth.suresh","id":"99167","dateCreated":"1566586865","dateModified":"1566586865"},{"type":"comment","comment":"@marmoute did you want this flag marked as experimental or am I misremembering?","author":"av6","id":"99166","dateCreated":"1566530850","dateModified":"1566530850"},{"type":"accept","author":"av6","id":"99165","dateCreated":"1566530850","dateModified":"1566530850"},{"type":"update","diffId":"16290","author":"navaneeth.suresh","id":"99119","dateCreated":"1566476106","dateModified":"1566476106"},{"type":"inline","comment":"Let's rename this variable to better reflect its intent. AFAIU, a better name would be `rawvalue` or `origvalue`.","replyTo":null,"isNewFile":"1","line":"1893","lineLength":"0","path":"mercurial\/commands.py","diffId":"16286","author":"av6","id":"99108","dateCreated":"1566362882","dateModified":"1566362882"},{"type":"update","diffId":"16286","author":"navaneeth.suresh","id":"99091","dateCreated":"1566318721","dateModified":"1566318721"},{"type":"update","diffId":"16248","author":"navaneeth.suresh","id":"98859","dateCreated":"1566054490","dateModified":"1566054490"},{"type":"update","diffId":"16247","author":"navaneeth.suresh","id":"98855","dateCreated":"1566053605","dateModified":"1566053605"},{"type":"inline","comment":"Nit: originally I was fine with two different `if ...: continue` blocks here, and I still think it would be better. Not only the condition here is fairly complex and spans multiple lines (so not easy to read), but this comment is not quite correct. We always omit items with dynamic defaults and generic items, but experimental (& etc) items are only omitted unless --verbose is given. Two comments in two if-blocks with two separate conditions here would be more readable.","replyTo":null,"isNewFile":"1","line":"832","lineLength":"0","path":"mercurial\/ui.py","diffId":"16229","author":"av6","id":"98848","dateCreated":"1566046797","dateModified":"1566046797"},{"type":"reject","author":"av6","id":"98846","dateCreated":"1566046550","dateModified":"1566046550"},{"type":"update","diffId":"16229","author":"navaneeth.suresh","id":"98820","dateCreated":"1565990480","dateModified":"1565990480"},{"type":"update","diffId":"16220","author":"navaneeth.suresh","id":"98777","dateCreated":"1565946681","dateModified":"1565946681"},{"type":"update","diffId":"16218","author":"navaneeth.suresh","id":"98775","dateCreated":"1565946359","dateModified":"1565946359"},{"type":"inline","comment":"Nit: this condition could be made into another `if ...: continue` block just like the one below, making things less indented.","replyTo":null,"isNewFile":"1","line":"825","lineLength":"1","path":"mercurial\/ui.py","diffId":"16216","author":"av6","id":"98768","dateCreated":"1565941872","dateModified":"1565941872"},{"type":"comment","comment":"It looks fine to me, one thing that could be improved is the output format of list values. For example, `progress.format`: its default value is shown to be `['topic', 'bar', 'number', 'estimate']`, but it doesn't match `hg help config.progress.format` (it says `default: topic bar number estimate`), and that is also not the format that users would need to use for the actual value in hgrc or using --config flag.","author":"av6","id":"98767","dateCreated":"1565941872","dateModified":"1565941872"},{"type":"update","diffId":"16216","author":"navaneeth.suresh","id":"98763","dateCreated":"1565898158","dateModified":"1565898158"},{"type":"comment","comment":"Looks good to me, but I want someone else to put eyes on it before it gets pushed.","author":"durin42","id":"98745","dateCreated":"1565881997","dateModified":"1565881997"},{"type":"accept","author":"durin42","id":"98744","dateCreated":"1565881997","dateModified":"1565881997"},{"type":"comment","comment":">>! In D6709#98718, @marmoute wrote:\n> I get 28 of them.\n> \n> I think we need to add an `experimental` or `status` argument ot the config registration.\n\n\nCreated D6728 to add an `experimental` argument to the config registrar and made it as a parent revision.\n\n","author":"navaneeth.suresh","id":"98729","dateCreated":"1565879534","dateModified":"1565879534"},{"type":"update","diffId":"16209","author":"navaneeth.suresh","id":"98725","dateCreated":"1565879368","dateModified":"1565879368"},{"type":"comment","comment":"I get 28 of them.\n\nI think we need to add an `experimental` or `status` argument ot the config registration.\n\n```\n> ag --nofilename '# experimental config:.*' -o | sort -u\n# experimental config: censor.policy\n# experimental config: cmdserver.max-repo-cache\n# experimental config: cmdserver.message-encodings\n# experimental config: commands.grep.all-files\n# experimental config: commands.status.skipstates\n# experimental config: convert.ignoreancestorcheck\n# experimental config: experimental.graphshorten\n# experimental config: experimental.graphstyle.*\n# experimental config: experimental.hook-track-tags\n# experimental config: format.chunkcachesize\n# experimental config: format.generaldelta\n# experimental config: format.internal-phase\n# experimental config: format.manifestcachesize\n# experimental config: format.maxchainlen\n# experimental config: fsmonitor.verbose\n# experimental config: merge.preferancestor\n# experimental config: patchbomb.publicurl\n# experimental config: perf.all-timing\n# experimental config: perf.parentscount\n# experimental config: perf.presleep\n# experimental config: perf.run-limits\n# experimental config: perf.stub\n# experimental config: repack.chainorphansbysize\n# experimental config: sparse.missingwarning\n# experimental config: storage.new-repo-backend\n# experimental config: storage.sqlite.compression\n# experimental config: web.view\n```","author":"marmoute","id":"98718","dateCreated":"1565863831","dateModified":"1565863831"},{"type":"comment","comment":">>! In D6709#98716, @marmoute wrote:\n> We will need more than just matching the categoie name to detect experimental\/deprecated config. There are such option outside of the `experimental` section, and we still need to hide them by default. You can grep for `# experimental config:` to see some example.\n\nI only see one of them `rebase.experimental.inmemory`. I think it will be nice to have configs option correctly put inside `experimental` section instead of adding more filtering here.","author":"pulkit","id":"98717","dateCreated":"1565863238","dateModified":"1565863238"},{"type":"comment","comment":"We will need more than just matching the categoie name to detect experimental\/deprecated config. There are such option outside of the `experimental` section, and we still need to hide them by default. You can grep for `# experimental config:` to see some example.","author":"marmoute","id":"98716","dateCreated":"1565862392","dateModified":"1565862392"},{"type":"update","diffId":"16172","author":"navaneeth.suresh","id":"98546","dateCreated":"1565552727","dateModified":"1565552727"},{"type":"comment","comment":"I missed the `debug` one too, sorry. (Although I\u2019m not sure why that also isn\u2019t `devel.`, so maybe it isn\u2019t a big deal. Curious what others think.)","author":"mharbison72","id":"98545","dateCreated":"1565552309","dateModified":"1565552309"},{"type":"comment","comment":">>! In D6709#98542, @mharbison72 wrote:\n> Should we hide `devel.*` like we do `experimental` when `verbose` isn\u2019t applied?  Presumably we don\u2019t want regular users to know about them.\n\nDone.","author":"navaneeth.suresh","id":"98544","dateCreated":"1565547200","dateModified":"1565547200"},{"type":"update","diffId":"16171","author":"navaneeth.suresh","id":"98543","dateCreated":"1565547135","dateModified":"1565547135"},{"type":"comment","comment":"Should we hide `devel.*` like we do `experimental` when `verbose` isn\u2019t applied?  Presumably we don\u2019t want regular users to know about them.","author":"mharbison72","id":"98542","dateCreated":"1565546227","dateModified":"1565546227"},{"type":"update","diffId":"16170","author":"navaneeth.suresh","id":"98540","dateCreated":"1565530001","dateModified":"1565530001"},{"type":"inline","comment":"okay. then, i should revert it to the previous revision.","replyTo":"98537","isNewFile":"1","line":"232","lineLength":"0","path":"tests\/test-config.t","diffId":"16167","author":"navaneeth.suresh","id":"98539","dateCreated":"1565528794","dateModified":"1565528794"},{"type":"inline","comment":"We should be consistent when printing. And we should also be consistent when recording stuff in data.\n\nI think it make sense to print human friendly version ('yes\/no') and use the actual boolean value in data()\/json","replyTo":"98536","isNewFile":"1","line":"232","lineLength":"0","path":"tests\/test-config.t","diffId":"16167","author":"marmoute","id":"98537","dateCreated":"1565521470","dateModified":"1565521470"},{"type":"inline","comment":"that change was there in my patch one revision before. i was asked by @pulkit to modify it as of now. would you recommend writing `no` to `fm.data()` also? the `defaultvalue` was not in `pycompat.bytestr()` after @yuja's suggestion. it would be better if we consider that as a string and change the function accordingly if we want to modify it. otherwise, it should print  `no` and store `False`, print `False` on `hg showconfig --Tjson` in `defaultvalue`.","replyTo":"98533","isNewFile":"1","line":"232","lineLength":"0","path":"tests\/test-config.t","diffId":"16167","author":"navaneeth.suresh","id":"98536","dateCreated":"1565463770","dateModified":"1565463770"},{"type":"inline","comment":"the `(default: False)` should be `(default: no)` too.","replyTo":null,"isNewFile":"1","line":"232","lineLength":"0","path":"tests\/test-config.t","diffId":"16167","author":"marmoute","id":"98533","dateCreated":"1565463362","dateModified":"1565463362"},{"type":"update","diffId":"16167","author":"navaneeth.suresh","id":"98527","dateCreated":"1565377717","dateModified":"1565377717"},{"type":"inline","comment":"Can you add some tests for `hg config <some-config> --registered`?","replyTo":null,"isNewFile":"1","line":"990","lineLength":"0","path":"tests\/test-config.t","diffId":"16165","author":"pulkit","id":"98525","dateCreated":"1565376751","dateModified":"1565376751"},{"type":"inline","comment":"In the second case above,\n\nHow about something like:\n\n```\nannotate.ignoreblanklines=False  (default: False)\n```\n\ni.e. we show `(default ..)` if the user has set that config option.","replyTo":"98426","isNewFile":"1","line":"228","lineLength":"0","path":"tests\/test-config.t","diffId":"16119","author":"pulkit","id":"98524","dateCreated":"1565376751","dateModified":"1565376751"},{"type":"inline","comment":"unrequired change I guess","replyTo":null,"isNewFile":"1","line":"1888","lineLength":"0","path":"mercurial\/commands.py","diffId":"16165","author":"pulkit","id":"98523","dateCreated":"1565376751","dateModified":"1565376751"},{"type":"comment","comment":">>! In D6709#98493, @marmoute wrote:\n>>>! In D6709#98479, @navaneeth.suresh wrote:\n>> @pulkit I couldn't figure out why the devel-warnings are coming. It's being shown for the following \n>> items in `configitems.py`. IIUC, it should be visible when we are trying to read a config item which is\n>> not in the registered items.  But, we are iterating over registered items only.\n> \n> There are \"generic\" config option. So it does not hold the option \"name\", but a regexp to match valid entry.\n> \n>> @av6 If you have a strong opinion on replacing `True\/False` with `yes\/no`, I can do that.\n> \n> Not sure is @av6 has a strong opinion, but I do :-)\n\nI don't want to discuss whether `yes\/no` are better or `True\/False` but when showing the default value, let's show the exact same which is there even though they mean the same?","author":"pulkit","id":"98522","dateCreated":"1565376376","dateModified":"1565376376"},{"type":"update","diffId":"16165","author":"navaneeth.suresh","id":"98518","dateCreated":"1565326829","dateModified":"1565326829"},{"type":"comment","comment":">>! In D6709#98493, @marmoute wrote:\n>>>! In D6709#98479, @navaneeth.suresh wrote:\n>> @pulkit I couldn't figure out why the devel-warnings are coming. It's being shown for the following \n>> items in `configitems.py`. IIUC, it should be visible when we are trying to read a config item which is\n>> not in the registered items.  But, we are iterating over registered items only.\n> \n> There are \"generic\" config option. So it does not hold the option \"name\", but a regexp to match valid entry.\n\nFixed.\n \n>> @av6 If you have a strong opinion on replacing `True\/False` with `yes\/no`, I can do that.\n> \n> Not sure is @av6 has a strong opinion, but I do :-)\n\nFixed this too. Sorry I was supposed to type @marmoute instead of @av6. My bad.","author":"navaneeth.suresh","id":"98517","dateCreated":"1565326470","dateModified":"1565326470"},{"type":"update","diffId":"16164","author":"navaneeth.suresh","id":"98516","dateCreated":"1565326358","dateModified":"1565326358"},{"type":"comment","comment":">>! In D6709#98479, @navaneeth.suresh wrote:\n> @pulkit I couldn't figure out why the devel-warnings are coming. It's being shown for the following \n> items in `configitems.py`. IIUC, it should be visible when we are trying to read a config item which is\n> not in the registered items.  But, we are iterating over registered items only.\n\nThere are \"generic\" config option. So it does not hold the option \"name\", but a regexp to match valid entry.\n\n> @av6 If you have a strong opinion on replacing `True\/False` with `yes\/no`, I can do that.\n\nNot sure is @av6 has a strong opinion, but I do :-)\n\n","author":"marmoute","id":"98493","dateCreated":"1565281512","dateModified":"1565281512"},{"type":"comment","comment":"@pulkit I couldn't figure out why the devel-warnings are coming. It's being shown for the following \nitems in `configitems.py`. IIUC, it should be visible when we are trying to read a config item which is\nnot in the registered items.  But, we are iterating over registered items only.\n\n```\ncoreconfigitem('help', br'hidden-command\\..*',\n    default=False,\n    generic=True,\n)\ncoreconfigitem('help', br'hidden-topic\\..*',\n    default=False,\n    generic=True,\n)\ncoreconfigitem('hostsecurity', '.*:fingerprints$',\n    default=list,\n    generic=True,\n)\ncoreconfigitem('hostsecurity', '.*:verifycertsfile$',\n    default=None,\n    generic=True,\n)\n```\nAlso, why would we want `walkregisteredconfig()` to return `section, name, value, defaultvalue` ?\nIf we do that, then it would require modification in `ui.walkregisteredconfig()` and `commands.config()`.\n\n@av6 If you have a strong opinion on replacing `True\/False` with `yes\/no`, I can do that.","author":"navaneeth.suresh","id":"98479","dateCreated":"1565280523","dateModified":"1565280523"},{"type":"update","diffId":"16154","author":"navaneeth.suresh","id":"98478","dateCreated":"1565279628","dateModified":"1565279628"},{"type":"update","diffId":"16153","author":"navaneeth.suresh","id":"98476","dateCreated":"1565279465","dateModified":"1565279465"},{"type":"inline","comment":"Note: we I think we should use `yes\/no` instead of `True` and `False`.","replyTo":null,"isNewFile":"1","line":"229","lineLength":"0","path":"tests\/test-config.t","diffId":"16119","author":"marmoute","id":"98427","dateCreated":"1565187789","dateModified":"1565187789"},{"type":"inline","comment":"Displaying the default vs current is good idea, but the current proposal might be a bit odd:\n\nIf nothing is set we will have:\n```\nannotate.ignoreblanklines=False\n```\n\nIf something is set and is the same as the default we'll have\n\n```\nannotate.ignoreblanklines=False\n```\n\nIf something is set and is different from the repo we will have\n\n```\nannotate.ignoreblanklines=True (default: False)\n```\n\nThe first two cases can't be distinguish while they probably should, and the default value is displayed differently between the first and third case.","replyTo":"98420","isNewFile":"1","line":"228","lineLength":"0","path":"tests\/test-config.t","diffId":"16119","author":"marmoute","id":"98426","dateCreated":"1565187789","dateModified":"1565187789"},{"type":"reject","author":"marmoute","id":"98425","dateCreated":"1565187789","dateModified":"1565187789"},{"type":"inline","comment":"Just for record, @av6 comment here is not done as there are still devel-warnings.","replyTo":"98230","isNewFile":"1","line":"238","lineLength":"0","path":"tests\/test-config.t","diffId":"16114","author":"pulkit","id":"98422","dateCreated":"1565187373","dateModified":"1565187373"},{"type":"inline","comment":"Can you look as why these devel-warning are coming up?\n\nSince we are using `--registered`, having warnings related to unregistered config does not seems good.","replyTo":null,"isNewFile":"1","line":"827","lineLength":"0","path":"tests\/test-config.t","diffId":"16119","author":"pulkit","id":"98421","dateCreated":"1565187373","dateModified":"1565187373"},{"type":"inline","comment":"In cases when the default value and the value of config set are different, let's do something like `<current-output> (default=<default_value>)`","replyTo":null,"isNewFile":"1","line":"228","lineLength":"0","path":"tests\/test-config.t","diffId":"16119","author":"pulkit","id":"98420","dateCreated":"1565187373","dateModified":"1565187373"},{"type":"inline","comment":"Since, we renamed the flag which was good idea, let's rename the function too.\n\nAlso, this should better return `section, name, value, default_value`.","replyTo":null,"isNewFile":"1","line":"821","lineLength":"0","path":"mercurial\/ui.py","diffId":"16119","author":"pulkit","id":"98419","dateCreated":"1565187373","dateModified":"1565187373"},{"type":"update","diffId":"16119","author":"navaneeth.suresh","id":"98249","dateCreated":"1564851212","dateModified":"1564851212"},{"type":"comment","comment":"Interesting feature for sure. Thanks for looking into it.\n\nThe `--all` flag might be a bit too generic\/vague. Maybe --known, \n--registered  or --default ?\n\nWe should skip experimental and deprecated configuration unless \n--verbose is specified. And we should flag them as deprecated\/experimental.\n\nFor config that has multiple alias, it could be a good idea to display \nthis information too (probably with --verbose)","author":"marmoute","id":"98242","dateCreated":"1564832576","dateModified":"1564832576"},{"type":"inline","comment":"Could you please suggest something better?","replyTo":"98206","isNewFile":"1","line":"1774","lineLength":"0","path":"mercurial\/commands.py","diffId":"16114","author":"navaneeth.suresh","id":"98231","dateCreated":"1564812027","dateModified":"1564812027"},{"type":"inline","comment":"I have ignored the cases with `dynamicdefault`. But, there are three cases showing a `devel-warn: accessing unregistered config item` message. Couldn't figure out why it is coming.","replyTo":"98207","isNewFile":"1","line":"238","lineLength":"0","path":"tests\/test-config.t","diffId":"16114","author":"navaneeth.suresh","id":"98230","dateCreated":"1564812027","dateModified":"1564812027"},{"type":"update","diffId":"16117","author":"navaneeth.suresh","id":"98227","dateCreated":"1564811710","dateModified":"1564811710"},{"type":"inline","comment":"Certainly a good way to find all config options without default values, but in the final implementation of `showconfig -a` it should not produce any warnings (especially not developer warnings).\n\nIt's probably possible to add default values to some of the items this test found, but I think some of them are missing defaults by design (an obvious example being `alias..*`). In that case it might be better to just skip them.","replyTo":null,"isNewFile":"1","line":"238","lineLength":"0","path":"tests\/test-config.t","diffId":"16114","author":"av6","id":"98207","dateCreated":"1564749893","dateModified":"1564749893"},{"type":"inline","comment":"This needs a better description to differentiate this flag and the default mode (see line 1786).","replyTo":null,"isNewFile":"1","line":"1774","lineLength":"0","path":"mercurial\/commands.py","diffId":"16114","author":"av6","id":"98206","dateCreated":"1564749893","dateModified":"1564749893"},{"type":"reject","author":"av6","id":"98205","dateCreated":"1564749893","dateModified":"1564749893"},{"type":"update","diffId":"16114","author":"navaneeth.suresh","id":"98203","dateCreated":"1564743188","dateModified":"1564743188"},{"type":"update","diffId":"16113","author":"navaneeth.suresh","id":"98198","dateCreated":"1564739338","dateModified":"1564739338"}],"dateCreated":"1564739338","dateModified":"1570217161","status":"Needs Review"},{"id":"6963","callsign":"HG","title":"config: show config options in a user-friendly format","author":"navaneeth.suresh","summary":"This patch does the following things to display the output in a\nuser-friendly format:\n* Replace bool by yes\/no.\n* Converts list to string.\n\nI will be modifying this soon to handle list values in a better way.","testPlan":"","lineCount":"790","dependsOn":["6709"],"reviewers":[],"ccs":["mjpieters","mercurial-devel"],"actions":[{"type":"update","diffId":"16803","author":"navaneeth.suresh","id":"102045","dateCreated":"1570217020","dateModified":"1570217020"}],"dateCreated":"1570217020","dateModified":"1570217066","status":"Needs Review"},{"id":"6962","callsign":"HG","title":"config: add defaults and experimental status for --debug flag","author":"navaneeth.suresh","summary":"This patch adds `EXPERIMENTAL` to the output of 'showconfig --debug'\nfor experimental flags which are not under the `section == 'experimental'`.\nThis also adds the default value of the config item if it differs from\nthe current value.","testPlan":"","lineCount":"18","dependsOn":["6709"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"16802","author":"navaneeth.suresh","id":"102037","dateCreated":"1570216224","dateModified":"1570216224"}],"dateCreated":"1570216224","dateModified":"1570216402","status":"Needs Review"},{"id":"6959","callsign":"HG","title":"setup: switch to having setup.py generate an hg script","author":"durin42","summary":"This gives us a more-standard entry_points setup and lets us skip the\nstep of generating the interpreter shebang etc, easing some Python 3\nwork.","testPlan":"","lineCount":"23","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"This currently breaks a bunch of stuff, I think because the installed hg isn't on $PATH?","author":"durin42","id":"102017","dateCreated":"1570209804","dateModified":"1570209804"},{"type":"plan-changes","author":"durin42","id":"102016","dateCreated":"1570209804","dateModified":"1570209804"},{"type":"update","diffId":"16797","author":"durin42","id":"102015","dateCreated":"1570209773","dateModified":"1570209773"},{"type":"update","diffId":"16795","author":"durin42","id":"102004","dateCreated":"1570209061","dateModified":"1570209061"}],"dateCreated":"1570209061","dateModified":"1570209804","status":"Changes Planned"},{"id":"6957","callsign":"HG","title":"rebase: unconditionally clear merge state when `--stop`ing a rebase","author":"durin42","summary":"I am NOT sure of the correctness of this change, but I've hit a point\non a work repository where the needupdate function returns false and\nso the merge state never gets correctly cleared. As far as I can tell\nwhen we're *always* in a merge state at this point, so we should\n*always* clear the merge state.\n\nI'm not sure how to structure the test at the moment, but if others\nagree that this looks plausible I'll try and figure out what state my\nwork repository is in to craft a test case that can be used to prevent\nany backsliding on this fix.","testPlan":"","lineCount":"7","dependsOn":[],"reviewers":["martinvonz"],"ccs":["marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D6957#101985, @martinvonz wrote:\n>>>! In D6957#101984, @marmoute wrote:\n>>>>! In D6957#101977, @martinvonz wrote:\n>>> How was it failing for you?\n>>> \n>>> I don't think I've used `hg rebase --stop`, but I had been wondering what it would do with the working directory. It's unclear to me what it should do, and now after looking at the code, it's also unclear what the author meant it to do. Maybe it would be best to just leave the working directory untouched? Oh, we should also compare to what `hg evolve --stop` does (I haven't checked).\n>> \n>> The evolve semantic, is to:\n>> * get out of the current conflict (so, reverting the working copy)\n>> * preserve all successful evolution so far.\n>> \n>> Since you cannot `continue` after the --stop, we would not be able to do anything good with the conflict if the user resolved it anyway.\n>> \n>> I think rebase should have the same logic and revert the current conflict (preserving all successfully rebased revision)\n> \n> True, you'd get to resolve the conflicts on the next `hg rebase\/evolve` anyway, so I agree there's no need to preserve the working copy.\n> \n> @durin42, any idea how you ended up with just one working copy parent?\n\nI don't have just one parent. If you want to inspect the state, look at `augie\/a 59473`;)","author":"durin42","id":"101986","dateCreated":"1570195921","dateModified":"1570195921"},{"type":"comment","comment":">>! In D6957#101984, @marmoute wrote:\n>>>! In D6957#101977, @martinvonz wrote:\n>> How was it failing for you?\n>> \n>> I don't think I've used `hg rebase --stop`, but I had been wondering what it would do with the working directory. It's unclear to me what it should do, and now after looking at the code, it's also unclear what the author meant it to do. Maybe it would be best to just leave the working directory untouched? Oh, we should also compare to what `hg evolve --stop` does (I haven't checked).\n> \n> The evolve semantic, is to:\n> * get out of the current conflict (so, reverting the working copy)\n> * preserve all successful evolution so far.\n> \n> Since you cannot `continue` after the --stop, we would not be able to do anything good with the conflict if the user resolved it anyway.\n> \n> I think rebase should have the same logic and revert the current conflict (preserving all successfully rebased revision)\n\nTrue, you'd get to resolve the conflicts on the next `hg rebase\/evolve` anyway, so I agree there's no need to preserve the working copy.\n\n@durin42, any idea how you ended up with just one working copy parent?\n","author":"martinvonz","id":"101985","dateCreated":"1570195088","dateModified":"1570195088"},{"type":"comment","comment":">>! In D6957#101977, @martinvonz wrote:\n> How was it failing for you?\n> \n> I don't think I've used `hg rebase --stop`, but I had been wondering what it would do with the working directory. It's unclear to me what it should do, and now after looking at the code, it's also unclear what the author meant it to do. Maybe it would be best to just leave the working directory untouched? Oh, we should also compare to what `hg evolve --stop` does (I haven't checked).\n\nThe evolve semantic, is to:\n* get out of the current conflict (so, reverting the working copy)\n* preserve all successful evolution so far.\n\nSince you cannot `continue` after the --stop, we would not be able to do anything good with the conflict if the user resolved it anyway.\n\nI think rebase should have the same logic and revert the current conflict (preserving all successfully rebased revision)","author":"marmoute","id":"101984","dateCreated":"1570194688","dateModified":"1570194688"},{"type":"comment","comment":"How was it failing for you?\n\nI don't think I've used `hg rebase --stop`, but I had been wondering what it would do with the working directory. It's unclear to me what it should do, and now after looking at the code, it's also unclear what the author meant it to do. Maybe it would be best to just leave the working directory untouched? Oh, we should also compare to what `hg evolve --stop` does (I haven't checked).","author":"martinvonz","id":"101977","dateCreated":"1570182767","dateModified":"1570182767"},{"type":"update","diffId":"16789","author":"durin42","id":"101967","dateCreated":"1570153196","dateModified":"1570153196"}],"dateCreated":"1570153196","dateModified":"1570195921","status":"Needs Review"},{"id":"6678","callsign":"HG","title":"continue: added support for histedit","author":"taapas1128","summary":"This patch adds the support for histedit in `hg continue` plan.\n\nAs seperate `hgcontinuehistedit()` function is created to handle\nindependent calls for resuming histedit. This function is\nthen registered as continuefunc for state detection API.\n\nResults are shown as tests.","testPlan":"","lineCount":"45","dependsOn":["6665"],"reviewers":["durin42"],"ccs":["pulkit","mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"100398","dateCreated":"1568215690","dateModified":"1568215690"},{"type":"comment","comment":"@pulkit This one is ready too.","author":"taapas1128","id":"98845","dateCreated":"1566036806","dateModified":"1566036806"},{"type":"update","diffId":"16157","author":"taapas1128","id":"98483","dateCreated":"1565280673","dateModified":"1565280673"},{"type":"inline","comment":"I see that we can have a unified function, `resumehistedit(..)` which can be called from `_histedit()` too. ","replyTo":null,"isNewFile":"1","line":"1842","lineLength":"0","path":"hgext\/histedit.py","diffId":"16019","author":"pulkit","id":"98464","dateCreated":"1565215321","dateModified":"1565215321"},{"type":"update","diffId":"16019","author":"taapas1128","id":"97691","dateCreated":"1563906702","dateModified":"1563906702"},{"type":"update","diffId":"16018","author":"taapas1128","id":"97683","dateCreated":"1563906535","dateModified":"1563906535"}],"dateCreated":"1563906535","dateModified":"1570189436","status":"Accepted"},{"id":"6665","callsign":"HG","title":"continue: added support for graft","author":"taapas1128","summary":"This patch creates `cmdutil.continuegraft()` function\nwhich contains the logic to resume graft when called directly.\nThis function is then registered as `continuefunc` to support\n`hg continue`.\n\nResults are shown as tests.","testPlan":"","lineCount":"73","dependsOn":["6659"],"reviewers":["durin42"],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"16792","author":"taapas1128","id":"101980","dateCreated":"1570189427","dateModified":"1570189427"},{"type":"accept","author":"durin42","id":"100396","dateCreated":"1568215665","dateModified":"1568215665"},{"type":"update","diffId":"16173","author":"taapas1128","id":"98547","dateCreated":"1565617752","dateModified":"1565617752"},{"type":"update","diffId":"16156","author":"taapas1128","id":"98482","dateCreated":"1565280659","dateModified":"1565280659"},{"type":"update","diffId":"16121","author":"taapas1128","id":"98257","dateCreated":"1564920842","dateModified":"1564920842"},{"type":"update","diffId":"15988","author":"taapas1128","id":"97540","dateCreated":"1563732312","dateModified":"1563732312"}],"dateCreated":"1563732312","dateModified":"1570189427","status":"Accepted"},{"id":"6859","callsign":"HG","title":"rust-cpython: mark PySharedState as Sync so &'PySharedState can be Send (RFC)","author":"yuja","summary":"The goal is to store &'static PySharedState in $leaked struct, which allows\nus to move the $leaked struct out of the macro. Currently, it depends on\n$inner.py_shared_state(py).\n\nI think PySharedState is Sync because any mutation is synchronized by the\nPython GIL, but I'm not pretty sure. I want to know if that's correct before\nmoving forward.","testPlan":"","lineCount":"4","dependsOn":[],"reviewers":[],"ccs":["Alphare","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"Also, since it's possible we could call back into Python code and *that* could release-and-reacquire the GIL, the GIL guarding is probably insufficient to make this a \"safe lie\".","author":"durin42","id":"100907","dateCreated":"1569267328","dateModified":"1569267328"},{"type":"comment","comment":"I asked some coworkers, and they said:\n\n> I do not believe this to be correct. An object is Sync if it is *inherently* thread-safe. This object is not -- the first thing borrow_mut does is a racy read of mutably_borrowed.\n\nso I'm now leaning towards this being a bad idea.","author":"durin42","id":"100906","dateCreated":"1569267265","dateModified":"1569267265"},{"type":"comment","comment":"It is indeed `Sync` because the `py_class!` macro forces us to have a reference to the GIL at the type level to access the data attributes, but I would also like to be extra sure and have someone else confirm it.","author":"Alphare","id":"100700","dateCreated":"1568711038","dateModified":"1568711038"},{"type":"update","diffId":"16562","author":"yuja","id":"100693","dateCreated":"1568676461","dateModified":"1568676461"}],"dateCreated":"1568676461","dateModified":"1569267328","status":"Needs Review"},{"id":"6776","callsign":null,"title":"bookmarks: validate changes on push (issue6193) (BC)","author":"idlsoft","summary":"The actual validation is in bundle2.handlebookmark.\nThe rest of the changes are there to pass the force parameter.\nI've also made force available to hooks. That way one can validate who can and cannot use --force on a shared repo.\n\nIn other words, in the case of:\n\n    o 2\n    |  o 1 @\n    o\/ 0\n\nwhen I last pulled, @ was on 0, and now I'm doing hg push -B @, but\nsince my last pull the server advanced @ to 2, meaning it's a\nnon-linear update of the bookmark. This used to be allowed, and is now\nprohibited without --force.\n\n.. bc::\n\n    `hg push --bookmark` and `hg push -B` no longer move a bookmark\n    during push if the new bookmark position isn't a descendant of the\n    current bookmark position.\n\n.. feature::\n\n    Hooks are now able to tell if --force was specified when a bookmark was pushed.","testPlan":"","lineCount":"203","dependsOn":[],"reviewers":["durin42"],"ccs":["pulkit","durin42","valentin.gatienbaron","mercurial-devel"],"actions":[{"type":"comment","comment":"> If you mean \"reject bad pushes as long as people don't push -f\", both versions implement this (the client-side check is not racy thanks to these check:bookmark bundle parts).\nThat was the idea. This implementation is a bit more flexible I think.\nSince it\u2019s server side, you don\u2019t have to upgrade your clients.\nIt\u2019s true old clients won\u2019t be able to use \u2014force, but new ones can.\nAnd you can add a trigger if you want to limit who can use \u2014force.\n\n","author":"idlsoft","id":"100533","dateCreated":"1568441725","dateModified":"1568441725"},{"type":"comment","comment":">>! In D6776#100506, @durin42 wrote:\n>>>! In D6776#100487, @valentin.gatienbaron wrote:\n>> I showed in D6847 the same change but implemented in exchange._processcompared. Tests pass.\n>> I think it'd make for a simpler final state: with the current change, the client sees that the bookmark is going to move sideways, decides this is fine, requests that the server validates that the bookmark is indeed moving sideways (which it does), but in the end the server rejects the move. In the suggested change, the client sees that the bookmark is going sideways and rejects it. This should be consistent with the way new heads or new branches or diverging rewrites are prevented.\n> \n> Isn't that a client-side change only though, so we still need functionality on the server to reject bad pushes? (I could be missing something.)\n\nIf you mean \"reject bad pushes as long as people don't push -f\", both versions implement this (the client-side check is not racy thanks to these check:bookmark bundle parts).\nIf you mean \"reject bad pushes, push -f or not\", a server-side hook is necessary for that, and hook.pretxnclose-bookmark should be able to do the job without any server code change. Server code change can certainly simplify writing such checks, but passing the force parameter on the procol is not needed.","author":"valentin.gatienbaron","id":"100532","dateCreated":"1568440575","dateModified":"1568440575"},{"type":"update","diffId":"16534","author":"idlsoft","id":"100519","dateCreated":"1568436765","dateModified":"1568436765"},{"type":"update","diffId":"16533","author":"idlsoft","id":"100518","dateCreated":"1568428463","dateModified":"1568428463"},{"type":"update","diffId":"16531","author":"idlsoft","id":"100513","dateCreated":"1568420567","dateModified":"1568420567"},{"type":"comment","comment":"> Isn't that a client-side change only though, so we still need functionality on the server to reject bad pushes? (I could be missing something.)\n\nI updated the diff to propagate --force properly","author":"idlsoft","id":"100511","dateCreated":"1568410784","dateModified":"1568420628"},{"type":"comment","comment":">>! In D6776#100487, @valentin.gatienbaron wrote:\n> I showed in D6847 the same change but implemented in exchange._processcompared. Tests pass.\n> I think it'd make for a simpler final state: with the current change, the client sees that the bookmark is going to move sideways, decides this is fine, requests that the server validates that the bookmark is indeed moving sideways (which it does), but in the end the server rejects the move. In the suggested change, the client sees that the bookmark is going sideways and rejects it. This should be consistent with the way new heads or new branches or diverging rewrites are prevented.\n\nIsn't that a client-side change only though, so we still need functionality on the server to reject bad pushes? (I could be missing something.)","author":"durin42","id":"100506","dateCreated":"1568382052","dateModified":"1568382052"},{"type":"comment","comment":"I showed in D6847 the same change but implemented in exchange._processcompared. Tests pass.\nI think it'd make for a simpler final state: with the current change, the client sees that the bookmark is going to move sideways, decides this is fine, requests that the server validates that the bookmark is indeed moving sideways (which it does), but in the end the server rejects the move. In the suggested change, the client sees that the bookmark is going sideways and rejects it. This should be consistent with the way new heads or new branches or diverging rewrites are prevented.\n","author":"valentin.gatienbaron","id":"100487","dateCreated":"1568349208","dateModified":"1568349208"},{"type":"update","diffId":"16524","author":"idlsoft","id":"100462","dateCreated":"1568310366","dateModified":"1568310366"},{"type":"inline","comment":"It will be nice to have documentation about what `force` does in the interface.","replyTo":null,"isNewFile":"1","line":"194","lineLength":"0","path":"mercurial\/interfaces\/repository.py","diffId":"16519","author":"pulkit","id":"100444","dateCreated":"1568268366","dateModified":"1568268366"},{"type":"inline","comment":"Hm, I think `conflicts` can be confusing but I don't have better suggestions here.","replyTo":null,"isNewFile":"1","line":"2149","lineLength":"0","path":"mercurial\/bundle2.py","diffId":"16519","author":"pulkit","id":"100443","dateCreated":"1568268366","dateModified":"1568268366"},{"type":"comment","comment":"I agree with @valentin.gatienbaron that `--force` is quite generic :(.  It may create new heads on the server even if I don't want to.","author":"pulkit","id":"100442","dateCreated":"1568268366","dateModified":"1568268366"},{"type":"comment","comment":"We're really close. I've uploaded my rebase of this to the latest dev hg (along with some minor test fixes). There's now only one failure:\n\n```--- \/Users\/augie\/Programming\/hg\/crew\/tests\/test-bookmarks-pushpull.t\n+++ \/Users\/augie\/Programming\/hg\/crew\/tests\/test-bookmarks-pushpull.t#b2-binary.err\n@@ -820,15 +820,17 @@\n   pushing to http:\/\/localhost:$HGPORT\/\n   searching for changes\n   no changes found\n-  updating bookmark Z\n-  [1]\n+  remote: push rejected: bookmark \"Z\" has changed\n+  remote: (run 'hg pull', resolve conflicts, and push again)\n+  abort: push failed on remote\n+  [255]\n   $ hg book -d Z\n   $ hg in -B http:\/\/localhost:$HGPORT\/\n   comparing with http:\/\/localhost:$HGPORT\/\n   searching for changed bookmarks\n      @                         9b140be10808\n      X                         9b140be10808\n-     Z                         0d2164f0ce0d\n+     Z                         9b140be10808\n      foo                       000000000000\n      foobar                    9b140be10808\n   $ hg pull -B Z http:\/\/localhost:$HGPORT\/\n@@ -853,7 +855,7 @@\n    * @                         1:9b140be10808\n      X                         1:9b140be10808\n      Y                         4:c922c0139ca0\n-     Z                         2:0d2164f0ce0d\n+     Z                         1:9b140be10808\n      foo                       -1:000000000000\n      foobar                    1:9b140be10808\n \n\nERROR: test-bookmarks-pushpull.t#b2-binary output changed\n```\n\nMy gut at this point is that we should:\n\n1) Document that legacy bookmark push behavior over pushkey is different\n2) Add a config to reject bookmark pushes over pushkey\n\nBut if there's a way to fix the pushkey behavior too, I'd be interested in that. I'm just not sure it's worth blocking on when that should only matter with very old servers. Obviously if others have stronger opinions they should speak up.","author":"durin42","id":"100418","dateCreated":"1568225245","dateModified":"1568225245"},{"type":"update","diffId":"16519","author":"durin42","id":"100417","dateCreated":"1568225133","dateModified":"1568225133"},{"type":"update","diffId":"16518","author":"idlsoft","id":"100413","dateCreated":"1568217168","dateModified":"1568217168"},{"type":"comment","comment":"I've uploaded my revised version (with the more complete commit message - no other changes) in case that helps.","author":"durin42","id":"100386","dateCreated":"1568212358","dateModified":"1568212358"},{"type":"reject","author":"durin42","id":"100385","dateCreated":"1568212358","dateModified":"1568212358"},{"type":"update","diffId":"16515","author":"durin42","id":"100382","dateCreated":"1568212309","dateModified":"1568212309"},{"type":"comment","comment":"I get a fair number of test failures with this, eg `test-bookmarks-corner-case.t`:\n\n```\n--- \/usr\/local\/google\/home\/augie\/hgtest\/tests\/test-bookmarks-corner-case.t\n+++ \/usr\/local\/google\/home\/augie\/hgtest\/tests\/test-bookmarks-corner-case.t.err\n@@ -178,11 +178,48 @@\n   $ hg push -R client-B -r book-B\n   pushing to ssh:\/\/user@dummy\/bookrace-server\n   searching for changes\n-  remote: adding changesets\n-  remote: adding manifests\n-  remote: adding file changes\n-  remote: added 1 changesets with 1 changes to 1 files\n-  updating bookmark book-B\n+  ** unknown exception encountered, please report by visiting\n+  ** https:\/\/mercurial-scm.org\/wiki\/BugTracker\n+  ** Python 2.7.16 (default, Apr  6 2019, 01:42:57) [GCC 7.3.0]\n+  ** Mercurial Distributed SCM (version 5.1.1+253-85a0f0de90e5)\n+  ** Extensions loaded:\n+  Traceback (most recent call last):\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/bin\/hg\", line 43, in <module>\n+      dispatch.run()\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 99, in run\n+      status = dispatch(req)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 225, in dispatch\n+      ret = _runcatch(req) or 0\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 376, in _runcatch\n+      return _callcatch(ui, _runcatchfunc)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 384, in _callcatch\n+      return scmutil.callcatch(ui, func)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/scmutil.py\", line 167, in callcatch\n+      return func()\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 367, in _runcatchfunc\n+      return _dispatch(req)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 1021, in _dispatch\n+      cmdpats, cmdoptions)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 756, in runcommand\n+      ret = _runcommand(ui, options, cmd, d)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 1030, in _runcommand\n+      return cmdfunc()\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/dispatch.py\", line 1018, in <lambda>\n+      d = lambda: util.checksignature(func)(ui, *args, **strcmdopt)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/util.py\", line 1682, in check\n+      return func(*args, **kwargs)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/commands.py\", line 4667, in push\n+      opargs=opargs)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/exchange.py\", line 570, in push\n+      _pushbundle2(pushop)\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/exchange.py\", line 1164, in _pushbundle2\n+      'force': pushop.force,\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/thirdparty\/concurrent\/futures\/_base.py\", line 457, in result\n+      return self.__get_result()\n+    File \"\/tmp\/hgtests.lYOPXh\/install\/lib\/python\/mercurial\/wireprotov1peer.py\", line 211, in sendcommands\n+      result = fn(**pycompat.strkwargs(args))\n+  TypeError: unbundle() got an unexpected keyword argument 'force'\n+  [1]\n```\n\nCould I get you to take a look? I like where this is going, but I don't have the time at the moment to hunt down the issues in the tests.","author":"durin42","id":"100381","dateCreated":"1568212284","dateModified":"1568212284"},{"type":"comment","comment":"Queued this with lots of content added to the commit message. Thanks!","author":"durin42","id":"100379","dateCreated":"1568211385","dateModified":"1568211385"},{"type":"accept","author":"durin42","id":"100378","dateCreated":"1568211385","dateModified":"1568211385"},{"type":"comment","comment":"Yes, server changed since your last pull, and you override the bookmark without so much as a warning.","author":"idlsoft","id":"100223","dateCreated":"1568053939","dateModified":"1568053939"},{"type":"comment","comment":"Clarifying I understand: this causes pushing a bookmark to fail in what cases that it currently succeeds? I think it's just the case of:\n\n  o 2\n  |  o 1 @\n  o\/ 0\n\nwhen I last pulled, `@` was on 0, and now I'm doing `hg push -B @`, but since my last pull the server advanced `@` to 2, meaning it's a non-linear update. Right?\n\nIf so, I wholeheartedly approve, as this behavior has previously burned me and I think it's well past time we started breaking some compatibility edges on bookmarks to make them actually useful to share.","author":"durin42","id":"100154","dateCreated":"1568043768","dateModified":"1568043768"},{"type":"comment","comment":"I see `--force` as a general \"I know what I'm doing, forget your checks\"  instruction.\nIf it's not, then all the variations would need their own `--force-heads`, `--force-bookmarks`, `--force-*`.\nMay be a bit much.\n\nAs for this being configurable?\nI, personally, don't see a lot of value in the current behavior.\nThere may be a use case, but the default behavior, useful for most users, would be to check it, I think.\n","author":"idlsoft","id":"99537","dateCreated":"1567523430","dateModified":"1567523430"},{"type":"comment","comment":"(just interested in this change, I don't have any power to actually accept it)\n\nInteresting. I've thought of `hg push -B` as forcing the move of the bookmark, and `hg push -r` as not forcing a bookmark move, as that's how they behave (well, mostly).\nI don't know if this is a bug: the intended behavior of `push -B` is not explicitly documented, but it at least appears to be consistent with `hg pull -B`.\nBut if it wasn't for compatibility, the behavior you're trying to implement looks superior: it gives the ability to ensure that a push either moves a bookmark forward or fails, which is clearly useful. We have an extension that makes `hg push -r BOOKMARK` have such a behavior, but the fewer extensions the better.\n\nBut given compatibility constraints, this behavior probably needs to be gated by a config option.\n\nAbout more technical aspects, I have a couple of remarks:\n- the change of behavior would be clearer in the diff if you added the test in a first change, and updated the code in a second change\n- the check should probably live in some combination of `exchange.{_processcompared,_pushb2checkbookmarks}` instead (that's where the \"move forward\" logic for push is right now)\n- using `hg push -f` to overwrite the remote bookmark is not great, because -f forces several completely unrelated things (new heads, removes race checks about bookmarks, something about obsolescence markers and something about phases). No one wants to bypass all these at once. Dedicated force flags seems better, perhaps `hg push --force-bookmark BOOKMARK`, to replicate the current behavior of `hg push -B BOOKMARK`.","author":"valentin.gatienbaron","id":"99521","dateCreated":"1567374841","dateModified":"1567374841"},{"type":"comment","comment":"This is a potential fix for https:\/\/bz.mercurial-scm.org\/show_bug.cgi?id=6193\nThe actual validation is in `bundle2.handlebookmark`.\nThe rest of the changes are there to pass the `force` parameter.\nI've also made `force` available to hooks. That way one can validate who can and cannot use `--force` on a shared repo.","author":"idlsoft","id":"99421","dateCreated":"1567188167","dateModified":"1567188167"},{"type":"update","diffId":"16341","author":"idlsoft","id":"99417","dateCreated":"1567187687","dateModified":"1567187687"}],"dateCreated":"1567187687","dateModified":"1568441725","status":"Needs Review"},{"id":"6847","callsign":"HG","title":"dont-accept-this: this is for reference in D6776","author":"valentin.gatienbaron","summary":"","testPlan":"","lineCount":"108","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"16527","author":"valentin.gatienbaron","id":"100482","dateCreated":"1568348707","dateModified":"1568348707"}],"dateCreated":"1568348707","dateModified":"1568349208","status":"Needs Review"},{"id":"6845","callsign":"HG","title":"pushkeys: introduce a server.bookmarks-pushkey-reject option to complement D6776","author":"idlsoft","summary":"","testPlan":"","lineCount":"30","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"16523","author":"idlsoft","id":"100458","dateCreated":"1568306882","dateModified":"1568306882"}],"dateCreated":"1568306882","dateModified":"1568306882","status":"Needs Review"},{"id":"4664","callsign":"HG","title":"mergecommit: add a new extension to merge in-memory and create a commit","author":"pulkit","summary":"This patch adds a new mergecommit command which is very useful for workflows\nwhere there is automated merging involved. This patch uses existing in-memory\nmerge API to merge in-memory and create a commit.\n\nI was thinking about --commit flag to merge command, but then we need other\ncommitopts too, so created a new command.\n\nThis patches filemerge.py to not raise IMMConflictsError on first conflict\nbecause we need a list of conflicts in the end.","testPlan":"","lineCount":"345","dependsOn":[],"reviewers":[],"ccs":["durin42","marcink","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D4664#100404, @durin42 wrote:\n> Neat. I assume you normally check these out later?\n\nFor now yes. The plan was to make `hg cat` support cat-ing maultiple files preventing to checkout.","author":"pulkit","id":"100440","dateCreated":"1568267806","dateModified":"1568267806"},{"type":"comment","comment":"Neat. I assume you normally check these out later?","author":"durin42","id":"100404","dateCreated":"1568215778","dateModified":"1568215778"},{"type":"comment","comment":"I don't aim for this to get reviewed and pushed. This is here right now for sharing. We are using this extension internally for months now and has shown good results.","author":"pulkit","id":"87922","dateCreated":"1551193372","dateModified":"1551193372"},{"type":"update","diffId":"14248","author":"pulkit","id":"87921","dateCreated":"1551192772","dateModified":"1551192772"},{"type":"comment","comment":"Thinking about this more, I think I have not done a good job writing commit message. The extension is very useful when you have automation around merges or you do merges because of the following reasons:\n\n  * The merge is done in-memory and is very fast if you disable the path conflicts auditing\n  * You can specify a merge destination using --dest flag, which means you don't need to update to merge. You can merge two changesets from anywhere\n  * You can parallelize multiple merges\n  * This can be used as --dry-run for hg merge as it can tell whether a merge will result in conflicts or not without applying anything\n\nThat said, I am not sure if this looks like a good candidate for in-core extension. However, we want to share the work we have done on speeding up merge internally so that it can help other companies which uses merges. So, feel free to pick this up from here if you need this. :)","author":"pulkit","id":"72700","dateCreated":"1538342063","dateModified":"1538342063"},{"type":"update","diffId":"11198","author":"pulkit","id":"70929","dateCreated":"1537361525","dateModified":"1537361525"}],"dateCreated":"1537361525","dateModified":"1568267806","status":"Needs Review"},{"id":"6825","callsign":"HG","title":"contrib: start building a library for simple hooks","author":"joerg.sonnenberger","summary":"Many workflows depend on hooks to enforce certain policies, e.g. to\nprevent forced pushes. The Mercurial Guide includes some cases and\nGoogle can help finding others, but it can save users a lot of time\nif hg itself has a couple of examples for further customization.","testPlan":"","lineCount":"77","dependsOn":[],"reviewers":[],"ccs":["durin42","indygreg","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D6825#100146, @durin42 wrote:\n> I like where this is going, but I wonder if these specific hooks can be written without being in-process Python hooks. Reason being that Python hooks use the unstable internals of hg and are semi-discouraged if they're avoidable.\n\nThis is exactly why I think the Python hooks should be part of the modules shipped as part of the core distribution :)","author":"indygreg","id":"100300","dateCreated":"1568080440","dateModified":"1568080440"},{"type":"comment","comment":"I like where this is going, but I wonder if these specific hooks can be written without being in-process Python hooks. Reason being that Python hooks use the unstable internals of hg and are semi-discouraged if they're avoidable.\n\nThoughts?\n\nIf you do stick with in-process for this, I definitely want a test included so we don't regress our own examples. ;)","author":"durin42","id":"100146","dateCreated":"1568042949","dateModified":"1568042949"},{"type":"comment","comment":"I think we should go a step further and have some built-in hooks in Mercurial itself, like we do extensions. A good first implementation would be to define those hooks somewhere where they can be imported, add tests like they are standalone hooks. As a follow-up (read: slightly more work), we can define a new config syntax for using these hooks. e.g. `builtin:reject_new_heads`.\n\nWhat do others think?","author":"indygreg","id":"100084","dateCreated":"1567877230","dateModified":"1567877230"},{"type":"update","diffId":"16431","author":"joerg.sonnenberger","id":"99986","dateCreated":"1567873920","dateModified":"1567873920"},{"type":"comment","comment":"Thanks a lot for putting efforts here. I am +1 on this. I haven't looked at the code though, will try to review if no one else beats me to it.","author":"pulkit","id":"99983","dateCreated":"1567873258","dateModified":"1567873258"},{"type":"update","diffId":"16430","author":"joerg.sonnenberger","id":"99977","dateCreated":"1567860653","dateModified":"1567860653"}],"dateCreated":"1567860653","dateModified":"1568080440","status":"Needs Review"},{"id":"6005","callsign":"HG","title":"uncommit: added interactive mode -i(issue6062)","author":"taapas1128","summary":"This adds interactive option to uncommit . Part of this code has been\nimported from evolve from commit hash `da2fdaa3d97c`. The basic\nfunctionality of the code lies in `_interactiveuncommit()`. It first uncommits\neverything then performs action similar to interactive amend .\n\nThe current implementation is not perfect and might result in `Hunk Failed`.\nat some point.","testPlan":"","lineCount":"1094","dependsOn":[],"reviewers":[],"ccs":["ryanmce","spectral","pulkit","martinvonz","mercurial-devel"],"actions":[{"type":"update","diffId":"14558","author":"taapas1128","id":"89708","dateCreated":"1553000469","dateModified":"1553000469"},{"type":"inline","comment":"uncommitting instead of recording","replyTo":null,"isNewFile":"1","line":"1053","lineLength":"0","path":"mercurial\/patch.py","diffId":"14547","author":"pulkit","id":"89706","dateCreated":"1552995408","dateModified":"1552995408"},{"type":"inline","comment":"here also, uncommit instead of record.","replyTo":null,"isNewFile":"1","line":"1052","lineLength":"0","path":"mercurial\/patch.py","diffId":"14547","author":"pulkit","id":"89705","dateCreated":"1552995408","dateModified":"1552995408"},{"type":"inline","comment":"`uncommit` instead of `record` here too.","replyTo":null,"isNewFile":"1","line":"1050","lineLength":"0","path":"mercurial\/patch.py","diffId":"14547","author":"pulkit","id":"89704","dateCreated":"1552995408","dateModified":"1552995408"},{"type":"inline","comment":"this should be `uncommit this change` right?","replyTo":null,"isNewFile":"1","line":"1046","lineLength":"0","path":"mercurial\/patch.py","diffId":"14547","author":"pulkit","id":"89703","dateCreated":"1552995408","dateModified":"1552995408"},{"type":"update","diffId":"14547","author":"taapas1128","id":"89637","dateCreated":"1552934250","dateModified":"1552934250"},{"type":"update","diffId":"14546","author":"taapas1128","id":"89634","dateCreated":"1552932468","dateModified":"1552932468"},{"type":"inline","comment":"This operation thing can be used to show `select hunks to uncommit` message.","replyTo":null,"isNewFile":"1","line":"258","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14521","author":"pulkit","id":"89633","dateCreated":"1552929443","dateModified":"1552929443"},{"type":"inline","comment":"okay sure.","replyTo":"89514","isNewFile":"1","line":"253","lineLength":"1","path":"hgext\/uncommit.py","diffId":"14464","author":"taapas1128","id":"89521","dateCreated":"1552751527","dateModified":"1552751527"},{"type":"inline","comment":"yes I applied your patch and I m trying to figure out what is going wrong . I will send a fix soon.","replyTo":"89515","isNewFile":"1","line":"241","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14493","author":"taapas1128","id":"89520","dateCreated":"1552751527","dateModified":"1552751527"},{"type":"inline","comment":"Yes, please try to fix it. Did you try?","replyTo":"89507","isNewFile":"1","line":"241","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14493","author":"martinvonz","id":"89515","dateCreated":"1552745888","dateModified":"1552745888"},{"type":"inline","comment":"I suggested addressing the todo now instead of waiting.","replyTo":"89508","isNewFile":"1","line":"253","lineLength":"1","path":"hgext\/uncommit.py","diffId":"14464","author":"martinvonz","id":"89514","dateCreated":"1552745888","dateModified":"1552745888"},{"type":"inline","comment":"I am a little puzzled about what is to be done here . the TODO states that operations are currently not wrapped . how do you want me to continue ?","replyTo":"89463","isNewFile":"1","line":"253","lineLength":"1","path":"hgext\/uncommit.py","diffId":"14464","author":"taapas1128","id":"89508","dateCreated":"1552731138","dateModified":"1552731138"},{"type":"inline","comment":"do you want me to remove the temporary commit part in this patch or a follow up of this because that will require fixing it up for added files.","replyTo":"89468","isNewFile":"1","line":"241","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14493","author":"taapas1128","id":"89507","dateCreated":"1552731138","dateModified":"1552731138"},{"type":"update","diffId":"14521","author":"taapas1128","id":"89504","dateCreated":"1552728980","dateModified":"1552728980"},{"type":"update","diffId":"14520","author":"taapas1128","id":"89501","dateCreated":"1552728260","dateModified":"1552728260"},{"type":"inline","comment":"Do we need to create the temporary commit? I found it hard to reason about (the temporary commit contains the changes that should be removed, which confused me) and we should ideally not leave that commit in the repo. I tried to rewrite it to not write the temporary commit. You can see my patch at http:\/\/paste.debian.net\/1073278\/. As you can see in the changed test case there, it doesn't work with added files. I don't know if that's because of the crecord bug that you mention on line 254 of this version or something else. Hopefully the patch is still a good start and maybe you can fix that bug. It would be great if you can even fix it in crecord (if that's where it is), so all users of crecord can benefit.","replyTo":null,"isNewFile":"1","line":"241","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14493","author":"martinvonz","id":"89468","dateCreated":"1552678817","dateModified":"1552678817"},{"type":"inline","comment":"`amend_source` includes the full hash. I think it's better to do the same here.","replyTo":null,"isNewFile":"1","line":"265","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14493","author":"martinvonz","id":"89467","dateCreated":"1552678817","dateModified":"1552678817"},{"type":"inline","comment":"`extras` is a confusing name for a node (it sounds too much like it's a changeset extras dict). I suggest renaming it to `oldnode`.","replyTo":null,"isNewFile":"1","line":"270","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14493","author":"martinvonz","id":"89466","dateCreated":"1552678817","dateModified":"1552678817"},{"type":"inline","comment":"I think it's still unclear if we even want to make that change (I think I would prefer it, but I'd like to hear from others), so let's leave it as is for now.","replyTo":"89315","isNewFile":"1","line":"110","lineLength":"0","path":"tests\/test-uncommit-interactive.t","diffId":"14464","author":"martinvonz","id":"89465","dateCreated":"1552678817","dateModified":"1552678817"},{"type":"inline","comment":"nit: remove the leading space here and in other docstrings for consistency (we seem to have about 60 instances with a leading space and 2900 without)","replyTo":null,"isNewFile":"1","line":"216","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14493","author":"martinvonz","id":"89464","dateCreated":"1552678817","dateModified":"1552678817"},{"type":"inline","comment":"It doesn't look done to me...","replyTo":"89232","isNewFile":"1","line":"253","lineLength":"1","path":"hgext\/uncommit.py","diffId":"14464","author":"martinvonz","id":"89463","dateCreated":"1552678817","dateModified":"1552678817"},{"type":"inline","comment":"I didn't mean \"use `cleanupnodes()` too\", I meant \"here too\" :) I.e., use `cleanupnodes()` here just like we do elsewhere in this file, not in addition to using `createmarkers()`. So just delete the `createmarkers()` call.","replyTo":"89227","isNewFile":"1","line":"235","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14464","author":"martinvonz","id":"89462","dateCreated":"1552678817","dateModified":"1552678817"},{"type":"inline","comment":"It looks like this is only useful in the non-interactive case. It's generally preferred to avoid unnecessary work, both because it's wasting computer resources (not really an issue here) and because it makes it clearer how the code works. In this case, it will make it clear that the `--keep` option does not matter with `--interactive`. However, it seems reasonable for `--keep` (and the corresponding config option) to be respected with `--interactive`. Maybe you should pass `keep` it into `_interactiveuncommit()` and use it there? I'd be fine with just leaving a TODO about that (and leave the `keepcommit` code here).","replyTo":null,"isNewFile":"1","line":"185","lineLength":"5","path":"hgext\/uncommit.py","diffId":"14493","author":"martinvonz","id":"89461","dateCreated":"1552678817","dateModified":"1552678817"},{"type":"comment","comment":"Can you wrap the commit message to 80 columns? I didn't find anything on https:\/\/www.mercurial-scm.org\/wiki\/ContributingChanges about it, but that's how almost everyone else does it.","author":"martinvonz","id":"89460","dateCreated":"1552678817","dateModified":"1552678817"},{"type":"inline","comment":"Can I work on this as a part as a follow up ? or should i make amends in this patch . ","replyTo":"89228","isNewFile":"1","line":"110","lineLength":"0","path":"tests\/test-uncommit-interactive.t","diffId":"14464","author":"taapas1128","id":"89315","dateCreated":"1552579696","dateModified":"1552579696"},{"type":"comment","comment":"@martinvonz I have made the necessary modifications and updated the description.","author":"taapas1128","id":"89314","dateCreated":"1552579696","dateModified":"1552579696"},{"type":"update","diffId":"14493","author":"taapas1128","id":"89304","dateCreated":"1552574286","dateModified":"1552574286"},{"type":"inline","comment":"nit: indent by 4 spaces","replyTo":null,"isNewFile":"1","line":"230","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14464","author":"martinvonz","id":"89234","dateCreated":"1552497194","dateModified":"1552497194"},{"type":"inline","comment":"nit: indent by 4 spaces","replyTo":null,"isNewFile":"1","line":"261","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14464","author":"martinvonz","id":"89233","dateCreated":"1552497194","dateModified":"1552497194"},{"type":"inline","comment":"I think it's fine to do it directly there, without wrapping. We're shipping this extension with core, so it shouldn't be a problem. It will have no effect unless you've enabled the extension, as far as I can tell.","replyTo":null,"isNewFile":"1","line":"253","lineLength":"1","path":"hgext\/uncommit.py","diffId":"14464","author":"martinvonz","id":"89232","dateCreated":"1552497194","dateModified":"1552497194"},{"type":"inline","comment":"nit: No need to say that it's a function, and the \"for interactively uncommiting a commit\" seems pretty obvious from the name. Just start with \"Makes a temporary commit...\" instead.","replyTo":null,"isNewFile":"1","line":"214","lineLength":"1","path":"hgext\/uncommit.py","diffId":"14464","author":"martinvonz","id":"89231","dateCreated":"1552497194","dateModified":"1552497194"},{"type":"inline","comment":"Same nit here: No need to say that it's a function, just start with \"Applies the patch...\"","replyTo":null,"isNewFile":"1","line":"270","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14464","author":"martinvonz","id":"89230","dateCreated":"1552497194","dateModified":"1552497194"},{"type":"inline","comment":"Add \" (EXPERIMENTAL)\" to the end of this description since the feature doesn't work with curses. That way it won't be visible when the user runs `hg help uncommit`.","replyTo":null,"isNewFile":"1","line":"148","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14464","author":"martinvonz","id":"89229","dateCreated":"1552497194","dateModified":"1552497194"},{"type":"inline","comment":"I think at least @spectral and @ryanmce had previously suggested that `hg revert -i` should ask you what pieces to keep, not what to discard. Your patch reminded me of that discussion, so I sent D6125. I'm curious to hear what others think about `hg uncommit -i`. Should it ask you what to discard or what to keep? I can see arguments both ways.\n\nPerhaps the strongest argument in favor if showing what to keep is that it makes uncommitting part of a line *much* easier. Let's say you changed a line from \"a\" to \"c\" in the commit and you meant to change it to \"b\" in the commit and leave the change to \"c\" in the working copy. You'd be presented with this:\n```\n-a\n+c\n```\n\nIf what you select is what to keep in the commit, then it seems pretty obvious that you should change that to:\n```\n-a\n+b\n```\n\nIt's much less obvious what to do if you select what to discard.\n\nI think it would also make it easier to implement this feature if the user selected what to keep (we would create a commit based on that and then move the dirstate there).","replyTo":null,"isNewFile":"1","line":"110","lineLength":"0","path":"tests\/test-uncommit-interactive.t","diffId":"14464","author":"martinvonz","id":"89228","dateCreated":"1552497194","dateModified":"1552497194"},{"type":"inline","comment":"Should probably use `scmutil.cleanupnodes()` here too?","replyTo":null,"isNewFile":"1","line":"235","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14464","author":"martinvonz","id":"89227","dateCreated":"1552497194","dateModified":"1552497194"},{"type":"inline","comment":"I think you're relying on this empty commit to not be saved, but I think it will be if the user has set `experiemtal.uncommit.keep` (or if they passed `--keep`). It seems better to not even attempt to create it if we don't want it.","replyTo":null,"isNewFile":"1","line":"191","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14464","author":"martinvonz","id":"89226","dateCreated":"1552497194","dateModified":"1552497194"},{"type":"comment","comment":">>! In D6005#89211, @pulkit wrote:\n>>>! In D6005#89182, @martinvonz wrote:\n>> Can you update the commit message to explain how this works? I think I saw somewhere else that it first uncommits everything and then does an interactive amend. Is that correct?\n> \n> Yes, this is correct.\n>> \n>> Also, I just tried to use this feature and it failed (depending on how many lines were added). I added two lines to a file, committed, then ran `hg uncommit -i` and selected the first line. Then I got this:\n>> \n>> ```\n>> starting interactive selection\n>> patching file z\n>> Hunk #1 succeeded at 2 with fuzz 2 (offset -1 lines).\n>> ```\n> \n> Yes this is also expected with the current implementation. Sometimes uncommit can fail and it will report `Hunk Failed` like this. There is definitely lot to improve in this implementation and I am fine with having this in core first.\n\nThat definitely should be in the commit message.","author":"martinvonz","id":"89225","dateCreated":"1552497194","dateModified":"1552497194"},{"type":"comment","comment":">>! In D6005#89182, @martinvonz wrote:\n> Can you update the commit message to explain how this works? I think I saw somewhere else that it first uncommits everything and then does an interactive amend. Is that correct?\n\nYes, this is correct.\n> \n> Also, I just tried to use this feature and it failed (depending on how many lines were added). I added two lines to a file, committed, then ran `hg uncommit -i` and selected the first line. Then I got this:\n> \n> ```\n> starting interactive selection\n> patching file z\n> Hunk #1 succeeded at 2 with fuzz 2 (offset -1 lines).\n> ```\n\nYes this is also expected with the current implementation. Sometimes uncommit can fail and it will report `Hunk Failed` like this. There is definitely lot to improve in this implementation and I am fine with having this in core first.\n\n","author":"pulkit","id":"89211","dateCreated":"1552465939","dateModified":"1552465939"},{"type":"comment","comment":"I suppose no .. because in the very initial patch I combined `hg uncommit` with `hg commit -i`(as was stated in the bug description(https:\/\/bz.mercurial-scm.org\/show_bug.cgi?id=6062)) . But later on I was asked to import it from `evolve` . The basic functionality lies in `_interactiveuncommit()` and the other two functions are imported as dependencies to that. ","author":"taapas1128","id":"89183","dateCreated":"1552416483","dateModified":"1552416483"},{"type":"comment","comment":"Can you update the commit message to explain how this works? I think I saw somewhere else that it first uncommits everything and then does an interactive amend. Is that correct?\n\nAlso, I just tried to use this feature and it failed (depending on how many lines were added). I added two lines to a file, committed, then ran `hg uncommit -i` and selected the first line. Then I got this:\n\n```\nstarting interactive selection\npatching file z\nHunk #1 succeeded at 2 with fuzz 2 (offset -1 lines).\n```\n","author":"martinvonz","id":"89182","dateCreated":"1552414856","dateModified":"1552414856"},{"type":"update","diffId":"14464","author":"taapas1128","id":"89100","dateCreated":"1552324675","dateModified":"1552324675"},{"type":"update","diffId":"14461","author":"taapas1128","id":"89072","dateCreated":"1552319396","dateModified":"1552319396"},{"type":"inline","comment":"okay sending a separate patch right away","replyTo":"88738","isNewFile":"1","line":"399","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14191","author":"taapas1128","id":"89065","dateCreated":"1552318795","dateModified":"1552318795"},{"type":"inline","comment":"Yes, please do. Then we can consider while reviewing that patch if we even need to pass the matcher. It's better to have that discussion separate from this patch.","replyTo":"88737","isNewFile":"1","line":"399","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14191","author":"martinvonz","id":"88738","dateCreated":"1552066880","dateModified":"1552066880"},{"type":"inline","comment":"@martinvonz this part of the patch too (`323,329,366`) has no relation with interactive uncommit but it makes `match` optional for `unamend`. Should I remove is and send it as a seperate patch too ?","replyTo":"87640","isNewFile":"1","line":"399","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14191","author":"taapas1128","id":"88737","dateCreated":"1552066781","dateModified":"1552066781"},{"type":"update","diffId":"14399","author":"taapas1128","id":"88735","dateCreated":"1552058869","dateModified":"1552058869"},{"type":"inline","comment":"Okay . Then I am reverting this back to what it was.","replyTo":"88733","isNewFile":"1","line":"109","lineLength":"1","path":"hgext\/uncommit.py","diffId":"14386","author":"taapas1128","id":"88734","dateCreated":"1552058644","dateModified":"1552058644"},{"type":"inline","comment":"So you're fixing something that was missed in an old commit? Please put that fix in a separate patch.","replyTo":"88732","isNewFile":"1","line":"109","lineLength":"1","path":"hgext\/uncommit.py","diffId":"14386","author":"martinvonz","id":"88733","dateCreated":"1552057393","dateModified":"1552057393"},{"type":"inline","comment":"In line number `115` a matcher is used . This is between oldctx and netctx now . In D971 a the matcher was removed so the comment was altered . But whenever the matcher was reused the comment wasn't changed .","replyTo":"88643","isNewFile":"1","line":"109","lineLength":"1","path":"hgext\/uncommit.py","diffId":"14386","author":"taapas1128","id":"88732","dateCreated":"1552028753","dateModified":"1552028753"},{"type":"inline","comment":"> It is the part of _uncommitdirstate() that has been left behind. okay I am not changing that\n\nAre you referring to D971? I see that your change kind of backs out that change. But why?","replyTo":"88641","isNewFile":"1","line":"109","lineLength":"1","path":"hgext\/uncommit.py","diffId":"14386","author":"martinvonz","id":"88643","dateCreated":"1551992859","dateModified":"1551992859"},{"type":"inline","comment":"It is the  part of _uncommitdirstate() that has been left behind. okay I am not changing that","replyTo":"88636","isNewFile":"1","line":"109","lineLength":"1","path":"hgext\/uncommit.py","diffId":"14386","author":"taapas1128","id":"88641","dateCreated":"1551992528","dateModified":"1551992528"},{"type":"update","diffId":"14389","author":"taapas1128","id":"88638","dateCreated":"1551992416","dateModified":"1551992416"},{"type":"inline","comment":"Similar existing flags and their descriptions:\n\ncommit: \"use interactive mode\"\namend: \"use interactive mode\"\nforget: \"use interactive mode\"\nrevert: \"interactively select the changes\"\nabsorb: \"interactively select which chunks to apply\"\nshelve: \"interactive mode, only works while creating a shelve\"\n\nI'd prefer to be consistent with one of those. I personally think revert's and absorb's versions are clearest.","replyTo":null,"isNewFile":"1","line":"148","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14388","author":"martinvonz","id":"88637","dateCreated":"1551989808","dateModified":"1551989808"},{"type":"inline","comment":"I don't follow the \"not containing changed files matched by match\" part. It *only* fixes the parts matched by the matches, right? Also, I think the matcher is just an optimization -- it would be incorrect, I think, to pass a matcher that doesn't match all the changes between oldctx and newctx. I'd just leave the comment untouched for now. We may even want to remove the matcher argument, but we can do that in a separate patch, if at all.","replyTo":null,"isNewFile":"1","line":"109","lineLength":"1","path":"hgext\/uncommit.py","diffId":"14386","author":"martinvonz","id":"88636","dateCreated":"1551989808","dateModified":"1551989808"},{"type":"inline","comment":"I preferred the old wording where it said \"newctx\" instead of \"a copy of oldctx\".","replyTo":null,"isNewFile":"1","line":"109","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14386","author":"martinvonz","id":"88635","dateCreated":"1551989808","dateModified":"1551989808"},{"type":"inline","comment":"No need to pass the `interactive` flag here, right?","replyTo":null,"isNewFile":"1","line":"107","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14386","author":"martinvonz","id":"88634","dateCreated":"1551989808","dateModified":"1551989808"},{"type":"comment","comment":"Here are some little comments to start with. I haven't even started reviewing the three new functions, but I need to take a break and work on other things a bit now.","author":"martinvonz","id":"88633","dateCreated":"1551989808","dateModified":"1551989808"},{"type":"update","diffId":"14388","author":"taapas1128","id":"88631","dateCreated":"1551989040","dateModified":"1551989040"},{"type":"comment","comment":"@martinvonz cleaned it up . ","author":"taapas1128","id":"88629","dateCreated":"1551988873","dateModified":"1551988873"},{"type":"update","diffId":"14387","author":"taapas1128","id":"88628","dateCreated":"1551988760","dateModified":"1551988760"},{"type":"update","diffId":"14386","author":"taapas1128","id":"88627","dateCreated":"1551988403","dateModified":"1551988403"},{"type":"comment","comment":"As I said a while ago on IRC, it feels like `_fixdirstate()` should not need an `interactive` flag, and it should not even need to be specifically for uncommit. It feels like it should work the same for any case where we move to a different commit without changing the working copy, such as uncommit, unamend, amend, fix (though we may want optimized code paths for some of them). So I took this patch and tried the most naive attempt at unifying the interactive version with the non-interactive version, namely to just drop the code for the interactive path (see patch below). Surprisingly, all tests pass :) So maybe you can just apply the below patch and clean it up (drop the `if True`), or maybe you need to add tests.\n\n```\ndiff --git a\/hgext\/uncommit.py b\/hgext\/uncommit.py\n--- a\/hgext\/uncommit.py\n+++ b\/hgext\/uncommit.py\n@@ -109,59 +109,10 @@ def _fixdirstate(repo, oldctx, newctx, m\n     oldctx to a copy of oldctx not containing changed files matched by\n     match.\n     \"\"\"\n-    ctx = repo['.']\n     ds = repo.dirstate\n     ds.setparents(newctx.node(), node.nullid)\n     copies = dict(ds.copies())\n-    if interactive:\n-        # In interactive cases, we will find the status between oldctx and ctx\n-        # and considering only the files which are changed between oldctx and\n-        # ctx, and the status of what changed between oldctx and ctx will help\n-        # us in defining the exact behavior\n-        s = oldctx.status(ctx, match=match)\n-        for f in s.modified:\n-            # These are files which are modified between oldctx and ctx which\n-            # contains two cases: 1) Were modified in oldctx and some\n-            # modifications are uncommitted\n-            # 2) Were added in oldctx but some part is uncommitted (this cannot\n-            # contain the case when added files are uncommitted completely as\n-            # that will result in status as removed not modified.)\n-            # Also any modifications to a removed file will result the status as\n-            # added, so we have only two cases. So in either of the cases, the\n-            # resulting status can be modified or clean.\n-            if ds[f] == 'r':\n-                # But the file is removed in the working directory, leaving that\n-                # as removed\n-                continue\n-            ds.normallookup(f)\n-\n-        for f in s.added:\n-            # These are the files which are added between oldctx and ctx(new\n-            # one), which means the files which were removed in oldctx\n-            # but uncommitted completely while making the ctx\n-            # This file should be marked as removed if the working directory\n-            # does not adds it back. If it's adds it back, we do a normallookup.\n-            # The file can't be removed in working directory, because it was\n-            # removed in oldctx\n-            if ds[f] == 'a':\n-                ds.normallookup(f)\n-                continue\n-            ds.remove(f)\n-\n-        for f in s.removed:\n-            # These are files which are removed between oldctx and ctx, which\n-            # means the files which were added in oldctx and were completely\n-            # uncommitted in ctx. If a added file is partially uncommitted, that\n-            # would have resulted in modified status, not removed.\n-            # So a file added in a commit, and uncommitting that addition must\n-            # result in file being stated as unknown.\n-            if ds[f] == 'r':\n-                # The working directory say it's removed, so lets make the file\n-                # unknown\n-                ds.drop(f)\n-                continue\n-            ds.add(f)\n-    else:\n+    if True:\n         s = newctx.status(oldctx, match=match)\n         for f in s.modified:\n             if ds[f] == 'r':\n```\n","author":"martinvonz","id":"88625","dateCreated":"1551985450","dateModified":"1551985450"},{"type":"update","diffId":"14385","author":"taapas1128","id":"88624","dateCreated":"1551983082","dateModified":"1551983082"},{"type":"comment","comment":"@pulkit Thanks for pointing that out . That was extremely silly of me . I have corrected that . Is there anything else to be changed ?","author":"taapas1128","id":"88055","dateCreated":"1551390417","dateModified":"1551390417"},{"type":"update","diffId":"14278","author":"taapas1128","id":"88053","dateCreated":"1551390277","dateModified":"1551390277"},{"type":"inline","comment":"I just skimmed through changes and looks like this is missing in the changed version.","replyTo":null,"isNewFile":"0","line":"101","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14193","author":"pulkit","id":"88049","dateCreated":"1551389274","dateModified":"1551389274"},{"type":"comment","comment":"@pulkit I am unable to figure out why the output for `test-unamend.t` is changing . Any hint on that ?","author":"taapas1128","id":"88046","dateCreated":"1551381557","dateModified":"1551381557"},{"type":"comment","comment":"@martinvonz I made the changes you asked . However I am not sure why `test-unamend.t` is changing because when `interactive` is false so it should behave exactly like the previous `_fixdirstate()` functioned . Can you provide some help with this ? I will work further based on your review.","author":"taapas1128","id":"87647","dateCreated":"1550865111","dateModified":"1550865111"},{"type":"update","diffId":"14193","author":"taapas1128","id":"87644","dateCreated":"1550864664","dateModified":"1550864664"},{"type":"update","diffId":"14192","author":"taapas1128","id":"87642","dateCreated":"1550860371","dateModified":"1550860371"},{"type":"inline","comment":"I've been trying to avoid accessing status fields by index because it's not very readable. Can you use the same pattern as below instead (i.e. `s.modifed` etc)?","replyTo":null,"isNewFile":"1","line":"114","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14191","author":"martinvonz","id":"87641","dateCreated":"1550860142","dateModified":"1550860142"},{"type":"inline","comment":"Instead of defining a value here, specify the argument by name when you call the function: `_uncommitdirstate(..., interactive=False)`. But it's probably better to just make `interactive` default to `False` and not pass it here.","replyTo":null,"isNewFile":"1","line":"399","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14191","author":"martinvonz","id":"87640","dateCreated":"1550860142","dateModified":"1550860142"},{"type":"inline","comment":"Keep the match optional instead?","replyTo":null,"isNewFile":"1","line":"400","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14191","author":"martinvonz","id":"87639","dateCreated":"1550860142","dateModified":"1550860142"},{"type":"inline","comment":"I don't think we need to rename it from `_fixdirstate()`, especially since it's used for both uncommit and unamend. (Fix commit message too, of course, if you switch back to the old name.)","replyTo":null,"isNewFile":"1","line":"101","lineLength":"0","path":"hgext\/uncommit.py","diffId":"14191","author":"martinvonz","id":"87638","dateCreated":"1550860142","dateModified":"1550860142"},{"type":"comment","comment":"I haven't reviewed much of it, but here are some initial comments","author":"martinvonz","id":"87637","dateCreated":"1550860142","dateModified":"1550860142"},{"type":"update","diffId":"14191","author":"taapas1128","id":"87630","dateCreated":"1550859507","dateModified":"1550859507"}],"dateCreated":"1550859507","dateModified":"1568048754","status":"Needs Review"},{"id":"6711","callsign":"HG","title":"branchheads: store wdir-dependent caches in wcache (issue6181)","author":"spectral","summary":"Previously, all branch2-* caches were stored in .hg\/cache, which is shared\nacross repos when using `hg share`. This can cause cache thrashing when the\nrepos are accessed concurrently, since some of the caches depend on wdir state\n(which is NOT shared across the repos).\n\nThere's already a cache directory for caches that depend on wdir state, wcache,\nso let's just put the caches there.\n\nThis change does not clean up any existing caches in .hg\/cache that are now\nmoved to the new location, and it does not re-use the caches from that location\nwhen constructing them in the wcache directory. Upgrades to versions of\nMercurial that have this commit will need to regenerate their branchheads once, and\nthis may be an expensive operation.\n\nThe format of these cache files is not changing - forwards\/backwards\ncompatibility remains; if a newer repo (with these in wcache) is accessed by an\nolder hg, the older hg will either see the files that remain in .hg\/cache, and\nupdate them there, or will not see the files at all and will fall back to a\nslower path (and then likely cache them in .hg\/cache). If it's then accessed by\na newer hg, the work done by the older hg is ignored, and the wcache copies are\nbrought up to date.","testPlan":"","lineCount":"54","dependsOn":[],"reviewers":[],"ccs":["marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":"I'm not sure what the current state of this is, but I don't want it lingering in the review queue while I'm not actively working on it. ","author":"spectral","id":"99582","dateCreated":"1567710416","dateModified":"1567710416"},{"type":"plan-changes","author":"spectral","id":"99581","dateCreated":"1567710415","dateModified":"1567710415"},{"type":"comment","comment":">>! In D6711#98318, @spectral wrote:\n>>>! In D6711#98248, @marmoute wrote:\n>> The change looks good to me, However we probably want to introduce a new filter level 'wdir-independent-visible' to ensure we a good branchcache cache in .hg\/cache that most share can use and that will be kept up to date. This also means we need to make sure it is warmed after transaction.\n> \n> I agree such a thing would be useful, and pretty easy to add (just needs to not remove items considered \"pinned\" during computehidden, but I'm a little concerned about the proliferation of these things. I think ideally we'd end up with:\n> \n> visible-hidden > visible > wdir-independent-visible > wdir-independent-served > wdir-independent-served.hidden > immutable > base\n> and\n> served > wdir-independent-served > wdir-independent-served.hidden > immutable > base\n> and\n> served.hidden > wdir-independent-served.hidden > immutable > base\n> \n> I think?\n\nYeah, this makes a lot of them, but the alternative (having non-up-to-date cache in the share-source would a significant issue). In the current situation you fix one bug, reintroducing another. I wonder if we have a \"simpler or saner\" way to introduce these various disctinction. Let me think about it a bit.\n\n> (Not sure if we need a wdir-independent-visible-hidden, I still don't really understand visible-hidden, I just know that updating it actually breaks a Lot of stuff, so I avoided doing so in the first commit in the stack. :))\n\n`visible-hidden` still exclude all the `internal` phase commit that we never want to expose to anyone. (yeah the name is \u2026 confusing)\n\n","author":"marmoute","id":"98502","dateCreated":"1565283682","dateModified":"1565283682"},{"type":"comment","comment":">>! In D6711#98248, @marmoute wrote:\n> The change looks good to me, However we probably want to introduce a new filter level 'wdir-independent-visible' to ensure we a good branchcache cache in .hg\/cache that most share can use and that will be kept up to date. This also means we need to make sure it is warmed after transaction.\n\nI agree such a thing would be useful, and pretty easy to add (just needs to not remove items considered \"pinned\" during computehidden, but I'm a little concerned about the proliferation of these things. I think ideally we'd end up with:\n\nvisible-hidden > visible > wdir-independent-visible > wdir-independent-served > wdir-independent-served.hidden > immutable > base\nand\nserved > wdir-independent-served > wdir-independent-served.hidden > immutable > base\nand\nserved.hidden > wdir-independent-served.hidden > immutable > base\n\nI think?\n\n(Not sure if we need a wdir-independent-visible-hidden, I still don't really understand visible-hidden, I just know that updating it actually breaks a Lot of stuff, so I avoided doing so in the first commit in the stack. :))\n","author":"spectral","id":"98318","dateCreated":"1565053883","dateModified":"1565053883"},{"type":"update","diffId":"16130","author":"spectral","id":"98317","dateCreated":"1565053667","dateModified":"1565053667"},{"type":"comment","comment":"The change looks good to me, However we probably want to introduce a new filter level 'wdir-independent-visible' to ensure we a good branchcache cache in .hg\/cache that most share can use and that will be kept up to date. This also means we need to make sure it is warmed after transaction.","author":"marmoute","id":"98248","dateCreated":"1564832941","dateModified":"1564832941"},{"type":"update","diffId":"16116","author":"spectral","id":"98218","dateCreated":"1564795614","dateModified":"1564795614"}],"dateCreated":"1564795614","dateModified":"1567710416","status":"Changes Planned"},{"id":"6718","callsign":"HG","title":"repository: suppress typing errors on functions without arguments","author":"indygreg","summary":"zope.interface uses class magic to define interfaces. Mypy doesn't\nlike the methods without arguments and raises a warning for the\ndozens of them in repository.py.\n\nThis commit adds type annotation comments to silence the error.\nTBH I'm not sure if this is the best way to do this. But it does\nget the job done. We may have to revisit once we add proper type\nannotations to this file. For now, it makes mypy's output far\nless verbose.","testPlan":"","lineCount":"138","dependsOn":["6717"],"reviewers":["durin42"],"ccs":["pulkit","durin42","mercurial-devel"],"actions":[{"type":"comment","comment":"I tried to queue but `test-check-code.t` and `test-check-commit.t` fails.","author":"pulkit","id":"99059","dateCreated":"1566317949","dateModified":"1566317949"},{"type":"comment","comment":"Seems fine, but probably file a bug against mypy on this.","author":"durin42","id":"98601","dateCreated":"1565810624","dateModified":"1565810624"},{"type":"accept","author":"durin42","id":"98600","dateCreated":"1565810624","dateModified":"1565810624"},{"type":"update","diffId":"16127","author":"indygreg","id":"98297","dateCreated":"1564948380","dateModified":"1564948380"}],"dateCreated":"1564948380","dateModified":"1566317949","status":"Needs Review"},{"id":"6739","callsign":"HG","title":"unshelve: add abort on using --interactive and --unresolved together","author":"navaneeth.suresh","summary":"It seems not to be a good idea to partially unshelve a mergestate. So,\nlet us abort on using `--interactive` and `--unresolved` together.`","testPlan":"","lineCount":"7","dependsOn":["6738"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"16255","author":"navaneeth.suresh","id":"98897","dateCreated":"1566074375","dateModified":"1566074375"}],"dateCreated":"1566074375","dateModified":"1566074922","status":"Needs Review"},{"id":"6717","callsign":"HG","title":"mypy: add a mypy.ini config file","author":"indygreg","summary":"Static analysis is good. Let's encourage its use by adding\na mypy.ini config file to the repo that has reasonable defaults.\n\nWith this file in place, `mypy` appears to \"just work\" out of\nthe box. It yields a ton of errors and warnings though. But\nit's a start!","testPlan":"","lineCount":"29","dependsOn":[],"reviewers":[],"ccs":["durin42","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"Did you run tests on this patch? IIRC there's a test that'll fail ;)","author":"durin42","id":"98598","dateCreated":"1565810586","dateModified":"1565810586"},{"type":"comment","comment":"I am +1 on this. If I don't hear any objection on it until next week, I will queue it. Thanks for doing this work!","author":"pulkit","id":"98470","dateCreated":"1565216414","dateModified":"1565216414"},{"type":"update","diffId":"16126","author":"indygreg","id":"98291","dateCreated":"1564948379","dateModified":"1564948379"}],"dateCreated":"1564948379","dateModified":"1565810586","status":"Needs Review"},{"id":"6719","callsign":"HG","title":"branchmap: refresh all \"heads\" of the branchmap subsets","author":"spectral","summary":"The comment about 'served' refreshing all the others only applies when served is\nthe head of the branchmap cache subsets. This was already no longer the case\n(and is presumably why served.hidden was added) but the comment was not\nadjusted. Currently, the \"heads\" of the branchmap cache subsets are the three\nspecified here: visible, visible-hidden, served.hidden.","testPlan":"","lineCount":"115","dependsOn":[],"reviewers":["durin42","marmoute"],"ccs":["mercurial-devel"],"actions":[{"type":"inline","comment":"Oops, it seems like `visible-hidden` and `served.hidden` has inconsistent naming. Feel free to fix that along the way.","replyTo":null,"isNewFile":"1","line":"28","lineLength":"0","path":"mercurial\/utils\/repoviewutil.py","diffId":"16128","author":"marmoute","id":"98498","dateCreated":"1565282874","dateModified":"1565282874"},{"type":"inline","comment":"We are no longer warming `served` explicitly If `served` and `served.hidden` are different this will be an issue (since `served` is much more used than `served.hidden`.\n\nI would also add a `XXX` to the comment about `visible-hidden` to encourage people to investigate. This said. The same apply, we would need to warm both `visible` and `visible.hidden` explciitly. ","replyTo":null,"isNewFile":"1","line":"2204","lineLength":"0","path":"mercurial\/localrepo.py","diffId":"16128","author":"marmoute","id":"98497","dateCreated":"1565282874","dateModified":"1565282874"},{"type":"comment","comment":"It seems like we are not warming enought cache with the new scheme.","author":"marmoute","id":"98496","dateCreated":"1565282874","dateModified":"1565282874"},{"type":"reject","author":"marmoute","id":"98495","dateCreated":"1565282873","dateModified":"1565282873"},{"type":"comment","comment":"Adding marmoute as explicit reviewer.","author":"spectral","id":"98321","dateCreated":"1565053983","dateModified":"1565053983"},{"type":"update","diffId":"16128","author":"spectral","id":"98305","dateCreated":"1565053664","dateModified":"1565053664"}],"dateCreated":"1565053664","dateModified":"1565282874","status":"Needs Revision"},{"id":"6697","callsign":"HG","title":"cmdutil: add allowunfinished to prevent checkunfinished() on docommit()","author":"navaneeth.suresh","summary":"`cmdutil.dorecord()` has a `checkunfinished()` function call. We might not\nwant to do that on certain occasions. For example, `unshelve --continue`\non interactive mode is trying to create a commit during an existing\nunfinished state.\n\nWe are now allowing that case using an option `interactive-unshelve`.\nHowever, there should be a general way to do that. This patch adds\na `allowunfinished` optional argument to the `cmdutil.dorecord()`\nfunction and make unshelve to migrate to this argument by removing\nthe `interactive-unshelve` option.","testPlan":"","lineCount":"12","dependsOn":[],"reviewers":["pulkit"],"ccs":["pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"The test still fails.","author":"pulkit","id":"98472","dateCreated":"1565216456","dateModified":"1565216456"},{"type":"reject","author":"pulkit","id":"98471","dateCreated":"1565216456","dateModified":"1565216456"},{"type":"update","diffId":"16110","author":"navaneeth.suresh","id":"98181","dateCreated":"1564733792","dateModified":"1564733792"},{"type":"comment","comment":">>! In D6697#98061, @pulkit wrote:\n> `test-commit-interactive.t` and some other tests fail for me with this, can you have a look?\n\nDoing that right away!","author":"navaneeth.suresh","id":"98093","dateCreated":"1564414216","dateModified":"1564414216"},{"type":"comment","comment":"`test-commit-interactive.t` and some other tests fail for me with this, can you have a look?","author":"pulkit","id":"98061","dateCreated":"1564394696","dateModified":"1564394696"},{"type":"comment","comment":"> cmdutil: add allowunfinished to prevent checkunfinished() on docommit()\n\ns\/docommit\/dorecord\/ in flight","author":"pulkit","id":"98051","dateCreated":"1564393296","dateModified":"1564393296"},{"type":"accept","author":"pulkit","id":"98050","dateCreated":"1564393296","dateModified":"1564393296"},{"type":"update","diffId":"16073","author":"navaneeth.suresh","id":"98000","dateCreated":"1564146326","dateModified":"1564146326"},{"type":"inline","comment":"I thought of splitting into two patches. Will be amending the changes soon in this patch itself.","replyTo":"97997","isNewFile":"1","line":"274","lineLength":"0","path":"mercurial\/cmdutil.py","diffId":"16072","author":"navaneeth.suresh","id":"97999","dateCreated":"1564146169","dateModified":"1564146169"},{"type":"inline","comment":"Why not get rid of `interactive-shelve` passed by unshelve and make that pass `allowunfinished=True` to dorecord?","replyTo":null,"isNewFile":"1","line":"274","lineLength":"0","path":"mercurial\/cmdutil.py","diffId":"16072","author":"pulkit","id":"97997","dateCreated":"1564146006","dateModified":"1564146006"},{"type":"update","diffId":"16072","author":"navaneeth.suresh","id":"97991","dateCreated":"1564145500","dateModified":"1564145500"}],"dateCreated":"1564145500","dateModified":"1565216456","status":"Needs Revision"},{"id":"6056","callsign":"HG","title":"patch: stop aborting when add\/rename\/copy files on --interactive (issue5727)","author":"navaneeth.suresh","summary":"issue5727 was reported specifically for mq on using qrefresh. On investigating further,\nI realized that it was a check in `patch.py` that resulting in the abort. I may be wrong.\nOn interactive mode, `gp.mode` was not `None`. I added a check in `_applydiff()` not to\nabort when `gp.mode` is `None` or `ui.interactive` is `True`.","testPlan":"","lineCount":"21","dependsOn":[],"reviewers":[],"ccs":["durin42","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"This patch breaks `test-split.t` - could you take a look?","author":"durin42","id":"94760","dateCreated":"1560357642","dateModified":"1560357642"},{"type":"comment","comment":"Gentle ping for review.","author":"navaneeth.suresh","id":"89905","dateCreated":"1553450928","dateModified":"1553450928"},{"type":"inline","comment":"IIUC, the current scenario is running into `abort: cannot create foo.h: destination already exists` if an empty file has been added. This means that the test case in my previous comment works fine without running into an error. I tested with hg (version 4.9+3-b70b7c585ee9) by adding a file with contents by running one command after another in my command line and got the same output. The interactive UI prompted me with only two queries. For an empty file, it should be only one as there are no changes to record. This might be the case for `qrefresh`. I'm not sure about this though.","replyTo":"89525","isNewFile":"1","line":"570","lineLength":"0","path":"tests\/test-mq-qrefresh.t","diffId":"14492","author":"navaneeth.suresh","id":"89558","dateCreated":"1552798795","dateModified":"1552798795"},{"type":"inline","comment":"I don't see the output which asks for `record this change to foo.h`  here in the test.","replyTo":"89500","isNewFile":"1","line":"570","lineLength":"0","path":"tests\/test-mq-qrefresh.t","diffId":"14492","author":"pulkit","id":"89525","dateCreated":"1552777310","dateModified":"1552777310"},{"type":"inline","comment":"i think that's usual here as the file `foo.h` is empty. i have the following case running successfully with this patch:\n```\n  $ echo foo > foo.h\n  $ hg add foo.h\n  $ hg qrefresh -i --config ui.interactive=true <<EOF\n  > y\n  > y\n  > n\n  > EOF\n  diff --git a\/foo.h b\/foo.h\n  new file mode 100644\n  examine changes to 'foo.h'? [Ynesfdaq?] y\n  \n  @@ -0,0 +1,1 @@\n  +foo\n  record this change to 'foo.h'? [Ynesfdaq?] y\n```","replyTo":"89407","isNewFile":"1","line":"570","lineLength":"0","path":"tests\/test-mq-qrefresh.t","diffId":"14492","author":"navaneeth.suresh","id":"89500","dateCreated":"1552726626","dateModified":"1552726626"},{"type":"inline","comment":"does this prompt ended here? it didn't show changes in 'foo.h'?","replyTo":null,"isNewFile":"1","line":"570","lineLength":"0","path":"tests\/test-mq-qrefresh.t","diffId":"14492","author":"pulkit","id":"89407","dateCreated":"1552657178","dateModified":"1552657178"},{"type":"update","diffId":"14492","author":"navaneeth.suresh","id":"89302","dateCreated":"1552544470","dateModified":"1552544470"},{"type":"update","diffId":"14319","author":"navaneeth.suresh","id":"88269","dateCreated":"1551641057","dateModified":"1551641057"}],"dateCreated":"1551641057","dateModified":"1560357642","status":"Needs Review"},{"id":"6355","callsign":"HG","title":"shelve: add `update --shelve` if shelve extension is loaded","author":"pulkit","summary":"A lot of times, I need to update to some other cset with dirty working\ndirectory. Good number of times, I run `hg shelve` and `hg update` in order.\n\nLet's add --shelve flag to `hg update` which will shelve wdir changes before\nrunning the update.\n\n.. feature::\n\n    `--shelve` flag to `hg update` if shelve extension is enabled. The flag will\n    shelve working directory changes before performing update.","testPlan":"","lineCount":"36","dependsOn":[],"reviewers":["durin42"],"ccs":["durin42","mharbison72","martinvonz","mercurial-devel"],"actions":[{"type":"comment","comment":"I like where this is going, but agree we should add a dirty-subrepos check so this doesn't burn subrepo users.","author":"durin42","id":"94753","dateCreated":"1560356242","dateModified":"1560356242"},{"type":"reject","author":"durin42","id":"94752","dateCreated":"1560356242","dateModified":"1560356242"},{"type":"comment","comment":">>! In D6355#92614, @mharbison72 wrote:\n> Should this abort if subrepos are present, since you can't shelve a subrepo?  No -S is available on `update`, but maybe looking for .hgsub with any contents is good enough?\n\nOn second thought, maybe just check for dirty subrepos so that this isn\u2019t completely incompatible with subrepos.\n","author":"mharbison72","id":"92616","dateCreated":"1557770825","dateModified":"1557770825"},{"type":"comment","comment":"Should this abort if subrepos are present, since you can't shelve a subrepo?  No -S is available on `update`, but maybe looking for .hgsub with any contents is good enough?\n\nI don't have time to play with it right now, but I know updating a dirty repo with dirty subrepos is massively confusing already.","author":"mharbison72","id":"92615","dateCreated":"1557754608","dateModified":"1557754608"},{"type":"inline","comment":"It's not clear that this is related to `--shelve`. Can we instead first check if the working is dirty? Or make this message more explicit. The former seems better if you think users (including you) will want to set `defaults.update=--shelve`.","replyTo":null,"isNewFile":"1","line":"1177","lineLength":"0","path":"tests\/test-shelve.t","diffId":"15045","author":"martinvonz","id":"92439","dateCreated":"1557506428","dateModified":"1557506428"},{"type":"update","diffId":"15045","author":"pulkit","id":"92409","dateCreated":"1557402072","dateModified":"1557402072"}],"dateCreated":"1557402072","dateModified":"1560356243","status":"Needs Revision"},{"id":"6082","callsign":"HG","title":"phabricator: add a `--branch` flag to `hg phabsend`","author":"pulkit","summary":"One of the existing problems with using phabricator for us is that there is no\nway to specify that the revision\/patch\/differential is intended for stable\nbranch.\n\nThis patch adds a new flag `--branch` to `hg phabsend` command. If the\n`--branch` is passed, `hg phabsend` will add a comment to the related\ndifferential saying that `The review is intended for a <branch-name> branch`.\n\nI looked into other API's which we can use or other properties which can be used\nto put the branch info and didn't found anything quite useful.\n\nFuture improvement can be checking the branch of the patch and commenting that\nbranch name.\n\nI am not sure how to add tests for this. I tested this patch while sending this\npatch.","testPlan":"","lineCount":"20","dependsOn":[],"reviewers":[],"ccs":["durin42","indygreg","Kwan","mharbison72","mercurial-devel"],"actions":[{"type":"comment","comment":"FYI: I've updated our phabricator recently, so maybe it's worth revisiting the branch-name-in-phab functionality from this patch?","author":"durin42","id":"94750","dateCreated":"1560355915","dateModified":"1560355915"},{"type":"comment","comment":">>! In D6082#89656, @pulkit wrote:\n>>>! In D6082#88981, @Kwan wrote:\n>>>>! In D6082#88852, @mharbison72 wrote:\n>>>>>! In D6082#88851, @pulkit wrote:\n>>>> @mharbison72 thanks for tips on adding test. Will add tests in next iteration.\n>>>> \n>>>> I found that Differentials do have a branch field, maybe we can use that? https:\/\/secure.phabricator.com\/source\/phabricator\/browse\/master\/src\/applications\/differential\/customfield\/DifferentialBranchField.php\n>>> \n>>> Seems worth a shot.  I don\u2019t know anything about it, but presumably this would be rendered specially in the web UI, like the test plan, etc.  That sounds better than as a follow up comment.  It also seems natural enough that maybe it can be done unconditionally, instead of needing the argument.\n>> \n>> Yeah, it shows in the Diff Detail pane, [like here](https:\/\/phabricator-dev.allizom.org\/D1092?id=1765).  Unfortunately I think it can be only set when using the creatediff endpoint, which is what I had to change my fork to do (though I could be wrong, the conduit docs are too sparse to be sure).\n> \n> Last night I tried different endpoints and looks like creatediff is the only one which can be used to set the branch. I have asked on their discourse https:\/\/discourse.phabricator-community.org\/t\/conduit-api-to-set-branch-of-a-differential\/2521.\n> \n> Talking about creatediff, can it be used instead of createrawdiff? It it's possible can you paste the changes you did your fork, maybe we need the exact same changes.\n\nOh man, yeah sure, let me just commit the WIP and push.  It's a lot of extra code to wrangle the data into creatediff form.  Bear in mind this wasn't exactly ready to have other eyes on it, and it's possible not all the changes are actually necessary (particularly the urlencoding ones, _so_ much fun having [multiple different ways](https:\/\/secure.phabricator.com\/T12447#216803) to submit the same data to Conduit :\/). I also have not downstreamed all my py3 compat changes yet.\nFrankly I thought this amount of extra code probably wouldn't fly for submitting to the official version (and my coding style is probably questionable).\n\nOn the plus side this did let me [successfully submit](https:\/\/phabricator.services.mozilla.com\/D23114?id=76558) binary file changes to mozilla-central.\n\n[In all its \"glory\"](https:\/\/bitbucket.org\/KwanEsq\/phabsend-moz\/commits\/branch\/beta)\n\nI've also started to write up what I've learnt about the API for the wiki there, to document things the official docs are silent on, like what the \"changes\" parameter to the creatediff endpoint is actually supposed to be.  Hopefully that'd help anyone else who wanted to use such APIs in future (or who even wanted to make changes to mine).\n","author":"Kwan","id":"89707","dateCreated":"1552998145","dateModified":"1552998191"},{"type":"comment","comment":">>! In D6082#88981, @Kwan wrote:\n>>>! In D6082#88852, @mharbison72 wrote:\n>>>>! In D6082#88851, @pulkit wrote:\n>>> @mharbison72 thanks for tips on adding test. Will add tests in next iteration.\n>>> \n>>> I found that Differentials do have a branch field, maybe we can use that? https:\/\/secure.phabricator.com\/source\/phabricator\/browse\/master\/src\/applications\/differential\/customfield\/DifferentialBranchField.php\n>> \n>> Seems worth a shot.  I don\u2019t know anything about it, but presumably this would be rendered specially in the web UI, like the test plan, etc.  That sounds better than as a follow up comment.  It also seems natural enough that maybe it can be done unconditionally, instead of needing the argument.\n> \n> Yeah, it shows in the Diff Detail pane, [like here](https:\/\/phabricator-dev.allizom.org\/D1092?id=1765).  Unfortunately I think it can be only set when using the creatediff endpoint, which is what I had to change my fork to do (though I could be wrong, the conduit docs are too sparse to be sure).\n\nLast night I tried different endpoints and looks like creatediff is the only one which can be used to set the branch. I have asked on their discourse https:\/\/discourse.phabricator-community.org\/t\/conduit-api-to-set-branch-of-a-differential\/2521.\n\nTalking about creatediff, can it be used instead of createrawdiff? It it's possible can you paste the changes you did your fork, maybe we need the exact same changes.\n\n>>! In D6082#89250, @indygreg wrote:\n> While there may be a need for an explicit `--branch` argument, should we start by having `hg phabsend` automatically pick up the branch from the changeset? i.e. wouldn't we want branch selection to be automatic?\n\nYes I agree. The next version of this patch will make `hg phabsend` automatically pick up the branch from changeset.","author":"pulkit","id":"89656","dateCreated":"1552994691","dateModified":"1552994691"},{"type":"update","diffId":"14548","author":"pulkit","id":"89639","dateCreated":"1552943259","dateModified":"1552943259"},{"type":"comment","comment":"While there may be a need for an explicit `--branch` argument, should we start by having `hg phabsend` automatically pick up the branch from the changeset? i.e. wouldn't we want branch selection to be automatic?","author":"indygreg","id":"89251","dateCreated":"1552502219","dateModified":"1552502219"},{"type":"comment","comment":">>! In D6082#88981, @Kwan wrote:\n>>>! In D6082#88852, @mharbison72 wrote:\n>>>>! In D6082#88851, @pulkit wrote:\n>>> @mharbison72 thanks for tips on adding test. Will add tests in next iteration.\n>>> \n>>> I found that Differentials do have a branch field, maybe we can use that? https:\/\/secure.phabricator.com\/source\/phabricator\/browse\/master\/src\/applications\/differential\/customfield\/DifferentialBranchField.php\n>> \n>> Seems worth a shot.  I don\u2019t know anything about it, but presumably this would be rendered specially in the web UI, like the test plan, etc.  That sounds better than as a follow up comment.  It also seems natural enough that maybe it can be done unconditionally, instead of needing the argument.\n> \n> Yeah, it shows in the Diff Detail pane, [like here](https:\/\/phabricator-dev.allizom.org\/D1092?id=1765).  Unfortunately I think it can be only set when using the creatediff endpoint, which is what I had to change my fork to do (though I could be wrong, the conduit docs are too sparse to be sure).\n\nYeah, that's kinda how I read the documentation too :\/\n\nI wonder if we can use `parents.set` in `differential.revision.edit` on the first commit in the series.  Or add the branch name to the existing metadata wiith `differential.setdiffproperty`?  I've aliased `phabimport` to `!\"%HG%\" phabread $1 --stack | \"%HG%\" import --bypass -`, but maybe a first class phabimport that knows how to use the data would make the tooling easier?","author":"mharbison72","id":"88983","dateCreated":"1552156019","dateModified":"1552156019"},{"type":"comment","comment":">>! In D6082#88852, @mharbison72 wrote:\n>>>! In D6082#88851, @pulkit wrote:\n>> @mharbison72 thanks for tips on adding test. Will add tests in next iteration.\n>> \n>> I found that Differentials do have a branch field, maybe we can use that? https:\/\/secure.phabricator.com\/source\/phabricator\/browse\/master\/src\/applications\/differential\/customfield\/DifferentialBranchField.php\n> \n> Seems worth a shot.  I don\u2019t know anything about it, but presumably this would be rendered specially in the web UI, like the test plan, etc.  That sounds better than as a follow up comment.  It also seems natural enough that maybe it can be done unconditionally, instead of needing the argument.\n\nYeah, it shows in the Diff Detail pane, [like here](https:\/\/phabricator-dev.allizom.org\/D1092?id=1765).  Unfortunately I think it can be only set when using the creatediff endpoint, which is what I had to change my fork to do (though I could be wrong, the conduit docs are too sparse to be sure).","author":"Kwan","id":"88982","dateCreated":"1552150082","dateModified":"1552150082"},{"type":"comment","comment":">>! In D6082#88851, @pulkit wrote:\n> @mharbison72 thanks for tips on adding test. Will add tests in next iteration.\n> \n> I found that Differentials do have a branch field, maybe we can use that? https:\/\/secure.phabricator.com\/source\/phabricator\/browse\/master\/src\/applications\/differential\/customfield\/DifferentialBranchField.php\n\nSeems worth a shot.  I don\u2019t know anything about it, but presumably this would be rendered specially in the web UI, like the test plan, etc.  That sounds better than as a follow up comment.  It also seems natural enough that maybe it can be done unconditionally, instead of needing the argument.","author":"mharbison72","id":"88852","dateCreated":"1552086746","dateModified":"1552086746"},{"type":"comment","comment":"@mharbison72 thanks for tips on adding test. Will add tests in next iteration.\n\nI found that Differentials do have a branch field, maybe we can use that? https:\/\/secure.phabricator.com\/source\/phabricator\/browse\/master\/src\/applications\/differential\/customfield\/DifferentialBranchField.php","author":"pulkit","id":"88851","dateCreated":"1552084239","dateModified":"1552084239"},{"type":"comment","comment":"To create a test, you need to `pip install pytest-vcr`, edit `auth.hgphab.phabtoken` at the top of the test, and use `--test-vcr` with your `hg phabsend` command.  See a641fd1a1196 for some background, and remember to purge your phabtoken from the changes before posting.  FWIW, I used a VirtualBox VM running Phabricator from Bitnami to figure things out before generating the test on phab.m-s.o to avoid extra noise.","author":"mharbison72","id":"88621","dateCreated":"1551980125","dateModified":"1551980125"},{"type":"comment","comment":"This review is intended for `default` branch.","author":"pulkit","id":"88617","dateCreated":"1551967198","dateModified":"1551967198"},{"type":"update","diffId":"14384","author":"pulkit","id":"88612","dateCreated":"1551967197","dateModified":"1551967197"}],"dateCreated":"1551967197","dateModified":"1560355916","status":"Needs Review"},{"id":"6356","callsign":"HG","title":"mdiff: prepare mdiff to be used for run-tests to replace unidiff","author":"sangeet259","summary":"Patch 1\/2\n\nThis patch adds some functions to mdiff.py that will be called from run-tests.py\nwhich will be added in the second part of this patch series.\n\nThe future changes to run-tests.py will enable one to use mdiif\nto diff rather than unidiff whenever the mercurial is installed in the system.\n\nhg diff uses mdiff which which gives simpler and more readable diffs than unidiff\n\nWhy do I need to split the patches into two ?\nThe reason to split what would have been a single patch into two is because\nfor the next patch to be able to use the mdiff during tests,\nthis revision has to be there in the system's mercurial installation.","testPlan":"","lineCount":"36","dependsOn":[],"reviewers":[],"ccs":["durin42","pulkit","martinvonz","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D6356#94599, @sangeet259 wrote:\n> @pulkit \n>> My understanding is that the 1st patch should be present in the mercurial installed in the system, which is what you said right? If that's correct, we can go ahead and have this whole as one patch as I don't think people usually do install system hg on patch to patch basis.\n> \n> Yes, that is what I was trying to say.\n> But apart from that, I see the two changes as doing two logically separable things, to deserve to be broken into two commits.\n> \n> Is that justified?\n\nTo be honest, the motivation behind this patch is the next patch. It will be nice to have them as one patch, so that when in future someone does annotate, they can see the whole functionality in one patch. But I fine with accepting as separate patches too.\n\nAlso, this patch still has some un-addressed comments incase you missed them.","author":"pulkit","id":"94610","dateCreated":"1560206469","dateModified":"1560206469"},{"type":"comment","comment":"@pulkit \n> My understanding is that the 1st patch should be present in the mercurial installed in the system, which is what you said right? If that's correct, we can go ahead and have this whole as one patch as I don't think people usually do install system hg on patch to patch basis.\n\nYes, that is what I was trying to say.\nBut apart from that, I see the two changes as doing two logically separable things, to deserve to be broken into two commits.\n\nIs that justified?","author":"sangeet259","id":"94599","dateCreated":"1560199497","dateModified":"1560199497"},{"type":"comment","comment":">>! In D6356#92695, @sangeet259 wrote:\n>>>! In D6356#92644, @pulkit wrote:\n>>> Why do I need to split the patches into two ?\n>>> The reason to split what would have been a single patch into two is because\n>>> for the next patch to be able to use the mdiff during tests,\n>>> this revision has to be there in the system's mercurial installation.\n>> \n>> I didn't get the last line. Can you explain more?\n>> \n>> I think both can be folded in one and should be good.\n> \n> @pulkit \n> Well the next patch imports mercurial and then calls `mdff.new_diff` . If I combine those two patches then you can not see the change as while testing D6359 , if there `mdiff` doesn't already have new_diff \n> it will always fall back to unified_diff as happened with @durin42  , while he was trying to see the alternate path as he trying to test D5514 .\n> \n> What I am trying to do here is, once D6356 is has added `new_diff` to `mdiff`, you can then have this revision installed in your system or wherever one tests this, and then check D6359 to see the alternate path it follows.\n\nI was trying to test it and unable to get this to work both with a single patch and two splitted patches.\n\nMy understanding is that the 1st patch should be present in the mercurial installed in the system, which is what you said right? If that's correct, we can go ahead and have this whole as one patch as I don't think people usually do install system hg on patch to patch basis.\n","author":"pulkit","id":"92737","dateCreated":"1557937290","dateModified":"1557937290"},{"type":"inline","comment":"nit: `return itertools.chain.from_iterable(hunklines)`","replyTo":null,"isNewFile":"1","line":"552","lineLength":"0","path":"mercurial\/mdiff.py","diffId":"15049","author":"pulkit","id":"92734","dateCreated":"1557936004","dateModified":"1557936004"},{"type":"inline","comment":"may be worth to rename it to `prepare_mdiff_input`.","replyTo":null,"isNewFile":"1","line":"531","lineLength":"0","path":"mercurial\/mdiff.py","diffId":"15049","author":"pulkit","id":"92733","dateCreated":"1557936004","dateModified":"1557936004"},{"type":"inline","comment":"We can do\n```\ndate = datetime.datetime.now().strftime(\"%a %b %d %y %H:%M:%S %Y %z\")\nreturn \"\".join(expected), date, \"\".join(output), date, diffopts(noprefix=True)\n```","replyTo":null,"isNewFile":"1","line":"540","lineLength":"0","path":"mercurial\/mdiff.py","diffId":"15049","author":"pulkit","id":"92732","dateCreated":"1557936004","dateModified":"1557936004"},{"type":"inline","comment":"I was unable to find any `getdiff` in this file.","replyTo":null,"isNewFile":"1","line":"544","lineLength":"0","path":"mercurial\/mdiff.py","diffId":"15049","author":"pulkit","id":"92731","dateCreated":"1557936004","dateModified":"1557936004"},{"type":"inline","comment":"nit: `return process_mdiff(uheaders, hunks)`","replyTo":null,"isNewFile":"1","line":"562","lineLength":"0","path":"mercurial\/mdiff.py","diffId":"15049","author":"pulkit","id":"92730","dateCreated":"1557936004","dateModified":"1557936004"},{"type":"inline","comment":"backwards compatibility with what?","replyTo":null,"isNewFile":"1","line":"557","lineLength":"0","path":"mercurial\/mdiff.py","diffId":"15049","author":"pulkit","id":"92729","dateCreated":"1557936004","dateModified":"1557936004"},{"type":"comment","comment":"> Patch 1\/2\n\nwe don't add that to commit messages.","author":"pulkit","id":"92728","dateCreated":"1557936004","dateModified":"1557936004"},{"type":"comment","comment":">>! In D6356#92644, @pulkit wrote:\n>> Why do I need to split the patches into two ?\n>> The reason to split what would have been a single patch into two is because\n>> for the next patch to be able to use the mdiff during tests,\n>> this revision has to be there in the system's mercurial installation.\n> \n> I didn't get the last line. Can you explain more?\n> \n> I think both can be folded in one and should be good.\n\n@pulkit \nWell the next patch imports mercurial and then calls `mdff.new_diff` . If I combine those two patches then you can not see the change as while testing D6359 , if there `mdiff` doesn't already have new_diff \nit will always fall back to unified_diff as happened with @durin42  , while he was trying to see the alternate path as he trying to test D5514 .\n\nWhat I am trying to do here is, once D6356 is has added `new_diff` to `mdiff`, you can then have this revision installed in your system or wherever one tests this, and then check D6359 to see the alternate path it follows.","author":"sangeet259","id":"92697","dateCreated":"1557907221","dateModified":"1557907221"},{"type":"comment","comment":"> Why do I need to split the patches into two ?\n> The reason to split what would have been a single patch into two is because\n> for the next patch to be able to use the mdiff during tests,\n> this revision has to be there in the system's mercurial installation.\n\nI didn't get the last line. Can you explain more?\n\nI think both can be folded in one and should be good.","author":"pulkit","id":"92645","dateCreated":"1557853675","dateModified":"1557853675"},{"type":"comment","comment":"> Oh, nice! I sometimes use run-tests.py -i and just accept an unreadable diff because I know that hg diff might make it easier to read. I had not understood why :) \nGlad to know you will be helped :)\n\nAdded some description to the commit message!","author":"sangeet259","id":"92456","dateCreated":"1557512190","dateModified":"1557512190"},{"type":"comment","comment":">>! In D6356#92453, @sangeet259 wrote:\n>>>! In D6356#92451, @martinvonz wrote:\n>>> The future changes to run-tests.py will enable one to use mdiif\n>>> to diff rather than unidiff whenever the mercurial is installed in the system.\n>> \n>> Perhaps a naive question, but why is that desirable? How will I (as someone running tests) notice?\n> \n> @martinvonz \n> This patch is a breakdown of the earlier patch https:\/\/phab.mercurial-scm.org\/D5514\n\nOh, nice! I sometimes use `run-tests.py -i` and just accept an unreadable diff because I know that `hg diff` might make it easier to read. I had not understood why :)\n\n> \n> \n> [[ https:\/\/phab.mercurial-scm.org\/D5514 | There ]] I have detailed why is this required.\n> In short, the diff output of tests is a bit ugly compared to what hg diff does, which is much nicer.\n> \n> \n> \n> I am thinking of putting that descriptive commit message in the patch 2\/2.\n\nPerhaps also adding a \"which gives simpler diffs\" or something like that to this patch?","author":"martinvonz","id":"92454","dateCreated":"1557510262","dateModified":"1557510262"},{"type":"comment","comment":">>! In D6356#92451, @martinvonz wrote:\n>> The future changes to run-tests.py will enable one to use mdiif\n>> to diff rather than unidiff whenever the mercurial is installed in the system.\n> \n> Perhaps a naive question, but why is that desirable? How will I (as someone running tests) notice?\n\n@martinvonz \nThis patch is a breakdown of the earlier patch https:\/\/phab.mercurial-scm.org\/D5514\n\n\n[[ https:\/\/phab.mercurial-scm.org\/D5514 | There ]] I have detailed why is this required.\nIn short, the diff output of tests is a bit ugly compared to what hg diff does, which is much nicer.\n\n\n\nI am thinking of putting that descriptive commit message in the patch 2\/2.\n\n\n","author":"sangeet259","id":"92453","dateCreated":"1557510056","dateModified":"1557510056"},{"type":"comment","comment":"> The future changes to run-tests.py will enable one to use mdiif\n> to diff rather than unidiff whenever the mercurial is installed in the system.\n\nPerhaps a naive question, but why is that desirable? How will I (as someone running tests) notice?","author":"martinvonz","id":"92452","dateCreated":"1557509673","dateModified":"1557509673"},{"type":"update","diffId":"15049","author":"sangeet259","id":"92446","dateCreated":"1557509283","dateModified":"1557509283"}],"dateCreated":"1557509283","dateModified":"1560206469","status":"Needs Review"},{"id":"6359","callsign":"HG","title":"test: change test's diff generation to use mdiff for nicer output","author":"sangeet259","summary":"This is patch (2\/2), hence must be there in the repo after 1\/2, which is at https:\/\/phab.mercurial-scm.org\/D6356\n\nThe current diff being used by tests upon failing is not very good. Sometimes there is a lot of redundancy.\n\nTo see for yourself, follow these steps:\n\n1. Download this bundle : http:\/\/bit.ly\/2IDgJFU\n\n```\n$ hg clone https:\/\/www.mercurial-scm.org\/hg\n$ cd hg\/\n$ hg unbundle af8efb83e1d6.hg\n$ hg up a1e70c1dbec0^\n$ g revert --all --rev a1e70c1dbec0\n$ hg revert -i tests\/test-bookmarks-pushpull.t # revert only the last three hunks (press 'n' for the first 8, and 'y' for the last three)\n$ cd tests\n$ hg diff --rev a1e70c1dbec0 # nice output from Mercurial\n$ .\/run-test.py test-bookmarks-pushpull.t # poor output from the test runner\n```\n\nIf you couldn't follow those steps, you can simply check the diffs here:\n\n* test's diff:\n\n```\n\n> --- \/media\/sangeet\/Stuff\/hgrepo\/Octobus\/MD4\/tests\/test-bookmarks-pushpull.t\n> +++ \/media\/sangeet\/Stuff\/hgrepo\/Octobus\/MD4\/tests\/test-bookmarks-pushpull.t.b2-binary.err\n> @@ -1086,8 +1086,7 @@\n>    pushing to $TESTTMP\/issue4455-dest (glob)\n>    searching for changes\n>    no changes found\n> -  pushkey-abort: prepushkey hook exited with status 1\n> -  abort: exporting bookmark @ failed!\n> +  abort: prepushkey hook exited with status 1\n>    [255]\n\n>  #endif\n> @@ -1126,27 +1125,27 @@\n>    pushing to ssh:\/\/user@dummy\/issue4455-dest\n>    searching for changes\n>    no changes found\n> +  remote: prepushkey hook exited with status 1\n> +  abort: push failed on remote\n> +  [255]\n> +\n> +#endif\n> +\n> +  $ hg -R ..\/issue4455-dest\/ bookmarks\n> +  no bookmarks set\n> +\n> +Using http\n> +----------\n> +\n> +#if b2-pushkey\n> +  $ hg push -B @ http # bundle2+\n> +  pushing to http:\/\/localhost:$HGPORT\/\n> +  searching for changes\n> +  no changes found\n>    remote: pushkey-abort: prepushkey hook exited with status 1\n>    abort: exporting bookmark @ failed!\n>    [255]\n>\n> -#endif\n> -\n> -  $ hg -R ..\/issue4455-dest\/ bookmarks\n> -  no bookmarks set\n> -\n> -Using http\n> -----------\n> -\n> -#if b2-pushkey\n> -  $ hg push -B @ http # bundle2+\n> -  pushing to http:\/\/localhost:$HGPORT\/\n> -  searching for changes\n> -  no changes found\n> -  remote: pushkey-abort: prepushkey hook exited with status 1\n> -  abort: exporting bookmark @ failed!\n> -  [255]\n> -\n>    $ hg -R ..\/issue4455-dest\/ bookmarks\n>    no bookmarks set\n>\n> @@ -1166,8 +1165,8 @@\n>    pushing to ssh:\/\/user@dummy\/issue4455-dest\n>    searching for changes\n>    no changes found\n> -  remote: pushkey-abort: prepushkey hook exited with status 1\n> -  abort: exporting bookmark @ failed!\n> +  remote: prepushkey hook exited with status 1\n> +  abort: push failed on remote\n>    [255]\n>\n>  #endif\n>\n> ERROR: test-bookmarks-pushpull.t (case b2-binary) output changed\n> !.\n> Failed test-bookmarks-pushpull.t (case b2-binary): output changed\n> # Ran 2 tests, 0 skipped, 1 failed.\n> python hash seed: 133193196\n> ```\n---\n\n* diff used by hg diff:\n\n```\n> diff -r a1e70c1dbec0 tests\/test-bookmarks-pushpull.t\n> --- a\/tests\/test-bookmarks-pushpull.t\tThu Nov 01 22:20:00 2018 +0530\n> +++ b\/tests\/test-bookmarks-pushpull.t\tTue Oct 17 12:38:13 2017 +0200\n> @@ -1086,8 +1086,7 @@\n>    pushing to $TESTTMP\/issue4455-dest (glob)\n>    searching for changes\n>    no changes found\n> -  pushkey-abort: prepushkey hook exited with status 1\n> -  abort: exporting bookmark @ failed!\n> +  abort: prepushkey hook exited with status 1\n>    [255]\n>\n>  #endif\n> @@ -1126,8 +1125,8 @@\n>    pushing to ssh:\/\/user@dummy\/issue4455-dest\n>    searching for changes\n>    no changes found\n> -  remote: pushkey-abort: prepushkey hook exited with status 1\n> -  abort: exporting bookmark @ failed!\n> +  remote: prepushkey hook exited with status 1\n> +  abort: push failed on remote\n>    [255]\n>\n>  #endif\n> @@ -1166,8 +1165,8 @@\n>    pushing to ssh:\/\/user@dummy\/issue4455-dest\n>    searching for changes\n>    no changes found\n> -  remote: pushkey-abort: prepushkey hook exited with status 1\n> -  abort: exporting bookmark @ failed!\n> +  remote: prepushkey hook exited with status 1\n> +  abort: push failed on remote\n>    [255]\n>\n>  #endif\n```\n\nTests uses _unified_diff based on difflib.py . The output isn't great!\n\nMercurial's diff uses mdiff which gives better diffs.\nThis patch uses mdiff's unidiff function to generate the diff for the failed tests.","testPlan":"","lineCount":"527","dependsOn":["6356"],"reviewers":[],"ccs":["pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"@pulkit \n\n> The commit message has diff which confuses `hg import`.  You need to indent those diffs.\n\u2705 \n> Also, remove the pastebin links as they are not required since we have diffs.\n\u2705 \n>> Download this bundle : http:\/\/bit.ly\/2DuJjsS\n> \n> This link asks me to login. So definitely not a good link to put in commit message.\n\u2705  \n","author":"sangeet259","id":"94602","dateCreated":"1560200514","dateModified":"1560200514"},{"type":"update","diffId":"15433","author":"sangeet259","id":"94600","dateCreated":"1560200157","dateModified":"1560200157"},{"type":"comment","comment":"The commit message has diff which confuses `hg import`.  You need to indent those diffs.\n\nAlso, remove the pastebin links as they are not required since we have diffs.\n\n> Download this bundle : http:\/\/bit.ly\/2DuJjsS\n\nThis link asks me to login. So definitely not a good link to put in commit message.","author":"pulkit","id":"92736","dateCreated":"1557936451","dateModified":"1557936451"},{"type":"update","diffId":"15052","author":"sangeet259","id":"92475","dateCreated":"1557523020","dateModified":"1557523020"}],"dateCreated":"1557523020","dateModified":"1560200514","status":"Needs Review"},{"id":"6462","callsign":"HG","title":"commitextras: try to remove localrepo hacking to add extras to commit","author":"pulkit","summary":"","testPlan":"","lineCount":"59","dependsOn":[],"reviewers":[],"ccs":["martinvonz","mercurial-devel"],"actions":[{"type":"comment","comment":"Can you elaborate a bit about what the current hack does and why it's bad?","author":"martinvonz","id":"94006","dateCreated":"1559597555","dateModified":"1559597555"},{"type":"comment","comment":"I am not sure this is good way to do this. But I will definitely like to remove the hacking around localrepo to add extras to a commit.","author":"pulkit","id":"93869","dateCreated":"1559240493","dateModified":"1559240510"},{"type":"update","diffId":"15302","author":"pulkit","id":"93865","dateCreated":"1559240451","dateModified":"1559240451"}],"dateCreated":"1559240451","dateModified":"1559597555","status":"Needs Review"},{"id":"5299","callsign":"HG","title":"phabricator: fallback reading arcanist config files","author":"philpep","summary":"This allow the phabricator extension to read arc config files to auto-configure\nurl, token and callsign.\n\nWe use it as a fallback when phabricator.url or phabricator.callsign aren't\ndefined.\n\nThis allow to configure conduit_uri and repository.callsign in a tracked\n.arcconfig json file in the root of the repository, so users having lot of\nsmall repositories in phabricator doesn't need to configure .hg\/hgrc after a\nfresh clone.","testPlan":"","lineCount":"51","dependsOn":[],"reviewers":["durin42"],"ccs":["durin42","Kwan","mharbison72","mercurial-devel"],"actions":[{"type":"comment","comment":"Thanks for reviewing @Kwan !\n\nActually I think parsing\/merging arcconfig files will be quite hard to maintain because they are not fully documented and subject to changes.\n\nFor my needs, just having hg being able to get phabricator.url and phabricator.callsign from .arcconfig in the repo root is enough. Then I just need to match this with hg auth config.\nI'll try to have a smaller patch not trying to read other files than .arcconfig and not reading the token.","author":"philpep","id":"92911","dateCreated":"1558002229","dateModified":"1558002229"},{"type":"comment","comment":"I see at least one outstanding comment that points out a typo. I'm generally in favor of this though, so please let us know when it's time to take another look.","author":"durin42","id":"92791","dateCreated":"1557943704","dateModified":"1557943704"},{"type":"reject","author":"durin42","id":"92790","dateCreated":"1557943704","dateModified":"1557943704"},{"type":"inline","comment":"Although, this wouldn't work with changing phab instances in hgrc, and using .arcrc for the token, since `readarcconfig` would return the  token for the original URL.  An alternative would be having `readarcconfig` return a dict mapping hosts to tokens (with '\/api\/' stripped from the hosts), and then `readurltoken` does `token = hgrctoken or arctokens.get(url)`.","replyTo":"92590","isNewFile":"1","line":"217","lineLength":"5","path":"hgext\/phabricator.py","diffId":"14253","author":"Kwan","id":"92605","dateCreated":"1557659058","dateModified":"1557659058"},{"type":"inline","comment":"Looks like annotating it with `@util.cachefunc` is enough?","replyTo":"78872","isNewFile":"1","line":"175","lineLength":"0","path":"hgext\/phabricator.py","diffId":"12590","author":"Kwan","id":"92604","dateCreated":"1557659058","dateModified":"1557659058"},{"type":"inline","comment":"Oh, and the `config.get('hosts', {}).get(uri)` would have to use a uri with `.path = b'api\/'`","replyTo":"91403","isNewFile":"1","line":"201","lineLength":"0","path":"hgext\/phabricator.py","diffId":"12590","author":"Kwan","id":"92592","dateCreated":"1557597352","dateModified":"1557597352"},{"type":"inline","comment":"Typo: should be `arcconfig` (two 'c's).\nAlso no dot for the \"\/etc\/\" one according to the docs","replyTo":null,"isNewFile":"1","line":"193","lineLength":"0","path":"hgext\/phabricator.py","diffId":"14253","author":"Kwan","id":"92591","dateCreated":"1557597352","dateModified":"1557597352"},{"type":"inline","comment":"Something I realised with some testing is that this requires both .arcconfig and .arcrc, one can't rely on the repo's .arcconfig for the repo settings while using .hg\/hgrc for the auth settings (or use hgrc for phab url with .arcrc for auth).  Maybe it could instead do the following:\n```\n    hgrcurl = repo.ui.config(b'phabricator', b'url')\n    arcurl, arctoken, __ = readarcconfig(repo)\n    url = hgrcurl or arcurl\n    if not url:\n        [etc...]\n\n    res = [etc...]\n    hgrctoken = None\n\n    if res:\n        [etc...]\n        hgrctoken = auth.get(b'token')\n    token = hgrctoken or arctoken\n    if not token:\n        [etc...]\n```\n\nThat way any mix of settings in hgrc or .arcconfig\/.arcrc would work, with hgrc having precedence.","replyTo":null,"isNewFile":"1","line":"217","lineLength":"5","path":"hgext\/phabricator.py","diffId":"14253","author":"Kwan","id":"92590","dateCreated":"1557597352","dateModified":"1557597352"},{"type":"inline","comment":"I think you could do\n```\nurl = util.url(conduit_uri)\nurl.path = None\nurl = b'%s' % url\n```\n\nAlso I think you need to check for `phabricator.uri` first, then fall back to `conduit_uri`, see [change to phabricator's .arcconfig](https:\/\/github.com\/phacility\/phabricator\/commit\/f0e6dc122109bcc2c3cade0af04b3f06af2fe50b) and [mozilla-central's current one](https:\/\/hg.mozilla.org\/mozilla-central\/file\/f7a15eb24f3d\/.arcconfig) (and perhaps rename conduit_uri variable appropriately)","replyTo":"78871","isNewFile":"1","line":"201","lineLength":"0","path":"hgext\/phabricator.py","diffId":"12590","author":"Kwan","id":"91403","dateCreated":"1555661299","dateModified":"1555661299"},{"type":"inline","comment":"Woops... Thanks for catching this!","replyTo":"87626","isNewFile":"1","line":"187","lineLength":"0","path":"hgext\/phabricator.py","diffId":"14175","author":"philpep","id":"87948","dateCreated":"1551264587","dateModified":"1551264587"},{"type":"inline","comment":"Yes, done.","replyTo":"87627","isNewFile":"1","line":"200","lineLength":"0","path":"hgext\/phabricator.py","diffId":"14175","author":"philpep","id":"87947","dateCreated":"1551264587","dateModified":"1551264587"},{"type":"inline","comment":"Indeed, I fixed this.","replyTo":"87628","isNewFile":"1","line":"290","lineLength":"0","path":"hgext\/phabricator.py","diffId":"14175","author":"philpep","id":"87946","dateCreated":"1551264587","dateModified":"1551264587"},{"type":"update","diffId":"14253","author":"philpep","id":"87944","dateCreated":"1551264509","dateModified":"1551264509"},{"type":"inline","comment":"It might be clearer to return None, since the function is to fetch the repoid.","replyTo":null,"isNewFile":"1","line":"290","lineLength":"0","path":"hgext\/phabricator.py","diffId":"14175","author":"mharbison72","id":"87628","dateCreated":"1550858358","dateModified":"1550858358"},{"type":"inline","comment":"Should this be using vfs to open, instead of raw open?  Using the vfs layer allows the class that provides posix-like functionality on Windows to be used.","replyTo":null,"isNewFile":"1","line":"200","lineLength":"0","path":"hgext\/phabricator.py","diffId":"14175","author":"mharbison72","id":"87627","dateCreated":"1550858358","dateModified":"1550858358"},{"type":"inline","comment":"s\/.encoding\/.environ\/ ?","replyTo":null,"isNewFile":"1","line":"187","lineLength":"0","path":"hgext\/phabricator.py","diffId":"14175","author":"mharbison72","id":"87626","dateCreated":"1550858358","dateModified":"1550858358"},{"type":"comment","comment":"Thanks for the review and sorry for taking so long time to update the patch... I made changes to use encoding.environ and vfs like you suggested.\nPlease let me known what I can do to introduce this (or at least part of) this feature, thanks!","author":"philpep","id":"87542","dateCreated":"1550773155","dateModified":"1550773155"},{"type":"update","diffId":"14175","author":"philpep","id":"87540","dateCreated":"1550772964","dateModified":"1550772964"},{"type":"update","diffId":"14174","author":"philpep","id":"87539","dateCreated":"1550772537","dateModified":"1550772537"},{"type":"inline","comment":"I think there\u2019s something for environment variables in encoding (or maybe procutil- I don\u2019t have the code in front of me).\n\nAlso, is there a way to use vfs here?  I think we\u2019re trying to avoid direct os.path usage.\n\nhttps:\/\/www.mercurial-scm.org\/wiki\/WindowsUTF8Plan","replyTo":null,"isNewFile":"1","line":"181","lineLength":"0","path":"hgext\/phabricator.py","diffId":"12590","author":"mharbison72","id":"78889","dateCreated":"1543080661","dateModified":"1543080661"},{"type":"inline","comment":"pycompat.iswindows","replyTo":null,"isNewFile":"1","line":"179","lineLength":"0","path":"hgext\/phabricator.py","diffId":"12590","author":"mharbison72","id":"78888","dateCreated":"1543080661","dateModified":"1543080661"},{"type":"inline","comment":"I'd be nice to cache the result of `readarcconfig` but I don't known how to implement this, any suggestion ?","replyTo":null,"isNewFile":"1","line":"175","lineLength":"0","path":"hgext\/phabricator.py","diffId":"12590","author":"philpep","id":"78872","dateCreated":"1542993410","dateModified":"1542993410"},{"type":"inline","comment":"HINT: This doesn't work for current mercurial config because \"arc install-certificates\" add a trailing \"\/\" to conduit_uri and our .arcconfig doesn't have this trailing slash.\nAny idea how to handle this properly ?","replyTo":null,"isNewFile":"1","line":"201","lineLength":"0","path":"hgext\/phabricator.py","diffId":"12590","author":"philpep","id":"78871","dateCreated":"1542993322","dateModified":"1542993322"},{"type":"update","diffId":"12590","author":"philpep","id":"78866","dateCreated":"1542993179","dateModified":"1542993179"}],"dateCreated":"1542993179","dateModified":"1558002229","status":"Needs Revision"},{"id":"5514","callsign":"HG","title":"test: change test's diff generation to use mdiff for nicer output","author":"sangeet259","summary":"The current diff being used by tests upon failing is not very good. Sometimes there is a lot of redundancy.\n\nTo see for yourself, follow these steps:\n\n1. Download this bundle : http:\/\/bit.ly\/2DuJjsS\n\n```\n$ hg clone https:\/\/www.mercurial-scm.org\/hg\n$ cd hg\/\n$ hg unbundle af8efb83e1d6.hg\n$ hg up a1e70c1dbec0^\n$ g revert --all --rev a1e70c1dbec0\n$ hg revert -i tests\/test-bookmarks-pushpull.t # revert only the last three hunks (press 'n' for the first 8, and 'y' for the last three)\n$ cd tests\n$ hg diff --rev a1e70c1dbec0 # nice output from Mercurial\n$ .\/run-test.py test-bookmarks-pushpull.t # poor output from the test runner\n```\n\nIf you couldn't follow those steps, you can simply check the diffs here:\n\n* test's diff: https:\/\/pastebin.com\/Z4LRg4vx\n\n```\n\n--- \/media\/sangeet\/Stuff\/hgrepo\/Octobus\/MD4\/tests\/test-bookmarks-pushpull.t\n+++ \/media\/sangeet\/Stuff\/hgrepo\/Octobus\/MD4\/tests\/test-bookmarks-pushpull.t.b2-binary.err\n@@ -1086,8 +1086,7 @@\n   pushing to $TESTTMP\/issue4455-dest (glob)\n   searching for changes\n   no changes found\n-  pushkey-abort: prepushkey hook exited with status 1\n-  abort: exporting bookmark @ failed!\n+  abort: prepushkey hook exited with status 1\n   [255]\n\n #endif\n@@ -1126,27 +1125,27 @@\n   pushing to ssh:\/\/user@dummy\/issue4455-dest\n   searching for changes\n   no changes found\n+  remote: prepushkey hook exited with status 1\n+  abort: push failed on remote\n+  [255]\n+\n+#endif\n+\n+  $ hg -R ..\/issue4455-dest\/ bookmarks\n+  no bookmarks set\n+\n+Using http\n+----------\n+\n+#if b2-pushkey\n+  $ hg push -B @ http # bundle2+\n+  pushing to http:\/\/localhost:$HGPORT\/\n+  searching for changes\n+  no changes found\n   remote: pushkey-abort: prepushkey hook exited with status 1\n   abort: exporting bookmark @ failed!\n   [255]\n\n-#endif\n-\n-  $ hg -R ..\/issue4455-dest\/ bookmarks\n-  no bookmarks set\n-\n-Using http\n-----------\n-\n-#if b2-pushkey\n-  $ hg push -B @ http # bundle2+\n-  pushing to http:\/\/localhost:$HGPORT\/\n-  searching for changes\n-  no changes found\n-  remote: pushkey-abort: prepushkey hook exited with status 1\n-  abort: exporting bookmark @ failed!\n-  [255]\n-\n   $ hg -R ..\/issue4455-dest\/ bookmarks\n   no bookmarks set\n\n@@ -1166,8 +1165,8 @@\n   pushing to ssh:\/\/user@dummy\/issue4455-dest\n   searching for changes\n   no changes found\n-  remote: pushkey-abort: prepushkey hook exited with status 1\n-  abort: exporting bookmark @ failed!\n+  remote: prepushkey hook exited with status 1\n+  abort: push failed on remote\n   [255]\n\n #endif\n\nERROR: test-bookmarks-pushpull.t (case b2-binary) output changed\n!.\nFailed test-bookmarks-pushpull.t (case b2-binary): output changed\n# Ran 2 tests, 0 skipped, 1 failed.\npython hash seed: 133193196\n```\n---\n\n* diff used by hg diff: https:\/\/pastebin.com\/qanQEsiA\n\n```\ndiff -r a1e70c1dbec0 tests\/test-bookmarks-pushpull.t\n--- a\/tests\/test-bookmarks-pushpull.t\tThu Nov 01 22:20:00 2018 +0530\n+++ b\/tests\/test-bookmarks-pushpull.t\tTue Oct 17 12:38:13 2017 +0200\n@@ -1086,8 +1086,7 @@\n   pushing to $TESTTMP\/issue4455-dest (glob)\n   searching for changes\n   no changes found\n-  pushkey-abort: prepushkey hook exited with status 1\n-  abort: exporting bookmark @ failed!\n+  abort: prepushkey hook exited with status 1\n   [255]\n\n #endif\n@@ -1126,8 +1125,8 @@\n   pushing to ssh:\/\/user@dummy\/issue4455-dest\n   searching for changes\n   no changes found\n-  remote: pushkey-abort: prepushkey hook exited with status 1\n-  abort: exporting bookmark @ failed!\n+  remote: prepushkey hook exited with status 1\n+  abort: push failed on remote\n   [255]\n\n #endif\n@@ -1166,8 +1165,8 @@\n   pushing to ssh:\/\/user@dummy\/issue4455-dest\n   searching for changes\n   no changes found\n-  remote: pushkey-abort: prepushkey hook exited with status 1\n-  abort: exporting bookmark @ failed!\n+  remote: prepushkey hook exited with status 1\n+  abort: push failed on remote\n   [255]\n\n #endif\n```\n\nTests uses _unified_diff based on difflib.py . The output isn't great!\n\nMercurial's diff uses mdiff which gives better diffs.\nThis patch uses mdiff's unidiff function to generate the diff for the failed tests.","testPlan":"","lineCount":"56","dependsOn":[],"reviewers":["durin42"],"ccs":["pulkit","durin42","mercurial-devel"],"actions":[{"type":"comment","comment":"(moving this off the dashboard until it gets updated)","author":"durin42","id":"87386","dateCreated":"1550694075","dateModified":"1550694075"},{"type":"reject","author":"durin42","id":"87385","dateCreated":"1550694075","dateModified":"1550694075"},{"type":"comment","comment":"Apologies, I didn't run the tests after the latest addition. \ud83d\ude14","author":"sangeet259","id":"87361","dateCreated":"1550590876","dateModified":"1550590876"},{"type":"inline","comment":"In the future please *run tests* before requesting another round of review: this is a trivial syntax error and proves you didn't try running tests.","replyTo":null,"isNewFile":"1","line":"80","lineLength":"0","path":"tests\/run-tests.py","diffId":"13998","author":"durin42","id":"87356","dateCreated":"1550588918","dateModified":"1550588918"},{"type":"comment","comment":"Even with my in-flight fixes, I can't get this to use the non-unified_diff codepath. Can you test again?\n\nhttps:\/\/bitbucket.org\/snippets\/durin42\/nejj94 has my in-flight fixes, but you may find it challenging to apply (the test output in the commit message confuses the patch parser). Hopefully that helps...","author":"durin42","id":"87355","dateCreated":"1550588918","dateModified":"1550588918"},{"type":"comment","comment":"I've done some cleanups (dropped an unused import, copyedited the commit message a bit) and should push this soon. Thanks!","author":"durin42","id":"87354","dateCreated":"1550588435","dateModified":"1550588435"},{"type":"comment","comment":"Hey @durin42 , take a look at the changes when you get time.","author":"sangeet259","id":"87352","dateCreated":"1550567970","dateModified":"1550567970"},{"type":"comment","author":"sangeet259","id":"87008","dateCreated":"1550117862","dateModified":"1550567945"},{"type":"update","diffId":"13998","author":"sangeet259","id":"86564","dateCreated":"1549774133","dateModified":"1549774133"},{"type":"inline","comment":"At least add a docstring taht explains this is designed to be a similar API to `difflib.unified_diff`?","replyTo":null,"isNewFile":"1","line":"554","lineLength":"0","path":"mercurial\/mdiff.py","diffId":"13123","author":"durin42","id":"82040","dateCreated":"1547133473","dateModified":"1547133473"},{"type":"inline","comment":"unused?","replyTo":null,"isNewFile":"1","line":"54","lineLength":"0","path":"tests\/run-tests.py","diffId":"13123","author":"durin42","id":"82039","dateCreated":"1547133473","dateModified":"1547133473"},{"type":"inline","comment":"unused?","replyTo":null,"isNewFile":"1","line":"50","lineLength":"0","path":"tests\/run-tests.py","diffId":"13123","author":"durin42","id":"82038","dateCreated":"1547133473","dateModified":"1547133473"},{"type":"inline","comment":"Nit: `except (ImportError, AttributeError):` instead of just catching `Exception`.","replyTo":null,"isNewFile":"1","line":"81","lineLength":"0","path":"tests\/run-tests.py","diffId":"13123","author":"durin42","id":"82037","dateCreated":"1547133473","dateModified":"1547133473"},{"type":"update","diffId":"13123","author":"sangeet259","id":"81958","dateCreated":"1547110532","dateModified":"1547110532"},{"type":"comment","comment":">>! In D5514#81800, @sangeet259 wrote:\n> @durin42 So the `try\/except` will fall back to `unified diff`?\n\nCorrect.\n\n> Is there a way we can enforce this on system's that don't have mercurial installed globally and not have to fall back on the earlier practice.\n\nI think we don't have any choice: if hg isn't installed, we have to fall back to the old codepath, since we won't know if mdiff is present.\n\n> \n> Also, I didn't get your comment on checking the API of `mdiff` :\/ \n\nWell, what if we iterate on the API of mdiff.new_diff? then again, if the point of it is to have the same API as difflib.unified_diff, probably don't need to worry (and so we only have to fall back to difflib if mdiff isn't available or is too old).","author":"durin42","id":"81890","dateCreated":"1547066844","dateModified":"1547066844"},{"type":"comment","comment":"@durin42 So the `try\/except` will fall back to `unified diff`?\nIs there a way we can enforce this on system's that don't have mercurial installed globally and not have to fall back on the earlier practice.\n\nAlso, I didn't get your comment on checking the API of `mdiff` :\/ ","author":"sangeet259","id":"81800","dateCreated":"1547021099","dateModified":"1547021099"},{"type":"comment","comment":">If you couldn't follow those steps, you can simply check the diffs here:\n>\n> test's diff: https:\/\/pastebin.com\/Z4LRg4vx\n> diff used by hg diff: https:\/\/pastebin.com\/qanQEsiA\n\nCan you make the diffs a part of commit message since pastebin's pastes can be removed in future?","author":"pulkit","id":"81704","dateCreated":"1546968449","dateModified":"1546968449"},{"type":"inline","comment":"This will fail if Mercurial isn't already globally installed on the machine, as would be the case in at least some packaging circumstances when building from a source tarball.\n\nProbably need a try\/except, and _maybe_ a sanity check that mdiff's API matches what we expect?","replyTo":null,"isNewFile":"1","line":"72","lineLength":"0","path":"tests\/run-tests.py","diffId":"13051","author":"durin42","id":"81701","dateCreated":"1546966076","dateModified":"1546966076"},{"type":"reject","author":"durin42","id":"81700","dateCreated":"1546966076","dateModified":"1546966076"},{"type":"comment","comment":"Note: To see this in action, one needs to add the changes from this `mdiff.py` to the mdiff.py of their installed mercurial.\nThis is because unless you do that, you cannot import `mdiff.new_patch` as that function won't be there in your installed version, and hence it will keep falling back to the `unified_diff`.\n\n\nElse, can it be implemented in any other way.","author":"sangeet259","id":"81572","dateCreated":"1546873561","dateModified":"1546873561"},{"type":"update","diffId":"13051","author":"sangeet259","id":"81571","dateCreated":"1546873153","dateModified":"1546873153"},{"type":"update","diffId":"13050","author":"sangeet259","id":"81566","dateCreated":"1546872835","dateModified":"1546872835"}],"dateCreated":"1546872835","dateModified":"1557907222","status":"Needs Revision"},{"id":"6312","callsign":"HG","title":"branchcache: update the filteredhash if we update the tiprev","author":"pulkit","summary":"We update the tiprev and in next if statement we check whether the branchcache\nis valid or not. If the update of tiprev happens, then definitely\nself.validfor() will return False because filteredhash is old now.\n\nLet's update the filteredhash if we update the tiprev also. This prevents us\nfrom entering the loop where we iter all the heads, and find the tiprev.","testPlan":"","lineCount":"1","dependsOn":[],"reviewers":[],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":">          if ntiprev > self.tiprev:\n>              self.tiprev = ntiprev\n>              self.tipnode = cl.node(ntiprev)\n> +            self.filteredhash = scmutil.filteredhash(repo, self.tiprev)\n>  \n>          if not self.validfor(repo):\n>              # cache key are not valid anymore\n\nand update `self.filteredhash` later again, which smells. Instead, shouldn't\nwe check the validity first, and take the fast path only if it was valid?\n\n```\nif self.validfor(repo):  # was valid, can take fast path\n    self.tiprev = ntiprev\n    self.tipnode = cl.node(ntiprev)\nelse:  # bad luck, recompute tiprev\/tipnode\n    ...\nself.filteredhash = scmutil.filteredhash(repo, self.tiprev)\n```","author":"yuja","id":"91967","dateCreated":"1556440717","dateModified":"1556440717"},{"type":"update","diffId":"14927","author":"pulkit","id":"91837","dateCreated":"1556320974","dateModified":"1556320974"}],"dateCreated":"1556320974","dateModified":"1556440717","status":"Needs Review"},{"id":"6259","callsign":"HG","title":"[POC] revset: on-disk cache for children queries","author":"joerg.sonnenberger","summary":"This is a proof of concept for further discussion.","testPlan":"","lineCount":"137","dependsOn":[],"reviewers":[],"ccs":["martinvonz","indygreg","mercurial-devel"],"actions":[{"type":"comment","comment":"Perhaps we'd want this to not be specifically for revsets? We could also write to it when we write to the changelog to keep it up to date.","author":"martinvonz","id":"91118","dateCreated":"1555507748","dateModified":"1555507748"},{"type":"comment","comment":"For the NetBSD repository, a trivial test with the new cache:\n\n```\ntime hg log -r '1000~-400' -T {node} > \/dev\/null\nreal\t0m1.898s\ntime hg log -r '1000~-400' -T {node} > \/dev\/null\nreal\t0m0.170s\ntime hg log -r '1000~-1' -T {node} > \/dev\/null\nreal\t0m0.166s\ntime hg log -r '440000~-1' -T {node} > \/dev\/null\nreal\t0m0.170s\n```\n\nFirst one includes the time to initially warmup the cache.\n\nWithout the cache:\n```\ntime hg log -r '1000~0' -T {node} > \/dev\/null\nreal\t0m0.196s\ntime hg log -r '1000~-1' -T {node} > \/dev\/null\nreal\t0m0.825s\ntime hg log -r '1000~-2' -T {node} > \/dev\/null\nreal\t0m1.288s\ntime hg log -r '1000~-400' -T {node} > \/dev\/null\nreal\t3m23.201s\ntime hg log -r '440000~-1' -T {node} > \/dev\/null\nreal\t0m0.182s\n```\n\nIn other words, building the cache is amortised by one or two queries for children early up in the tree. The cache still provides a good benefit nearer to tip.","author":"joerg.sonnenberger","id":"91110","dateCreated":"1555505679","dateModified":"1555505679"},{"type":"comment","comment":"Do you have performance numbers to share? Substantial wins would definitely pique my interest :)","author":"indygreg","id":"91066","dateCreated":"1555498467","dateModified":"1555498467"},{"type":"update","diffId":"14789","author":"joerg.sonnenberger","id":"91040","dateCreated":"1555454599","dateModified":"1555454599"}],"dateCreated":"1555454599","dateModified":"1555507748","status":"Needs Review"},{"id":"6027","callsign":"HG","title":"mq: make unshelve to apply on modified mq patch (issue4318)","author":"navaneeth.suresh","summary":"unshelve wasn't working on a modified mq patch. I added checks for\nnot aborting on a modified mq patch in both rebase and mq.\n\nChecking `repo.vfs.exists('unshelverebasestate')` works in rebase,\nnot in mq. I used `cmdutil.unfinishedstates` to find `shelvedstate`\nin mq.","testPlan":"","lineCount":"29","dependsOn":[],"reviewers":["martinvonz"],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"> It doesn't make sense to check the existence of 'shelvedstate' in a static\n> table.\n> \n> Can't we somehow get around the mq in a similar way to shelve.getcommitfunc()?\n> I don't think it's good idea to rely on state files saved on disk.\n\nI felt that the only workaround to stop aborting unshelve on a modified mq patch should be adding a check on `mq.abortifwdirpatched()`. Will try to investigate in `shelve.getcommitfunc()` for sure. Thanks.","author":"navaneeth.suresh","id":"89928","dateCreated":"1553624502","dateModified":"1553624502"},{"type":"comment","comment":"> --- a\/hgext\/mq.py\n> +++ b\/hgext\/mq.py\n> @@ -3518,7 +3518,10 @@\n>                  delattr(self.unfiltered(), r'mq')\n>  \n>          def abortifwdirpatched(self, errmsg, force=False):\n> -            if self.mq.applied and self.mq.checkapplied and not force:\n> +            shelveinprogress = any('shelvedstate' in state\n> +                                    for state in cmdutil.unfinishedstates)\n> +            if (self.mq.applied and self.mq.checkapplied and not force and\n> +                not shelveinprogress):\n\nIt doesn't make sense to check the existence of 'shelvedstate' in a static\ntable.\n\nCan't we somehow get around the mq in a similar way to shelve.getcommitfunc()?\nI don't think it's good idea to rely on state files saved on disk.","author":"yuja","id":"89919","dateCreated":"1553552983","dateModified":"1553552983"},{"type":"comment","comment":"Gentle ping for review.","author":"navaneeth.suresh","id":"89906","dateCreated":"1553450952","dateModified":"1553450952"},{"type":"update","diffId":"14400","author":"navaneeth.suresh","id":"88740","dateCreated":"1552069564","dateModified":"1552069564"},{"type":"comment","comment":"Ping for review.","author":"navaneeth.suresh","id":"88530","dateCreated":"1551851154","dateModified":"1551851154"},{"type":"update","diffId":"14245","author":"navaneeth.suresh","id":"87900","dateCreated":"1551183856","dateModified":"1551183856"}],"dateCreated":"1551183856","dateModified":"1553624502","status":"Needs Review"},{"id":"6123","callsign":"HG","title":"similar: add condition to avoid Zerodivisonerror in function _score() (issue6099)","author":"akshjain.jain74","summary":"","testPlan":"","lineCount":"4","dependsOn":[],"reviewers":["durin42"],"ccs":["av6","pulkit","mercurial-devel"],"actions":[{"type":"inline","comment":"yes actually \ud83d\ude05  i did'nt noticed that ","replyTo":"89412","isNewFile":"1","line":"68","lineLength":"0","path":"mercurial\/similar.py","diffId":"14487","author":"akshjain.jain74","id":"89432","dateCreated":"1552659675","dateModified":"1552659675"},{"type":"update","diffId":"14508","author":"akshjain.jain74","id":"89430","dateCreated":"1552659596","dateModified":"1552659596"},{"type":"comment","comment":"thanks for the review\n","author":"akshjain.jain74","id":"89422","dateCreated":"1552658279","dateModified":"1552658279"},{"type":"comment","comment":">>! In D6123#89410, @pulkit wrote:\n> Can you try to add a test for this?\n\nyes i can definitely try to add test for this ","author":"akshjain.jain74","id":"89421","dateCreated":"1552658267","dateModified":"1552658267"},{"type":"inline","comment":"no need for this else. you can `return 0` without else.","replyTo":null,"isNewFile":"1","line":"68","lineLength":"0","path":"mercurial\/similar.py","diffId":"14487","author":"pulkit","id":"89412","dateCreated":"1552657477","dateModified":"1552657477"},{"type":"inline","comment":"we can do `if lengths:` here.","replyTo":null,"isNewFile":"1","line":"66","lineLength":"0","path":"mercurial\/similar.py","diffId":"14487","author":"pulkit","id":"89411","dateCreated":"1552657477","dateModified":"1552657477"},{"type":"comment","comment":"Can you try to add a test for this?","author":"pulkit","id":"89410","dateCreated":"1552657477","dateModified":"1552657477"},{"type":"update","diffId":"14487","author":"akshjain.jain74","id":"89272","dateCreated":"1552508232","dateModified":"1552508232"},{"type":"comment","comment":"actually  i am not getting what can be the proper topic for this :(","author":"akshjain.jain74","id":"89249","dateCreated":"1552501010","dateModified":"1552501010"},{"type":"comment","comment":"sorry for that , but can you tell me in what condition this function will return none value?","author":"akshjain.jain74","id":"89248","dateCreated":"1552500860","dateModified":"1552500860"},{"type":"inline","comment":"`None > 1` is still an issue, see my comment above.","replyTo":null,"isNewFile":"1","line":"66","lineLength":"1","path":"mercurial\/similar.py","diffId":"14482","author":"av6","id":"89240","dateCreated":"1552500162","dateModified":"1552500162"},{"type":"comment","comment":"Okay, let's go over #1 in https:\/\/www.mercurial-scm.org\/wiki\/ContributingChanges#Submission_checklist once more. If you want to know what a good \"topic\" is, look at what other people do. How patches that get accepted generally look. How bug-fixing commits are worded.\n\nSecondly, about that capitalization. I'm sorry if this is some sort of silly autocorrect that's doing it for you, I really hope you're not writing commit messages on a phone.","author":"av6","id":"89239","dateCreated":"1552500162","dateModified":"1552500162"},{"type":"update","diffId":"14482","author":"akshjain.jain74","id":"89237","dateCreated":"1552498479","dateModified":"1552498479"},{"type":"comment","comment":"Sorry for the various mistake\n I will correct everything in an hour thanks","author":"akshjain.jain74","id":"89222","dateCreated":"1552470438","dateModified":"1552470438"},{"type":"inline","comment":"This returns None in some cases, and code that uses `_score()` and `score()` tries to compare it to an integer. In Python3 `None > 1` raises TypeError.","replyTo":null,"isNewFile":"1","line":"67","lineLength":"0","path":"mercurial\/similar.py","diffId":"14477","author":"av6","id":"89221","dateCreated":"1552469028","dateModified":"1552469028"},{"type":"inline","comment":"This is some... interesting syntax. Is this valid Python?","replyTo":null,"isNewFile":"1","line":"66","lineLength":"1","path":"mercurial\/similar.py","diffId":"14477","author":"av6","id":"89220","dateCreated":"1552468824","dateModified":"1552468824"},{"type":"comment","comment":"I find it troubling that we now have contributors that don't follow #1 in https:\/\/www.mercurial-scm.org\/wiki\/ContributingChanges#Submission_checklist. Potentially #4 too (as Pulkit commented).\n\nSeriously, the title is terrible at describing what this patch fixes and where. The commit message could briefly mention why\/when this condition is even required.","author":"av6","id":"89219","dateCreated":"1552468824","dateModified":"1552468824"},{"type":"comment","comment":"Oh sorry ,my bad  I think that is by mistake I will correct it now\nIthink while committing I added that file by mistake","author":"akshjain.jain74","id":"89217","dateCreated":"1552468624","dateModified":"1552468624"},{"type":"inline","comment":"Is this change required for this patch?","replyTo":null,"isNewFile":"1","line":"1127","lineLength":"0","path":"hgext\/histedit.py","diffId":"14477","author":"pulkit","id":"89214","dateCreated":"1552467285","dateModified":"1552467285"},{"type":"update","diffId":"14477","author":"akshjain.jain74","id":"89176","dateCreated":"1552414170","dateModified":"1552414170"}],"dateCreated":"1552414170","dateModified":"1552659675","status":"Needs Review"},{"id":"6026","callsign":"HG","title":"lock: Improve the waiting for lock message which will help newcomers\n(issue6081)","author":"akshjain.jain74","summary":"","testPlan":"","lineCount":"71","dependsOn":[],"reviewers":[],"ccs":["pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D6026#88552, @pulkit wrote:\n> I am not sure the new message is much helpful. As JordiGH and others pointed out on IRC, it will definitely be helpful if we can show which operation has the lock right now.\n> \n> Something like:\n> \n> `waiting for lock on working directory of b held by process '*' running <cmd-name> on host '*'`\n\nSo for which commands we can show this message, like i got message when i run hg commit --amend sometimes ","author":"akshjain.jain74","id":"88558","dateCreated":"1551900706","dateModified":"1551900706"},{"type":"inline","comment":"I accept these changes while running test,  if i am not changing this then it will cause test failing","replyTo":"88554","isNewFile":"0","line":"18","lineLength":"0","path":"tests\/test-lock-badness.t","diffId":"14277","author":"akshjain.jain74","id":"88557","dateCreated":"1551893473","dateModified":"1551893473"},{"type":"comment","comment":"okay @pulkit let me work upon your suggestion and ","author":"akshjain.jain74","id":"88556","dateCreated":"1551893473","dateModified":"1551893473"},{"type":"inline","comment":"The output is not correctly aligned. ","replyTo":null,"isNewFile":"1","line":"62","lineLength":"0","path":"tests\/test-lock-badness.t","diffId":"14291","author":"pulkit","id":"88555","dateCreated":"1551879636","dateModified":"1551879636"},{"type":"inline","comment":"still here are unrealted changes.","replyTo":"88052","isNewFile":"0","line":"18","lineLength":"0","path":"tests\/test-lock-badness.t","diffId":"14277","author":"pulkit","id":"88554","dateCreated":"1551879636","dateModified":"1551879636"},{"type":"inline","comment":"unrelated changes.","replyTo":null,"isNewFile":"1","line":"155","lineLength":"0","path":"tests\/test-extdiff.t","diffId":"14291","author":"pulkit","id":"88553","dateCreated":"1551879636","dateModified":"1551879636"},{"type":"comment","comment":"I am not sure the new message is much helpful. As JordiGH and others pointed out on IRC, it will definitely be helpful if we can show which operation has the lock right now.\n\nSomething like:\n\n`waiting for lock on working directory of b held by process '*' running <cmd-name> on host '*'`","author":"pulkit","id":"88552","dateCreated":"1551879636","dateModified":"1551879636"},{"type":"update","diffId":"14291","author":"akshjain.jain74","id":"88119","dateCreated":"1551530162","dateModified":"1551530162"},{"type":"comment","comment":"@pulkit done changes as per your suggestion in lock file too but what did you meant by storelock?","author":"akshjain.jain74","id":"88059","dateCreated":"1551392049","dateModified":"1551392049"},{"type":"update","diffId":"14279","author":"akshjain.jain74","id":"88056","dateCreated":"1551391885","dateModified":"1551391885"},{"type":"inline","comment":"unrelated changes in the test file here and below.","replyTo":null,"isNewFile":"0","line":"18","lineLength":"0","path":"tests\/test-lock-badness.t","diffId":"14277","author":"pulkit","id":"88052","dateCreated":"1551389487","dateModified":"1551389487"},{"type":"inline","comment":"remove which file manually to continue?\n\nI think we should delete the `If it still fails, ..... remove the file manually to continue` part.","replyTo":null,"isNewFile":"1","line":"316","lineLength":"0","path":"hgext\/journal.py","diffId":"14277","author":"pulkit","id":"88051","dateCreated":"1551389487","dateModified":"1551389487"},{"type":"inline","comment":"This is only for locking namejournal.lock and not for working directory lock and store lock. We need to improve message there too.","replyTo":null,"isNewFile":"1","line":"310","lineLength":"0","path":"hgext\/journal.py","diffId":"14277","author":"pulkit","id":"88050","dateCreated":"1551389487","dateModified":"1551389487"},{"type":"update","diffId":"14277","author":"akshjain.jain74","id":"88048","dateCreated":"1551388596","dateModified":"1551388596"},{"type":"update","diffId":"14274","author":"akshjain.jain74","id":"88039","dateCreated":"1551376882","dateModified":"1551376882"},{"type":"update","diffId":"14273","author":"akshjain.jain74","id":"88038","dateCreated":"1551373745","dateModified":"1551373745"},{"type":"update","diffId":"14272","author":"akshjain.jain74","id":"88037","dateCreated":"1551373367","dateModified":"1551373367"},{"type":"update","diffId":"14271","author":"akshjain.jain74","id":"88036","dateCreated":"1551373151","dateModified":"1551373151"},{"type":"comment","comment":"Ya I am sending that  just trying to find out the file","author":"akshjain.jain74","id":"87909","dateCreated":"1551191027","dateModified":"1551191027"},{"type":"comment","comment":"This patch does not changes any code. It only changes some test output. You need to change the error message in the code.","author":"pulkit","id":"87908","dateCreated":"1551190913","dateModified":"1551190913"},{"type":"update","diffId":"14244","author":"akshjain.jain74","id":"87894","dateCreated":"1551173448","dateModified":"1551173448"}],"dateCreated":"1551173448","dateModified":"1551900706","status":"Needs Review"},{"id":"6043","callsign":"HG","title":"UnicodeEncoding:change the default encoding of the whole script to be 'UTF-8'\n(issue6040)","author":"akshjain.jain74","summary":"","testPlan":"","lineCount":"23","dependsOn":[],"reviewers":["indygreg"],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"comment","comment":"If we wanted to call `sys.setdefaultencoding()`, we should call it once during `hg` or at the top of `mercurial\/__init__.py`.\n\nBut we don't want to call `sys.setdefaultencoding()`. This topic has been discussed heavily over the years. The various answers at https:\/\/stackoverflow.com\/questions\/3828723\/why-should-we-not-use-sys-setdefaultencodingutf-8-in-a-py-script have a lot of context and I won't rehash the reasons here.\n\nMay I ask what compelled you to want to do this? Any bug you encountered that was fixed by this change represents a place where Mercurial isn't handling encoding properly. We should fix the actual places where that is occurring. Because even if we switch to UTF-8 as the default string encoding, UTF-8 isn't used everywhere and the underlying encoding problem may still exist!\n\nAny patch to introduce `sys.setdefaultencoding()` into the code base will likely never be accepted (unless it is doing something special like what `HGUNICODEPEDANTRY` is doing). So you may want to mark this code review as abandoned.","author":"indygreg","id":"88140","dateCreated":"1551559275","dateModified":"1551559310"},{"type":"reject","author":"indygreg","id":"88139","dateCreated":"1551559275","dateModified":"1551559275"},{"type":"update","diffId":"14292","author":"akshjain.jain74","id":"88121","dateCreated":"1551536157","dateModified":"1551536157"}],"dateCreated":"1551536157","dateModified":"1551559275","status":"Needs Revision"},{"id":"6029","callsign":"HG","title":"Bug 1477205 - Remove the exception when a node is created after closing the AudioContext. r?padenot","author":"vmillet","summary":"","testPlan":"","lineCount":"77","dependsOn":[],"reviewers":[],"ccs":["marmoute","mercurial-devel"],"actions":[{"type":"comment","comment":"Hi Valentin,\n\nIt looks like you are not using the right Phabricator instance. This one is dedicated to the Mercurial projet, not Firefox.","author":"marmoute","id":"87950","dateCreated":"1551270268","dateModified":"1551270268"},{"type":"update","diffId":"14252","author":"vmillet","id":"87940","dateCreated":"1551264426","dateModified":"1551264426"}],"dateCreated":"1551264426","dateModified":"1551270268","status":"Needs Review"},{"id":"5410","callsign":"HG","title":"merge: allow to merge non-conflicting changes outside narrowspec","author":"pulkit","summary":"This patch allows merging of non-conflicting changes outside narrowspec.","testPlan":"","lineCount":"15","dependsOn":[],"reviewers":["durin42","martinvonz"],"ccs":["martinvonz","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D5410#87526, @pulkit wrote:\n>>>! In D5410#85244, @martinvonz wrote:\n>>>>! In D5410#85232, @pulkit wrote:\n>>>>>! In D5410#80207, @martinvonz wrote:\n>>>> I'm pretty sure this doesn't actually perform the merge, it just drops the changes outside the narrowspec. On commit, we need to record that outside\/ has the new nodeid that we got from the side we merged in. To do that, we need to remember what that nodeid is, from the time of `hg merge` to the time of `hg commit`. That probably means storing the nodeid in the dirstate (like git does), or maybe in the merge state.\n>>> \n>>> IIUC, dirstate does not contains files outside narrowspec. Maybe we need to do this in merge state?\n>> \n>> I think neither of them currently contains files outside narrows, so we'd need to extend whichever we decide. It's probably easier to extend the merge state. I'm not sure which I think is cleaner to extend. There's precedent for populating the commit based on the dirstate (index) in git.\n> \n> Or not touch any of them and introduce a new file?\n\nSure, that's another option. It might be the easiest one since it won't involve making the format compatible (although I think that's pretty easy for the merge state).","author":"martinvonz","id":"87557","dateCreated":"1550799377","dateModified":"1550799377"},{"type":"comment","comment":">>! In D5410#85244, @martinvonz wrote:\n>>>! In D5410#85232, @pulkit wrote:\n>>>>! In D5410#80207, @martinvonz wrote:\n>>> I'm pretty sure this doesn't actually perform the merge, it just drops the changes outside the narrowspec. On commit, we need to record that outside\/ has the new nodeid that we got from the side we merged in. To do that, we need to remember what that nodeid is, from the time of `hg merge` to the time of `hg commit`. That probably means storing the nodeid in the dirstate (like git does), or maybe in the merge state.\n>> \n>> IIUC, dirstate does not contains files outside narrowspec. Maybe we need to do this in merge state?\n> \n> I think neither of them currently contains files outside narrows, so we'd need to extend whichever we decide. It's probably easier to extend the merge state. I'm not sure which I think is cleaner to extend. There's precedent for populating the commit based on the dirstate (index) in git.\n\nOr not touch any of them and introduce a new file?","author":"pulkit","id":"87526","dateCreated":"1550768316","dateModified":"1550768316"},{"type":"comment","comment":">>! In D5410#85232, @pulkit wrote:\n>>>! In D5410#80207, @martinvonz wrote:\n>> I'm pretty sure this doesn't actually perform the merge, it just drops the changes outside the narrowspec. On commit, we need to record that outside\/ has the new nodeid that we got from the side we merged in. To do that, we need to remember what that nodeid is, from the time of `hg merge` to the time of `hg commit`. That probably means storing the nodeid in the dirstate (like git does), or maybe in the merge state.\n> \n> IIUC, dirstate does not contains files outside narrowspec. Maybe we need to do this in merge state?\n\nI think neither of them currently contains files outside narrows, so we'd need to extend whichever we decide. It's probably easier to extend the merge state. I'm not sure which I think is cleaner to extend. There's precedent for populating the commit based on the dirstate (index) in git.","author":"martinvonz","id":"85244","dateCreated":"1549297459","dateModified":"1549297459"},{"type":"comment","comment":">>! In D5410#80207, @martinvonz wrote:\n> I'm pretty sure this doesn't actually perform the merge, it just drops the changes outside the narrowspec. On commit, we need to record that outside\/ has the new nodeid that we got from the side we merged in. To do that, we need to remember what that nodeid is, from the time of `hg merge` to the time of `hg commit`. That probably means storing the nodeid in the dirstate (like git does), or maybe in the merge state.\n\nIIUC, dirstate does not contains files outside narrowspec. Maybe we need to do this in merge state?","author":"pulkit","id":"85232","dateCreated":"1549288085","dateModified":"1549288085"},{"type":"comment","comment":"I'm pretty sure this doesn't actually perform the merge, it just drops the changes outside the narrowspec. On commit, we need to record that outside\/ has the new nodeid that we got from the side we merged in. To do that, we need to remember what that nodeid is, from the time of `hg merge` to the time of `hg commit`. That probably means storing the nodeid in the dirstate (like git does), or maybe in the merge state.","author":"martinvonz","id":"80208","dateCreated":"1544539647","dateModified":"1544539647"},{"type":"reject","author":"martinvonz","id":"80207","dateCreated":"1544539647","dateModified":"1544539647"},{"type":"comment","comment":"I am dubiuos that my fix is correct. I went through the history and didn't find any explanation why we don't allow merging non-conflicting changes outside narrowspec except TODO's. @martinvonz do you know why we don't allow merging of non-conflicting changes here?","author":"pulkit","id":"80202","dateCreated":"1544527498","dateModified":"1544527498"},{"type":"update","diffId":"12822","author":"pulkit","id":"80195","dateCreated":"1544527312","dateModified":"1544527312"}],"dateCreated":"1544527312","dateModified":"1550799376","status":"Needs Revision"},{"id":"5941","callsign":"HG","title":"tweakdefault: Add better documentation for ui.tweakdefault\n(issue6000)","author":"akshjain.jain74","summary":"","testPlan":"","lineCount":"8","dependsOn":[],"reviewers":["pulkit"],"ccs":["pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"okay","author":"akshjain.jain74","id":"87031","dateCreated":"1550152045","dateModified":"1550152045"},{"type":"comment","comment":">>! In D5941#87025, @akshjain.jain74 wrote:\n> @pulkit like what else we required to improve the documentation for the issue , in general what tweakdefault do for mercurial is already mention in the issue \ud83e\udd14 \n\nAs commented on the issue, I don't think we need anything more.\n\n(Marking this as Request Changes to move it out of review list)","author":"pulkit","id":"87029","dateCreated":"1550151740","dateModified":"1550151740"},{"type":"reject","author":"pulkit","id":"87028","dateCreated":"1550151740","dateModified":"1550151740"},{"type":"comment","comment":"@pulkit like what else we required to improve the documentation for the issue , in general what tweakdefault do for mercurial is already mention in the issue \ud83e\udd14 ","author":"akshjain.jain74","id":"87025","dateCreated":"1550151448","dateModified":"1550151448"},{"type":"comment","comment":"Hi, thanks for the patch. This is adding just un required churn to help text.","author":"pulkit","id":"87024","dateCreated":"1550150934","dateModified":"1550150934"},{"type":"update","diffId":"14079","author":"akshjain.jain74","id":"86979","dateCreated":"1550088514","dateModified":"1550088514"},{"type":"update","diffId":"14050","author":"akshjain.jain74","id":"86861","dateCreated":"1550002957","dateModified":"1550002957"},{"type":"update","diffId":"14038","author":"akshjain.jain74","id":"86788","dateCreated":"1549912783","dateModified":"1549912783"},{"type":"update","diffId":"14037","author":"akshjain.jain74","id":"86784","dateCreated":"1549912214","dateModified":"1549912214"}],"dateCreated":"1549912214","dateModified":"1550152045","status":"Needs Revision"},{"id":"1937","callsign":"FBHGX","title":"p4fastimport: import purged files as empty files","author":"hollisb","summary":"P4 may preserve only the most recent copy of a file's data, automatically\n\"purging\" the file data from older changelists when a new one is submitted.\nThat data is gone, and can't be accessed even from P4.\n\nWhen importing such a file, we create an empty file so we can record that it\nexisted (e.g. which changelist introduced it).\n\nTherefore, we include it in the list of filelogs we import, and we record that\nchangelists modified the file too. The file just has empty contents in the\nolder changesets.","testPlan":"","lineCount":"56","dependsOn":[],"reviewers":["dsp","durin42","quark","durham"],"ccs":[],"actions":[{"type":"comment","comment":"This is on Facebook's extensions repository, which I don't own. At this point, it probably makes sense to move p4fastimport to its own repository and maintain it there.","author":"durin42","id":"86775","dateCreated":"1549908053","dateModified":"1549908053"},{"type":"resign","author":"durin42","id":"86774","dateCreated":"1549908053","dateModified":"1549908053"},{"type":"comment","comment":"Hi, I still need this. Since my P4 repo has \"purged\" changesets, I can't import without this patch.","author":"hollisb","id":"86773","dateCreated":"1549907549","dateModified":"1549907549"},{"type":"update","diffId":"5001","author":"hollisb","id":"32644","dateCreated":"1516757506","dateModified":"1516757506"}],"dateCreated":"1516757506","dateModified":"1549908576","status":"Needs Review"},{"id":"5812","callsign":"HG","title":"py3: pass str into ValueError to prevent b'' prefix in output","author":"pulkit","summary":"# skip-blame because mostly just r'' prefixes","testPlan":"","lineCount":"24","dependsOn":[],"reviewers":["durin42","martinvonz"],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":">   I am not whether this is correct. This should have fix failure of `test-lfs-serve.t#lfsremote-on` failure on py3 but it does not.\n\nAs you guess, this isn't correct. For example, `_(unicode_sring)` will crash\nif gettext is enabled.\n\nI don't know why ValueError is used extensively in exchange.py and where it's\nsupposed to be caught, but the easiest workaround is to make a ValueError\nsubclass that implements __bytes__.\n\n```\nclass ExchangeValueError(ValueError):\n    __bytes__ = _tobytes\n```","author":"yuja","id":"85203","dateCreated":"1549198102","dateModified":"1549198102"},{"type":"comment","comment":"I am not whether this is correct. This should have fix failure of `test-lfs-serve.t#lfsremote-on` failure on py3 but it does not.","author":"pulkit","id":"85190","dateCreated":"1549196395","dateModified":"1549196395"},{"type":"update","diffId":"13716","author":"pulkit","id":"85179","dateCreated":"1549196017","dateModified":"1549196017"}],"dateCreated":"1549196017","dateModified":"1549198102","status":"Needs Review"},{"id":"5737","callsign":"HG","title":"py3: convert info.name to bytes in subrepo.py","author":"pulkit","summary":"","testPlan":"","lineCount":"5","dependsOn":[],"reviewers":[],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":">          for info in tar:\n> +            infoname = pycompat.bytestr(info.name)\n\nSo `info.name` would come from environment. It's probably better to use\n`encoding.strtolocal()`.","author":"yuja","id":"84402","dateCreated":"1548850912","dateModified":"1548850912"},{"type":"update","diffId":"13559","author":"pulkit","id":"84338","dateCreated":"1548800838","dateModified":"1548800838"}],"dateCreated":"1548800838","dateModified":"1548850912","status":"Needs Review"},{"id":"5632","callsign":"HG","title":"setdiscovery: pass srvheads into partialdiscovery constructor","author":"martinvonz","summary":"I found it hard to follow how disco._undecided was initialized (the\ncall to disco.addbases(srvheads) caused the disco.undecided property\nto be access, which initialized disco._undecided). I think this patch\nmakes it easier.","testPlan":"","lineCount":"18","dependsOn":[],"reviewers":["lothiraldan"],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"This needs updating since it conflicts with changes made on the stable branch.","author":"martinvonz","id":"83763","dateCreated":"1548442886","dateModified":"1548442886"},{"type":"plan-changes","author":"martinvonz","id":"83762","dateCreated":"1548442886","dateModified":"1548442886"},{"type":"update","diffId":"13324","author":"martinvonz","id":"83090","dateCreated":"1547835635","dateModified":"1547835635"}],"dateCreated":"1547835635","dateModified":"1548442886","status":"Changes Planned"},{"id":"5496","callsign":"HG","title":"revset: add \"samebranch\" keyword argument to the merge revset","author":"angel.ezquerra","summary":"By default all merges are shown but if \"samebranch\" is set to False then merges\nwith the same branch (i.e. where both parents belong to the same branch) will\nbe filtered out.\n\nConversely, if \"samebranch\" is set to True then only merges with the same branch\nwill be shown.\n\nThis is useful to visualize at a high level the relationships between different\nbranches and how they are merged with each other.\n\nWith the addition of the merge(withbranch) idiom on a previous revision this\ncould already be done in a quite complicated way, by doing something like:\n\nmerge() and branch(somebranch) and not merge(somebranch)\n\nThis is not very practical ano only works for a single branch. Thus this new\noption is added.","testPlan":"","lineCount":"59","dependsOn":["5495"],"reviewers":[],"ccs":["mharbison72","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":">   Maybe `anonymous`, defaulting to True?\n\nTo all: the default can't be True. It would break the current `merge()`\nrevset behavior. Only viable choice is to set the default to \"don't care\".\n\nAnd I think tri-state bool is confusing in this context. So, IMHO, it's\nbetter to add an argument taking a keyword string specifying constraint\nsuch as `merge(between=\"a-keyword-to-select-merges-of-named-branches\")`.\n\n> That's in the glossary under `Branch, anonymous`, so not technically\n> a merge, but I think it still conveys the point.\n\nI disagree. Merges of the same branch are pretty common if your team preferred\nmerge-based strategy. I wouldn't explicitly call new head pulled from public\nrepo as an anonymous head.\n\nIt can also be wrong if you're using bookmarks.","author":"yuja","id":"83416","dateCreated":"1548247882","dateModified":"1548247882"},{"type":"comment","comment":">>! In D5496#82908, @angel.ezquerra wrote:\n>>>! In D5496#82671, @yuja wrote:\n> \n> Do you mean that the flag should only indicate whether you want to hide the same branch merges? I guess that is OK too, since the main use case for this flag is to hide the merge from the same branch. However I think we should change the flag name then. Perhaps \"hidesame\"? Or \"includesame\" or \"includeself\", defaulting to True? Any ideas?\n\nMaybe `anonymous`, defaulting to True?  That's in the glossary under `Branch, anonymous`, so not technically a merge, but I think it still conveys the point.\n\nI think I have a similar reaction as Yuya, but in the opposite direction- `merge(anonymous=True)` makes me think that's all that's of interest.  So maybe `withanonymous`?\n\nI do like the compactness of:\n\n    merge() => all merges\n    merge(anonymous=True) => only merges with matching (p1, p2) branch names\n    merge(anonymous=False) => only merges with different (p1, p2) branch names\n\nOtherwise finding only anonymous merges is something like `merge() - merge(anonymous=False)`, and it took some thinking to get there with the double negative.\n\nBut I have no idea how well that applies to other things if we set that precedent here, and don't feel that strongly about it.","author":"mharbison72","id":"83200","dateCreated":"1548181703","dateModified":"1548181703"},{"type":"comment","comment":">   > Okay, I didn't notice that. And it's tricky to map `samebranch=False` to\n>   >  \"different branch\" constraint. I would read it as \"I don't care whether\n>   >  the branches are the same or not.\"\n>   >\n>   > We can instead express it as `merge() - merge(samebranch=True)`.\n>   \n>   Do you mean that the flag should only indicate whether you want to hide the same branch merges?\n\nI just mean tri-state bool is confusing. `<whatever>=False` sounds like we\ndon't care about the `<whatever>` condition.\n\n> I guess that is OK too, since the main use case for this flag is to hide the merge from the same branch. However I think we should change the flag name then. Perhaps \"hidesame\"? Or \"includesame\" or \"includeself\", defaulting to True? Any ideas?\n\nIt could be an argument taking a string like `'same'`, but I can't think\nof nice names. What's the best term describing a merge between two named\nbranches?","author":"yuja","id":"83052","dateCreated":"1547734900","dateModified":"1547734900"},{"type":"comment","comment":">>! In D5496#82671, @yuja wrote:\n>>   > `[, samebranch]` or [, samebranch=False]`.\n>>   \n>>   I guess that means:\n>>   \n>>   @predicate('merge([withbranch [, samebranch=None]])', safe=True)\n>>   \n>>   Right? (I realized that it is incorrect to say that samebranch's default value is False).\n> \n> Okay, I didn't notice that. And it's tricky to map `samebranch=False` to\n> \"different branch\" constraint. I would read it as \"I don't care whether\n> the branches are the same or not.\"\n\n>>! In D5496#82671, @yuja wrote:\n>>   > `[, samebranch]` or [, samebranch=False]`.\n>>   \n>>   I guess that means:\n>>   \n>>   @predicate('merge([withbranch [, samebranch=None]])', safe=True)\n>>   \n>>   Right? (I realized that it is incorrect to say that samebranch's default value is False).\n> \n> Okay, I didn't notice that. And it's tricky to map `samebranch=False` to\n> \"different branch\" constraint. I would read it as \"I don't care whether\n> the branches are the same or not.\"\n> \n> We can instead express it as `merge() - merge(samebranch=True)`.\n\nDo you mean that the flag should only indicate whether you want to hide the same branch merges? I guess that is OK too, since the main use case for this flag is to hide the merge from the same branch. However I think we should change the flag name then. Perhaps \"hidesame\"? Or \"includesame\" or \"includeself\", defaulting to True? Any ideas?\n","author":"angel.ezquerra","id":"82908","dateCreated":"1547662268","dateModified":"1547662268"},{"type":"comment","comment":">   > `[, samebranch]` or [, samebranch=False]`.\n>   \n>   I guess that means:\n>   \n>   @predicate('merge([withbranch [, samebranch=None]])', safe=True)\n>   \n>   Right? (I realized that it is incorrect to say that samebranch's default value is False).\n\nOkay, I didn't notice that. And it's tricky to map `samebranch=False` to\n\"different branch\" constraint. I would read it as \"I don't care whether\nthe branches are the same or not.\"\n\nWe can instead express it as `merge() - merge(samebranch=True)`.\n\n>   >   if len(matchfns) == 1:\n>   >       # fast path for common case\n>   >       return subset.filter(matchfn[0], ...)\n>   >   else:\n>   >       return subset.filter(lambda r: all(p(r) for p in matchfn), ...)\n>   \n>   Do you think this makes the code simpler?\n\nYes. The original version was hard to find all possible call paths.\nSeparate function per constraint is easier to follow.\n\n> In any case, if you think this approach is best I can do it, but perhaps it would be a little better to keep a single subset.filter call as follows:\n>   \n>     if len(matchfns) == 1:\n>         finalmatchfn = matchfns[0]\n>     else:\n>         finalmatchfn = lambda r: all(p(r) for p in matchfns)\n>     return subset.filter(finalmatchfn, condrepr='<merge>')\n\nI don't care about these differences.","author":"yuja","id":"82671","dateCreated":"1547644201","dateModified":"1547644201"},{"type":"comment","comment":">>! In D5496#82394, @yuja wrote:\n>> -@predicate('merge(withbranch)', safe=True)\n>> +@predicate('merge(withbranch, samebranch=True)', safe=True)\n> \n> `[, samebranch]` or [, samebranch=False]`.\n\nI guess that means:\n\n@predicate('merge([withbranch [, samebranch=None]])', safe=True)\n\nRight? (I realized that it is incorrect to say that samebranch's default value is False).\n\n>>      withbranch = ''\n>>      if 'withbranch' in args:\n>>          withbranch = getstring(args['withbranch'],\n>>                                 _('withbranch argument must be a string'))\n>>          kind, branchname, branchmatcher = stringutil.stringmatcher(withbranch)\n>> +    samebranch = None\n>> +    if 'samebranch' in args:\n>> +        # i18n: \"samebranch\" is a keyword\n>> +        samebranch = getboolean(args['samebranch'],\n>> +            _('samebranch argument must be a True or False'))\n>>      cl = repo.changelog\n>>      # create the function that will be used to filter the subset\n>>      if withbranch:\n>>          # matchfn is a function that returns true when a revision\n>>          # is a merge and the second parent belongs to a branch that\n>>          # matches the withbranch pattern (which can be a literal or a regex)\n>>          if kind == 'literal':\n>> -            matchfn = lambda r: (cl.parentrevs(r)[1] != -1\n>> -                                 and repo[r].p2().branch() == withbranch)\n>> +            basematchfn = lambda r: (cl.parentrevs(r)[1] != -1\n>> +                                     and repo[r].p2().branch() == withbranch)\n>>          else:\n>> -            matchfn = lambda r: (cl.parentrevs(r)[1] != -1\n>> -                                 and branchmatcher(repo[r].p2().branch()))\n>> -    else:\n>> -        # matchfn is a function that returns true when a revision is a merge\n>> -        matchfn = lambda r: cl.parentrevs(r)[1] != -1\n>> +            basematchfn = lambda r: (cl.parentrevs(r)[1] != -1\n>> +                                     and branchmatcher(repo[r].p2().branch()))\n>> +    else:\n>> +        basematchfn = lambda r: cl.parentrevs(r)[1] != -1\n>> +    if samebranch is None:\n>> +        matchfn = basematchfn\n>> +    else:\n>> +        # if samebranch was specified, build a new match function\n>> +        # that on top of basematch checks if the parents belong (or not)\n>> +        # to the same branch (depending on the value of samebranch)\n>> +        def matchfn(r):\n>> +            c = repo[r]\n>> +            if not basematchfn(r):\n>> +                return False\n>> +            issamebranchmerge = c.p1().branch() == c.p2().branch()\n>> +            return issamebranchmerge if samebranch else not issamebranchmerge\n> \n> These conditions can be formed as followed:\n> \n> ```\n> matchfns = [lambda r: cl.parentrevs(r)[1] != -1]\n> if withbranch:\n>     matchfns.append(lambda r: branchmatcher(repo[r].p2().branch()))\n> if samebranch:\n>     matchfns.append(samebranchmatchfn)\n> \n> if len(matchfns) == 1:\n>     # fast path for common case\n>     return subset.filter(matchfn[0], ...)\n> else:\n>     return subset.filter(lambda r: all(p(r) for p in matchfn), ...)\n> ```\n\nDo you think this makes the code simpler? In any case, if you think this approach is best I can do it, but perhaps it would be a little better to keep a single subset.filter call as follows:\n\n```\nif len(matchfns) == 1:\n    finalmatchfn = matchfns[0]\nelse:\n    finalmatchfn = lambda r: all(p(r) for p in matchfns)\nreturn subset.filter(finalmatchfn, condrepr='<merge>')\n```\n\nWhat do you think?\n","author":"angel.ezquerra","id":"82562","dateCreated":"1547596927","dateModified":"1547596927"},{"type":"update","diffId":"13211","author":"angel.ezquerra","id":"82415","dateCreated":"1547508409","dateModified":"1547508409"},{"type":"comment","comment":"> -@predicate('merge(withbranch)', safe=True)\n> +@predicate('merge(withbranch, samebranch=True)', safe=True)\n\n`[, samebranch]` or [, samebranch=False]`.\n\n>      withbranch = ''\n>      if 'withbranch' in args:\n>          withbranch = getstring(args['withbranch'],\n>                                 _('withbranch argument must be a string'))\n>          kind, branchname, branchmatcher = stringutil.stringmatcher(withbranch)\n> +    samebranch = None\n> +    if 'samebranch' in args:\n> +        # i18n: \"samebranch\" is a keyword\n> +        samebranch = getboolean(args['samebranch'],\n> +            _('samebranch argument must be a True or False'))\n>      cl = repo.changelog\n>      # create the function that will be used to filter the subset\n>      if withbranch:\n>          # matchfn is a function that returns true when a revision\n>          # is a merge and the second parent belongs to a branch that\n>          # matches the withbranch pattern (which can be a literal or a regex)\n>          if kind == 'literal':\n> -            matchfn = lambda r: (cl.parentrevs(r)[1] != -1\n> -                                 and repo[r].p2().branch() == withbranch)\n> +            basematchfn = lambda r: (cl.parentrevs(r)[1] != -1\n> +                                     and repo[r].p2().branch() == withbranch)\n>          else:\n> -            matchfn = lambda r: (cl.parentrevs(r)[1] != -1\n> -                                 and branchmatcher(repo[r].p2().branch()))\n> -    else:\n> -        # matchfn is a function that returns true when a revision is a merge\n> -        matchfn = lambda r: cl.parentrevs(r)[1] != -1\n> +            basematchfn = lambda r: (cl.parentrevs(r)[1] != -1\n> +                                     and branchmatcher(repo[r].p2().branch()))\n> +    else:\n> +        basematchfn = lambda r: cl.parentrevs(r)[1] != -1\n> +    if samebranch is None:\n> +        matchfn = basematchfn\n> +    else:\n> +        # if samebranch was specified, build a new match function\n> +        # that on top of basematch checks if the parents belong (or not)\n> +        # to the same branch (depending on the value of samebranch)\n> +        def matchfn(r):\n> +            c = repo[r]\n> +            if not basematchfn(r):\n> +                return False\n> +            issamebranchmerge = c.p1().branch() == c.p2().branch()\n> +            return issamebranchmerge if samebranch else not issamebranchmerge\n\nThese conditions can be formed as followed:\n\n```\nmatchfns = [lambda r: cl.parentrevs(r)[1] != -1]\nif withbranch:\n    matchfns.append(lambda r: branchmatcher(repo[r].p2().branch()))\nif samebranch:\n    matchfns.append(samebranchmatchfn)\n\nif len(matchfns) == 1:\n    # fast path for common case\n    return subset.filter(matchfn[0], ...)\nelse:\n    return subset.filter(lambda r: all(p(r) for p in matchfn), ...)\n```","author":"yuja","id":"82395","dateCreated":"1547435478","dateModified":"1547435478"},{"type":"update","diffId":"13205","author":"angel.ezquerra","id":"82389","dateCreated":"1547419525","dateModified":"1547419525"},{"type":"update","diffId":"13018","author":"angel.ezquerra","id":"81361","dateCreated":"1546801412","dateModified":"1546801412"}],"dateCreated":"1546801412","dateModified":"1548247882","status":"Needs Review"},{"id":"5495","callsign":"HG","title":"revset: add \"branch\" positional arguments to the merge revset","author":"angel.ezquerra","summary":"Make it possible to only include those merge revisions that are merges with one\nor more specific branches (passed as a positional argument that can receive\neither a single branch name or a regular expression). All merge revisions are\nshown by default (i.e. if no \"merge with\" branch or expression is specified).","testPlan":"","lineCount":"124","dependsOn":[],"reviewers":[],"ccs":["mharbison72","mjpieters","lothiraldan","pulkit","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"Thank you Matt. I just did that.\n\nCheers,\n\nAngel","author":"angel.ezquerra","id":"82634","dateCreated":"1547625859","dateModified":"1547625859"},{"type":"comment","comment":">>! In D5495#82416, @angel.ezquerra wrote:\n> I've sent an updated set of patches, following your recommendations. There are 2 patches now, since each includes its own tests. This means that the 3rd patch on the original patch set is no longer needed. However I don't know what is the best way to tell that to phabricator...\n\nI think you should be able to go to that 3rd patch, and set it to abandoned in the actions at the bottom.\n\n\n","author":"mharbison72","id":"82590","dateCreated":"1547618397","dateModified":"1547618397"},{"type":"comment","comment":">>! In D5495#82397, @yuja wrote:\n> Generally looks good.\n> \n> Can you fix a couple of nits? And if possible, fold the tests from D5577\n> into this and the next patch. We prefer including relevant test in each\n> commit.\n> \n>> -@predicate('merge()', safe=True)\n>> +@predicate('merge(withbranch)', safe=True)\n> \n> `merge([withbranch])` as it is an optional parameter.\n> \n>>  def merge(repo, subset, x):\n>> -    \"\"\"Changeset is a merge changeset.\n>> +    \"\"\"Changeset is a merge changeset\n>> +\n>> +    All merge revisions are returned by default. If a \"withbranch\"\n>> +    pattern is provided only merges with (i.e. whose second parent\n>> +    belongs to) those branches that match the pattern will be returned.\n>> +    The simplest pattern is the name of a single branch. It is also\n>> +    possible to specify a regular expression by starting the pattern\n>> +    with \"re:\". This can be used to match more than one branch\n>> +    (e.g. \"re:branch1|branch2\").\n>>      \"\"\"\n>>      # i18n: \"merge\" is a keyword\n>> -    getargs(x, 0, 0, _(\"merge takes no arguments\"))\n>> +    args = getargsdict(x, 'merge', 'withbranch')\n>> +    withbranch = ''\n>> +    if 'withbranch' in args:\n>> +        withbranch = getstring(args['withbranch'],\n>> +                               _('withbranch argument must be a string'))\n>> +        kind, branchname, branchmatcher = stringutil.stringmatcher(withbranch)\n> \n> Can you merge this with the next `if withbranch:` block to reduce the number\n> of conditionally defined variables referenced later?\n> \n>>      cl = repo.changelog\n>> -    return subset.filter(lambda r: cl.parentrevs(r)[1] != -1,\n>> -                         condrepr='<merge>')\n>> +    # create the function that will be used to filter the subset\n>> +    if withbranch:\n> \n>> +        # matchfn is a function that returns true when a revision\n>> +        # is a merge and the second parent belongs to a branch that\n>> +        # matches the withbranch pattern (which can be a literal or a regex)\n> \n> Nit: these comments seem a bit verbose. It's documented in stringmatcher().\n> \n>> +        if kind == 'literal':\n>> +            matchfn = lambda r: (cl.parentrevs(r)[1] != -1\n>> +                                 and repo[r].p2().branch() == withbranch)\n>> +        else:\n>> +            matchfn = lambda r: (cl.parentrevs(r)[1] != -1\n>> +                                 and branchmatcher(repo[r].p2().branch()))\n> \n> If we don't have anything special about the `literal` kind, we can always use\n> the `branchmatcher()`. `if kind == 'literal'` isn't needed.\n\n\n\n>>! In D5495#82407, @yuja wrote:\n>>   What about making the argument a revset instead of a branch name. You can get the same result `merge(branch(\"foo\")` but have a more expressive result `merge(only(4.8, 4.7))` ?\n> \n> That's basically a simpler form of my `filter()` proposal.\n> \n> The problem of `merge(branch(\"foo\"))` is that it's ambiguous which revision\n> the expression will be tested against. It could be expressed as\n> `merge(p2=branch(\"foo\"))` to disambiguate, but this syntax isn't generic\n> enough to express the `samebranch=True` constraint. So if we want a truly\n> expressive syntax, we'll need something like a lambda function.\n> \n> ```\n> filtereach(merge(), p2(_) & branch(\"foo\"))\n> filtereach(merge(), samebranch(parents(_))\n> ```\n> \n> I agreed with Angel in that `merge(withbranch=name)` would be useful enough\n> to have a dedicated syntax, but I'm open to other ideas like\n> `merge(p1=expr, p2=expr)`.\n\n@lothiraldan , your proposal is interesting but as @yuja said it is less generic that introducing a full blown filter function. Also, to be really flexible it would require some way to refer to the p2 revision (i.e. you'd need to introduce an implicit or explicit reference to each of the p1 or p2 revisions). I think this would make the syntax for the most common use cases that I want to cover too complex. That being said, the proposed syntax leaves open the door for introducing such revset based filtering in the future if needed (although I think that a generic filter function would be more useful).\n\n@yuja  , I've sent an updated set of patches, following your recommendations. There are 2 patches now, since each includes its own tests. This means that the 3rd patch on the original patch set is no longer needed. However I don't know what is the best way to tell that to phabricator...","author":"angel.ezquerra","id":"82416","dateCreated":"1547509014","dateModified":"1547509014"},{"type":"update","diffId":"13210","author":"angel.ezquerra","id":"82413","dateCreated":"1547508400","dateModified":"1547508400"},{"type":"comment","comment":">   What about making the argument a revset instead of a branch name. You can get the same result `merge(branch(\"foo\")` but have a more expressive result `merge(only(4.8, 4.7))` ?\n\nThat's basically a simpler form of my `filter()` proposal.\n\nThe problem of `merge(branch(\"foo\"))` is that it's ambiguous which revision\nthe expression will be tested against. It could be expressed as\n`merge(p2=branch(\"foo\"))` to disambiguate, but this syntax isn't generic\nenough to express the `samebranch=True` constraint. So if we want a truly\nexpressive syntax, we'll need something like a lambda function.\n\n```\nfiltereach(merge(), p2(_) & branch(\"foo\"))\nfiltereach(merge(), samebranch(parents(_))\n```\n\nI agreed with Angel in that `merge(withbranch=name)` would be useful enough\nto have a dedicated syntax, but I'm open to other ideas like\n`merge(p1=expr, p2=expr)`.","author":"yuja","id":"82407","dateCreated":"1547472644","dateModified":"1547472644"},{"type":"comment","comment":"What about making the argument a revset instead of a branch name. You can get the same result `merge(branch(\"foo\")` but have a more expressive result `merge(only(4.8, 4.7))` ?\n\n(Sorry to be a bit late to the party) ","author":"lothiraldan","id":"82404","dateCreated":"1547468468","dateModified":"1547468468"},{"type":"comment","comment":"Generally looks good.\n\nCan you fix a couple of nits? And if possible, fold the tests from D5577\ninto this and the next patch. We prefer including relevant test in each\ncommit.\n\n> -@predicate('merge()', safe=True)\n> +@predicate('merge(withbranch)', safe=True)\n\n`merge([withbranch])` as it is an optional parameter.\n\n>  def merge(repo, subset, x):\n> -    \"\"\"Changeset is a merge changeset.\n> +    \"\"\"Changeset is a merge changeset\n> +\n> +    All merge revisions are returned by default. If a \"withbranch\"\n> +    pattern is provided only merges with (i.e. whose second parent\n> +    belongs to) those branches that match the pattern will be returned.\n> +    The simplest pattern is the name of a single branch. It is also\n> +    possible to specify a regular expression by starting the pattern\n> +    with \"re:\". This can be used to match more than one branch\n> +    (e.g. \"re:branch1|branch2\").\n>      \"\"\"\n>      # i18n: \"merge\" is a keyword\n> -    getargs(x, 0, 0, _(\"merge takes no arguments\"))\n> +    args = getargsdict(x, 'merge', 'withbranch')\n> +    withbranch = ''\n> +    if 'withbranch' in args:\n> +        withbranch = getstring(args['withbranch'],\n> +                               _('withbranch argument must be a string'))\n> +        kind, branchname, branchmatcher = stringutil.stringmatcher(withbranch)\n\nCan you merge this with the next `if withbranch:` block to reduce the number\nof conditionally defined variables referenced later?\n\n>      cl = repo.changelog\n> -    return subset.filter(lambda r: cl.parentrevs(r)[1] != -1,\n> -                         condrepr='<merge>')\n> +    # create the function that will be used to filter the subset\n> +    if withbranch:\n\n> +        # matchfn is a function that returns true when a revision\n> +        # is a merge and the second parent belongs to a branch that\n> +        # matches the withbranch pattern (which can be a literal or a regex)\n\nNit: these comments seem a bit verbose. It's documented in stringmatcher().\n\n> +        if kind == 'literal':\n> +            matchfn = lambda r: (cl.parentrevs(r)[1] != -1\n> +                                 and repo[r].p2().branch() == withbranch)\n> +        else:\n> +            matchfn = lambda r: (cl.parentrevs(r)[1] != -1\n> +                                 and branchmatcher(repo[r].p2().branch()))\n\nIf we don't have anything special about the `literal` kind, we can always use\nthe `branchmatcher()`. `if kind == 'literal'` isn't needed.","author":"yuja","id":"82397","dateCreated":"1547435479","dateModified":"1547435479"},{"type":"update","diffId":"13204","author":"angel.ezquerra","id":"82387","dateCreated":"1547419518","dateModified":"1547419518"},{"type":"comment","comment":">   This would not make it possible to select multiple \"merged with\" branches by doing: hg log -r \"merge(feature1, feature2)\"\n>   Instead I guess you are proposing that for that use case we force the user to do: hg log -r \"merge('re:(feature1|feature2)')\n>   \n>   Did I understand you correctly?\n\nYes. And we can introduce other prefixes of string matcher if `re:` seemed\nunnecessarily complex.\n\nEDIT: or introduce `merge(withbranch=(foo, bar))` syntax. This works, but is really new\nsyntax so I don't want to go this way at this point.","author":"yuja","id":"82310","dateCreated":"1547259824","dateModified":"1547260148"},{"type":"comment","comment":">>! In D5495#82036, @yuja wrote:\n>>   I think it would be a good idea to make the \"branch\" arguments more flexible. One option could be to use a stringmatcher to add support for regular expressions as you suggest. I can look into that. However there may be some other options worth exploring. The one you suggest is very interesting although I find the syntax a bit complicated for the common use cases that I want to enable which are:\n>>   \n>>   1. Ignore merges from the same branch, which in a named-branch based branching strategy are usually irrelevant\n>>   2. Look into merges with a specific branch (e.g. which branches have been merged with the default branch)?\n>>   \n>>   In my experience those two are the ones that are the most common and I think we should try to make the easy to use. That is, I think that even if mercurial had a filter function like the one you propose I would still want to be able to express those 2 common merge properties in a simple way.\n> \n> Yep, I agree with that.\n> \n>>   That being said, I really like your idea since I often find myself being unable to express what I want with a revset (as powerful as those are) because of the lack of a filtering mechanism. Adding a generic filter function would be very useful indeed. I'm not sure if the syntax you propose would work as is though. It seems that it would need a new \"&\" operator? In any case I believe that it is out of the scope of this particular set of patches. Do you agree?\n> \n> Yes. Actually I have a PoC-level implementation of generic filtering predicate,\n> which can be reviewed separately.\n> \n>> If so I can focus on improving this patch by adding the stringmatcher as you suggest (as it seems I'm not the only one who thinks this would be useful). Is that ok?\n> \n> Sounds good to me. To be clear, I want `'withbranch'` instead of\n> `'*withbranch'`, because the withbranch option doesn't look like a first-class\n> parameter of the `merge()` predicate.\n\nThis would not make it possible to select multiple \"merged with\" branches by doing: hg log -r \"merge(feature1, feature2)\"\nInstead I guess you are proposing that for that use case we force the user to do: hg log -r \"merge('re:(feature1|feature2)')\n\nDid I understand you correctly?","author":"angel.ezquerra","id":"82291","dateCreated":"1547248200","dateModified":"1547248200"},{"type":"comment","comment":">   I think it would be a good idea to make the \"branch\" arguments more flexible. One option could be to use a stringmatcher to add support for regular expressions as you suggest. I can look into that. However there may be some other options worth exploring. The one you suggest is very interesting although I find the syntax a bit complicated for the common use cases that I want to enable which are:\n>   \n>   1. Ignore merges from the same branch, which in a named-branch based branching strategy are usually irrelevant\n>   2. Look into merges with a specific branch (e.g. which branches have been merged with the default branch)?\n>   \n>   In my experience those two are the ones that are the most common and I think we should try to make the easy to use. That is, I think that even if mercurial had a filter function like the one you propose I would still want to be able to express those 2 common merge properties in a simple way.\n\nYep, I agree with that.\n\n>   That being said, I really like your idea since I often find myself being unable to express what I want with a revset (as powerful as those are) because of the lack of a filtering mechanism. Adding a generic filter function would be very useful indeed. I'm not sure if the syntax you propose would work as is though. It seems that it would need a new \"&\" operator? In any case I believe that it is out of the scope of this particular set of patches. Do you agree?\n\nYes. Actually I have a PoC-level implementation of generic filtering predicate,\nwhich can be reviewed separately.\n\n> If so I can focus on improving this patch by adding the stringmatcher as you suggest (as it seems I'm not the only one who thinks this would be useful). Is that ok?\n\nSounds good to me. To be clear, I want `'withbranch'` instead of\n`'*withbranch'`, because the withbranch option doesn't look like a first-class\nparameter of the `merge()` predicate.","author":"yuja","id":"82036","dateCreated":"1547126177","dateModified":"1547126177"},{"type":"comment","comment":">>! In D5495#81562, @yuja wrote:\n>> +@predicate('merge(*withbranch)', safe=True)\n>>  def merge(repo, subset, x):\n>> -    \"\"\"Changeset is a merge changeset.\n>> +    \"\"\"Changeset is a merge changeset\n>> +\n>> +    All merge revisions are returned by default. If one or more \"withbranch\"\n>> +    names are provided only merges with those branches (i.e. whose\n>> +    second parent belongs to one of those branches) will be returned.\n> \n> I understand this will be useful in a certain branch strategy, but the\n> proposed syntax is hardly extensible. Maybe it can be a non-wildcard argument\n> of `stringmatcher` type so we can at least add another option later.\n>\n> Any thoughts? Do anyone love this feature?\n> \n> If we had a syntax to filter revisions by sub expression, this and the\n> samebranch option could be expressed as follows:\n> \n> ```\n> merge() & filter($a, p2($a) & branch(\"...\"))\n> merge() & filter($a, samebranch(parents($a)))\n> \n> where filter(argname, boolean-expr)\n> ```\n> \n> This is much more expressive (or verbose) and can support other types of\n> branches, but is hard to implement.\n\nThank you for the review, @yuja \n\nI think it would be a good idea to make the \"branch\" arguments more flexible. One option could be to use a stringmatcher to add support for regular expressions as you suggest. I can look into that. However there may be some other options worth exploring. The one you suggest is very interesting although I find the syntax a bit complicated for the common use cases that I want to enable which are:\n\n1. Ignore merges from the same branch, which in a named-branch based branching strategy are usually irrelevant\n2. Look into merges with a specific branch (e.g. which branches have been merged with the default branch)?\n\nIn my experience those two are the ones that are the most common and I think we should try to make the easy to use. That is, I think that even if mercurial had a filter function like the one you propose I would still want to be able to express those 2 common merge properties in a simple way.\n\nThat being said, I really like your idea since I often find myself being unable to express what I want with a revset (as powerful as those are) because of the lack of a filtering mechanism. Adding a generic filter function would be very useful indeed. I'm not sure if the syntax you propose would work as is though. It seems that it would need a new \"&\" operator? In any case I believe that it is out of the scope of this particular set of patches. Do you agree? If so I can focus on improving this patch by adding the stringmatcher as you suggest (as it seems I'm not the only one who thinks this would be useful). Is that ok?\n","author":"angel.ezquerra","id":"81915","dateCreated":"1547076060","dateModified":"1547076060"},{"type":"comment","comment":">>! In D5495#81562, @yuja wrote:\n>> +@predicate('merge(*withbranch)', safe=True)\n>>  def merge(repo, subset, x):\n>> -    \"\"\"Changeset is a merge changeset.\n>> +    \"\"\"Changeset is a merge changeset\n>> +\n>> +    All merge revisions are returned by default. If one or more \"withbranch\"\n>> +    names are provided only merges with those branches (i.e. whose\n>> +    second parent belongs to one of those branches) will be returned.\n> \n> I understand this will be useful in a certain branch strategy, but the\n> proposed syntax is hardly extensible. Maybe it can be a non-wildcard argument\n> of `stringmatcher` type so we can at least add another option later.\n> \n> Any thoughts? Do anyone love this feature?\n\nI like this feature as it will be quite useful for us. Also I like your filter() suggestion more than the syntax this series introduces.","author":"pulkit","id":"81688","dateCreated":"1546949106","dateModified":"1546949106"},{"type":"comment","comment":"> +@predicate('merge(*withbranch)', safe=True)\n>  def merge(repo, subset, x):\n> -    \"\"\"Changeset is a merge changeset.\n> +    \"\"\"Changeset is a merge changeset\n> +\n> +    All merge revisions are returned by default. If one or more \"withbranch\"\n> +    names are provided only merges with those branches (i.e. whose\n> +    second parent belongs to one of those branches) will be returned.\n\nI understand this will be useful in a certain branch strategy, but the\nproposed syntax is hardly extensible. Maybe it can be a non-wildcard argument\nof `stringmatcher` type so we can at least add another option later.\n\nAny thoughts? Do anyone love this feature?\n\nIf we had a syntax to filter revisions by sub expression, this and the\nsamebranch option could be expressed as follows:\n\n```\nmerge() & filter($a, p2($a) & branch(\"...\"))\nmerge() & filter($a, samebranch(parents($a)))\n\nwhere filter(argname, boolean-expr)\n```\n\nThis is much more expressive (or verbose) and can support other types of\nbranches, but is hard to implement.","author":"yuja","id":"81563","dateCreated":"1546870648","dateModified":"1546870648"},{"type":"update","diffId":"13017","author":"angel.ezquerra","id":"81355","dateCreated":"1546801405","dateModified":"1546801405"}],"dateCreated":"1546801405","dateModified":"1547625859","status":"Needs Review"},{"id":"5565","callsign":"HG","title":"revlog: add version 2 format flag to control sparse","author":"indygreg","summary":"Revlog behavior should live as close to the revlog as possible.\nIn version 1 revlogs, we engaged sparse semantics by using a\nrepository requirement. This constituted action at a distance\nand wasn't optimal.\n\nThis commit introduces a feature flag on version 2 revlogs that\nexplicitly denotes whether sparse reading semantics are enabled.\n\nThe flag is enabled by default for version 2 revlogs.\n\nIn order to get the flag enabled by default, we had to tweak\nlocalrepo's logic for populating opener options to only set\n\"sparse-revlog\" if the requirement was present. This lets the\nrevlog initializer use sane defaults depending on the revlog\nversion. (The interaction between opener options and the revlog\nclass is kinda wonky and could use a re-think. But my little\nbrain isn't prepared to handle that at this time.)\n\nI'm also a bit unsure why we have 2 attributes controlling\nsparse behavior (revlog._sparserevlog and revlog._withsparseread).\nI *think* they can be consolidated. But I'm not sure. The new\nrevlog feature flag implies both, which seems reasonable.","testPlan":"","lineCount":"44","dependsOn":[],"reviewers":[],"ccs":["lothiraldan","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D5565#82224, @lothiraldan wrote:\n> Why have a flag for revlog v2 at all? Since v2 have not been \"released\"\n> yet, why not use sparse-revlog logic in all case when using revlog v2?\n\nThat's a good point and I'm glad you weighed in on this. I meant to ask that question in the commit message!\n\nIf we don't have a good reason to disable sparse revlogs, I'd be OK removing the feature flag and implying the feature by default. I'll update this commit accordingly unless others object to making is always on.\n\n> The revlog._sparserevlog flag enables sparse writing (and reading),\n> writing sparse revlog requires readers to use sparse-reading and is\n> gated behind a new requirement (introduced in hg 4.7).\n> \n> Sparse-reading can be used for non-sparse repositories, it is just a\n> reader thing.\n\nThank you for clarifying this! It might be useful to have this better documented in the code...","author":"indygreg","id":"82293","dateCreated":"1547248288","dateModified":"1547248288"},{"type":"plan-changes","author":"indygreg","id":"82292","dateCreated":"1547248288","dateModified":"1547248288"},{"type":"comment","comment":"> Revlog behavior should live as close to the revlog as possible.\n> In version 1 revlogs, we engaged sparse semantics by using a\n> repository requirement. This constituted action at a distance\n> and wasn't optimal.\n> \n> This commit introduces a feature flag on version 2 revlogs that\n> explicitly denotes whether sparse reading semantics are enabled.\n\nWhy have a flag for revlog v2 at all? Since v2 have not been \"released\"\nyet, why not use sparse-revlog logic in all case when using revlog v2? \n\n> \n> The flag is enabled by default for version 2 revlogs.\n> \n> In order to get the flag enabled by default, we had to tweak\n> localrepo's logic for populating opener options to only set\n> \"sparse-revlog\" if the requirement was present. This lets the\n> revlog initializer use sane defaults depending on the revlog\n> version. (The interaction between opener options and the revlog\n> class is kinda wonky and could use a re-think. But my little\n> brain isn't prepared to handle that at this time.)\n> \n> I'm also a bit unsure why we have 2 attributes controlling\n> sparse behavior (revlog._sparserevlog and revlog._withsparseread).\n> I *think* they can be consolidated. But I'm not sure. The new\n> revlog feature flag implies both, which seems reasonable.\n\nThe revlog._sparserevlog flag enables sparse writing (and reading),\nwriting sparse revlog requires readers to use sparse-reading and is\ngated behind a new requirement (introduced in hg 4.7).\n\nSparse-reading can be used for non-sparse repositories, it is just a\nreader thing.\n","author":"lothiraldan","id":"82225","dateCreated":"1547201188","dateModified":"1547201188"},{"type":"update","diffId":"13161","author":"indygreg","id":"82180","dateCreated":"1547166755","dateModified":"1547166755"}],"dateCreated":"1547166755","dateModified":"1547248288","status":"Changes Planned"},{"id":"5567","callsign":"HG","title":"revlog: assign revlog._io in version lookup conditional","author":"indygreg","summary":"A single version lookup is desirable.","testPlan":"","lineCount":"9","dependsOn":["5566"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"13163","author":"indygreg","id":"82200","dateCreated":"1547166761","dateModified":"1547166761"}],"dateCreated":"1547166761","dateModified":"1547166762","status":"Needs Review"},{"id":"5566","callsign":"HG","title":"revlog: rename revlog I\/O classes to reflect version (API)","author":"indygreg","summary":"I never liked these names. They imply the existence of exactly\n2 revlog versions. We're hacking on version 2. So let's\nintroduce better names.","testPlan":"","lineCount":"14","dependsOn":["5565"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"13162","author":"indygreg","id":"82190","dateCreated":"1547166758","dateModified":"1547166758"}],"dateCreated":"1547166758","dateModified":"1547166761","status":"Needs Review"},{"id":"5539","callsign":"HG","title":"style: run yapf on a subset of mercurial","author":"durin42","summary":"I've tried to pick knobs that more or less conform to our current\nstyle. I ran the formatter on the same set of files as the black\nproposal (see D5064), but it resulted in many fewer edits.","testPlan":"","lineCount":"171","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"inline","comment":"We could force this to one-per-line by adding a trailing comma.","replyTo":null,"isNewFile":"1","line":"53","lineLength":"0","path":"mercurial\/scmwindows.py","diffId":"13110","author":"durin42","id":"81887","dateCreated":"1547066206","dateModified":"1547066206"},{"type":"inline","comment":"yapf bug here, filed as https:\/\/github.com\/google\/yapf\/issues\/662","replyTo":null,"isNewFile":"1","line":"57","lineLength":"1","path":"mercurial\/minifileset.py","diffId":"13110","author":"durin42","id":"81886","dateCreated":"1547066206","dateModified":"1547066206"},{"type":"comment","comment":"I see a few minor issues here, but it's at least plausible?","author":"durin42","id":"81885","dateCreated":"1547066206","dateModified":"1547066206"},{"type":"update","diffId":"13110","author":"durin42","id":"81877","dateCreated":"1547065732","dateModified":"1547065732"}],"dateCreated":"1547065732","dateModified":"1547066206","status":"Needs Review"},{"id":"5503","callsign":"HG","title":"vfs: add support for repo names with `$` when using with env vars (issue5739)","author":"navaneeth.suresh","summary":"`$ foo=bar hg root` fails to recognise the repo `$foo`. I stopped expanding env\nvars from vfs when there exists a repo with the same name as the env var.","testPlan":"","lineCount":"12","dependsOn":[],"reviewers":[],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":">   > This is logically incorrect. The problem is that we're doing variable\n>   >  expansion at too lower layer. `vfs(expand(user_specified_path))` makes\n>   >  some sense, but `vfs(expand(getcwd()))` is clearly wrong. And the vfs class\n>   >  can't know where the `base` comes from.\n>   \n>   If I add a condition for expanding env var if present in `hgrc`, can this work as a fix?\n\nMaybe no. Where do you intend to add such code? vfs doesn't know where the path\ncomes from. Neither does localrepo.\n\n>   If the only solution for this is shifting path expansion from `vfs` class, where do you\n>   think it can be?\n\nSomewhere specifying repository path read from hgrc or user input.","author":"yuja","id":"81826","dateCreated":"1547043138","dateModified":"1547043138"},{"type":"comment","comment":"> This is logically incorrect. The problem is that we're doing variable\n> expansion at too lower layer. `vfs(expand(user_specified_path))` makes\n> some sense, but `vfs(expand(getcwd()))` is clearly wrong. And the vfs class\n> can't know where the `base` comes from.\n\nIf I add a condition for expanding env var if present in `hgrc`, can this work as a fix?\nIf the only solution for this is shifting path expansion from `vfs` class, where do you\nthink it can be?","author":"navaneeth.suresh","id":"81684","dateCreated":"1546920534","dateModified":"1546920534"},{"type":"comment","comment":">      def __init__(self, base, audit=True, cacheaudited=False, expandpath=False,\n>                   realpath=False):\n> +        if '$' in base and os.path.isdir(base):\n> +            # when there exists a repo '$foo' and an env var foo=bar, stop\n> +            # expanding path. refer issue5739.\n> +            expandpath = False\n\nThis is logically incorrect. The problem is that we're doing variable\nexpansion at too lower layer. `vfs(expand(user_specified_path))` makes\nsome sense, but `vfs(expand(getcwd()))` is clearly wrong. And the vfs class\ncan't know where the `base` comes from.","author":"yuja","id":"81561","dateCreated":"1546867921","dateModified":"1546867921"},{"type":"update","diffId":"13046","author":"navaneeth.suresh","id":"81547","dateCreated":"1546862928","dateModified":"1546862928"},{"type":"update","diffId":"13025","author":"navaneeth.suresh","id":"81425","dateCreated":"1546850305","dateModified":"1546850305"}],"dateCreated":"1546850305","dateModified":"1547043138","status":"Needs Review"},{"id":"2880","callsign":"HG","title":"bundle: add the possibility to bundle bookmarks (issue5792)","author":"lothiraldan","summary":"Also take the wlock when unbundling. It shouldn't have a big impact on\nperformance.","testPlan":"","lineCount":"143","dependsOn":[],"reviewers":["indygreg"],"ccs":["martinvonz","indygreg","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"Just a reminder that this has not been queued yet.","author":"martinvonz","id":"79389","dateCreated":"1543515570","dateModified":"1543515570"},{"type":"inline","comment":"I tried adding such scenarios but failed to produce a divergence scenario, no idea why.\n\nI don't think I will have time to debug the issue before the freeze, so let's skip this changeset for 4.6","replyTo":"53793","isNewFile":"1","line":"37","lineLength":"26","path":"tests\/test-bundle-bookmarks.t","diffId":"7077","author":"lothiraldan","id":"54248","dateCreated":"1523950897","dateModified":"1523950897"},{"type":"inline","comment":"I think it should be the same thing as pulling from another repo. Try putting the same changes in another repo and pulling from it without giving the path a name (nothing in [paths] config). I haven't checked what suffix will be used on the divergent bookmark, but it probably makes sense to use the same here (perhaps it's just going to be \"D1@1\" as I guessed before).","replyTo":"53729","isNewFile":"1","line":"37","lineLength":"26","path":"tests\/test-bundle-bookmarks.t","diffId":"7077","author":"martinvonz","id":"53793","dateCreated":"1523724103","dateModified":"1523724103"},{"type":"inline","comment":"I have added such test and indeed this case is not handled right now. I'm not aware of how Mercurial handle this case when exchanging bookmarks, I will need to take a look at the code to find out.\n\nWhat is the correct behavior here? Change the existing bookmark or the bookmark from the bundle?","replyTo":"46275","isNewFile":"1","line":"37","lineLength":"26","path":"tests\/test-bundle-bookmarks.t","diffId":"7077","author":"lothiraldan","id":"53729","dateCreated":"1523698843","dateModified":"1523698843"},{"type":"update","diffId":"8263","author":"lothiraldan","id":"53727","dateCreated":"1523698706","dateModified":"1523698706"},{"type":"comment","comment":">>! In D2880#52559, @indygreg wrote:\n> What's the status of this patch? Is it still reviewable? If so, let's get a rebased version submitted, just in case things have changed.\n\nI need to update the patch according to @martinvoz comment.\n\nI was also waiting on your comment on https:\/\/phab.mercurial-scm.org\/D2880#46263, do you think we will keep the option once the bundlespec system is revamped? If yes, we can make the config option a non-experimental one. But if it will be dropped soon, I think keeping it experimental until it's dropped is preferable. What do you think?","author":"lothiraldan","id":"52583","dateCreated":"1523555228","dateModified":"1523555228"},{"type":"comment","comment":"What's the status of this patch? Is it still reviewable? If so, let's get a rebased version submitted, just in case things have changed.","author":"indygreg","id":"52560","dateCreated":"1523549760","dateModified":"1523549760"},{"type":"reject","author":"indygreg","id":"52559","dateCreated":"1523549760","dateModified":"1523549760"},{"type":"inline","comment":"Can we have a similar test case where we create divergence? Create a fork in the graph in the debugdrawdag call above. Let's say you have commit F that branches off of B, then do something like this:\n\n```\n$ hg bundle --all bundle\n$ hg strip --no-backup C\n$ hg bookmarks -f -r F D1\n$ hg unbundle -q bundle\n$ hg log -G -T '{desc} {bookmarks}\\n'\n  o  E\n  |\n  o  D D1 D2\n  |\n  o  C\n  |\n  |  o F D1@1\n  |\/\n  o  B\n  |\n  o  A A1\n```\n\nI don't know if \"@1\" is the appropriate divergence marker, but I can't think of a better one. I haven't even looked at your code to try to guess what it would be in practice (if it would work at all).","replyTo":null,"isNewFile":"1","line":"37","lineLength":"26","path":"tests\/test-bundle-bookmarks.t","diffId":"7077","author":"martinvonz","id":"46275","dateCreated":"1521218729","dateModified":"1521218729"},{"type":"inline","comment":"I was afraid we might have to delete this option once we have the discussion about bundle spec format with @indygreg. If that would be the case, I would feel more comfortable deleting an experimental option.\n\nIf we agreed on moving bundle-phases out of experimental, I guess we can do the same for bundle-bookmarks.\n\n@indygreg Do you think we would still have this option around once we have new-style bundle spec?","replyTo":"46262","isNewFile":"1","line":"422","lineLength":"0","path":"mercurial\/configitems.py","diffId":"7077","author":"lothiraldan","id":"46264","dateCreated":"1521208181","dateModified":"1521208181"},{"type":"inline","comment":"Any reason why we have all these config option as experimental? We talked at sprint about moving things out of experimental and we agreed on `experimental.bundle-phases`. This one sounds similar.","replyTo":null,"isNewFile":"1","line":"422","lineLength":"0","path":"mercurial\/configitems.py","diffId":"7077","author":"pulkit","id":"46262","dateCreated":"1521206865","dateModified":"1521206865"},{"type":"update","diffId":"7077","author":"lothiraldan","id":"46256","dateCreated":"1521206506","dateModified":"1521206506"}],"dateCreated":"1521206506","dateModified":"1543515570","status":"Needs Review"},{"id":"5308","callsign":"HG","title":"store: don't pass 'atomictemp=True' while appending to fncache","author":"pulkit","summary":"Appending to an atomictemp file means that the entire file is copied first.\nThanks to Yuya for suggesting.","testPlan":"","lineCount":"2","dependsOn":[],"reviewers":[],"ccs":["yuja","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":">   > As I said, we'll also need to somehow hide partial data from another\n>   >  reader processes. There's no read lock.\n>   \n>   \n>   Read locks! was there a previous attempt on implementing them? I will try to take a shot at implementing them. I am unable to find any good detail except mentions in wiki or mailing list archive.\n\nAnother option is to ignore trailing data after `\\n`. That's how the revlog\nparser gets around partially-written entry.\n\nIn either way, writing fncache non-atomically wouldn't be strictly compatible\nwith older hg clients. I think that's okayish, but I should note that.","author":"yuja","id":"79385","dateCreated":"1543492790","dateModified":"1543492790"},{"type":"comment","comment":">>! Pasting Yuja's reply to that from mailing list:\n>>>! In D5308#78989, @pulkit wrote:\n>>>>! In D5308#78985, @yuja wrote:\n>>>> --- a\/mercurial\/store.py\n>>>> +++ b\/mercurial\/store.py\n>>>> @@ -486,7 +486,7 @@\n>>>>          if self.addls:\n>>>>             # if we have just new entries, let's append them to the fncache\n>>>>              tr.addbackup('fncache')\n>>>> -            fp = self.vfs('fncache', mode='ab', atomictemp=True)\n>>>> +            fp = self.vfs('fncache', mode='ab')\n>>> \n>>> Ah, no. addbackup() creates hardlink, which means fncache can't be updated in\n>>> place. Also, the reader wouldn't handle partially-written fncache well.\n>> \n>> do we need to call `addbackup()` if we are just appending?\n>\n> We need a mechanism to restore the original content on rollback. IIUC,\n> it's `tr.add()` for append-only files.\n>\n> As I said, we'll also need to somehow hide partial data from another\n> reader processes. There's no read lock.\n\nRead locks! was there a previous attempt on implementing them? I will try to take a shot at implementing them. I am unable to find any good detail except mentions in wiki or mailing list archive.","author":"pulkit","id":"79002","dateCreated":"1543424805","dateModified":"1543424805"},{"type":"comment","comment":">>! In D5308#78985, @yuja wrote:\n>> --- a\/mercurial\/store.py\n>> +++ b\/mercurial\/store.py\n>> @@ -486,7 +486,7 @@\n>>          if self.addls:\n>>              # if we have just new entries, let's append them to the fncache\n>>              tr.addbackup('fncache')\n>> -            fp = self.vfs('fncache', mode='ab', atomictemp=True)\n>> +            fp = self.vfs('fncache', mode='ab')\n> \n> Ah, no. addbackup() creates hardlink, which means fncache can't be updated in\n> place. Also, the reader wouldn't handle partially-written fncache well.\n\ndo we need to call `addbackup()` if we are just appending?","author":"pulkit","id":"78989","dateCreated":"1543326786","dateModified":"1543326786"},{"type":"comment","comment":"> --- a\/mercurial\/store.py\n> +++ b\/mercurial\/store.py\n> @@ -486,7 +486,7 @@\n>          if self.addls:\n>              # if we have just new entries, let's append them to the fncache\n>              tr.addbackup('fncache')\n> -            fp = self.vfs('fncache', mode='ab', atomictemp=True)\n> +            fp = self.vfs('fncache', mode='ab')\n\nAh, no. addbackup() creates hardlink, which means fncache can't be updated in\nplace. Also, the reader wouldn't handle partially-written fncache well.","author":"yuja","id":"78986","dateCreated":"1543325866","dateModified":"1543325866"},{"type":"update","diffId":"12610","author":"pulkit","id":"78976","dateCreated":"1543324956","dateModified":"1543324956"}],"dateCreated":"1543324956","dateModified":"1543492790","status":"Needs Review"},{"id":"5295","callsign":"HG","title":"branchmap: define a hasbranch() to find whether a branch exists or not","author":"pulkit","summary":"This patch introduces a branchmap.hasbranch() function to find whether a branch\nexists or not. I was going through profile of one of most used command\ninternally on server side and found that we are spending ~50% of time finding\nwhether a branch exists or not. We are reading the branchmap cache, building the\nrelated object and then finding whether a branch exists or not which is quite\nslow on repositories which have more than 10k named branches.\n\nIn the new function, we just iterate over the whole branchmap cache and find\nthat whether a branch name is present or not. This is essentially\nbranchmap.read() but without any hash validation, creation of the branchcache()\nobject.\n\nFollowing were the improvements observed:\n\nBefore:\n\n`hg log -b . -l 1`: 0.53 sec\n`hg log -b <last_branch_in_the_cache> -l 1`: 1.12 sec\n\nAfter:\n\n`hg log -b . -l 1`: 0.32 sec\n`hg log -b <last_branch_in_the_cache> -l 1`: 0.95 sec\n\n\nThere we no improvements observed in `hg log -r <branch_name>`, if the log limit\nis greater than 1, and while using revsets.\n\nI have added a TODO here that we can use binary search instead of plain\niteration for finding whether a branch name exists or not. I got to know that\nMartijn Pieters is working on some related stuff to load branchmap in memory as\nraw data and decided to implement binary search on top of that.","testPlan":"","lineCount":"29","dependsOn":[],"reviewers":[],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"I don't think it's good idea to re-scan the cache file per hasbranch() call.\nInstead, we'll probably need a lazy parser backed by a in-memory cache data.\nThe current cache file format is text-based, which wouldn't be easily bisected\nwithout loading (or memmap) the whole content.\n\n> +def hasbranch(repo, branchname):\n> +    \"\"\"check whether a branchname exists in the repo or not by reading the\n> +    branchmap cache\"\"\"\n> +\n> +    if not repo.cachevfs.exists(_filename(repo)):\n> +        # branchmap file is not present, let's go repo.branchmap() route which\n> +        # will create that file\n> +        return branchname in repo.branchmap()\n> +\n> +    # TODO: implement binary-search here for faster search\n> +    with repo.cachevfs(_filename(repo)) as f:\n> +        f = repo.cachevfs(_filename(repo))\n> +        lineiter = iter(f)\n> +        next(lineiter).rstrip('\\n').split(\" \", 2)\n\nNeed to check if the cache file is valid.\n\n> +        for l in lineiter:\n> +            l = l.rstrip('\\n')\n> +            if not l:\n> +                continue\n> +            label = l.split(\" \", 2)[2]\n> +            label = encoding.tolocal(label.strip())\n> +            if label == branchname:\n\nAnd maybe need to check if the node exists.\n\n> +                return True\n> +    return False","author":"yuja","id":"78895","dateCreated":"1543118662","dateModified":"1543118662"},{"type":"update","diffId":"12582","author":"pulkit","id":"78822","dateCreated":"1542887394","dateModified":"1542887394"}],"dateCreated":"1542887394","dateModified":"1543118662","status":"Needs Review"},{"id":"1701","callsign":"HG","title":"logtoprocess: add the possibility to not popup a console","author":"lothiraldan","summary":"Starting a subprocess on Windows with `DETACHED_PROCESS |\nCREATE_NEW_PROCESS_GROUP` as startup info means starting a console GUI window\nin almost all cases. If we add a logtoprocess for commandfinish and the prompt\ndo some hg calls, it will create a short-lived GUI window which is annoying\nfor end-users.\n\nCreating a subprocess with `CREATE_CONSOLE` instead seems to no start a\nconsole window but could have other side-effects so it kept under a config\nknob.","testPlan":"","lineCount":"13","dependsOn":["1700"],"reviewers":[],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"inline","comment":"Can we add `CREATE_NEW_PROCESS_GROUP` ?","replyTo":null,"isNewFile":"1","line":"66","lineLength":"0","path":"hgext\/logtoprocess.py","diffId":"4468","author":"yuja","id":"29101","dateCreated":"1513346507","dateModified":"1513346507"},{"type":"comment","comment":"> but could have other side-effects so it kept under a config knob.\n\nMy two cents, `experimental.*` might be better if the config knob exists as\na workaround for an unknown bug.","author":"yuja","id":"29100","dateCreated":"1513346507","dateModified":"1513346507"},{"type":"update","diffId":"4468","author":"lothiraldan","id":"29029","dateCreated":"1513332660","dateModified":"1513332660"}],"dateCreated":"1513332660","dateModified":"1541507268","status":"Needs Review"},{"id":"5102","callsign":"HG","title":"beautifygraph: add configs for customizing the characters","author":"hooper","summary":"I figure we should keep this out of graphmod.py and templatekw.py for now.\nMoving the extension functionality out of hgext is a separate issue.\n\nCalling ui.config() inside getgraphnode seems like it might slow things down,\nbut it needs to happen there because of the template keyword. We probably want\nto honor config overrides, so we can't cache glyphs at this level.","testPlan":"","lineCount":"208","dependsOn":[],"reviewers":[],"ccs":["spectral","mercurial-devel"],"actions":[{"type":"comment","comment":"I'll elaborate a bit. I think the idea of using unicode to make the graph good looking is flawed. There are no characters that properly serve common cases like this:\n\n```\no\n|\n \\\n  o\n```\n\nThat's part of why there was some disagreement in early discussion of this extension.\n\nI think it's a bad user experience, because if the graph looks 95% like a connected drawing, these broken areas are going to look like malfunctions (whereas we started with a stylized ascii drawing where the limitations are obvious to the user).\n\nAdditionally, the existing graphlog output is lossy. The two pipes in this example do not have the same meaning:\n\n```\no\n|\n|\n \\\n   o\n```\n\nEven if we had the unicode characters\/custom font needed to make this work, we would need at least 5 configurable variants of what is currently just a pipe. You would need hundreds of distinct characters to support all combinations of the 8 horizontal and diagonal edges in each character\/cell of the graph rendering. More than double that to support dashed lines. Maybe exclude some unused characters. It's hard to imagine making that easy to configure.\n\nYou can also imagine having the graphlog output optionally use only horizontal\/vertical edges so this can be done properly with box drawing characters. This is would complicate graphlog itself considerably, regardless of configuration.\n\nMeanwhile, this patch would be useful to some of our users, and it keeps the problems contained within the extension.","author":"hooper","id":"77628","dateCreated":"1540934965","dateModified":"1540934965"},{"type":"comment","comment":"hooper and I talked at the sprint, and they wrote up the following for why they feel we should keep this out of graphmod\/templatekw for now:\n\n> I don't think configurable graph log characters in core is a great idea right now, since it makes the empty promise that you can make logs look correct by using common fonts. E.g. the problem that pipe characters are used in several situations that just can't be handled well by one character.\n\nAs a specific example, there's no unicode line drawing characters that are fully-extended lines at 0 degrees (straight up) and 135 degrees (down to the right to the corner of the character box), so there will always be cases that can't really be represented \"perfectly\".\n\nI don't generally agree with this reasoning - limitations of unicode should not be a reason to require that we go through a separate extension like this.  The reasoning for the extension instead of just making the actual graph characters customizable was two-fold, if I remember correctly:\n\n1. there is currently some awkward code to handle extending one of the characters used to draw parent\/grandparent lines for a few lines and then switch to the other. (https:\/\/www.mercurial-scm.org\/repo\/hg\/file\/tip\/tests\/test-glog.t#l3041 shows this in action) - the code to implement this is not unicode safe (at least in python2)\n2. the current graphlog code does not currently have config knobs to control every character, I think. \n\n\nI think we should fix the code issue in #1 (I just sent D5112 for this), and then we can extended graphlog to have whatever character(s) we need, instead of attempting to do the replacements in an extension like we're currently doing?  The extension could just become a set of \"recommended\" values for these config knobs.\n","author":"spectral","id":"76474","dateCreated":"1539693777","dateModified":"1539693777"},{"type":"update","diffId":"12138","author":"hooper","id":"76357","dateCreated":"1539526671","dateModified":"1539526671"},{"type":"update","diffId":"12130","author":"hooper","id":"76302","dateCreated":"1539519730","dateModified":"1539519730"}],"dateCreated":"1539519730","dateModified":"1540934965","status":"Needs Review"},{"id":"4810","callsign":"HG","title":"repository: introduce an ellipses repo requirement","author":"pulkit","summary":"Right now there is no good way to check whether a repo is ellipses enabled or\nnot. This patch introduces a ellipses repo requirement which will be used in\nupcoming patches.\n\nI have purposefully not included narrow in the requirement name because now they\nare looking different concepts to me.","testPlan":"","lineCount":"5","dependsOn":[],"reviewers":[],"ccs":["indygreg","martinvonz","mercurial-devel"],"actions":[{"type":"comment","comment":"I think this patch (and later patches that start using it, of course) would be a good idea. I suppose it won't make it into 4.8, but we don't have a freeze, so please send an updated version whenever you have time","author":"martinvonz","id":"76964","dateCreated":"1539816026","dateModified":"1539816026"},{"type":"comment","comment":"New requirements should be documented in `help\/internals\/requirements.txt`.","author":"indygreg","id":"72817","dateCreated":"1538412974","dateModified":"1538412974"},{"type":"comment","comment":"Let's do this step by step and get the wireprotocol command reviewed first. Once that is done, I will resend this one.","author":"pulkit","id":"72789","dateCreated":"1538409775","dateModified":"1538409775"},{"type":"plan-changes","author":"pulkit","id":"72788","dateCreated":"1538409775","dateModified":"1538409775"},{"type":"inline","comment":"Yeah, the intent was to say the same thing as the comment about NARROW_REQUIREMENT says but re-reading myself, looks like I messed up. I will update this.","replyTo":"72704","isNewFile":"1","line":"22","lineLength":"2","path":"mercurial\/repository.py","diffId":"11501","author":"pulkit","id":"72706","dateCreated":"1538352558","dateModified":"1538352558"},{"type":"inline","comment":"I'm not sure I understand what this says.\n\nThe first sentence sounds too obvious to mention (kind of like \"when it's done, it should be working well\"), but I suspect you mean something else. Do you mean that that's the criteria for dropping the \"exp-\" prefix (much like the comment for narrow says above)?\n\nI don't know what the second sentence says either. Isn't it already generalized to shallow and ellipses?","replyTo":null,"isNewFile":"1","line":"22","lineLength":"2","path":"mercurial\/repository.py","diffId":"11501","author":"martinvonz","id":"72704","dateCreated":"1538352074","dateModified":"1538352074"},{"type":"update","diffId":"11501","author":"pulkit","id":"72668","dateCreated":"1538323845","dateModified":"1538323845"},{"type":"update","diffId":"11493","author":"pulkit","id":"72644","dateCreated":"1538265895","dateModified":"1538265895"}],"dateCreated":"1538265895","dateModified":"1539816026","status":"Changes Planned"},{"id":"4876","callsign":"HG","title":"amend: add config to skip amend if only date is changed (issue5828)","author":"Zharaskhan","summary":"When --date flag specified with `hg amend` and working copy is clean,\n`hg amend` amends, which is generally undesirable behavior.\nBut it is commonly used to change date on each amend.\nI added experimental.amend.dateonly config option to not amend\nif only thing that changed is date.\nI also added tests for this.","testPlan":"","lineCount":"56","dependsOn":[],"reviewers":["pulkit","durin42"],"ccs":["durin42","yuja","martinvonz","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"It sounds like @pulkit has some ideas on what needs to be done follow-up wise.","author":"durin42","id":"76409","dateCreated":"1539531108","dateModified":"1539531108"},{"type":"reject","author":"durin42","id":"76408","dateCreated":"1539531108","dateModified":"1539531108"},{"type":"comment","comment":">   I should be easy to introduce such an option and make amend respect it (similar amount of code as this patch), so I'd just like to hear if others think it's a good idea first. If others agree with it, then it seems better to introduce the generic option right away. I can't\/won't access IRC right now, but feel free to check there what others think and update this review when you have.\n\nSGTM.\n\nPerhaps, `ui.history-editing-backup` can be moved under the same config group.","author":"yuja","id":"74243","dateCreated":"1539087709","dateModified":"1539087709"},{"type":"comment","comment":">>! In D4876#74021, @pulkit wrote:\n> (Replying because I adviced Zharas to take up this issue and he is a new mercurial user and have less context on the problem)\n> \n>>>! In D4876#74017, @martinvonz wrote:\n>> I'm not sure how I feel about this. I think we talked within the team at Google about always passing a `-D now` and decided not to do it because of the issue you're fixing here (I may be confusing the discussion with one about using `hg metaedit`). Still, I feel like this patch is a workaround for the real problem. I assume that the real problem is that there the date is not normally updated when you amend a commit (i.e. you want to always pass `-D now`, not a specific other timestamp). If that's the problem we're trying address, should we instead introduce a config called something like `amend.updatetimestamp` that makes it update the timestamp to the current time? That would naturally not update the timestamp if the timestamp was the only thing that changed (just like this patch does it). The natural generalization of `amend.updatetimestamp` is something like `rewrite.updatetimestamp` that would be respected by amend, histedit, rebase, etc.\n>> \n>> What do you think? Is that the use case you're trying to address with this patch?\n> \n> I agree that the real problem is amend not updating the timestamp. People have aliased `amend` to `amend -D now` or just like you said, they always pass `-D now`. In such cases, even if the working directory is not changed, we end up creating a new commit with just date change. This patch tries to solve the problem of creating a new commit when only date has changed for people who do `amend -D now` always by preventing that if the config option is turned on.\n> \n> I like your idea of having a config option which is respected by all the commands.\n> \n> That said, will you like to see a v2 of this patch with inline comments addressed or we abandon this idea in favour of proposed config option to change the date.\n\nI should be easy to introduce such an option and make amend respect it (similar amount of code as this patch), so I'd just like to hear if others think it's a good idea first. If others agree with it, then it seems better to introduce the generic option right away. I can't\/won't access IRC right now, but feel free to check there what others think and update this review when you have.","author":"martinvonz","id":"74049","dateCreated":"1539015450","dateModified":"1539015450"},{"type":"inline","comment":"\"amend.skipdateonly\" sounds good.","replyTo":"74020","isNewFile":"1","line":"440","lineLength":"2","path":"mercurial\/configitems.py","diffId":"11660","author":"pulkit","id":"74022","dateCreated":"1539014629","dateModified":"1539014629"},{"type":"comment","comment":"(Replying because I adviced Zharas to take up this issue and he is a new mercurial user and have less context on the problem)\n\n>>! In D4876#74017, @martinvonz wrote:\n> I'm not sure how I feel about this. I think we talked within the team at Google about always passing a `-D now` and decided not to do it because of the issue you're fixing here (I may be confusing the discussion with one about using `hg metaedit`). Still, I feel like this patch is a workaround for the real problem. I assume that the real problem is that there the date is not normally updated when you amend a commit (i.e. you want to always pass `-D now`, not a specific other timestamp). If that's the problem we're trying address, should we instead introduce a config called something like `amend.updatetimestamp` that makes it update the timestamp to the current time? That would naturally not update the timestamp if the timestamp was the only thing that changed (just like this patch does it). The natural generalization of `amend.updatetimestamp` is something like `rewrite.updatetimestamp` that would be respected by amend, histedit, rebase, etc.\n> \n> What do you think? Is that the use case you're trying to address with this patch?\n\nI agree that the real problem is amend not updating the timestamp. People have aliased `amend` to `amend -D now` or just like you said, they always pass `-D now`. In such cases, even if the working directory is not changed, we end up creating a new commit with just date change. This patch tries to solve the problem of creating a new commit when only date has changed for people who do `amend -D now` always by preventing that if the config option is turned on.\n\nI like your idea of having a config option which is respected by all the commands.\n\nThat said, will you like to see a v2 of this patch with inline comments addressed or we abandon this idea in favour of proposed config option to change the date.","author":"pulkit","id":"74021","dateCreated":"1539014629","dateModified":"1539014629"},{"type":"inline","comment":"\"amend.dateonly\" sounds like it only updates the date. Maybe \"amend.skipdateonly\" or \"amend.nodateonly\"? It doesn't matter much because we'll need to update it anyway later if we drop the \"experimental\" label.","replyTo":null,"isNewFile":"1","line":"440","lineLength":"2","path":"mercurial\/configitems.py","diffId":"11660","author":"martinvonz","id":"74020","dateCreated":"1538975614","dateModified":"1538975614"},{"type":"inline","comment":"You only care about the date here, right? You can probably do something like `hg log -T '{date|isodate}\\n'` to make the test clearer.","replyTo":null,"isNewFile":"1","line":"372","lineLength":"14","path":"tests\/test-amend.t","diffId":"11660","author":"martinvonz","id":"74019","dateCreated":"1538975614","dateModified":"1538975614"},{"type":"comment","comment":"I'm not sure how I feel about this. I think we talked within the team at Google about always passing a `-D now` and decided not to do it because of the issue you're fixing here (I may be confusing the discussion with one about using `hg metaedit`). Still, I feel like this patch is a workaround for the real problem. I assume that the real problem is that there the date is not normally updated when you amend a commit (i.e. you want to always pass `-D now`, not a specific other timestamp). If that's the problem we're trying address, should we instead introduce a config called something like `amend.updatetimestamp` that makes it update the timestamp to the current time? That would naturally not update the timestamp if the timestamp was the only thing that changed (just like this patch does it). The natural generalization of `amend.updatetimestamp` is something like `rewrite.updatetimestamp` that would be respected by amend, histedit, rebase, etc.\n\nWhat do you think? Is that the use case you're trying to address with this patch?\n","author":"martinvonz","id":"74018","dateCreated":"1538975614","dateModified":"1538975614"},{"type":"comment","comment":"This looks good to me but since I helped Zharas in preparing the patch, I won't queue it.","author":"pulkit","id":"73696","dateCreated":"1538680221","dateModified":"1538680221"},{"type":"accept","author":"pulkit","id":"73695","dateCreated":"1538680221","dateModified":"1538680221"},{"type":"update","diffId":"11660","author":"Zharaskhan","id":"73590","dateCreated":"1538605984","dateModified":"1538605984"}],"dateCreated":"1538605984","dateModified":"1539531108","status":"Needs Revision"},{"id":"5052","callsign":"HG","title":"mercurial: strip function return type annotations (RFC)","author":"indygreg","summary":"THIS IS SUPER HACKY. DO NOT EVEN THINK ABOUT LANDING YET.\n\nNow that we have a custom module importer on Python 2 and that importer\nis using Python 3.7's tokenizer, it is possible for us to analyze the\nsource code token stream and transform it to valid Python 2.7 source\nbefore it is compiled into a code object.\n\nThis commit teaches the token stream transformer to recognize the tokens\nfor a function return type annotation and to strip those tokens from the\ntoken stream. As far as Python 2's code compiler is concerned, the original\nsource didn't contain a type annotation!\n\nTo prove it works, we define a type annotation in the dispatch module.\nPython 2 is able to import the module just fine.\n\nThis feature means we could start adding type annotations throughout the\ncode base while still remaining Python 2 compatible.\n\nBut why stop at type annotations? We could also rewrite the token stream\nso we can leverage other Python 3 only features. This includes \"yield from\"\nsuper() without arguments, class definitions without \"(object)\", etc. We\ncould also \"invert\" our source transformer strategy and make the code base\nnative Python 3 and source transform to remain compatible with Python 2.","testPlan":"","lineCount":"15","dependsOn":["5051"],"reviewers":[],"ccs":["mjpieters","mercurial-devel"],"actions":[{"type":"update","diffId":"12008","author":"indygreg","id":"75694","dateCreated":"1539415751","dateModified":"1539415751"}],"dateCreated":"1539415751","dateModified":"1539415751","status":"Needs Review"},{"id":"5051","callsign":"HG","title":"mercurial: implement custom module importer for Python 2.7 (RFC)","author":"indygreg","summary":"THIS IS SUPER HACKY. IT DOESN'T INVALIDATE .pyc FILES, WHICH MEANS SOURCE\nCHANGES AREN'T PICKED UP. DO NOT LAND.","testPlan":"","lineCount":"111","dependsOn":["5050"],"reviewers":[],"ccs":["mjpieters","mercurial-devel"],"actions":[{"type":"update","diffId":"12007","author":"indygreg","id":"75684","dateCreated":"1539415744","dateModified":"1539415744"}],"dateCreated":"1539415744","dateModified":"1539415751","status":"Needs Review"},{"id":"5050","callsign":"HG","title":"tests: add test verifying our Python 3 tokenizer works","author":"indygreg","summary":"Our vendored Python 3.7 tokenizer is now fully working on Python 2.7.\nLet's verify that by adding a test that ensures we can tokenize all .py\nfiles in the repo.","testPlan":"","lineCount":"65","dependsOn":["5049"],"reviewers":[],"ccs":["mjpieters","mercurial-devel"],"actions":[{"type":"update","diffId":"12006","author":"indygreg","id":"75674","dateCreated":"1539415737","dateModified":"1539415737"}],"dateCreated":"1539415737","dateModified":"1539415744","status":"Needs Review"},{"id":"5049","callsign":"HG","title":"hgdemandimport: don't use str.isidentifier()","author":"indygreg","summary":"This method doesn't exist in Python 2.7.\n\nThe new code is equivalent to what Python was doing up until\nisidentifier() was introduced to Lib\/tokenize.py in\n33856de84d1115a18b699e0ca93c3b921bc6a1af.\n\nStrictly speaking, a simple ascii check is not sufficient, as a proper\nidentifier is defined by PEP 3131 and allows non-ascii characters. But\nwe don't plan to use this tokenizer on arbitrary source code, so I think\nwe can get away with not conforming to PEP 3131.","testPlan":"","lineCount":"6","dependsOn":["5048"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"12005","author":"indygreg","id":"75664","dateCreated":"1539415731","dateModified":"1539415731"}],"dateCreated":"1539415731","dateModified":"1539415737","status":"Needs Review"},{"id":"5048","callsign":"HG","title":"hgdemandimport: port line consuming to Python 2","author":"indygreg","summary":"This commit rewrites the line consuming to use next() on a generator\nin order to appease Python 2.\n\nWith this commit, we are now able to emit some tokens on Python 2.7 using\nthe Python 3.7 tokenizer. But there are still bugs...","testPlan":"","lineCount":"24","dependsOn":["5047"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"12004","author":"indygreg","id":"75654","dateCreated":"1539415725","dateModified":"1539415725"}],"dateCreated":"1539415725","dateModified":"1539415731","status":"Needs Review"},{"id":"5047","callsign":"HG","title":"hgdemandimport: remove re.ASCII","author":"indygreg","summary":"This is a Python 3'ism. Our intent is to only use this code from Python\n2 and Python 2's behavior is essentially the same as re.ASCII AFAIK.","testPlan":"","lineCount":"5","dependsOn":["5046"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"12003","author":"indygreg","id":"75644","dateCreated":"1539415717","dateModified":"1539415717"}],"dateCreated":"1539415717","dateModified":"1539415725","status":"Needs Review"},{"id":"5046","callsign":"HG","title":"hgdemandimport: adjust imports to reflect vendored module","author":"indygreg","summary":"The \"token\" module is renamed in our local copy. Import it appropriately.\n\nThis angered test-check-module-imports due to attempting relative import of\nstdlib module and direct symbol imports. We suppress that check on this file\nsince it is mostly 3rd party code.","testPlan":"","lineCount":"18","dependsOn":["5045"],"reviewers":[],"ccs":["mjpieters","mercurial-devel"],"actions":[{"type":"update","diffId":"12002","author":"indygreg","id":"75634","dateCreated":"1539415710","dateModified":"1539415710"}],"dateCreated":"1539415710","dateModified":"1539415717","status":"Needs Review"},{"id":"5045","callsign":"HG","title":"hgdemandimport: remove unused functionality from vendored modules","author":"indygreg","summary":"We'll never use this. It is just bloating the files.\n\nThe PSF license section 3 stipulates that derived works...\n\"include in any such work a brief summary of the changes made to Python.\"\nWhile I think commit messages and version control count, I'm going one\nstep further and documenting things inline.\n\nThis change makes test-check-module-imports.t happy.","testPlan":"","lineCount":"193","dependsOn":["5044"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"12000","author":"indygreg","id":"75623","dateCreated":"1539415703","dateModified":"1539415703"}],"dateCreated":"1539415703","dateModified":"1539415710","status":"Needs Review"},{"id":"5044","callsign":"HG","title":"hgdemandimport: add PSF license and copyright notice to vendored files","author":"indygreg","summary":"This seems to be required per the PSFv2 license text.","testPlan":"","lineCount":"110","dependsOn":["5043"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"11999","author":"indygreg","id":"75613","dateCreated":"1539415696","dateModified":"1539415696"}],"dateCreated":"1539415696","dateModified":"1539415703","status":"Needs Review"},{"id":"5043","callsign":"HG","title":"hgdemandimport: vendor CPython 3.7 tokenizer modules","author":"indygreg","summary":"I have an evil plan to leverage the Python 3 tokenizer on Python 2.7.\n\nThe added files are Lib\/token.py and Lib\/tokenize.py from cpython's\nGit repository at commit d4ed8809ddfaa23fe5edf2987c03afc32f5576c0. This\ncommit corresponds to the current development tip of the 3.7 branch.\nThe only commit since the 3.7.0 tag is\nab75d9e4244ee24bc96ea9d52362899e3bf365a2, which appears to contain a minor\nfix to make the Python code more consistent with the C implementation.\n\nThe files are added without modifications. Future commits will tidy\nthings up a bit.\n\nBecause the files are third party, I've added them to static analysis\nexclusion lists.\n\ntest-check-py3-compat.t and test-check-module-imports.t currently fail.\nI'll deal with that in a subsequent commit.\n\n# no-check-commit style violations galore","testPlan":"","lineCount":"902","dependsOn":[],"reviewers":[],"ccs":["mjpieters","mercurial-devel"],"actions":[{"type":"update","diffId":"11998","author":"indygreg","id":"75607","dateCreated":"1539415690","dateModified":"1539415690"}],"dateCreated":"1539415690","dateModified":"1539415696","status":"Needs Review"},{"id":"5019","callsign":"HG","title":"pager: disable auto pager if we think it doesn't support F, R, X","author":"spectral","summary":"","testPlan":"","lineCount":"164","dependsOn":[],"reviewers":[],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"inline","comment":"Won't this iterate integers on Python 3?","replyTo":null,"isNewFile":"1","line":"1120","lineLength":"0","path":"mercurial\/ui.py","diffId":"11937","author":"indygreg","id":"75313","dateCreated":"1539368646","dateModified":"1539368646"},{"type":"comment","comment":"I need to review this on a fresher brain. But I'll be honest, I'm not sure how I feel about this.\n\nDo you know of other programs that jump through similar hoops to properly set up a pager?","author":"indygreg","id":"75312","dateCreated":"1539368646","dateModified":"1539368646"},{"type":"update","diffId":"11937","author":"spectral","id":"75284","dateCreated":"1539366293","dateModified":"1539366293"}],"dateCreated":"1539366293","dateModified":"1539368646","status":"Needs Review"},{"id":"2679","callsign":"HG","title":"[PoC] obsolete: config option to enable local only obsolescence mode","author":"indygreg","summary":"Our path to enable obsolescence\/evolve in core is to enable\ncreation of markers locally (no exchange) with user-facing behavior\nthat mimics existing behavior as closely as possible. Think of it\nas evolve light.\n\nWe introduce a config option to control this behavior.","testPlan":"","lineCount":"14","dependsOn":[],"reviewers":[],"ccs":["martinvonz","markand","durin42","lothiraldan","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D2679#73347, @martinvonz wrote:\n> Here's a case I just ran into where I would have liked to de-obsolete a commit:\n> \n> 1. Someone queues a patch and pushes to central repo. Repo looks like this:\n\nYou are using the words \"Someone queues a patch\", is your example taken from the current Mercurial project workflow? If so, keep in mind that this workflow is a bit unique. It is not what we refer as \"distributed evolution\" and diverges from it in various ways. In particular, we can highlight the following difference:\n\n\n  - Contributions are exchanged through email or Phabricator. Both ways fail to transfers the associated obsmarkers (and therefore break the evolution chains). \n    Instead people using distributed evolution exchanges changesets through mercurial repositories, fully taking advantage of the obsmarkers data. This makes it possible for them to collaborate on the same feature branch and other evolution benefits (eg: evolution data in code review tools).\n  -  The publication workflow is odds as hundreds of unrelated draft changeset can stack above each other before being published. This is not really the use-case that draft phase and evolution targets.\n> \n> ```\n> o  B\n> |\n> o  A\n> ```\n> \n> 2. I fix a typo and and amend, but I forget to push. \n> 3. I build my own commit on top. My repo:\n> \n> ```\n> o  X\n> |\n> o  B'\n> |\n> o  A\n> ```\nSmall side question: Why are you building X on top of (draft) B', are they related?\n> \n> 4. Someone pushes new patches to central repo. Central repo:\n> \n> ```\n> o  C\n> |\n> o  B\n> |\n> o  A\n> ```\nAdditional side question: Why is C on top of (draft) B. Are they related?\n> \n> 5. I pull from central repo. My repo:\n> \n> ```\n> o  C\n> |\n> x B\n> |\n> | o  X\n> | |\n> | o  B'\n> |\/\n> o  A\n> ```\n> \n> 6. I move my change onto the new upstream and prune my local B' that's now unwanted:\n> \n> ```\n> o X'\n> |\n> o  C\n> |\n> x B\n> |\n> | x B'\n> |\/\n> o  A\n> ```\n> \n> If upstream history was really just a single commit (`C` above), then the obvious thing to do is to just evolve that commit and push it. However, sometimes there is a long chain on top, and in my case there was a separate commit upstream that fixed the typo I fixed when I amended `B` and it would be a little confusing to explain why someone's fix was \"lost\". \n\nI can see two distinct arguments in that description:\n  #  Someone else made a similar fix in an independent changeset, and you want to give them the priority.\n  #  There are many drafts stacked above it and you don't want to rewrite B.\n\n\nRegarding the first argument, the case is easily handled by \"rewinding\" your amend's change and restoring the diff provided by 'B'. The `hg rewind` command deal with this case well: `hg rewind --to B`. The use of `hg prune` in your example is wrong. By using prune, you signal that the full line of change in B' (B' and it predecessors B) is something that is unwanted. So you are not just dropping the change introduced in your amend, but the other associated change.\n\nRegarding the second argument, the one I interpret as it would create too many orphans.\nIt seems to be the consequence of the current Mercurial Project workflow where many unrelated drafts get stacked.\nThe point of the draft phase is to signal that a changeset is safe to be rewritten. In other words that the consequences of such rewriting are acceptable. If you get to the point where rewriting draft no longer feel safe you seem to have a workflow issue.\n\nFor the sake of the current argument, let's assume that the workflow would be fixed in a direction where B would be public. After your pull. In that case, B' would be \"phase-divergent\". Solving that phase-divergence will create a \u0394B changeset with just the fix (you amend change). Rebasing that \u0394B on top of the other fix will make it disappears, giving priority as you intended.\n\n> So I'd prefer to mark B as no longer obsolete. I know I can do that with `hg strip B'`, but that also strips `X`, which is probably not a big loss, but it's a weird side-effect.\n\nYou cannot really strip the obsmarkers between B and B' without stripping B' itself. If B' end up being visible again it's Evolve that would be lost introducing confusion too.\n\n> Perhaps all I'm asking for is a way of dropping the obsmarker between `B` and `B'`. I don't know what the best UI for that would be, though. For now, I guess I'll use `hg strip`.\n\nStripping obsmarkers (and changesets) gets tricky quickly as their might continue to exist elsewhere. [issue5267](https:\/\/bz.mercurial-scm.org\/show_bug.cgi?id=5267) is a good example. There is already a couple of ways to do it (hg strip or hg debugobsolete) but it is currently confined into advanced commands. Before smoothing special case that could benefit stripping (or equivalent feature), it is important to deal with the UI for the main use-case. The use-case that solves both local and distributed evolution with the same command set. We want this commands set to comes first as we know it will be necessary. We can add more advanced commands and concept to deal with stripping afterward.\n\n\nLet me clarify that last part: imagine two commands (or command set, or concepts):\n\n # Command-A handles cases for both local and distributed evolution,\n # Command-B only handles local evolution, but deal with a corner case a bit later.\n\n\nIf we introduce Command-A early, we can foster a good user experience that will be the same for local and distributed case. This makes the \"step\" to distributed usage simple and painless. The overall user experience and other commands will make sure they work smoothly with Command-A. Later, we can introduce Command-B that will deal with specialized cases were Command-A is lacking. Since Command-A is already covering the main use-cases well, Command-B can focus on dealing with the specialized cases only. Each command has clear responsibilities.\n\nOn the other hand, introducing Command-B first will create a user experience that does not cover all of the main use-cases. The later arrival of Command-A will introduce an overlap in responsibilities confusing to users. In addition, it will create a problematic step to move from the local experience to the distributed one. Users will have to \"forget\" their previous usage to be able to get the better of Mercurial, this will create more confusion.","author":"lothiraldan","id":"74342","dateCreated":"1539204897","dateModified":"1539204897"},{"type":"comment","comment":"Here's a case I just ran into where I would have liked to de-obsolete a commit:\n\n1. Someone queues a patch and pushes to central repo. Repo looks like this:\n\n```\no  B\n|\no  A\n```\n\n2. I fix a typo and and amend, but I forget to push. \n3. I build my own commit on top. My repo:\n\n```\no  X\n|\no  B'\n|\no  A\n```\n\n4. Someone pushes new patches to central repo. Central repo:\n\n```\no  C\n|\no  B\n|\no  A\n```\n\n5. I pull from central repo. My repo:\n\n```\no  C\n|\nx B\n|\n| o  X\n| |\n| o  B'\n|\/\no  A\n```\n\n6. I move my change onto the new upstream and prune my local B' that's now unwanted:\n\n```\no X'\n|\no  C\n|\nx B\n|\n| x B'\n|\/\no  A\n```\n\nIf upstream history was really just a single commit (`C` above), then the obvious thing to do is to just evolve that commit and push it. However, sometimes there is a long chain on top, and in my case there was a separate commit upstream that fixed the typo I fixed when I amended `B` and it would be a little confusing to explain why someone's fix was \"lost\".  So I'd prefer to mark B as no longer obsolete. I know I can do that with `hg strip B'`, but that also strips `X`, which is probably not a big loss, but it's a weird side-effect. Perhaps all I'm asking for is a way of dropping the obsmarker between `B` and `B'`. I don't know what the best UI for that would be, though. For now, I guess I'll use `hg strip`.","author":"martinvonz","id":"73348","dateCreated":"1538584552","dateModified":"1538584552"},{"type":"inline","comment":"https:\/\/www.mercurial-scm.org\/wiki\/UIGuideline#naming_config_options","replyTo":null,"isNewFile":"1","line":"1041","lineLength":"0","path":"mercurial\/configitems.py","diffId":"6637","author":"markand","id":"73020","dateCreated":"1538468057","dateModified":"1538468057"},{"type":"comment","comment":">>! In D2679#70935, @durin42 wrote:\n>>>! In D2679#70934, @lothiraldan wrote:\n>>>>! In D2679#69388, @durin42 wrote:\n>>> I'm slowly becoming convinced that the long-unquestioned axiom that \"all markers are distributed globally\" isn't correct, and this is part of why: it's potentially of great value to be able to restore a change by re-pulling it, even though the obsmarkers would normally cause it to be deleted.\n>> Avoiding silent reappearance of the locally obsolete changeset that we see on a remote repository is a core feature of obsolescence. Actually, it is the one issue that prompted the creation of changeset evolution in the first place. \n> \n> There's a difference (in my view) between something accidentally coming back and intentionally coming back. The current state of affairs prevents both. I feel like we can do better.\n\nI feel like detecting if an obsolete changeset is re-added accidentally or intentionally is a near impossible problem. We have submitted code recently to detect when an obsolete changeset is re-added, but again we don't know if it is accidentally or intentionally. The safe path here is to inform the user about suspicious situations and give them the tool to explicitly restore changesets they want to be restored. That why we have been working on an explicit `hg rewind` command in evolve.\n\n> \n>> We and the other people using distributed evolution rely on this behavior on a daily basis. The includes people who picked up the evolve extension on their own and came up with their own workflow without ever speaking to us. We can see some user interfaces adjustment in the future, but the set of synchronized markers and the associated behavior is something we are happy about. It has been well tested in diverse teams and situation for multiple years now.\n> \n> I've brought this up repeatedly and been dismissed with this exact argument every time. I weary of it, because it's not a new argument, it's just blind devotion to the initial design without any attempt at reflection if we can do better.\n\n\nSince I joined Octobus, I've witnessed the exploration of all the remaining uncharted territories and solving of most of the resulting associated challenges. In particular, some important aspects of distributed evolution: instabilities resolutions and efficient obsmarkers exchanges have been solved and have working implementations used on a daily basis. We did alter the initial design when deemed so by new information from exploration or feedback of evolve users.\nDuring these developments, we did not find reasons to challenge the obsolescence core concepts. They, in fact, proved a useful help to build solutions to the distributed evolution challenges. To name a few of these progress and design changes: vocabulary renaming, the missing commands for history exploration and reviving, the new discovery protocol and more recently how to track fold in obsmarkers.\n\nIn a similar way, the numbers and types of distributed evolution users have grown and we had more and more opportunity to exchange with them. We base our plans on more than \"some people using it without complains\". They are a diverse and large corpus of people we have been talking to and studied their workflows. Here again, core concepts, in particular, the global state and instabilities are things that, practically helps teams to use distributed evolution workflows and newcomers to get a good grasp of it. Important behavior designed and tested in the past 5 years, like the exchange behavior, have been battle tested and real people rely on them in their day to day workflow.\n\nSo, it might seem like the same argument, but it is actually a stronger one. The data to back it kept growing in the past couple of years.\n\nIf you need more details, check our recent blog post about evolution: https:\/\/octobus.net\/blog\/2018-09-03-evolve-status-2018-08.html\n\n> I don't dispute that evolution as currently implemented is a good thing, but I feel like there's room for significant improvement while simultaneously simplifying the exchange algorithms. Care to try and convince me why I'm wrong, without anecdotal \"many people use this and haven't complained\" arguments?\n\n\nSure, the proposal in this PoC (\"unobsolete\" all re-added changesets) break basic distributed evolution workflow very quickly. Here are small examples among many. They display simple draft changesets roundtrips:\n\n- Example A:\n\n        - I am working on a repository with a changeset A that is present also on my default server\n        - I amend A into A'\n        - I pull from my default server, the server doesn't know yet that A has been rewritten into A'. A is sent by the server.\n        - A is hidden before the pull. Getting A to be visible again would be confusing for me as I would now have both A and A' \"alive\" at the same time.\n \n- Example B:\n\n        - I am working on a repository with a changeset A that is present also on my default server\n        - I amend A into A'\n        - One of my coworkers push a changeset B on top of A to the server\n        - I pull from my default server\n        - I receive both B and A, and I have all the needed information to stabilize B and continue my work. I don't want A to become \"unobsolete\" on pull.\n\nWe can provide other examples if needed.\n\nCould you give some details about the improvements that you suggest and that what kind of core changes they would require and their effects on distributed evolution?\n","author":"lothiraldan","id":"72403","dateCreated":"1538147960","dateModified":"1538147960"},{"type":"comment","comment":">>! In D2679#70934, @lothiraldan wrote:\n>>>! In D2679#69388, @durin42 wrote:\n>> I'm slowly becoming convinced that the long-unquestioned axiom that \"all markers are distributed globally\" isn't correct, and this is part of why: it's potentially of great value to be able to restore a change by re-pulling it, even though the obsmarkers would normally cause it to be deleted.\n> Avoiding silent reappearance of the locally obsolete changeset that we see on a remote repository is a core feature of obsolescence. Actually, it is the one issue that prompted the creation of changeset evolution in the first place. \n\nThere's a difference (in my view) between something accidentally coming back and intentionally coming back. The current state of affairs prevents both. I feel like we can do better.\n\n> We and the other people using distributed evolution rely on this behavior on a daily basis. The includes people who picked up the evolve extension on their own and came up with their own workflow without ever speaking to us. We can see some user interfaces adjustment in the future, but the set of synchronized markers and the associated behavior is something we are happy about. It has been well tested in diverse teams and situation for multiple years now.\n\nI've brought this up repeatedly and been dismissed with this exact argument every time. I weary of it, because it's not a new argument, it's just blind devotion to the initial design without any attempt at reflection if we can do better. I don't dispute that evolution as currently implemented is a good thing, but I feel like there's room for significant improvement while simultaneously simplifying the exchange algorithms. Care to try and convince me why I'm wrong, without anecdotal \"many people use this and haven't complained\" arguments?\n\n>> It's _super confusing_ when I `hg import` a patch and it seems to work but also immediately disappears, so I've got more sympathy for this PoC series than I do the theoretical purity of markers having any kind of globalness. Does that make sense?\n> This seems like an unrelated user interface issues. We usually warn the user when their working copy becomes obsolete, pointing out to the newest version\/evolution. We have to extend this messages logic to `hg import` to clarify the situation.\n\nI disagree, perhaps unsurprisingly.","author":"durin42","id":"70935","dateCreated":"1537377795","dateModified":"1537377795"},{"type":"comment","comment":">>! In D2679#69388, @durin42 wrote:\n>>>! In D2679#68489, @lothiraldan wrote:\n>> To take a step back, I'm wondering what's the end goal? I remember there was a discussion about having rebase enabled by default, is it related?\n> \n> Getting rebase (and maybe histedit?) enabled by default is my recollection of the rough goal.\n> \n>> \n>> The behavior target by this series (\"unobsolete\" re-pulled changeset) conflicts with the final behavior we want for Changeset Evolution. Intermediate steps are a good way to make progress. I feel like it is important to write down a clear plan when it comes to adding behavior that does not match our final goals. How are we planning to transition from the local-only step to full (ie, distributed) Evolution?\n> \n> I'm slowly becoming convinced that the long-unquestioned axiom that \"all markers are distributed globally\" isn't correct, and this is part of why: it's potentially of great value to be able to restore a change by re-pulling it, even though the obsmarkers would normally cause it to be deleted.\nAvoiding silent reappearance of the locally obsolete changeset that we see on a remote repository is a core feature of obsolescence. Actually, it is the one issue that prompted the creation of changeset evolution in the first place. We and the other people using distributed evolution rely on this behavior on a daily basis. The includes people who picked up the evolve extension on their own and came up with their own workflow without ever speaking to us. We can see some user interfaces adjustment in the future, but the set of synchronized markers and the associated behavior is something we are happy about. It has been well tested in diverse teams and situation for multiple years now.\n> It's _super confusing_ when I `hg import` a patch and it seems to work but also immediately disappears, so I've got more sympathy for this PoC series than I do the theoretical purity of markers having any kind of globalness. Does that make sense?\nThis seems like an unrelated user interface issues. We usually warn the user when their working copy becomes obsolete, pointing out to the newest version\/evolution. We have to extend this messages logic to `hg import` to clarify the situation.\n","author":"lothiraldan","id":"70934","dateCreated":"1537368619","dateModified":"1537368619"},{"type":"comment","comment":">>! In D2679#68489, @lothiraldan wrote:\n> To take a step back, I'm wondering what's the end goal? I remember there was a discussion about having rebase enabled by default, is it related?\n\nGetting rebase (and maybe histedit?) enabled by default is my recollection of the rough goal.\n\n> \n> The behavior target by this series (\"unobsolete\" re-pulled changeset) conflicts with the final behavior we want for Changeset Evolution. Intermediate steps are a good way to make progress. I feel like it is important to write down a clear plan when it comes to adding behavior that does not match our final goals. How are we planning to transition from the local-only step to full (ie, distributed) Evolution?\n\nI'm slowly becoming convinced that the long-unquestioned axiom that \"all markers are distributed globally\" isn't correct, and this is part of why: it's potentially of great value to be able to restore a change by re-pulling it, even though the obsmarkers would normally cause it to be deleted. It's _super confusing_ when I `hg import` a patch and it seems to work but also immediately disappears, so I've got more sympathy for this PoC series than I do the theoretical purity of markers having any kind of globalness. Does that make sense?","author":"durin42","id":"69389","dateCreated":"1536762660","dateModified":"1536762660"},{"type":"comment","comment":"Hi Pulkit,\n\nThanks for your patience. I had a couple of important things to get out of the way before I could turn my attention to this.\n\nI reached out to Ryan and he sent me the code he wrote at the 4.6 Sprint. I made it available here to support the discussion: https:\/\/phab.mercurial-scm.org\/D4479. The core differences in his approach are to filter out obsmarkers affecting the \"re-pulled\" nodes instead of \"stripping\" those markers. The main benefit is to avoid information loss. Stripping markers will break the evolution history, preventing user to benefit from it. Filtering markers out mean that the history will be fully restored if the affected changeset get obsolete again. It can be triggered by the same events.This is a pure implementation detail, having the same user-level effect than the behavior proposed in this Proof of Concept series.\n\nRegarding the implementation of this series, I feel like the current detection code needs to move at a higher level. Having changegroup aware of obsmarkers at such a low level seems wrong and can lead to consistency issues if the bundle contains  obsmarkers. An alternative approach would be to keep track of redundant incoming nodes during changegroup processing (on the transaction object as we are already doing for all new nodes), and process that list at the end of the transaction. We'll give a shot at such implementation, it is useful in other scenarios.\n\nTo take a step back, I'm wondering what's the end goal? I remember there was a discussion about having rebase enabled by default, is it related?\n\nThe behavior target by this series (\"unobsolete\" re-pulled changeset) conflicts with the final behavior we want for Changeset Evolution. Intermediate steps are a good way to make progress. I feel like it is important to write down a clear plan when it comes to adding behavior that does not match our final goals. How are we planning to transition from the local-only step to full (ie, distributed) Evolution?","author":"lothiraldan","id":"68489","dateCreated":"1536103480","dateModified":"1536103480"},{"type":"comment","comment":"Hey @lothiraldan, if not the patches itself, can you please explain the approach taken?\nIf I don't hear from you this week, I will push this series so that we can have enough time testing this in current cycle. Thanks!","author":"pulkit","id":"67297","dateCreated":"1535375938","dateModified":"1535375938"},{"type":"comment","comment":"@lothiraldan Gentle reminder for the series you were talking about.","author":"pulkit","id":"66824","dateCreated":"1534935417","dateModified":"1534935417"},{"type":"comment","comment":">>! In D2679#64079, @lothiraldan wrote:\n>>>! In D2679#62662, @pulkit wrote:\n>> These patches were result of a very extensive discussion about what ways we have to start supporting obsmarkers by default. I will like to push these changesets so that we can try these in this cycle. If I don't hear any concern in a week, I will push them.\n> \n> We made a series with Ryan during the sprint that had the advantage of not requiring to delete obs-markers. I will undust it, rebase it and send it here for making the discussion go forward.\n\nOh nice! That will be great! Looking forward to your series.","author":"pulkit","id":"64233","dateCreated":"1533639536","dateModified":"1533639536"},{"type":"comment","comment":">>! In D2679#62662, @pulkit wrote:\n> These patches were result of a very extensive discussion about what ways we have to start supporting obsmarkers by default. I will like to push these changesets so that we can try these in this cycle. If I don't hear any concern in a week, I will push them.\n\nWe made a series with Ryan during the sprint that had the advantage of not requiring to delete obs-markers. I will undust it, rebase it and send it here for making the discussion go forward.","author":"lothiraldan","id":"64080","dateCreated":"1533587987","dateModified":"1533587987"},{"type":"comment","comment":"These patches were result of a very extensive discussion about what ways we have to start supporting obsmarkers by default. I will like to push these changesets so that we can try these in this cycle. If I don't hear any concern in a week, I will push them.","author":"pulkit","id":"62663","dateCreated":"1533162260","dateModified":"1533162260"},{"type":"update","diffId":"6637","author":"indygreg","id":"43207","dateCreated":"1520210571","dateModified":"1520210571"}],"dateCreated":"1520210571","dateModified":"1539204897","status":"Needs Review"},{"id":"4716","callsign":"HG","title":"lfs: don't add extension to hgrc after clone or share (BC)","author":"indygreg","summary":"Now that repository loading in core supports automatically loading\nthe lfs extension when the \"lfs\" requirement is present, we no\nlonger need to update the .hg\/hgrc of newly-created repos to load\nthe lfs extension!\n\nI'm marking this as BC because it is a change in behavior. But users\nshould not notice unless they create an LFS repo with new Mercurial\nand then attempt to use it with an old versions that doesn't support\nautomatic extension loading.","testPlan":"","lineCount":"36","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"11324","author":"indygreg","id":"71559","dateCreated":"1537805608","dateModified":"1537805608"}],"dateCreated":"1537805608","dateModified":"1537805609","status":"Needs Review"},{"id":"4479","callsign":"HG","title":"[RFC] obsolete: add mechanism to filter obsstore","author":"lothiraldan","summary":"This patch is not ready to land and only sent for discussion.","testPlan":"","lineCount":"24","dependsOn":[],"reviewers":[],"ccs":["pulkit","martinvonz","mercurial-devel"],"actions":[{"type":"comment","comment":"I just had a quick look. obsmarker repr hash, are we kind of inventing a way to index obsmarkers? I am pretty sure you people have thought about that, can you explain why you went with obsmarker repr hash instead of including a real index?\n\nAlso, feel free to point me to old discussions if this was discussed earlier.","author":"pulkit","id":"68685","dateCreated":"1536183949","dateModified":"1536183949"},{"type":"comment","comment":"I'll reply to my own question: The context is in D2679.","author":"martinvonz","id":"68491","dateCreated":"1536103749","dateModified":"1536103749"},{"type":"comment","comment":"Why? (Sorry if I'm asking to early and you were just about to send an update.)","author":"martinvonz","id":"68488","dateCreated":"1536103366","dateModified":"1536103366"},{"type":"update","diffId":"10777","author":"lothiraldan","id":"68482","dateCreated":"1536103193","dateModified":"1536103193"}],"dateCreated":"1536103193","dateModified":"1536183949","status":"Needs Review"},{"id":"4409","callsign":"HG","title":"rebase: skip *all* obsolete revisions, just warn about divergence","author":"martinvonz","summary":"We already skip obsolete revisions in some case: if there is no\nsuccessor, or when the successor is in the rebase set or in the\ndestination, I think. However, we instead error out if the successor\nis elsewhere (e.g. a child or a sibling of the destination), because\nit would cause divergence. The previous commit fixed one specific case\nof this.\n\nConsider this history (based on a test case updated by this patch):\n\n  o  D\n  |\n  | o  B'\n  |\/\n  | o  C\n  | |\n  | x  B\n  |\/\n  o A\n\nIf the user now runs `hg rebase -s B -d D` we would error out and tell\nthem that it would cause divergence from B. This patch makes it so we\ninstead ignore B and C (and tell the user that we're doing that\nbecause it would cause divergence). I think this simpler model will be\neasier for users to understand (I had also thought that all obsolete\ncommits and their descendants were skipped until we got reports from\nusers that that wasn't the case).\n\nNote that we still skip just the obsolete (not its descendants) if\nit's a prune or if the successor is in the destination.\n\nThis should also let us simplify the source quite a bit. I'll do that\nin later commits after I've heard people's thoughts on this one.","testPlan":"","lineCount":"40","dependsOn":[],"reviewers":[],"ccs":["lothiraldan","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"Changing the behavior of `--src` to ignore obsolete and orphan unrelated to the destination seems like a good idea.\n\nHowever, this change seems to also affect `--rev`. The `--rev` allow for a precise selection of what the user wants to see rebased and it feels like we should stick to the user wishes here. Dropping explicitly selected revisions feels wrong and will make some use cases harder to perform.","author":"lothiraldan","id":"67654","dateCreated":"1535551219","dateModified":"1535551219"},{"type":"comment","comment":"> @@ -1289,18 +1286,16 @@\n>    o  0:b173517d0057 a\n>    \n>    $ hg rebase -d 0 -r 2\n> -  rebasing 2:a82ac2b38757 \"c\" (c)\n> +  note: not rebasing 2:a82ac2b38757 \"c\" (c) and its descendants as this would cause divergence\n\nLooks like the fix for issue5782 regressed.\n\nhttps:\/\/bz.mercurial-scm.org\/show_bug.cgi?id=5782","author":"yuja","id":"67642","dateCreated":"1535547342","dateModified":"1535547342"},{"type":"update","diffId":"10616","author":"martinvonz","id":"67528","dateCreated":"1535441604","dateModified":"1535441604"}],"dateCreated":"1535441604","dateModified":"1535551219","status":"Needs Review"},{"id":"4283","callsign":"HG","title":"webcommands: fix `@webcommand` decorator","author":"sheehan","summary":"This commit fixes the `@webcommand` decorator used to define\nwebcommands. Although webcommands are currently using this\ndecorator, it does not behave as intended. Using the decorator\nshould record the name of the decorator in a `commands` dict,\nand when a request arrives to hgweb the correct function to\ncall should be resolved from that dict.\n\nIn the current implementation the command is added to the\ncommands dict, but when hgweb attempts to resolve the function\nwhile processing a request, it instead looks for an attribute\nwith the same name attached to the `webcommands` module. To\nsummarize, a command 'commandname' should be resolved from\n\n    `mercurial.hgweb.webcommands.commands['commandname']`\n\nbut is instead being resolved from\n\n    `mercurial.hgweb.webcommands.commandname`\n\nThe decorator appears to be working on the core webcommands\n(such as log, rev, file) however this is because those\ncommands are defined with the same name in the underlying\nPython function.\n\nThis commit changes hgweb_mod.py to resolve the function used\nfrom webcommands to come from the `commands` dict in the\n`webcommands` module. Due to the change in how webcommands\nare resolved, a `wrapwebcommand` function is also added, which\nwraps a webcommand by applying the wrapper as a partial function\nand overwrites the existing function in the `commands` dict.\n\nWrapped webcommands in shipped extensions and hgweb tests\nare changed to use the fixed decorator and `wrapwebcommand`\nfunction.","testPlan":"","lineCount":"48","dependsOn":[],"reviewers":[],"ccs":["foozy","indygreg","mercurial-devel"],"actions":[{"type":"comment","comment":"Sorry, I overlooked delivery error of reply to phabricator.\n\nThis is re-sending of the reply at Sat, 18 Aug 2018 15:18:10 +0900,\nwhich was cc-ed to mercurial-devel@mercurial-scm.org.\n\nAt Wed, 15 Aug 2018 19:00:51 +0000,\nsheehan (Connor Sheehan) wrote:\n[snip]\n> diff --git a\/mercurial\/hgweb\/hgweb_mod.py b\/mercurial\/hgweb\/hgweb_mod.py\n> --- a\/mercurial\/hgweb\/hgweb_mod.py\n> +++ b\/mercurial\/hgweb\/hgweb_mod.py\n> @@ -354,7 +354,7 @@\n>                  cmd = cmd[style + 1:]\n>  \n>              # avoid accepting e.g. style parameter as command\n> -            if util.safehasattr(webcommands, cmd):\n> +            if cmd in webcommands.commands:\n>                  req.qsparams['cmd'] = cmd\n>  \n>              if cmd == 'static':\n> @@ -416,15 +416,15 @@\n>  \n>                  res.headers['ETag'] = tag\n>  \n> -            if cmd not in webcommands.__all__:\n> +            if cmd not in webcommands.commands:\n>                  msg = 'no such method: %s' % cmd\n>                  raise ErrorResponse(HTTP_BAD_REQUEST, msg)\n>              else:\n>                  # Set some globals appropriate for web handlers. Commands can\n>                  # override easily enough.\n>                  res.status = '200 Script output follows'\n>                  res.headers['Content-Type'] = ctype\n> -                return getattr(webcommands, cmd)(rctx)\n> +                return webcommands.commands[cmd](rctx)\n>  \n>          except (error.LookupError, error.RepoLookupError) as err:\n>              msg = pycompat.bytestr(err)\n\nIMHO, for backward compatibility, this kind of (API) change should\nhave deprecation period before stopping support, and should use\nui.deprecwan() while such period, like below (this implementation\nassumes introduction of new decorator registrar.webcommand).\n\n    def _getwebcommand(ui, name):\n        cmd = webcommands.commands.get(name, None)\n        if not cmd:\n            if (name in webcommands.__all__ and\n                util.safehasattr(webcommands, name)):\n                cmd = getattr(webcommands, name)\n                # store into webcommands.commands for subsequent access\n                webcommands.commands[name] = cmd\n\n                ui.deprecwarn('legacy registration for webcommand %s,'\n                              ' use registrar.webcommand decorator' % name,\n                              '5.0')\n        return cmd\n\n\n> diff --git a\/hgext\/largefiles\/uisetup.py b\/hgext\/largefiles\/uisetup.py\n> --- a\/hgext\/largefiles\/uisetup.py\n> +++ b\/hgext\/largefiles\/uisetup.py\n> @@ -151,7 +151,7 @@\n>      extensions.wrapfunction(archival, 'archive', overrides.overridearchive)\n>      extensions.wrapfunction(subrepo.hgsubrepo, 'archive',\n>                              overrides.hgsubrepoarchive)\n> -    extensions.wrapfunction(webcommands, 'archive', overrides.hgwebarchive)\n> +    webcommands.wrapwebcommand('archive', overrides.hgwebarchive)\n>      extensions.wrapfunction(cmdutil, 'bailifchanged',\n>                              overrides.overridebailifchanged)\n\nAfter changes above, direct invocation of original webcommand function\n'webcommands.archive()' from another code path avoids wrapping effect,\nbecause 'wrapwebcommand' wraps only the function stored in dispatch\ntable 'webcommands.command'.\n\nNot for webcommand wrapping example, but for normal command wrapping\nexample, largefiles extension wraps both 'rebase' command and 'rebase'\nfunction. In largefiles\/uisetup.py::\n\n        if name == 'rebase':\n            extensions.wrapcommand(getattr(module, 'cmdtable'), 'rebase',\n                overrides.overriderebase)\n            extensions.wrapfunction(module, 'rebase',\n                                    overrides.overriderebase)\n\nOf course, it will be rare that un-wrapped original function causes\nproblem in webcommand case. But \"wrap function in dispatch table\"\nshould be separated from \"stop wrapping original webcommand function\"\nat first, IMHO.\n\n\nI'm also working around webcommand registration, and will post patches\nsoon. But, of course, feel free to re-send your revised one, for\nfeedback between us :-)","author":"foozy","id":"66813","dateCreated":"1534900316","dateModified":"1534900316"},{"type":"comment","comment":">>! In D4283#65988, @indygreg wrote:\n> This seems like a strict improvement.\n> \n> But the proper way to register web commands from extensions would be to go through the `registrar` API and have the extension loader look for a well-named symbol in each extension module that is loaded and hgweb would consult the registrar for active commands. In theory, this will only activate web commands on repositories that have an extension loaded.\n> \n> Search for `templatefilter` in `mercurial\/extensions.py` for an example of how all this works.\n> \n> Would you be willing to try that approach? It doesn't have to be perfect. But we are moving to the registrar for extensions wishing to install well-defined things. And web commands fit that bill.\n\nSeems reasonable to me! I took a look through the code and I think I understand what is going on. I'll update this patch with something that uses the registrar API.","author":"sheehan","id":"66593","dateCreated":"1534772811","dateModified":"1534772811"},{"type":"plan-changes","author":"sheehan","id":"66592","dateCreated":"1534772811","dateModified":"1534772811"},{"type":"comment","comment":"This seems like a strict improvement.\n\nBut the proper way to register web commands from extensions would be to go through the `registrar` API and have the extension loader look for a well-named symbol in each extension module that is loaded and hgweb would consult the registrar for active commands. In theory, this will only activate web commands on repositories that have an extension loaded.\n\nSearch for `templatefilter` in `mercurial\/extensions.py` for an example of how all this works.\n\nWould you be willing to try that approach? It doesn't have to be perfect. But we are moving to the registrar for extensions wishing to install well-defined things. And web commands fit that bill.","author":"indygreg","id":"65989","dateCreated":"1534378968","dateModified":"1534378968"},{"type":"update","diffId":"10360","author":"sheehan","id":"65975","dateCreated":"1534359638","dateModified":"1534359638"}],"dateCreated":"1534359638","dateModified":"1534900316","status":"Changes Planned"},{"id":"4301","callsign":"HG","title":"tests: add a directory 'knownfailures' to check in known failures","author":"pulkit","summary":"There are some things which everyone of us stumble upon and found out that this\ndoes not work. Sometimes, we hg developers know that these things does not works\nbecause of experience. But this does not scale well when we have a new developer\nor maybe a user who wants to see what does not work and is interested in fixing\nthat.\n\nChecking in the tests about the things which don't work will help others to\nreproduce these and also helps in fixing because of functionalities\n.\/run-tests.py provides.\n\nIIRC we had this thought in one of the previous sprints also to checkin some of\nthe known failures.\n\nI am starting with checking in a basic test failure. But I plan to check in\nmore narrow related failures which we have found.\n\nUnable to find easily what exactly broken with merges and narrow made me to\nimplement this idea so that we won't have similar problem in future.","testPlan":"","lineCount":"4","dependsOn":[],"reviewers":["durin42"],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"I also think that the 'knowfailures' can serve as a good place for new contributors.\nI don't want to check-in all the failures and leave them unfixed. It's like I don't know which one I will be able to fix and I have a reproduction which can help others.","author":"pulkit","id":"66188","dateCreated":"1534432054","dateModified":"1534432054"},{"type":"update","diffId":"10391","author":"pulkit","id":"66182","dateCreated":"1534431586","dateModified":"1534431586"}],"dateCreated":"1534431586","dateModified":"1534432054","status":"Needs Review"},{"id":"3896","callsign":"HG","title":"copies: handle case when both merge cset are not descendant of merge base","author":"pulkit","summary":"There can be cases when both the changesets which we are merging are not\ndescendants of the merge base. In those cases dirtyc1 and dirtyc2 both will be\ntrue. The existing code assumes that either of them will be true always but that\nis not a right assumption.\n\nI found this while working with content-divergence resolution. In\ncontent-divergence resolution, we use the common predecessor as the merge base\nfor resolving content divergence and there it can be possible that the merge\nbase is not the descendant of both the content-divergence changsets.\n\nThe code in content-divergence which does this is at:\nhttps:\/\/www.mercurial-scm.org\/repo\/evolve\/file\/b81fd1487e04\/hgext3rd\/evolve\/evolvecmd.py#l507","testPlan":"","lineCount":"5","dependsOn":[],"reviewers":[],"ccs":["spectral","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D3896#65986, @spectral wrote:\n> Any updates on this?  I'm poking at updating this function in core, and not too excited to have to also modify the copy in evolve that seems to have spawned :\/\n\nI am yet to write tests. Feel free to update the one in core, I will take care of the evolve copy.","author":"pulkit","id":"66180","dateCreated":"1534428512","dateModified":"1534428512"},{"type":"comment","comment":"Any updates on this?  I'm poking at updating this function in core, and not too excited to have to also modify the copy in evolve that seems to have spawned :\/","author":"spectral","id":"65987","dateCreated":"1534370496","dateModified":"1534370496"},{"type":"comment","comment":"Can you add some tests that make both `dirtyc1` and `dirtyc2` set, and\ntrigger copy tracing?\n\n> Since we can have both dirtyc1, and dirtyc2 true, I am not sure whether\n> this else should be turned into it's own if statement?\n\nNo idea. I doubt if the current copy tracing can handle such cases. From\nmy vague memory, the current algorithm relies on the fact that the pseudo\n`base` revision exists in between the `c1` and the `c2`.","author":"yuja","id":"60811","dateCreated":"1531138991","dateModified":"1531138991"},{"type":"inline","comment":"Since we can have both dirtyc1, and dirtyc2 true, I am not sure whether this else should be turned into it's own if statement?","replyTo":null,"isNewFile":"1","line":"496","lineLength":"0","path":"mercurial\/copies.py","diffId":"9471","author":"pulkit","id":"60802","dateCreated":"1531041256","dateModified":"1531041256"},{"type":"update","diffId":"9471","author":"pulkit","id":"60797","dateCreated":"1531041116","dateModified":"1531041116"}],"dateCreated":"1531041116","dateModified":"1534428512","status":"Needs Review"},{"id":"4053","callsign":"HG","title":"[RFC]hgweb: garbage collect on every request in hgweb_mod too","author":"pulkit","summary":"We recently updated to mercurial 4.6.2 on our servers and also increased number\nof requests to be made on server at one time. This made hgweb instance takes up\na lot of memory, sometime upto 50GB of memory when requests are made parallely.\n\nThis patch is motivated from\nhttps:\/\/www.mercurial-scm.org\/repo\/hg-committed\/rev\/ff2370a70fe8 which adds\ngc.collect() call for the server which serves multiple repositories.\n\nI tried profiling this fix, sometimes this shows less memory usage, sometimes\nmore, so I am not sure whether this is right and hence RFC tag.","testPlan":"","lineCount":"16","dependsOn":[],"reviewers":[],"ccs":["av6","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D4053#62855, @av6 wrote:\n> Are you sure you're not just using hgwebdir_mod? hgweb_mod is for cases when you don't use --web-conf flag, at least that seems to be the logic that `hgweb.createapp()` uses to pick one of the two modules.\n\nI checked and we are using hgwebdir_mod. When I was testing locally I was not using --web-conf flag, so maybe that's why I ran into `hgweb_mod`. The problem still exists though and we have limited the number of requests at once. Thanks!","author":"pulkit","id":"65973","dateCreated":"1534331436","dateModified":"1534331436"},{"type":"comment","comment":"Are you sure you're not just using hgwebdir_mod? hgweb_mod is for cases when you don't use --web-conf flag, at least that seems to be the logic that `hgweb.createapp()` uses to pick one of the two modules.","author":"av6","id":"62856","dateCreated":"1533231595","dateModified":"1533231595"},{"type":"update","diffId":"9792","author":"pulkit","id":"62851","dateCreated":"1533225478","dateModified":"1533225478"},{"type":"update","diffId":"9787","author":"pulkit","id":"62829","dateCreated":"1533219726","dateModified":"1533219726"}],"dateCreated":"1533219726","dateModified":"1534331436","status":"Needs Review"},{"id":"3986","callsign":"HG","title":"split: abort if there's an unfinished operation","author":"martinvonz","summary":"","testPlan":"","lineCount":"10","dependsOn":[],"reviewers":[],"ccs":["quark","mercurial-devel"],"actions":[{"type":"comment","comment":"I think a most flexible solution is to not do the check if there is nothing to rebase.","author":"quark","id":"62080","dateCreated":"1533137720","dateModified":"1533137720"},{"type":"comment","comment":"Oh, I should have said that I agree with not queuing this patch now. We can discuss what we want to do and do it on the default branch later.","author":"martinvonz","id":"61992","dateCreated":"1533018979","dateModified":"1533018979"},{"type":"comment","comment":">>! In D3986#61989, @quark wrote:\n> FB has users reporting they need to split commits in the middle of a histedit. So this might be too restrictive.\n\nTwo thoughts:\n\n1. We had talked at Google about having the \"edit\" action create split markers if the user created multiple commits. Do you think that would address the FB users' use case?\n\n2. It seems very dangerous to not have this check at least when not using obsmarkers and there are descendants of the current commit (split then rebases the descendants), so I'd like to keep the check in at least that case.\n","author":"martinvonz","id":"61991","dateCreated":"1533014407","dateModified":"1533014407"},{"type":"comment","comment":"FB has users reporting they need to split commits in the middle of a histedit. So this might be too restrictive.","author":"quark","id":"61990","dateCreated":"1533014171","dateModified":"1533014171"},{"type":"update","diffId":"9671","author":"martinvonz","id":"61978","dateCreated":"1532987112","dateModified":"1532987112"}],"dateCreated":"1532987112","dateModified":"1533137720","status":"Needs Review"},{"id":"3946","callsign":"HG","title":"obsolete: resolved ValueError for var containing 2 ':' chars(issue-5783)","author":"abhyudaypratap","summary":"feature Note accepts ':' chars\nSo metadata of obsmarker consists of more then 1 ':' char,\nThe content of the variable 'data' in this function is:\n'date:1518013344.878793 -3600\\x00ef1:0\\x00note:6c95ca::a1e17f\\x00p1:ed7673f73387b36521da58a87f08e02e4a795ded\\x00user:Denis Laxalde <xxx@yyy.zz>'\n\nresulting in giving a error ValueError (too many values to unpack) because we are trying to store multiple values into two variables key and value\n\nResolving this error by splitting the variable 'l' from the first occurence of ':'\nkey, value = l.split(\"\", 1)","testPlan":"","lineCount":"2","dependsOn":[],"reviewers":[],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"Looks good. Can you add a test?\n\nhttps:\/\/www.mercurial-scm.org\/wiki\/ContributingChanges#Coding_style_and_testing\n\nThe version 0 format can be enforced by `--config format.obsstore-version=0`.","author":"yuja","id":"61491","dateCreated":"1531661257","dateModified":"1531661257"},{"type":"update","diffId":"9596","author":"abhyudaypratap","id":"61478","dateCreated":"1531593829","dateModified":"1531593829"}],"dateCreated":"1531593829","dateModified":"1531661257","status":"Needs Review"},{"id":"3830","callsign":"HG","title":"rebase: suppress transaction warns during dry-run","author":"khanchi97","summary":"Suppressed warnings thrown while aborting a transaction during\ndryrun because these warnings does not sound safe to user.","testPlan":"","lineCount":"23","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"9593","author":"khanchi97","id":"61465","dateCreated":"1531549446","dateModified":"1531549446"},{"type":"update","diffId":"9501","author":"khanchi97","id":"60911","dateCreated":"1531233875","dateModified":"1531233875"},{"type":"update","diffId":"9384","author":"khanchi97","id":"60399","dateCreated":"1530438740","dateModified":"1530438740"},{"type":"update","diffId":"9359","author":"khanchi97","id":"60261","dateCreated":"1530295767","dateModified":"1530295767"},{"type":"update","diffId":"9347","author":"khanchi97","id":"60219","dateCreated":"1530216657","dateModified":"1530216657"},{"type":"update","diffId":"9269","author":"khanchi97","id":"59837","dateCreated":"1529835539","dateModified":"1529835539"},{"type":"update","diffId":"9267","author":"khanchi97","id":"59827","dateCreated":"1529832650","dateModified":"1529832650"}],"dateCreated":"1529832650","dateModified":"1531549447","status":"Needs Review"},{"id":"3670","callsign":"HG","title":"cmdutil: don't return statedetectionpredicate function from _getrepostate()","author":"pulkit","summary":"This is a part of refactoring which can lead us where we can unify\ncmdutil.STATES and cmdutil.unfinishedstates easily.","testPlan":"","lineCount":"4","dependsOn":["3669"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"plan-changes","author":"pulkit","id":"61257","dateCreated":"1531344976","dateModified":"1531344976"},{"type":"update","diffId":"8925","author":"pulkit","id":"57635","dateCreated":"1527632579","dateModified":"1527632579"}],"dateCreated":"1527632579","dateModified":"1531344976","status":"Changes Planned"},{"id":"3669","callsign":"HG","title":"cmdutil: have statefile names in STATES instead of functions","author":"pulkit","summary":"This will help us in unifying cmdutil.STATES and cmdutil.unfinishedstates as the\nchecking logic for STATES is moved to _getrepostate() and STATES now have just\nfilenames which is similar to unfinishedstates.","testPlan":"","lineCount":"21","dependsOn":[],"reviewers":[],"ccs":["martinvonz","mercurial-devel"],"actions":[{"type":"comment","comment":"I won't have time before the upcoming freeze to get this done.","author":"pulkit","id":"61256","dateCreated":"1531344957","dateModified":"1531344957"},{"type":"plan-changes","author":"pulkit","id":"61255","dateCreated":"1531344957","dateModified":"1531344957"},{"type":"inline","comment":"(Sorry, I missed this one too. I have turned off personal emails from phabricator and use mercurial-devel to keep track of people replying to me.)\n\nThe object sounds good API. I will try that.","replyTo":"58293","isNewFile":"1","line":"3210","lineLength":"0","path":"mercurial\/cmdutil.py","diffId":"8924","author":"pulkit","id":"60483","dateCreated":"1530480466","dateModified":"1530480466"},{"type":"inline","comment":"It's a bit more complicated, I agree, but I think it's better than the alternative. If it removes the need for clearable, it's not that much more complicated.\n\nAn alternative would be to create an object with [is]dirty(), allowcommit(), and clear() methods and have a function that creates such an object for file-based states (all but .hg\/merge?). That would reduce the duplication of fileexistspredicate(<name>) and clearfunction(<name>).\n\nPS. Sorry about the delay. I've been away.","replyTo":"57884","isNewFile":"1","line":"3210","lineLength":"0","path":"mercurial\/cmdutil.py","diffId":"8924","author":"martinvonz","id":"58293","dateCreated":"1528746902","dateModified":"1528746902"},{"type":"inline","comment":"Don't you think it's getting a bit complicated?","replyTo":"57834","isNewFile":"1","line":"3210","lineLength":"0","path":"mercurial\/cmdutil.py","diffId":"8924","author":"pulkit","id":"57884","dateCreated":"1528027688","dateModified":"1528027688"},{"type":"inline","comment":"We don't have to. We could add a `clearstatefn` function in addition to the `statedetectionpredicate`. Perhaps the `if not clearable and ...` stuff could move into the function in that case","replyTo":"57827","isNewFile":"1","line":"3210","lineLength":"0","path":"mercurial\/cmdutil.py","diffId":"8924","author":"martinvonz","id":"57834","dateCreated":"1527872876","dateModified":"1527872876"},{"type":"inline","comment":">How about instead making unfinishedstates more generic by supporting a predicate there\n> instead of the file? We could still allow files as well for BC for a little while.\n\n@martinvonz : because of above util.unlink() we have to keep the filenames in unfinishedstates. :(","replyTo":null,"isNewFile":"1","line":"3210","lineLength":"0","path":"mercurial\/cmdutil.py","diffId":"8924","author":"pulkit","id":"57827","dateCreated":"1527850226","dateModified":"1527850226"},{"type":"inline","comment":"The point of the STATES dict (as opposed to putting all the code here) seems to be to make it generic and extensible. Handling \"merge\" differently here seems like a step backwards. How about instead making unfinishedstates more generic by supporting a predicate there instead of the file? We could still allow files as well for BC for a little while.","replyTo":null,"isNewFile":"1","line":"649","lineLength":"1","path":"mercurial\/cmdutil.py","diffId":"8924","author":"martinvonz","id":"57645","dateCreated":"1527634784","dateModified":"1527634784"},{"type":"update","diffId":"8924","author":"pulkit","id":"57629","dateCreated":"1527632554","dateModified":"1527632554"}],"dateCreated":"1527632554","dateModified":"1531344957","status":"Changes Planned"},{"id":"3672","callsign":"HG","title":"retractboundary: add dryrun parameter","author":"khanchi97","summary":"Added the logic to find those csets whose phase will be changed\nwithout --dry-run and return those csets.","testPlan":"","lineCount":"66","dependsOn":[],"reviewers":[],"ccs":["yuja","pulkit","mercurial-devel"],"actions":[{"type":"inline","comment":"I think affected can be used here. Maybe @yuja might know better.\n\n@yuja we want to return a set of revs whose phase is changed by this function. Does affected looks like the correct set to you?","replyTo":"57830","isNewFile":"1","line":"417","lineLength":"0","path":"mercurial\/phases.py","diffId":"8948","author":"pulkit","id":"61254","dateCreated":"1531344290","dateModified":"1531344290"},{"type":"update","diffId":"8960","author":"khanchi97","id":"57892","dateCreated":"1528034158","dateModified":"1528034158"},{"type":"update","diffId":"8959","author":"khanchi97","id":"57891","dateCreated":"1528033881","dateModified":"1528033881"},{"type":"inline","comment":"okay, will do this for 'advanceboundry' too","replyTo":"57825","isNewFile":"1","line":"511","lineLength":"0","path":"mercurial\/phases.py","diffId":"8948","author":"khanchi97","id":"57833","dateCreated":"1527857439","dateModified":"1527857439"},{"type":"inline","comment":"yeah, I got it.","replyTo":"57824","isNewFile":"1","line":"430","lineLength":"0","path":"mercurial\/phases.py","diffId":"8948","author":"khanchi97","id":"57832","dateCreated":"1527857439","dateModified":"1527857439"},{"type":"inline","comment":"okay","replyTo":"57823","isNewFile":"1","line":"395","lineLength":"0","path":"mercurial\/phases.py","diffId":"8948","author":"khanchi97","id":"57831","dateCreated":"1527857439","dateModified":"1527857439"},{"type":"inline","comment":"Because I think this affected set is calculated after performing actions, when phases are changed. And calculating affected using new phaseroots. Am I missing something here?","replyTo":"57822","isNewFile":"1","line":"417","lineLength":"0","path":"mercurial\/phases.py","diffId":"8948","author":"khanchi97","id":"57830","dateCreated":"1527857439","dateModified":"1527857439"},{"type":"inline","comment":"This should better be:\n\n`If dryrun is True, no actions will be performed\n\nreturns a set of revs whose phase is changed or should be changed`","replyTo":null,"isNewFile":"1","line":"511","lineLength":"0","path":"mercurial\/phases.py","diffId":"8948","author":"pulkit","id":"57825","dateCreated":"1527845546","dateModified":"1527845546"},{"type":"inline","comment":"(Not sure which line I should put this comment on)\n\nJust like D3671, here also, the function should return the correct set of changes whose phase have been changed irrespective of the dryrun value passed.","replyTo":null,"isNewFile":"1","line":"430","lineLength":"0","path":"mercurial\/phases.py","diffId":"8948","author":"pulkit","id":"57824","dateCreated":"1527845546","dateModified":"1527845546"},{"type":"inline","comment":"Add documentation about dry-run and the return value.","replyTo":null,"isNewFile":"1","line":"395","lineLength":"0","path":"mercurial\/phases.py","diffId":"8948","author":"pulkit","id":"57823","dateCreated":"1527845546","dateModified":"1527845546"},{"type":"inline","comment":"Why are we not using this affected set here to find the changesets whose phase is changed?","replyTo":null,"isNewFile":"1","line":"417","lineLength":"0","path":"mercurial\/phases.py","diffId":"8948","author":"pulkit","id":"57822","dateCreated":"1527845546","dateModified":"1527845546"},{"type":"update","diffId":"8948","author":"khanchi97","id":"57812","dateCreated":"1527836390","dateModified":"1527836390"},{"type":"update","diffId":"8929","author":"khanchi97","id":"57663","dateCreated":"1527675912","dateModified":"1527675912"}],"dateCreated":"1527675912","dateModified":"1531344290","status":"Needs Review"},{"id":"3866","callsign":"HG","title":"histedit: use cbor to write histedit-state file","author":"pulkit","summary":"This patch starts using state.cmdstate.write() which uses cbor as serialization\nformat to write histedit-state files.\n\nCompatibility for reading old state files using new code is maintained.\n\nSome changes in test which depended on the format of histedit state file.","testPlan":"","lineCount":"64","dependsOn":[],"reviewers":["durin42"],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"I am not confident to land some state format changes at this point in the cycle. Let's do it early in next cycle.","author":"pulkit","id":"60839","dateCreated":"1531161109","dateModified":"1531161109"},{"type":"plan-changes","author":"pulkit","id":"60838","dateCreated":"1531161109","dateModified":"1531161109"},{"type":"comment","comment":">>! In D3866#60421, @yuja wrote:\n> Queued the first 4 patches, thanks.\n> \n>>    $ HGEDITOR=\"sh $TESTTMP\/editplan.sh\" hg histedit --edit-plan\n>>    $ cat .hg\/histedit-state\n>> -  v1\n>> -  055a42cdd88768532f9cf79daa407fc8d138de9b\n>> -  3c6a8ed2ebe862cc949d2caa30775dd6f16fb799\n>> -  False\n>> -  3\n>> -  drop\n>> -  e860deea161a2f77de56603b340ebbb4536308ae\n>> -  drop\n>> -  652413bf663ef2a641cab26574e46d5f5a64a55a\n>> -  drop\n>> -  3c6a8ed2ebe862cc949d2caa30775dd6f16fb799\n>> -  0\n>> -  strip-backup\/177f92b77385-0ebe6a8f-histedit.hg\n>> +  2\n> \n> I know anything other than \"v1\" will make old hg crash, but I think the\n> version syntax should stay \"v%d\" (i.e. \"v2\" in this case.)\n\nYeah, I think we need to pass version number in the state.cmdstate.read(). Supporting rebasestate will also need similar tweak.\n> \n>>      def _write(self, fp):\n>> -        fp.write('v1\\n')\n>> -        fp.write('%s\\n' % node.hex(self.parentctxnode))\n>> -        fp.write('%s\\n' % node.hex(self.topmost))\n>> -        fp.write('%s\\n' % ('True' if self.keep else 'False'))\n>> -        fp.write('%d\\n' % len(self.actions))\n>> +        data = {'parentctxnode': self.parentctxnode,\n>> +                'topmost': self.topmost,\n>> +                'keep': self.keep,\n>> +                'backupfile': self.backupfile,\n>> +                'replacements': self.replacements}\n>> +        rules = []\n>>          for action in self.actions:\n>> -            fp.write('%s\\n' % action.tostate())\n>> -        fp.write('%d\\n' % len(self.replacements))\n>> -        for replacement in self.replacements:\n>> -            fp.write('%s%s\\n' % (node.hex(replacement[0]), ''.join(node.hex(r)\n>> -                for r in replacement[1])))\n>> -        backupfile = self.backupfile\n>> -        if not backupfile:\n>> -            backupfile = ''\n>> -        fp.write('%s\\n' % backupfile)\n>> +            rules.append(action.tostate().split('\\n'))\n>> +        rules = \"\\n\".join([\"%s %s\" % (verb, rest) for [verb, rest] in rules])\n> \n> Isn't it better to serialize `[(verb, rest)]` as is since CBOR can store that?\n\nYeah, it's better. I will do that.","author":"pulkit","id":"60480","dateCreated":"1530479460","dateModified":"1530479460"},{"type":"comment","comment":"Queued the first 4 patches, thanks.\n\n>    $ HGEDITOR=\"sh $TESTTMP\/editplan.sh\" hg histedit --edit-plan\n>    $ cat .hg\/histedit-state\n> -  v1\n> -  055a42cdd88768532f9cf79daa407fc8d138de9b\n> -  3c6a8ed2ebe862cc949d2caa30775dd6f16fb799\n> -  False\n> -  3\n> -  drop\n> -  e860deea161a2f77de56603b340ebbb4536308ae\n> -  drop\n> -  652413bf663ef2a641cab26574e46d5f5a64a55a\n> -  drop\n> -  3c6a8ed2ebe862cc949d2caa30775dd6f16fb799\n> -  0\n> -  strip-backup\/177f92b77385-0ebe6a8f-histedit.hg\n> +  2\n\nI know anything other than \"v1\" will make old hg crash, but I think the\nversion syntax should stay \"v%d\" (i.e. \"v2\" in this case.)\n\n>      def _write(self, fp):\n> -        fp.write('v1\\n')\n> -        fp.write('%s\\n' % node.hex(self.parentctxnode))\n> -        fp.write('%s\\n' % node.hex(self.topmost))\n> -        fp.write('%s\\n' % ('True' if self.keep else 'False'))\n> -        fp.write('%d\\n' % len(self.actions))\n> +        data = {'parentctxnode': self.parentctxnode,\n> +                'topmost': self.topmost,\n> +                'keep': self.keep,\n> +                'backupfile': self.backupfile,\n> +                'replacements': self.replacements}\n> +        rules = []\n>          for action in self.actions:\n> -            fp.write('%s\\n' % action.tostate())\n> -        fp.write('%d\\n' % len(self.replacements))\n> -        for replacement in self.replacements:\n> -            fp.write('%s%s\\n' % (node.hex(replacement[0]), ''.join(node.hex(r)\n> -                for r in replacement[1])))\n> -        backupfile = self.backupfile\n> -        if not backupfile:\n> -            backupfile = ''\n> -        fp.write('%s\\n' % backupfile)\n> +            rules.append(action.tostate().split('\\n'))\n> +        rules = \"\\n\".join([\"%s %s\" % (verb, rest) for [verb, rest] in rules])\n\nIsn't it better to serialize `[(verb, rest)]` as is since CBOR can store that?","author":"yuja","id":"60422","dateCreated":"1530448552","dateModified":"1530448552"},{"type":"update","diffId":"9378","author":"pulkit","id":"60359","dateCreated":"1530371419","dateModified":"1530371419"}],"dateCreated":"1530371419","dateModified":"1531161109","status":"Changes Planned"},{"id":"3650","callsign":"HG","title":"serve: add an option to open in the default browser","author":"nspanti-logilab","summary":"It is inspired by a similar functionality in pydoc. `-g`\/`--graphical` may not be adequate, the only other idea that I have is `-w`\/`--window`.","testPlan":"","lineCount":"42","dependsOn":[],"reviewers":[],"ccs":["yuja","pulkit","av6","durin42","mercurial-devel"],"actions":[{"type":"comment","comment":"(Resend because I forgot to remove the \"someone wrote:\" line again, sorry.)\n\n>   For laziness,  this patch could be also useful. It is also better for text shell beginners, because they may not know that they can combine commands like that (even if it is basic).\n\nFor laziness, we can add it to `[alias]`. I'm not a fan of adding lots of\none-off options since that's the source of man page bloat.\n\nHow about document the xdg-open example in `hg help serve -v`?","author":"yuja","id":"58867","dateCreated":"1529155285","dateModified":"1529155285"},{"type":"comment","comment":"For laziness,  this patch could be also useful. It is also better for text shell beginners, because they may not know that they can combine commands like that (even if it is basic). Moreover, you can still use `hg serve` in foreground or use it in background and give the result of `--print-url` to a non web browser application (but I imagine that there is a way to duplicate stdout to multiple programs). These are the advantages of this patch that I see over `--print-url` of D3649. It is better for convenience and require less knowledge for the user, but it is not a need. D3649 was precisely suggested to me because it can fulfill the functionality of the current patch and is more versatile.","author":"nspanti-logilab","id":"58735","dateCreated":"1529052032","dateModified":"1529052032"},{"type":"comment","comment":"Do we need this patch any more since D3649 has landed and we can do `xdg-open \"$(hg serve --print-url)\"`?","author":"pulkit","id":"58567","dateCreated":"1529005653","dateModified":"1529005653"},{"type":"comment","comment":"D3649 mentions `xdg-open \"$(hg serve --print-url)\"`, which shows that --print-url can nearly replace --graphical and is more versatile.","author":"av6","id":"57842","dateCreated":"1527944680","dateModified":"1527944680"},{"type":"comment","comment":"I don't love the flag name, and am -0 on the feature in general. All terminal emulators I've used in the last 10 years have URL detection logic and make clicking the link trivial...","author":"durin42","id":"57770","dateCreated":"1527794132","dateModified":"1527794132"},{"type":"update","diffId":"8881","author":"nspanti-logilab","id":"57359","dateCreated":"1527168904","dateModified":"1527168904"}],"dateCreated":"1527168904","dateModified":"1529155285","status":"Needs Review"},{"id":"2945","callsign":"HG","title":"state: add a magicheader to each state file","author":"pulkit","summary":"This patch adds a magic header to each state file written using CBOR format so\nthat we can distinguish between old state files and new one even if old state\nfiles get successfully parsed by cbor.","testPlan":"","lineCount":"1","dependsOn":[],"reviewers":[],"ccs":["jeffpc","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D2945#58586, @pulkit wrote:\n> There is a suggestion from @jeffpc to have a plain text header in statefiles like `HGStateFile` so that user can grep for them or look into files and know that they are state files. How does that sound?\n> (@jeffpc I am not sure I explained this correctly, it will be great if you can chime in.)\n\nI don't really care about the actual string value, I just think it is a good storage design practice to have every on-disk structure contain a magic value of some sort.  (Beware, I have a storage background and therefore opinions about these things... ;) )  This makes it easier to do all sort of data recovery should the need arise.  E.g.,\n\n  - if you know that a random file (e.g., from lost+found) is a hg state file, you can ignore\/delete it and just reclone your repos\n  - hg can detect some corruption better, and depending on the state file regenerate it or error out\n  - hg developers can more easily sort out what's what when looking at buffers\/files\/etc.\n  - as an added bonus, the magic can be used for format versioning\n\n\nFWIW, the three major things that I consider essential to good on-disk structures:\n\n  # magic numbers - see above\n  # checksums - possibly two checksums: one for the header and one for the payload\n  # back-pointers - see below\n\nBack-pointers allow you to tie the file\/buffer into the bigger context - be it which state file it is, or which repository it belongs to.  In this case a state file's back-pointer could be something like the repo-id + state-file-name stored in the state file's header.  (I realize that there is no repo-id, but in general some approximation of it tends to be better than nothing.)  This should make it painfully obvious what data one is dealing with and how to parse\/interpret it just by looking at the byte-stream without any other context.\n\n\nBy the way, I think that the magic should *not* be part of the CBOR payload but rather be at a fixed location in the file.  The easier it is to find, the easier it is to detect issues (and to avoid trying to decode bad\/malicious input).","author":"jeffpc","id":"58725","dateCreated":"1529024379","dateModified":"1529024509"},{"type":"comment","comment":"There is a suggestion from @jeffpc to have a plain text header in statefiles like `HGStateFile` so that user can grep for them or look into files and know that they are state files. How does that sound?\n(@jeffpc I am not sure I explained this correctly, it will be great if you can chime in.)","author":"pulkit","id":"58587","dateCreated":"1529007034","dateModified":"1529007034"},{"type":"comment","comment":"> There are some old state files, which don't have a version header on top\n> of them like graftstate. I need suggestion on how to handle them.\n\nIn that case, we would have to either do some heuristic (like histedit), or maintain\nold\/new state files (like mergestate.) Perhaps graft can do the latter?","author":"yuja","id":"47899","dateCreated":"1522244380","dateModified":"1522244380"},{"type":"comment","comment":">>! In D2945#47831, @yuja wrote:\n> I think the magic has to vary depending on the current state file format.\n> The state file must be backward\/forward compatible with the older\/newer formats.\n> \n> If the current magic is `2\\n` (and is parsed as `int(f.readline())`) for example, the\n> CBOR preamble would have to be `3\\n`. Otherwise, old hg client cant determine\n> whether the state file is corrupted or written by newer client.\n\nThere are some old state files, which don't have a version header on top of them like graftstate. I need suggestion on how to handle them.\n","author":"pulkit","id":"47892","dateCreated":"1522235138","dateModified":"1522235138"},{"type":"comment","comment":"I think the magic has to vary depending on the current state file format.\nThe state file must be backward\/forward compatible with the older\/newer formats.\n\nIf the current magic is `2\\n` (and is parsed as `int(f.readline())`) for example, the\nCBOR preamble would have to be `3\\n`. Otherwise, old hg client cant determine\nwhether the state file is corrupted or written by newer client.\n\nFWIW, last time I reviewed `simplekeyvaluefile`, I insisted that a parser should\ntake a file stream instead of a filename, so the caller can handle compatibility thingy.\n\n```\nwith open(\"statefile\", \"rb\") as fp:\n    try:\n        version = int(fp.readline())\n    except ValueError:\n        raise some nicer exception\n    if version == 2:\n        return readold(fp)\n    elif version == 3:\n        return readcbor(fp)\n```","author":"yuja","id":"47832","dateCreated":"1522155487","dateModified":"1522155487"},{"type":"update","diffId":"7299","author":"pulkit","id":"47624","dateCreated":"1522084159","dateModified":"1522084159"}],"dateCreated":"1522084159","dateModified":"1529024379","status":"Needs Review"},{"id":"1313","callsign":"HG","title":"dirstate: gate access to self._map.dirs","author":"mbolin","summary":"`_droppath()` already checks `\"dirs\" in self._map.__dict__` before accessing\n`self._map.dirs`. This updates `_addpath()` to be equally cautious.","testPlan":"","lineCount":"23","dependsOn":[],"reviewers":["mbthomas"],"ccs":["pulkit","mbthomas","durham","mercurial-devel"],"actions":[{"type":"comment","comment":"Do we need this anymore or can this be abandoned? (trying to close some not-required-any-more differentials)","author":"pulkit","id":"58571","dateCreated":"1529006100","dateModified":"1529006100"},{"type":"inline","comment":"I don't think it's safe to do this.  We're looking for clashes between files and directories, so we do need to look in self.dirs, even if that means generating it because we're accessing it for the first time.","replyTo":null,"isNewFile":"1","line":"405","lineLength":"0","path":"mercurial\/dirstate.py","diffId":"3267","author":"mbthomas","id":"21733","dateCreated":"1509750955","dateModified":"1509750955"},{"type":"reject","author":"mbthomas","id":"21732","dateCreated":"1509750955","dateModified":"1509750955"},{"type":"update","diffId":"3267","author":"mbolin","id":"21716","dateCreated":"1509749978","dateModified":"1509749978"}],"dateCreated":"1509749978","dateModified":"1529006100","status":"Needs Revision"},{"id":"3664","callsign":"HG","title":"graft: reuse the --edit value passed initially in `hg graft --continue` (BC)","author":"pulkit","summary":"This patch starts storing the value of --edit flag passed by the user initially\nwhen they runs `hg graft --edit`. We can now read the value from graftstate in\ncase of `--continue` and respect the value which user passed earlier.\n\nThe tests changes demonstrate the fix.","testPlan":"","lineCount":"28","dependsOn":["3663"],"reviewers":[],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"Queued the first two, thanks.\n\n>   This patch starts storing the value of --edit flag passed by the user initially\n>   when they runs `hg graft --edit`. We can now read the value from graftstate in\n>   case of `--continue` and respect the value which user passed earlier.\n\nI'm -0.5 on this since --edit is an option to change the interactive behavior,\nand I think we don't preserve such options across interrupted sessions.","author":"yuja","id":"58065","dateCreated":"1528200002","dateModified":"1528200002"},{"type":"update","diffId":"8909","author":"pulkit","id":"57568","dateCreated":"1527287139","dateModified":"1527287139"}],"dateCreated":"1527287139","dateModified":"1528200002","status":"Needs Review"},{"id":"3187","callsign":"HG","title":"phase: add dry-run functionality","author":"khanchi97","summary":"Added the logic to find those csets whose phase will be changed\n(while running without --dry-run). And show the list of those csets.","testPlan":"","lineCount":"173","dependsOn":[],"reviewers":["pulkit"],"ccs":["av6","mercurial-devel"],"actions":[{"type":"update","diffId":"8962","author":"khanchi97","id":"57894","dateCreated":"1528037274","dateModified":"1528037274"},{"type":"comment","comment":"Nice work! I like where how you simplified things from previous version.\n\nIf you look at the patch, this seems to do multiple things at once which are:\n\n  * adding dry-run argument to advanceboundary and retractboundary functions\n  * adding a new --dry-run flag to hg phase\n\nLet's break things up in individual patches so that we can improve more on individual pieces. Can you split this into a separate patch for adding dryrun argument to each function, i.e. one patch for adcanceboundary, one for retractboundary, and then one last patch which adds the new flag? That will be very much helpful in reviewing this work and also making incremental changes and moving forward step by step.","author":"pulkit","id":"57621","dateCreated":"1527622549","dateModified":"1527622549"},{"type":"comment","comment":"@pulkit Now I moved the logic for finding revs (those phase will change)  to advanceboundry and retractboundry function and for now it shows all nodes. I am working to show range instead. Take a look at this when you are free :)","author":"khanchi97","id":"57619","dateCreated":"1527584154","dateModified":"1527584154"},{"type":"update","diffId":"8896","author":"khanchi97","id":"57476","dateCreated":"1527280427","dateModified":"1527280427"},{"type":"comment","comment":">>! In D3187#57349, @khanchi97 wrote:\n> okay, but I have some queries like\n> 1. How about showing revision no. instead of cset id?\n\nI think we should show cset ids. If you want to with rev numbers, go with that. This should not be a blocker to get the initial patch in.\n> 2. And in this https:\/\/pastebin.com\/raw\/kWcr9xVK example if I change revision 2 phase to --secret then how it should print the range, I mean now we have branches in this range?\n> \n> Can we show that range like this:\n> \n> 0316ce92851d : : b385d13d5ed4  draft  ->  secret\n> 0316ce92851d : : 4ccc844d5454   draft  -> secret\n\nThere are two ways you can show the range in this case:\n\n1) 0316ce92851d::b385d13d5ed4 and f19b7f89f44e::4ccc844d5454\n2) 0316ce92851d::4ccc844d5454 and b385d13d5ed4\n\nLook into `hg help revsets` to understand what `::` means.","author":"pulkit","id":"57419","dateCreated":"1527196739","dateModified":"1527196739"},{"type":"comment","comment":"okay, but I have some queries like\n1. How about showing revision no. instead of cset id?\n2. And in this https:\/\/pastebin.com\/raw\/kWcr9xVK example if I change revision 2 phase to --secret then how it should print the range, I mean now we have branches in this range?\n\nCan we show that range like this:\n\n0316ce92851d : : b385d13d5ed4  draft  ->  secret\n0316ce92851d : : 4ccc844d5454   draft  -> secret","author":"khanchi97","id":"57349","dateCreated":"1527158527","dateModified":"1527158527"},{"type":"inline","comment":"This is not very much helpful. In such cases, how about showing the range of changesets, something like:\n```f7b1eb17ad24::925d80f479bb public -> draft\nb385d13d5ed4::fdc0253c25cf secret -> draft``` ","replyTo":null,"isNewFile":"1","line":"990","lineLength":"0","path":"tests\/test-phases.t","diffId":"7877","author":"pulkit","id":"57180","dateCreated":"1526844970","dateModified":"1526844970"},{"type":"inline","comment":"Since all the logic is copy-pasted from phases.advanceboundary and phases.retractboundary, why not we just pass the `--dry-run` option there and get the count from those functions only.","replyTo":null,"isNewFile":"1","line":"3898","lineLength":"0","path":"mercurial\/commands.py","diffId":"7877","author":"pulkit","id":"57179","dateCreated":"1526844970","dateModified":"1526844970"},{"type":"comment","comment":"@pulkit Can you please review it?","author":"khanchi97","id":"51519","dateCreated":"1523353338","dateModified":"1523353338"},{"type":"update","diffId":"7877","author":"khanchi97","id":"51174","dateCreated":"1523185235","dateModified":"1523185235"},{"type":"inline","comment":"`\"cannot use --dry-run without target phase\"`","replyTo":null,"isNewFile":"1","line":"3872","lineLength":"0","path":"mercurial\/commands.py","diffId":"7874","author":"av6","id":"51173","dateCreated":"1523167056","dateModified":"1523167056"},{"type":"update","diffId":"7874","author":"khanchi97","id":"51159","dateCreated":"1523101349","dateModified":"1523101349"},{"type":"update","diffId":"7873","author":"khanchi97","id":"51153","dateCreated":"1523100805","dateModified":"1523100805"}],"dateCreated":"1523100805","dateModified":"1528037274","status":"Needs Review"},{"id":"3445","callsign":"HG","title":"dispatch: validate return type from dispatch() return value","author":"indygreg","summary":"This commit adds type checking to the result of dispatch() so\nwe catch non-None and non-int values. This prevents crashes\nwhen we later try to \"& 255\" this value.\n\nThe Python 3 test failures introduced previously have all gone away.","testPlan":"","lineCount":"50","dependsOn":["3444"],"reviewers":["admin","durin42"],"ccs":["durin42","admin","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"(derp, that was me, but my password vault mis-fired and I got admin instead of me.)","author":"durin42","id":"57766","dateCreated":"1527793864","dateModified":"1527793864"},{"type":"reject","author":"durin42","id":"57765","dateCreated":"1527793864","dateModified":"1527793864"},{"type":"comment","comment":"This looks good, but needs rebased.","author":"admin","id":"57762","dateCreated":"1527793807","dateModified":"1527793807"},{"type":"reject","author":"admin","id":"57761","dateCreated":"1527793807","dateModified":"1527793807"},{"type":"update","diffId":"8654","author":"indygreg","id":"56035","dateCreated":"1526100492","dateModified":"1526100492"},{"type":"comment","comment":"IIRC, SystemExit is caught at callcatch and translated to a status code.\n\n> +    # The logic here attempts to mimic how CPython's pythonrun.c does things.\n> +    # Essentially:\n> +    #\n> +    # * Exit is controlled by returning a value or raising SystemExit.\n> +    # * An integer value exits with that exit code.\n> +    # * A value of ``None`` is interpreted as ``0``.\n> +    # * A non-integer, non-None value results in that value being printed\n> +    #   and an exit code of ``1``.\n> +    # * SystemExit can have a ``code`` attribute containing the exit value.\n>      try:\n> -        status = (dispatch(req) or 0)\n> +        code = dispatch(req) or 0\n>      except error.StdioError as e:\n>          err = e\n> -        status = -1\n> +        code = -1\n> +    except SystemExit as err:\n> +        try:\n> +            code = err.code\n> +            err = None\n> +        except AttributeError:","author":"yuja","id":"54925","dateCreated":"1525609762","dateModified":"1525609762"},{"type":"update","diffId":"8460","author":"indygreg","id":"54814","dateCreated":"1525579872","dateModified":"1525579872"}],"dateCreated":"1525579872","dateModified":"1527794332","status":"Needs Revision"},{"id":"3444","callsign":"HG","title":"tests: comprehensively test exit handling","author":"indygreg","summary":"Rust `hg` currently has some test failures around exit handling.\nThis commit establishes some centralized tests around exit handling so\nthat we can unify the behavior of our Rust frontend and `python`.\n\nThere are some added tests that use a value other than an integer\nor None for the exit code. The docs for sys.exit() say such a value\nis allowed. However, Mercurial currently crashes in this case. Upcoming\ncommits will teach Mercurial to handle these values.\n\nThis does introduce a few Python 3 test failures. However, this test\nalready has a few failures. And the failures being introduced should\nmostly go away with subsequent commits. So I think this is acceptable.","testPlan":"","lineCount":"91","dependsOn":[],"reviewers":["durin42"],"ccs":["durin42","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"This LG, esp with D3445 which appears to be its child, but D3445 still needs rebased AFAICT","author":"durin42","id":"57781","dateCreated":"1527794332","dateModified":"1527794332"},{"type":"accept","author":"durin42","id":"57779","dateCreated":"1527794332","dateModified":"1527794332"},{"type":"comment","comment":">   > I generally like the direction of this series, but I think there's no point\n>   >  to extend Mercurial's exit code handling to support all weird Python types.\n>   >\n>   > Only ints and (None for 0) are ever valid.\n>   \n>   \n>   The reason I did this is because from the context or `rhg`, we don't have CPython's default exit handling to fall back on. Our choices are:\n>   \n>   1. Reimplement CPython's exit\/error handling in Rust\n>   2. Reimplement CPython's exit\/error handling in Python in dispatch [so the end state is more well-defined]\n>   3. Do something crude in `rhg` when we hit special cases that CPython would normally deal with.\n>   \n>   Since extensions could do weird things, I figured 2 was the best option.\n\nI don't fully understand the situation in `rhg`, but maybe we can instead\nfix `scmutil.callcatch()` to either translate non-int SystemExit to integer\nor raise ProgrammingError as a bad use of sys.exit() in hg. No SystemExit\nshould be raised outside of the callcatch().\n\nI'm against allowing command functions to return any objects other than\nint or None because it's useless.","author":"yuja","id":"56045","dateCreated":"1526104337","dateModified":"1526104337"},{"type":"comment","comment":">>! In D3444#54922, @yuja wrote:\n> I generally like the direction of this series, but I think there's no point\n> to extend Mercurial's exit code handling to support all weird Python types.\n> \n> Only ints and (None for 0) are ever valid.\n\nThe reason I did this is because from the context or `rhg`, we don't have CPython's default exit handling to fall back on. Our choices are:\n\n1. Reimplement CPython's exit\/error handling in Rust\n2. Reimplement CPython's exit\/error handling in Python in dispatch [so the end state is more well-defined]\n3. Do something crude in `rhg` when we hit special cases that CPython would normally deal with.\n\nSince extensions could do weird things, I figured 2 was the best option.\n\nBut I'll take a look at this series again and re-evaluate if we can simplify things. I just thought I'd brain dump on what I'm thinking.","author":"indygreg","id":"56014","dateCreated":"1526097317","dateModified":"1526097317"},{"type":"comment","comment":"I generally like the direction of this series, but I think there's no point\nto extend Mercurial's exit code handling to support all weird Python types.\n\nOnly ints and (None for 0) are ever valid.","author":"yuja","id":"54923","dateCreated":"1525609756","dateModified":"1525609756"},{"type":"update","diffId":"8459","author":"indygreg","id":"54808","dateCreated":"1525579871","dateModified":"1525579871"}],"dateCreated":"1525579871","dateModified":"1527794332","status":"Accepted"},{"id":"3454","callsign":"HG","title":"Assign to result from block.","author":"kevincox","summary":"This is more idiomatic because you don't have uninitialized variables and has less typing.","testPlan":"","lineCount":"9","dependsOn":["3447"],"reviewers":["indygreg","durin42"],"ccs":["martinvonz","durin42","mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"57759","dateCreated":"1527793653","dateModified":"1527793653"},{"type":"comment","comment":"It looks like this is based on top of D3447. So I'll just hook up the dependency and we'll land it as soon as my series is landed.","author":"indygreg","id":"56011","dateCreated":"1526097062","dateModified":"1526097062"},{"type":"accept","author":"indygreg","id":"56009","dateCreated":"1526097062","dateModified":"1526097062"},{"type":"comment","comment":"This doesn't apply. Looks like it's based on a version where exit code is 1 (line 193), but our main.rs seems to have always have had it set to 255.","author":"martinvonz","id":"55724","dateCreated":"1525900608","dateModified":"1525900608"},{"type":"update","diffId":"8471","author":"kevincox","id":"54912","dateCreated":"1525594657","dateModified":"1525594657"}],"dateCreated":"1525594657","dateModified":"1527793653","status":"Accepted"},{"id":"3447","callsign":"HG","title":"rust: make exit handling consistent with `hg`","author":"indygreg","summary":"Now that dispatch.run() handles special exit cases and always returns\nan exit code, Rust's (formerly lacking) invocation of dispatch.run() can\nhandle the return value with minimal hassle.\n\nIn addition, we change Rust to exit 1 instead of 255 in the case\nof unhandled errors, as that is actually what Python does.\n\nThis fixes a few test failures when running the test suite with rhg.","testPlan":"","lineCount":"22","dependsOn":["3446"],"reviewers":["kevincox","durin42"],"ccs":["durin42","kevincox","mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"57757","dateCreated":"1527793647","dateModified":"1527793647"},{"type":"inline","comment":"s\/unreachable\/panic\/ since the code can never be hit as long as the python code returns the right type.\n\nAlso it might be a good idea to try to print out the value returned in the error message. Although if not easy it is probably not worth it.","replyTo":null,"isNewFile":"1","line":"204","lineLength":"0","path":"rust\/hgcli\/src\/main.rs","diffId":"8462","author":"kevincox","id":"54910","dateCreated":"1525593073","dateModified":"1525593073"},{"type":"accept","author":"kevincox","id":"54909","dateCreated":"1525593073","dateModified":"1525593073"},{"type":"update","diffId":"8462","author":"indygreg","id":"54834","dateCreated":"1525579874","dateModified":"1525579874"}],"dateCreated":"1525579874","dateModified":"1527793647","status":"Accepted"},{"id":"3446","callsign":"HG","title":"dispatch: move sys.exit() to caller (API)","author":"indygreg","summary":"Moving sys.exit() to the caller will make it easier to implement\nexit handling in Rust `hg` by eliminating the need to handle\nSystemExit in Rust.\n\n.. api::\n\n   dispatch.run() now returns an integer exit code instead of calling\n   sys.exit(). Callers of dispatch.run() must now exit.","testPlan":"","lineCount":"6","dependsOn":["3445"],"reviewers":["lothiraldan","durin42"],"ccs":["mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"57755","dateCreated":"1527793642","dateModified":"1527793642"},{"type":"update","diffId":"8655","author":"indygreg","id":"56038","dateCreated":"1526100493","dateModified":"1526100493"},{"type":"accept","author":"lothiraldan","id":"54928","dateCreated":"1525677084","dateModified":"1525677084"},{"type":"update","diffId":"8461","author":"indygreg","id":"54824","dateCreated":"1525579873","dateModified":"1525579873"}],"dateCreated":"1525579873","dateModified":"1527793642","status":"Accepted"},{"id":"3663","callsign":"HG","title":"graft: add test showing --continue not preserving --edit passed earlier","author":"pulkit","summary":"Right now, if you run `hg graft --edit`, face some conflicts, resolve them and\nthen run `hg graft --continue`, you will see graft no longer pops up for the\neditor and you hate mercurial for not remembering arguments you passed earlier.\n\nUpcoming patch will fix this buggy behavior and this test will help us in\nrealizing those changes.","testPlan":"","lineCount":"41","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"8908","author":"pulkit","id":"57562","dateCreated":"1527287120","dateModified":"1527287120"}],"dateCreated":"1527287120","dateModified":"1527287308","status":"Needs Review"},{"id":"2875","callsign":"HG","title":"remotenames: introduce a config option to allow creation of remote bookmarks","author":"pulkit","summary":"This patch introduces another config option which if set to true, we can create\nnew bookmarks on the server using push command. An earlier patch added\ncapability to push to a certain bookmark on the server. If bookmark was not\nalready present on the server, we errored out. With\nremotenames.createremotebookmark config set, the push will create that bookmark\non the server.\n\nThis series serves as a great feature for people who use bookmarks as after this\nyou can push changesets to a bookmark which does not exists locally. In other\nwords, you can push your changesets to a bookmark without having it locally.\n\nThis series will help people in having a non-local bookmark workflow involving\nremotenames.\n\nThe functionality added in this patch is equivalent to --create flag to push\ncommand added by hgremotenames extension.","testPlan":"","lineCount":"166","dependsOn":[],"reviewers":["indygreg"],"ccs":["mercurial-devel"],"actions":[{"type":"accept","author":"indygreg","id":"52032","dateCreated":"1523468132","dateModified":"1523468132"},{"type":"update","diffId":"7288","author":"pulkit","id":"47564","dateCreated":"1522064875","dateModified":"1522064875"},{"type":"update","diffId":"7251","author":"pulkit","id":"47276","dateCreated":"1521704137","dateModified":"1521704137"},{"type":"update","diffId":"7105","author":"pulkit","id":"46425","dateCreated":"1521448583","dateModified":"1521448583"},{"type":"update","diffId":"7063","author":"pulkit","id":"46164","dateCreated":"1521121786","dateModified":"1521121786"}],"dateCreated":"1521121786","dateModified":"1526652340","status":"Accepted"},{"id":"2873","callsign":"HG","title":"remotenames: add functionality to override -B flag of push","author":"pulkit","summary":"This patch adds a new config option which can be used to override the `-B` flag\nof push command. If config is set to true, changesets will be pushed to that\nbookmark on the server. This is equivalent to `--to` flag of remotenames and\ninfinitepush.\n\nAfter this patch if config is set to true, the behavior will be:\n\n  * Normal push without -B flag: no behavior change\n  * specifying one bookmark using -B flag: changesets will be pushed to that\n        bookmark on the server, as explained above. Bookmark pushed will be on\n        the head most revision of the changesets pushed.\n  * specifying multiple bookmarks using -B flag: no behavior change, the same\n        behavior as it's today without this config option\n  * specifying multiple topologcial heads to push: no behvaior change\n\nThere needs some extra logic to update the remotenames state locally after the\npush since we know that the bookmark will now be at a known updated location.","testPlan":"","lineCount":"356","dependsOn":[],"reviewers":["indygreg"],"ccs":["smf","indygreg","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D2873#52100, @indygreg wrote:\n>>>! In D2873#52025, @smf wrote:\n>>>>! In D2873#52021, @indygreg wrote:\n>>> Looks good!\n>> \n>> I'm very heavily against this direction. Changing the behavior of push (even in this extension) is something I've always considered outside the scope of remotenames. Having another extension that changes push behavior (e.g. bookmark-push) is where I think this should go so that remotenames is just that: keeping track of remote names.\n> \n> I think there's room for this feature to live outside of remotenames. But currently I think it is the best place for it, since remotenames is the closest thing we have to... tracking remote names. We can always alias the old config option in the future if we move this functionality elsewhere.\n\nOne of the biggest regrets I have about the original remotenames, is the modifying of push (and some default) behavior. The `--to` is small enough (and I guess fine enough) for now but I absolutely and strongly believe that all the other behavior modifications should stay in an out-of-core repo for now. My goal is to split my remotenames repo to be based off of core's remotenames (basically only having the behavior changing patches there).","author":"smf","id":"52118","dateCreated":"1523482769","dateModified":"1523482769"},{"type":"comment","comment":">>! In D2873#52025, @smf wrote:\n>>>! In D2873#52021, @indygreg wrote:\n>> Looks good!\n> \n> I'm very heavily against this direction. Changing the behavior of push (even in this extension) is something I've always considered outside the scope of remotenames. Having another extension that changes push behavior (e.g. bookmark-push) is where I think this should go so that remotenames is just that: keeping track of remote names.\n\nI think there's room for this feature to live outside of remotenames. But currently I think it is the best place for it, since remotenames is the closest thing we have to... tracking remote names. We can always alias the old config option in the future if we move this functionality elsewhere.","author":"indygreg","id":"52100","dateCreated":"1523480112","dateModified":"1523480112"},{"type":"comment","comment":">>! In D2873#52021, @indygreg wrote:\n> Looks good!\n\nI'm very heavily against this direction. Changing the behavior of push (even in this extension) is something I've always considered outside the scope of remotenames. Having another extension that changes push behavior (e.g. bookmark-push) is where I think this should go so that remotenames is just that: keeping track of remote names.","author":"smf","id":"52026","dateCreated":"1523467971","dateModified":"1523467971"},{"type":"inline","comment":"Nit: \"exist\". This can be fixed in flight.","replyTo":null,"isNewFile":"1","line":"113","lineLength":"0","path":"hgext\/remotenames.py","diffId":"7286","author":"indygreg","id":"52023","dateCreated":"1523467769","dateModified":"1523467769"},{"type":"comment","comment":"Looks good!","author":"indygreg","id":"52022","dateCreated":"1523467769","dateModified":"1523467769"},{"type":"accept","author":"indygreg","id":"52021","dateCreated":"1523467769","dateModified":"1523467769"},{"type":"comment","comment":"A gentle reminder for reviewing this series. If this config option gets in, we can use it in infinitepush extension too where for now we have overridden `-B` flag in a hacky way.","author":"pulkit","id":"48737","dateCreated":"1522601487","dateModified":"1522601487"},{"type":"update","diffId":"7286","author":"pulkit","id":"47560","dateCreated":"1522064849","dateModified":"1522064849"},{"type":"inline","comment":"What happens if we're pushing multiple heads? I suspect this will choose a head\/revision arbitrarily - maybe depending on the `-r` arguments to `hg push`.\n\nI think we need to validate that the outgoing revs are in a single DAG head and we should then pick the rev that is the DAG head.\n\nPlease add test coverage for multiple `-r` arguments and `-r` arguments that resolve to multiple heads.","replyTo":null,"isNewFile":"1","line":"99","lineLength":"0","path":"hgext\/remotenames.py","diffId":"7249","author":"indygreg","id":"47382","dateCreated":"1521831360","dateModified":"1521831360"},{"type":"inline","comment":"Nit: what is `--create`?","replyTo":null,"isNewFile":"1","line":"101","lineLength":"0","path":"hgext\/remotenames.py","diffId":"7249","author":"indygreg","id":"47381","dateCreated":"1521831360","dateModified":"1521831360"},{"type":"inline","comment":"Strictly speaking, we should probably wrap `exchange._pushdiscoverybookmarks` so other extensions can get involved. But I think this is fine.","replyTo":null,"isNewFile":"1","line":"287","lineLength":"0","path":"hgext\/remotenames.py","diffId":"7249","author":"indygreg","id":"47380","dateCreated":"1521831360","dateModified":"1521831360"},{"type":"comment","comment":"I'm happy with this feature.\n\nBut the code needs work around multiple revisions\/heads before it can be queued.","author":"indygreg","id":"47379","dateCreated":"1521831360","dateModified":"1521831360"},{"type":"reject","author":"indygreg","id":"47378","dateCreated":"1521831360","dateModified":"1521831360"},{"type":"update","diffId":"7249","author":"pulkit","id":"47274","dateCreated":"1521704112","dateModified":"1521704112"},{"type":"update","diffId":"7103","author":"pulkit","id":"46423","dateCreated":"1521448561","dateModified":"1521448561"},{"type":"comment","comment":"I am not sure the functionality and config names should go to core or not, so I have introduced them in this extension. Also suggestions for better config names are welcome.","author":"pulkit","id":"46265","dateCreated":"1521212432","dateModified":"1521212432"},{"type":"update","diffId":"7061","author":"pulkit","id":"46148","dateCreated":"1521121763","dateModified":"1521121763"}],"dateCreated":"1521121763","dateModified":"1526652340","status":"Accepted"},{"id":"3565","callsign":"FBHGX","title":"sparse: delete now that it's in the core repo","author":"martinvonz","summary":"It was moved added to core repo in abd7dedbaa36 (sparse: vendor\nFacebook-developed extension, 2017-07-01).","testPlan":"","lineCount":"2706","dependsOn":[],"reviewers":["quark"],"ccs":["quark"],"actions":[{"type":"reject","author":"quark","id":"56456","dateCreated":"1526597213","dateModified":"1526597213"},{"type":"comment","comment":"I think there are still some differences. Namely the integration with `simplecache`, which is helpful for performance. Does the core version have something similar?","author":"quark","id":"56344","dateCreated":"1526429367","dateModified":"1526429592"},{"type":"update","diffId":"8703","author":"martinvonz","id":"56328","dateCreated":"1526428875","dateModified":"1526428875"}],"dateCreated":"1526428875","dateModified":"1526597213","status":"Needs Revision"},{"id":"3304","callsign":"HG","title":"formatter: add support for -Tcbor","author":"indygreg","summary":"The implementation in the formatter is hopefully pretty\nstraightforward.\n\nUnlike other formats, we don't emit a list\/array or need to\nhandle \"joining\" elements between emitted items. That's because\nCBOR doesn't require any joining element: you just read the\nnext byte to see what type it is then decode it. You do that for\nas long as there are bytes to read.\n\nAs long as we aren't nesting formatters, the choice to omit\nan outer container for data seems acceptable. If nothing else,\nit will make it easier for decoders who don't support streaming\nto decode data without buffering the entire array first.\n\nI'm a bit unsure about add --cbor support to the f tool by importing\nMercurial modules. It does work in the test environment. But there's\nno demand module importer, etc. Unlike the existing JSON and pickle\nformatters, there isn't an implementation in the standard library\nfor us to use. So unless we want to forgo parsing the CBOR (this\ndoesn't seem great because the data isn't human readable), we'll\nneed to import at least the CBOR package from mercurial.*.\n\nThis commit also doesn't implement