Mercurial > hg
view tests/test-rebase-partial.t @ 33309:69c4493a54f9
changegroup: don't fail on empty changegroup (API)
I don't know why applying an empty changegroup should be an error. It
seems harmless. I suspect the check was there to find code that
creates empty changegroups just because that would be wasteful. Let's
use develwarn() for that instead, so we catch any such cases that run
with our test runner, but we still allow others to generate empty
changegroups if they want to.
We have run into this check at Google once or twice and had to work
around it, but I'm changing this not so much because of that, but
because it seems like it shouldn't be an error.
I also changed the message slightly to be more modern ("changelog
group" -> "changegroup") and more generic ("received" -> "applied").
author | Martin von Zweigbergk <martinvonz@google.com> |
---|---|
date | Fri, 30 Jun 2017 23:58:59 -0700 |
parents | 78496ac30025 |
children | 6c1a9fd8361b |
line wrap: on
line source
Tests rebasing with part of the rebase set already in the destination (issue5422) $ cat >> $HGRCPATH <<EOF > [extensions] > rebase= > drawdag=$TESTDIR/drawdag.py > > [experimental] > evolution=createmarkers,allowunstable > > [alias] > tglog = log -G --template "{rev}: {desc}" > EOF $ rebasewithdag() { > N=`$PYTHON -c "print($N+1)"` > hg init repo$N && cd repo$N > hg debugdrawdag > hg rebase "$@" > _rebasetmp > r=$? > grep -v 'saved backup bundle' _rebasetmp > [ $r -eq 0 ] && hg tglog > cd .. > return $r > } Rebase two commits, of which one is already in the right place $ rebasewithdag -r C+D -d B <<EOF > C > | > B D > |/ > A > EOF rebasing 2:b18e25de2cf5 "D" (D) already rebased 3:26805aba1e60 "C" (C tip) o 4: D | | o 3: C |/ | x 2: D | | o | 1: B |/ o 0: A Can collapse commits even if one is already in the right place $ rebasewithdag --collapse -r C+D -d B <<EOF > C > | > B D > |/ > A > EOF rebasing 2:b18e25de2cf5 "D" (D) rebasing 3:26805aba1e60 "C" (C tip) o 4: Collapsed revision | * D | * C | x 3: C |/ | x 2: D | | o | 1: B |/ o 0: A Rebase with "holes". The commits after the hole should end up on the parent of the hole (B below), not on top of the destination (A). $ rebasewithdag -r B+D -d A <<EOF > D > | > C > | > B > | > A > EOF already rebased 1:112478962961 "B" (B) not rebasing ignored 2:26805aba1e60 "C" (C) rebasing 3:f585351a92f8 "D" (D tip) o 4: D | | x 3: D | | | o 2: C |/ o 1: B | o 0: A