On Mon, 1 Oct 2007 23:41:56 +0200, "Tom Clarke" wrote:What I think I've always wanted is something like the following behavior for "git pull": * Fast forward if possible * Otherwise, rebase, but only if there are no conflicts at all * Otherwise, do the merge as normal, (leave conflict markers in place allowing the user to fix them up and then commit). Would it be straightforward to turn your rebase merge strategy into something like the above? And if so, would that address the primary concerns that Junio raised? -Carl
| H. Peter Anvin | Re: [RFC 00/15] x86_64: Optimize percpu accesses |
| Tarkan Erimer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Eric W. Biederman | Remaining straight forward kthread API conversions... |
| Greg Kroah-Hartman | [PATCH 001/196] Chinese: Add the known_regression URI to the HOWTO |
| David Miller | [GIT]: Networking |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
| Frans Pop | svc: failed to register lockdv1 RPC service (errno 97). |
git: | |
