Jeff King wrote:That implication is not a technical one, but merely a convention in the mind of the git-user. Relevant, of course, but maybe we can accomodate both uses. Correct. True. However... What if the merge-base determination code is modified to behave as if --first-parent is specified while searching for the merge-base? In that case it *will* find A as the merge-base, even in the presence of "sideportlinks". Does that resolve all technical issues? -- Sincerely, Stephen R. van den Berg. "The future is here, it's just not widely distributed yet." -- William Gibson -- 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
| monstr | [PATCH 26/60] microblaze_v4: time support |
| Jon Smirl | Re: 463 kernel developers missing! |
| Andrew Morton | Re: x86: 4kstacks default |
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
git: | |
| Gerrit Renker | [PATCH 15/37] dccp: Set per-connection CCIDs via socket options |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| David Miller | Re: [GIT]: Networking |
| Jiri Olsa | [PATCHv5 0/2] net: fix race in the receive/select |
