in the following case: mr-fox ~ # eix-sync * Running emerge --sync >>> Syncing repository 'gentoo' into '/usr/portage'... /usr/bin/git pull Auto packing the repository in background for optimum performance. See "git help gc" for manual housekeeping. error: The last gc run reported the following. Please correct the root cause and remove .git/gc.log. Automatic cleanup will not be performed until the file is removed. warning: There are too many unreachable loose objects; run 'git prune' to remove them. Updating 0151841..6f96f8b error: Your local changes to the following files would be overwritten by merge: eclass/cmake-utils.eclass Please, commit your changes or stash them before you can merge. Aborting !!! git pull error in /usr/portage * Main gentoo tree does not appear to have changed: exiting * Use -a or set have_changed=: in a ! hook to override this check * Time statistics: 3 seconds for syncing 3 seconds total mr-fox ~ # echo $? 0 mr-fox ~ # cat /usr/portage/.git/gc.log warning: There are too many unreachable loose objects; run 'git prune' to remove them.
This is only related with emerge --sync, not with eix: If emerge --sync would return with an error, eix would exit with an error, too. BTW, the reason of your git problem is probably related with bug 552814 (i.e. perhaps that [part of] the fix was reverted or that it is perhaps not used if you specify depth)
(In reply to Martin Väth from comment #1) well, I was thinking about return non-zero even if git returns zero - if the git operation could not be made.
eix-sync does not call git: git is called only indirectly through emerge --sync: It is the latter command which decides to ignore the return code of git. There is not much eix can do against this policy. This policy has to be decided by portage. CC-ing the portage team: It is up to them to decide when emerge --sync is considered to be failed (and possibly how to override errors if just syncing of a "non-main" repository failed)
We have reverted all the sync-depth functionality of the git sync module. There have been too many problems associated with it. The many additional steps required to clean up and restore the correctness of the git repository can take longer than syncing the full depth.
(In reply to Brian Dolbec from comment #4) > We have reverted all the sync-depth functionality of the git sync module. That's not the reason why I have CC'd the portage team: This bug is about error handling of emerge --sync, i.e. that git errors are currently simply "tacitly" ignored - visible only in the output. This seems wrong to me, at least as far as the syncing of the "main" repository is concerned (one might discuss whether every syncing failure of any overlay should lead to an error exit, also. Perhaps at least by default with some possibility of overriding if some overlay is temporarily not accessible...) Anyway, since you mention it here, let me also address this point: > There have been too many problems associated with it. The many additional > steps required to clean up and restore the correctness of the git repository > can take longer than syncing the full depth. It's not a question of time but of reliability. I am not sure whether the current "git pull" (instead of the more advanced "git fetch" + "git reset") really avoids this problem or whether it might need the time-costly "git update-index --refresh -q --unmerged" as preparation as well in some situations (for e.g. overlayfs). Moreover, "git pull" fails for users who want to make local changes (e.g. who use egencache if the repository does not provide an appropriate .gitignore), and - even worse - it fails for users who just happen to sync at the "wrong" time (e.g. before some rebase). (Even if rebases of the main repository are avoided as a rule, there might always happen mistakes which make in unavoidable in some cases, e.g. if somebody pushed a long binary or a copyrighted file by accident.) Every user who runs into an "error" situation - unless he is a very git expert - will probably remove the whole repository and fetch it again which not only costs much more time (also of the user) but also a huge amount of traffic. IMHO, emerge --sync should act similarly as previous "rsync" did: overriding local changes, repairing any possible previous damage (since this is meant for users, developers wanting to keep their changes over an emerge --sync should take care of this by themselves with "git stash" or something similar; the previously chosen "git reset --merge" is actually even quite developer-friendly). Or perhaps one could provide two "modes" for fetching a repository: One as the user-friendly "overriding" variant (using perhaps even "git reset --hard") and the other only meant for developers who want to work in that repository and never want to risk loosing their changes (based on "git pull").
