-1

I´m working on a project with composer. Composer loads multiple private git repositories. Now I want to working on this repos as well and commit them from the root project, so I load the repos via --prefer-source.

Everything works fine, except this:

Whenever I execute composer update it makes a new git clone instead of pull. So I lost all my uncommited changes. Is there a way to get rid of this?

Thanks in advance!

Sascha Wolff
  • 111
  • 1
  • 13
  • If changing your workflow is an option, I recommend reading [my post](http://stackoverflow.com/a/26201961/1459926) to a related question from a while back. – Alexandru Guzinschi Dec 23 '14 at 20:14
  • Unfortunately, this is not a satisfying solution. Is this a normal composer behavior, that it **clones** the private repo **everytime** I run composer update? Even when nothing has changed? Why does composer not just make a git pull instead of a new git clone? – Sascha Wolff Dec 23 '14 at 22:18
  • As long as you stated in your original question that you work inside "vendor", that means that **you** do actually **change something**. Although my solution does not seems satisfying for you, it's the only *proper* way to work on a dependency inside your vendor directory. The alternative is to move your library inside "src" and split it in a new package after it reaches a stable enough state. – Alexandru Guzinschi Dec 24 '14 at 09:33
  • Actually it seems like its **not** normal behavior since the last update fixed it. The issue was that composer cloned everything again though nothing has changed. And that overwrote my self-made changes. Now composer makes nothing when no newer version of my package is found, just like expected. – Sascha Wolff Dec 24 '14 at 09:37
  • "Last update" is a relative term here, because the most recent update did not touch any part of the code that could affect the issue your are referring to. Last change to that code dates 4 days ago and it was a test fix commit. However, hitting this problem should be a hint for you that your flow of working in parallel on your dependencies has ( *at least* ) one problem. – Alexandru Guzinschi Dec 24 '14 at 09:50
  • I didn't mean that the last update fixed it but updating in general fixed the problem. And I don't see why my workflow should be a problem since I use composer the way it's meant to be. Quote from [the docs](https://getcomposer.org/doc/05-repositories.md#package): **Source: The source is used for development. This will usually originate from a source code repository, such as git. You can fetch this when you want to modify the downloaded package.**. That´s exactly what I wanted to do: Modifying the downloaded package to commit the changes back to the repo. No symlinks necessary. – Sascha Wolff Dec 24 '14 at 10:05
  • If you update your dependency often ( *which you will happen in early stages of development* ), you will see that your workflow takes longer from the time you change your dependency and until you can use that change in your application. With a symlink ( *or manually register your directories in composer* ) approach you don't need to commit/push/update your changes in your dependency in order to use them in your main application. That small change will speed your workflow and you will have a more clean CVS history ( *aka: no more "testing" commits.* ). – Alexandru Guzinschi Dec 24 '14 at 10:36
  • Ok, I think you don't get it. ;) I don't make test commits. I work on my package inside my main project (my dev version) . I can test and develop it where it is. I don't need to commit or copy something to test it. Then, when I'm ready, I commit and push the package and can `composer update` it in the prod environment. Very speedy, isn't it? ;) – Sascha Wolff Dec 24 '14 at 10:41

1 Answers1

0

It seems like it was a bug in composer itself. After a composer self-update it works like expected. Don´t know what the problem was...

Sascha Wolff
  • 111
  • 1
  • 13