modman icon indicating copy to clipboard operation
modman copied to clipboard

Modules with tags produce 'Update Error'

Open adamj88 opened this issue 10 years ago • 4 comments
trafficstars

I'm using modman to deploy specific versions (tagged as releases) of modules, when running modman update-all these modules produce the following error:

Updating module_name
Could not resolve remote tracking branch, code will not be updated.

ERROR: Error occurred while updating module_name

It appears the following git command is responsible when returning an empty string: https://github.com/colinmollenhour/modman/blob/d58b80f2f9e60d3287577480ad78066d44ed530c/modman#L706-L714

Expected behaviour should be:

Updating module_name Already up-to-date.

or resolving the tag to a commit and updating the module

adamj88 avatar Jun 01 '15 14:06 adamj88

I submitted a pull request a while back which partially resolved this, as this is a case where your repo is not on an actual branch and is instead checked out at a specific commit. (A tag, in your case.)

My code attempts to identify the branch with that commit in it and checkout that branch before updating the code. I had a flaw in my detection though which made it only work for HEAD commits... I just submitted a new PR to fix this.

However, this doesn't include tag detection. I feel like this would require some kind of additional flag to tell modman "hey, keep my repos on any tagged commits" as the default functionality is to run a fetch and pull - which assumes a branch setup.

What sounds better to you?

Silarn avatar Nov 18 '15 21:11 Silarn

@adamj88, I believe tags are really meant to be immutable.. That is, version 1.0 should not change but rather should be updated to version 1.1 which gets a new tag. So it should not be up to modman to choose which tag to use if the user chose a tag already. Now if the author of the code is force-pushing tags then they should be using a branch instead like a "1.x" branch that always tracks the latest 1.x tag.

colinmollenhour avatar Nov 19 '15 21:11 colinmollenhour

I guess this comes down to: If detached heads not being updated is intended functionality, then it should really just be a warning instead of an error when you run an update-all.

Running a direct update on a specific repo could be an error, as doing so suggests the user wants the repo to be updated when it has no clear update path in its current state, however an update-all does not necessarily mean this and should simply give a warning.

Silarn avatar Nov 20 '15 15:11 Silarn

Agreed, during update-all an error finding the tracking branch should be just a notice and not an error.

colinmollenhour avatar Nov 20 '15 16:11 colinmollenhour