On 10/1/07, Junio C Hamano <gitster@pobox.com> wrote:Thanks for the ample feedback, you raise a number of interesting issues. I am wondering now if making rebase a merge strategy is really a good idea. Rebasing is not merging, a difference that could perhaps be overlooked in the no-conflict scenario, but as you point out, is glaringly obvious as soon as you have conflicts. I'm happy to try to address the issues you raised, but I wonder if we would do better to look back at my original proposal which was to add a --rebase option to git-pull. git-pull is the main place there I see need for using a rebase instead of a merge, as anywhere where you might use git-merge directly, if what you really want is a rebase, you can just run git-rebase. -Tom - 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
| Greg KH | [GIT PATCH] driver core patches against 2.6.24 |
| James Bottomley | Re: Integration of SCST in the mainstream Linux kernel |
| Stephen Rothwell | Re: Announce: Linux-next (Or Andrew's dream :-)) |
| Arjan van de Ven | Re: [malware-list] [RFC 0/5] [TALPA] Intro to a linux interfaceforon access scanning |
| Patrick McHardy | Re: [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| Jarek Poplawski | [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Eric W. Biederman | Re: namespace support requires network modules to say "GPL" |
git: | |
