On Fri, Sep 12, 2008 at 02:27:13PM +0200, Jan Nieuwenhuizen wrote: > On vr, 2008-09-12 at 13:00 +0200, Petr Baudis wrote: > > > But this is rewriting history, isn't it? > > No (that would be useless), see > > http://kerneltrap.org/mailarchive/git/2008/8/13/2925144 #first tg redepend idea Huh. I can't see how that could ever work. > $ git checkout -b P' P > $ git rebase --onto B' B > $ git checkout P > $ git merge --no-ff --no-commit B' (*) > $ git read-tree -u P' > $ git commit > $ git branch -D P' The read-tree step is broken, you can't do that. The dependencies content will be gone from your base, but not from the actual head - what's the point of removing them at all? Actually, tg patch will then show diff not only of your patch, but the removed dependencies as well! There's plenty of other problems with this approach as well. And I can't see how readding a removed dependency would work at all either. > I've just implemented the second idea > > http://kerneltrap.org/mailarchive/git/2008/8/15/2954214 > > but haven't got any time to test it yet. Then there's also > > http://kerneltrap.org/mailarchive/git/2008/8/15/2952004 > > to consider. That's good point, indirect dependencies problem did not occur to me before. That's troublesome... I'm beginning to wonder if it is worth the trouble to support changing dependencies in existing branches at all, except in the case the dependency got merged to upstream (then we don't hit any of these troubles). I'm stopping to see any way how to sanely support dependency removal without history rewriting, since we rely on Git for our all changes propagation. > > Currently, I'm thinking that something like .topundeps (or !-prefixing > > dependencies in .topdeps) is the only way to implement this... > > Yeah, i've been thinking that too. It would be nice if we could > hack around that. It seems that the two redepend ideas get around > it at the expense of creating the whole list of dependencies, > which is much too expensive for my taste. Actually, you would have to do this here as well for what we could call "the evil Jonathan scenario": > Make a topic branch t/foo depending on master. > Change the dependency of t/foo to the older version maint. > Make a new topic branch t/bar depending on t/foo and master. When creating t/bar, you _need_ to look in t/foo dependencies to figure out that you really do need the master stuff merged. Even worse, these dependency removals act dominantly through merges. Consider t/xyzzy and t/qux both depending on master. If you remove master dependency from t/xyzzy and then merge them together, you'll lose master from the result, even though t/qux needs it, because of the dependency removal commit! More and more worms turn up in the can. -- Petr "Pasky" Baudis The next generation of interesting software will be done on the Macintosh, not the IBM PC. -- Bill Gates -- 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
