{"state":{"revisions":[{"id":"5633","callsign":"HG","title":"grep: use set instead of dict with dummy value","author":"martinvonz","summary":"","testPlan":"","lineCount":"10","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"13326","author":"martinvonz","id":"83098","dateCreated":"1547839140","dateModified":"1547839140"}],"dateCreated":"1547839140","dateModified":"1547839140","status":"Needs Review"},{"id":"5620","callsign":"HG","title":"grep: don't look up copy info unless --follow is given","author":"martinvonz","summary":"If no --follow was given, then the \"copy\" variable will become\nNone. In that case we would still look up the copy information from\nthe filelog and then ignore it. Let's avoid even looking it up.","testPlan":"","lineCount":"21","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"13325","author":"martinvonz","id":"83096","dateCreated":"1547838658","dateModified":"1547838658"},{"type":"update","diffId":"13317","author":"martinvonz","id":"83057","dateCreated":"1547743711","dateModified":"1547743711"},{"type":"update","diffId":"13303","author":"martinvonz","id":"82957","dateCreated":"1547688193","dateModified":"1547688193"}],"dateCreated":"1547688193","dateModified":"1547839135","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":"update","diffId":"13324","author":"martinvonz","id":"83090","dateCreated":"1547835635","dateModified":"1547835635"}],"dateCreated":"1547835635","dateModified":"1547835666","status":"Needs Review"},{"id":"5594","callsign":"HG","title":"copies: consider nullrev a common ancestor","author":"martinvonz","summary":"I've seen many bugs in the git codebase that were caused by it not\nhaving a null revision and being forced to treat root commits\ndifferently. Mercurial has a null revision and I think it's generally\na bug to treat it differently from other commits in graph algorithms.\n\nThis effectively undoes 83cfa1baf8ad (copies: don't report copies with\nunrelated branch, 2010-01-01). The test cases that that commit added\nstill passes. I suspect some other fix after that commit made it\nunnecessary.","testPlan":"","lineCount":"13","dependsOn":[],"reviewers":[],"ccs":["lothiraldan","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":">   There are definitely repositories in the wild where p1 is nullrev (and p2 is not). It's unusual but expressable so, of course, it happened.\n>   \n>   For that matters, there is also case with nullrev != p1 && p1 == p2.\n\nWell, I think it should be considered a sort of corruption. context.py for\nexample would go wrong.\n\nMaybe we can add some check to \"hg verify\".","author":"yuja","id":"83088","dateCreated":"1547820109","dateModified":"1547820109"},{"type":"comment","comment":">>! In D5594#83078, @yuja wrote:\n>>   I've seen many bugs in the git codebase that were caused by it not\n>>   having a null revision and being forced to treat root commits\n>>   differently. Mercurial has a null revision and I think it's generally\n>>   a bug to treat it differently from other commits in graph algorithms.\n> \n> I agree with that, but I don't think every non-merge revision (p2 = null)\n> should be considered a direct child of null revision.\n> \n>> @@ -65,8 +63,6 @@\n>>          else:\n>>              parents = cl.parentrevs(r)\n> \n> Here `parents[1]` may be `nullrev`. Is that expected?\n> \n>>          for p in parents:\n>> -            if p < 0:\n>> -                continue\n\n\nThere are definitely repositories in the wild where p1 is nullrev (and p2 is not). It's unusual but expressable so, of course, it happened.\n\nFor that matters, there is also case with nullrev != p1 && p1 == p2.\n","author":"lothiraldan","id":"83087","dateCreated":"1547817945","dateModified":"1547817945"},{"type":"comment","comment":">   I've seen many bugs in the git codebase that were caused by it not\n>   having a null revision and being forced to treat root commits\n>   differently. Mercurial has a null revision and I think it's generally\n>   a bug to treat it differently from other commits in graph algorithms.\n\nI agree with that, but I don't think every non-merge revision (p2 = null)\nshould be considered a direct child of null revision.\n\n> @@ -65,8 +63,6 @@\n>          else:\n>              parents = cl.parentrevs(r)\n\nHere `parents[1]` may be `nullrev`. Is that expected?\n\n>          for p in parents:\n> -            if p < 0:\n> -                continue","author":"yuja","id":"83079","dateCreated":"1547813677","dateModified":"1547813677"},{"type":"update","diffId":"13232","author":"martinvonz","id":"82578","dateCreated":"1547598444","dateModified":"1547598444"}],"dateCreated":"1547598444","dateModified":"1547820109","status":"Needs Review"},{"id":"5631","callsign":"HG","title":"hghave: let OSError with ENOENT through like any other","author":"martinvonz","summary":"Before this patch, if we get an OSError with ENOENT, we would not\nre-raise it and would instead run into an undefined variable (\"p\")\nsoon thereafter.","testPlan":"","lineCount":"9","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"13321","author":"martinvonz","id":"83073","dateCreated":"1547795286","dateModified":"1547795286"}],"dateCreated":"1547795286","dateModified":"1547795286","status":"Needs Review"},{"id":"5629","callsign":"HG","title":"cleanup: delete lots of unused local variables","author":"martinvonz","summary":"These were found by IntelliJ. There are many more, but these seemed\npretty safe.","testPlan":"","lineCount":"124","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"13320","author":"martinvonz","id":"83071","dateCreated":"1547795128","dateModified":"1547795128"},{"type":"update","diffId":"13318","author":"martinvonz","id":"83059","dateCreated":"1547749443","dateModified":"1547749443"}],"dateCreated":"1547749443","dateModified":"1547795129","status":"Needs Review"},{"id":"5622","callsign":"HG","title":"localrepo: use context manager for transaction in commit()","author":"martinvonz","summary":"A side-effect is that the transaction is released a little earlier, so\nthe \"commit message saved in ...\" messages now comes after the\n\"rollback completed\" message. That seems slightly better to me.","testPlan":"","lineCount":"27","dependsOn":["5621"],"reviewers":["durin42","lothiraldan"],"ccs":["lothiraldan","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D5622#83013, @martinvonz wrote:\n>>>! In D5622#83011, @lothiraldan wrote:\n>> I have the impression that the test changes are due to the previous patch in the stack. \n> \n> I don't think so. See commit message for why I think they changed.\n\nRight, I was confused between the time the transaction was closed and the time the transaction was released. ","author":"lothiraldan","id":"83070","dateCreated":"1547794759","dateModified":"1547794759"},{"type":"accept","author":"lothiraldan","id":"83069","dateCreated":"1547794759","dateModified":"1547794759"},{"type":"comment","comment":">>! In D5622#83011, @lothiraldan wrote:\n> I have the impression that the test changes are due to the previous patch in the stack. \n\nI don't think so. See commit message for why I think they changed.","author":"martinvonz","id":"83013","dateCreated":"1547714703","dateModified":"1547714703"},{"type":"comment","comment":"I have the impression that the test changes are due to the previous patch in the stack. ","author":"lothiraldan","id":"83012","dateCreated":"1547714475","dateModified":"1547714475"},{"type":"update","diffId":"13305","author":"martinvonz","id":"82970","dateCreated":"1547702886","dateModified":"1547702886"}],"dateCreated":"1547702886","dateModified":"1547794759","status":"Needs Review"},{"id":"5630","callsign":"HG","title":"remotefilelog: remove pointless return statement from constructor","author":"martinvonz","summary":"","testPlan":"","lineCount":"4","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"13319","author":"martinvonz","id":"83065","dateCreated":"1547792350","dateModified":"1547792350"}],"dateCreated":"1547792350","dateModified":"1547792350","status":"Needs Review"},{"id":"5624","callsign":"HG","title":"localrepo: use context manager for lock and transaction in commitctx()","author":"martinvonz","summary":" ","testPlan":"","lineCount":"10","dependsOn":["5623"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"13307","author":"martinvonz","id":"82990","dateCreated":"1547702890","dateModified":"1547702890"}],"dateCreated":"1547702890","dateModified":"1547743661","status":"Needs Review"},{"id":"5623","callsign":"HG","title":"localrepo: use context manager for locks in commit()","author":"martinvonz","summary":" ","testPlan":"","lineCount":"10","dependsOn":["5622"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"13306","author":"martinvonz","id":"82981","dateCreated":"1547702888","dateModified":"1547702888"}],"dateCreated":"1547702888","dateModified":"1547743660","status":"Needs Review"},{"id":"5621","callsign":"HG","title":"commit: print \"commit message saved in\" message also if bookmark update fails","author":"martinvonz","summary":"The bookmark update is done within the same transaction, so if fails,\nthe commit will also be rolled back.\n\nI just happened to notice this while messing with this code; we have\nnot had reports of crashing bookmark updates from our users.\n\nThe same applies to the clearing of the merge state, although I don't\nthink that's currently tied into the transaction.","testPlan":"","lineCount":"10","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"13304","author":"martinvonz","id":"82964","dateCreated":"1547702885","dateModified":"1547702885"}],"dateCreated":"1547702885","dateModified":"1547743658","status":"Needs Review"},{"id":"5590","callsign":"HG","title":"watchman: ignore some of watchman errors","author":"lothiraldan","summary":"Don't display 'illegal_fstypes' errors. In environments with network\nfilesystems, the error messages are quickly pilling up and polluting outputs.","testPlan":"","lineCount":"3","dependsOn":["5589"],"reviewers":["indygreg"],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D5590#82940, @indygreg wrote:\n> I don't suppose there's a way to easily test this? I'm guessing not...\n> \n> The change seems reasonable though.\n\nUnfortunately, I don't see an easy way to test it\n\nThank you for your thorough review of the series, I will wait after the RC to send a new version as it's a non-urgent series","author":"lothiraldan","id":"83056","dateCreated":"1547743655","dateModified":"1547743655"},{"type":"comment","comment":"I don't suppose there's a way to easily test this? I'm guessing not...\n\nThe change seems reasonable though.","author":"indygreg","id":"82941","dateCreated":"1547674431","dateModified":"1547674431"},{"type":"accept","author":"indygreg","id":"82940","dateCreated":"1547674431","dateModified":"1547674431"},{"type":"comment","comment":"This series is non-urgent and it's fine if not included in the RC. I would like to gather feedback from fsmonitor experts on it but phabricator doesn't allow to set a `RFC` flag","author":"lothiraldan","id":"82546","dateCreated":"1547574704","dateModified":"1547574704"},{"type":"update","diffId":"13226","author":"lothiraldan","id":"82537","dateCreated":"1547571443","dateModified":"1547571443"}],"dateCreated":"1547571443","dateModified":"1547743655","status":"Accepted"},{"id":"5589","callsign":"HG","title":"watchman: add the possibility to set the exact watchman binary location","author":"lothiraldan","summary":"This is necessary to make rolling releases of new watchman versions across\nusers.","testPlan":"","lineCount":"27","dependsOn":["5588"],"reviewers":[],"ccs":["indygreg","mjpieters","mercurial-devel"],"actions":[{"type":"inline","comment":"I see several ways to refactor the code around:\n- Pass the watchman_exe parameter to all Transport class even if they don't need it. The `CLIProcessTransport` is already ignoring the timeout attribute.\n- Pass a `functools.partial` of `CLIProcessTransport.__init__`.\n- Pass the client instance to the transport, which will likely results in a memory leak due to the circular reference.\n- Store an instance as `client.transport` but that would requires to move passing the sockpath and update the transport to manage a `ready` state, which would be false until they get all the needed parameters.\n\nI have a small preference for solution 1). Solution 4) seems the most heavyweight","replyTo":"82938","isNewFile":"1","line":"567","lineLength":"4","path":"hgext\/fsmonitor\/pywatchman\/__init__.py","diffId":"13225","author":"lothiraldan","id":"83055","dateCreated":"1547743590","dateModified":"1547743590"},{"type":"inline","comment":"Why the nested `__init__`?\n\nPerhaps this initialization code could be cleaned up so we are assigning an instance instead of a class to `self.transport`?","replyTo":null,"isNewFile":"1","line":"567","lineLength":"4","path":"hgext\/fsmonitor\/pywatchman\/__init__.py","diffId":"13225","author":"indygreg","id":"82938","dateCreated":"1547674347","dateModified":"1547674347"},{"type":"comment","comment":"Overall I like the feature. But the class initialization logic is wonky. That's not your fault: you happen to be wading into a mess. Since it looks like there will be a v2 on this series, I'd encourage you to add some inline comments about the `__init__` mess at the least, or ideally refactor it so the code is cleaner.","author":"indygreg","id":"82937","dateCreated":"1547674347","dateModified":"1547674347"},{"type":"update","diffId":"13225","author":"lothiraldan","id":"82527","dateCreated":"1547571438","dateModified":"1547571438"}],"dateCreated":"1547571438","dateModified":"1547743590","status":"Needs Review"},{"id":"5588","callsign":"HG","title":"watchman: disable fsmonitor when running non-interactively","author":"lothiraldan","summary":"One of the risks with activating fsmonitor globally is resource exhaustion\n(like inotify watches on Linux).\n\nWhen launching background-jobs, it's often better to not activate fsmonitor in\norder to conserve resources for future interactive commands launched by users.\n\nThis can be overridden with the environment variable HGWATCHMAN_ENABLE","testPlan":"","lineCount":"12","dependsOn":["5587"],"reviewers":["indygreg"],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D5588#82922, @indygreg wrote:\n> Why wouldn't we want automated, non-interactive tools to have the benefits of watchman? There are plenty of use cases where complex Mercurial operations are scripted and would benefit from watchman.\n> \n> Your commit message details an issue that I assume you encountered in the wild. Are there other ways we can work around this? Perhaps we can set the idle timeout\/shutdown interval of watchman to be much smaller when Mercurial is non-interactive?\n\nYes what we saw in the wild is background jobs taking all the resources making interactive commands slower for users.\n\nI'm not sure what are the others workaround for this, I don't know if tuning the timeout \/ shutdown might be useful.\n\nThere is also the possibility to put it behind a config knob.","author":"lothiraldan","id":"83054","dateCreated":"1547742959","dateModified":"1547742959"},{"type":"comment","comment":"Why wouldn't we want automated, non-interactive tools to have the benefits of watchman? There are plenty of use cases where complex Mercurial operations are scripted and would benefit from watchman.\n\nYour commit message details an issue that I assume you encountered in the wild. Are there other ways we can work around this? Perhaps we can set the idle timeout\/shutdown interval of watchman to be much smaller when Mercurial is non-interactive?","author":"indygreg","id":"82923","dateCreated":"1547668245","dateModified":"1547668245"},{"type":"reject","author":"indygreg","id":"82922","dateCreated":"1547668245","dateModified":"1547668245"},{"type":"update","diffId":"13224","author":"lothiraldan","id":"82517","dateCreated":"1547571432","dateModified":"1547571432"}],"dateCreated":"1547571432","dateModified":"1547742959","status":"Needs Revision"},{"id":"5586","callsign":"HG","title":"watchman: add verbose config knob","author":"lothiraldan","summary":"This new config knob allows to silent watchman log and warning messages when\nwatchman is unavailable.","testPlan":"","lineCount":"10","dependsOn":[],"reviewers":[],"ccs":["pulkit","indygreg","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D5586#83031, @pulkit wrote:\n>>>! In D5586#82915, @indygreg wrote:\n>> This new config knob defaults to off and we're therefore changing the behavior to not warn when watchman is unavailable. This is a bit concerning to me because someone could have fsmonitor enabled and I don't think they'd ever get an error if watchman isn't working correctly.\n>> \n>> I support introducing the config knob. But I don't like silently suppressing watchman errors that could lead to false user expectations.\n> \n> I on +1 with what @indygreg said. These warning messages have proved much helpful for us internally.\n\nI will update this patch to activate it by default.","author":"lothiraldan","id":"83053","dateCreated":"1547742544","dateModified":"1547742544"},{"type":"comment","comment":">>! In D5586#82915, @indygreg wrote:\n> This new config knob defaults to off and we're therefore changing the behavior to not warn when watchman is unavailable. This is a bit concerning to me because someone could have fsmonitor enabled and I don't think they'd ever get an error if watchman isn't working correctly.\n> \n> I support introducing the config knob. But I don't like silently suppressing watchman errors that could lead to false user expectations.\n\nI on +1 with what @indygreg said. These warning messages have proved much helpful for us internally.","author":"pulkit","id":"83032","dateCreated":"1547720236","dateModified":"1547720236"},{"type":"comment","comment":"This new config knob defaults to off and we're therefore changing the behavior to not warn when watchman is unavailable. This is a bit concerning to me because someone could have fsmonitor enabled and I don't think they'd ever get an error if watchman isn't working correctly.\n\nI support introducing the config knob. But I don't like silently suppressing watchman errors that could lead to false user expectations.\n\nIs my understanding here correct?\n\n(I would accept a patch that defaults the config option to on. I will continue reviewing this series.)","author":"indygreg","id":"82916","dateCreated":"1547667640","dateModified":"1547667640"},{"type":"update","diffId":"13222","author":"lothiraldan","id":"82501","dateCreated":"1547571421","dateModified":"1547571421"}],"dateCreated":"1547571421","dateModified":"1547742544","status":"Needs Review"},{"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":["yuja","mercurial-devel"],"actions":[{"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":"1547734900","status":"Needs Review"},{"id":"5628","callsign":"HG","title":"diffstat: make --git work properly on renames (issue6025)","author":"navaneeth.suresh","summary":"`$ hg diff --stat --git` shows only the new filename on renames.\nI added the old filename also to the output to make it identical\nwith the output of `$ git diff --stat`.","testPlan":"","lineCount":"23","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"13314","author":"navaneeth.suresh","id":"83040","dateCreated":"1547729182","dateModified":"1547729182"}],"dateCreated":"1547729182","dateModified":"1547729182","status":"Needs Review"},{"id":"5587","callsign":"HG","title":"watchman: detect nested mercurial repositories and abort","author":"lothiraldan","summary":"Disable fsmonitor on nested mercurial repositories. Only depth one\nrepositories are detected at the moment.","testPlan":"","lineCount":"13","dependsOn":["5586"],"reviewers":["indygreg"],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"inline","comment":"Nit: we should be using `repo.vfs.listdir()` here, as all I\/O should be abstracted via VFS layer. But I think this is fine (we make this violation in many other places).","replyTo":null,"isNewFile":"1","line":"766","lineLength":"2","path":"hgext\/fsmonitor\/__init__.py","diffId":"13223","author":"indygreg","id":"82919","dateCreated":"1547667874","dateModified":"1547667874"},{"type":"accept","author":"indygreg","id":"82918","dateCreated":"1547667874","dateModified":"1547667874"},{"type":"update","diffId":"13223","author":"lothiraldan","id":"82507","dateCreated":"1547571427","dateModified":"1547571427"}],"dateCreated":"1547571427","dateModified":"1547667874","status":"Accepted"},{"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":"5596","callsign":"HG","title":"copies: get working copy parents from wctx, not dirstate, to make in-mem work","author":"martinvonz","summary":"Before this patch, `run-tests.py test-rebase-conflicts.t\n--extra-config-opt rebase.experimental.inmemory=1` would have some\nlines that say \"searching for copies back to rev 3\" changed to\n\"... rev 1\". I don't know of a better way of testing this patch than\ndoing that manually. There are many other differences, so we're not\nready to use #testcases syntax on the entire test-rebase-conflicts.t\nyet.","testPlan":"","lineCount":"6","dependsOn":["5595"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"13234","author":"martinvonz","id":"82598","dateCreated":"1547618774","dateModified":"1547618774"}],"dateCreated":"1547618774","dateModified":"1547618774","status":"Needs Review"},{"id":"5595","callsign":"HG","title":"copies: pass contexts into _findlimit()","author":"martinvonz","summary":"Just a little refactoring to make the next patch simpler.","testPlan":"","lineCount":"8","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"13233","author":"martinvonz","id":"82592","dateCreated":"1547618772","dateModified":"1547618772"}],"dateCreated":"1547618772","dateModified":"1547618774","status":"Needs Review"},{"id":"5490","callsign":"HG","title":"commit: remove ignore whitespace option on --interactive (issue6042)","author":"navaneeth.suresh","summary":"`hg commit --interactive` don't see changes to whitespace on having `ignorews=True` under `[diff]` in `.hgrc`. This is derived from record extension according to `486a1fe09422`. I removed `whitespace=True` from `patch.difffeatureopts()` in `cmdutils.dorecord.recordfunc()` and got this to work without failing any tests. I'll be sending follow up patches to this if this fails to work on any other cases which don't have tests written. Perhaps calling `cmdutils.dorecord` with additional arguments only for record extension et al be a nice fix then.","testPlan":"","lineCount":"46","dependsOn":[],"reviewers":[],"ccs":["yuja","durin42","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":">   > `_performrevert()` would be in the same boat, but it was explicitly flagged on\n>   >  at https:\/\/phab.mercurial-scm.org\/rHGf37a69ec3f4717fdb4f00699ca06c225f106696c. This implies that the `diff.ignorews` option would be used\n>   >  in practice to exclude whitespace changes while interactive commit\/revert.\n>   >  So disabling any whitespace options would break someone's workflow.\n>   \n>   I'm confused after this comment. How do you want me to move forward?\n\nYeah, I'm also confused about the current state. Honestly, I'm out of ideas.\nWe could add diff options to commit and revert, but I'm not sure if they\nare widely used enough to being options of these commands.","author":"yuja","id":"82399","dateCreated":"1547438293","dateModified":"1547438293"},{"type":"comment","comment":"> `_performrevert()` would be in the same boat, but it was explicitly flagged on\n> at f37a69ec3f47. This implies that the `diff.ignorews` option would be used\n> in practice to exclude whitespace changes while interactive commit\/revert.\n> So disabling any whitespace options would break someone's workflow.\n\nI'm confused after this comment. How do you want me to move forward?","author":"navaneeth.suresh","id":"82384","dateCreated":"1547389917","dateModified":"1547389917"},{"type":"comment","comment":">   > It was intentionally added by https:\/\/phab.mercurial-scm.org\/rHG3f1dccea9510c122cf9ab0e7a5a19ceed3600a7f (with no tests.)\n>   \n>   Do you want me to add tests for that?  If yes, please mention the things I need to take care of on\n>    writing those tests.\n\nI think you can reuse the test you've written for `commit -i`.\n\n>   I've updated the revision and things are working fine. There is still `whitespace=True` existing\n>   on calling `patch.difffeatureopts()` in `fastannotate`, `diffutil.diffallopts()`,\n>   `webutil.difffeatureopts()` and ``cmdutil._performrevert()`. Is there anything\n>   to be done on that?\n\nGood questionn. Maybe we can't simply fix the issue6042 by turning off the\nwhitespace options?\n\n`_performrevert()` would be in the same boat, but it was explicitly flagged on\nat f37a69ec3f47. This implies that the `diff.ignorews` option would be used\nin practice to exclude whitespace changes while interactive commit\/revert.\nSo disabling any whitespace options would break someone's workflow.","author":"yuja","id":"82340","dateCreated":"1547345420","dateModified":"1547345420"},{"type":"comment","comment":"> --- a\/mercurial\/cmdutil.py\n> +++ b\/mercurial\/cmdutil.py\n> @@ -237,6 +237,7 @@\n>  def dorecord(ui, repo, commitfunc, cmdsuggest, backupall,\n>              filterfn, *pats, **opts):\n>      opts = pycompat.byteskwargs(opts)\n> +    ignorews = opts.get('ignorews', False)\n\nIt isn't nice to mix command options and internal flags. Instead, maybe we can\nfirst change `record()` to not call `commands.commit()`, and pass in `whitespace`\noption to `cmdutil.dorecord()`.\n\n```\ndef record(ui, repo, *pats, **opts):\n    opts = pycompat.byteskwargs(opts)\n    ...\n    with repo.wlock(), repo.lock():\n        ret = cmdutil.dorecord(ui, repo, commands.commit, ..., whitespace=True,\n                               pats, opts)\n        ...\n```\n\nAnd I don't think `ignorews` is good name. It doesn't mean whitespace is\nignored.\n\n>  def qrefresh(origfn, ui, repo, *pats, **opts):\n>      if not opts[r'interactive']:\n> @@ -89,7 +89,7 @@\n>  \n>      # backup all changed files\n>      cmdutil.dorecord(ui, repo, committomq, None, True,\n> -                    cmdutil.recordfilter, *pats, **opts)\n> +                    cmdutil.recordfilter, *pats, ignorews=True, **opts)\n\nPerhaps, this one should be `ignorefs=False` since qrefresh has no diffwsopts.","author":"yuja","id":"82331","dateCreated":"1547344556","dateModified":"1547344556"},{"type":"comment","comment":"> Sorry for late, but doesn't it break `hg record --ignore-all-space`, etc.?\n\nYes. Exactly! Thanks for pointing that out.\n\n> It was intentionally added by 3f1dccea9510 (with no tests.)\n\nDo you want me to add tests for that?  If yes, please mention the things I need to take care of on\n writing those tests.\n\nI've updated the revision and things are working fine. There is still `whitespace=True` existing\non calling `patch.difffeatureopts()` in `fastannotate`, `diffutil.diffallopts()`,\n`webutil.difffeatureopts()` and ``cmdutil._performrevert()`. Is there anything\nto be done on that?\n","author":"navaneeth.suresh","id":"82266","dateCreated":"1547219617","dateModified":"1547219617"},{"type":"update","diffId":"13177","author":"navaneeth.suresh","id":"82265","dateCreated":"1547219495","dateModified":"1547219495"},{"type":"comment","comment":"> -        diffopts = patch.difffeatureopts(ui, opts=opts, whitespace=True)\n> +        diffopts = patch.difffeatureopts(ui, opts=opts)\n\nSorry for late, but doesn't it break `hg record --ignore-all-space`, etc.?\nIt was intentionally added by 3f1dccea9510 (with no tests.)","author":"yuja","id":"82228","dateCreated":"1547211091","dateModified":"1547211091"},{"type":"comment","comment":"@durin42 I've added test for the current revision. Unfortunately, I'm unable to write a test for the wrong behaviour.  I'll try writing it again. Any hints from your side?","author":"navaneeth.suresh","id":"82223","dateCreated":"1547180944","dateModified":"1547180944"},{"type":"update","diffId":"13166","author":"navaneeth.suresh","id":"82222","dateCreated":"1547180751","dateModified":"1547180751"},{"type":"comment","comment":"> Could you add a test?\n> \n> (Bonus points if you add a test that shows the wrong behavior and then fix it in this change.)\n\nSure. Will do.","author":"navaneeth.suresh","id":"82035","dateCreated":"1547126037","dateModified":"1547126037"},{"type":"comment","comment":"Could you add a test?\n\n(Bonus points if you add a test that shows the wrong behavior and then fix it in this change.)","author":"durin42","id":"81843","dateCreated":"1547063248","dateModified":"1547063248"},{"type":"comment","comment":">>! In D5490#81294, @pulkit wrote:\n> I am not sure whether this change is correct or not, but please add more description to your commit message explaining what this patch is doing, what the issue is about and how it fixes that.\n\nDone @pulkit ","author":"navaneeth.suresh","id":"81320","dateCreated":"1546681536","dateModified":"1546681536"},{"type":"comment","comment":"I am not sure whether this change is correct or not, but please add more description to your commit message explaining what this patch is doing, what the issue is about and how it fixes that.","author":"pulkit","id":"81295","dateCreated":"1546622916","dateModified":"1546622916"},{"type":"update","diffId":"13003","author":"navaneeth.suresh","id":"81272","dateCreated":"1546597394","dateModified":"1546597394"}],"dateCreated":"1546597394","dateModified":"1547438293","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":"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":"53","dependsOn":[],"reviewers":["durin42"],"ccs":["pulkit","durin42","mercurial-devel"],"actions":[{"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":"1547133473","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":"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":"1547065835","status":"Needs Review"},{"id":"5516","callsign":"HG","title":"fix: add some arguments to facilitate extensions","author":"hooper","summary":"For example, these additions allow wrapping `hg fix` to do things like:\n- Telling fixer tools what commit a file belongs to\n- Cleaning up temporary files created by Fixer objects\n\nThere are no intended functional changes.","testPlan":"","lineCount":"17","dependsOn":[],"reviewers":[],"ccs":["durin42","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D5516#81841, @durin42 wrote:\n>>>! In D5516#81683, @hooper wrote:\n>>>>! In D5516#81679, @durin42 wrote:\n>>> I'm -0 on this: what's special about this functionality that it needs to be an extension of an extension instead of something that can be done in core?\n>> \n>> Google's internal use of this extension makes some customizations that I doubt would be appealing in core. This patch makes some of it simpler to implement. Making all of it possible through configs\/templates might be unduly complex.\n> \n> What kinds of customizations?\n> \n\nOne is to aggregate metadata output from multiple fixer tool executions to display a summary at the end (so wrapping cleanup() is sensible). Not sure who else would use that, or if there's a good way to make a generic interface for it.\n\nAnother is basically to add a \"--nodeid_for_this_file=deadbeef\" to a fixer tool command line. That's where it would be sufficient to have the ctx available. It might be nice to put the ctx into the templater, but that raises some questions about implementation that I wanted to punt for now.\n\n>> \n>> A better version of this might put \"ctx\" into the templater inside Fixer.command, and maybe add a no-op Fixer.cleanup method to make that part more explicit. I think that would be a less trivial super set of this patch.","author":"hooper","id":"81875","dateCreated":"1547064942","dateModified":"1547064942"},{"type":"comment","comment":">>! In D5516#81683, @hooper wrote:\n>>>! In D5516#81679, @durin42 wrote:\n>> I'm -0 on this: what's special about this functionality that it needs to be an extension of an extension instead of something that can be done in core?\n> \n> Google's internal use of this extension makes some customizations that I doubt would be appealing in core. This patch makes some of it simpler to implement. Making all of it possible through configs\/templates might be unduly complex.\n\nWhat kinds of customizations?\n\n> \n> A better version of this might put \"ctx\" into the templater inside Fixer.command, and maybe add a no-op Fixer.cleanup method to make that part more explicit. I think that would be a less trivial super set of this patch.\n\n","author":"durin42","id":"81841","dateCreated":"1547062928","dateModified":"1547062928"},{"type":"comment","comment":">>! In D5516#81679, @durin42 wrote:\n> I'm -0 on this: what's special about this functionality that it needs to be an extension of an extension instead of something that can be done in core?\n\nGoogle's internal use of this extension makes some customizations that I doubt would be appealing in core. This patch makes some of it simpler to implement. Making all of it possible through configs\/templates might be unduly complex.\n\nA better version of this might put \"ctx\" into the templater inside Fixer.command, and maybe add a no-op Fixer.cleanup method to make that part more explicit. I think that would be a less trivial super set of this patch.","author":"hooper","id":"81683","dateCreated":"1546906338","dateModified":"1546906338"},{"type":"comment","comment":"I'm -0 on this: what's special about this functionality that it needs to be an extension of an extension instead of something that can be done in core?","author":"durin42","id":"81680","dateCreated":"1546905244","dateModified":"1546905244"},{"type":"update","diffId":"13063","author":"hooper","id":"81596","dateCreated":"1546902246","dateModified":"1546902246"}],"dateCreated":"1546902246","dateModified":"1547064942","status":"Needs Review"},{"id":"5538","callsign":"HG","title":"hgweb: add \/obsgraph page that shows obsolescence history of a changeset (PoC)","author":"av6","summary":"Feel free to ask questions, I suspect some chunks would need a comment (either\nin review or in code) to explain what's going on there.\n\nI'll start working on the other hgweb themes later, when I get feedback on this\nseries.\n\nColor choices are from the current canvas-based graph, but that probably will\nchange when I find a better color scheme.\n\nI'm revisiting the idea of making graph in hgweb be SVG as opposed to canvas,\nand this new page, that is separate from \/graph, looks like a good testing\nfield: locally I have replaced canvas graph with this new SVG graph on \/graph\npage and it works fine and looks better, and I hope to improve the visuals even\nmore. The data structures are the same (for now, at least), and SVGGraph in\nmercurial.js is mostly a copy of the current Graph class.\n\nTooltips for different graph nodes currently work only in Chromium and similar\nbrowsers, but it's still better than no tooltips (on cavnas).\n\nYou can see obsgraph live on http:\/\/hg-test.dwimlabs.net\/","testPlan":"","lineCount":"458","dependsOn":["5537"],"reviewers":[],"ccs":["durin42","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":"Without looking deeply at the implementation (I basically trust you to do reasonable things here), I like the feature existing and poking around briefly on obsdemo looks reasonable...","author":"durin42","id":"81832","dateCreated":"1547062477","dateModified":"1547062477"},{"type":"update","diffId":"13092","author":"av6","id":"81811","dateCreated":"1547032282","dateModified":"1547032282"}],"dateCreated":"1547032282","dateModified":"1547062477","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":"5537","callsign":"HG","title":"obsutil: add a simplified obshistorywalker() (PoC)","author":"av6","summary":"This code is taken from evolve extension, namely from obslog command\nimplementation, and somewhat simplified to be easier to review.\n\nNo tests and no users for now. The next patch will be more interesting.","testPlan":"","lineCount":"153","dependsOn":[],"reviewers":[],"ccs":["mjpieters","mercurial-devel"],"actions":[{"type":"update","diffId":"13091","author":"av6","id":"81805","dateCreated":"1547032273","dateModified":"1547032273"}],"dateCreated":"1547032273","dateModified":"1547032282","status":"Needs Review"},{"id":"5444","callsign":"HG","title":"help: use \"yes\" and \"no\" for boolean defaults instead of \"on\" and \"off\"","author":"av6","summary":"","testPlan":"","lineCount":"45","dependsOn":[],"reviewers":["durin42"],"ccs":["yuja","martinvonz","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"I feel `--no-<thing>` and `--<thing>=off|false` are more natural, and\n`(default: %s)` is the latter form.","author":"yuja","id":"80613","dateCreated":"1544924937","dateModified":"1544924937"},{"type":"comment","comment":"Arguments against yes\/no:\n\n1. \"default: yes\/no\" can easily be read as \"is this a default\", which is not quite the same, although it would have the same effect.\n\n2. On\/off fits well in sentences like \"is --hidden on by default\".\n\nI see your arguments too (mostly the last one of them), but I still slightly prefer on\/off.","author":"martinvonz","id":"80611","dateCreated":"1544903230","dateModified":"1544903230"},{"type":"comment","comment":"The point of D5430 was to make hg help output more human friendly by replacing `True` and `False` with something less Python-related. In other words, more human-friendly. \"Yes\" and \"no\" are way more human-friendly:\n\n* they are one of the most used words, so people naturally expect to see them, and can tell them apart from just \"y\" or \"n\" (they are also less ambiguous themselves \u2014 just look up how many meanings \"on\" or \"off\" has and how many parts of speech can they be),\n* they also work perfectly fine as answers to the flag descriptions (Consider hidden changesets? Yes, please. No, thanks.),\n* and \"no\" (more precisely, \"no-\") is the very same thing that users should add to the flags to negate them (not \"--off-hidden\").\n","author":"av6","id":"80608","dateCreated":"1544897014","dateModified":"1544897014"},{"type":"comment","comment":"TBH, I think 'on' and 'off' are more appropriate than 'yes' and 'no'.","author":"pulkit","id":"80606","dateCreated":"1544888113","dateModified":"1544888113"},{"type":"update","diffId":"12881","author":"av6","id":"80580","dateCreated":"1544874595","dateModified":"1544874595"}],"dateCreated":"1544874595","dateModified":"1544924937","status":"Needs Review"},{"id":"5417","callsign":"HG","title":"rust: translated random test of missingancestors","author":"gracinet","summary":"In case of a failed example, all needed information\nfor reproduction is included in the panic message,\nso that we don't need to\nseed the random generator explicitely. This is how\n`test_remove_ancestors_from_case1()` has been generated.\n\nAn alternative would have been to expose to Python\nMissingAncestors<VecGraphs> but that would have meant\n- pollution of the release build used from Python,\n  whereas we do it in this changeset within the tests submodule\n- waiting on rust-cpython bindings to be ready or doing the\n  cumbersome direct-ffi (more pollution with unsafe C code)","testPlan":"","lineCount":"405","dependsOn":[],"reviewers":[],"ccs":["yuja","durin42","kevincox","mercurial-devel"],"actions":[{"type":"comment","comment":"@yuja: I'll look into it, maybe that's a case for benches (I've not played with them yet).","author":"gracinet","id":"80471","dateCreated":"1544866546","dateModified":"1544866546"},{"type":"comment","comment":">   In case of a failed example, all needed information\n>   for reproduction is included in the panic message,\n>   so that we don't need to\n>   seed the random generator explicitely. This is how\n>   `test_remove_ancestors_from_case1()` has been generated.\n\nCan we turn this into a utility command? I don't think it's good idea to\ninclude random data in module tests. We'll probably want to loop it over\nvarious seeds to find interesting graphs.","author":"yuja","id":"80470","dateCreated":"1544844558","dateModified":"1544844558"},{"type":"update","diffId":"12856","author":"gracinet","id":"80394","dateCreated":"1544810361","dateModified":"1544810361"},{"type":"update","diffId":"12833","author":"gracinet","id":"80283","dateCreated":"1544631984","dateModified":"1544631984"},{"type":"update","diffId":"12830","author":"gracinet","id":"80269","dateCreated":"1544627486","dateModified":"1544627486"}],"dateCreated":"1544627486","dateModified":"1544874674","status":"Needs Review"},{"id":"5424","callsign":"HG","title":"py3: use util.buffer instead of buffer in remotefilelog","author":"pulkit","summary":"This fixes test-remotefilelog-bundles.t on Python 3.","testPlan":"","lineCount":"4","dependsOn":[],"reviewers":[],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"> -        if isinstance(text, buffer):\n> +        if isinstance(text, util.buffer):\n>              text = str(text)\n\n`util.buffer` isn't a type object on Python 3. Given `str(text)` didn't\nexplode, such cases wouldn't be covered by the tests.","author":"yuja","id":"80453","dateCreated":"1544836740","dateModified":"1544836740"},{"type":"update","diffId":"12849","author":"pulkit","id":"80358","dateCreated":"1544805761","dateModified":"1544805761"}],"dateCreated":"1544805761","dateModified":"1544836740","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":"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":"1544539647","status":"Needs Revision"},{"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":"5296","callsign":"HG","title":"store: don't read the whole fncache in memory","author":"pulkit","summary":"In large repositories with lot of files, the fncache grows more than 100 MB and\nreading that whole thing into memory slows things down. Let's not read the whole\nthing into memory.\n\nFollowing are the performance optimizations observed:\n\n`hg perffncacheload` (best of 4 runs)\n\nbefore: wall 3.253480 comb 3.440000 user 2.500000 sys 0.940000 (best of 3)\nafter: wall 2.850717 comb 3.010000 user 2.370000 sys 0.640000 (best of 4)","testPlan":"","lineCount":"14","dependsOn":[],"reviewers":[],"ccs":["yuja","mjpieters","mercurial-devel"],"actions":[{"type":"comment","comment":"Seeing the performance benefit it brings on our repo, I want to try other ways we can do this. Do we like having a conditional which checks the size of fncache and choose one of the approaches depending on how large it is?\n\nIf size(fncache) < 50M, use the current approach\nelse, use the approach described in this patch\n\n@yuja what do you think?","author":"pulkit","id":"78966","dateCreated":"1543315722","dateModified":"1543315722"},{"type":"comment","comment":">>! In D5296#78834, @yuja wrote:\n>> diff --git a\/mercurial\/store.py b\/mercurial\/store.py\n>> --- a\/mercurial\/store.py\n>> +++ b\/mercurial\/store.py\n>> @@ -461,13 +461,13 @@\n>>              # skip nonexistent file\n>>              self.entries = set()\n>>              return\n>> -        self.entries = set(decodedir(fp.read()).splitlines())\n>> -        if '' in self.entries:\n>> -            fp.seek(0)\n>> -            for n, line in enumerate(util.iterfile(fp)):\n>> -                if not line.rstrip('\\n'):\n>> -                    t = _('invalid entry in fncache, line %d') % (n + 1)\n>> -                    raise error.Abort(t)\n>> +        self.entries = set()\n>> +        for n, line in enumerate(util.iterfile(fp)):\n>> +            entry = line.rstrip('\\n')\n>> +            if not entry:\n>> +                t = _('invalid entry in fncache, line %d') % (n + 1)\n>> +                raise error.Abort(t)\n>> +            self.entries.add(decodedir(entry))\n> \n> This goes the opposite direction to 9fca5b056c0a. I guess the current code\n> would be faster if the fncache is around ~10MB. Can you benchmark it?\n\nYeah the current code is much faster if fncache is not large. ","author":"pulkit","id":"78900","dateCreated":"1543228711","dateModified":"1543228711"},{"type":"comment","comment":"> diff --git a\/mercurial\/store.py b\/mercurial\/store.py\n> --- a\/mercurial\/store.py\n> +++ b\/mercurial\/store.py\n> @@ -461,13 +461,13 @@\n>              # skip nonexistent file\n>              self.entries = set()\n>              return\n> -        self.entries = set(decodedir(fp.read()).splitlines())\n> -        if '' in self.entries:\n> -            fp.seek(0)\n> -            for n, line in enumerate(util.iterfile(fp)):\n> -                if not line.rstrip('\\n'):\n> -                    t = _('invalid entry in fncache, line %d') % (n + 1)\n> -                    raise error.Abort(t)\n> +        self.entries = set()\n> +        for n, line in enumerate(util.iterfile(fp)):\n> +            entry = line.rstrip('\\n')\n> +            if not entry:\n> +                t = _('invalid entry in fncache, line %d') % (n + 1)\n> +                raise error.Abort(t)\n> +            self.entries.add(decodedir(entry))\n\nThis goes the opposite direction to 9fca5b056c0a. I guess the current code\nwould be faster if the fncache is around ~10MB. Can you benchmark it?","author":"yuja","id":"78836","dateCreated":"1542893536","dateModified":"1542893536"},{"type":"update","diffId":"12583","author":"pulkit","id":"78828","dateCreated":"1542889621","dateModified":"1542889621"}],"dateCreated":"1542889621","dateModified":"1543315722","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":"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":[],"ccs":["mharbison72","mercurial-devel"],"actions":[{"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":"1543080661","status":"Needs Review"},{"id":"5290","callsign":"HG","title":"branchmap: refactor for better encapsulation","author":"mjpieters","summary":"","testPlan":"","lineCount":"302","dependsOn":[],"reviewers":[],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"Can you split this to a couple of patches?\n\nThe idea sounds good, but it isn't easy to review formatting changes,\ncode moves, and interface improvements as a single patch.","author":"yuja","id":"78884","dateCreated":"1543029860","dateModified":"1543029860"},{"type":"comment","comment":"The goal of this refactor is to bring clarity to the branchmap cache behaviour, and to make it easier to add performance improvements (in an upcoming additional series of patches).","author":"mjpieters","id":"78820","dateCreated":"1542886704","dateModified":"1542886704"},{"type":"update","diffId":"12573","author":"mjpieters","id":"78776","dateCreated":"1542721522","dateModified":"1542721522"}],"dateCreated":"1542721522","dateModified":"1543029860","status":"Needs Review"},{"id":"5292","callsign":"HG","title":"branchmap: make it easier for extensions not to break branchcache","author":"mjpieters","summary":"The _branchcache global gives us a reference for super() to use even if an\nextension subclasses branchmap.branchcache then replaces the class in the\nmodule.","testPlan":"","lineCount":"7","dependsOn":["5290"],"reviewers":[],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":">   The _branchcache global gives us a reference for super() to use even if an\n>   extension subclasses branchmap.branchcache then replaces the class in the\n>   module.\n\nCan't we instead add a factory function which can be easily hooked by\nextensions?\n\nIt should be discouraged to replace a class globally.","author":"yuja","id":"78880","dateCreated":"1543029177","dateModified":"1543029177"},{"type":"update","diffId":"12577","author":"mjpieters","id":"78797","dateCreated":"1542812162","dateModified":"1542812162"}],"dateCreated":"1542812162","dateModified":"1543029177","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":"5211","callsign":"HG","title":"templateutil: add mappingdict to handle dicts in template\/formatter props","author":"spectral","summary":"(Code is copy\/pasted from yuya's comment on\nhttps:\/\/phab.mercurial-scm.org\/D5094)","testPlan":"","lineCount":"23","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"12368","author":"spectral","id":"77780","dateCreated":"1541113276","dateModified":"1541113276"}],"dateCreated":"1541113276","dateModified":"1541113338","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":"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":"108","dependsOn":[],"reviewers":[],"ccs":["marcink","mercurial-devel"],"actions":[{"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":"1539706284","status":"Needs Review"},{"id":"5112","callsign":"HG","title":"graphmod: remove support for graph lines mixing parent\/grandparent styles (BC)","author":"spectral","summary":"Currently, if the configuration for a graph edge draw style has multiple bytes\n(at least on python2), it is interpreted as \"this is a request to draw the line\npartially in the style of the parent, partially in the style of the\ngrandparent\". This precludes the configuration handling unicode characters\n(which trigger the `len > 1` check, at least on python2), and I believe was part\nof the reason that beautifygraph was written the way it was.\n\nTalking with the person who implemented this, it appears to have been to achieve\nfeature parity with the rendering of the smartlog extension. I suspect that this\nisn't actually used outside of that situation, so I think that we can remove it\nwithout much issue.\n\nThis will make it so that multi-character edges are possible, and render any\nexisting configuration that uses this feature with these multiple characters.\nThis is *not* going to adjust the width of everything to make it line up\ncorrectly, please see the test that's being modified in this changeset for an\nexample of how the previous configuration now renders.\n\nNote also that the previous configuration seems to have been broken, or at least\nit was behaving in a really non-obvious way - it was avoiding the grandparent\ncharacter(s) when it should have been displaying them! This is why so many \"!\"\ncharacters changed to \"3.\"; I don't know if this was intentional.","testPlan":"","lineCount":"271","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"12159","author":"spectral","id":"76468","dateCreated":"1539693715","dateModified":"1539693715"}],"dateCreated":"1539693715","dateModified":"1539693777","status":"Needs Review"},{"id":"5088","callsign":"HG","title":"hghave: add pyXY features for Python version numbers","author":"indygreg","summary":"This will allow us to sniff for Python >= versions in tests.","testPlan":"","lineCount":"7","dependsOn":[],"reviewers":[],"ccs":["durin42","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D5088#76415, @durin42 wrote:\n> Ah, so I could do (no-py27 no-py35 !) I suppose. Doesn't help with the other half, but it's still only three lines...\n\n`(no-py27 no-py35 !)` would be \"<2.7 & < 3.5\", which would only be true for <=2.6. You'd want `no-py35` to say \"Python 2.7 only\" for example. \n \n> I'm not opposed to the patch, but I'm a little wary of it - so far we only have one use case and I already worked around that with an (re) line instead.\n\nExplicit annotation of expected differences in behavior is better than e.g. a `(re)`. I'm willing to be that `(re)` survives long after we drop support for Python 3.6 in several years...","author":"indygreg","id":"76416","dateCreated":"1539588517","dateModified":"1539588517"},{"type":"comment","comment":">>! In D5088#76414, @indygreg wrote:\n>>>! In D5088#76278, @durin42 wrote:\n>> Is there a way for me to specify something like \"<=3.5\" and \"3.6<=\" or similar?\n> \n> Adding `no-` to the capability name will invert the condition. e.g. 3.5 will test false for `no-py27` and `no-py35` and true for `no-py36` and `no-py37`.\n> \n> If that is too confusing (I can make an argument it is), we could add a 2nd hghave series for the `<=` check. Say `pymax27`, `pymax36` etc.\n\nAh, so I could do (no-py27 no-py35 !) I suppose. Doesn't help with the other half, but it's still only three lines...\n\nI'm not opposed to the patch, but I'm a little wary of it - so far we only have one use case and I already worked around that with an (re) line instead.","author":"durin42","id":"76415","dateCreated":"1539581122","dateModified":"1539581122"},{"type":"comment","comment":">>! In D5088#76278, @durin42 wrote:\n> Is there a way for me to specify something like \"<=3.5\" and \"3.6<=\" or similar?\n\nAdding `no-` to the capability name will invert the condition. e.g. 3.5 will test false for `no-py27` and `no-py35` and true for `no-py36` and `no-py37`.\n\nIf that is too confusing (I can make an argument it is), we could add a 2nd hghave series for the `<=` check. Say `pymax27`, `pymax36` etc.","author":"indygreg","id":"76414","dateCreated":"1539555018","dateModified":"1539555018"},{"type":"comment","comment":"Is there a way for me to specify something like \"<=3.5\" and \"3.6<=\" or similar?","author":"durin42","id":"76279","dateCreated":"1539511457","dateModified":"1539511457"},{"type":"update","diffId":"12096","author":"indygreg","id":"76154","dateCreated":"1539442820","dateModified":"1539442820"},{"type":"update","diffId":"12095","author":"indygreg","id":"76149","dateCreated":"1539442433","dateModified":"1539442433"}],"dateCreated":"1539442433","dateModified":"1539588517","status":"Needs Review"},{"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":"4785","callsign":"HG","title":"streamclone: pass includes and excludes to fn generating clones","author":"pulkit","summary":"This patch adds includes and excludes as argument to couple of functions which\ngenerates the streamclone. The goal is to filter out the data according to user\npassed includes and excludes.\n\nI need to develop some API's which can be used to filter the streamclone data\nand not depend on revlog-specific API's. So for now, we just raise an error\nsaying this is not implemented.\n\nThis patch adds a test showing that code is working and we are correctly passing\nincludes and excludes around.","testPlan":"","lineCount":"60","dependsOn":["4784"],"reviewers":["durin42","indygreg"],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"comment","comment":"I'm +1 on the direction of this series.\n\nI think we should make the feature stream clone version 2 only, as it requires client-side features and clients will presumably be using stream clone version 2. So supporting version 1 stream clones feels like avoidable complexity.\n\nWe may also want to make server advertisement of the capability conditional on a value in `repo.features`. Then we can have revlog-based repos add that feature in `localrepo.makefilestorage()`. This is because not all storage backends will support narrow stream clone and I think it is something that a storage backend should opt into.\n\nIt may also help to reorder the series so the `streamclone.py` changes come before the wire protocol bits, as they are less controversial and could be committed earlier.","author":"indygreg","id":"72888","dateCreated":"1538415031","dateModified":"1538415031"},{"type":"reject","author":"indygreg","id":"72887","dateCreated":"1538415031","dateModified":"1538415031"},{"type":"update","diffId":"11457","author":"pulkit","id":"72368","dateCreated":"1538080034","dateModified":"1538080034"}],"dateCreated":"1538080034","dateModified":"1538415031","status":"Needs Revision"},{"id":"4783","callsign":"HG","title":"narrow: add 'narrowstream' server capability to use streamclones with narrow","author":"pulkit","summary":"This patch adds a new server capability \"narrowstream\" which will dictate\nwhether the server is capable of serving narrow-stream clones or not.\n\nThis also add support for getting include and exclude arguments as part of\nstream_out wireprotocol call. We don't use those arguments yet, but we will use\nin future.","testPlan":"","lineCount":"21","dependsOn":[],"reviewers":[],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"inline","comment":"This will need a `decodelist()`.","replyTo":null,"isNewFile":"1","line":"550","lineLength":"1","path":"mercurial\/wireprotov1server.py","diffId":"11455","author":"indygreg","id":"72885","dateCreated":"1538414661","dateModified":"1538414661"},{"type":"comment","comment":"Since this feature will require Mercurial 4.8 and since stream clone v2 is enabled by default in 4.8, I have a moderate preference for not changing the `stream_out` command to support narrow stream clones. i.e. why introduce complexity on that command when it will likely never be used.","author":"indygreg","id":"72884","dateCreated":"1538414661","dateModified":"1538414661"},{"type":"comment","comment":"This series works on streamclone v1 right now because I ran into that codepath first and also that's what we use right now. I looked into the code for v2 streamclone and once I get narrow clones working for v1, I will make sure we support v2.","author":"pulkit","id":"72378","dateCreated":"1538080233","dateModified":"1538080233"},{"type":"update","diffId":"11455","author":"pulkit","id":"72352","dateCreated":"1538080021","dateModified":"1538080021"}],"dateCreated":"1538080021","dateModified":"1538414661","status":"Needs Review"},{"id":"4784","callsign":"HG","title":"streamclone: pass includes and excludes to stream_out wireprotocol cmd","author":"pulkit","summary":"This adds client side logic to pass includes and excludes to the stream_out()\nwireprotocol command. Tests are not added because there is not server side logic\nyet to filter out data to stream.\n\n# no-check-commit because it touches a function with foo_bar naming","testPlan":"","lineCount":"19","dependsOn":["4783"],"reviewers":["indygreg"],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"inline","comment":"I think we also want to make this conditional on a narrow stream clone actually being requested. i.e. don't send the arguments unless they have values.","replyTo":null,"isNewFile":"1","line":"141","lineLength":"0","path":"mercurial\/streamclone.py","diffId":"11456","author":"indygreg","id":"72881","dateCreated":"1538414544","dateModified":"1538414544"},{"type":"inline","comment":"Nit: don't use mutable values as default argument values.","replyTo":null,"isNewFile":"1","line":"412","lineLength":"0","path":"mercurial\/wireprotov1peer.py","diffId":"11456","author":"indygreg","id":"72880","dateCreated":"1538414544","dateModified":"1538414544"},{"type":"reject","author":"indygreg","id":"72879","dateCreated":"1538414544","dateModified":"1538414544"},{"type":"update","diffId":"11456","author":"pulkit","id":"72358","dateCreated":"1538080027","dateModified":"1538080027"}],"dateCreated":"1538080027","dateModified":"1538414544","status":"Needs Revision"},{"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 -Tcbor for changeset printing.\nI'll have to figure that out...\n\nI added tests for -Tcbor for most of the instances of -Tjson in\nthe test harness.\n\n.. feature::\n\n   `--template\/-T cbor` can now be specified to emit data as CBOR.\n\n   (This feature is experimental and the data format may change.)","testPlan":"","lineCount":"419","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"plan-changes","author":"indygreg","id":"53405","dateCreated":"1523664767","dateModified":"1523664767"},{"type":"update","diffId":"8105","author":"indygreg","id":"52788","dateCreated":"1523600792","dateModified":"1523600792"}],"dateCreated":"1523600792","dateModified":"1523664767","status":"Changes Planned"},{"id":"3209","callsign":"HG","title":"amend: exit 0 if there are no changes","author":"spectral","summary":"It's useful for writing some scripts or shell aliases if `hg amend` doesn't\nabort the series of commands if there's nothing to amend.  Users can then have\nsomething like \"alias amendevo='hg amend && hg evolve -a'\" to amend and evolve\nin one step.\n\nTo do this otherwise would require something like this:\n\n    alias amendevo='[[ -z \"$(hg status -mar)\" ]] && hg amend && hg evolve -a'\n\nWhile that's not too onerous, it's not immediately obvious to most that this is\nwhat would have to be done, so it's a small hurdle that users either have to\nspend time to figure out on their own or ask about.\n\nA similar change was made to `hg evolve` recently, for similar reasons.","testPlan":"","lineCount":"11","dependsOn":[],"reviewers":[],"ccs":["quark","mercurial-devel"],"actions":[{"type":"comment","comment":"I think it depends on what scripts want to do. I guess mpm's original point is, suppose you have a build script, or something that should do nothing if nothing changed, then `hg amend && build_script` just works as expected. If amend returns 0, then it'd be more complex to detect \"nothing changed\" case.","author":"quark","id":"51517","dateCreated":"1523325101","dateModified":"1523325101"},{"type":"comment","comment":">>! In D3209#51512, @quark wrote:\n> Returning 1 is actually more consistent with other core commands like pull, push, commit. See https:\/\/www.mercurial-scm.org\/pipermail\/mercurial-devel\/2012-January\/037711.html. Scripts should be updated to use `$?` explicitly. \n\nI'm not sure how scripts can be updated to use $? explicitly.  Mercurial exits 1 in many situations:\n- nothing found\n- hg verify, if there's any problems\n- unresolved conflicts when updating\/rebasing\/whatever\n- histedit 'edit' seems to dump you back into a terminal with exit status 1\n- MQ seems to use it a lot\n- I think a few others?\n\nYes, none of these apply to `hg amend`, so doing something like `hg amend; [[ $? -eq 1 ]] && hg evolve -a` is feasible, but again, feels really weird and non-discoverable. :\/\n\nI also see a few cases that return 2, mostly in MQ stuff (though there is one case in test-bookmarks-pushpull.t that's a little odd).  There's obviously the \"255\" return whenever there's a major problem.  \n\nI'm not too tied to the patch and can abandon it if people feel it's incorrect.  \n","author":"spectral","id":"51514","dateCreated":"1523319609","dateModified":"1523319609"},{"type":"comment","comment":"Returning 1 is actually more consistent with other core commands like pull, push, commit. See https:\/\/www.mercurial-scm.org\/pipermail\/mercurial-devel\/2012-January\/037711.html. Scripts should be updated to use `$?` explicitly. ","author":"quark","id":"51513","dateCreated":"1523317049","dateModified":"1523317049"},{"type":"update","diffId":"7916","author":"spectral","id":"51436","dateCreated":"1523311789","dateModified":"1523311789"}],"dateCreated":"1523311789","dateModified":"1523325101","status":"Needs Review"},{"id":"2403","callsign":"HG","title":"stack: remove destutil.stackbase","author":"lothiraldan","summary":"Use directly stack.getstack in show stack command. Remove destutil.stackbase.\nImport a TODO from the show stack in the code.","testPlan":"","lineCount":"16","dependsOn":["2402"],"reviewers":[],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"update","diffId":"7736","author":"lothiraldan","id":"50324","dateCreated":"1522945351","dateModified":"1522945351"},{"type":"comment","comment":">>! In D2403#39460, @indygreg wrote:\n> Oh, I guess the series never did formerly define a revset for stack :\/\n> \n> I think there is room for one. We have the ability to mark revsets as experimental or internal, right? Could\/should we do that so we don't need `hg debugstack`?\n> \n> Anyway, I could probably queue this with some minor rework. But I'm going to hold off a bit and see if others have opinions.\n\nI have updated the series without using debugstack, thank you for the suggestion. I thought revset would were much harder to implement but turn out not so much harder.","author":"lothiraldan","id":"40956","dateCreated":"1519934450","dateModified":"1519934450"},{"type":"update","diffId":"6219","author":"lothiraldan","id":"40701","dateCreated":"1519862380","dateModified":"1519862380"},{"type":"comment","comment":"Oh, I guess the series never did formerly define a revset for stack :\/\n\nI think there is room for one. We have the ability to mark revsets as experimental or internal, right? Could\/should we do that so we don't need `hg debugstack`?\n\nAnyway, I could probably queue this with some minor rework. But I'm going to hold off a bit and see if others have opinions.","author":"indygreg","id":"39461","dateCreated":"1519440298","dateModified":"1519440298"},{"type":"update","diffId":"6017","author":"lothiraldan","id":"39366","dateCreated":"1519382238","dateModified":"1519382238"}],"dateCreated":"1519382238","dateModified":"1522945387","status":"Needs Review"},{"id":"2402","callsign":"HG","title":"stack: introduce an option to limit the selection on the current branch","author":"lothiraldan","summary":" ","testPlan":"","lineCount":"37","dependsOn":["2401"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"7735","author":"lothiraldan","id":"50323","dateCreated":"1522945345","dateModified":"1522945345"},{"type":"update","diffId":"6218","author":"lothiraldan","id":"40700","dateCreated":"1519862377","dateModified":"1519862377"},{"type":"update","diffId":"6016","author":"lothiraldan","id":"39357","dateCreated":"1519382234","dateModified":"1519382234"}],"dateCreated":"1519382234","dateModified":"1522945345","status":"Needs Review"},{"id":"2401","callsign":"HG","title":"stack: introduce an option to disable the restriction on ancestor","author":"lothiraldan","summary":"The default stack revset restrict on only the ancestors of a revision. Some\ntools might want to display the current stack even if the working directory\nparent is in the middle of the stack.\n\nAdd the `stack.restrict-ancestors` option to disable that.","testPlan":"","lineCount":"17","dependsOn":["2400"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"7734","author":"lothiraldan","id":"50322","dateCreated":"1522945341","dateModified":"1522945341"},{"type":"update","diffId":"6217","author":"lothiraldan","id":"40699","dateCreated":"1519862374","dateModified":"1519862374"},{"type":"update","diffId":"6015","author":"lothiraldan","id":"39347","dateCreated":"1519382229","dateModified":"1519382229"}],"dateCreated":"1519382229","dateModified":"1522945341","status":"Needs Review"},{"id":"2400","callsign":"HG","title":"stack: begin to make the stack revset configurable","author":"lothiraldan","summary":"First extrat the not-merge part in its own configuration knob `stack.not-\nmerge`.","testPlan":"","lineCount":"25","dependsOn":[],"reviewers":["indygreg"],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"update","diffId":"7733","author":"lothiraldan","id":"50320","dateCreated":"1522945336","dateModified":"1522945336"},{"type":"comment","comment":"The goal of this series is to define a clean API so that commands and tools can be built in a stack-definition agnostic way. It's not to define a one-size-fits-all stack definition.\n\nPeople and companies have different workflows and needs. Their definition of a stack will likely to be different to better match their workflow. I tried finding a way to configure stack as easily as possible. I have the impression that using configuration options is slightly easier than defining a custom extension. I also avoided using directly a revset from the configuration file as I'm not sure it would be the best way to express all situations.\n\nI don't know if the config options best place are in the `stack` section though.","author":"lothiraldan","id":"50310","dateCreated":"1522943035","dateModified":"1522943035"},{"type":"comment","comment":"Reading through the remainder of the series, I like the customization of stack evaluation. But the use of config options seems weird to me. It isn't clear why we need config options. It feels like these options should be passed in as function arguments. Now, it will be useful to test these variations. Maybe that does require config options. But until there is a user-facing need for these config options, It feels better to put them in `[devel]` or something like that.\n\nIs there a future consumer of these config options that justifies them being normal config options?","author":"indygreg","id":"46534","dateCreated":"1521490461","dateModified":"1521490461"},{"type":"reject","author":"indygreg","id":"46533","dateCreated":"1521490461","dateModified":"1521490461"},{"type":"inline","comment":"As I review just this patch, I question if we shouldn't just concatenate `and not ::merge()` to the revset string. But I know other changes are coming. I assume the final state justifies the extra complexity.","replyTo":null,"isNewFile":"1","line":"41","lineLength":"1","path":"mercurial\/stack.py","diffId":"6216","author":"indygreg","id":"46531","dateCreated":"1521490117","dateModified":"1521490117"},{"type":"comment","comment":"I'm not super keen on introducing a new `[stack]` config section. But I don't have any better ideas for where this should go. `[ui]` is my best idea, but I thought we decided we wanted to stop stuffing random stuff into `[ui]`. So I dunno.","author":"indygreg","id":"46530","dateCreated":"1521490117","dateModified":"1521490117"},{"type":"accept","author":"indygreg","id":"46529","dateCreated":"1521490117","dateModified":"1521490117"},{"type":"update","diffId":"6216","author":"lothiraldan","id":"40698","dateCreated":"1519862372","dateModified":"1519862372"},{"type":"update","diffId":"6014","author":"lothiraldan","id":"39337","dateCreated":"1519382224","dateModified":"1519382224"}],"dateCreated":"1519382224","dateModified":"1522945336","status":"Needs Review"},{"id":"2999","callsign":"HG","title":"infinitepush: use zope.interface to define indexapi interface","author":"pulkit","summary":"This patch makes indexapi use zope.interface which is now vendored with\nmercurial.","testPlan":"","lineCount":"20","dependsOn":[],"reviewers":["indygreg"],"ccs":["indygreg","mercurial-devel"],"actions":[{"type":"comment","comment":"Oh, when you add test coverage, watch out for `mysql.connector` being unavailable. You may want to register a fake module in `sys.modules['mysql.connector']` to ensure it always is available.","author":"indygreg","id":"48566","dateCreated":"1522517045","dateModified":"1522517045"},{"type":"inline","comment":"`Interface` classes don't define `self` on methods. So please drop `self` from all these methods.","replyTo":null,"isNewFile":"1","line":"25","lineLength":"0","path":"hgext\/infinitepush\/indexapi.py","diffId":"7466","author":"indygreg","id":"48564","dateCreated":"1522516965","dateModified":"1522516965"},{"type":"comment","comment":"Please also add test coverage to `test-check-interfaces.py`, otherwise these interfaces mean practically nothing. `zope.interface` doesn't perform run-time interface conformance tests unless you explicitly instruct it to. For now, we're going to verify interfaces in `test-check-interfaces.py`.","author":"indygreg","id":"48563","dateCreated":"1522516965","dateModified":"1522516965"},{"type":"reject","author":"indygreg","id":"48562","dateCreated":"1522516965","dateModified":"1522516965"},{"type":"update","diffId":"7466","author":"pulkit","id":"48513","dateCreated":"1522497241","dateModified":"1522497241"}],"dateCreated":"1522497241","dateModified":"1522517045","status":"Needs Revision"},{"id":"2623","callsign":"HG","title":"dispatch: adding config items for overriding flag defaults","author":"rdamazio","summary":"This introduces the new defaults format \"commandname.default.optionname\" which\ndirectly overrides the default of the option, instead of prepending the\ncommand-line option. This is meant to replace the [defaults] section which is\nalready deprecated in a manner that's easier and safer to use than creating\naliases.","testPlan":"","lineCount":"96","dependsOn":["2622"],"reviewers":["yuja"],"ccs":["dploch","mercurial-devel"],"actions":[{"type":"inline","comment":"I thought callables were meant to be used to generate the default default, not with overridden values?","replyTo":"43409","isNewFile":"1","line":"625","lineLength":"1","path":"mercurial\/dispatch.py","diffId":"6609","author":"rdamazio","id":"47743","dateCreated":"1522132208","dateModified":"1522132208"},{"type":"inline","comment":"Nobody should use the same *instance* on multiple flags. Even with the current flags, if you use e.g. the same list on many, that'll cause problems with listopt.\n","replyTo":"43410","isNewFile":"1","line":"639","lineLength":"1","path":"mercurial\/dispatch.py","diffId":"6609","author":"rdamazio","id":"47742","dateCreated":"1522132208","dateModified":"1522132208"},{"type":"inline","comment":"This makes me nervous.  What if someone re-uses a customopt instance in multiple commands?  i.e.:\n\nDATE_FLAG = mypkg.dateopt()\n...\n('b', 'before', DATE_FLAG, '')\n('a', 'after', 'DATE_FLAG', '')\n\nNow, setting commands.defaults.before=2018-03-05 also silently changes the default for 'after'.  I suspect we need to introduce a wrapper class like what I suggest on lines 625-625, that delegates and leaves the original default unchanged.  And either way, we should probably clarify in the docs on customopts what expected use of the class is (i.e., should we just forbid reuse, is 'oldstate' safe to mutate, etc.)","replyTo":null,"isNewFile":"1","line":"639","lineLength":"1","path":"mercurial\/dispatch.py","diffId":"6609","author":"dploch","id":"43410","dateCreated":"1520292544","dateModified":"1520292544"},{"type":"inline","comment":"This doesn't handle callables properly.  I wonder if the something like the following would work instead:\n\noldopt = fancyopts._defaultopt(olddefault)\nnewdefault = old.opt.newstate(olddefault, ui.config(\"commands\", cfgitem)\nc[idx] = (opt[0], opt[1], fancyopts._withnewdefault(oldopt, newdefault), opt[3])\n\nWhere '_withnewdefault' is a wrapper customopt that just changes the default.","replyTo":null,"isNewFile":"1","line":"625","lineLength":"1","path":"mercurial\/dispatch.py","diffId":"6609","author":"dploch","id":"43409","dateCreated":"1520292544","dateModified":"1520292544"},{"type":"inline","comment":"I think rdamazio's response is correct.  The type information for an opt exists only in the 'defaultvalue' slot in the tuple, so it needs to be extracted from there before reading the config.  I don't have a strong opinion as to where this code should go - 'ui' does seem marginally more appropriate than 'fancyopts', since it keeps 'fancyopts' low-level and not depending on 'ui'.","replyTo":"42582","isNewFile":"1","line":"624","lineLength":"0","path":"mercurial\/dispatch.py","diffId":"6523","author":"dploch","id":"43408","dateCreated":"1520292544","dateModified":"1520292544"},{"type":"inline","comment":"Ah, makes sense. See if this addresses that case satisfactorily - it still has the caveat of not being able to \"reset\" container types, but that's true of the command line as well (if you have a list flag with a non-empty default, there's no way to remove that default item).","replyTo":"42770","isNewFile":"1","line":"624","lineLength":"0","path":"mercurial\/dispatch.py","diffId":"6523","author":"rdamazio","id":"43071","dateCreated":"1520195950","dateModified":"1520195950"},{"type":"update","diffId":"6609","author":"rdamazio","id":"43064","dateCreated":"1520195818","dateModified":"1520195818"},{"type":"inline","comment":"IIUC, an extension author may implement its own customopt subclasses, and\nput them into the command table, so we can't make ui.configtyped to\nsupport all of them.","replyTo":"42686","isNewFile":"1","line":"624","lineLength":"0","path":"mercurial\/dispatch.py","diffId":"6523","author":"yuja","id":"42770","dateCreated":"1520183736","dateModified":"1520183736"},{"type":"inline","comment":"You're right, I had the plain logic inverted in my head. Removed.","replyTo":"42581","isNewFile":"1","line":"390","lineLength":"0","path":"mercurial\/ui.py","diffId":"6523","author":"rdamazio","id":"42687","dateCreated":"1520181261","dateModified":"1520181261"},{"type":"inline","comment":"The issue is that customopt (and all its children) assume the value type is already the correct one, and thus do not perform any conversion. Since we're parsing values from the config file, the conversion is desired to ensure they don't all end up as text - the config{bool,int,etc} methods called by configtyped perform the proper conversion. In most cases (all commands that declare default values) no conversio is needed since those already have the correct type.\n","replyTo":"42582","isNewFile":"1","line":"624","lineLength":"0","path":"mercurial\/dispatch.py","diffId":"6523","author":"rdamazio","id":"42686","dateCreated":"1520181261","dateModified":"1520181261"},{"type":"update","diffId":"6548","author":"rdamazio","id":"42684","dateCreated":"1520181250","dateModified":"1520181250"},{"type":"inline","comment":"Maybe this type conversion can be a `fancyopt.customopt` method since we've\nrefactored the default handling by D2090?\n\n```\n# no idea if _defaultopt() should be made public or the whole commands.default handling\n# should be moved to fancyopts\nx = fancyopts._defaultopt(olddefault)\nnewdefault = x.configdefault(ui, cmd, optname, ...)\n```\n\n@dploch, any suggestions?","replyTo":null,"isNewFile":"1","line":"624","lineLength":"0","path":"mercurial\/dispatch.py","diffId":"6523","author":"yuja","id":"42582","dateCreated":"1520173297","dateModified":"1520173297"},{"type":"inline","comment":"Perhaps this is noop since `[commands]` is removed at all if `ui.plain()` returns True.","replyTo":null,"isNewFile":"1","line":"390","lineLength":"0","path":"mercurial\/ui.py","diffId":"6523","author":"yuja","id":"42581","dateCreated":"1520173297","dateModified":"1520173297"},{"type":"reject","author":"yuja","id":"42578","dateCreated":"1520173297","dateModified":"1520173297"},{"type":"comment","comment":"FYI this is a change I had previously sent to the list as 60b3222e01f96f91ece7eda9681a89bf3bb930a6, and Yuya reviewed . I just had never followed up on it.","author":"rdamazio","id":"42436","dateCreated":"1520122245","dateModified":"1520122245"},{"type":"update","diffId":"6523","author":"rdamazio","id":"42435","dateCreated":"1520121514","dateModified":"1520121514"},{"type":"update","diffId":"6521","author":"rdamazio","id":"42421","dateCreated":"1520121282","dateModified":"1520121282"}],"dateCreated":"1520121282","dateModified":"1522132208","status":"Needs Review"},{"id":"2057","callsign":"HG","title":"rust implementation of hg status","author":"Ivzhh","summary":"* implementation of revlog v1\n* parsing changelog, manifest, dirstate\n* use .hgignore in repo root\n* comparable performance with current hg status (Linux & Mac: slightly faster, Windows: slightly slower)\n* use hg r-status as subcommand, in this case, bypass python engine","testPlan":"","lineCount":"3066","dependsOn":[],"reviewers":["kevincox"],"ccs":["quark","yuja","glandium","krbullock","indygreg","durin42","kevincox","mercurial-devel"],"actions":[{"type":"inline","comment":"I meant safe not as it it didn't need the unsafe keyword, but in that the use of the `unsafe` block is safe.\n\nIt should really be called the `trust_me,_I_know_this_is_safe` block. But since you are not getting the compiler checking it is often useful to add a comment why the action you are performing is correct. In this case it is correct because the caller initializes this variable before the function is called.","replyTo":"46950","isNewFile":"1","line":"91","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"47428","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"Actually I didn't realize that RwLock doesn't get a regular `get()` since it is doing a compile time borrow check. https:\/\/doc.rust-lang.org\/std\/sync\/struct.RwLock.html#method.get_mut. My mistake, the code is fine.","replyTo":"46960","isNewFile":"1","line":"136","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"47427","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"Does it make sense to make `DirStateEntry.mtime` be a `std::time::SystemTime` and convert upon reading the structure in?\n\nIf not I would prefer doing the conversion here:\n\n```\nelse if mtd.modified().unwrap() == UNIX_EPOCH + Duration::from_secs(dir_entry.mtime as u64) {\n```\n\n(Maybe extract the system time to higher up, or even a helper function on dir_entry)","replyTo":null,"isNewFile":"1","line":"263","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"7188","author":"kevincox","id":"47426","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"Sorry, I misunderstood the logic. You can do this:\n\n```\ndiff -r ccc683587fdb rust\/hgstorage\/src\/dirstate.rs\n--- a\/rust\/hgstorage\/src\/dirstate.rs\tSat Mar 24 10:05:53 2018 +0000\n+++ b\/rust\/hgstorage\/src\/dirstate.rs\tSat Mar 24 10:14:58 2018 +0000\n@@ -184,8 +184,7 @@\n                         continue;\n                     }\n \n-                    if self.dir_state_map.contains_key(rel_path) {\n-                        let dir_entry = &self.dir_state_map[rel_path];\n+                    if let Some(dir_entry) = self.dir_state_map.get(rel_path) {\n                         files_not_in_walkdir.remove(rel_path);\n                         DirState::check_status(&mut res, abs_path, rel_path, dir_entry);\n                     } else if !matcher.check_path_ignored(rel_path.to_str().unwrap()) {\n```","replyTo":"46959","isNewFile":"1","line":"170","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"47425","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"Switch the return type to `std::io::Result` and then you can have\n\n```\nlet metadata = p.metadata()?;\nlet mtime = metadata.modified()?;\n\/\/ ...\n```","replyTo":null,"isNewFile":"1","line":"103","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"7188","author":"kevincox","id":"47424","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"A link to the mentioned wiki page would be very helpful to readers.","replyTo":null,"isNewFile":"1","line":"50","lineLength":"0","path":"rust\/hgstorage\/src\/config.rs","diffId":"7188","author":"kevincox","id":"47423","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"These are `HashSet`'s which don't have a defined iterator order. IIRC the python implementation sorts the results which is probably desirable.","replyTo":null,"isNewFile":"1","line":"260","lineLength":"0","path":"rust\/hgcli\/src\/main.rs","diffId":"7188","author":"kevincox","id":"47422","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"If this computation only depends on `len` it would be nice to put it in a helper function.","replyTo":null,"isNewFile":"1","line":"105","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"7188","author":"kevincox","id":"47421","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"inline","comment":"I get that, but I still think it makes the code easier to read when the python-interop and the logic as separated where it is easy to do so.","replyTo":"46947","isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"47420","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"comment","comment":"The latest changes are looking really good. I have a couple more comments but I didn't have time for a full review. I'll try to get more reviewed tomorrow. It seems that you still have a lot of stuff still in-flight so I'll try to slowly review the changes as I have time. If you want input\/feedback on any particular part just ask and I will prioritize it.\n\nThis change is very large so it might be worth splitting off a smaller component and getting that submitted first. However I do realize that for starting out it is often helpful to get some actual use cases implemented before committing the base structures.","author":"kevincox","id":"47419","dateCreated":"1521888284","dateModified":"1521888284"},{"type":"comment","comment":">>! In D2057#46980, @Ivzhh wrote:\n>>>! In D2057#46726, @yuja wrote:\n>>>> I think the only place where you would need to do os-specific code is when\n>>>> doing serialization and serialization\n>>> \n>>> Yes, that will be feasible in strictly typed language like Rust.\n>> \n>> To be clear, I meant serialization\/deserialization between filesystem path and\n>> internal dirstate\/manifest path, not between dirstate storage and in-memory\n>> dirstate object.\n> \n> I guess your suggestion is like this: @yuja\n> \n> 1. if it is windows and the code page is MBCS, try to decode the paths read from manifest and dirstate into unicode equivalent\n> 2. use utf internally and with rust IO api\n> 3. when writing back to dirstate and manifest, encode utf to MBCS\n\nNo. My suggestion is:\n\n1. keep manifest\/dirstate paths as bytes (which are probably wrapped by some type, say HgPath)\n2. but we want to use Rust's standard library for I\/O\n3. so, add utility function\/trait to convert HgPath to Path\/PathBuf, where MBCS-Wide conversion\n   will occur.\n\nI think raw byte paths will be needed to build store paths (e.g. `.hg\/store\/data\/~2eclang-format.i`).\n\nhttps:\/\/www.mercurial-scm.org\/repo\/hg\/file\/4.5.2\/mercurial\/store.py","author":"yuja","id":"47287","dateCreated":"1521730814","dateModified":"1521730814"},{"type":"comment","comment":">>! In D2057#46726, @yuja wrote:\n>>> I think the only place where you would need to do os-specific code is when\n>>> doing serialization and serialization\n>> \n>> Yes, that will be feasible in strictly typed language like Rust.\n> \n> To be clear, I meant serialization\/deserialization between filesystem path and\n> internal dirstate\/manifest path, not between dirstate storage and in-memory\n> dirstate object.\n\nI guess your suggestion is like this: @yuja\n\n1. if it is windows and the code page is MBCS, try to decode the paths read from manifest and dirstate into unicode equivalent\n2. use utf internally and with rust IO api\n3. when writing back to dirstate and manifest, encode utf to MBCS\n\nPlease let me know if I have misunderstanding. Thank you!","author":"Ivzhh","id":"46981","dateCreated":"1521662441","dateModified":"1521662461"},{"type":"inline","comment":"I guess I did this because I met some empty change delta in the beginning. I think I won't try to parallelize unzip for now.","replyTo":"43866","isNewFile":"1","line":"290","lineLength":"3","path":"rust\/hgstorage\/src\/revlog_v1.rs","diffId":"6724","author":"Ivzhh","id":"46964","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I think it explains why in mercurial repo, rust version is significantly faster. I am working on cpu future, but I did not finalize design style yet. I will keep working on that.","replyTo":"43867","isNewFile":"1","line":"279","lineLength":"0","path":"rust\/hgstorage\/src\/revlog_v1.rs","diffId":"6724","author":"Ivzhh","id":"46963","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"This part, including the stream-style, is from python part. I will update later with xi-rope.","replyTo":"43969","isNewFile":"1","line":"51","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"Ivzhh","id":"46962","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I borrow this logic as whole from python code. It will need sometime to re-translate to non-pointer-arithmetic way.","replyTo":"43949","isNewFile":"1","line":"14","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"Ivzhh","id":"46961","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I think LRU will update reference count (or timestamp) when the data is accessed.","replyTo":"43942","isNewFile":"1","line":"136","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"Ivzhh","id":"46960","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I kind of get borrow check compile error here. Later I use Occupied() when possible.","replyTo":"43930","isNewFile":"1","line":"170","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"Ivzhh","id":"46959","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I add the error handling back","replyTo":"43923","isNewFile":"1","line":"161","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"Ivzhh","id":"46958","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"For the filter, I follow the example in the walkdir doc. I guess what I want is to skip the dir for later recursive visiting. ","replyTo":"43921","isNewFile":"1","line":"152","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"Ivzhh","id":"46957","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I think dir state needs to 1. read existing one; 2. create one if not exits; maybe private for now.","replyTo":"43916","isNewFile":"1","line":"108","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"Ivzhh","id":"46956","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I remember the python hg uses the name, in the beginning, I tried to replicate py-hg's behaviour. But I think it needs to be renamed. I agree with you.","replyTo":"43928","isNewFile":"1","line":"48","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"Ivzhh","id":"46955","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I like to_owned(), I will them in later occasions. Thank you!","replyTo":"43913","isNewFile":"1","line":"78","lineLength":"0","path":"rust\/hgstorage\/src\/config.rs","diffId":"6724","author":"Ivzhh","id":"46954","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"Sure, I will use v1 only for now. In the beginning I kinda over designed this part.","replyTo":"43865","isNewFile":"1","line":"95","lineLength":"0","path":"rust\/hgstorage\/src\/config.rs","diffId":"6724","author":"Ivzhh","id":"46953","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I guess I will use the rest info later. hg seems put some meta data in the commit comments. I will keep it for now. Thank you!","replyTo":"43911","isNewFile":"1","line":"31","lineLength":"0","path":"rust\/hgstorage\/src\/changelog.rs","diffId":"6724","author":"Ivzhh","id":"46952","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"Thank you for the suggestion! I guess I need to extend clap later to support hg style command line. Right now whenever clap cannot handle the argument parsing, I will redirect the arguments to hg directly.","replyTo":"43864","isNewFile":"1","line":"233","lineLength":"28","path":"rust\/hgcli\/src\/main.rs","diffId":"6724","author":"Ivzhh","id":"46951","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"when I removed the unsafe, I got error: error[E0133]: use of mutable static requires unsafe function or block","replyTo":"43908","isNewFile":"1","line":"91","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"Ivzhh","id":"46950","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"I guess it is because NLL. When I started the work, rust compiler reported borrow check error on this part. I later read an article talking about NLL update in rust. But before that, I use the braces to avoid the error.","replyTo":"43901","isNewFile":"1","line":"46","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"Ivzhh","id":"46949","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"pad is a bool, however when I checked it in hg-python, int are passed to the function. I guess I need to update cpython wrapper for this, a more broad logic conversion.","replyTo":"43900","isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"Ivzhh","id":"46948","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"This crate is my previous try to integrate rust into hg. Right now I guess mine main pursue is to add hg r-* commands for rust. I will follow your suggestion when I am implementing the wire protocol and reuse the code for pure rust crate.","replyTo":"43897","isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"Ivzhh","id":"46947","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"inline","comment":"It should be any &[u8], but the current cpython crate doesn't wrap for &[u8]. I think I need to fork and add that part. I put it in my checklist now.","replyTo":"43898","isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"Ivzhh","id":"46946","dateCreated":"1521658541","dateModified":"1521658541"},{"type":"comment","comment":"  - add revlog and mpatch facilities\n  - add changelog parsing\n  - add manifest parsing\n  - path encoding for data store\n  - add dirstate and matcher facilities\n  - add local repository and the supporting modules\n  - use cargo fmt to format code\n  - add hg r-status command\n  - bincode 1.0.0 is a bit slow in my test\n  - delay pattern matching during dir walk\n  - optimize out trie and enable CoreXL profiling\n  - use hashmap\n  - remove thread pool\n  - rust default read is not buf-ed, this is the key of slowness\n  - change to globset\n  - convert glob to regex\n  - hg ignore patterns are all converted to regex (as hg does), and now it is faster\n  - filter dir early to prevent walking\n  - Update matcher mod after testing Mozilla unified repo\n  - bug fix: use byte literals instead of numbers\n  - hg store path encoding is per byte style, update code according to Kevin Cox's comments\n  - update matcher testing according to Match interface change\n  - If clap fails to recognize r-* subcommands, then run python-version hg\n  - changelog coding style revised\n  - remove legacy revlog v0 and unfinished v2.\n  - partially revise the dirstate reviews\n  - remove duplicated build.rs, let the executable module guarantee the python\n  - use cursor in base85 encoding, reducing raw index-math\n  - use cursor in base85 decoding, reducing raw index-math\n  - dirstate update according to review comments\n  - config update according to review comments\n  - mpatch rename to more meaningful names\n  - simplify matcher as when there is no syntax named in the beginning, use regexp\n  - local repo coding style update\n  - dirstate coding style update\n  - manifest coding style update\n","author":"Ivzhh","id":"46944","dateCreated":"1521656608","dateModified":"1521656608"},{"type":"update","diffId":"7188","author":"Ivzhh","id":"46942","dateCreated":"1521656608","dateModified":"1521656608"},{"type":"comment","comment":"Ah, I forgot to consider the python interop. Now the need for that crate makes sense. Thanks for explaining.","author":"kevincox","id":"46733","dateCreated":"1521627628","dateModified":"1521627628"},{"type":"comment","comment":">> I think the only place where you would need to do os-specific code is when\n>> doing serialization and serialization\n> \n> Yes, that will be feasible in strictly typed language like Rust.\n\nTo be clear, I meant serialization\/deserialization between filesystem path and\ninternal dirstate\/manifest path, not between dirstate storage and in-memory\ndirstate object.","author":"yuja","id":"46726","dateCreated":"1521613817","dateModified":"1521613817"},{"type":"comment","comment":"> I think the only place where you would need to do os-specific code is when\n> doing serialization and serialization\n\nYes, that will be feasible in strictly typed language like Rust.\n\n> which I think should be handled by https:\/\/doc.rust-lang.org\/std\/os\/unix\/ffi\/trait.OsStringExt.html\n> and https:\/\/doc.rust-lang.org\/std\/os\/windows\/ffi\/trait.OsStringExt.html.\n\nNot true for Windows because Rust uses Unicode (UTF-16-ish) API, whereas\nPython 2 does ANSI. We need to convert a \"wide\" string to a locale-dependent string.\n\nMaybe the local-encoding crate will do that for us?\n\n","author":"yuja","id":"46723","dateCreated":"1521607475","dateModified":"1521607475"},{"type":"comment","comment":"I'm not a windows expert but it seems like the rust OsStr, Path and filesystem APIs should handle these conversions for you. I think the only place where you would need to do os-specific code is when doing serialization and serialization which I think should be handled by https:\/\/doc.rust-lang.org\/std\/os\/unix\/ffi\/trait.OsStringExt.html and https:\/\/doc.rust-lang.org\/std\/os\/windows\/ffi\/trait.OsStringExt.html.","author":"kevincox","id":"46685","dateCreated":"1521577349","dateModified":"1521577349"},{"type":"comment","comment":"https:\/\/crates.io\/crates\/local-encoding seems to be the right choice.","author":"quark","id":"46681","dateCreated":"1521573831","dateModified":"1521573831"},{"type":"comment","comment":"> I am looking at Mozilla's rust winapi bindings, let me see if I can directly wrap around [winapi::um::fileapi::FindFirstFileA](https:\/\/docs.rs\/winapi\/*\/x86_64-pc-windows-msvc\/winapi\/um\/fileapi\/fn.FindFirstFileA.html)\n\nThat's probably a hard way. I was thinking of something converting\nbetween OsStr (i.e. Path) and MBCS bytes by using Win32 API, instead\nof calling out the \"A\" API.\n\nhttps:\/\/msdn.microsoft.com\/en-us\/library\/windows\/desktop\/dd319072(v=vs.85).aspx\n\nWe don't do that in Python, but Rust's type system will help making it right.","author":"yuja","id":"44688","dateCreated":"1520680806","dateModified":"1520680806"},{"type":"comment","comment":">>! In D2057#44269, @yuja wrote:\n>>> Reading that page it seems to claim that filenames should be utf8, not bytes. If utf8, this is what the code does, but if it is bytes that definitely won't work.\n>> \n>> IIRC it's bytes everyplace except Windows, where we pretend utf8 is real?\n> \n> It's MBCS (i.e. ANSI multi-byte characters) on Windows. The plain was to support\n> both MBCS and UTF-8-variant on Windows, but that isn't a thing yet.\n> \n> Perhaps we'll have to write a platform compatibility layer (or serialization\/deserialization\n> layer) on top of the Rust's file API, something like vfs.py we have in Python code.\n\nThank you for confirming that, I am a bit confusing when I read Encoding Plan wiki page. I am looking at Mozilla's rust winapi bindings, let me see if I can directly wrap around [winapi::um::fileapi::FindFirstFileA](https:\/\/docs.rs\/winapi\/*\/x86_64-pc-windows-msvc\/winapi\/um\/fileapi\/fn.FindFirstFileA.html)","author":"Ivzhh","id":"44295","dateCreated":"1520618349","dateModified":"1520618349"},{"type":"comment","comment":">> Reading that page it seems to claim that filenames should be utf8, not bytes. If utf8, this is what the code does, but if it is bytes that definitely won't work.\n> \n> IIRC it's bytes everyplace except Windows, where we pretend utf8 is real?\n\nIt's MBCS (i.e. ANSI multi-byte characters) on Windows. The plain was to support\nboth MBCS and UTF-8-variant on Windows, but that isn't a thing yet.\n\nPerhaps we'll have to write a platform compatibility layer (or serialization\/deserialization\nlayer) on top of the Rust's file API, something like vfs.py we have in Python code.","author":"yuja","id":"44270","dateCreated":"1520598781","dateModified":"1520598781"},{"type":"comment","comment":"Hi everyone,\n\nThank you for your encouragements and comments! I will follow up with all comments and update the code soon.\n\n@indygreg It is a great idea to test on Mozilla repo, actually I found several things interesting:\n\n1. I found a bug in my code (shame on me): because I did not use byte literal, and I made a typo. This triggers problem in Mozilla unified repo\n2. A regexp pattern in hgignore in Mozilla unified repo is not supported by rust's regex crate, a.k.a. \"(?!)\". I choose to ignore these unsupported patterns.\n3. My version is slower in this repo: 70s (hg) and 90s (mine). CodeXL reveals that the mpatch::collect() function uses 63% of the running time. I think I need to optimize it somehow.\n\nI totally agree with @kevincox that I did not sort well on char\/u8\/str\/String\/Path\/PathBuf. The first bug is caused by this. I need to improve them.\n\nThank you everyone!","author":"Ivzhh","id":"44180","dateCreated":"1520558265","dateModified":"1520558265"},{"type":"comment","comment":"Rust has platform independent types [[ https:\/\/doc.rust-lang.org\/stable\/std\/path\/struct.PathBuf.html | `PathBuf` ]] and [[ https:\/\/doc.rust-lang.org\/stable\/std\/path\/struct.Path.html | `&Path` ]] for paths and [[ https:\/\/doc.rust-lang.org\/stable\/std\/ffi\/struct.OsString.html | `OsString` ]] and [[ https:\/\/doc.rust-lang.org\/stable\/std\/ffi\/struct.OsStr.html | `&OsStr` ]] for strings (owned and references respectively. They do have os-specific extensions but as long as you don't use them it should be cross platform. That being said, if you are serializing and deserializing them you may need to write some platform dependant code.","author":"kevincox","id":"43991","dateCreated":"1520536377","dateModified":"1520536377"},{"type":"comment","comment":">>! In D2057#43989, @durin42 wrote:\n>>>! In D2057#43988, @kevincox wrote:\n>>>>! In D2057#43987, @durin42 wrote:\n>>> \n>>> Mercurial tries to be principled about always treating filenames as bytes. AIUI https:\/\/www.mercurial-scm.org\/wiki\/WindowsUTF8Plan is still the plan of record there?\n>> \n>> Reading that page it seems to claim that filenames should be utf8, not bytes. If utf8, this is what the code does, but if it is bytes that definitely won't work.\n> \n> IIRC it's bytes everyplace except Windows, where we pretend utf8 is real?\n> \n> We may have to make adjustments to this plan on macOS with APFS, but I'm not sure about that yet.\n\nI think we want to express a path as a dedicated type which has different underlying storage depending on the platform (bytes on Linux, UTF-16 on Windows). All filesystem operations should take a `Path` instance to operate on. This is the only way to cleanly round trip filenames between the OS, the application, and back to the OS. That leaves us with the hard problem of normalizing Mercurial's storage representation of paths (bytes) with the operating system's. But this world is strictly better than today, where we lose path data from the OS because we use POSIX APIs.\n\nFWIW, Python 3 rewrote the I\/O layer to use Win32 APIs everywhere. Combined with the `pathlib` types, I'm pretty sure Python 3 can round trip paths on Windows. I also think Rust's path type(s) have OS-dependent functionality.","author":"indygreg","id":"43990","dateCreated":"1520534077","dateModified":"1520534077"},{"type":"comment","comment":">>! In D2057#43988, @kevincox wrote:\n>>>! In D2057#43987, @durin42 wrote:\n>> \n>> Mercurial tries to be principled about always treating filenames as bytes. AIUI https:\/\/www.mercurial-scm.org\/wiki\/WindowsUTF8Plan is still the plan of record there?\n> \n> Reading that page it seems to claim that filenames should be utf8, not bytes. If utf8, this is what the code does, but if it is bytes that definitely won't work.\n\nIIRC it's bytes everyplace except Windows, where we pretend utf8 is real?\n\nWe may have to make adjustments to this plan on macOS with APFS, but I'm not sure about that yet.","author":"durin42","id":"43989","dateCreated":"1520533145","dateModified":"1520533145"},{"type":"comment","comment":">>! In D2057#43987, @durin42 wrote:\n> \n> Mercurial tries to be principled about always treating filenames as bytes. AIUI https:\/\/www.mercurial-scm.org\/wiki\/WindowsUTF8Plan is still the plan of record there?\n\nReading that page it seems to claim that filenames should be utf8, not bytes. If utf8, this is what the code does, but if it is bytes that definitely won't work.","author":"kevincox","id":"43988","dateCreated":"1520532520","dateModified":"1520532520"},{"type":"comment","comment":">>! In D2057#43892, @kevincox wrote:\n> On a higher level, all of these code appears to be treating file names as strings. This isn't really true and will disallow some valid file names. Maybe we should stick with bytes throughout. Of course this makes windows filepaths difficult because they are actually (utf16) strings.\n\nMercurial tries to be principled about always treating filenames as bytes. AIUI https:\/\/www.mercurial-scm.org\/wiki\/WindowsUTF8Plan is still the plan of record there?","author":"durin42","id":"43987","dateCreated":"1520531899","dateModified":"1520531899"},{"type":"inline","comment":"Take a `&str`.","replyTo":null,"isNewFile":"1","line":"62","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43985","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nfn escape(out: &mut String, b: char) {\n    unimplemented!()\n}\n\npub fn encode_path(path: &str) -> String {\n    let mut out = String::with_capacity(path.len());\n\n    for c in path.bytes() {\n        let c = c as char;\n        match c {\n            'A'...'Z' => {\n                out.push('_');\n                out.push(c.to_ascii_lowercase());\n            }\n            '\\\\' | ':' | '*' | '?' | '\"' | '<' | '>' | '|' => {\n                escape(&mut out, c);\n            }\n            \/\/ The rest of the printable range.\n            ' '...'~' => {\n                out.push(c);\n            }\n            _ => {\n                escape(&mut out, c);\n            }\n        }\n    }\n\n    out\n}\n```\nhttps:\/\/godbolt.org\/g\/3WCQs3","replyTo":null,"isNewFile":"1","line":"57","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43984","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Don't pass a `char` by reference. Also it seems your function wants a `u8`.","replyTo":null,"isNewFile":"1","line":"11","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43983","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Use a String.","replyTo":null,"isNewFile":"1","line":"35","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43982","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`encode_file_name`?","replyTo":null,"isNewFile":"1","line":"34","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43981","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Take a `&str`","replyTo":null,"isNewFile":"1","line":"34","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43980","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\np.ends_with(\".i\") || p.ends_with(\".d\")\n```","replyTo":null,"isNewFile":"1","line":"25","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43979","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"This isn't necessary.","replyTo":null,"isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43978","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I don't think you need this.","replyTo":null,"isNewFile":"1","line":"22","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43977","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`Vec<char>` is odd. Is there any reason not to use a `String` or `Vec<u8>`","replyTo":null,"isNewFile":"1","line":"11","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43976","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"c should be a `u8`.","replyTo":null,"isNewFile":"1","line":"7","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43975","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"const HEX_DIGIT: [u8; 16] = *b\"0123456789abcdef\";","replyTo":null,"isNewFile":"1","line":"5","lineLength":"0","path":"rust\/hgstorage\/src\/path_encoding.rs","diffId":"6724","author":"kevincox","id":"43974","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nassert!(!frags.is_empty());\n```","replyTo":null,"isNewFile":"1","line":"137","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43973","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Please explain.","replyTo":null,"isNewFile":"1","line":"120","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43972","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Make this one line and don't bother renaming.","replyTo":null,"isNewFile":"1","line":"86","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43971","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nfor &Fragment{frag_len, frag_ofs} in list.iter().rev()\n```","replyTo":null,"isNewFile":"1","line":"68","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43970","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"It seems weird to take a cursor to a vec if you are just going to do an absolute seek. Can it work with `&mut [u8]`?","replyTo":null,"isNewFile":"1","line":"51","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43969","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`vec![0; count]` works. (The arguments might be the other way around).","replyTo":null,"isNewFile":"1","line":"54","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43968","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`mov` is overly shortened and generic.","replyTo":null,"isNewFile":"1","line":"51","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43967","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`pull` is very generic.","replyTo":null,"isNewFile":"1","line":"35","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43966","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nstruct Fragment {\n    len: u32,\n    offset: u32,\n}\n```","replyTo":null,"isNewFile":"1","line":"24","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43965","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/f\/fragment\/","replyTo":null,"isNewFile":"1","line":"40","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43964","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"If you are unwrapping the `pop` there is no need for the prior check.","replyTo":null,"isNewFile":"1","line":"40","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43963","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Maybe it's just me but I think it is more common to put the source before the destination.","replyTo":null,"isNewFile":"1","line":"35","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43962","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nassert!(!src.is_empty())\n```","replyTo":null,"isNewFile":"1","line":"39","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43961","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Spell these out please.","replyTo":null,"isNewFile":"1","line":"13","lineLength":"0","path":"rust\/hgstorage\/src\/mpatch.rs","diffId":"6724","author":"kevincox","id":"43960","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would do `self.inner.map(|m| m.is_match(rp)).unwrap_or(false)` but this is fine.","replyTo":null,"isNewFile":"1","line":"200","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43959","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/rp\/path\/","replyTo":null,"isNewFile":"1","line":"195","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43958","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/relglob\/relative_glob_re\/","replyTo":null,"isNewFile":"1","line":"108","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43957","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Is this a warning or error? You might want to switch to `panic!`.","replyTo":null,"isNewFile":"1","line":"159","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43956","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would move this into the following match because it dedupes the `starts_with` check and puts the logic closer together.","replyTo":null,"isNewFile":"1","line":"160","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43955","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/ln\/line\/","replyTo":null,"isNewFile":"1","line":"143","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43954","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Better name please.","replyTo":null,"isNewFile":"1","line":"131","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43953","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"You should be able to do `&string` rather then `string.as_str()` as it coerces. ","replyTo":null,"isNewFile":"1","line":"111","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43952","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"If you are just doing one call just return the result.","replyTo":null,"isNewFile":"1","line":"111","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43951","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"If you are going to call `String.as_str()` just take a `&str`.","replyTo":null,"isNewFile":"1","line":"108","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43950","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Can you manage a `&[u8]` rather then pointer arithmetic for the whole string. It will make me feel better and will probably be easier to read.","replyTo":null,"isNewFile":"1","line":"14","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43949","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Might be worth calling `String::with_capacity(pat.len())` since it will be at least that long.","replyTo":null,"isNewFile":"1","line":"10","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43948","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/pat\/glob\/","replyTo":null,"isNewFile":"1","line":"9","lineLength":"0","path":"rust\/hgstorage\/src\/matcher.rs","diffId":"6724","author":"kevincox","id":"43947","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"What are these numbers?","replyTo":null,"isNewFile":"1","line":"49","lineLength":"0","path":"rust\/hgstorage\/src\/manifest.rs","diffId":"6724","author":"kevincox","id":"43946","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/ent\/entry\/","replyTo":null,"isNewFile":"1","line":"42","lineLength":"0","path":"rust\/hgstorage\/src\/manifest.rs","diffId":"6724","author":"kevincox","id":"43945","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"What are these magic numbers?","replyTo":null,"isNewFile":"1","line":"33","lineLength":"0","path":"rust\/hgstorage\/src\/manifest.rs","diffId":"6724","author":"kevincox","id":"43944","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"This test has no assetions. Consider calling it `test_create_...` or something to indicate that you are just checking for panics.","replyTo":null,"isNewFile":"1","line":"155","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43943","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Why does it need to be mutable to clone?","replyTo":null,"isNewFile":"1","line":"136","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43942","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/fp\/path\/","replyTo":null,"isNewFile":"1","line":"121","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43941","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`gd` is cryptic.","replyTo":null,"isNewFile":"1","line":"129","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43940","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nassert!(abspath.exists(), \"path not exists: {:?}\", abspath);\n```","replyTo":null,"isNewFile":"1","line":"127","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43939","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nwhile !root.join(\".hg\").exists() {\n    root = root.parent().expect(\".hg folder not found\");\n}\n```","replyTo":null,"isNewFile":"1","line":"66","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43938","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would replace the condition with.\n\n```\nassert!(dot_hg_path.exists(), \".hg folder not found for the path given by -R argument: {:?}\", p);\n```","replyTo":null,"isNewFile":"1","line":"50","lineLength":"0","path":"rust\/hgstorage\/src\/local_repo.rs","diffId":"6724","author":"kevincox","id":"43937","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"You can add a later `.arg(dst)` to support non-utf8 paths instead of converting to a str here.","replyTo":null,"isNewFile":"1","line":"54","lineLength":"0","path":"rust\/hgstorage\/src\/lib.rs","diffId":"6724","author":"kevincox","id":"43936","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"In rust we generally avoid brackets around `as` as it is very tightly binding.","replyTo":null,"isNewFile":"1","line":"206","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43935","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Please use a better name for `sent`.","replyTo":null,"isNewFile":"1","line":"199","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43934","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"You can use the entry api here.","replyTo":null,"isNewFile":"1","line":"184","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43933","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/rem\/path\/ or remaining_path.","replyTo":null,"isNewFile":"1","line":"183","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43932","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Use an `else if`.","replyTo":null,"isNewFile":"1","line":"175","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43931","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"You could do the following for a slight performance win and save a line.\n\n```\nif let Occupied(entry) = self.dmap.entry(relpath) {\n   ...\n}\n```","replyTo":null,"isNewFile":"1","line":"170","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43930","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I recommend not renaming this. It is confusing.","replyTo":null,"isNewFile":"1","line":"5","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43929","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"This could have a better name.","replyTo":null,"isNewFile":"1","line":"48","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43928","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```\nlet mut grey = Set::new();\ngrey.extend(self.dmap.keys().map(|s| s.as_path()));\n```\n\nAlso I would pick a name like `undiscovered_paths` or something. `grey` is cryptic.","replyTo":null,"isNewFile":"1","line":"146","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43927","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would also put this filter above. But more importantly all `_is_bad()` does is check for file types. So it seems like the former filter is redundant with this one.","replyTo":null,"isNewFile":"1","line":"169","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43926","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would move this filter beside the filter in the loop.","replyTo":null,"isNewFile":"1","line":"167","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43925","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would just call this `path` or `pathbuf`.","replyTo":null,"isNewFile":"1","line":"162","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43924","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Please explain why you are ignoring the error condition.","replyTo":null,"isNewFile":"1","line":"161","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43923","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"This is probably worth a helper function.","replyTo":null,"isNewFile":"1","line":"155","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43922","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would prefer doing the filter before the loop and storing it in a variable.","replyTo":null,"isNewFile":"1","line":"152","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43921","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"s\/mtc\/matcher\/","replyTo":null,"isNewFile":"1","line":"141","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43920","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Don't use `_` prefix for privates. Rely on rust viability. \n\nAlso `is_bad` isn't very informative.","replyTo":null,"isNewFile":"1","line":"130","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43919","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Is ignoring duplicate entries desired? It might be worth a comment explaining why.","replyTo":null,"isNewFile":"1","line":"125","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43918","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"This should Probably return a `Result<Self>` and pass the error to the caller.","replyTo":null,"isNewFile":"1","line":"87","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43917","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"1. Does this function need to be public? It seems internal to the constructor.\n1. If it doesn't need to be I would prefer it return the Map so that you don't have a partial-constructed DirState.","replyTo":null,"isNewFile":"1","line":"108","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43916","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"I would skip this check and rely on `p.metadata()`. Just switch `.unwrap()` to `.expect()` with a nicer message. This also handles race conditions more nicely.","replyTo":null,"isNewFile":"1","line":"90","lineLength":"0","path":"rust\/hgstorage\/src\/dirstate.rs","diffId":"6724","author":"kevincox","id":"43915","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Is this used yet? It probably also needs some documentation because I don't really understand the fields (but I do have little domain knowledge).","replyTo":null,"isNewFile":"1","line":"49","lineLength":"0","path":"rust\/hgstorage\/src\/config.rs","diffId":"6724","author":"kevincox","id":"43914","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"If you are just going to convert to String I would recommend taking a String argument.\n\nAlso prefer `.to_owned()` over `.to_string()`.","replyTo":null,"isNewFile":"1","line":"78","lineLength":"0","path":"rust\/hgstorage\/src\/config.rs","diffId":"6724","author":"kevincox","id":"43913","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Just put `msg: content` in the struct construction.","replyTo":null,"isNewFile":"1","line":"33","lineLength":"0","path":"rust\/hgstorage\/src\/changelog.rs","diffId":"6724","author":"kevincox","id":"43912","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"If you aren't using the value I would prefer `truncate(NodeId::hex_len())`","replyTo":null,"isNewFile":"1","line":"31","lineLength":"0","path":"rust\/hgstorage\/src\/changelog.rs","diffId":"6724","author":"kevincox","id":"43911","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Passing a message as a third argument is really useful.","replyTo":null,"isNewFile":"1","line":"24","lineLength":"0","path":"rust\/hgstorage\/src\/changelog.rs","diffId":"6724","author":"kevincox","id":"43910","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"Let rust do the overflow checking.\n\n```\nacc = acc.checked_mul(85)\n    .ok_or_else(|| {\n        PyErr::new::<exc::ValueError, _>(\n            py,\n            format!(\"bad base85 character at position {}\", i))\n    })?;","replyTo":null,"isNewFile":"1","line":"152","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43909","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"This is probably worth a comment that this is safe because D85DEC is required to be initialized before this function is called.","replyTo":null,"isNewFile":"1","line":"91","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43908","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"```while !ptext.is_empty()```","replyTo":null,"isNewFile":"1","line":"52","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43907","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"It might be best to use a [[ https:\/\/doc.rust-lang.org\/stable\/std\/io\/struct.Cursor.html | `std::io::Cursor` ]] and let it drack `dst_off` for your.","replyTo":null,"isNewFile":"1","line":"47","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43906","dateCreated":"1520530210","dateModified":"1520530210"},{"type":"inline","comment":"`ptext` isn't very descriptive. ","replyTo":null,"isNewFile":"1","line":"45","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43905","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"Tracking len manually is a smell. Why not drop it and use `ptest.is_empty()`.","replyTo":null,"isNewFile":"1","line":"63","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43904","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"I would prefer the name `chunk` or even `accum` is a lot mode obvious to me than `acc`.","replyTo":null,"isNewFile":"1","line":"54","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43903","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"I suspect this type annotation isn't required.","replyTo":null,"isNewFile":"1","line":"47","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43902","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"Why the braces here?","replyTo":null,"isNewFile":"1","line":"46","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43901","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"IIUC pad is only ever checked `== 0`. Can it be made into a bool?","replyTo":null,"isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43900","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"I would just combine these into one line as the name `ch` isn't adding much.","replyTo":null,"isNewFile":"1","line":"58","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43899","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"`&str` can only hold valid utf8 data? Does it make more sense to have `&[u8]` here for a list of bytes?","replyTo":null,"isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43898","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"Would it be possible to separate the decode from the python objects. I'm thinking two helper functions.\n\n```\nfn b85_required_len(text: &str) -> usize\nfn b85_encode(text: &str, pad: i32, out: &mut [u8]) -> Result<()>\n```\n\n","replyTo":null,"isNewFile":"1","line":"23","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43897","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"```\nfor i in &[24, 16, 8, 0]\n```","replyTo":null,"isNewFile":"1","line":"56","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43896","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"I prefer something like this: https:\/\/play.rust-lang.org\/?gist=5ca18a5b95335600e911b8f9310ea5c7&version=stable\n\nI doubt lazy_static is too slow. Otherwise we can stay like this until const functions get implemented.\n\nEither way note:\n* I changed the type of B85CHARS to an array as opposed to an array ref.\n* The loop condition is much nicer.","replyTo":null,"isNewFile":"1","line":"21","lineLength":"0","path":"rust\/hgbase85\/src\/base85.rs","diffId":"6724","author":"kevincox","id":"43895","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"inline","comment":"If this is going to be reused I would move it into it's own crate. It seems like everything here could be boiled down to a single function call in main.","replyTo":"43863","isNewFile":"1","line":"1","lineLength":"0","path":"rust\/hgbase85\/build.rs","diffId":"6724","author":"kevincox","id":"43894","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"comment","comment":"I will try to finish the review later, but it might be quicker if you incorporate some of the changes first since a lot of them are repeated many times. Overall it looks good, there are a couple of things that i would highlight to make the code easier to read.\n\n* Prefer more descriptive variable names.\n* If you can, avoid \"pointer\" arithmetic. Cursors and slices are nice and have great convenience methods.\n* Group your flow control and filtering more.\n* Try to keep your types straight. In rust using the right types helps catch errors. So be aware of `char` vs `u8` vs `String` vs `Vec<char>` vs `Vec<u8>`.\n\nOn a higher level, all of these code appears to be treating file names as strings. This isn't really true and will disallow some valid file names. Maybe we should stick with bytes throughout. Of course this makes windows filepaths difficult because they are actually (utf16) strings.","author":"kevincox","id":"43893","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"reject","author":"kevincox","id":"43892","dateCreated":"1520530209","dateModified":"1520530209"},{"type":"comment","comment":"Doesn't mononoke have code to read revlogs already?","author":"glandium","id":"43869","dateCreated":"1520495348","dateModified":"1520495348"},{"type":"inline","comment":"IIRC, core Mercurial keeps an open file handle on revlogs and ensures we don't run out of file handles by not keeping too many revlogs open at the same time. For scanning operations, not having to open and close the file handles all the time will make a difference for performance. Also, core Mercurial loads the entirety of the `.i` file into memory. That's a scaling problem for large revlogs. But it does make performance of index lookups really fast.","replyTo":null,"isNewFile":"1","line":"279","lineLength":"0","path":"rust\/hgstorage\/src\/revlog_v1.rs","diffId":"6724","author":"indygreg","id":"43867","dateCreated":"1520494272","dateModified":"1520494272"},{"type":"inline","comment":"A thread pool to help with zlib decompression should go a long way here.\n\nProbably too early to think about this, but we'll likely eventually want a global thread pool for doing I\/O and CPU expensive tasks, such as reading chunks from a revlog and decompressing them.\n\nFWIW, we're going to radically alter the storage format in order to better support shallow clones. But that work hasn't started yet. I still think there is a benefit to implementing the revlog code in Rust though.","replyTo":null,"isNewFile":"1","line":"290","lineLength":"3","path":"rust\/hgstorage\/src\/revlog_v1.rs","diffId":"6724","author":"indygreg","id":"43866","dateCreated":"1520494272","dateModified":"1520494272"},{"type":"inline","comment":"I would not worry about supporting v0 or v2 at this time. v0 is only important for backwards compatibility with ancient repos. And v2 never got off the ground.","replyTo":null,"isNewFile":"1","line":"95","lineLength":"0","path":"rust\/hgstorage\/src\/config.rs","diffId":"6724","author":"indygreg","id":"43865","dateCreated":"1520494272","dateModified":"1520494272"},{"type":"inline","comment":"This is definitely nifty and an impressive achievement \\o\/\n\nThe `r-` commands for testing pure Rust code paths are an interesting idea!\n\nI think I'm OK with including support for this in `hgcli`. But I think the code should live in a separate file so it doesn't pollute `main()`. And it should be behind a Cargo feature flag so we maintain compatibility with `hg` as much as possible by default.\n\nAlso, Mercurial's command line parser is extremely wonky and has some questionable behavior. If the intent is to make `rhg` compatible with `hg`, we would need to preserve this horrible behavior. We'll likely have to write a custom argument parser because of how quirky Mercurial's argument parser is :(","replyTo":null,"isNewFile":"1","line":"233","lineLength":"28","path":"rust\/hgcli\/src\/main.rs","diffId":"6724","author":"indygreg","id":"43864","dateCreated":"1520494272","dateModified":"1520494272"},{"type":"inline","comment":"I see this file was copied. There's nothing wrong with that. But does this mean we will need a custom build.rs for each Rust package doing Python? If that's the case, then I would prefer to isolate all our rust-cpython code to a single package, if possible. I'm guessing that could be challenging due to crossing create boundaries. I'm sure there are placed where we don't want to expose symbols outside the crate.\n\nI'm curious how others feel about this.","replyTo":null,"isNewFile":"1","line":"1","lineLength":"0","path":"rust\/hgbase85\/build.rs","diffId":"6724","author":"indygreg","id":"43863","dateCreated":"1520494272","dateModified":"1520494272"},{"type":"comment","comment":"First of all - wow! Thanks for writing all this code. There's definitely a lot to work with. And work with it we will!\n\nThis is definitely too big to review as one commit. If you could do *any* work to split it up, it would be greatly appreciated. I'd focus on the pure Rust pieces first. Everything needed to open revlogs would be great!\n\nYou may find our custom Phabricator extensions (linked from https:\/\/www.mercurial-scm.org\/wiki\/Phabricator) useful for submitting series of commits to Phabricator.\n\nRegarding the performance, that's pretty good! The dirstate code is some of the most optimized code in Mercurial. There are some gnarly Python C hacks to make it fast. Some of those tricks involve using special system calls to walk directories to minimize the number of system calls. I'm not sure if the crate you imported has those optimizations. (I wouldn't be surprised either way.) I wouldn't worry too much about performance at this juncture. But I suspect we could make the Rust code another 50% faster with some tweaking. It would also be interesting to test on a larger repo, say https:\/\/hg.mozilla.org\/mozilla-unified. Also, I believe there are hooks in the dirstate code to use Watchman (fsmonitor). Those hooks are critical in order to achieve peak performance on large repositories.\n\nSince you seem to be proficient at writing lots of Rust code, if you are looking for another project, may I suggest porting `chg` to Rust? That code is in `contrib\/chg`. That might be the easiest component to actually ship in Rust since it is a standalone binary that doesn't link against Python. But we shouldn't get ahead of ourselves :)\n\nAnyway, it is late for me and I need to detach from my computer. I'm sure others will have things to say as well...","author":"indygreg","id":"43862","dateCreated":"1520494272","dateModified":"1520494272"},{"type":"comment","comment":"Hi all,\n\nBased on the discussion a few weeks ago, I come up with a solution for review and discussion. After reading the Oxidation plan, the first thought is to bypass python engine and current plugin system IFF on request. If user (maybe background checker of IDE) request r-* subcommands, then hg gives rust implementations instead of python's. So I try to make hg r-status as fast as possible. The submitted version has comparable performance (as an example of the performance, not evidence, on my MacBook, in hg's own repo, hg r-status 150ms, and hg status 220ms). I am using CodeXL to profile the performance, and plan to use Future.rs to make the loading parallel and maybe 30ms faster.\n\nThe implementation originates from hg python implementation, because the python version is really fast. I tried to split into small changes, however, I eventually to combine all hgstorage module as one commit.\n\nThank you for your comments!","author":"Ivzhh","id":"43861","dateCreated":"1520491361","dateModified":"1520491361"},{"type":"comment","comment":"  - merge with stable\n  - translate base85.c into rust code\n  - move hgbase85 into independent module\n  - add hgstorage crate\n  - hg status implementation in rust\n","author":"Ivzhh","id":"43856","dateCreated":"1520490633","dateModified":"1520490633"},{"type":"update","diffId":"6724","author":"Ivzhh","id":"43855","dateCreated":"1520490633","dateModified":"1520490633"},{"type":"comment","comment":"Thank you @indygreg!\n\nThe OxidationPlan is my best reference when I started to make a move, and this thread is even more helpful. I am really interested in exploring this ;-) In 2014 I was trying to change the hg backend storage to Postgres, a silly and failed experiment.\n\nAnyway, I will save everyone's time and stop talking. I will come back later with a more meaningful implementation.","author":"Ivzhh","id":"34977","dateCreated":"1518075333","dateModified":"1518075333"},{"type":"comment","comment":"To be honest, we're not yet sure what we'll decide for the Python -> Rust bridge. The problem is summarized in the `Rust <=> Python Interop` section on https:\/\/www.mercurial-scm.org\/wiki\/OxidationPlan.\n\nI suspect at some level we'll need a CPython extension for CPython for performance reasons (especially for high volume function calls). PyPy obviously uses CFFI. I think the ideal outcome is we can write Rust that exposes a C API and use CFFI natively on PyPy and something like `cbindgen` + `Milksnake` to auto-generate a CPython extension that acts as a wrapper around the C API exposed by Rust. I'm not sure if anyone has invented this exact wheel yet. If not, it's probably faster to use `rust-cpython`. Maybe several months from now we have enough Rust and maintaining `rust-cpython` is painful enough that we pursue the auto-generated CPython extension route.\n\nWhat I'm trying to say is you have a green field to explore! But at this juncture, perfect is the enemy of done. We'll be happy with any forward progress, even failed experiments.","author":"indygreg","id":"34976","dateCreated":"1518074550","dateModified":"1518074550"},{"type":"comment","comment":"As the author of this patch, actually I have the same concern. I started to translate base85 as baby steps to find a way of integrating rust and cpython, on my side, Today I modify setup.py, policy.py and makefile to run hg's test suit with the new base85. For myself, it is only proof of concept.\n\nMaybe I should take another way: translate more python modules into CFFI-style, and let CFFI call rust implementation. And gradually change more implementations of python modules with corresponding cffi-style, while keep the python interface the same. My own hope is the rust routines will be able to call each other and eventually run some __basic__ tasks without calling python part. And the rust still lazily provides info to python interface for extensions etc.\n\nI am exploring this way now, and hope the findings will be useful for community to make decision.\n\nThank you all for the comments!","author":"Ivzhh","id":"34975","dateCreated":"1518070365","dateModified":"1518070365"},{"type":"comment","comment":"What would be the advantage of taking this? Since we already have the C implementation, it's not likely to gain us any performance. On the other hand, it might make a good test case for integrating Rust and Python, finding the right API boundaries and experimenting with different approaches, precisely \/\/because\/\/ we already have a C implementation. @indygreg @durin42 what are your thoughts about it?\n\n","author":"krbullock","id":"34910","dateCreated":"1518062354","dateModified":"1518062354"},{"type":"comment","comment":"I agree with the splitting comments :) In fact there might already be a base85 crate which can be used: https:\/\/docs.rs\/zero85. Either way I'll hold off on the review, feel free to ping me when you are ready for me to take a look.","author":"kevincox","id":"34640","dateCreated":"1518001891","dateModified":"1518001891"},{"type":"comment","comment":"Thank you @indygreg for your detailed explanation!\n\nI understand the process now, and I will go back reading the developer's guide thoroughly again. I will try my best to provide a relatively clean stack of patches.\n\nThank you for you time!","author":"Ivzhh","id":"34561","dateCreated":"1517972031","dateModified":"1517972031"},{"type":"comment","comment":"We generally prefer that patches to Mercurial be small and do a single thing. This makes it easier to review and understand changes, since each change can be evaluated in isolation. If you submit changesets together using `hg phabsend`, they automatically show up as a \/\/stack\/\/ in Phabricator. And if changesets at the bottom of the stack are ready to land, we generally land those without waiting for the entire stack to land. This enables forward progress to be made and this is generally better for everyone than waiting until a series of commits is perfect before adding any of them.\n\nWhat that means is you should ideally split this work into smaller parts. For example:\n\n  # Add the pure Rust code\/crate\n  # Add the Python Rust code\/crate\n  # Build system \/ module policy changes\n\nI'm not sure of the order of things though. Since this is the first Rust extension, it's not clear what needs to be implemented in what order. I'm fine looking at a large commit if things are too tightly coupled to separate. But you should strive to make smaller commits.\n\n","author":"indygreg","id":"34557","dateCreated":"1517970792","dateModified":"1517970792"},{"type":"comment","comment":"Sure, thank you for the comments! I can definitely prepare makefile and setup.py to make the building process work with rust part. I am planning to change the policy.py module to support and try to load rust modules and run all the tests. I will submit a new patch after finishing these two tasks.\n\nAfter reading wiki\/OxidationPlan again, I plan to change to cffi for better compatibility (pypy and others), and try to build algorithms in pure rust. Shall I wait till migrating to cffi based solution now and resubmit this patch with all three changes (building, testing, and cffi)?\n\nThank you!","author":"Ivzhh","id":"34556","dateCreated":"1517970271","dateModified":"1517970271"},{"type":"comment","comment":"Yes, we should definitely split things into multiple crates. Small, narrowly-focused crates does seem to be the Rust way, after all.\n\n`hgcli` should be for things specific to the Rust implementation of `hg`. I think this can also include the feature set of `chg` (once we've ported `chg` to Rust).\n\nI definitely support separating the \"pure Rust\" from the \"Python Rust\" via a crate boundary. It is generally useful to have Rust that isn't bound to Python because it will facilitate reuse outside of Python contexts. For example, someone could implement a Mercurial wire protocol server in pure Rust without needing to worry about Python. Of course, we're likely to encounter areas where we really want tight coupling in order to achieve optimal performance in Python. So we may have to design APIs on the pure Rust side to facilitate CPython use. I'm OK with that.\n\nAs for how many crates to have, I don't have super strong opinions. I could see us putting every little component\/subsystem in its own crate. I could also see us putting everything in one large crate. I don't think it is worth deciding at this early juncture. API design and ability to be reused outside its originally intended purpose is the important property to strive for. I think that has more to do with how the code is authored rather than which crates things are in.\n\nA missing piece of this patch is the build system and module loader integration. We have a \/\/module policy\/\/ that dictates which implementation of a Python module we use. We probably want to introduce a `rust` policy that uses Rust-based modules where available and falls back to the `cext` modules\/policy if a Rust module isn't available. We also need to figure out how to integrate Rust into `setup.py`. But I think the build system bit can be deferred until we're actually ready to ship Rust, which is still a bit of ways off. I'm happy for the workflow to be \/\/run cargo in order to load Rust modules\/\/ for the time being. But if you can implement `Makefile` and\/or `setup.py` integration to build these Rust extensions, that would be awesome.","author":"indygreg","id":"34484","dateCreated":"1517947275","dateModified":"1517947275"},{"type":"comment","comment":"I am open to the three-crates plan. Oirginally I have hgcli and hgext separately, and I was planning to use CFFI mode. I am a pypy user too, so I will be willing to provide a python C API free crate for pypy and others.","author":"Ivzhh","id":"34443","dateCreated":"1517928889","dateModified":"1517944524"},{"type":"inline","comment":"I think I'd like to separate things a bit more and have a Python-free module, and then a glue module that we can use to call into the pure Rust. Part of the reason is that in my perfect world we won't use the cpython crate for speedups so they can be used from pypy as well. Separating them at least makes it easier to have an extern \"C\" version of the method that can be used from cffi instead of only through the CPython API.\n\n(Not sure what opinions others have. It's likely that I'll attempt this approach in the near future as part of a continued attempt to speed up `hg diff`.)","replyTo":null,"isNewFile":"1","line":"22","lineLength":"0","path":"rust\/hgcli\/src\/hgext\/base85.rs","diffId":"5238","author":"durin42","id":"34390","dateCreated":"1517913293","dateModified":"1517913293"},{"type":"comment","comment":"I'd be curious to see what @indygreg has to say about this, maybe wait on his input before doing any work in response to my feedback?\n\nI do wonder if we should have at least three crates:\n\n # hgcli\n # libmercurial\n # hgcext\n\nThe first one would be the command-line entry point, the last could use the cpython API, and libmercurial would be \"pure rust\" and open the door to eventually having a libhg or something that exports C functions and would be suitable for cffi and linking into other binaries?","author":"durin42","id":"34389","dateCreated":"1517913293","dateModified":"1517913293"},{"type":"update","diffId":"5238","author":"Ivzhh","id":"34367","dateCreated":"1517869861","dateModified":"1517869861"}],"dateCreated":"1517869861","dateModified":"1521888284","status":"Needs Review"},{"id":"2884","callsign":"HG","title":"wireproto: experimental command to emit file data","author":"indygreg","summary":"Partial clones will require new wire protocol functionality to\nretrieve repository data. The remotefilelog extensions - which\nimplements various aspects of partial clone - adds a handful of\nwire protocol commands:\n\ngetflogheads\n   Obtain heads of a filelog\ngetfile\n   Obtain data for an individual file revision\ngetfiles\n   Batch version of getfile\ngetpackv1\n   Obtain a \"pack file\" containing index and data on multiple\n   files\n\n(among others)\n\nRecently, the wire protocol has gained support for \"obtain repository\ndata\" in the form of overloading the \"getbundle\" wire protocol\ncommand. This is arguaby OK in the context of \"all data is attached\nto bundles\" and \"bundles are a self-contained representation of\ncomplete repository data.\" But partial clone invalidates these\nassumptions because in a partial clone world, we no longer can assume\nthings like \"the client has all the base revisions.\"\n\nIn a partial clone world, we'll need wire protocol commands that allow\nclients to obtain specific pieces of data with vastly different\naccess patterns. For example, a client may want to obtain \"index\"\ndata but keep the fulltext data on the server. Or vice-versa. Or a\nclient may wish to fetch all revisions of a specific file but only\nthe latest revision of another. These access patterns will be\ndifficult to shoehorn into single, powerful commands (like\n\"getbundle\"). Even if we could, doing that isn't wise from a server\nimplementation perspective because it makes implementing scalable\nservers hard. We want server-side commands to be small and simple\nso alternate server implementations can come into existence more\neasily.\n\nThis is one reason why the frame-based wire protocol I'm implementing\nsupports command pipelining and out-of-order responses. This\nproperty will enable clients performing complex operations to send\ncommand streams containing dozens or even hundreds of small command\nrequests to servers.\n\nAnyway, this commit implements an experimental wire protocol command\nfor \"get files data.\" Essentially, you give it a changeset revision\nyou are interested in and it spits back all the files and their data\nin that revision, as fulltexts.\n\nThis command is just one way a server could emit data for files.\nA variation of this command that accepts specific file paths and nodes\nwhose data is to be retrieved would also be useful. And I imagine we'll\neventually implement that. It would also be useful to emit index\ndata. Or have each file blob be individually compressed. (Right now\ncompression is performed on the whole stream because that's how the\nwire protocol currently works - but I have plans to evolve the frame\nbased protocol to do new and novel things here.)\n\nI'm not even sure this variation of the wire protocol command is a\ngood one to have! One reason I want to start with this command is\nthat it seems like a useful primitive. For example, with this\ncommand, one could build a client that is able to realize a working\ndirectory from a single wire protocol request: you can literally\nstream the response to this command and turn the data into files on\nthe filesystem with minimal stream processing!\n\nAs implemented, this command is effectively a benchmark of revlog\nreading and\/or compression. On the mozilla-unified repository when\noperating on revision c488b8d0e074efb490ebca32db68eb77871bfd2f (a\nrecent revision of mozilla-central, the head of Firefox development),\nmy i7-6700K yields the following:\n\n* no compression: 1478MB;  ~94s wall; ~56s CPU\n* zstd level 3:    343MB;  ~97s wall; ~57s CPU\n* zlib level 6:    367MB; ~116s wall; ~74s CPU\n\nFor comparison, `hg bundle --base null -r c488b8d0e0 -t zstd-v2`\n(which approximates what `hg clone -r` would be doing on the server)\nyields:\n\n  1397MB; ~624s wall; ~225s CPU\n\nOf course, these are vastly different operations. But this does\ndemonstrate that if your use case of version control is \"check out\nrevision X\" and you were previously relying on `hg clone` [without\nstream clone bundles] to do that, this wire protocol command\nis overall much more efficient on servers. It's worth noting that\nthe use case of version control for many automated systems *is*\n\"check out revision X.\" So I think providing a clone mode that can\nrealize a working copy as fast as possible is a worthwhile feature\nto have!","testPlan":"","lineCount":"335","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"comment","comment":"This needs rebasing. Please hold off reviewing.","author":"indygreg","id":"47297","dateCreated":"1521732096","dateModified":"1521732096"},{"type":"plan-changes","author":"indygreg","id":"47296","dateCreated":"1521732096","dateModified":"1521732096"},{"type":"update","diffId":"7150","author":"indygreg","id":"46609","dateCreated":"1521503993","dateModified":"1521503993"},{"type":"update","diffId":"7081","author":"indygreg","id":"46289","dateCreated":"1521241628","dateModified":"1521241628"}],"dateCreated":"1521241628","dateModified":"1521732096","status":"Changes Planned"},{"id":"2588","callsign":"HG","title":"commit: adds multiline commit message support(issue5616)","author":"sangeet259","summary":"The earlier functionality used to ignore the all but last -m flag's value.\nIt used to store the arguments information in a state dict and then overwrites each\nsubsequent value of -m in the 'message' key. This patch intercepts the message flag and\nchecks if it is already empty. In case it is not empty, add the current value of -m flag to\nthe message key with a leading '\\n' character. This makes every subsequent passed -m flag\nas the new line message of the commit.","testPlan":"","lineCount":"28","dependsOn":[],"reviewers":[],"ccs":["durin42","tom.prince","yuja","pulkit","jeffpc","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D2588#44645, @sangeet259 wrote:\n> Since the current code just overwrites message each time with the newer. What can be done to avoid losing the earlier message values?\n\nYou should look how we handle multiple `--rev` flags. That will help you in this case.","author":"pulkit","id":"44677","dateCreated":"1520666278","dateModified":"1520666278"},{"type":"comment","comment":"Since the current code just overwrites message each time with the newer. What can be done to avoid losing the earlier message values?\n","author":"sangeet259","id":"44645","dateCreated":"1520655918","dateModified":"1520655918"},{"type":"inline","comment":"agreed","replyTo":"42705","isNewFile":"1","line":"847","lineLength":"0","path":"tests\/test-commit.t","diffId":"6537","author":"durin42","id":"43618","dateCreated":"1520437801","dateModified":"1520437801"},{"type":"comment","comment":"@pulkit Yeah, this rather a not so elegant hack. How can it be parsed in hg commit? \nAs the first message passed is overwritten by the second one at this step only.  :\/\n\n@yuja I think maybe subclassing the customopt may be a fair choice.","author":"sangeet259","id":"43614","dateCreated":"1520437520","dateModified":"1520437520"},{"type":"inline","comment":"Right. Alternatively, we could add a subclass of customopt, but I don't know which\nwould be nicer.\n\nFWIW, I'm kinda -1 on this feature, but I have no strong opinion and Git is the\ncurrent standard.","replyTo":"42704","isNewFile":"1","line":"365","lineLength":"0","path":"mercurial\/fancyopts.py","diffId":"6537","author":"yuja","id":"42772","dateCreated":"1520184244","dateModified":"1520184244"},{"type":"inline","comment":"starting with a newline seems awkward.","replyTo":null,"isNewFile":"1","line":"847","lineLength":"0","path":"tests\/test-commit.t","diffId":"6537","author":"pulkit","id":"42705","dateCreated":"1520181862","dateModified":"1520181862"},{"type":"inline","comment":"I think this is not the right place to have this hack. We should have this as a part of `hg commit` code rather.","replyTo":null,"isNewFile":"1","line":"365","lineLength":"0","path":"mercurial\/fancyopts.py","diffId":"6537","author":"pulkit","id":"42704","dateCreated":"1520181862","dateModified":"1520181862"},{"type":"update","diffId":"6537","author":"sangeet259","id":"42559","dateCreated":"1520149348","dateModified":"1520149348"},{"type":"comment","comment":"@jeffpc That means two new lines. Shall I edit this patch to effect that?\n","author":"sangeet259","id":"42558","dateCreated":"1520142981","dateModified":"1520147672"},{"type":"update","diffId":"6536","author":"sangeet259","id":"42557","dateCreated":"1520139879","dateModified":"1520139879"},{"type":"comment","author":"sangeet259","id":"41893","dateCreated":"1520098879","dateModified":"1520098898"},{"type":"comment","comment":"FWIW, this is slightly different behavior from what git does.  There, each -m is added as a separate *paragraph*.  IOW,\n\n\n```\n$ git commit -m \"first\" -m \"second\"\n```\n\ncreates:\n\n```\nfirst\n\nsecond\n```","author":"jeffpc","id":"41892","dateCreated":"1520098727","dateModified":"1520098727"},{"type":"update","diffId":"6438","author":"sangeet259","id":"41882","dateCreated":"1520098029","dateModified":"1520098029"}],"dateCreated":"1520098029","dateModified":"1520666278","status":"Needs Review"},{"id":"2681","callsign":"HG","title":"[PoC] scmutil: support local only obsolescence","author":"indygreg","summary":"Now that we have a config option for enabling local-only obsolescence,\nit is time to do something with it.\n\nThis commit teaches cleanupnodes() - which is called after rewrite\noperations - to handle local only obsolescence mode.\n\nIn this mode, we create a backup bundle of the obsoleted changesets -\njust like what happens if obsolescence is disabled. But we don't strip\nthe repo: we keep the original changesets around in a non-visible state.\n\nThe new code verifies that no unstable changesets are introduced in\nlocal-only obsolescence mode.\n\nThe new code hackily only runs if the action is \"amend.\" The intent\nis to make this conditional only on the feature option. However,\ndoing that would have significant test fallout. So we limit to \"amend\"\nfor now.\n\nTODO:\n\n* Better test coverage (I think the \"(testcase !)\" syntax might be\n  subtly wrong by flagging output as optional and not required).\n* Delete obsolescence markers when we pull and unbundle from the\n  bundle.\n* Support pulling locally-hidden heads.","testPlan":"","lineCount":"143","dependsOn":["2680"],"reviewers":[],"ccs":["mharbison72","mercurial-devel"],"actions":[{"type":"comment","comment":"re: the \"(testcase !)\" syntax- I agree that it would be better if \"(false !)\" means the line is *not* present, instead of optional.\n\nI made an attempt to do that, but somehow I came up with a test in test-run-tests.t that failed there, but the exact same test ran fine in another *.t.  I wondered if it was a case of run-tests.py processing it for a test inside test-run-tests.t, and then the main instance of run-tests.py re-processing it.  If I can find that code, I can post it if you think it might be useful.  But I've long forgotten the nuance in that code. ","author":"mharbison72","id":"43337","dateCreated":"1520216552","dateModified":"1520216552"},{"type":"update","diffId":"6639","author":"indygreg","id":"43226","dateCreated":"1520210577","dateModified":"1520210577"}],"dateCreated":"1520210577","dateModified":"1520216552","status":"Needs Review"},{"id":"2682","callsign":"HG","title":"[PoC] changegroup: delete obs markers when applying changegroup","author":"indygreg","summary":"In local-only obsolescence mode, our short-term hack to unhide a\nchangeset is to delete obsolescence markers causing it to be hidden.\nWe need to do this every time a changeset is introduced into the\nrepository.\n\nI was hoping we could implement the unhide logic once, around\ntransaction close time. However, it appears that we'll need to\nteach every mechanism that introduces changesets to unhide\nchangesets because of interaction between those mechanisms and\nvisibility. For example, changegroup application no-ops on incoming\nchangesets that are present but hidden. The code that scans for\n\"new\" changesets is based on changesets between the old and new\nchangelog length. Since the unhidden changeset is possibly older\nthan the old changelog length, we need to either track unhides\nexplicitly or deal with them specially.\n\nThis commit teaches changegroup application to record which changesets\nare in the incoming changegroup so it can scan for relevant\nobsolescence markers after changegroup applications and delete\ntheir markers.\n\nI'm not convinced this is the best approach to the problem. But it's\na start.","testPlan":"","lineCount":"27","dependsOn":["2681"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"6640","author":"indygreg","id":"43236","dateCreated":"1520210580","dateModified":"1520210580"}],"dateCreated":"1520210580","dateModified":"1520210580","status":"Needs Review"},{"id":"2680","callsign":"HG","title":"[PoC] obsolete: make markers database writable if local-only mode enabled","author":"indygreg","summary":" ","testPlan":"","lineCount":"4","dependsOn":["2679"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"6638","author":"indygreg","id":"43217","dateCreated":"1520210574","dateModified":"1520210574"}],"dateCreated":"1520210574","dateModified":"1520210577","status":"Needs Review"},{"id":"2622","callsign":"HG","title":"ui: adding a generic method to read config items with an arbitrary type","author":"rdamazio","summary":"This can be used for reading many config options of various types where the\ntype of each is known in some other structure (e.g. options matching command\nflags).","testPlan":"","lineCount":"10","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"6520","author":"rdamazio","id":"42415","dateCreated":"1520121279","dateModified":"1520121279"}],"dateCreated":"1520121279","dateModified":"1520121282","status":"Needs Review"},{"id":"2079","callsign":"HG","title":"color: honor NO_COLOR","author":"indygreg","summary":"The http:\/\/no-color.org\/ initiative is trying to get programs that\nemit color by default to honor a NO_COLOR environment variable to\ndisable color.\n\nI think that's a good idea. So this commit implements support for\nNO_COLOR.\n\nI'm not sure if the precedence of settings is proper here. Right now,\nNO_COLOR overrides config settings set by hgrc or --config. But it\ndoesn't override --color. I can see an argument for honoring\n--config as well. Same for hgrc (since color is enabled by default\nthese days). But the existing logic\/precedence is unclear to me. So\nI went with an easy implementation.","testPlan":"","lineCount":"43","dependsOn":[],"reviewers":["lothiraldan","yuja"],"ccs":["durin42","martinvonz","yuja","quark","lothiraldan","mercurial-devel"],"actions":[{"type":"comment","comment":"(just clarify the current state of this patch)","author":"yuja","id":"37633","dateCreated":"1518697359","dateModified":"1518697359"},{"type":"reject","author":"yuja","id":"37632","dateCreated":"1518697359","dateModified":"1518697359"},{"type":"comment","comment":"The goal was to allow users to override system default using environment variables. So a separate `[systemdefaults]` (proposed by @durin42) becomes unnecessary.","author":"quark","id":"35160","dateCreated":"1518290016","dateModified":"1518290016"},{"type":"comment","comment":">>! In D2079#35154, @yuja wrote:\n>> I'm not sure if the precedence of settings is proper here.\n> \n> Perhaps it should be placed at the same level as `$EDITOR` (i.e. envrcitems)?\n\nI haven't bothered checking what that means for precedence, but I have an argument for giving NO_COLOR higher precedence than at least the system config: we set the system config for all our users at Google and some may want to override with NO_COLOR. I know someone (Jun? Yuya?) did some work related to precedence of EDITOR a while ago, but I don't remember what the goal of that was.\n","author":"martinvonz","id":"35157","dateCreated":"1518279995","dateModified":"1518279995"},{"type":"comment","comment":"> I'm not sure if the precedence of settings is proper here.\n\nPerhaps it should be placed at the same level as `$EDITOR` (i.e. envrcitems)?\n\nAnd can you update help\/color and environment?","author":"yuja","id":"35155","dateCreated":"1518265384","dateModified":"1518265384"},{"type":"comment","comment":"You might want to let run-tests.py drop NO_COLOR for tests.","author":"quark","id":"34711","dateCreated":"1518036117","dateModified":"1518036117"},{"type":"comment","comment":":+1: Hurrah for standards!","author":"lothiraldan","id":"34709","dateCreated":"1518024955","dateModified":"1518024955"},{"type":"accept","author":"lothiraldan","id":"34708","dateCreated":"1518024955","dateModified":"1518024955"},{"type":"update","diffId":"5298","author":"indygreg","id":"34702","dateCreated":"1518023858","dateModified":"1518023858"}],"dateCreated":"1518023858","dateModified":"1518697359","status":"Needs Revision"},{"id":"2259","callsign":"HG","title":"py3: use pycompat.bytestr to convert int\/bytes to bytes","author":"pulkit","summary":"The item value can be integer or can be bytes, so cannot use \"%d\" here.","testPlan":"","lineCount":"2","dependsOn":[],"reviewers":["yuja"],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"comment","comment":"> The item value can be integer or can be bytes, so cannot use \"%d\" here.\n\nSounds like a bug. IIUC, the item should be a byte string because it is\npassed to `ui.progress(item=)`. Can you take a look?","author":"yuja","id":"37455","dateCreated":"1518614063","dateModified":"1518614063"},{"type":"reject","author":"yuja","id":"37454","dateCreated":"1518614063","dateModified":"1518614063"},{"type":"update","diffId":"5699","author":"pulkit","id":"37333","dateCreated":"1518607500","dateModified":"1518607500"}],"dateCreated":"1518607500","dateModified":"1518614064","status":"Needs Revision"},{"id":"2158","callsign":"HG","title":"py3: use raw string for open() mode","author":"indygreg","summary":" ","testPlan":"","lineCount":"8","dependsOn":[],"reviewers":[],"ccs":["yuja","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"I wanna leave it with no prefix as possible. I think we'll have to bulk-replace\n`''`s to `b''`s at some point so we can leverage static analysis tools, where\n`r''` will be unneeded.","author":"yuja","id":"35990","dateCreated":"1518432079","dateModified":"1518432079"},{"type":"comment","comment":"Looks like a better approach will be to revert this change: https:\/\/www.mercurial-scm.org\/repo\/hg\/rev\/7c54917b31f6. I did that in favor of pycompat.open() and now I think it's better to revert that change. ","author":"pulkit","id":"35944","dateCreated":"1518420826","dateModified":"1518420826"},{"type":"update","diffId":"5459","author":"indygreg","id":"35745","dateCreated":"1518402936","dateModified":"1518402936"}],"dateCreated":"1518402936","dateModified":"1518432079","status":"Needs Review"},{"id":"2010","callsign":"HG","title":"check-commit: allow foo_bar naming in functions","author":"indygreg","summary":"nameswithallthewordssmashedtogetherarehardtoread.\nespeciallyifenglishisnotyourprimarylanguage.\n\nLet's align with the rest of the programming universe and\nallow_the_use_of_underscores_in_names.","testPlan":"","lineCount":"10","dependsOn":[],"reviewers":["pulkit","durin42"],"ccs":["av6","yuja","durin42","pulkit","mercurial-devel"],"actions":[{"type":"comment","comment":"As opposed to 11 words smashed together, function names in Mercurial usually are 2 or 3 words (if not just one), which is not at all bad. I think breaking consistency with the existing code base would be worse than making people get used to no-spaces style (the one that python's stdlib usually follows, in fact). So, FWIW, -1 from me.","author":"av6","id":"33903","dateCreated":"1517723192","dateModified":"1517723215"},{"type":"comment","comment":"I'm kinda -1 on this because of inconsistency with the 10-year codebase.","author":"yuja","id":"33887","dateCreated":"1517646932","dateModified":"1517646932"},{"type":"comment","comment":"I'm also +1 on this.","author":"durin42","id":"33697","dateCreated":"1517595429","dateModified":"1517595429"},{"type":"accept","author":"durin42","id":"33696","dateCreated":"1517595429","dateModified":"1517595429"},{"type":"comment","comment":"I am +1 on this.","author":"pulkit","id":"33694","dateCreated":"1517595331","dateModified":"1517595331"},{"type":"accept","author":"pulkit","id":"33693","dateCreated":"1517595331","dateModified":"1517595331"},{"type":"update","diffId":"5162","author":"indygreg","id":"33687","dateCreated":"1517595246","dateModified":"1517595246"}],"dateCreated":"1517595246","dateModified":"1517723192","status":"Needs Review"},{"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"],"ccs":[],"actions":[{"type":"update","diffId":"5001","author":"hollisb","id":"32644","dateCreated":"1516757506","dateModified":"1516757506"}],"dateCreated":"1516757506","dateModified":"1516757576","status":"Needs Review"},{"id":"1936","callsign":"FBHGX","title":"p4fastimport: report more information about unsupported p4 file actions","author":"hollisb","summary":"No matter what, users and developers need this information to understand the\nproblem.","testPlan":"","lineCount":"3","dependsOn":[],"reviewers":["dsp"],"ccs":[],"actions":[{"type":"comment","comment":"I will have a followup patch to handle 'purge' file actions at some point, but it's not yet clear to me how to do it in the most useful and nonsurprising way. :-) In the meantime, this is a useful step.","author":"hollisb","id":"32642","dateCreated":"1516666023","dateModified":"1516666023"},{"type":"update","diffId":"5000","author":"hollisb","id":"32637","dateCreated":"1516665895","dateModified":"1516665895"}],"dateCreated":"1516665895","dateModified":"1516666023","status":"Needs Review"},{"id":"1649","callsign":"FBHGX","title":"infinitepush: add logic to support old clients on the basis of pushkey part","author":"pulkit","summary":"This patch adds logic to check whether a push is an infinitepush or not from\nan old client or client who don't have infinitepush client logic.","testPlan":"","lineCount":"60","dependsOn":[],"reviewers":["durham"],"ccs":[],"actions":[{"type":"comment","comment":"Status update: While adding tests, I found that I am reading the part twice, once for adding in bundlepart and once for the copied part. Since I can't read that twice, I need to do better here with the logic involved.","author":"pulkit","id":"31242","dateCreated":"1515664035","dateModified":"1515664064"},{"type":"inline","comment":"Can we add a comment saying this could require a lot of memory, and that we might want to move this to being stored on disk in the future?","replyTo":null,"isNewFile":"1","line":"1080","lineLength":"0","path":"infinitepush\/__init__.py","diffId":"4342","author":"durham","id":"30893","dateCreated":"1515514134","dateModified":"1515514134"},{"type":"inline","comment":"I'd make it clear that this will have performance impact.","replyTo":null,"isNewFile":"1","line":"1055","lineLength":"0","path":"infinitepush\/__init__.py","diffId":"4342","author":"durham","id":"30892","dateCreated":"1515514134","dateModified":"1515514134"},{"type":"inline","comment":"I'd rename this `supportoldclients`, since it's a server configuration.","replyTo":null,"isNewFile":"1","line":"1108","lineLength":"0","path":"infinitepush\/__init__.py","diffId":"4342","author":"durham","id":"30891","dateCreated":"1515514134","dateModified":"1515514134"},{"type":"comment","comment":"Could this have a test? Is there a config knob to disable bundle2 or force bundle1?","author":"durham","id":"30890","dateCreated":"1515514134","dateModified":"1515514134"},{"type":"reject","author":"durham","id":"30889","dateCreated":"1515514134","dateModified":"1515514134"},{"type":"update","diffId":"4342","author":"pulkit","id":"28287","dateCreated":"1512952476","dateModified":"1512952476"}],"dateCreated":"1512952476","dateModified":"1515664035","status":"Needs Revision"},{"id":"1779","callsign":"HG","title":"unionrepo: use named attributes on revlog index entries","author":"indygreg","summary":"This appears to be the last user of the offsets in core (as far as\nthe test harness was able to reveal).","testPlan":"","lineCount":"11","dependsOn":["1778"],"reviewers":["durin42"],"ccs":["durin42","mercurial-devel"],"actions":[{"type":"comment","comment":"I think we should hold off landing until the native C type is ready. I don't like shipping a performance regression on such low-level code without any other user benefit to offset it. The assumption here is that I'm the only one who will absorb pain from this series lingering. I'm willing to take that hit.","author":"indygreg","id":"31193","dateCreated":"1515640397","dateModified":"1515640397"},{"type":"comment","comment":"Happy to see these land, but waiting for any objections from others.","author":"durin42","id":"31088","dateCreated":"1515624896","dateModified":"1515624896"},{"type":"accept","author":"durin42","id":"31087","dateCreated":"1515624896","dateModified":"1515624896"},{"type":"update","diffId":"4640","author":"indygreg","id":"30186","dateCreated":"1514334979","dateModified":"1514334979"}],"dateCreated":"1514334979","dateModified":"1515640397","status":"Accepted"},{"id":"1778","callsign":"HG","title":"debugcommands: use named attributes on revlog index entries","author":"indygreg","summary":" ","testPlan":"","lineCount":"16","dependsOn":["1777"],"reviewers":["durin42"],"ccs":["mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31084","dateCreated":"1515624896","dateModified":"1515624896"},{"type":"update","diffId":"4741","author":"indygreg","id":"30870","dateCreated":"1515227185","dateModified":"1515227185"},{"type":"update","diffId":"4639","author":"indygreg","id":"30177","dateCreated":"1514334977","dateModified":"1514334977"}],"dateCreated":"1514334977","dateModified":"1515624896","status":"Accepted"},{"id":"1777","callsign":"HG","title":"upgrade: use named attributes on revlog index entries","author":"indygreg","summary":" ","testPlan":"","lineCount":"6","dependsOn":["1776"],"reviewers":["durin42"],"ccs":["mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31082","dateCreated":"1515624895","dateModified":"1515624895"},{"type":"update","diffId":"4638","author":"indygreg","id":"30168","dateCreated":"1514334975","dateModified":"1514334975"}],"dateCreated":"1514334974","dateModified":"1515624895","status":"Accepted"},{"id":"1776","callsign":"HG","title":"bundlerepo: use named attributes on revlog index entries","author":"indygreg","summary":" ","testPlan":"","lineCount":"4","dependsOn":["1775"],"reviewers":["durin42"],"ccs":["mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31080","dateCreated":"1515624894","dateModified":"1515624894"},{"type":"update","diffId":"4637","author":"indygreg","id":"30159","dateCreated":"1514334972","dateModified":"1514334972"}],"dateCreated":"1514334972","dateModified":"1515624894","status":"Accepted"},{"id":"1775","callsign":"HG","title":"dagutil: use named attributes on revlog index entries","author":"indygreg","summary":"Continuing the transition away from tuples.","testPlan":"","lineCount":"20","dependsOn":["1774"],"reviewers":["durin42"],"ccs":["mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31078","dateCreated":"1515624893","dateModified":"1515624893"},{"type":"update","diffId":"4636","author":"indygreg","id":"30149","dateCreated":"1514334970","dateModified":"1514334970"}],"dateCreated":"1514334970","dateModified":"1515624893","status":"Accepted"},{"id":"1774","callsign":"HG","title":"repoview: use named attributes on revlog index entries","author":"indygreg","summary":"We want to remove __getitem__ support from index entries. Port\na usage in repoview.","testPlan":"","lineCount":"2","dependsOn":["1773"],"reviewers":["durin42"],"ccs":["mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31076","dateCreated":"1515624893","dateModified":"1515624893"},{"type":"update","diffId":"4740","author":"indygreg","id":"30869","dateCreated":"1515227182","dateModified":"1515227182"},{"type":"update","diffId":"4635","author":"indygreg","id":"30139","dateCreated":"1514334968","dateModified":"1514334968"}],"dateCreated":"1514334968","dateModified":"1515624893","status":"Accepted"},{"id":"1773","callsign":"HG","title":"revlog: use named attributes on revlog index entries","author":"indygreg","summary":"Now that we're using a dedicated type for index entries everywhere,\nwe can access fields in them by name instead of integer offset.\n\nThis change has a significant impact on performance on the Firefox\nrepository. (Values are from before refactor, parent commit, this\ncommit.)\n\n$ HGMODULEPOLICY=c hg perfrevset '::tip'\n! wall 0.755869 comb 0.750000 user 0.750000 sys 0.000000 (best of 13)\n! wall 1.011107 comb 1.010000 user 1.010000 sys 0.000000 (best of 10)\n! wall 0.864906 comb 0.860000 user 0.860000 sys 0.000000 (best of 11)\n\n$ HGMODULEPOLICY=py hg perfrevset '::tip'\n! wall 1.366281 comb 1.360000 user 1.360000 sys 0.000000 (best of 7)\n! wall 1.860068 comb 1.860000 user 1.860000 sys 0.000000 (best of 5)\n! wall 1.672432 comb 1.680000 user 1.670000 sys 0.010000 (best of 6)\n\nAnd with PyPy:\n\n! wall 0.163141 comb 0.160000 user 0.160000 sys 0.000000 (best of 56)\n! wall 0.154325 comb 0.160000 user 0.160000 sys 0.000000 (best of 54)\n! wall 0.155534 comb 0.160000 user 0.160000 sys 0.000000 (best of 53)\n\nThe C extension is ~15% slower than before the refactor. This is a\nbit unfortunate. That is a bit steep price to pay for more readable\ncode and the establishment of a formal interface for index entries.\n\nHowever, all is not lost! Because we're now using a custom type and\nconforming to a yet-to-be-formally-defined interface, there's nothing\npreventing us from implementing a backed-by-C custom type for revlog\nentries. This type could lazily resolve PyObject instances, which\nshould result in a massive performance boost for operations that\ndon't need to access all fields of the index entry. This is easier\ndone *after* we drop all uses of tuples and their API for referring\nto index entries.","testPlan":"","lineCount":"56","dependsOn":["1772"],"reviewers":["durin42"],"ccs":["durin42","yuja","mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31074","dateCreated":"1515624892","dateModified":"1515624892"},{"type":"comment","comment":">>! In D1773#30628, @yuja wrote:\n>> However, it is quite large and I suspect it will take a bit more effort to finish it.\n> \n> Isn't that something like `dirstateTupleType`? If we had a native type, we wouldn't\n> need D1767, D1768, and probably D1769. If it can get rid of refcounting business,\n> reviewing this series will be much fun.\n\nI don't feel strongly about the approach. My bias is to land this whole series as-is. The \"lazy struct\" should be fairly easily done as a followup.\n\nThe refcounting of the type looks okay to me.","author":"durin42","id":"31061","dateCreated":"1515624811","dateModified":"1515624811"},{"type":"comment","comment":"> However, it is quite large and I suspect it will take a bit more effort to finish it.\n\nIsn't that something like `dirstateTupleType`? If we had a native type, we wouldn't\nneed D1767, D1768, and probably D1769. If it can get rid of refcounting business,\nreviewing this series will be much fun.","author":"yuja","id":"30628","dateCreated":"1515131007","dateModified":"1515131007"},{"type":"comment","comment":">>! In D1773#30283, @yuja wrote:\n> Not reviewed the series yet, but can't we just start with a custom type\n> backed by C so we don't have to import back IndexV1Entry from Python?\n\nThat's possible. I do have a work-in-progress patch to the C code to implement such a type.\n\nHowever, it is quite large and I suspect it will take a bit more effort to finish it. The end result of this series gets us into a state where the C type can be swapped in with minimal effort. I have a soft preference for implementing the type in C as a follow-up. But I can refactor the series if wanted. Or someone can review this series without accepting it and I'll add the C type later.","author":"indygreg","id":"30285","dateCreated":"1514487399","dateModified":"1514487399"},{"type":"comment","comment":"> Because we're now using a custom type and conforming to\n> a yet-to-be-formally-defined interface, there's nothing\n> preventing us from implementing a backed-by-C custom type\n> for revlog entries. \n\nNot reviewed the series yet, but can't we just start with a custom type\nbacked by C so we don't have to import back IndexV1Entry from Python?","author":"yuja","id":"30284","dateCreated":"1514469876","dateModified":"1514469876"},{"type":"update","diffId":"4634","author":"indygreg","id":"30129","dateCreated":"1514334966","dateModified":"1514334966"}],"dateCreated":"1514334966","dateModified":"1515624892","status":"Accepted"},{"id":"1772","callsign":"HG","title":"tests: port revlog index code to modern API","author":"indygreg","summary":"All revlog index parsers are now using our new type to\nrepresent index entries. We can now undo the custom type\ncomparison code we implemented to see us through the transition.\n\nIn addition, the code has been ported to use named attributes\ninstead of field offsets.","testPlan":"","lineCount":"48","dependsOn":["1771"],"reviewers":["durin42"],"ccs":["mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31072","dateCreated":"1515624891","dateModified":"1515624891"},{"type":"update","diffId":"4739","author":"indygreg","id":"30867","dateCreated":"1515227180","dateModified":"1515227180"},{"type":"update","diffId":"4633","author":"indygreg","id":"30119","dateCreated":"1514334964","dateModified":"1514334964"}],"dateCreated":"1514334964","dateModified":"1515624891","status":"Accepted"},{"id":"1771","callsign":"HG","title":"revlog: pass index entry type into packentry() (API)","author":"indygreg","summary":"packentry() currently accepts tuples. Let's pass in index entry types\ninstead.\n\nThe censor extension was calling into this low-level code. It has\nbeen refactored to use our new type and to look up fields in index\nentries by name instead of offset.","testPlan":"","lineCount":"34","dependsOn":["1770"],"reviewers":["durin42"],"ccs":["mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31070","dateCreated":"1515624891","dateModified":"1515624891"},{"type":"update","diffId":"4632","author":"indygreg","id":"30109","dateCreated":"1514334962","dateModified":"1514334962"}],"dateCreated":"1514334962","dateModified":"1515624891","status":"Accepted"},{"id":"1770","callsign":"HG","title":"revlog: use revlog index entry type for version 0 revlogs","author":"indygreg","summary":"The pure Python parser for version 1 revlogs uses it. Let's\nplug it into version 0 revlogs as well.","testPlan":"","lineCount":"9","dependsOn":["1769"],"reviewers":["durin42"],"ccs":["mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31068","dateCreated":"1515624890","dateModified":"1515624890"},{"type":"update","diffId":"4631","author":"indygreg","id":"30099","dateCreated":"1514334959","dateModified":"1514334959"}],"dateCreated":"1514334959","dateModified":"1515624890","status":"Accepted"},{"id":"1769","callsign":"HG","title":"cext: use dedicated type for index entries","author":"indygreg","summary":"Now that we have a handle on our type to represent revlog index\nentries, let's use it.\n\nThis commit essentially consists of porting code from PyTuple to\nPyObject.\n\nAs part of porting the code, we now retrieve elements in the entry\ntype by named attribute instead of integer index.\n\nBefore, PyTuple_* APIs allowed us to retrieve a borrowed reference\nto PyObject elements. We can no longer do this via the PyObject_*\nAPIs for a type not implemented in C. This required extra refcount\nmanipulation in various places.\n\nThe C extension is now emitting the new type. And because various\ncode is still accessing index entry elements via __getitem__, we\nsee a performance regression in the Firefox repository:\n\n$ hg perfrevset '::tip'\n! wall 0.755869 comb 0.750000 user 0.750000 sys 0.000000 (best of 13)\n! wall 1.011107 comb 1.010000 user 1.010000 sys 0.000000 (best of 10)\n\nWe will claw back this regression in subsequent commits by accessing\nfields by name instead of index.\n\nThe version of the \"parsers\" C extension has been incremented to\nreflect the change in behavior.","testPlan":"","lineCount":"123","dependsOn":["1768"],"reviewers":["yuja","durin42"],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31067","dateCreated":"1515624889","dateModified":"1515624889"},{"type":"update","diffId":"4738","author":"indygreg","id":"30864","dateCreated":"1515227178","dateModified":"1515227178"},{"type":"inline","comment":"No error reported to the caller.\n\nAttributeError would be set automatically.","replyTo":null,"isNewFile":"1","line":"1788","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4630","author":"yuja","id":"30618","dateCreated":"1515129734","dateModified":"1515129734"},{"type":"inline","comment":"I slightly prefer `goto bail` instead of `result = NULL; goto cleanup` pairs.","replyTo":null,"isNewFile":"1","line":"327","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4630","author":"yuja","id":"30617","dateCreated":"1515129734","dateModified":"1515129734"},{"type":"inline","comment":"This is tricky, but looks okay. Alternatively, we could inc\/decref borrowed `obj`.","replyTo":null,"isNewFile":"1","line":"321","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4630","author":"yuja","id":"30616","dateCreated":"1515129734","dateModified":"1515129734"},{"type":"inline","comment":"Perhaps AttributeError would be set by `PyObject_GetAttrString()`.","replyTo":null,"isNewFile":"1","line":"141","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4630","author":"yuja","id":"30615","dateCreated":"1515129734","dateModified":"1515129734"},{"type":"reject","author":"yuja","id":"30614","dateCreated":"1515129734","dateModified":"1515129734"},{"type":"update","diffId":"4630","author":"indygreg","id":"30089","dateCreated":"1514334957","dateModified":"1514334957"}],"dateCreated":"1514334957","dateModified":"1515624889","status":"Needs Review"},{"id":"1768","callsign":"HG","title":"cext: obtain reference to index entry type","author":"indygreg","summary":"We recently introduced a dedicated type for index entries in the\npure Python implementation.\n\nThis commit tells the revlog C code about that type.\n\nWe register the type on the parsers module so it is exposed to\nimporters of the module.\n\nIn addition, we store a reference to the type on revlog index\ninstances. In theory, we could grab the reference from the\nmodule. However, this requires a fair bit of C code. It is easier\nto just re-import the original module and get a ref from there. This\nalso avoids problems with caching a type on a reload()d module.","testPlan":"","lineCount":"35","dependsOn":["1767"],"reviewers":["yuja","durin42"],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31066","dateCreated":"1515624888","dateModified":"1515624888"},{"type":"update","diffId":"4737","author":"indygreg","id":"30861","dateCreated":"1515227177","dateModified":"1515227177"},{"type":"inline","comment":"In theory, there could be a mismatch.\n\nIf this module is loaded, its `IndexV1Entry` will refer to whatever `mercurial.pure.parsers.IndexV1Entry` is. If `mercurial.pure.parsers` is then reloaded and its `IndexV1Entry` changes and a revlog index type is created, its `IndexV1Entry` will be the new one from the reloaded `mercurial.pure.parsers`.\n\nSince I plan to replace the Python-implemented type with a C backed type, I'm inclined to not care about this.","replyTo":"30611","isNewFile":"1","line":"2117","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4629","author":"indygreg","id":"30845","dateCreated":"1515222660","dateModified":"1515222660"},{"type":"inline","comment":"Can we be sure that this `IndexV1Entry` is identical to `self->entrytype`\nafter reloading Python modules?","replyTo":null,"isNewFile":"1","line":"2117","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4629","author":"yuja","id":"30611","dateCreated":"1515128067","dateModified":"1515128067"},{"type":"comment","comment":"> We hold off incrementing the version of the \"parsers\" extension\n> because nothing in core relies on the new API yet.\n\nIt's really minor nit, but we have to increment the version since new\ncompiled module doesn't work with old `pure.parsers` module, which\nprovides no IndexV1Entry type.","author":"yuja","id":"30610","dateCreated":"1515128067","dateModified":"1515128067"},{"type":"reject","author":"yuja","id":"30609","dateCreated":"1515128067","dateModified":"1515128067"},{"type":"update","diffId":"4629","author":"indygreg","id":"30079","dateCreated":"1514334955","dateModified":"1514334955"}],"dateCreated":"1514334955","dateModified":"1515624888","status":"Needs Review"},{"id":"1767","callsign":"HG","title":"cext: make nullentry a member of index types","author":"indygreg","summary":"An upcoming commit will change the type of index entries from tuple\nto something else. This type may not be initialized\/available at\nmodule init time.\n\nWe prepare for this future change by making null entries a per-instance\nvariable on the index type.\n\nIn theory, this does add some overhead (a new 8-tuple per index\ninstance). However, the overhead should be negligible compared to\nthe run-time overhead of creating an index entry for each revision\nin the index.","testPlan":"","lineCount":"19","dependsOn":["1766"],"reviewers":["yuja","durin42"],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31065","dateCreated":"1515624888","dateModified":"1515624888"},{"type":"update","diffId":"4736","author":"indygreg","id":"30859","dateCreated":"1515227176","dateModified":"1515227176"},{"type":"inline","comment":"This comment shouldn't be moved. We need to NULLify all attributes, but don't\nhave to create PyObject.","replyTo":null,"isNewFile":"1","line":"1876","lineLength":"0","path":"mercurial\/cext\/revlog.c","diffId":"4628","author":"yuja","id":"30606","dateCreated":"1515124415","dateModified":"1515124415"},{"type":"reject","author":"yuja","id":"30605","dateCreated":"1515124415","dateModified":"1515124415"},{"type":"update","diffId":"4628","author":"indygreg","id":"30069","dateCreated":"1514334953","dateModified":"1514334953"}],"dateCreated":"1514334953","dateModified":"1515624888","status":"Needs Review"},{"id":"1766","callsign":"HG","title":"cext: rename variable describing format for index entries","author":"indygreg","summary":"\"tuple_format\" is ambiguous.","testPlan":"","lineCount":"6","dependsOn":["1765"],"reviewers":["durin42"],"ccs":["mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31063","dateCreated":"1515624887","dateModified":"1515624887"},{"type":"update","diffId":"4627","author":"indygreg","id":"30059","dateCreated":"1514334951","dateModified":"1514334951"}],"dateCreated":"1514334951","dateModified":"1515624887","status":"Accepted"},{"id":"1765","callsign":"HG","title":"parsers: use an attr-derived class for revlog index entries","author":"indygreg","summary":"Currently, revlog index entries are tuples.\n\nThis commit introduces a new type to represent revlog v1 index\nentries. The pure Python parser has been converted to use it.\n\nTo provide backwards compatibility with existing code (including the\nC extension), the type has a __getitem__ to facilitate index\nlookups. The intent is to remove this __getitem__ once all consumers\nare using named attributes.\n\nSince the pure Python index parser is now using our new type,\ntest-parseindex2.py had to be updated to deal with the type mismatch.\nOnce all index parsers are converted and the new type\/interface is\nubiquitous, we can restore the simplicity of test-parseindex2.py. We\nalso had to (temporarily) add \"# no-check-code\" to test-parseindex2.py\nto allow the import of the pure module. This will be removed once the C\nextension is ported.\n\nBecause consumers are going through an extra Python function call to\n__getitem__ to resolve attributes by index, this change regresses\nperformance on a simple DAG walking revset for the Firefox repository:\n\n$ HGMODULEPOLICY=py hg perfrevset '::tip'\n! wall 1.366281 comb 1.360000 user 1.360000 sys 0.000000 (best of 7)\n! wall 1.860068 comb 1.860000 user 1.860000 sys 0.000000 (best of 5)\n\nUsing PyPy, a major regression is not apparent:\n\n! wall 0.163141 comb 0.160000 user 0.160000 sys 0.000000 (best of 56)\n! wall 0.154325 comb 0.160000 user 0.160000 sys 0.000000 (best of 54)","testPlan":"","lineCount":"70","dependsOn":[],"reviewers":["yuja","durin42"],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"accept","author":"durin42","id":"31062","dateCreated":"1515624886","dateModified":"1515624886"},{"type":"update","diffId":"4735","author":"indygreg","id":"30856","dateCreated":"1515227175","dateModified":"1515227175"},{"type":"inline","comment":"Perhaps you mean `list(map(...))` instead of a list of one element?","replyTo":null,"isNewFile":"1","line":"182","lineLength":"0","path":"tests\/test-parseindex2.py","diffId":"4626","author":"yuja","id":"30602","dateCreated":"1515124211","dateModified":"1515124211"},{"type":"reject","author":"yuja","id":"30601","dateCreated":"1515124211","dateModified":"1515124211"},{"type":"update","diffId":"4626","author":"indygreg","id":"30049","dateCreated":"1514334949","dateModified":"1514334949"}],"dateCreated":"1514334949","dateModified":"1515624886","status":"Needs Review"},{"id":"1714","callsign":"FBHGX","title":"distutils_rust: use atomic replace to install the .so file","author":"quark","summary":"Python loads .so using mmap. Rewriting a .so in-place when there is a Python\nprocess with that .so mmap-ed could crash that Python process. Therefore\nlet's avoid rewriting the destination .so in-place.\n\nThis was discovered by a txnclose Python hook I used to keep binaries\nup-to-date. It caused segfault after building the Rust extensions currently\nloaded by the Python process running the hook.","testPlan":"","lineCount":"5","dependsOn":[],"reviewers":["mbthomas"],"ccs":[],"actions":[{"type":"accept","author":"mbthomas","id":"30880","dateCreated":"1515440159","dateModified":"1515440159"},{"type":"update","diffId":"4529","author":"quark","id":"29324","dateCreated":"1513624671","dateModified":"1513624671"}],"dateCreated":"1513624671","dateModified":"1515440159","status":"Accepted"},{"id":"1828","callsign":"FBHGX","title":"morestatus: sync the extension with the logic moved to core","author":"pulkit","summary":"All the functionality of the morestatus extension was moved to core except the\nupdate part. The update part hacks around the update command and stores the\nargument passed before the update. This patch drops the code which was moved to\ncore, wraps the code in core to support the update state functionality. The\nsupport for update in extension is bit hacky as functions which returns helpful\nmessage for each state, does not take a repo argument in core.\n\nEven after this patch, the config options morestatus.show and\nmorestatus.skipstates works the same way as they used to be.\n\nThere are some newlines changes because of bit change in format of output in\ncore.","testPlan":"","lineCount":"209","dependsOn":[],"reviewers":[],"ccs":[],"actions":[{"type":"update","diffId":"4734","author":"pulkit","id":"30852","dateCreated":"1515225678","dateModified":"1515225678"}],"dateCreated":"1515225678","dateModified":"1515225678","status":"Needs Review"},{"id":"1821","callsign":"FBHGX","title":"treemanifest: subclass remotetreedatastore from generatingdatastore","author":"singhsrb","summary":"Introducing class generatingdatastore to represent all stores like\nremotetreedatastore which generate the trees when they are not found in the\nshared store, add them to the shared store, and thereafter, repeat the original\noperation on the shared store expecting it to succeed.","testPlan":"Ran all the tests.","lineCount":"50","dependsOn":["1820"],"reviewers":[],"ccs":[],"actions":[{"type":"update","diffId":"4721","author":"singhsrb","id":"30753","dateCreated":"1515197877","dateModified":"1515197877"}],"dateCreated":"1515197877","dateModified":"1515197910","status":"Needs Review"},{"id":"1820","callsign":"FBHGX","title":"treemanifest: refactor remotetreedatastore call hierarchy","author":"singhsrb","summary":"The plan is to eventually subclass remotetreedatastore and this\nrefactor sets us up nicely for that.","testPlan":"Ran all the tests.","lineCount":"13","dependsOn":[],"reviewers":[],"ccs":[],"actions":[{"type":"update","diffId":"4720","author":"singhsrb","id":"30747","dateCreated":"1515195853","dateModified":"1515195853"}],"dateCreated":"1515195853","dateModified":"1515197910","status":"Needs Review"},{"id":"1805","callsign":"FBHGX","title":"sparse: don't materialize sparse files during IMM","author":"phillco","summary":"There's no need to do this and not doing so speeds up IMM tremendously when the sparse profile had to be adjusted.","testPlan":"I ran an IMM before and after this change. Both succeeded but the later version was\nmuch faster.","lineCount":"10","dependsOn":[],"reviewers":["quark","durham"],"ccs":["durham"],"actions":[{"type":"update","diffId":"4701","author":"phillco","id":"30626","dateCreated":"1515130813","dateModified":"1515130813"},{"type":"inline","comment":"\"mutable\" is tricky since technically on the on-disk working context is mutable too.","replyTo":"30565","isNewFile":"1","line":"82","lineLength":"0","path":"hgext3rd\/fbsparse.py","diffId":"4691","author":"phillco","id":"30625","dateCreated":"1515130763","dateModified":"1515130763"},{"type":"inline","comment":"maybe \"working context\" would work","replyTo":"30564","isNewFile":"1","line":"82","lineLength":"0","path":"hgext3rd\/fbsparse.py","diffId":"4691","author":"phillco","id":"30565","dateCreated":"1515098574","dateModified":"1515098574"},{"type":"inline","comment":"Looks fine. It might be nice to come up with some better terminology. I think of \"working copy\" as always referring to the physical on disk one, so maybe we need some other term for a mutable context (of which working copy would be one type).","replyTo":null,"isNewFile":"1","line":"82","lineLength":"0","path":"hgext3rd\/fbsparse.py","diffId":"4691","author":"durham","id":"30564","dateCreated":"1515097649","dateModified":"1515097649"},{"type":"update","diffId":"4691","author":"phillco","id":"30563","dateCreated":"1515097415","dateModified":"1515097415"},{"type":"comment","comment":"I added a comment and also filed T24918295 for the wider task around allowing lazy filectx writes (but as Durham mentioned that's a strict improvement on the status quo).","author":"phillco","id":"30562","dateCreated":"1515097338","dateModified":"1515097338"},{"type":"update","diffId":"4690","author":"phillco","id":"30561","dateCreated":"1515097206","dateModified":"1515097206"},{"type":"comment","comment":"I'll add a comment.","author":"phillco","id":"30534","dateCreated":"1515093676","dateModified":"1515093676"},{"type":"comment","comment":"Discussed this in person. My concerns were that this would allow large action lists to propagate up and cause excess remotefilelog actions.  Phil's response was that A) this only applies to rebases for now, and any action in the rebase is going to require downloading anyway (when it the sparse profile gets temporarily expanded below), and B) any action on a in memory context should probably not be filtered by sparseness anyway.  I think the invariant in B is reasonable, and if we see it causing problems like A we can reevaluate how to fix that problem to meet invariant B.","author":"durham","id":"30533","dateCreated":"1515092819","dateModified":"1515092819"},{"type":"accept","author":"durham","id":"30532","dateCreated":"1515092819","dateModified":"1515092819"},{"type":"accept","author":"quark","id":"30529","dateCreated":"1515090793","dateModified":"1515090793"},{"type":"update","diffId":"4687","author":"phillco","id":"30524","dateCreated":"1515088883","dateModified":"1515088883"}],"dateCreated":"1515088883","dateModified":"1515130813","status":"Accepted"},{"id":"1743","callsign":null,"title":"p4fastimport: allow sync commits only when imported repository is up-to-date","author":"dsp","summary":"Previously we allowed a sync commit to happen at any time, but imported the\nfull repository to bring it into sync. This is slow for very large repositories\nand might be accidentally triggered. We change this behavior to only do a sync\ncommit if only the imported client changed but nothing else.","testPlan":"  cd tests\n  python ..\/..\/hg-crew\/tests\/run-tests.py test-p4fastimport-*.t test-check*.t","lineCount":"282","dependsOn":["1742"],"reviewers":["kaleyh"],"ccs":["kaleyh"],"actions":[{"type":"inline","comment":"that can be a good idea","replyTo":"30496","isNewFile":"1","line":"134","lineLength":"0","path":"tests\/test-p4fastimport-blobcommit.t","diffId":"4577","author":"kaleyh","id":"30509","dateCreated":"1515016570","dateModified":"1515016570"},{"type":"accept","author":"kaleyh","id":"30508","dateCreated":"1515016570","dateModified":"1515016570"},{"type":"inline","comment":"In case `p4fastimport` uses the new client-spec, it behaves like before: if a file changes it will happily included it. So what we want to do is: use the new-spec only after p4syncimport changed. Maybe in an upcoming change we can save information about the clientspec in Mercurial to automatically detect a change in the p4fastimport case","replyTo":"29849","isNewFile":"1","line":"134","lineLength":"0","path":"tests\/test-p4fastimport-blobcommit.t","diffId":"4577","author":"dsp","id":"30496","dateCreated":"1514922124","dateModified":"1514922124"},{"type":"request-review","author":"dsp","id":"30494","dateCreated":"1514921883","dateModified":"1514921883"},{"type":"inline","comment":"Yes, using the old clientspec it will be able to update it.","replyTo":"29849","isNewFile":"1","line":"134","lineLength":"0","path":"tests\/test-p4fastimport-blobcommit.t","diffId":"4577","author":"dsp","id":"30493","dateCreated":"1514921870","dateModified":"1514921870"},{"type":"inline","comment":"What client will it use if we fall back to `fast import` ? Since CL 5 touches files that are not in the current client spec, will `fast import` be able to update the repo to CL5?","replyTo":null,"isNewFile":"1","line":"134","lineLength":"0","path":"tests\/test-p4fastimport-blobcommit.t","diffId":"4577","author":"kaleyh","id":"29849","dateCreated":"1513982220","dateModified":"1513982220"},{"type":"reject","author":"kaleyh","id":"29848","dateCreated":"1513982220","dateModified":"1513982220"},{"type":"update","diffId":"4577","author":"dsp","id":"29750","dateCreated":"1513905522","dateModified":"1513905522"}],"dateCreated":"1513905522","dateModified":"1515016570","status":"Accepted"},{"id":"1787","callsign":null,"title":"rebase: turn off IMM if any rebased paths match a config","author":"phillco","summary":" ","testPlan":"","lineCount":"21","dependsOn":["1786"],"reviewers":["quark"],"ccs":["quark"],"actions":[{"type":"update","diffId":"4678","author":"phillco","id":"30456","dateCreated":"1514512002","dateModified":"1514512002"},{"type":"update","diffId":"4664","author":"phillco","id":"30334","dateCreated":"1514502802","dateModified":"1514502802"},{"type":"inline","comment":"Could you make this a regular expression?","replyTo":null,"isNewFile":"1","line":"914","lineLength":"0","path":"hgext\/rebase.py","diffId":"4663","author":"quark","id":"30332","dateCreated":"1514500915","dateModified":"1514500915"},{"type":"accept","author":"quark","id":"30331","dateCreated":"1514500915","dateModified":"1514500915"},{"type":"update","diffId":"4663","author":"phillco","id":"30317","dateCreated":"1514500517","dateModified":"1514500517"}],"dateCreated":"1514500517","dateModified":"1514512002","status":"Accepted"},{"id":"1786","callsign":null,"title":"rebase: extract _shoulddisableimm for clarity","author":"phillco","summary":" ","testPlan":"","lineCount":"41","dependsOn":["1785"],"reviewers":["quark"],"ccs":[],"actions":[{"type":"accept","author":"quark","id":"30328","dateCreated":"1514500793","dateModified":"1514500793"},{"type":"update","diffId":"4662","author":"phillco","id":"30310","dateCreated":"1514500514","dateModified":"1514500514"}],"dateCreated":"1514500514","dateModified":"1514500793","status":"Accepted"},{"id":"1785","callsign":null,"title":"rebase: log why we didn't use IMM","author":"phillco","summary":"In preparation for adding more conditions that will disable IMM, let's make\nthis framework more extensible and log the reason IMM wasn't used.\n\nThe `whynotimm` variable name was inspired by the `why_not_eden` name in\n`hg\/eden\/__init__.py`.","testPlan":"","lineCount":"26","dependsOn":[],"reviewers":["quark"],"ccs":[],"actions":[{"type":"inline","comment":"same here","replyTo":null,"isNewFile":"1","line":"996","lineLength":"0","path":"hgext\/rebase.py","diffId":"4661","author":"quark","id":"30326","dateCreated":"1514500758","dateModified":"1514500758"},{"type":"inline","comment":"+3 spaces","replyTo":null,"isNewFile":"1","line":"798","lineLength":"0","path":"hgext\/rebase.py","diffId":"4661","author":"quark","id":"30325","dateCreated":"1514500758","dateModified":"1514500758"},{"type":"accept","author":"quark","id":"30324","dateCreated":"1514500758","dateModified":"1514500758"},{"type":"update","diffId":"4661","author":"phillco","id":"30305","dateCreated":"1514498645","dateModified":"1514498645"}],"dateCreated":"1514498645","dateModified":"1514500758","status":"Accepted"},{"id":"1753","callsign":"HG","title":"streamclone: preserve remote phases (issue5648)","author":"indygreg","summary":"As the tests added by the previous changeset demonstrate, stream clones\nwere never taught about the existence of phases. As a result, all\nchangesets applied via stream clone were made public, even if they\nwere draft (or even secret) on the remote.\n\nThis commit integrates phases knowledge into stream clones.\n\nAs the inline comment explains, because there are scenarios where\nwe can't disambiguate phases support, the resulting phase data may\nnot match the server exactly. However, I believe the remaining\nareas of buggy behavior are confined to secret changesets. Secret\nchangesets aren't common. And transferring them via stream clones\neither requires a buggy Mercurial server or a specially-configured\nserver. I think it will require stream clone support in bundle2\nbefore we can properly handle secret phases for stream clones.\n\nIt \/might\/ be acceptable to force all local changesets to secret\nand then promote to draft or public from remote phases data. However,\nI was having trouble implementing this. Existing phases code doesn't\nseem geared towards supporting this scenario and I didn't want to\nincur a lot of extra work to refactor the phases code. Perfect is\nthe enemy of good: I'm inclined to tackle secret phase as part of\nsupporting stream clones in bundle2.\n\nThis change introduces a `roots(all())` revset, which will require\na linear scan of the changelog during clone bundles. On a Firefox\nrepo, this may slow down stream clones by ~1s. Again, support for\nstream clones in bundle2 should help here.\n\n.. fix::\n\n   Draft changeset phase is now preserved during a stream clone.\n\n   Before, all changesets pulled via a stream clone would have a\n   public phase, even if they were draft on the remote and the remote\n   was non-publishing.","testPlan":"","lineCount":"64","dependsOn":["1752"],"reviewers":["yuja"],"ccs":["yuja","mercurial-devel"],"actions":[{"type":"inline","comment":"Perhaps the remote sends back actual phases data even if it is a publishing server.\nThat's probably why `exchange._pullapplyphases()` checks 'publishing' flag.","replyTo":"30215","isNewFile":"1","line":"191","lineLength":"0","path":"mercurial\/streamclone.py","diffId":"4603","author":"yuja","id":"30280","dateCreated":"1514466877","dateModified":"1514466877"},{"type":"inline","comment":"Maybe.\n\nMy reasoning here was that if the remote advertises phases data, then it is phases aware and the code below will ensure phases are adjusted appropriately. We certainly could special case the mixed phase + publishing case and skip all phase adjustment.","replyTo":"29973","isNewFile":"1","line":"191","lineLength":"0","path":"mercurial\/streamclone.py","diffId":"4603","author":"indygreg","id":"30215","dateCreated":"1514399658","dateModified":"1514399658"},{"type":"inline","comment":"It seems odd that `remotephases` data aren't used at all, but\nI'm not sure.","replyTo":null,"isNewFile":"1","line":"200","lineLength":"0","path":"mercurial\/streamclone.py","diffId":"4603","author":"yuja","id":"29974","dateCreated":"1514293502","dateModified":"1514293502"},{"type":"inline","comment":"Shouldn't we test `remotephases.get('publishing', False)` for\nmixed-phase + publishing server?\n\n","replyTo":null,"isNewFile":"1","line":"191","lineLength":"0","path":"mercurial\/streamclone.py","diffId":"4603","author":"yuja","id":"29973","dateCreated":"1514293502","dateModified":"1514293502"},{"type":"reject","author":"yuja","id":"29972","dateCreated":"1514293502","dateModified":"1514293502"},{"type":"update","diffId":"4603","author":"indygreg","id":"29886","dateCreated":"1514138810","dateModified":"1514138810"}],"dateCreated":"1514138810","dateModified":"1514466877","status":"Needs Revision"},{"id":"1784","callsign":"FBHGX","title":"fbamend: autorestack children for simple rebases","author":"marco.leogrande","summary":"Today, if you run 'hg amend' while in the middle of a stack of\ncommits, it amends the commit and leaves the top of the stack\nbehind. Users then have to run 'hg amend --restack' or 'hg restack' to\nbring the old top of the stack onto the new version of the commit.\n\nAdd heuristic code so that an automatic restack can be performed if\namending a commit did not change its manifest, nor did it leave behind\na dirty working copy. This optimization can be avoided by providing\nthe --no-rebase commandline option.\n\nFix the existing tests that relied on the previous behaviour (so their\noriginal intent is kept), and add new ones to cover the new heuristic.","testPlan":"","lineCount":"107","dependsOn":[],"reviewers":["quark"],"ccs":["quark"],"actions":[{"type":"comment","comment":"Great!","author":"quark","id":"30274","dateCreated":"1514435622","dateModified":"1514435622"},{"type":"accept","author":"quark","id":"30273","dateCreated":"1514435622","dateModified":"1514435622"},{"type":"update","diffId":"4657","author":"marco.leogrande","id":"30271","dateCreated":"1514428200","dateModified":"1514428200"},{"type":"inline","comment":"`debugbuilddag` creates empty commits that requires explicit \"add\" if you changed \"b\". That's doable by using `hg amend -A b` here.","replyTo":null,"isNewFile":"1","line":"899","lineLength":"0","path":"tests\/test-fbamend-restack.t","diffId":"4656","author":"quark","id":"30267","dateCreated":"1514426580","dateModified":"1514426580"},{"type":"inline","comment":"`hg debugbuilddag '+3'` is a more efficient way to create multiple commits. You can use `hg update 'tip^'` in the next line to update to the second commit. That said, I'm fine with just using `mkcommit`.","replyTo":null,"isNewFile":"1","line":"873","lineLength":"2","path":"tests\/test-fbamend-restack.t","diffId":"4656","author":"quark","id":"30266","dateCreated":"1514426580","dateModified":"1514426580"},{"type":"inline","comment":"Since this is user-facing and not everyone knows what \"manifest\" is. It's more friendly to avoid the terminology. Power users may want to disable the feature (ex. if they want to amend multiple commits and then just use restack once to fix them all) but it's not obvious how. Maybe something like \"(auto-rebasing descendants, use --no-rebase to disable this)\"\n\nNote \"children\" and \"descendants\" are different in hg. See `hg help revset` for details.\n","replyTo":null,"isNewFile":"1","line":"278","lineLength":"1","path":"hgext3rd\/fbamend\/__init__.py","diffId":"4656","author":"quark","id":"30265","dateCreated":"1514426580","dateModified":"1514426580"},{"type":"comment","comment":"This looks pretty good. I just have a small request about the user-facing message.","author":"quark","id":"30264","dateCreated":"1514426580","dateModified":"1514426580"},{"type":"reject","author":"quark","id":"30263","dateCreated":"1514426580","dateModified":"1514426580"},{"type":"update","diffId":"4656","author":"marco.leogrande","id":"30258","dateCreated":"1514424219","dateModified":"1514424219"}],"dateCreated":"1514424219","dateModified":"1514435622","status":"Accepted"},{"id":"1752","callsign":"HG","title":"tests: show phases aren't preserved part of streaming clone (issue5648)","author":"indygreg","summary":"draft and secret changesets are promoted to public changesets when\ntransferred via a stream clone. That's not desirable behavior. Add\ntests demonstrating it.\n\nAs far as I can tell, this buggy behavior has been present since\nphases were introduced. Stream clone predated phases (1.7 versus 1.9)\nand stream clone was never taught to be phase aware.","testPlan":"","lineCount":"65","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"4602","author":"indygreg","id":"29880","dateCreated":"1514138808","dateModified":"1514138808"}],"dateCreated":"1514138808","dateModified":"1514138810","status":"Needs Review"},{"id":"1742","callsign":null,"title":"p4fastimport: return the last changelist number that affects the client view","author":"dsp","summary":"Previously we returned the last changelist number of any change a\nclient can see. This includes changes outside of the files specified in the\nview. We now return the last changelist number of files affected by the client\nview.","testPlan":"python ..\/..\/hg-crew\/tests\/run-tests.py test-check* test-p4fastimport*","lineCount":"3","dependsOn":["1741"],"reviewers":["quark"],"ccs":[],"actions":[{"type":"accept","author":"quark","id":"29766","dateCreated":"1513913174","dateModified":"1513913174"},{"type":"update","diffId":"4576","author":"dsp","id":"29741","dateCreated":"1513905502","dateModified":"1513905502"}],"dateCreated":"1513905502","dateModified":"1513913174","status":"Accepted"},{"id":"1741","callsign":null,"title":"p4fastimport: fix symlink test on MacOS","author":"dsp","summary":"On MacOS the resulting symlinks do have a differnt mode and a slightly\ndifferent formatting due to the use of BSD ls.","testPlan":"Ran\n\n  python ..\/..\/hg-crew\/tests\/run-tests.py test-check* test-p4fastimport*\n\nand see it fail on MacOS. After the fix ran it again and see it worked","lineCount":"4","dependsOn":[],"reviewers":["quark"],"ccs":[],"actions":[{"type":"accept","author":"quark","id":"29764","dateCreated":"1513913128","dateModified":"1513913128"},{"type":"update","diffId":"4575","author":"dsp","id":"29736","dateCreated":"1513905500","dateModified":"1513905500"}],"dateCreated":"1513905500","dateModified":"1513913128","status":"Accepted"},{"id":"1621","callsign":"HG","title":"transaction: encodes tuples in changes['phases'] as 4 bit ints","author":"joerg.sonnenberger","summary":"changes['phases'] contains tuples for the phase transitions, which\nprovides a non-trivial overhead in Python. Replace this with a Python\ndictionary containing 4 bit integers. Provide accessors to centralize\nchanges['phases'] procsessing in one place.\n\nOn average, this improves user time for issue5691 by 1% and peak RSS by\n3MB.","testPlan":"","lineCount":"78","dependsOn":[],"reviewers":["quark"],"ccs":["yuja","quark","mercurial-devel"],"actions":[{"type":"comment","comment":"When thinking about it again, I believe providing a way to disable `tr.chanages['phases']` is a better way to solve this issue. If we cannot disable that automatically from what hooks are used, we can still provide a config option to disable that.","author":"quark","id":"29293","dateCreated":"1513404110","dateModified":"1513404110"},{"type":"resign","author":"quark","id":"29292","dateCreated":"1513404110","dateModified":"1513404110"},{"type":"comment","comment":">>! In D1621#28387, @joerg.sonnenberger wrote:\n> The bitset version has shown already that optimizing this is worthwhile and can eliminate up to 10% of the total size of the transaction object.\n\nIIRC, Jun said a plain intbitset wouldn't be optimal for all scenarios, and I agree\nwith that. Also, it isn't a standard Python library.\n\nI think the current way of recording phase change is too ad-hoc if it does iterate\nall incoming nodes to build `(old, new)` phases pairs. Instead, can't we reconstruct\nthem from DAG + old\/new phase roots, for example?\n\nIf the current `tr.changes['phases']` is only used by hooks and third-party\nextensions, it can be opt-in feature.","author":"yuja","id":"28507","dateCreated":"1513084873","dateModified":"1513084873"},{"type":"comment","comment":"The bitset version has shown already that optimizing this is worthwhile and can eliminate up to 10% of the total size of the transaction object.\n\nThe change as is primarily gets the interfaces in place, so that outside code can be adjusted.","author":"joerg.sonnenberger","id":"28387","dateCreated":"1513015530","dateModified":"1513015530"},{"type":"comment","comment":">>! In D1621#28285, @joerg.sonnenberger wrote:\n> This version should be committable. It introduces the necessary API for isolating further changes and gives a small improvement already. I'll be looking at provider a memory and time efficient sparce vector next, that's where the real benefits will be.\n\nI think it's better to hold this change off until we can get a real performance or\nmemory-space win. The current number, \"peak RSS by 3MB\", won't buy much\ncompared to the API complexity this patch will introduce.\n\nRegarding the API, I think `tr.changes[key]` is the source of the problem. It allows\nfree read\/write access to arbitrary data, which is hard to gradually improve the\nunderlying data structure or algorithm.\n\nNoob quesiton. Can't we completely switch of `tr.changes['phases']` when it's\nunnecessary?","author":"yuja","id":"28324","dateCreated":"1513002345","dateModified":"1513002345"},{"type":"comment","comment":"This version should be committable. It introduces the necessary API for isolating further changes and gives a small improvement already. I'll be looking at provider a memory and time efficient sparce vector next, that's where the real benefits will be.","author":"joerg.sonnenberger","id":"28285","dateCreated":"1512940391","dateModified":"1512940391"},{"type":"update","diffId":"4341","author":"joerg.sonnenberger","id":"28282","dateCreated":"1512940262","dateModified":"1512940262"},{"type":"comment","comment":"> Original code: 485s \/ 584MB\n> Set version: 501s \/ 582MB\n> intbitset: 478s \/ 563MB\n\nI'm not sure how to read this. Do we only get -2\/584MB better space\nconsumption against the original simplest implementation?","author":"yuja","id":"27976","dateCreated":"1512825094","dateModified":"1512825094"},{"type":"comment","comment":"That said, I think the usage of list of sets is smart and this change looks good to me.","author":"quark","id":"27917","dateCreated":"1512779148","dateModified":"1512779148"},{"type":"accept","author":"quark","id":"27916","dateCreated":"1512779148","dateModified":"1512779148"},{"type":"inline","comment":"Since this hook is the only user of `tr.changes['phases']`. I'd suggest disabling calculating `tr.changes['phases']` if the hook does not exist.","replyTo":null,"isNewFile":"1","line":"1243","lineLength":"0","path":"mercurial\/localrepo.py","diffId":"4278","author":"quark","id":"27915","dateCreated":"1512778979","dateModified":"1512778979"},{"type":"comment","comment":"This is a Proof-of-Concept and with a follow-up in D1622 to use a C implementation for the bitset.\n\nOriginal code: 485s \/ 584MB\nSet version: 501s \/ 582MB\nintbitset: 478s \/ 563MB\n\n","author":"joerg.sonnenberger","id":"27912","dateCreated":"1512778236","dateModified":"1512778236"},{"type":"update","diffId":"4278","author":"joerg.sonnenberger","id":"27897","dateCreated":"1512777987","dateModified":"1512777987"}],"dateCreated":"1512777987","dateModified":"1513404110","status":"Needs Review"},{"id":"1518","callsign":"FBHGX","title":"nodemap: move some methods to changelog utils","author":"quark","summary":"Those methods and constants will be reused by another module.","testPlan":"","lineCount":"68","dependsOn":[],"reviewers":["jsgf"],"ccs":["jsgf"],"actions":[{"type":"update","diffId":"4461","author":"quark","id":"28995","dateCreated":"1513307716","dateModified":"1513307716"},{"type":"update","diffId":"4455","author":"quark","id":"28981","dateCreated":"1513304499","dateModified":"1513304499"},{"type":"inline","comment":"```\nif rev > i32::MAX as u64 {\n```\n\nYou may need to `use std::i32;`","replyTo":null,"isNewFile":"1","line":"13","lineLength":"0","path":"rust\/indexes\/src\/utils.rs","diffId":"3880","author":"jsgf","id":"27451","dateCreated":"1512667504","dateModified":"1512667504"},{"type":"inline","comment":"(driveby) You can use `b'a'` to get a character value as a `u8`. so `b'a'...b'f' => ch - b'a',`, etc","replyTo":null,"isNewFile":"1","line":"190","lineLength":"2","path":"rust\/indexes\/src\/nodemap.rs","diffId":"3880","author":"jsgf","id":"27450","dateCreated":"1512667504","dateModified":"1512667504"},{"type":"reject","author":"jsgf","id":"27449","dateCreated":"1512667504","dateModified":"1512667504"},{"type":"update","diffId":"3880","author":"quark","id":"25601","dateCreated":"1511807450","dateModified":"1511807450"}],"dateCreated":"1511807450","dateModified":"1513385306","status":"Needs Review"},{"id":"1521","callsign":"FBHGX","title":"clindex: use childmap to calculate phases","author":"quark","summary":"Calculating phases is O(len(changelog)) since it scans revisions starting\nwith min(draft()) (unfiltered). Use the childmap so it is actually\nO(len(not public())).\n\nThis saves 100+ms for a fbsource repo created in late 2015.\n\nBesides, the old phases code build a O(len(changelog)) Python list for\nrev -> phase queries. This patch does not build such list and saves\nO(len(changelog)) memory.","testPlan":"With verify mode on, run core hg tests and make sure there is no\ninconsistent cases with the original phases implementation.","lineCount":"38","dependsOn":["1520"],"reviewers":[],"ccs":[],"actions":[{"type":"update","diffId":"4458","author":"quark","id":"28985","dateCreated":"1513304505","dateModified":"1513304505"},{"type":"update","diffId":"3883","author":"quark","id":"25627","dateCreated":"1511807456","dateModified":"1511807456"}],"dateCreated":"1511807456","dateModified":"1513385283","status":"Needs Review"},{"id":"1426","callsign":"HG","title":"logtoprocess: add the possibility to not start a shell","author":"lothiraldan","summary":"Starting a shell on Windows means starting a console GUI window in almost all\ncases. If we add a logtoprocess for commandfinish and the prompt do some hg\ncalls, it will create a short-lived GUI window which is annoying for end-\nusers.","testPlan":"","lineCount":"14","dependsOn":[],"reviewers":["mbthomas"],"ccs":["mharbison72","durin42","yuja","mbthomas","mercurial-devel"],"actions":[{"type":"comment","comment":"I've resent as https:\/\/phab.mercurial-scm.org\/D1700 because I couldn't get phabsend to reproduce my linear updated stack on phabricator :(","author":"lothiraldan","id":"29059","dateCreated":"1513333033","dateModified":"1513333033"},{"type":"comment","comment":"It works when passing `CREATE_NEW_CONSOLE` instead of `DETACHED_PROCESS | CREATE_NEW_PROCESS_GROUP`.\n\nMy concern now is about changing the behavior, do we want to keep the improvement under a config knob.","author":"lothiraldan","id":"28793","dateCreated":"1513271022","dateModified":"1513271022"},{"type":"comment","comment":"Sorry, I'm not sure what the context is here.  Is this all to resolve %FOO% type variables?  I don't know of any library to do this either.\n\nEarlier this year I tried fixing the logtoprocess test, which was leaving out chunks of output on Windows.  The only notes I left were that the output showed up if DETACHED_PROCESS was removed, but then it flickered a bunch of cmd.exe windows.  IDK how that works, so eventually I gave up and required no-windows.  That said, Yuya's code snippet seems to work for me on Win7 in a python shell.\n\nI don't have time to test tonight, but maybe this will help?  I vaguely remember having luck with SW_HIDE.\n\n  https:\/\/www.codeproject.com\/Articles\/2537\/Running-console-applications-silently\n\n","author":"mharbison72","id":"28773","dateCreated":"1513232248","dateModified":"1513232248"},{"type":"comment","comment":">>! In D1426#28695, @lothiraldan wrote:\n> Without `DETACHED_PROCESS`, no console is spawned either with `shell=False` or `shell=True` **but** Mercurial will wait for the log-to-process script to finish before ending.\n\nNo idea why, but a simple python script running `subprocess.Popen()` exits\nimmediately on my utterly old Windows XP.\n\n```\nimport subprocess\nimport sys\ncreationflags = subprocess.CREATE_NEW_PROCESS_GROUP\nsubprocess.Popen('%s -c \"import time; time.sleep(10)\"' % sys.executable,\n                 shell=True, creationflags=creationflags)\n```\n\n> So I would say to keep `DETACHED_PROCESS`.\n> \n> The real question is how to do variables expansion with `shell=False`, I don't think that Python has a stdlib function for doing that.\n\nEmulating cmd.exe behavior wouldn't be easy. If we had to set `shell=False`,\nwe'd probably better to document the Windows-specific issue.\n\n@mharbison72, do you have any idea?","author":"yuja","id":"28731","dateCreated":"1513173998","dateModified":"1513173998"},{"type":"comment","comment":"Without `DETACHED_PROCESS`, no console is spawned either with `shell=False` or `shell=True` **but** Mercurial will wait for the log-to-process script to finish before ending.\n\nSo I would say to keep `DETACHED_PROCESS`.\n\nThe real question is how to do variables expansion with `shell=False`, I don't think that Python has a stdlib function for doing that.","author":"lothiraldan","id":"28695","dateCreated":"1513155805","dateModified":"1513155805"},{"type":"comment","comment":"I've access to a Windows machine this week, so you can expect a comment or new version before the end of the week.","author":"lothiraldan","id":"28506","dateCreated":"1513068206","dateModified":"1513068206"},{"type":"comment","comment":"Boris, any updates on this?","author":"durin42","id":"28389","dateCreated":"1513015895","dateModified":"1513015895"},{"type":"comment","comment":"Do you think `DETACH_PROCESS` should remain specified? I believe that's\nthe source of the problem, but I can't say it's unnecessary with my little Windows-fu.\n\nWhat I know is our `win32.spawndetached()` sets only `CREATE_NO_WINDOW`.","author":"yuja","id":"26008","dateCreated":"1511959228","dateModified":"1511959228"},{"type":"update","diffId":"3914","author":"lothiraldan","id":"25821","dateCreated":"1511901396","dateModified":"1511901396"},{"type":"comment","comment":">>> `shell=False` also disables envar expansion, and I guess there would\n>>> be lots of trivial behavior changes.\n>> \n>> I'm not sure to understand what you mean, I tried this configuration:\n>> \n>> ```\n>> [logtoprocess]\n>> commandfinish = %HOMEPATH%\/script.pl\n>> ```\n>> \n>> And `%HOMEPATH` seemed to be expanded.\n> \n> Maybe it's resolved while looking up the executable path. I suspect\n> `script.pl %HOMEPATH%` wouldn't work.\n\nWith further testing, I can confirm that `script.pl %HOMEPATH%` is not working on Windows with `shell=False`. I don't know an equivalent of `shlex.split` for Windows, so I guess that documenting it would be enough as we don't force `shell=False`.\n\nI will document it.","author":"lothiraldan","id":"25813","dateCreated":"1511896687","dateModified":"1511896687"},{"type":"comment","comment":">>! In D1426#23803, @lothiraldan wrote:\n>>>! In D1426#23797, @yuja wrote:\n>> Can't we use `openflags=CREATE_NO_WINDOW` instead?\n>> \n>> https:\/\/stackoverflow.com\/a\/7006424\n> \n> I tried lots of things including openflags=CREATE_NO_WINDOW that didn't seem to work, unfortunately.\n\nRight. cmd.exe does allocates new console because the process is \"DETACHED\" from\nthe parent's console. I have no idea if `DETACH_PROCESS` is what we wanted.\n\n>> `shell=False` also disables envar expansion, and I guess there would\n>> be lots of trivial behavior changes.\n> \n> I'm not sure to understand what you mean, I tried this configuration:\n> \n> ```\n> [logtoprocess]\n> commandfinish = %HOMEPATH%\/script.pl\n> ```\n> \n> And `%HOMEPATH` seemed to be expanded.\n\nMaybe it's resolved while looking up the executable path. I suspect\n`script.pl %HOMEPATH%` wouldn't work.","author":"yuja","id":"23804","dateCreated":"1510842452","dateModified":"1510842452"},{"type":"comment","comment":">>! In D1426#23797, @yuja wrote:\n> Can't we use `openflags=CREATE_NO_WINDOW` instead?\n> \n> https:\/\/stackoverflow.com\/a\/7006424\n\nI tried lots of things including openflags=CREATE_NO_WINDOW that didn't seem to work, unfortunately.\n\n> \n> `shell=False` also disables envar expansion, and I guess there would\n> be lots of trivial behavior changes.\n\nI'm not sure to understand what you mean, I tried this configuration:\n\n```\n[logtoprocess]\ncommandfinish = %HOMEPATH%\/script.pl\n```\n\nAnd `%HOMEPATH` seemed to be expanded.","author":"lothiraldan","id":"23803","dateCreated":"1510839765","dateModified":"1510839765"},{"type":"comment","comment":"Can't we use `openflags=CREATE_NO_WINDOW` instead?\n\nhttps:\/\/stackoverflow.com\/a\/7006424\n\n`shell=False` also disables envar expansion, and I guess there would\nbe lots of trivial behavior changes.","author":"yuja","id":"23798","dateCreated":"1510838357","dateModified":"1510838357"},{"type":"inline","comment":"Right, I was not aware of this limitation.\n\nIf a company would deploy the same configuration for both Windows and Linux, we might have `shell=False` on Linux system but it would work well if the script doesn't take any argument or with an intermediary script that injects all the arguments, I will document it in the commit message and extensions documentation.","replyTo":"23570","isNewFile":"1","line":"65","lineLength":"0","path":"hgext\/logtoprocess.py","diffId":"3528","author":"lothiraldan","id":"23793","dateCreated":"1510823364","dateModified":"1510823364"},{"type":"inline","comment":"On unix systems `shell=False` means the command provided cannot take any arguments, as it's the shell that does the argument splitting.  I am guessing that this is OK, as we'll just never configure `logtoprocess.shell` as False on unix systems.  Is that right?","replyTo":null,"isNewFile":"1","line":"65","lineLength":"0","path":"hgext\/logtoprocess.py","diffId":"3528","author":"mbthomas","id":"23570","dateCreated":"1510766283","dateModified":"1510766283"},{"type":"accept","author":"mbthomas","id":"23569","dateCreated":"1510766283","dateModified":"1510766283"},{"type":"update","diffId":"3528","author":"lothiraldan","id":"23538","dateCreated":"1510760656","dateModified":"1510760656"}],"dateCreated":"1510760656","dateModified":"1513333033","status":"Needs Review"},{"id":"1700","callsign":"HG","title":"logtoprocess: pass ui in runshellcommand","author":"lothiraldan","summary":"We are gonna read a configuration specific to Windows, instead of adding a\nuseless arguments for runshellcommand on linux, pass the ui object to read it\ndirectly.","testPlan":"","lineCount":"6","dependsOn":[],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"4467","author":"lothiraldan","id":"29023","dateCreated":"1513332655","dateModified":"1513332655"}],"dateCreated":"1513332655","dateModified":"1513332916","status":"Needs Review"},{"id":"1520","callsign":"FBHGX","title":"clindex: integrate Rust childmap","author":"quark","summary":"Like nodemap, maintain the Rust childmap in clindex. The childmap is pretty\ncompact - only 10% the size of changelog.i in fbsource.","testPlan":"","lineCount":"92","dependsOn":["1519"],"reviewers":[],"ccs":[],"actions":[{"type":"update","diffId":"4457","author":"quark","id":"28984","dateCreated":"1513304503","dateModified":"1513304503"},{"type":"update","diffId":"3882","author":"quark","id":"25618","dateCreated":"1511807454","dateModified":"1511807454"}],"dateCreated":"1511807454","dateModified":"1513307719","status":"Needs Review"},{"id":"1519","callsign":"FBHGX","title":"childmap: add a map for efficient children query","author":"quark","summary":" ","testPlan":"","lineCount":"509","dependsOn":["1518"],"reviewers":[],"ccs":[],"actions":[{"type":"update","diffId":"4462","author":"quark","id":"28998","dateCreated":"1513307718","dateModified":"1513307718"},{"type":"update","diffId":"4456","author":"quark","id":"28983","dateCreated":"1513304501","dateModified":"1513304501"},{"type":"update","diffId":"3881","author":"quark","id":"25610","dateCreated":"1511807452","dateModified":"1511807452"}],"dateCreated":"1511807452","dateModified":"1513307718","status":"Needs Review"},{"id":"1534","callsign":"HG","title":"logtoprocess: add an option to parse script command","author":"lothiraldan","summary":"With `shell=False`, the logtoprocess script will not be parsed by a shell and\nwe won't be able to pass arguments in logtoprocess configuration. Add a new\noption `logtoprocess.parsescript` that calls `shlex.split` on the script so we\ncan pass arguments. As `shlex.split` is only designed for POSIX system, this\noption have no impact on Windows.","testPlan":"","lineCount":"16","dependsOn":["1426"],"reviewers":[],"ccs":["mercurial-devel"],"actions":[{"type":"update","diffId":"3915","author":"lothiraldan","id":"25823","dateCreated":"1511901399","dateModified":"1511901399"}],"dateCreated":"1511901399","dateModified":"1513269543","status":"Needs Review"},{"id":"1330","callsign":"FBHGX","title":"hgext3rd: add hg continue and hg abort","author":"phillco","summary":"I hate having to remember and type which command I need to abort or continue.\nWhy make the user do that work? Life is short, and we already know what\nstatefiles exist and how to deal with them.\n\nWe could even have it loop until no statefiles are left, to deal with issues\nwhere both a rebase state and a merge state are left.","testPlan":"","lineCount":"63","dependsOn":[],"reviewers":["quark","durham"],"ccs":["durham","quark"],"actions":[{"type":"inline","comment":"Yeh, that's fair. It's a shame merge (the command) doesn't have a distinct statefile from merge.update (the function). Since we don't need to support the `hg merge` case at FB, I'll just have it detect the merge state file and print something in that case.","replyTo":"22386","isNewFile":"1","line":"68","lineLength":"0","path":"hgext3rd\/conflictinfo.py","diffId":"3348","author":"phillco","id":"22398","dateCreated":"1510247720","dateModified":"1510247720"},{"type":"inline","comment":"Can we print a message saying what we're continueing\/aborting?  Like \"continuing rebase (via hg rebase --continue) ...\" or \"aborting merge (via hg update --clean) ...\".  That way users know what action is being continued and knows what actually happening so they can figure out how to undo it if necessary.","replyTo":null,"isNewFile":"1","line":"34","lineLength":"0","path":"hgext3rd\/continue.py","diffId":"3348","author":"durham","id":"22387","dateCreated":"1510245420","dateModified":"1510245420"},{"type":"inline","comment":"Is merge\/state used in any case other than hg merge? I have this feeling it is?  If so, update --clean could lose user data and I don't think it's necessarily clear that 'hg abort' would do that.","replyTo":null,"isNewFile":"1","line":"68","lineLength":"0","path":"hgext3rd\/conflictinfo.py","diffId":"3348","author":"durham","id":"22386","dateCreated":"1510245420","dateModified":"1510245420"},{"type":"comment","comment":"Probably needs a test once it's not a POC","author":"durham","id":"22385","dateCreated":"1510245420","dateModified":"1510245420"},{"type":"reject","author":"durham","id":"22384","dateCreated":"1510245420","dateModified":"1510245420"},{"type":"inline","comment":"Add the `from __future__ import absolute_import` here.","replyTo":null,"isNewFile":"1","line":"7","lineLength":"0","path":"hgext3rd\/continue.py","diffId":"3348","author":"quark","id":"22268","dateCreated":"1510169291","dateModified":"1510169291"},{"type":"inline","comment":"Use `from . import conflicttinfo` instead.","replyTo":null,"isNewFile":"1","line":"20","lineLength":"0","path":"hgext3rd\/continue.py","diffId":"3348","author":"quark","id":"22267","dateCreated":"1510169291","dateModified":"1510169291"},{"type":"update","diffId":"3348","author":"phillco","id":"22256","dateCreated":"1510162410","dateModified":"1510162410"},{"type":"inline","comment":"It might be obviated by your suggestion. I think it's related to dispatching twice. I'll debug it more if we actually want to go this way.","replyTo":"22072","isNewFile":"1","line":"127","lineLength":"1","path":"hgext3rd\/undo.py","diffId":"3317","author":"phillco","id":"22075","dateCreated":"1510092299","dateModified":"1510092299"},{"type":"inline","comment":"That might work better. I'll try it.","replyTo":"22071","isNewFile":"1","line":"27","lineLength":"0","path":"hgext3rd\/continue.py","diffId":"3317","author":"phillco","id":"22074","dateCreated":"1510092299","dateModified":"1510092299"},{"type":"inline","comment":"Why is this change?","replyTo":null,"isNewFile":"1","line":"127","lineLength":"1","path":"hgext3rd\/undo.py","diffId":"3317","author":"quark","id":"22072","dateCreated":"1510092104","dateModified":"1510092104"},{"type":"inline","comment":"Instead of issuing a new dispatch request, you can lookup the command function using `cmdutil.findcmd` and execute that function directly.","replyTo":null,"isNewFile":"1","line":"27","lineLength":"0","path":"hgext3rd\/continue.py","diffId":"3317","author":"quark","id":"22071","dateCreated":"1510092104","dateModified":"1510092104"},{"type":"reject","author":"quark","id":"22070","dateCreated":"1510092104","dateModified":"1510092104"},{"type":"update","diffId":"3317","author":"phillco","id":"22034","dateCreated":"1510080495","dateModified":"1510080495"},{"type":"update","diffId":"3316","author":"phillco","id":"22033","dateCreated":"1510080441","dateModified":"1510080441"},{"type":"update","diffId":"3315","author":"phillco","id":"22029","dateCreated":"1510080374","dateModified":"1510080374"}],"dateCreated":"1510080374","dateModified":"1513209943","status":"Needs Revision"},{"id":"1665","callsign":"FBHGX","title":"perftweaks: pass a correct revgen to branchcache.update","author":"quark","summary":"The revgen parameter cannot be null. Otherwise the \"for i in None\" code path\nwill be executed if disablebranchcache is False while disablebranchcache2 is\nTrue.","testPlan":"","lineCount":"2","dependsOn":[],"reviewers":[],"ccs":[],"actions":[{"type":"update","diffId":"4373","author":"quark","id":"28483","dateCreated":"1513039161","dateModified":"1513039161"}],"dateCreated":"1513039161","dateModified":"1513039161","status":"Needs Review"},{"id":"1622","callsign":"HG","title":"[PoC] transaction: Use intbitset for implementing changes['phase']","author":"joerg.sonnenberger","summary":" ","testPlan":"","lineCount":"4","dependsOn":["1621"],"reviewers":["yuja"],"ccs":["yuja","quark","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D1622#27981, @joerg.sonnenberger wrote:\n> Like I said, this is primarily a proof of concept. I'm still playing with different approaches\n\nAh, okay. I've added [PoC] to the subject so this won't be queued by mistake.\n\nFWIW, we generally don't move codes to C unless there is significant improvement.\n\n","author":"yuja","id":"28278","dateCreated":"1512904090","dateModified":"1512904090"},{"type":"comment","comment":"Like I said, this is primarily a proof of concept. I'm still playing with different approaches and I don't think intbitset is a good fit for other reasons, but it worked the best from the various pre-existing implementations.","author":"joerg.sonnenberger","id":"27981","dateCreated":"1512832551","dateModified":"1512832551"},{"type":"comment","comment":"> Although this is definitely better for the clone case. intbitset does not seem to implement segmented bitsets so the memory usage could in theory be worse for other cases.\n\nPerhaps. And if we need to iterate a sparse bitset, the performance would\nbe way worse.\n","author":"yuja","id":"27979","dateCreated":"1512825512","dateModified":"1512825512"},{"type":"reject","author":"yuja","id":"27978","dateCreated":"1512825512","dateModified":"1512825512"},{"type":"inline","comment":"It's still worthwhile to have `set()` as a fallback. So the code runs in pure python or pypy environment","replyTo":null,"isNewFile":"1","line":"1283","lineLength":"0","path":"mercurial\/localrepo.py","diffId":"4279","author":"quark","id":"27920","dateCreated":"1512779474","dateModified":"1512779474"},{"type":"comment","comment":"Although this is definitely better for the clone case. intbitset does not seem to implement segmented bitsets so the memory usage could in theory be worse for other cases.","author":"quark","id":"27919","dateCreated":"1512779474","dateModified":"1512779474"},{"type":"update","diffId":"4279","author":"joerg.sonnenberger","id":"27903","dateCreated":"1512777992","dateModified":"1512777992"}],"dateCreated":"1512777992","dateModified":"1512904090","status":"Needs Revision"},{"id":"1618","callsign":"FBHGX","title":"infinitepush: write backup state file atomically","author":"stash","summary":"","testPlan":"Run infinitepush tests","lineCount":"2","dependsOn":[],"reviewers":["mbthomas","quark"],"ccs":["quark"],"actions":[{"type":"inline","comment":"`json.dump({...}, f)` could avoid creating the temporary string. Although it probably does not make a visible difference here.","replyTo":null,"isNewFile":"1","line":"842","lineLength":"0","path":"infinitepush\/backupcommands.py","diffId":"4255","author":"quark","id":"27946","dateCreated":"1512788509","dateModified":"1512788509"},{"type":"accept","author":"quark","id":"27945","dateCreated":"1512788509","dateModified":"1512788509"},{"type":"update","diffId":"4255","author":"stash","id":"27810","dateCreated":"1512751899","dateModified":"1512751899"}],"dateCreated":"1512751899","dateModified":"1512788509","status":"Accepted"},{"id":"1593","callsign":"FBHGX","title":"infinitepush: remove duplicated logic for storing changegroups","author":"pulkit","summary":"Before this patch, we had same code in parthandler for scratchbranchparttype and\nprocesspart where we override bundle2.processpart and add storing changegroup\nlogic if we get scratchbranchparttype.\n\nSince we have all this logic in parthandler, we can just go ahead and process\nthe scratchbranchparttype instead of adding it in processparts().","testPlan":"","lineCount":"24","dependsOn":[],"reviewers":["durham"],"ccs":[],"actions":[{"type":"inline","comment":"Ah, thanks for the explanation. I got confused by the exact same code and variable names.","replyTo":"27688","isNewFile":"0","line":"1125","lineLength":"0","path":"infinitepush\/__init__.py","diffId":"4121","author":"pulkit","id":"27689","dateCreated":"1512694616","dateModified":"1512694616"},{"type":"inline","comment":"This one is storing the entire bundler though.  So every part that was added to the bundler above is in the infinitepush stored bundle.  The standard scratchbranchparttype part handler would result in a bundle that only contained the changegroup part.  So the new code allows us to produce a bundle that contain parts like obsmarkers and stuff.","replyTo":"27659","isNewFile":"0","line":"1125","lineLength":"0","path":"infinitepush\/__init__.py","diffId":"4121","author":"durham","id":"27688","dateCreated":"1512693851","dateModified":"1512693851"},{"type":"inline","comment":"@durham I am referring to this part handler part. It has the same logic which I deleted above.","replyTo":null,"isNewFile":"0","line":"1254","lineLength":"0","path":"infinitepush\/__init__.py","diffId":"4121","author":"pulkit","id":"27660","dateCreated":"1512685256","dateModified":"1512685256"},{"type":"inline","comment":"There is part handler defined for that already which has exact same logic which I just deleted. The only difference I see is that, in this case, we are storing changegroup in the end, while that won't be executed in the end.","replyTo":"27630","isNewFile":"0","line":"1125","lineLength":"0","path":"infinitepush\/__init__.py","diffId":"4121","author":"pulkit","id":"27659","dateCreated":"1512685256","dateModified":"1512685256"},{"type":"inline","comment":"If we delete this code, when does this bundler get processed? I think the purpose of having this serialization logic is so that every other part in the bundle gets processed above first, and then we serialize it here.  Without this code here, then the bundler is just thrown away and all the parts that were added to it are lost, and the only serialization ends up being from the scratchbranchparttype processing, which doesn't handle the other parts.\n\nOr am I forgetting something?","replyTo":null,"isNewFile":"0","line":"1125","lineLength":"0","path":"infinitepush\/__init__.py","diffId":"4121","author":"durham","id":"27630","dateCreated":"1512683960","dateModified":"1512683960"},{"type":"reject","author":"durham","id":"27629","dateCreated":"1512683960","dateModified":"1512683960"},{"type":"comment","comment":"All the `test-infinitepush-*` skips for me except one, so I am not sure whether this breaks something or not. Any help on how can I run the test locally will be of great help.","author":"pulkit","id":"27072","dateCreated":"1512501221","dateModified":"1512501221"},{"type":"update","diffId":"4121","author":"pulkit","id":"27067","dateCreated":"1512501082","dateModified":"1512501082"}],"dateCreated":"1512501082","dateModified":"1512694616","status":"Needs Revision"},{"id":"1594","callsign":"FBHGX","title":"prune: only prompt uncommit when revs = ['.']","author":"quark","summary":"This is a follow-up of D1335.\n\n`uncommit` only works for the dot revision. Therefore the advice shouldn't\nbe visible when stripping other revisions.\n\nBesides, added missing i18n functions and added a test.","testPlan":"","lineCount":"40","dependsOn":[],"reviewers":["mitrandir"],"ccs":[],"actions":[{"type":"update","diffId":"4122","author":"quark","id":"27080","dateCreated":"1512504540","dateModified":"1512504540"}],"dateCreated":"1512504540","dateModified":"1512506757","status":"Needs Review"},{"id":"1542","callsign":"FBHGX","title":"fbamend: prevent amending only some changes with --rebase\/fixup","author":"tja","summary":"When calling hg amend --rebase <some files>,\na subsequent rebase fails if <some files> doesn't cover\nall the changes in the working copy.\n\nAs there is currently no code for shelving\/unshelving\nthe remaining changes, let's switch off this\ncombination of options for now, to avoid\ngetting people into failed rebase situations.\n\n--fixup can't work for the same reasons.","testPlan":"$ cd fb-hgext\/tests rt\n# Ran 232 tests, 21 skipped, 0 failed.","lineCount":"9","dependsOn":[],"reviewers":["quark"],"ccs":["quark"],"actions":[{"type":"comment","comment":"Probably also defend against:\n\n    --interactive\n    --include\n    --exclude\n\n","author":"quark","id":"26055","dateCreated":"1511984854","dateModified":"1511984871"},{"type":"accept","author":"quark","id":"26054","dateCreated":"1511984854","dateModified":"1511984854"},{"type":"update","diffId":"3961","author":"tja","id":"26014","dateCreated":"1511965164","dateModified":"1511965164"}],"dateCreated":"1511965164","dateModified":"1511984854","status":"Accepted"},{"id":"1312","callsign":"FBHGX","title":"packfiles: add hg debugpackstatus","author":"phillco","summary":"@akushner thought it'd be helpful to have a dedicated debug command to run if packfile unpleasantness is suspected, and I thought it'd be useful too.\n\nAlso added some missing metrics on remotefilelog stores.","testPlan":"","lineCount":"171","dependsOn":[],"reviewers":["singhsrb","durham"],"ccs":["quark","durham","akushner"],"actions":[{"type":"inline","comment":"Interesting, I didn't know you could chain them. I'll take the shorter way.","replyTo":"25994","isNewFile":"1","line":"385","lineLength":"2","path":"remotefilelog\/debugcommands.py","diffId":"3887","author":"phillco","id":"26005","dateCreated":"1511936991","dateModified":"1511936991"},{"type":"inline","comment":"Yeah, it doesn't matter today but I was looking ahead if we were to generalize this function \/ move it into a util. Then I'd expect it to behave the Ruby way too (or at least have a different name, like `filterfalsy`).","replyTo":"25993","isNewFile":"1","line":"377","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3887","author":"phillco","id":"26004","dateCreated":"1511936991","dateModified":"1511936991"},{"type":"inline","comment":"Maybe more common in Python:\n\n  [p for s in store.stores if s for p in getpaths(s)]\n\nIt's much shorter. Although I personally do not enjoy list comprehensive that much.","replyTo":null,"isNewFile":"1","line":"385","lineLength":"2","path":"remotefilelog\/debugcommands.py","diffId":"3887","author":"quark","id":"25994","dateCreated":"1511927497","dateModified":"1511927497"},{"type":"inline","comment":"Yes. Whether `0` or `[]` should be `False` is a separate topic (I personally prefer the Ruby\/Lua way - only `nil` and `false` are False). It seems you're using it to filter paths, which is fine I guess?","replyTo":"25992","isNewFile":"1","line":"377","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3887","author":"quark","id":"25993","dateCreated":"1511927497","dateModified":"1511927497"},{"type":"inline","comment":"@quark looks like that removes other falsy values too, like 0. But, I guess that is desirable?","replyTo":"25933","isNewFile":"1","line":"377","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3887","author":"phillco","id":"25992","dateCreated":"1511921930","dateModified":"1511921930"},{"type":"inline","comment":"clever, thx","replyTo":"25934","isNewFile":"1","line":"47","lineLength":"0","path":"remotefilelog\/basestore.py","diffId":"3887","author":"phillco","id":"25991","dateCreated":"1511921930","dateModified":"1511921930"},{"type":"inline","comment":"No need to split.","replyTo":"25657","isNewFile":"1","line":"202","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3887","author":"quark","id":"25935","dateCreated":"1511917343","dateModified":"1511917343"},{"type":"inline","comment":"Maybe just `count = len(list(self._listkeys())` since that's shorter and does not need placeholders","replyTo":null,"isNewFile":"1","line":"47","lineLength":"0","path":"remotefilelog\/basestore.py","diffId":"3887","author":"quark","id":"25934","dateCreated":"1511917343","dateModified":"1511917343"},{"type":"inline","comment":"Could you use `filter(None, list)`? It is more common in python.","replyTo":"25931","isNewFile":"1","line":"377","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3887","author":"quark","id":"25933","dateCreated":"1511917343","dateModified":"1511917343"},{"type":"inline","comment":"It's based on Ruby\/Underscore.js's name for the same function. Then again, who ever said Ruby was a paragon of naming?","replyTo":"25918","isNewFile":"1","line":"377","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3887","author":"phillco","id":"25931","dateCreated":"1511916796","dateModified":"1511916796"},{"type":"inline","comment":"I'd use the words \"File Data Store\" and \"File History Store\" in the user facing code.  content and metadata were old terms and should probably be replaced throughout the code.","replyTo":null,"isNewFile":"1","line":"416","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3887","author":"durham","id":"25919","dateCreated":"1511915533","dateModified":"1511915533"},{"type":"inline","comment":"I'd rename this 'removenone' or something.","replyTo":null,"isNewFile":"1","line":"377","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3887","author":"durham","id":"25918","dateCreated":"1511915533","dateModified":"1511915533"},{"type":"accept","author":"durham","id":"25917","dateCreated":"1511915533","dateModified":"1511915533"},{"type":"inline","comment":"Not really related, but I noticed that `debugdatapack` aborted too early if one of the paths had any errors. I could split this out if you think it's warranted.","replyTo":null,"isNewFile":"1","line":"202","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3887","author":"phillco","id":"25657","dateCreated":"1511813176","dateModified":"1511813176"},{"type":"comment","comment":"I flushed this out a bit since the last change, adding `getmetrics()` to `datapackstore` and printing the paths for remotefilelog stores, too.","author":"phillco","id":"25656","dateCreated":"1511813176","dateModified":"1511813176"},{"type":"update","diffId":"3887","author":"phillco","id":"25655","dateCreated":"1511812988","dateModified":"1511812988"},{"type":"update","diffId":"3886","author":"phillco","id":"25654","dateCreated":"1511812858","dateModified":"1511812858"},{"type":"plan-changes","author":"phillco","id":"23792","dateCreated":"1510814137","dateModified":"1510814137"},{"type":"update","diffId":"3564","author":"phillco","id":"23790","dateCreated":"1510813934","dateModified":"1510813934"},{"type":"inline","comment":"os.path.join(self._getrootpath(), fnhashhex[:2], fnhashhex[2:]) would be the more platform agnostic way of doing this.","replyTo":null,"isNewFile":"1","line":"58","lineLength":"1","path":"remotefilelog\/basestore.py","diffId":"3509","author":"durham","id":"23657","dateCreated":"1510790200","dateModified":"1510790200"},{"type":"comment","comment":"Needs a test","author":"durham","id":"23656","dateCreated":"1510790200","dateModified":"1510790200"},{"type":"reject","author":"durham","id":"23655","dateCreated":"1510790200","dateModified":"1510790200"},{"type":"inline","comment":"From our IRL chat, added `verbose=False`.","replyTo":"21913","isNewFile":"1","line":"58","lineLength":"0","path":"remotefilelog\/basestore.py","diffId":"3289","author":"phillco","id":"23471","dateCreated":"1510716288","dateModified":"1510716288"},{"type":"comment","comment":"Ready for another look. Please check my C.","author":"phillco","id":"23470","dateCreated":"1510716288","dateModified":"1510716288"},{"type":"update","diffId":"3509","author":"phillco","id":"23468","dateCreated":"1510716229","dateModified":"1510716229"},{"type":"update","diffId":"3507","author":"phillco","id":"23465","dateCreated":"1510715278","dateModified":"1510715278"},{"type":"update","diffId":"3506","author":"phillco","id":"23464","dateCreated":"1510715111","dateModified":"1510715111"},{"type":"comment","comment":".","author":"phillco","id":"22115","dateCreated":"1510119235","dateModified":"1510119235"},{"type":"plan-changes","author":"phillco","id":"22114","dateCreated":"1510119235","dateModified":"1510119235"},{"type":"update","diffId":"3331","author":"phillco","id":"22109","dateCreated":"1510119227","dateModified":"1510119227"},{"type":"inline","comment":"We may want a try\/catch around all of these metric functions that call _getfiles.  _getfiles could throw an exception if the directory isn't readable for some reason, and we don't want metric logging code to bring down the process.  Or we add the try\/catch to _getfiles or _listkeys and print a warning if the directory is inaccesible, then return an empty list.","replyTo":null,"isNewFile":"1","line":"45","lineLength":"0","path":"remotefilelog\/basestore.py","diffId":"3289","author":"durham","id":"21916","dateCreated":"1509995914","dateModified":"1509995914"},{"type":"inline","comment":"If we're just getting the file size, we can use _listkeys to get the information necessary to compute the file path to get the size.","replyTo":null,"isNewFile":"1","line":"54","lineLength":"0","path":"remotefilelog\/basestore.py","diffId":"3289","author":"durham","id":"21915","dateCreated":"1509995914","dateModified":"1509995914"},{"type":"inline","comment":"If we're just counting, we can use _listkeys() instead, so we don't have to resolve the filenames.","replyTo":null,"isNewFile":"1","line":"46","lineLength":"0","path":"remotefilelog\/basestore.py","diffId":"3289","author":"durham","id":"21914","dateCreated":"1509995914","dateModified":"1509995914"},{"type":"inline","comment":"Isn't getmetrics called at store creation time now?  By your previous diff.  If so, getnumfiles is expensive right?  How do we ensure that we don't accidentally call getnumfiles every time we want to log metrics.","replyTo":null,"isNewFile":"1","line":"58","lineLength":"0","path":"remotefilelog\/basestore.py","diffId":"3289","author":"durham","id":"21913","dateCreated":"1509995914","dateModified":"1509995914"},{"type":"inline","comment":"I'd write out the full name `debugpackstatus`.  `st` isn't a super common acronym in the code base.","replyTo":null,"isNewFile":"1","line":"271","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3289","author":"durham","id":"21912","dateCreated":"1509995914","dateModified":"1509995914"},{"type":"reject","author":"durham","id":"21911","dateCreated":"1509995914","dateModified":"1509995914"},{"type":"update","diffId":"3289","author":"phillco","id":"21864","dateCreated":"1509935138","dateModified":"1509935138"},{"type":"update","diffId":"3266","author":"phillco","id":"21700","dateCreated":"1509736600","dateModified":"1509736600"}],"dateCreated":"1509736600","dateModified":"1511936991","status":"Accepted"},{"id":"1524","callsign":"FBHGX","title":"morestatus: drop the extension as it was moved to core","author":"pulkit","summary":"This patch drops the morestatus extension as the functionality was directly\nmoved to core as `hg status -v` or can be used by setting config\n`commands.status.verbose` to True.\n\nNote: The update part of the morestatus was not ported to core as that wraps\nupdate command to save the args and dropping the extensions results in\nfunctionality lose of showing conflict state of hg update. But I think that\ncan't happen at Fb as `hg update` aborts if the working directory is dirty as\nmentioned in tweakdefaults.py.","testPlan":"","lineCount":"441","dependsOn":[],"reviewers":["quark"],"ccs":["quark"],"actions":[{"type":"comment","comment":"The update part can happen if users pressed Ctrl+C during a long update. So we still want that feature.","author":"quark","id":"25871","dateCreated":"1511910092","dateModified":"1511910092"},{"type":"reject","author":"quark","id":"25870","dateCreated":"1511910092","dateModified":"1511910092"},{"type":"update","diffId":"3896","author":"pulkit","id":"25678","dateCreated":"1511819079","dateModified":"1511819079"}],"dateCreated":"1511819079","dateModified":"1511910092","status":"Needs Revision"},{"id":"1525","callsign":"FBHGX","title":"fold: support user template in json output","author":"pulkit","summary":"This patch syncs the JSON output of fold command with that of core Mercurial\nextensions. For reference: https:\/\/phab.mercurial-scm.org\/D1293","testPlan":"","lineCount":"8","dependsOn":["1524"],"reviewers":[],"ccs":[],"actions":[{"type":"update","diffId":"3897","author":"pulkit","id":"25683","dateCreated":"1511819085","dateModified":"1511819085"}],"dateCreated":"1511819085","dateModified":"1511819085","status":"Needs Review"},{"id":"1506","callsign":"HG","title":"dagop: handle IndexError when using wdir() in dag range","author":"swhitaker","summary":"Using wdir() in a dag range revset can crash Mercurial. For example:\n\n    hg status --rev '.^::wdir()\n\nrevlog.c reports an IndexError in this instance, but it isn't caught\nby the calling code. This change adds IndexError to the set of exception\ntypes the calling code catches. When an IndexError is caught, the code\nfalls back to calling the pure Python implementation of reachableroots,\nwhich fails gracefully.","testPlan":"$ hg status --rev '.::wdir()'\nabort: working directory revision cannot be specified","lineCount":"2","dependsOn":[],"reviewers":["mbthomas","yuja"],"ccs":["ryanmce","yuja","mercurial-devel"],"actions":[{"type":"comment","comment":">>! In D1506#25509, @ryanmce wrote:\n> but ideally, wouldn't this be supported?\n\nYeah, this case, `includepath=True`, won't be difficult to handle. If reachableroots() raised\nWdirUnsupportedError, drop wdir revision from `y` of `x::y`, add parents instead, rerun\n`x::(y - wdir() + parents(wdir()))`, and append wdir to the result.","author":"yuja","id":"25511","dateCreated":"1511704872","dateModified":"1511704872"},{"type":"comment","comment":"I understand that fixing the crash is a good first step, but ideally, wouldn't this be supported? Is there a reason it's particularly hard to support?","author":"ryanmce","id":"25510","dateCreated":"1511689355","dateModified":"1511689355"},{"type":"comment","comment":"I think it's better to fail fast instead of trying the slow path which is supposed\nto raise WdirUnsupported exception.\n\n> $ hg status --rev '.::wdir()'\n> abort: working directory revision cannot be specified\n\nCan you add test?","author":"yuja","id":"25487","dateCreated":"1511582067","dateModified":"1511582067"},{"type":"reject","author":"yuja","id":"25486","dateCreated":"1511582067","dateModified":"1511582067"},{"type":"accept","author":"mbthomas","id":"25372","dateCreated":"1511541089","dateModified":"1511541089"},{"type":"update","diffId":"3813","author":"swhitaker","id":"25358","dateCreated":"1511525215","dateModified":"1511525215"}],"dateCreated":"1511525215","dateModified":"1511704872","status":"Needs Revision"},{"id":"474","callsign":"FBHGX","title":"perftweaks: store rev to node mapping for preloading","author":"mbthomas","summary":"Change perftweaks to store the node-to-rev mapping for interesting\nrevisions, rather than just the rev numbers.\n\nPreviously this was used to prepopulate the changelog's node-to-rev\nlookup trie, however since we only stored the revision numbers this\nstill required looking at the revlog index contents in order to\nread out the node hash.\n\nWith these changes, the trie can be prepopulated without touching\nthe index.\n\nOn its own, this gives only a modest performance increase, however\nwhen combined with using mmap for the revlog index (coming in\nanother diff), it gives a noticable improvment on repos with very\nlarge revlogs, as we no longer need to touch large portions of the\nrevlog index on every invocation.\n\nWhen loading the cache data, we check that the rev numbers are\nin range for the revlog, and drop any entries that are out of\nrange.  The assumption is that a node hash won't be reassigned to\nanother rev index.  The other way round ought to be ok, as the\nold hash ought to be abandoned if it's no longer part of the\nrevlog.  If there's any more checking needed, please suggest in\nthe review comments.","testPlan":"Re-run unit tests.\nGenerate cache data on a large repo and verify indexes can be\npreloaded without touching the index contents.\nRun with mmap change to verify perf improvement.","lineCount":"64","dependsOn":[],"reviewers":["durham"],"ccs":["quark"],"actions":[{"type":"comment","comment":"This is no longer needed after D1472.","author":"quark","id":"25010","dateCreated":"1511320901","dateModified":"1511320901"},{"type":"inline","comment":"Is this better than `revstr, node = line.split(':')`?\n\nAlso, mercurial generally avoids using `_` for unused variables, because `_` is already the function name for the string internationalization function.  I usually use `x` or some such","replyTo":null,"isNewFile":"1","line":"223","lineLength":"0","path":"hgext3rd\/perftweaks.py","diffId":"1155","author":"durham","id":"8042","dateCreated":"1503593933","dateModified":"1503593933"},{"type":"comment","comment":"I think we want to be pretty conservative about cache invalidation initially.  If we get the map wrong, we could end up reading entirely incorrect data out of the changelog and associating it with the incorrect node.  A few ideas:\n\n- We could initially treat the cache as risky, and instead of using the data we could just confirm that the data is always correct, by comparing the getnode(rev) result with our stored node->rev. If our cache doesn't match the truth, print a ui.develwarn so we see it.  Once we have confidence, we can actually use the map result instead of calling getnode(rev).\n- We should invalidate the entire cache when `repo.destroyed()` is called.  That is the function called at the end of a strip, to let extensions perform invalidation like this.\n- Maybe we could only use the cached mappings for commits older than `tip - 10000`.  Any node that claims to be newer than tip-10000 we could do getnode(rev) and put the actual node value in the nodemap instead.  Since the The top of the changelog is where the most churn happens and where the most risk will be, this should help prevent most bad cache issues and shouldn't add much IO slow down (10k revs is only 620KB of .i file)","author":"durham","id":"8041","dateCreated":"1503593933","dateModified":"1503593933"},{"type":"reject","author":"durham","id":"8040","dateCreated":"1503593933","dateModified":"1503593933"},{"type":"update","diffId":"1155","author":"mbthomas","id":"7443","dateCreated":"1503406015","dateModified":"1503406015"}],"dateCreated":"1503406015","dateModified":"1511320901","status":"Needs Revision"},{"id":"1453","callsign":"FBHGX","title":"remotefilelog: never deadlock on writing to a pipe","author":"ikostia","summary":"Instead of guesstimating that 10000 (or any fixed number) steps\nalways fit in a buffer, we can just count the bytes as we write.\n\nDepends on D1436","testPlan":"- not tested yet","lineCount":"28","dependsOn":[],"reviewers":["durham"],"ccs":["durham","wlis"],"actions":[{"type":"inline","comment":"`i += 1`","replyTo":null,"isNewFile":"1","line":"238","lineLength":"0","path":"remotefilelog\/fileserverclient.py","diffId":"3663","author":"durham","id":"24394","dateCreated":"1511203049","dateModified":"1511203049"},{"type":"comment","comment":"Have you tested the performance impact of this change?  Previously we would issue 10k at a time, now if the buffer is 65k and if each entry is 100 bytes (40 byte hash + 60 byte path) then we're only doing 650 at a time.  You may need to set `remotefilelog.cacheprocess=` to force it to fallback to normal ssh fetching to execute this code path in bulk.","author":"durham","id":"24393","dateCreated":"1511203049","dateModified":"1511203049"},{"type":"reject","author":"durham","id":"24392","dateCreated":"1511203049","dateModified":"1511203049"},{"type":"comment","comment":"remove unnecessary condition","author":"ikostia","id":"24339","dateCreated":"1511198823","dateModified":"1511198823"},{"type":"update","diffId":"3663","author":"ikostia","id":"24338","dateCreated":"1511198823","dateModified":"1511198823"},{"type":"inline","comment":"Is there a way to get this value from the OS, in case someone has some custom setting for the default pipe size?","replyTo":null,"isNewFile":"1","line":"372","lineLength":"0","path":"remotefilelog\/fileserverclient.py","diffId":"3630","author":"wlis","id":"24303","dateCreated":"1511198212","dateModified":"1511198212"},{"type":"inline","comment":"Probably remove the \"True\"","replyTo":null,"isNewFile":"1","line":"230","lineLength":"0","path":"remotefilelog\/fileserverclient.py","diffId":"3630","author":"wlis","id":"24302","dateCreated":"1511198212","dateModified":"1511198212"},{"type":"update","diffId":"3630","author":"ikostia","id":"24226","dateCreated":"1511125192","dateModified":"1511125192"}],"dateCreated":"1511125192","dateModified":"1511203049","status":"Needs Revision"},{"id":"1423","callsign":"FBHGX","title":"debugdatapack: add more stats, and --summary","author":"phillco","summary":"- Use byte and comma formatters\n- In addition to each filename, print stats for each packfile, and for everything together (if numpackfiles > 1)\n- Add a `--summary` option which hides all the nodes and filename totals, which can be very noisy for huge packs, and only shows the packfile\/grand-total lines.\n\nExample output: https:\/\/phabricator.intern.facebook.com\/P58641463","testPlan":"","lineCount":"577","dependsOn":[],"reviewers":["durham"],"ccs":["durham"],"actions":[{"type":"inline","comment":"It's not obvious what the '?' means on its own.  Maybe write out \"missing blob sizes\" or something","replyTo":null,"isNewFile":"1","line":"57","lineLength":"0","path":"tests\/test-treemanifest-server.t","diffId":"3512","author":"durham","id":"23653","dateCreated":"1510789627","dateModified":"1510789627"},{"type":"inline","comment":"Same here for files vs something else.","replyTo":null,"isNewFile":"1","line":"312","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3512","author":"durham","id":"23652","dateCreated":"1510789627","dateModified":"1510789627"},{"type":"inline","comment":"Instead of \"unique files\" maybe say \"unique paths\", since it could also represent trees, and eventually other things.","replyTo":null,"isNewFile":"1","line":"304","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3512","author":"durham","id":"23651","dateCreated":"1510789627","dateModified":"1510789627"},{"type":"inline","comment":"I'd move the new total up one line, and the above newline down one.  So\n```\nw:\nNode          Delta Base    Delta Length  Blob Size\nbb6ccd5dceaa  000000000000  2 bytes       2 bytes\nTotal:                      2 bytes       2 bytes   (0.0% bigger)\n\nx:\nNode ....\n```\n\nThat way the separation between files is more visible.","replyTo":null,"isNewFile":"1","line":"160","lineLength":"0","path":"tests\/test-remotefilelog-bgprefetch.t","diffId":"3512","author":"durham","id":"23650","dateCreated":"1510789627","dateModified":"1510789627"},{"type":"inline","comment":"This whole section (lines 253-297) is becoming a bit of a mess.  We should refactor it to be something like:\n```\ndef getfileentries(entryiter)\n    lastfilename = None\n    entries = []\n    for filename, node, deltabase, deltalen in entryiter:\n        if lastfilename is not None and filename != lastfilename:\n            yield lastfilename, entries\n            entries = []\n        lastfilename = filename\n        entries.append((node, deltabase, deltalen))\n\n    if lastfilename is not None:\n        yield lastfilename, entries    \n...\nentryiter = dpack.iterentries()\nfor filename, entries in getfileentries(entryiter):\n   # Print header\n   for entry in entries:\n      # print entry\n   # print summary\n```\nSo we can untangle the filename != lastfilename logic and the post-loop logic to handle the last case.","replyTo":null,"isNewFile":"1","line":"297","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3512","author":"durham","id":"23649","dateCreated":"1510789627","dateModified":"1510789627"},{"type":"inline","comment":"I'd move this two lines up.  It's not related to metadata but it's right between the metadata reading and using.","replyTo":null,"isNewFile":"1","line":"281","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3512","author":"durham","id":"23648","dateCreated":"1510789627","dateModified":"1510789627"},{"type":"inline","comment":"We should probably move the contents of this loop to another function.  Not in this diff of course.","replyTo":null,"isNewFile":"1","line":"225","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3512","author":"durham","id":"23647","dateCreated":"1510789627","dateModified":"1510789627"},{"type":"inline","comment":"Debugdatapack is getting big.  I'd at least move this inner function out to be a top level function. To start to reduce complexity.","replyTo":null,"isNewFile":"1","line":"219","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3512","author":"durham","id":"23646","dateCreated":"1510789627","dateModified":"1510789627"},{"type":"inline","comment":"not quite alphabetical","replyTo":null,"isNewFile":"1","line":"9","lineLength":"0","path":"remotefilelog\/debugcommands.py","diffId":"3512","author":"durham","id":"23645","dateCreated":"1510789627","dateModified":"1510789627"},{"type":"reject","author":"durham","id":"23644","dateCreated":"1510789627","dateModified":"1510789627"},{"type":"update","diffId":"3512","author":"phillco","id":"23492","dateCreated":"1510730331","dateModified":"1510730331"}],"dateCreated":"1510730331","dateModified":"1510789627","status":"Needs Revision"},{"id":"1371","callsign":"HG","title":"global: remove redundant parenthesis","author":"indygreg","summary":"My code editor was spewing several warnings for redundant\nparenthesis. It supports easily fixing them. So I just did it\nglobally.\n\nWhat redundant parenthesis are left are in 3rd party code or\nare needed around string literals so our style checker doesn't\ncomplain about the lack of _().","testPlan":"","lineCount":"490","dependsOn":[],"reviewers":["yuja"],"ccs":["yuja","dlax","mercurial-devel"],"actions":[{"type":"comment","comment":"I used my editor's feature to fix violations. That's probably what introduced the whitespace changes. If only Mercurial conformed to PEP-8 style...","author":"indygreg","id":"22888","dateCreated":"1510591352","dateModified":"1510591352"},{"type":"inline","comment":"I don't like this sort of changes because here a tuple is a\ndata structure used thoroughly, not an arbitrary set of values\nto be returned.","replyTo":null,"isNewFile":"0","line":"298","lineLength":"0","path":"mercurial\/revsetlang.py","diffId":"3426","author":"yuja","id":"22867","dateCreated":"1510580851","dateModified":"1510580851"},{"type":"reject","author":"yuja","id":"22866","dateCreated":"1510580851","dateModified":"1510580851"},{"type":"inline","comment":"I'd keep this one as it makes it clearer that we return a generator. Arguably, that's nitpicking.","replyTo":null,"isNewFile":"1","line":"319","lineLength":"0","path":"mercurial\/bookmarks.py","diffId":"3426","author":"dlax","id":"22834","dateCreated":"1510561193","dateModified":"1510561193"},{"type":"inline","comment":"Spurious indentation changes here as well.","replyTo":null,"isNewFile":"1","line":"337","lineLength":"0","path":"hgext\/hgk.py","diffId":"3426","author":"dlax","id":"22833","dateCreated":"1510561193","dateModified":"1510561193"},{"type":"inline","comment":"Why this extra indentation?","replyTo":null,"isNewFile":"1","line":"79","lineLength":"0","path":"hgext\/hgk.py","diffId":"3426","author":"dlax","id":"22832","dateCreated":"1510561193","dateModified":"1510561193"},{"type":"comment","comment":"LGTM modulo a few nits. Nice cleanup.","author":"dlax","id":"22831","dateCreated":"1510561193","dateModified":"1510561193"},{"type":"update","diffId":"3426","author":"indygreg","id":"22733","dateCreated":"1510455062","dateModified":"1510455062"}],"dateCreated":"1510455062","dateModified":"1510591352","status":"Needs Revision"},{"id":"1361","callsign":"NRWHG","title":"exchange: set \"known\" property in generic override","author":"martinvonz","summary":" ","testPlan":"","lineCount":"17","dependsOn":[],"reviewers":["durin42"],"ccs":[],"actions":[{"type":"accept","author":"durin42","id":"22631","dateCreated":"1510350907","dateModified":"1510350907"},{"type":"update","diffId":"3403","author":"martinvonz","id":"22572","dateCreated":"1510342722","dateModified":"1510342722"}],"dateCreated":"1510342722","dateModified":"1510350907","status":"Accepted"},{"id":"1362","callsign":"NRWHG","title":"tracked: access narrowpats from repo instead of re-reading","author":"martinvonz","summary":"This is how we do it throughout the rest of the file.","testPlan":"","lineCount":"2","dependsOn":["1361"],"reviewers":["durin42"],"ccs":[],"actions":[{"type":"accept","author":"durin42","id":"22629","dateCreated":"1510350886","dateModified":"1510350886"},{"type":"update","diffId":"3404","author":"martinvonz","id":"22579","dateCreated":"1510342722","dateModified":"1510342722"}],"dateCreated":"1510342722","dateModified":"1510350886","status":"Accepted"},{"id":"1363","callsign":"NRWHG","title":"widening: stop passing old{in,ex}clude to _widen()","author":"martinvonz","summary":"The values are easily (and efficiently) accessible on the repo\ninstance, and not passing them will make simplify an upcoming patch.","testPlan":"","lineCount":"7","dependsOn":["1362"],"reviewers":["durin42"],"ccs":[],"actions":[{"type":"accept","author":"durin42","id":"22627","dateCreated":"1510350876","dateModified":"1510350876"},{"type":"update","diffId":"3405","author":"martinvonz","id":"22587","dateCreated":"1510342723","dateModified":"1510342723"}],"dateCreated":"1510342723","dateModified":"1510350876","status":"Accepted"},{"id":"1360","callsign":"NRWHG","title":"exchange: set {,old}{in,ex}cludepats in generic override","author":"martinvonz","summary":"With this patch, one can safely call exchange.pull() and it will pass\nall necessary parameters to the server.\n\nI think we may want to change the parameters so lack of\nold{in,ex}cludepats means that they're the same as the current\nones. Then widening would instead add new{in,ex}cludepats. But let's\ndiscuss that later.","testPlan":"","lineCount":"49","dependsOn":[],"reviewers":["durin42"],"ccs":[],"actions":[{"type":"accept","author":"durin42","id":"22625","dateCreated":"1510350770","dateModified":"1510350770"},{"type":"update","diffId":"3402","author":"martinvonz","id":"22569","dateCreated":"1510342711","dateModified":"1510342711"}],"dateCreated":"1510342711","dateModified":"1510350770","status":"Accepted"},{"id":"829","callsign":"FBHGX","title":"tweakdefaults: improve basic help text","author":"mbthomas","summary":"The default help ('hg help' or 'hg --help') shows only the built-in commands.\nWith all of our extensions, this is not a sensible list to show.  It also\nlists the enabled extensions, which is a long list that is not very useful\nto users.\n\nWe override the help command in the following circumstances:\n\n  * `hg`, or `hg non-existent-command`, to show a much smaller list of commands.\n  * `hg help`, or `hg --help`, to show the full list of relevant commands.\n\nOther invocations of `hg help` are not affected.","testPlan":"","lineCount":"88","dependsOn":[],"reviewers":["ryanmce"],"ccs":["quark"],"actions":[{"type":"comment","comment":"Going to think about this a bit more.  It may be worth considering what improvements we can make to upstream instead.","author":"mbthomas","id":"16244","dateCreated":"1507280551","dateModified":"1507280551"},{"type":"plan-changes","author":"mbthomas","id":"16243","dateCreated":"1507280551","dateModified":"1507280551"},{"type":"inline","comment":"If we still do this out-of-core, these could be config options.","replyTo":null,"isNewFile":"1","line":"113","lineLength":"9","path":"hgext3rd\/tweakdefaults.py","diffId":"2137","author":"quark","id":"14123","dateCreated":"1506624833","dateModified":"1506624833"},{"type":"comment","comment":"When thinking about it again, it seems desirable to show extension commands even without `-v`.\n\nI also think the upstream wants the alternative behavior too. Otherwise `rebase` not shown up in `hg help` just seems strange. It could be gated by a config option (ex. `commands.help.showextensioncommands`) to satisfy old users.\n\nWith `-v`, we can show commands marked as `EXPERIMENTAL`, `ADVANCED`, `DEPRECATED`. This is consistent with command flags.","author":"quark","id":"14122","dateCreated":"1506624833","dateModified":"1506624833"},{"type":"inline","comment":"This seems to be a copy-paste from core Mercurial to replace part of its function. Usually we avoid doing that unless the feature is urgent.\n\nConsider:\n\n - Get this feature done directly in upstream (I think `-v` is reasonable)\n\nOr:\n\n - Split upstream function so we can wrap it without code duplication. See 45e02cfad4bd for an example.","replyTo":null,"isNewFile":"1","line":"245","lineLength":"64","path":"hgext3rd\/tweakdefaults.py","diffId":"2137","author":"quark","id":"14121","dateCreated":"1506624349","dateModified":"1506624349"},{"type":"inline","comment":"We no longer support Python 2.6, the set literal syntax is preferred:\n\n  helpcommandsshort = {'add', ...}","replyTo":null,"isNewFile":"1","line":"113","lineLength":"0","path":"hgext3rd\/tweakdefaults.py","diffId":"2137","author":"quark","id":"14120","dateCreated":"1506624349","dateModified":"1506624349"},{"type":"update","diffId":"2137","author":"mbthomas","id":"14004","dateCreated":"1506601060","dateModified":"1506601060"},{"type":"comment","comment":"Feel free to bikeshed the list of commands that are presented.","author":"mbthomas","id":"14003","dateCreated":"1506600917","dateModified":"1506600917"},{"type":"update","diffId":"2136","author":"mbthomas","id":"13998","dateCreated":"1506600866","dateModified":"1506600866"}],"dateCreated":"1506600866","dateModified":"1507280551","status":"Changes Planned"}],"profiles":[{"userName":"angel.ezquerra","realName":"Angel Ezquerra","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/xw2pljwr7c5qppevxwp3\/PHID-FILE-23lixqcrrtkfnt6ptp7q\/profile"},{"userName":"gracinet","realName":"Georges Racinet","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/7c5xeavq4o7axutv52hq\/PHID-FILE-4vjjy4phli3gyduesdzg\/alphanumeric_lato-white_G.png-_335862-0%2C0%2C0%2C0.png"},{"userName":"marcink","realName":"Marcin K","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/6g4sm6aciqqkub3aava4\/PHID-FILE-uys7rbgtunddicsxojma\/alphanumeric_lato-dark_M.png-_ec9da1-255%2C255%2C255%2C0.4.png"},{"userName":"navaneeth.suresh","realName":"Navaneeth Suresh","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/v7zzzp6htug64ayfsyoy\/PHID-FILE-o5lfhn36ahtkiydnxkm6\/profile"},{"userName":"Zharaskhan","realName":"Zharaskhan","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/lcpedijyswyhguzwsmh6\/PHID-FILE-ymiw54ac73atesbarttu\/alphanumeric_lato-white_Z.png-_6bafb6-0%2C0%2C0%2C0.3.png"},{"userName":"abhyudaypratap","realName":"ABHYUDAY PRATAP SINGH","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/fhyoa4ylarfj4mjjsfnz\/PHID-FILE-gdiilvqk6dvaelqttevu\/alphanumeric_lato-white_A.png-_7867a3-0%2C0%2C0%2C0.png"},{"userName":"nspanti-logilab","realName":"Nicola Spanti","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/2szz77xfd5ejbn5ipcfr\/PHID-FILE-6ltvplbn3fcn7r5ogoqm\/alphanumeric_lato-white_N.png-_4e5632-0%2C0%2C0%2C0.3.png"},{"userName":"jeffpc","realName":"Jeff Sipek","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/tdb3ls7h66j7dh5upryy\/PHID-FILE-7uafys6btqxf3dd33pey\/alphanumeric_lato-white_J.png-_b1c8eb-0%2C0%2C0%2C0.3.png"},{"userName":"sheehan","realName":"Connor Sheehan","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/xos732z337wctb7orxn2\/PHID-FILE-imgmr7hs6lhgmhnyhuim\/profile"},{"userName":"sangeet259","realName":"Sangeet Kumar Mishra","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/w2t3qtjbkq6i7d4fiflb\/PHID-FILE-pjpjz4ab55pgexyec3j2\/alphanumeric_lato-dark_S.png-_4e5632-255%2C255%2C255%2C0.4.png"},{"userName":"Ivzhh","realName":"Sheng Mao","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/762wysb4ooe3ekoga43a\/PHID-FILE-zur24kxarfkspo26ir67\/profile"},{"userName":"khanchi97","realName":"Sushil khanchi","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/3pp56o77ancwuv65wlhu\/PHID-FILE-c2txpmsbutyxgjyde2zp\/profile"},{"userName":"kevincox","realName":"Kevin Cox","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/sbp5kmlbv6vamvjkmjy5\/PHID-FILE-knnjmppp4vpzcxpqmkwh\/profile"},{"userName":"dploch","realName":"Daniel Ploch","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/ociwxv6qntytpb6zdxls\/PHID-FILE-m4wajbifgsqubz5w6r4u\/profile"},{"userName":"tom.prince","realName":"Tom Prince","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/afbz4m4ohutpjetr3tql\/PHID-FILE-rblbnvxfl47fyw546ocf\/profile"},{"userName":"marco.leogrande","realName":"Marco Leogrande","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/tkvibdelmgssnv4ebov7\/PHID-FILE-tfjptcanefutqscooi75\/profile"},{"userName":"kaleyh","realName":"Kaley Zhihui Huang","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/clcmxxq7nzpdqhqeze35\/PHID-FILE-enqeoiscacbj3quvmu5v\/profile"},{"userName":"joerg.sonnenberger","realName":"Joerg Sonnenberger","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/r6zqtnrvelifbtppj4mu\/PHID-FILE-orm5fypdgkwptokuvhu5\/profile"},{"userName":"tja","realName":"Thomas Jacob","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/lwnnvur42bobvgmv7c54\/PHID-FILE-ztcsvphl242bhhrawoeh\/alphanumeric_aleo-white_T.png-_335862-0%2C0%2C0%2C0.png"},{"userName":"wlis","realName":"Wojciech Lis","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/qksokzpep5fnbwl4cxnv\/PHID-FILE-4snkiib4rpc643dsuvgs\/profile"},{"userName":"markand","realName":"David Demelier","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/v5ibglquzd3qe4b3fxzp\/PHID-FILE-ra4iu3zvlvimurhularx\/profile"},{"userName":"av6","realName":"Anton Shestakov","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/hbjxchhduli6jrz3wy53\/PHID-FILE-hixj32uzzbjuvjsax6e3\/profile"},{"userName":"foozy","realName":"Katsunori FUJIWARA","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/uxmk3ymbn5cplhrcc3ox\/PHID-FILE-eyxzcwqdufk55nuzrkui\/profile"},{"userName":"dlax","realName":"Denis Laxalde","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/llz4fftev4b7zckiqfvi\/PHID-FILE-d7t77nx6n56nzytddceb\/profile"},{"userName":"hollisb","realName":"Hollis Blanchard","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/iggfsbubv47fw5tdrrwe\/PHID-FILE-a57xt2zd72jp64xezauu\/alphanumeric_lato-white_H.png-_335862-255%2C255%2C255%2C0.7.png"},{"userName":"singhsrb","realName":"Saurabh Singh","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/bp7zbulgy4snhr3ou6z4\/PHID-FILE-dvujqtbp56tzyuttwvwp\/profile"},{"userName":"philpep","realName":"Philippe Pepiot","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/boj5wqy2tcfzm4b3x5py\/PHID-FILE-6nfhwshmtwghgvfcnttu\/profile"},{"userName":"mbolin","realName":"Michael Bolin","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/a4aw73weeriuryfkpvbx\/PHID-FILE-nk3y36i25zsmgf7anqqh\/profile"},{"userName":"hooper","realName":"Danny Hooper","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/3xis26hjezfqq4wckvgd\/PHID-FILE-mc6rpdu52jzz2pqlfi3k\/profile"},{"userName":"glandium","realName":"Mike Hommey","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/wexe6n4s2bpojsuxutj6\/PHID-FILE-angxhhuxuyx7rg7mniop\/alphanumeric_aleo-white_G.png-_6c8548-255%2C255%2C255%2C0.4.png"},{"userName":"mbthomas","realName":"Mark Thomas","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/ceuosb7vyo3urrgvwvnm\/PHID-FILE-ffbbyima2mbsxuqqisjf\/profile"},{"userName":"swhitaker","realName":"Simon Whitaker","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/rejzev6zgxqpmlisheps\/PHID-FILE-4mav5wnholgu7gerlvk6\/profile"},{"userName":"mjpieters","realName":"Martijn Pieters","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/lcpb6ee667oiti6xdnc4\/PHID-FILE-6okmi7uyvn6ygzcdj3mm\/profile"},{"userName":"rdamazio","realName":"Rodrigo Damazio Bovendorp","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/4a77tfxnpjbpt2ggycfj\/PHID-FILE-lsili2yioao6o54nuevs\/profile"},{"userName":"mharbison72","realName":"Matt Harbison","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/exavetnjpwt74m5ctwqc\/PHID-FILE-a6gptxixmw2meahkn2ad\/profile"},{"userName":"ikostia","realName":"Kostia Balytskyi","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/7zljfaajqc5fwpgggoxv\/PHID-FILE-6jwkzbmu4cf22o35mx3k\/profile"},{"userName":"lothiraldan","realName":"Boris Feld","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/m3bla7ufl3cjmnym5xat\/PHID-FILE-kigxoxqookrqrhpspjit\/profile"},{"userName":"stash","realName":"Stanislau Hlebik","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/wf3xb2kovxyqypqtp2rz\/PHID-FILE-akocypfziwimghtqh4iu\/alphanumeric_lato-dark_S.png-_9166aa-255%2C255%2C255%2C0.4.png"},{"userName":"indygreg","realName":"Gregory Szorc","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/nf3veituwivx24ctdwf6\/PHID-FILE-b2sr2l6owww6nd3m2kml\/profile"},{"userName":"dsp","realName":"David Soria Parra","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/xrjhk4aswt4nlwofuz2i\/PHID-FILE-rjdjfgxnzlwhx3iqgl3a\/profile"},{"userName":"spectral","realName":"Kyle Lippincott","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/afmemikabk26zacyrve3\/PHID-FILE-c7do5pqxf7rpec3jj3qs\/profile"},{"userName":"yuja","realName":"Yuya Nishihara","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/kyyyaiumhfkcjjtysphq\/PHID-FILE-iujngvd4rkw4tyyogag4\/profile"},{"userName":"ryanmce","realName":"Ryan McElroy","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/acfbd4z6nesfd76wnnj5\/PHID-FILE-k26xnkr6nvkc5l6jsscc\/profile"},{"userName":"pulkit","realName":"Pulkit Goyal","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/67mfdmcxxo6hghy7bxoq\/PHID-FILE-swcwmgf52vkrkmcqjnwd\/profile"},{"userName":"smf","realName":"Sean Farley","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/tbwekyw6pglxsobywzco\/PHID-FILE-hdxjtngw5tp2k5dbysdt\/profile"},{"userName":"durham","realName":"Durham Goode","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/tbr2anpbd33oiyqeijif\/PHID-FILE-g363nrrxd6paer5ugcpw\/profile"},{"userName":"jsgf","realName":"Jeremy Fitzhardinge","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/6ihycyjpnngswp5u3tum\/PHID-FILE-4x5bowxqnm7tdk27to2v\/profile"},{"userName":"martinvonz","realName":"Martin von Zweigbergk","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/llyfr65e22jrp77s6ufm\/PHID-FILE-fggemwj53prdzf5tnsir\/profile"},{"userName":"quark","realName":"Jun Wu","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/yhgthtf3uk3yamwaqfbv\/PHID-FILE-ntlso5gq5tmxn6qqmqhq\/profile"},{"userName":"phillco","realName":"Phil Cohen","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/s6v7x5h734dqbi4pkii6\/PHID-FILE-dcp3elsshux2rxyfb2g3\/profile"},{"userName":"krbullock","realName":"Kevin Bullock","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/cak2ma7v7iz7ac522on2\/PHID-FILE-achi52mww6qbb5dslmow\/profile"},{"userName":"durin42","realName":"Augie Fackler","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/fxdzcgfaiyjyat5yx6wn\/PHID-FILE-wab3a6a3bynn7dobtpoz\/profile"},{"userName":"admin","realName":"Administrator","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/ax2ohnusy6xhxcsictnf\/PHID-FILE-earziycgjj2v67gz3vq4\/alphanumeric_lato-white_A.png-_335862-0%2C0%2C0%2C0.3.png"},{"userName":"mercurial-devel","realName":"mercurial-devel@mercurial-scm.org","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/uxfm523cqrdxtqfl55gh\/PHID-FILE-igq3uy3gdohueaer3qxy\/alphanumeric_aleo-white_M.png-_335862-255%2C255%2C255%2C0.7.png"},{"userName":"mitrandir","realName":"Mateusz Jakub Kwapich","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/3og26nizhmuzz7vtuiob\/PHID-FILE-q3vx3ix5yiu5gs6umqvx\/profile"},{"userName":"akushner","realName":"Aaron Kushner","image":"https:\/\/phab.mercurial-scm.org\/file\/data\/z5rynd6nw66bxxba2mjl\/PHID-FILE-tgtgg2xrru4t4ezofo2k\/profile"}]}}