Problem: If you delete the master branch of your project, people will get a git warning when they clone your project:

warning: remote HEAD refers to nonexistent ref, unable to checkout.

In addition, the cloned project folder will be empty which is a huge usability WTF.
Proposed solution: Add an option to the administration pages of a project where maintainers can select a default branch. Github does it this way.
I think the default branch is defined in the file .git/HEAD of a project repository, unfortunately it cannot be pushed to the servers.

Documentation on how to remove the master branch

It's available


It seems that a simple one liner can be run on the remote repo to set a default branch git symbolic-ref HEAD refs/heads/<new-default-branch>


Title:Setting a default branchLet set a default branch on git repositories
Priority:Normal» Major
Issue tags:+git phase 3

Yep, we definitely need that, not sure exactly what should be the right project to patch, but sounds like versioncontrol_git inside repo manager.

Changing priority as cloning and end up with no files is a really bad status.

Title:Let set a default branch on git repositoriesSetting a default branch
Priority:Major» Normal
Issue tags:-git phase 3

A big +1 for this.

The reason this is important from my standpoint is that I, like many others, used to use HEAD in CVS as my main development branch. Development snapshots were generated from CVS HEAD. In the migration, CVS HEAD has been moved to Git master, but you can't create a development snapshot from Git master. This makes master ill-suited for use as a main branch.

Options are:

1) Keep master but just don't use it and hope no-one else uses it. This becomes a "convention" that the project maintainer knows about, but is not obvious to anyone else. Using Views as an example, Views has a 7.x-3.x branch with the main 7.x-3.x development and dev snapshot releases. Likewise, it has a 6.x-3.x and a 6.x-2.x, etc. But the master branch holds some unknown version of some 6.x branch. What is master being used for here? Only the maintainer knows for sure. Conventions like this are undocumented and unenforceable.

2) Rename master to something like [major].x-[minor].x and use this new named branch as the main development branch. Delete master so it can't be used and is not visible. The problem is git clone will set the default branch to master, causing the above error if you have deleted master.

Being able to designate which Git branch is your main development branch, as proposed by @klausi, seems like a great way to go. It lets you do 2) without the error. This would allow maintainers to manage their projects as they liked, moreover would serve as a concrete piece of documentation about which branch was the real main branch.

Title:Setting a default branchLet set a default branch on git repositories
Priority:Normal» Major
Issue tags:+git phase 3

Cross posted - restoring tags from #2


Yeah, we need something like the Github integration branch thingy here. Go go go!

Title:Let set a default branch on git repositoriesLet maintainers set a default branch on git repositories

Yeah, we were talking about this in IRC. Presumably the default HEAD branch is also what gitweb is using, which was the other thing people were concerned about when considering ditching 'master' for well-named branches.

One idea we kicked around was adding a node/N/edit/git subtab on project pages (or something) for various settings project maintainers might need to make to their Git repo (aside from the ACLs at node/N/maintainers). One obvious setting would be from here:

#1025916: Add a setting for enabling version control for a project

The default branch from this issue is clearly another. Sam said he had some other ideas about stuff that could go here, but I'm not sure what they are.

If we're going this route, it probably makes the most sense to do this as a combination of versoncontrol_git and versioncontrol_project. I.e. vc_project is responsible for the tab and basic form plumbing. Then vc_git can alter that form to inject its own Git-specific settings. Or something. It gets a little tricky trying to keep everything totally abstracted and independent. We obviously want vc_git to work without all of Project*. OTOH, vc_git has no real UI of its own, so it kind of needs vc_project (at least for now) to expose this to maintainers.

p.s. Sorry, I should say "node/N/edit/version-control" or something generic. vc_project doesn't (and shouldn't) know what particular VCS a given project's repo is. It just knows it's a VCAPI supported repo. In theory, you can have VCAPI + project + vc_project and a bunch of different backends and let project maintainers choose what kind of repo they want for their project. That's now how d.o works, but it should/could be the way VC* + Project* work.

node/N/edit/vcs would be simpler.
I know at least does not have a HEAD because i renamed master to 6.x-2.x

Just had a conversation about this on IRC with sdboyer & mikey_p.
See #1078084: Allow project maintainers to specify a "Default Branch"
mikey_p said he was going to work on a patch for vc_project to do this.




There's a first draft of the UI for this and other settings available at:

Looks great to me.

I only wonder if this should be integrated under the 'edit / releases' tab somehow to better group related repository & release information & settings.
That might get complicated, though. This looks much simpler to implement.

After following Moving from an old CVS HEAD (master) to a 7.x-1.x branch we end up with a repo summary page that exhibits a dead body, e.g., OTOH, shows no shortlog at all, apparently because the project never had a master branch.

Yet another case is : I've tried removing the remote master branch (git branch -a is not showing it anymore), but surprisingly, the repo summary page is still displaying it (a dead body, too).

What we need is to be able to pick a head other than master from the "heads" list at the bottom of the summary page, which should be used for creating the shortlog on the summary page.

I think this is directly related to the issue of what to clone in the OP — it should be the same head. However, I don't see the connection to the UI linked from #16. Am I missing something?

@salvis: Look under the Repository / Settings tab in the mockup. You'll see a fieldset where you get to pick the default branch - this will be the branch that the HEAD remote ref points to.

@eliza411: This fieldset has the title "Title" in the mockup - it should probably be "Default branch" or something along those lines. Otherwise, it looks great, and exposes more functionality than I expected.

Thanks, TR, I didn't realize the mock-up was clickable.

Could it be too ambitious? too far off? The first page has pretty much the same information as the repo summary page.

heh, also just ran into this. Added a warning to the handbook page.

Even though technical details have been already fleshed out, this thread on the git mailing list explains some internals:

Could we add a quick fix to d.o until a perfect UI has been figured out?

Could we add a quick fix to d.o until a perfect UI has been figured out?

+1 on that.

The additional options and UI look great, but for now adding a simple setting, or way to do this with a git command (or even a smart default that realizes when the "master" branch is missing) would be great already.

I'm pretty sure this is blocked on time and in a "patches welcome" state, fancy UI not required.

Secound step: Respect the default branch for the Git instructions: #1291674: Use VersioncontrolGitRepository::getDefaultBranch() for the default selection.
However #25 must be fixed/comitted first.

Nice! Thanks a lot Niklas for working on this!

Another blocking issue, that needs review: #1293720: Allow backend specific repository controllers

Status:Active» Needs review

While the API is on it's way: - a simple user interface for changing the default branch. I'd love reviews of UI and code.

Yay, #1291674: Use VersioncontrolGitRepository::getDefaultBranch() for the default selection is fixed.

That means this depends only on reviews of the sandbox project, especially having the user interface texts in mind, AND having sdboyer set up a production like staging site to test it more thoroughly before deployment.

Assigned:Unassigned» sdboyer

@sdboyer: Can you get this on your schedule for office hours?

Status:Needs review» Needs work

Looks like this got promoted to a full project, so the URL is now

I filed a few issues in the module's queue, so marking this as needs work for now.

Thanks for reviewing. I'll set it back to needs review once I solved the issues.

Yes, I decided to promote it, mostly because project_git_default_branch as a name won't eat up precious namespace. Forgot to link the new page here - thanks again ;)

Status:Needs review» Reviewed & tested by the community

I filed a docs cleanup patch, but other than that the code looks great.

Setting RTBC, apologies if that's not the right status since sdboyer hasn't gotten a chance to review it.

That is great.

But how to run it on the remote repo?
EDIT: That was a question to #1

So what do we need to do to move this forward? We can hope for @sdboyer's participation, but it should move forward anyway if we can't get that.

Tagging for deployment. I believe this is the process to get Neil/dww/etc. to look at this. I agree that we can't hold a nice improvement like this forever.

Sadly, no. That tag is for once something is committed and pushed to Git and actually ready to deploy. See #1183682-7: "Projects" link on Getting Involved page should read "Community Initiatives" for a recent explaination.

The way to get me or Neil involved is to ping us. ;) or in this case, I'm already following so I just saw this in my tracker.

That said, I'm on my phone and about to eat, so I can't review this and figure out what has to happen next to take this live. :( but, I'll look again tomorrow morning when I'll have more time and a better environment to Get Things Done.


@alex.designworks: it will get a web interface similar to this one:
Only local images are allowed.
(UI text and branch order has been changed a bit, since I made the screenshot.)

The nescessary changes are there and deployed on Currently it's only blocked on being thoroughly tested. @sdboyer said he could deploy it himself, after that.

So, it seems there's a whole new project that manages the UI on project nodes:

However, there's also a patch to move this functionality directly into versioncontrol_project: #1443268: Move project_git_default_branch into this project. That certainly seems like a better approach than a whole separate project.

What's not clear from trying to read all the related issues is how that UI actually communicates to the Git repos on disk. I guess that's all handled behind the scenes by #1291308: Add setDefaultBranch() and getDefaultBranch() method to VersioncontrolGitRepository?

- How many of the VCAPI changes required for this feature to work have already been deployed?
- Looks like there we problems with the DB updates over at #1291308 -- did all that get resolved? Is it live?
- If any required changes aren't yet deployed, what else has changed in VCAPI that might break things if we deployed latest -dev now to get this live?

These are exactly the kinds of things that make me nervous to plow forward on this without sdboyer. I don't have the bandwidth to follow all VCAPI* development and all the other Git infrastructure that's happening behind the scenes (the beanstalkd stuff, queue processors, drush jobs, etc). I'm worried that if I just committed and pushed #1443268 for versioncontrol_project and deployed that live, that I might break something which I wouldn't know how to immediately fix. Sadly, sdboyer really is a single point of failure on this stuff (just like I'm a single point of failure on many other parts of d.o). That sucks and we need to fix it, but "just go for it, anyway" isn't a solution to those deeper problems.

So, I'm going to have to leave this assigned to sdboyer for now.

Sorry folks,

No changes have been deployed on d.o, yet. We're about a year or so behind, there.

All nescessary changes (except moving the new project_git_default_branch project into versioncontrol_project) have been committed. Unless the testing shows that more stuff needs to be fixed.

The update function problems are solved and the fix is committed.

And exactly: I remember sdboyer saying that he'd deploy this himself.

Status:Reviewed & tested by the community» Fixed

Looks like deployed and working! Yay! :)

Yes it is! YAY! What a win!

Great, thanks!

release from pain... champagne!

Just to clarify how to use it:
1. Go to your project page
2. Click 'Edit'
3. Click 'Default branch'
4. Select your default branch

Default branch will not be selected automatically on project creation! You must set it manually.

There is also this documentation page:

@alex.designworks does make a good point, though. setting the default branch on an empty repository really doesn't make sense (technically it's master, but with no commits, there are no real branches, so it's moot). however, we should add logic to syncInitial() that checks the default branch and sets it according. we can prefer master, but if the push came to a non-master branch, then we should set the default branch to whatever the pushed branch was in the db AND in the repo on disk.

Status:Fixed» Closed (fixed)
Issue tags:-git phase 3

Automatically closed -- issue fixed for 2 weeks with no activity.

Issue summary:View changes


Issue summary:View changes