| 582 | ) |
| 583 | |
| 584 | def parse_revs(self) -> List[ghstack.git.CommitHeader]: |
| 585 | # There are two distinct usage patterns: |
| 586 | # |
| 587 | # 1. You may want to submit only HEAD, but not everything below it, |
| 588 | # because you only did minor changes to the commits below and |
| 589 | # you want to let the CI finish without those changes. |
| 590 | # See https://github.com/ezyang/ghstack/issues/165 |
| 591 | # |
| 592 | # 2. I want to submit a prefix of the stack, because I'm still working |
| 593 | # on the top of the stack and don't want to spam people with |
| 594 | # useless changes. See https://github.com/ezyang/ghstack/issues/101 |
| 595 | # |
| 596 | # If we use standard git log/rev-list style parsing, you get (2) by |
| 597 | # default because a single commit implies a reachability constraint. |
| 598 | # Specifying (1) is a bit inconvenient; you have to say something |
| 599 | # like `ghstack submit HEAD~..`. In particular, both (1) and (2) would like |
| 600 | # the meaning of `ghstack submit HEAD` to do different things (1 wants a single |
| 601 | # commit, whereas 2 wants everything reachable from the commit.) |
| 602 | # |
| 603 | # To resolve the ambiguity, we introduce a new command line argument |
| 604 | # --no-stack (analogous to the --stack argument on jf) which disables |
| 605 | # "stacky" behavior. With --no-stack, we only submit HEAD by default |
| 606 | # and you can also specify a specific commit to submit if you like |
| 607 | # (if this commit is not reachable from HEAD, we will tell you how |
| 608 | # to checkout the updated commit.) If you specify multiple commits, |
| 609 | # we will process each of them in turn. Ranges are not supported; use |
| 610 | # git rev-list to preprocess them into single commits first (in principle |
| 611 | # we could support this, but it would require determining if a REV was |
| 612 | # a range versus a commit, as different handling would be necessary |
| 613 | # in each case.) |
| 614 | # |
| 615 | # Without --no-stack, we use standard git rev-list semantics. Some of the |
| 616 | # more advanced spellings can be counterintuitive, but `ghstack submit X` |
| 617 | # is equivalent to checking out X and then performing ghstack (and then |
| 618 | # restacking HEAD on top, if necessary), and you can say `X..Y` |
| 619 | # (exclusive-inclusive) to specify a specific range of commits (oddly, |
| 620 | # `X..` will do what you expect, but `..Y` will almost always be empty.) |
| 621 | # But I expect this to be fairly niche. |
| 622 | # |
| 623 | # In both cases, we support submitting multiple commits, because the set |
| 624 | # of commits you specify affects what rebasing we do, which is sometimes |
| 625 | # not conveniently done by calling ghstack multiple times. |
| 626 | |
| 627 | # Interestingly, the default is the same whether it is --stack or |
| 628 | # --no-stack |
| 629 | revs = ("HEAD",) if not self.revs else self.revs |
| 630 | |
| 631 | # In jf, we determine whether or not we should consider a diff by checking |
| 632 | # if it is draft or not (only draft commits can be posted). Git doesn't |
| 633 | # have a directly analogous concept, so we need some other strategy. A |
| 634 | # simple approach is to inspect the base branch in the upstream |
| 635 | # repository, and exclude all commits which are reachable from it. |
| 636 | # We don't want to blast ALL remote branches into the list here though; |
| 637 | # it's possible the draft commits were pushed to the remote repo for |
| 638 | # unrelated reasons, and we don't want to treat them as non-draft if |
| 639 | # this happens! |
| 640 | |
| 641 | commits_to_submit_and_boundary = [] |