I'm trying to switch to the dev version of Views. Repository instructions worked and I was able to git clone Views.

However, listing the available branches with git branch -a only shows * 7.x-3.x .

And trying to add a "dev" branch with pull returns an error:

$ git pull origin 7.x-3.x
From http://git.drupal.org/project/views
 * branch            7.x-3.x    -> FETCH_HEAD
Already up-to-date.
$ git pull origin 7.x-3.x-dev
fatal: Couldn't find remote ref 7.x-3.x-dev

What am I doing wrong?

  • 1
    Have you actually read the answer before editing your question?
    – Chapabu
    Commented May 1, 2012 at 21:13
  • @Chapabu, The purpose of these edits were to make the question more readable--for future readers--as I tried several different commands and the previous version read strange. The question is the same and the answer remains relevant. What is your concern?
    – xtian
    Commented May 5, 2012 at 20:11

4 Answers 4


If I do

git clone --recursive --branch 7.x-3.x http://git.drupal.org/project/views.git

and then

git branch -r

I get

origin/HEAD -> origin/7.x-3.x  

I believe you need the recursive flag to get all remotes. Not sure if you did that, but a quick git fetch will update your list of remotes.

git pull origin 7.x-3.x-dev
fatal: Couldn't find remote ref 7.x-3.x-dev
Unexpected end of command stream 

I think this is just due to the naming conventions, current dev is HEAD afaik.

git pull origin 7.x-3.x
From http://git.drupal.org/project/views
 * branch            7.x-3.x    -> FETCH_HEAD
Already up-to-date.

I believe that any branch (not tag) can be considered 'dev' for that drupal version.

Hope this helps.

  • 1
    +1 for "...this is just due to the naming conventions, current dev is HEAD..."
    – xtian
    Commented Aug 29, 2012 at 13:19
  • 1
    Any Drupal development snapshot is created from a git branch. On Drupal.org git branch names never include the -dev part.
    – apaderno
    Commented Aug 29, 2012 at 15:14

I'm not a Git expert, but as I understand it all of the releases of the dev branch listed on the project page are made directly to the 7.x-3.x branch. Of course you're free to create your own branches locally for your own needs, but the master-like branch, which includes all of the releases pushed to drupal.org, is always going to be that 7.x-3.x branch.

If you want to switch to one of the tagged releases, use git tag to get a list of all the releases. Then, to check out the 7.x-3.1 release (for example), use git co 7.x-3.1.

If you intend to edit the code for this release, you can then create a new branch (as Git explains) by using git checkout -b mycustombranch.

  • 1
    +1 for the answer, although to clarify: If maintainers are using git on Drupal.org properly there should never be a master branch - there should only be version specific branches.
    – Chapabu
    Commented May 1, 2012 at 9:49
  • @Chapabu Thanks for the clarification! I updated my answer. Commented May 1, 2012 at 10:14
  • I now remember why I hesitated accepting the answer! Today, when I attempted to add a patch from last month, $git apply said the patch doesn't apply, and yet the patch is very recent. And just to be certain, I grep'd the file for the change line and its not in the latest release 7.x-2.0-beta. Using $git tag I get the following 7.x releases: 7.x-2.0, 7.x-2.0-beta1 but you'll see there is no 7.x-2.x-dev. So my original question is really unanswered. Either 'dev' is not in the repository, or it is--in which case why does the new patch not apply?
    – xtian
    Commented Aug 15, 2012 at 23:48
  • 2
    The dev branch is the 3.x branch. HEAD will always be the latest dev release; each individual dev release will not usually be tagged. As for why the patch doesn't apply, that's specific to the patch you're trying to apply. However, the date or how recent the patch is doesn't matter-- it's only whether the code is changed or not. Almost all patches on drupal.org will specify to which version of a module/core they apply. Commented Aug 15, 2012 at 23:56
  • 1
    Draggableviews has a 2.0 release, so I'm not sure where you got beta1. If you follow the instructions here this should give you a working copy: drupal.org/node/283087/git-instructions/7.x-2.x However, it sounds like you are very confused about Git. I would read a Git tutorial or two first; it will definitely pay off in saving you time later. Commented Aug 17, 2012 at 2:18

The way to pull the repository for the 7.x-3.x branch of the Views module (i.e. the development snapshot 7.x-3.x-dev for the Views module) from Drupal.org for the first time is executing the following command:

git pull git clone --recursive --branch 7.x-3.x http://git.drupal.org/project/views.git

After that, if you need to keep the local repository for the Views module updated, you should execute the following commands:

cd views
git reset --hard
git pull origin 7.x-3.x

To make it clear: A Drupal development snapshot is created from a git branch, while a Drupal release is created from a git tag. The name of the git branch is the name of the Drupal development snapshot without the -dev part. In your case the development snapshot is 7.x-3.x-dev, and the git branch is 7.x-3.x.
Furthermore, the git tag used to create a Drupal release must follow a specific schema. Tags similar to 7.x-3.0 (or 7.x-3.1-beta3) are for the 7.x-3 version of a module, and its development snapshot is named 7.x-3.x-dev. On Drupal.org, you cannot create a Drupal release from a git tag similar to beta-release, or a Drupal snapshot from a git branch similar to test-branch.


EDIT: As pointed out, the question was "How do I git pull a dev branch" which has been partially demonstrated in the other answers. Yet, a key second part of any answer must include a translation of the Drupal -dev naming convention. Simply because it does not appear using the commands $git branch or $git tag while -dev clearly is evident in the "Development releases" table on a module's main page. This is my attempt to clarify this with a reasoned, but in no sense authoritative, definition:

There is a sense -dev is equivalent to rough draft in the familiar metaphor of writing. An article describes setting up "your own Git repository viewer" on a local repository (for developers who prefer to not host in the cloud),

"You can choose either the latest stable version or the master version, but keep in mind the master version may have bugs since developers are actively working on it." PHPMaster

Now we have a definitive statement describing a convention for active development on the "master version". And here is the principal issue I've been working on in this post: relating a convention (developer convention, programming best practice, or The Drupal Way) to the operation and use of the git application.

Now, you'll have to bear with me for a moment as I digress. In my novice git-ucation, I wasn't sure if "master" was also a naming convention of developers or built into the git application itself. And here I turned to a site search at the maintainers site, git-scm.com, to find this gem:

"In the default case that is automatically written by a git remote add command, Git fetches all the references under refs/heads/ on the server and writes them to refs/remotes/origin/ locally. So, if there is a master branch on the server, you can access the log of that branch locally..." git-scm

if there is a master branch? That does not suggest "every" git repository has a "master". Fortunately this mystery was quickly solved by creating my own test repository and a subsequent search at Stackoverflow confirms this is technically true, a new git repository without any commits does not have a master branch:

"Now, the reason you wouldn't have a master branch even after doing a git init is that there are no commits: when you create your first commit, you will then have a master branch." stackoverflow: "fatal: Not a valid object name: 'master'"

Its a strange example to find at the maintainers site, adding a remote repository without any commits, but in the Land of Oz customization to the nth degree is a known hazzard.

Now, returning the helpful advise I've received to this point. Kiamlaluno points out,

"A Drupal development snapshot is created from a git branch, while a Drupal release is created from a git tag." Instead of git tag try with git branch."

And yet, still won't say what I'm about to say. Now its finally possible to understand the -dev branch in Drupal as the "development snapshot" created from the "master" branch of the git branch hosted at Drupal.org. The -dev branch label is not present in the branch command output unless you put it there yourself in your local cloned repository. This I've also tested, recently, because I found it useful to label my current working brach different than the remote master branch of the same name.

I chose to use the git versions and use git to make my own -dev branch of a few modules to troubleshoot the interaction of Views and Draggableviews modules, because. as Kiamlaluno points out, the tar and gzip files in the "Development releases" table are snapshots. Thus, by reason they are always older than the master branch.

In another curious event, here is a definition of snapshot from a Wikipedia Disambiguation Page,

Snapshot: "A view of a source code repository as it was at a particular time for the purpose of revision control in software development." Wikipedia

Its ironic to find this definition for "source code repository" not in an wiki-article, or at wiktionary, but tucked away in a disambiguation page. Not ironic because the definition should be tucked away in a remote location, rather this brings to mind a printing term widow, which does have its own wiki-article page and wictionary entry, unlike git's 'master branch', or Drupal's '-dev branch' (at the time of this missive).

  • Blimey, looks like you've had a long day's reading :) Thanks for sharing, this is really useful info
    – Clive
    Commented Aug 29, 2012 at 15:34

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.