Wenn du den Branch noch nicht irgendwohin gepusht hast (zm Beispiel für ein Code review), könnte man in Git einfach ein Rebase auf deinen "Default" machen damit dein Feature branch sauber auf dem neuen Changeset aufbaut (eventuelle Konflikte müssen natürlich behoben werden)
... snip ...
Bei nur einem Fix in der Lebenszeit deines Feature branches mag das Okay sein. Aber irgendwann kriegt man da Augenkrebs. Da macht das dann IMO schon Sinn regelmäßig den Feature-Branch auf den aktuellen Hauptbranch zu stülpen (IOW: rebase)
Wenn ihr allerdings Code reviews á la Kiln nutzt, dann würde ich zwar vor dem ersten Review ein Rebase machen, aber von da an den Hauptbranch in den Featurebranch mergen.
Sieht dann nicht so toll aus, aber die Changeset ID bleibt erhalten, und somit auch die Reviews deiner Kollegen.
IIRC kannst du den 2. merge fast forwarden, so dass man in der History nur einen Merge commit hat. Von Branches rebasen halte ich persönlich nix, da holt man sich zu viel Ärger (außer der branch ist wirklich nur lokal vorhanden und die betroffenen Änderungen nicht remote). Außer halt wenn man nen remote pullt, das sollte man immer mit seinem lokalen rebasen, da man sonst unnötige Commits á la "merged remote/feature-x to feature-x" commits hat, die für Nüsse sind.
Bei dem gefragten Fall würd ich wohl zu nem cherry-pick (das ist wenn ich das richtig gelesen habe, das was in hg graft macht) tendieren.