"Eric A. Borisch" <ebori...@macports.org> writes: > Thanks for all the hard work with this transition! I'm sure once we're all > "over the hump" we'll look back and wonder why we waited so long. > > Just so I'm clear on this, is the desired approach for each committer to: > > == setup == > 1) clone macports/macports-ports to the local filesystem > == every change == > 2) make changes > 3) 'add' changes > 4) 'commit' changes > 5) 'push' changes (to macports-ports) > > Oh, and and to capture upstream changes, somewhere after 1 and before 5 (4? > 3?), > > a) git fetch > b) git rebase origin/master > It looks like git pull --rebase does both of those, so that's not too bad.
I've noticed that when I do this and I run 'port sync', macports apparently tries to rebase? 9 times out of 10 I wind up in a detached head state. I'm not sure I agree with attempting to modify the git repo at all. For example, what if I'm in the middle of bisecting and need to add/remove a port? Why does 'port sync' call at all what the state is? _______________________________________________ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
