Hi,
Jan Nieuwenhuizen wrote:
> The bad thing is that this does not play well with tg undepend;
> it won't work to re-add a previously removed dependency. This
> --add is implemented as a merge, and all merge commits are
> already present; it is only that lateron they are reverted.
>
> Any ideas on how to fix that?
Interesting - I had imagined changing dependencies working in an
entirely different way.
Let's say your history is
B -- (some mess) -- P
where P is your current branch head, and B is the current top base, a
merge of all your current dependencies. Now you change your
dependencies drastically, and you end up with a new top base B'. Then
ideally you want your new branch head P' to have the same tree as if you
had run "git rebase --onto B' B P", but of course you want to preserve
the history, so you could
$ 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'
or something like that. The line marked with a (*) doesn't work as it
should in current git as far as I remember, but it would be a simple
change. The point is to achieve the result
B -- (some mess) -- old P -- P
/
B'
with the diff from B to old P being approximately the same as the diff
from B' to P, even if we just dropped some dependencies.
The main problem I see with this story is that if B' is just B with some
new changes added this is overly complicated. In other words, in the
simple case of moving from (say) a patch based on master to a patch
based on next, one would probably prefer
B -- (some mess) -- old P -- P
\ /
---------------------- B'
and similarly for moving from depending on master+(one additional patch)
to next+(that same patch).
Hope this helps, and sorry I don't have something more constructive to
say. Thanks for starting this going.
Jonathan
--
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
