Benoit SIGOURE wrote:That's exactly what I would expect to happen. The "git-rebase" is the key here; it is effectively telling git to switch back to your master branch. Try running "git log" before and after the rebase command and you should get a slightly better idea of what's happening. Rebase is kind of a tricky beast; a basic rule of thumb is that you should only use it to go forward in time on a single upstream branch, not to hop between upstream branches. Its behavior in non-forward-in-time cases is predictable once you know how it works, but not necessarily intuitive. What are you expecting rebase to do here? We can probably suggest some other commands that will do what you're hoping to do. My hunch is that you're trying to use it to effectively do a merge of your "a" and "b" branches, but maybe I'm wrong about that. -Steve - To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
| Jeff Garzik | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Christoph Hellwig | Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interface for on access scan... |
| Heiko Carstens | Re: -mm merge plans for 2.6.23 -- sys_fallocate |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Arjan van de Ven | Re: [GIT]: Networking |
| Jens Axboe | Re: [BUG] New Kernel Bugs |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Emmanuel Dreyfus | fixing send(2) semantics (kern/29750) |
| Christos Zoulas | Re: Melting down your network [Subject changed] |
| Juan RP | Changing the I/O scheduler on-the-fly |
| Emmanuel Dreyfus | Re: fixing send(2) semantics (kern/29750) |
