On Tue, 10 Apr 2007, Andy Parkins wrote:this is very similar to the problem I asked about with merging config files a couple weeks ago. the answer then was that when we get .gitattributes we should be able to specify content specific merge programs that could deal with this sort of thing on a per-file basis. That sounds like the answer to your concern as well, rather then makeing things order dependant and otherwise harder to read to make it able to be merged with the current tools (which assume line-based order-dependant content) David Lang - 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
| debian developer | Re: Dual-Licensing Linux Kernel with GPL V2 and GPL V3 |
| Greg Kroah-Hartman | [PATCH 014/196] kobject: remove incorrect comment in kobject_rename |
| Vladislav Bolkhovitin | Re: Integration of SCST in the mainstream Linux kernel |
| Stephen Rothwell | Re: Announce: Linux-next (Or Andrew's dream :-)) |
git: | |
| Gerrit Renker | [PATCH 27/37] dccp: Integration of dynamic feature activation - part 2 (server side) |
| David Miller | [GIT]: Networking |
| Radu Rendec | htb parallelism on multi-core platforms |
| David Miller | Re: [PATCH] pkt_sched: Destroy gen estimators under rtnl_lock(). |
