<Diziet> I discover that stitch treats non-launderedness as a snag.
<Diziet> This is not quite compatible with these newfangled
push-your-unlaundered-stuff workflows.
<Diziet> It would be possible to make one of prepush or stitch
(currently synonyms) behave differently in this respect.
<spwhitton> do you know why stitch treats non-launderedness as a snag?
<spwhitton> given that we expect [most people] to use `git debrebase
conclude`, which launders, and never invoke `git debrebase
stitch` explicitly, it would be okay to change that such
that `git debrebase stitch` does not consider
non-launderedness to be a snag.
<Diziet> I think it does that just because I am the kind of person
who thinks, when writing some routine, "what could I check
here?" :-)
<Diziet> I think you are perhaps right that it ought not to.
<Diziet> "conclude" didn't exist then of course.
<spwhitton> okay. git-debrebase(1) could note "you probably want
conclude because you probably want to launder"
<Diziet> Mmmm.
Signed-off-by: Ian Jackson <ijackson@chiark.greenend.org.uk>
my $prose = 'stitch';
GetOptions('prose=s', \$prose) or die badusage("bad options to stitch");
badusage "no arguments allowed" if @ARGV;
my $prose = 'stitch';
GetOptions('prose=s', \$prose) or die badusage("bad options to stitch");
badusage "no arguments allowed" if @ARGV;
- do_stitch $prose, \&snag;
}
sub cmd_prepush () { cmd_stitch(); }
}
sub cmd_prepush () { cmd_stitch(); }
If there is no ffq-prev, it is an error, unless --noop-ok.
If there is no ffq-prev, it is an error, unless --noop-ok.
-It is a snag (see B<-f>) if the branch is not laundered.
+You should consider using B<conclude> instead,
+because that launders the branch too.
=item git-debrebase new-upstream-v0 <new-version> [<upstream-details>...]
=item git-debrebase new-upstream-v0 <new-version> [<upstream-details>...]