On Jan 9, 2015, at 3:49 PM, René J.V. Bertin <[email protected]> wrote:
> On Friday January 09 2015 13:14:16 Lawrence Velázquez wrote: > >> Yes, you'd have to resolve conflicts in your repository. This happens less >> often than you'd think. I don't think it outweighs the benefits gained by >> having a simpler development setup. > > Esp. one in which once every so often you don't wonder why things that worked > "the other day" no longer work ... oh, wait, I did a selfupdate :) Yes, exactly. No more weird shadowing issues, and conflicts are not overwritten without your knowledge. > But if port sync uses `git rebase` when using git instead of svn, don't you > lose local changes? It uses `git pull --rebase` or `git svn rebase`, depending on your setup. Thus, uncommitted/unstashed local changes will cause the Git update to fail, although `portindex` still runs and updates your indices. >> From whatever location the local repo uses as its remote. `port sync` just >> does a Subversion update or Git rebase. > > That still doesn't explain how a local, file:// repo could get a remote > location assigned to it (something my copy of sources.conf doesn't explain > either, and I'm not fluent enough in Tcl to grasp the code at the link below > without staring at it for a long time). I don't understand your confusion. If the "repository" is a Subversion checkout or Git clone, it already knows where to pull updates from. If it's not, then it's simply not updated. And `portindex` refreshes the indices either way. > Anyway, the change to using svn is exactly the sort of thing I'll try out > first on my Linux box. I take it `port selfupdate` will still work? I think so, but I'm not sure. I don't use `selfupdate` because I use base from trunk. vq _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
