On Sat, Apr 10, 2010 at 12:26 AM, Jeff King <peff@xxxxxxxx> wrote: > On Fri, Apr 09, 2010 at 03:35:42PM -0400, Eugene Sajine wrote: > >> In case of this situation >> >> A master >> \ >> B next >> \ >> C topic >> >> >> $ git rebase --onto master topic >> First, rewinding head to replay your work on top of it... >> fatal: Not a range. >> Nothing to do. >> >> Which is OK. > > I think this doesn't do quite what you thought. It's true there is > "nothing to do" as in "nothing to apply", but it _did_ in fact rewind > topic back to "master". > > You seem to be thinking that > > git rebase --onto master topic > > means "rebase everything from master to topic onto master". It doesn't. > That would be: > > git rebase master topic > > or, if you are already on topic, just > > git rebase master. > > The "--onto" option takes an argument, which says "put the commits on > top of here, even though it was not the upstream base otherwise > specified". So what your command does is say "using the current branch > (which is topic), take everything built on top of topic (which is > nothing), and rebuild it on top of master". Actually no, i was not thinking about what you think i was;). What i was trying to understand with this command (git rebase --onto master topic) is the behavior of the system when the topic branch is indirect descendant of the master and the direct parent of topic (next) is omitted, skipped. In this situatiion git rebase master topic does not work (see thread "git rebase command and docs questions") p1. So, once again i think that the interface in this case worked properly: as topic is not direct descendant, master option value goes to --onto and there is no range defined properly. Therefore the command worked ok, when it refused to do anything. Now the problem i have is that: git rebase -i --onto master topic actually worked and did something, what i would not expect it to do. So, the problem is: non-interactive rebase DOES NOT execute the command, interactive DOES execute. > > So no, it's not a bug. Yes, it's a terrible interface. There is really > no reason IMHO for rebase to take a "which branch to operate on" > argument at all. It should just operate on HEAD, like merge does. If you > want to merge on a different branch, you "git checkout" that branch > first. The bug is in the fact that rebase works differently in interactive and non-interactive variants. Thanks, Eugene -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html