Idea for rebase strategy

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html

[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]