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; 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
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?
1. well, there is, grafts and filter-branch, but it's a bit long-winded.
vcs-pkg-discuss mailing list