On Thu, 2008-11-20 at 12:56 -0600, Manoj Srivastava wrote: > > Manoj, could you detail a particular scenario where you had conflicts > > between the topic branches ? > Sure. Back when I was still the sole maintainer of refpolicy, I > had a branch where we had a Debian specific user role called netuser -- > this added to the the set of roles upstream policy had created, > (sysadmin, staff, user, ...). This required modifications of files that > touched a lot of places, since a user entity is used in a lot of > security domains (file permissions, ability access other security > domains, etc). [...]
This is all very interesting; I don't think anyone should doubt that conflicts arise. I think this sub-thread started with the desire to have a moving merge commit that got re-written. With git you could potentially do this; I don't know that there is a normal UI way of doing it[1]; it's the sort of thing I normally do using my 'git-amend' script (http://utsl.gen.nz/git/git-amend ) which just pops open HEAD in an editor and lets you mess with it. In this way the previous merge commit can be removed from the history, which makes it equivalent to the case where you re-merged continuously, but you get the merge behaviour you desire. If I can understand the use case a little better I could possibly propose built-in functionality to allow this kind of thing. Why would you want to drop those intermediate merge commits? Sam. 1. well, there is, grafts and filter-branch, but it's a bit long-winded. _______________________________________________ vcs-pkg-discuss mailing list [email protected] http://lists.alioth.debian.org/mailman/listinfo/vcs-pkg-discuss
