{"action":"opened","issue":{"url":"https://api.github.com/repos/vanadium/issues/issues/821","labels_url":"https://api.github.com/repos/vanadium/issues/issues/821/labels{/name}","comments_url":"https://api.github.com/repos/vanadium/issues/issues/821/comments","events_url":"https://api.github.com/repos/vanadium/issues/issues/821/events","html_url":"https://github.com/vanadium/issues/issues/821","id":112919670,"number":821,"title":"Using jiri to track non-master remote branches","user":{"login":"jamesr","id":7497301,"avatar_url":"https://avatars.githubusercontent.com/u/7497301?v=3","gravatar_id":"","url":"https://api.github.com/users/jamesr","html_url":"https://github.com/jamesr","followers_url":"https://api.github.com/users/jamesr/followers","following_url":"https://api.github.com/users/jamesr/following{/other_user}","gists_url":"https://api.github.com/users/jamesr/gists{/gist_id}","starred_url":"https://api.github.com/users/jamesr/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jamesr/subscriptions","organizations_url":"https://api.github.com/users/jamesr/orgs","repos_url":"https://api.github.com/users/jamesr/repos","events_url":"https://api.github.com/users/jamesr/events{/privacy}","received_events_url":"https://api.github.com/users/jamesr/received_events","type":"User","site_admin":false},"labels":[],"state":"open","locked":false,"assignee":null,"milestone":null,"comments":0,"created_at":"2015-10-23T00:45:28Z","updated_at":"2015-10-23T00:45:28Z","closed_at":null,"body":"We'd like to use Jiri to track tagged releases from a repo (in this case V8) that aren't off of master.  Our manifest entry looks like this:\r\n\r\n```\r\n    <project name=\"v8\"\r\n             remote=\"https://chromium.googlesource.com/v8/v8.git\"\r\n             path=\"src/v8\"\r\n             revision=\"3f036fc0ba4ca4483fe77822f8605c277d37ee24\"/>\r\n```\r\n\r\njiri update tries by default to run `git pull origin master` before running `git reset --hard 3f036fc0ba4ca4483fe77822f8605c277d37ee24`.  The rebase implied by the git pull fails because 3f036fc0 isn't from the remote master branch.  There are several possible options here that are all pretty easy to implement if we can agree on the desired semantics.  The desired semantics depend on what we expect updating revision to do - can it switch between remote branches, for instance - and what the tool is supposed to do with local changes.\r\n\r\nI think a simple modification to the current behavior is to replace\r\n````\r\ngit pull origin master\r\ngit reset --hard <refspec>\r\n```\r\n\r\nwith\r\n```\r\ngit fetch origin\r\ngit rebase <refspec>\r\ngit reset --hard HEAD\r\n```\r\nwhere <refspec> is the revision if specified on the Project or `origin/master` if not.  This has two consequences:\r\n\r\nFirst, it fetches all configured refs exposed by the remote instead of just 'master'.  If this isn't desirable, then we could retain the fetch-only-master behavior and provide another attribute on the Project that controls whether we fetch it.  This is needed if the desired rev isn't reachable from 'master' but is from somewhere else.\r\n\r\nThe second change rebases local changes against the specified revision instead of the remote 'master', if specified.\r\n\r\nDoes this sound reasonable?  If this would break existing users we could also control the new non-master-tracking functionality with project attributes.\r\n\r\n/cc @nlacasse @tatatodd @shinykitten"}}