Hi, On Tue, Aug 2, 2011 at 21:08, martin f krafft <madduck@xxxxxxxxxxx> wrote: > also sprach Bert Wesarg <bert.wesarg@xxxxxxxxxxxxxx> [2011.08.02.1506 +0200]: >> while I appreciate, that you dig this topic up. I think you are trying >> to solve the wrong problem first. My main problem with the TopGit >> approach is, that you can't freely change the dependencies of a topic. >> This may be not the most common case in distro development. But in my >> eyes more problematic than maintaining the meta data. > > Hello Bert, thank you for taking the time to respond! > > Could you please try to illuminate me a bit on a use-case of > changing dependencies? I am aware that TopGit has had a problem with > changing dependencies due to renamed branches, and I think I have > a solution to that (encode the dependent ref, not the branch head), > but I cannot come up with a use case for freely changing > dependencies just like that. Not each feature branch may end up in master. And there does not need to be one feature branch which depends on all other features. For the latter you have probably an empty feature branch which just depends on all features. I call this branch mostly 'tip'. Removing a feature branch from the tips dependency list only with merges can't be done right now, and the proposed solutions never reached a usable state. My second usecase is to convert a big quilt patch series into TopGit. Such big Quilt patches have mostly an artificial dependency to its predecessors. Removing these artifical dependencies makes it necessary to remove dependencies from patches. > >> For my first mentioned problem, I think a new 'system' needs to be >> 'rebase' based, not merge based like TopGit. > > The problem with rebasing is that you cannot publish the branches. That doesn't hold you back to publish them. But the other side need to know how to deal with them. Saying that doesn't mean I know a good way to deal with them. I mostly end up using plumbing commands to deal with this. > > However, maybe I am simply not seeing the light here. Do you have > some further ideas about what this would be like? Please keep in > mind that what I seek is not just a way to bring feature branches > up-to-date with upstream, but also to have those branches be shared > among developers. I think that having the TopGit philosophy of one feature branch is one patch, you can handle an rebased upstream. Thinking of a feature branch as a series of patches makes this way harder. But I would like to have this philosophy. Bert > > Thanks, > -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html