Hi, an idea hit me today: maybe we can make rebase work nicely with merges after all. We could record the original branch point and the new branch point for rebases. If this information is somehow accessible when doing a merge, git could check if the old branch point is reachable from the current HEAD, but not the new branch point, and if both are the case, rebase the changes since the old branch point on top of the new branch point before trying to merge. Does this sound too far-fetched? Ciao, Dscho - 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
| Linus Torvalds | Linux 2.6.27-rc8 |
| Bron Gondwana | BUG: mmapfile/writev spurious zero bytes (x86_64/not i386, bisected, reproducable) |
| Jeff Garzik | Virt RNG? |
| Crispin Cowan | AppArmor Security Goal |
git: | |
| walt | [VOTE] git versus mercurial |
| Pavel Roskin | Implementing branch attributes in git config |
| Peter Karlsson | RCS keyword expansion |
| Johannes Schindelin | Re: Empty directories... |
| Christian Weisgerber | Re: libiconv problem |
| Steve Shockley | Re: Real men don't attack straw men |
| Theo de Raadt | Re: Oddly high load average |
| Steve B | Intel Atom and D945GCLF2 |
| Karlin Dodd | VL-bus questions |
| Jim Winstead Jr. | Re: Root Disk/Book Disk Compatibility |
| Joern Rennecke | Use shadow ram? |
| Framstag | ftp-error: bind: Address already in use? |
