Why can't git open empty branches ?

Hi,

when creating a new branch in git, it is by default filled with the contents of the current branch.

Sometimes a new but empty branch is needed. There are plenty of instructions in the web to achieve this with „dirty tricks”, i.e. fiddle around with git's internals. Which is poor design.

Why doesn't git's branch command support opening empty branches in a clean an natural way?

regards Hadmut

Hadmut Danisch wrote:

	git init ../unrelated-topic
	cd ../unrelated-topic
	hack away...
	git commit
	cd -
	git fetch ../unrelated-topic master:<new branch>

Or:

	git checkout --orphan <new branch>
	git rm -fr .
	hack away...

Please feel free to contact the authors of the instructions you found on the web to fix them.

Thanks and hope that helps, Jonathan

Am 11.04.2012 12:59, schrieb Jonathan Nieder:

I would have expected something more obvious and intuitive like

  git branch --empty

It is not really plausible to create a new branch by checking out a non-existing one.

However, this helps. Thanks.

Hadmut Danisch <hadmut@danisch.de> writes:

... but it is hardly useful to create a new branch unless you want to check it out.

I think the most common way to create a branch with Git is "git checkout -b new-branch", which does the creation+checkout in a single command. "git checkout --orphan" is the natural extension of it.

BTW, it is rarely good practice to create an empty branch in an existing repository. You'll have different branches that do not share any history, and they would likely be better in separate repositories (or at least, be in separate local repositories, pushed to the same remote bare repository, in which case you don't need anything special, just "git init" and "git push"). That doesn't mean you shouldn't do it, but just that you may want to think twice before doing it ;-).

Am 11.04.2012 13:21, schrieb Matthieu Moy:

That's a pretty good point for discussion.

Sometimes people are working on different sorts of information, that are nevertheless closely related, e.g. open source software and the web pages describing it (like in git hub), or a web server tree and the software generating it. They are related, but do not logically share a history.

Creating independent branches by pushing two separates into a single remote bare is a nice idea, but if I understood git correctly, the very first commit in a repos is always to the master branch, where you have two masters trying to push into the shared remote bare. This is obviously solvable if you use the correct commands and maybe delete and re-clone the repos, but this is all overcomplicated and non-trivial. Nothing I could do without reading manuals.

So your proposal might work perfectly, but in my eyes it is error prone and not user friendly.

regards

Hadmut Danisch wrote:

I suppose you had to read the manual to learn the "git commit" and "git branch -m" commands, yes. But what's wrong with that, or how could we fix it?

	git init code
	cd code
	... hack away ...
	git remote add origin <url>
	git push -u origin master
	cd ..

	git init website
	cd website
	... hack away ...
	git branch -m website
	git remote add origin <url>
	git push -u origin website
	cd ..

I wonder if there is a potential documentation or error message update lurking behind these questions.

Hope that helps, Jonathan

Hadmut Danisch <hadmut@danisch.de> writes:

In these cases, you'll want to have two working directories, if only to avoid:

git checkout documentation # fix a typo git commit git checkout code make # complete rebuild triggered.

Not necessarily. I don't see an option in "git init" to change the default branch name, but you can

git init foo cd foo git checkout -b whatever-branch-name

and work.

Otherwise, you can have a branch that is locally called "master", and push it as another name (but that is probably the "error prone" in your message ;-) ).

Hi Hadmut ;-)

On 11.04.2012 13:47, Hadmut Danisch wrote:

AFAIK the only thing that makes master the initial branch is the file .git/HEAD that points to master after you "git init". This is not hardcoded.

 > So your proposal might work perfectly, but in my eyes it is error
 > prone and not user friendly.

Serious errors should not happen since the bare repo on the server is created with the flag denyNonFastForwards. So even if you had a master branch in both repos, only one of them, the first one, would succeed in pushing to the server, a push of the second one would give you an error message. Maybe not user friendly, but safe.