> >>> * rebase onto the present end of testing >> > > I suspect that this option is a bad idea (and we shouldn't recommend it) - > those commits in testing are going to change, get rebased and reordered and > maybe even removed. > Can the testbranch task tell the difference between the commits that are > intended to be part of the feature branch and the commits that are artifacts > from rebasing off of an old testing? >
Beats me. In the system we discussed and that I mostly implemented (where the changes necessary to make a commit apply were tracked by the rake task) the answer would have been yes; they would have been kept (as an indexed collection of diffs). Everyone but you and I seemed to think that this was more trouble than it was worth, and with the process we are presently using it is up to the branch owner to mintain/manage such conflicts however they see fit. Our agreement is to try doing it this way until/unless actuall problems arise, rather than solving hypothetical problems. The main argument against your (our) concern seems to be based on the fact that git tracks code, not diffs, and so a branch rebased on a commit that later goes away/gets reordered/whatever should still apply cleanly to the new end-of-testing provided only that the code in question wasn't modified in an inconsistent manner. Since this is exactly the sort of thing that would have required manual intervention under our system we're (the argument goes) o worse off and it's a lot less overhead. I'm not entirely convinced but (on agile grounds) I agree that trying it this way first is the right thing to do. -- Markus -- You received this message because you are subscribed to the Google Groups "Puppet Developers" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/puppet-dev?hl=en.
