
Aaron Denney wrote:
On 2008-06-04, apfelmus
wrote: <-- cut --> Or the next->topic path relies on features from next that are not present in master . But then, you're screwed anyway
Yep.
Well not really, depends what kind the dependency is, this kind of rebase is useful when "topic" depends only syntactically (as you pointed later) on "next" or when the semantic dependency is only on a small part of "next". Git rebase allows you get the syntax or the small part of semantics to the rebased "topic" by asking you for (manual) conflict resolution. This would correspond to commuting darcs patches which depend on each other (again possible by providing manual conflict resolution). Of course this happens only when it was anticipated that upstream merge of "next" happens before "topic", but then the upstream maintainers decided that "topic" should go upstream first. So, not often.
and should merge some parts from next into master so as to advance the point where master and next fork.
That's one solution. Of course, darcs doesn't have semantic dependency, but syntactic dependency. (You can add extra dependencies to model semantic dependencies, but you can't take away the syntactic dependencies.) Another solution, if there's syntactic, but not semantic dependencies, is to manually use patch and diff to get 90% there, and then cleanup and record.
OK, so I think this is what I expected for such a case. Thanks for the explanation of the meaning of "merging patches prior head". Peter.