Modules with tags produce 'Update Error'

[adamj88]

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:

modman/modman

Lines 706 to 714 in d58b80f

	###########################################################################
	# Get git remote tracking branch or an empty string
	get_tracking_branch ()
	{
	local tracking_branch=$(git rev-parse --symbolic-full-name --abbrev-ref @{u} 2> /dev/null)
	if [ -n "$tracking_branch" -a "$tracking_branch" != "@{u}" ]; then
	echo $tracking_branch
	fi
	}

Expected behaviour should be:

Updating module_name Already up-to-date.

or resolving the tag to a commit and updating the module

[Silarn]

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?

[colinmollenhour]

@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.

[Silarn]

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.

[colinmollenhour]

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