I don't understand why portage is trying to reset the repo. I'm testing new versions and not ready to push it to remote. Now I lost all changes in ebuild file. I can see portage also runs "git reset --merge refs/remotes/origin/master" on other repos. Reproducible: Always Steps to Reproduce: 1. sudo emerge --verbose --sync Actual Results: >>> Syncing repository 'gentoo-overlay' into '/var/db/repos/gentoo-overlay'... /usr/sbin/git fetch origin --depth 1 remote: Total 0 (delta 0), reused 0 (delta 0), pack-reused 0 Removing metadata/md5-cache/sys-kernel/xanmod-sources-6.1.13 Removing metadata/md5-cache/sys-kernel/xanmod-sources-6.2.1 Removing sys-kernel/xanmod-sources/xanmod-sources-6.1.13.ebuild Removing sys-kernel/xanmod-sources/xanmod-sources-6.2.1.ebuild /usr/sbin/git reset --hard refs/remotes/origin/master HEAD is now at 8b13ae9 update === Sync completed for gentoo-overlay Expected Results: Portage should do nothing since there is no change on remote.
You should set 'volatile=yes' in repos.conf. It has heuristics based on ownership to try figure out if volatile should be yes. This is mentioned in Portage NEWS.
Thanks for pointing out. Is there any way to know this kind of breaking change of Portage through emerge, except checking "https://github.com/gentoo/portage/blob/master/NEWS" manually? It seems to be not included in "eselect news list" and I missed this change.
(In reply to gentoo@imrebuild.com from comment #2) > Thanks for pointing out. > > Is there any way to know this kind of breaking change of Portage through > emerge, except checking "https://github.com/gentoo/portage/blob/master/NEWS" > manually? > > It seems to be not included in "eselect news list" and I missed this change. We considered a news item and went back and forth on it. This whole topic is tricky and I'm sorry about the inconvenience. There was some debate over it at https://archives.gentoo.org/gentoo-dev/message/f58a97027252458ad0a44090a2602897 (and a lot more on IRC). It comes down to whether or not portage should try hard to prioritise a successful sync or not. Then we realised that there's no real way to tell Portage if you want it to "act like rsync" with git (blast everything) or if it should let you use listed repos that it syncs for development. The compromise was to add some heuristics based on repo location + ownership (permissions) and figured that should be good enough. Maybe it wasn't though :(
> There was some debate over it at > https://archives.gentoo.org/gentoo-dev/message/ > f58a97027252458ad0a44090a2602897 (and a lot more on IRC). The argument seems to be different from my use case. I have multiple devices with different hardware configrations(Intel cpu with Intel card, AMD cpu with AMD card, Intel cpu with Nvidia card). So I use one git overlay to manage and sync all personal changes for them. I switched from layman to "eselect repository" because letting Portage manage all repos seems to be more convenient. > It comes down to whether or not portage should try hard to prioritise a > successful sync or not. Then we realised that there's no real way to tell > Portage if you want it to "act like rsync" with git (blast everything) or if > it should let you use listed repos that it syncs for development. From my perspective as a user, pursuing a successful sync by restting all modification sounds a little bit aggressive. Portage may stop when unexpected modification is detected, and guide user to check if the modification is intended. Then the user can decide if the change should be discarded or saved to another place for future use. > The compromise was to add some heuristics based on repo location + ownership > (permissions) and figured that should be good enough. Maybe it wasn't though > :( I believe this behavior only works after https://github.com/gentoo/portage/commit/bd8f9f6c590dca750285e296a6c3d530f1053d89. "volatile" was set to yes for all repos before and that's the reason why my overlay was still safe.
(In reply to gentoo@imrebuild.com from comment #4) > > There was some debate over it at > > https://archives.gentoo.org/gentoo-dev/message/ > > f58a97027252458ad0a44090a2602897 (and a lot more on IRC). > > The argument seems to be different from my use case. I have multiple devices > with different hardware configrations(Intel cpu with Intel card, AMD cpu > with AMD card, Intel cpu with Nvidia card). So I use one git overlay to > manage and sync all personal changes for them. > > I switched from layman to "eselect repository" because letting Portage > manage all repos seems to be more convenient. If you're editing a repo manually, then Portage isn't really managing your repo, is it? > > It comes down to whether or not portage should try hard to prioritise a > > successful sync or not. Then we realised that there's no real way to tell > > Portage if you want it to "act like rsync" with git (blast everything) or if > > it should let you use listed repos that it syncs for development. > > From my perspective as a user, pursuing a successful sync by restting all > modification sounds a little bit aggressive. Portage may stop when > unexpected modification is detected, and guide user to check if the > modification is intended. Then the user can decide if the change should be > discarded or saved to another place for future use. > > > The compromise was to add some heuristics based on repo location + ownership > > (permissions) and figured that should be good enough. Maybe it wasn't though > > :( > > I believe this behavior only works after > https://github.com/gentoo/portage/commit/ > bd8f9f6c590dca750285e296a6c3d530f1053d89. > > "volatile" was set to yes for all repos before and that's the reason why my > overlay was still safe.
(In reply to John Helmert III from comment #5) > (In reply to gentoo@imrebuild.com from comment #4) > > > There was some debate over it at > > > https://archives.gentoo.org/gentoo-dev/message/ > > > f58a97027252458ad0a44090a2602897 (and a lot more on IRC). > > > > The argument seems to be different from my use case. I have multiple devices > > with different hardware configrations(Intel cpu with Intel card, AMD cpu > > with AMD card, Intel cpu with Nvidia card). So I use one git overlay to > > manage and sync all personal changes for them. > > > > I switched from layman to "eselect repository" because letting Portage > > manage all repos seems to be more convenient. > > If you're editing a repo manually, then Portage isn't really managing your > repo, is it? At least partly. My workflow is: 1. Add local change and test. 2. Push to remote once the change is working. 3. Sync to other machines through "emerge --sync" Therefore I can easily add and test different packages(like driver) for all machines. I usually do step 3 before step 2 since I'm the only user of overlay and I push to master branch directly. Portage helps me to pull the latest change. For now I think "volatile=yes" should be sufficient for me. > > > It comes down to whether or not portage should try hard to prioritise a > > > successful sync or not. Then we realised that there's no real way to tell > > > Portage if you want it to "act like rsync" with git (blast everything) or if > > > it should let you use listed repos that it syncs for development. > > > > From my perspective as a user, pursuing a successful sync by restting all > > modification sounds a little bit aggressive. Portage may stop when > > unexpected modification is detected, and guide user to check if the > > modification is intended. Then the user can decide if the change should be > > discarded or saved to another place for future use. > > > > > The compromise was to add some heuristics based on repo location + ownership > > > (permissions) and figured that should be good enough. Maybe it wasn't though > > > :( > > > > I believe this behavior only works after > > https://github.com/gentoo/portage/commit/ > > bd8f9f6c590dca750285e296a6c3d530f1053d89. > > > > "volatile" was set to yes for all repos before and that's the reason why my > > overlay was still safe.
