New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Carthage doesn't appear to "see" latest commit of local repository specified with a relative path #968

Open
bcattle opened this Issue Dec 4, 2015 · 14 comments

Comments

Projects
None yet
@bcattle

bcattle commented Dec 4, 2015

This is kind of an obscure corner case. I have a Cartfile that specifies a dependency on a local repo like this:

git "../ISUtils" 

If I run carthage update I get

$ carthage update
*** Fetching ISUtils
*** Checking out ISUtils at "1.0.0"

I can change the Cartfile to specify the same repo using an absolute path

git "file:///Users/bryan/Documents/ISUtils"

Now if I run carthage update I get

$ carthage update
*** Fetching ISUtils
*** Checking out ISUtils at "1.0.1"

The second checkout is correct, the latest commit is tagged "1.0.1". The commit before that ("HEAD~1") is tagged as "1.0.0".

@bcattle bcattle changed the title from Carthage can't appear to "see" latest commit of local repository specified with a relative path to Carthage doesn't appear to "see" latest commit of local repository specified with a relative path Dec 4, 2015

@brentleyjones

This comment has been minimized.

Show comment
Hide comment
@brentleyjones

brentleyjones Dec 7, 2015

Contributor

I have run into this issue as well. It seems to be a caching issue. After nuking ~/Library/Caches/org.carthage.CarthageKit it saw the latest version.

Contributor

brentleyjones commented Dec 7, 2015

I have run into this issue as well. It seems to be a caching issue. After nuking ~/Library/Caches/org.carthage.CarthageKit it saw the latest version.

@Amnell

This comment has been minimized.

Show comment
Hide comment
@Amnell

Amnell commented Dec 21, 2015

+1

@robertmryan

This comment has been minimized.

Show comment
Hide comment
@robertmryan

robertmryan Dec 29, 2015

@brentleyjones - Thanks for the link to that folder. I wish that were in the documentation somewhere! I was tracking down some other problem that was clearly a result of caching and was looking for some carthage command to purge its caches. I guess we can go behind the scenes and fix it at the very least.

+1

robertmryan commented Dec 29, 2015

@brentleyjones - Thanks for the link to that folder. I wish that were in the documentation somewhere! I was tracking down some other problem that was clearly a result of caching and was looking for some carthage command to purge its caches. I guess we can go behind the scenes and fix it at the very least.

+1

@jomnius

This comment has been minimized.

Show comment
Hide comment
@jomnius

jomnius commented Jan 11, 2016

+1

@ikesyo ikesyo added the bug label Feb 9, 2016

@tkrajacic

This comment has been minimized.

Show comment
Hide comment
@tkrajacic

tkrajacic Mar 16, 2016

Contributor

I am seeing the same problem when using a local repository as dependency. Commits are hardly ever picked up by carthage update and I have to delete the cache every time I want to update the dependency.

Contributor

tkrajacic commented Mar 16, 2016

I am seeing the same problem when using a local repository as dependency. Commits are hardly ever picked up by carthage update and I have to delete the cache every time I want to update the dependency.

@sstadelman

This comment has been minimized.

Show comment
Hide comment
@sstadelman

sstadelman Mar 17, 2016

+1

I don't think this is just happening with the relative paths. I see the same thing with absolute paths also. Opening general issue #1191

sstadelman commented Mar 17, 2016

+1

I don't think this is just happening with the relative paths. I see the same thing with absolute paths also. Opening general issue #1191

@NachoSoto

This comment has been minimized.

Show comment
Hide comment
@NachoSoto

NachoSoto Apr 8, 2016

Contributor

Seeing this too. A workaround is to manually edit Cartfile.resolved with the right hash and do carthage update X.

Contributor

NachoSoto commented Apr 8, 2016

Seeing this too. A workaround is to manually edit Cartfile.resolved with the right hash and do carthage update X.

@drekka

This comment has been minimized.

Show comment
Hide comment
@drekka

drekka Jul 25, 2016

Just got this. None of my repos have any tags. Carthage keeps picking up a commit thats over a month old. Completely ignoring the commits made since then.

Tried deleting the carthage cache directory.

Now carthage is crashing when attempting to read the local repo.

*** Cloning crux-lib
2016-07-25 12:50:24.879 carthage[75515:1086206] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'working directory doesn't exist.'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff9d81e4f2 __exceptionPreprocess + 178
1 libobjc.A.dylib 0x00007fff950ea73c objc_exception_throw + 48
2 CoreFoundation 0x00007fff9d8854bd +[NSException raise:format:] + 205
3 Foundation 0x00007fff8de6f10b -[NSConcreteTask launchWithDictionary:] + 620
4 ReactiveTask 0x0000000100f6a33e TFFFF12ReactiveTask10launchTaskFTVS_4Task13standardInputGSqGV13ReactiveCocoa14SignalProducerCSo6NSDataO6Result7NoError___GS2_GOS_9TaskEventS3__OS_9TaskError_U_FTGVS1_8ObserverGS6_S3__S7__CS1_19CompositeDisposable_T_U0_FTCS_P33_8622FA0C3FE9071537A42FE3BB905E344PipeS10__GS2_GS6_S3__S7__U_FTGS8_GS6_S3__S7__S9__T + 1678
5 ReactiveTask 0x0000000100f667dc TPA__TFFFF12ReactiveTask10launchTaskFTVS_4Task13standardInputGSqGV13ReactiveCocoa14SignalProducerCSo6NSDataO6Result7NoError___GS2_GOS_9TaskEventS3__OS_9TaskError_U_FTGVS1_8ObserverGS6_S3__S7__CS1_19CompositeDisposable_T_U0_FTCS_P33_8622FA0C3FE9071537A42FE3BB905E344PipeS10__GS2_GS6_S3__S7__U_FTGS8_GS6_S3__S7__S9__T + 556
6 ReactiveCocoa 0x0000000100e4a6a7 TFV13ReactiveCocoa14SignalProducer15startWithSignalfFTGCS_6Signalxq__PS_10Disposable__T_T + 759
7 ReactiveCocoa 0x0000000100ddf9b7 TTWu0_R_s9ErrorTyperGV13ReactiveCocoa14SignalProducerxq__S0_18SignalProducerTypeS0_FS2_15startWithSignalfFTGCS0_6Signalwx5Valuewx5Error_PS0_10Disposable__T_T + 87
8 ReactiveCocoa 0x0000000100e1e331 TFFe13ReactiveCocoaRxS_10SignalTypewx5ValueS_18SignalProducerTypewx5ErrorzWxS1_5Error_rS0_P33_F9B5D3FB407CAF9A5D2D355C6E47C3CE12observeMergeFTGVS_8ObserverWxS1_5Value_wxS3__CS_19CompositeDisposable_GSqPS_10Disposable__U0_FGOS_5EventQQPS0_5ValueQS10_5Error_T + 433
9 ReactiveCocoa 0x0000000100e1b0d8 TPA__TFFe13ReactiveCocoaRxS_10SignalTypewx5ValueS_18SignalProducerTypewx5ErrorzWxS1_5Error_rS0_P33_F9B5D3FB407CAF9A5D2D355C6E47C3CE12observeMergeFTGVS_8ObserverWxS1_5Value_wxS3__CS_19CompositeDisposable_GSqPS_10Disposable__U0_FGOS_5EventQQPS0_5ValueQS10_5Error_T + 248
10 ReactiveCocoa 0x0000000100dff830 TFFC13ReactiveCocoa6SignalcFFGVS_8Observerxq__GSqPS_10Disposable__GS0_xq__U_FGOS_5EventQ_Q0__T + 2336
11 ReactiveCocoa 0x0000000100e632cd TFFV13ReactiveCocoa14SignalProducer15startWithSignalFFTGCS_6Signalxq__PS_10Disposable__T_T_U0_FGOS_5EventQ_Q0__T + 221
12 ReactiveCocoa 0x0000000100e4f78e TPA__TFFV13ReactiveCocoa14SignalProducer15startWithSignalFFTGCS_6Signalxq__PS_10Disposable__T_T_U0_FGOS_5EventQ_Q0__T + 110
13 ReactiveCocoa 0x0000000100dff830 TFFC13ReactiveCocoa6SignalcFFGVS_8Observerxq__GSqPS_10Disposable__GS0_xq__U_FGOS_5EventQ_Q0__T + 2336
14 ReactiveCocoa 0x0000000100e016ea TFFFE13ReactiveCocoaPS_10SignalType3mapurFFwx5Valueqd__GCS_6Signalqd__wx5Error_U_FGVS_8ObserverQ_QQPS0_5Error_GSqPS_10Disposable__U_FGOS_5EventQS5_5ValueS6__T + 170
15 ReactiveCocoa 0x0000000100dfcf8f TPA__TFFFE13ReactiveCocoaPS_10SignalType3mapurFFwx5Valueqd__GCS_6Signalqd__wx5Error_U_FGVS_8ObserverQ_QQPS0_5Error_GSqPS_10Disposable__U_FGOS_5EventQS5_5ValueS6__T + 175
16 ReactiveCocoa 0x0000000100dff830 TFFC13ReactiveCocoa6SignalcFFGVS_8Observerxq__GSqPS_10Disposable__GS0_xq__U_FGOS_5EventQ_Q0__T + 2336
17 ReactiveCocoa 0x0000000100e632cd TFFV13ReactiveCocoa14SignalProducer15startWithSignalFFTGCS_6Signalxq__PS_10Disposable__T_T_U0_FGOS_5EventQ_Q0__T + 221
18 ReactiveCocoa 0x0000000100e4f78e _TPA__TFFV13ReactiveCocoa14SignalProducer15startWithSignalFFTGCS_6Signalxq__PS_10Disposab
...

drekka commented Jul 25, 2016

Just got this. None of my repos have any tags. Carthage keeps picking up a commit thats over a month old. Completely ignoring the commits made since then.

Tried deleting the carthage cache directory.

Now carthage is crashing when attempting to read the local repo.

*** Cloning crux-lib
2016-07-25 12:50:24.879 carthage[75515:1086206] *** Terminating app due to uncaught exception 'NSInvalidArgumentException', reason: 'working directory doesn't exist.'
*** First throw call stack:
(
0 CoreFoundation 0x00007fff9d81e4f2 __exceptionPreprocess + 178
1 libobjc.A.dylib 0x00007fff950ea73c objc_exception_throw + 48
2 CoreFoundation 0x00007fff9d8854bd +[NSException raise:format:] + 205
3 Foundation 0x00007fff8de6f10b -[NSConcreteTask launchWithDictionary:] + 620
4 ReactiveTask 0x0000000100f6a33e TFFFF12ReactiveTask10launchTaskFTVS_4Task13standardInputGSqGV13ReactiveCocoa14SignalProducerCSo6NSDataO6Result7NoError___GS2_GOS_9TaskEventS3__OS_9TaskError_U_FTGVS1_8ObserverGS6_S3__S7__CS1_19CompositeDisposable_T_U0_FTCS_P33_8622FA0C3FE9071537A42FE3BB905E344PipeS10__GS2_GS6_S3__S7__U_FTGS8_GS6_S3__S7__S9__T + 1678
5 ReactiveTask 0x0000000100f667dc TPA__TFFFF12ReactiveTask10launchTaskFTVS_4Task13standardInputGSqGV13ReactiveCocoa14SignalProducerCSo6NSDataO6Result7NoError___GS2_GOS_9TaskEventS3__OS_9TaskError_U_FTGVS1_8ObserverGS6_S3__S7__CS1_19CompositeDisposable_T_U0_FTCS_P33_8622FA0C3FE9071537A42FE3BB905E344PipeS10__GS2_GS6_S3__S7__U_FTGS8_GS6_S3__S7__S9__T + 556
6 ReactiveCocoa 0x0000000100e4a6a7 TFV13ReactiveCocoa14SignalProducer15startWithSignalfFTGCS_6Signalxq__PS_10Disposable__T_T + 759
7 ReactiveCocoa 0x0000000100ddf9b7 TTWu0_R_s9ErrorTyperGV13ReactiveCocoa14SignalProducerxq__S0_18SignalProducerTypeS0_FS2_15startWithSignalfFTGCS0_6Signalwx5Valuewx5Error_PS0_10Disposable__T_T + 87
8 ReactiveCocoa 0x0000000100e1e331 TFFe13ReactiveCocoaRxS_10SignalTypewx5ValueS_18SignalProducerTypewx5ErrorzWxS1_5Error_rS0_P33_F9B5D3FB407CAF9A5D2D355C6E47C3CE12observeMergeFTGVS_8ObserverWxS1_5Value_wxS3__CS_19CompositeDisposable_GSqPS_10Disposable__U0_FGOS_5EventQQPS0_5ValueQS10_5Error_T + 433
9 ReactiveCocoa 0x0000000100e1b0d8 TPA__TFFe13ReactiveCocoaRxS_10SignalTypewx5ValueS_18SignalProducerTypewx5ErrorzWxS1_5Error_rS0_P33_F9B5D3FB407CAF9A5D2D355C6E47C3CE12observeMergeFTGVS_8ObserverWxS1_5Value_wxS3__CS_19CompositeDisposable_GSqPS_10Disposable__U0_FGOS_5EventQQPS0_5ValueQS10_5Error_T + 248
10 ReactiveCocoa 0x0000000100dff830 TFFC13ReactiveCocoa6SignalcFFGVS_8Observerxq__GSqPS_10Disposable__GS0_xq__U_FGOS_5EventQ_Q0__T + 2336
11 ReactiveCocoa 0x0000000100e632cd TFFV13ReactiveCocoa14SignalProducer15startWithSignalFFTGCS_6Signalxq__PS_10Disposable__T_T_U0_FGOS_5EventQ_Q0__T + 221
12 ReactiveCocoa 0x0000000100e4f78e TPA__TFFV13ReactiveCocoa14SignalProducer15startWithSignalFFTGCS_6Signalxq__PS_10Disposable__T_T_U0_FGOS_5EventQ_Q0__T + 110
13 ReactiveCocoa 0x0000000100dff830 TFFC13ReactiveCocoa6SignalcFFGVS_8Observerxq__GSqPS_10Disposable__GS0_xq__U_FGOS_5EventQ_Q0__T + 2336
14 ReactiveCocoa 0x0000000100e016ea TFFFE13ReactiveCocoaPS_10SignalType3mapurFFwx5Valueqd__GCS_6Signalqd__wx5Error_U_FGVS_8ObserverQ_QQPS0_5Error_GSqPS_10Disposable__U_FGOS_5EventQS5_5ValueS6__T + 170
15 ReactiveCocoa 0x0000000100dfcf8f TPA__TFFFE13ReactiveCocoaPS_10SignalType3mapurFFwx5Valueqd__GCS_6Signalqd__wx5Error_U_FGVS_8ObserverQ_QQPS0_5Error_GSqPS_10Disposable__U_FGOS_5EventQS5_5ValueS6__T + 175
16 ReactiveCocoa 0x0000000100dff830 TFFC13ReactiveCocoa6SignalcFFGVS_8Observerxq__GSqPS_10Disposable__GS0_xq__U_FGOS_5EventQ_Q0__T + 2336
17 ReactiveCocoa 0x0000000100e632cd TFFV13ReactiveCocoa14SignalProducer15startWithSignalFFTGCS_6Signalxq__PS_10Disposable__T_T_U0_FGOS_5EventQ_Q0__T + 221
18 ReactiveCocoa 0x0000000100e4f78e _TPA__TFFV13ReactiveCocoa14SignalProducer15startWithSignalFFTGCS_6Signalxq__PS_10Disposab
...

@mdiep

This comment has been minimized.

Show comment
Hide comment
@mdiep

mdiep Jul 25, 2016

Member

@drekka That's a duplicate of #1324/#1355. It'd be a great first bug if you were interested in contributing to the project.

It's on my list, but I haven't gotten around to it yet.

Member

mdiep commented Jul 25, 2016

@drekka That's a duplicate of #1324/#1355. It'd be a great first bug if you were interested in contributing to the project.

It's on my list, but I haven't gotten around to it yet.

@ikesyo

This comment has been minimized.

Show comment
Hide comment
@ikesyo

ikesyo Aug 21, 2017

Member

Finally submitted a fix #2125.

Member

ikesyo commented Aug 21, 2017

Finally submitted a fix #2125.

@mdiep mdiep closed this in #2125 Aug 25, 2017

@lacyrhoades

This comment has been minimized.

Show comment
Hide comment
@lacyrhoades

lacyrhoades Oct 12, 2017

This happened to me on carthage 0.26.0 just now, with Cartfile pointed at a github fork

  1. Did carthage update a few times
  2. Had never specified a branch or pushed a new tag in the Cartfile
  3. Realized my mistake, started trying to force a branch name, "branchname", "HEAD", etc.
  4. Carthage would never see the new commits
  5. Cleared cache and all good

lacyrhoades commented Oct 12, 2017

This happened to me on carthage 0.26.0 just now, with Cartfile pointed at a github fork

  1. Did carthage update a few times
  2. Had never specified a branch or pushed a new tag in the Cartfile
  3. Realized my mistake, started trying to force a branch name, "branchname", "HEAD", etc.
  4. Carthage would never see the new commits
  5. Cleared cache and all good
@einsteinx2

This comment has been minimized.

Show comment
Hide comment
@einsteinx2

einsteinx2 Oct 13, 2017

Just happened to me right now. Switched from my own fork to the upstream repo. Carthage kept finding some commit from 18 months ago even though I have it set to the master branch. Cleared the cache folder as mentioned above and it now sees the correct commit.

einsteinx2 commented Oct 13, 2017

Just happened to me right now. Switched from my own fork to the upstream repo. Carthage kept finding some commit from 18 months ago even though I have it set to the master branch. Cleared the cache folder as mentioned above and it now sees the correct commit.

@ikesyo

This comment has been minimized.

Show comment
Hide comment
@ikesyo

ikesyo Oct 14, 2017

Member

@lacyrhoades @einsteinx2 This issue is about local git repositories, not about repositories on GitHub. You may be hitting #2143 so please follow that issue instead.

Member

ikesyo commented Oct 14, 2017

@lacyrhoades @einsteinx2 This issue is about local git repositories, not about repositories on GitHub. You may be hitting #2143 so please follow that issue instead.

@Carthage Carthage locked and limited conversation to collaborators Oct 14, 2017

@Carthage Carthage unlocked this conversation Dec 8, 2017

@jdhealy

This comment has been minimized.

Show comment
Hide comment
@jdhealy

jdhealy Dec 8, 2017

Member

Haven't yet tested the implications on this from #2260 (which reverts #2125 (which closed this issue)), but I'm assuming this is again an issue with the release of 0.27.0.

Workaround (as yet untestedpassed my testing)

When file:// URLs can't be made absolute (as often is the case to allow differently named user accounts), create a symlink to the respective repository directory within /Users/Shared or /usr/local/share.

Member

jdhealy commented Dec 8, 2017

Haven't yet tested the implications on this from #2260 (which reverts #2125 (which closed this issue)), but I'm assuming this is again an issue with the release of 0.27.0.

Workaround (as yet untestedpassed my testing)

When file:// URLs can't be made absolute (as often is the case to allow differently named user accounts), create a symlink to the respective repository directory within /Users/Shared or /usr/local/share.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment