mharbison72 added a comment.

  Big +1 on this functionality, and I'd be happy to experiment with it now.  I 
couldn't quite figure it out from an extension.  Also +1 on doing this for 
filesets.
  
  My use case is less about generic revsets (e.g.,` nudge = push -r .`), and 
more about defining ones that collect the paths for various products in the 
repo.  It makes sense to lock those into each revision as the codebase evolves. 
 So my initial thoughts for next cycle are:
  
  1. Hopefully the paths can define filesets in .hgfileset, and then the 
fileset be used to define the revset (probably as input to 'files()'), to avoid 
duplication.  (It's not clear to me if there will be ordering/dependency issues 
when these are read in.)
  
  2. I think using wdir() by default makes sense.  But an option to use another 
rev makes sense in some cases (consider `hg archive -r 1234 -I 
'set:product1()'`, without updating to 1234).
  
  3. I can see cases where the repo defined alias should be enforced (e.g. a 
release script running `hg archive`).  I think HGRCPATH= ignores every hgrc 
except .hg/hgrc, right?  A config option that the script knows about to alter 
the default behavior seems useful.
  
  Not directly related to this, but I've also been wondering how to get defined 
revsetaliases more discoverable.  Maybe recognizing minirst help text inside 
the # comments in the section, and inserting them into the core help?  I don't 
think an end user cares about the difference between a revset proper and a 
revsetalias.

REPOSITORY
  rHG Mercurial

REVISION DETAIL
  https://phab.mercurial-scm.org/D98

EMAIL PREFERENCES
  https://phab.mercurial-scm.org/settings/panel/emailpreferences/

To: indygreg, #hg-reviewers
Cc: mharbison72, quark, mercurial-devel
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Reply via email to