Skip to main content
Fixed typo
Source Link
Ikke
  • 101.6k
  • 23
  • 101
  • 121

While helping a friend with a git problem today, I had to introduce a branch that needed to be totally separate from the master branch. The contents of this branch really had a different origin from what had been developed on the master branch, but they were going to be merged into the master branch at a later time.

I remembered from reading John Wiegley's Git from the bottom up how branches are essentially a label to a commit that follows a certain convention and how a commit is tied to a tree of files and, optionally to parent commits. We went to create a parentless commit to the existing repository using git's plumbing:

So we got rid of all files in the index ...

$ git rm -rf . 

... extracted directories and files from a tarball, added those to the index ...

$ git add . 

... and created a tree object ...

$ git write-tree 

(git-write-tree told us the sha1sum of the created tree objactobject.)

Then, We committed the tree, without specifying parent commits...

$ echo "Imported project foo" | git commit-tree $TREE 

(git-commit-tree told us the sha1sum of the created commit object.)

... and created a new branch that points to our newly created commit.

$ git update-ref refs/heads/other-branch $COMMIT 

Finally, we returned to the master branch to continue work there.

$ git checkout -f master 

This seems to have worked as planned. But this is clearly not the kind of procedure I would recommend to someone who is just getting started using git, to put it mildly. Is there an easier way of creating a new branch that is entirely unrelated to everything that has happened in the repository so far?

While helping a friend with a git problem today, I had to introduce a branch that needed to be totally separate from the master branch. The contents of this branch really had a different origin from what had been developed on the master branch, but they were going to be merged into the master branch at a later time.

I remembered from reading John Wiegley's Git from the bottom up how branches are essentially a label to a commit that follows a certain convention and how a commit is tied to a tree of files and, optionally to parent commits. We went to create a parentless commit to the existing repository using git's plumbing:

So we got rid of all files in the index ...

$ git rm -rf . 

... extracted directories and files from a tarball, added those to the index ...

$ git add . 

... and created a tree object ...

$ git write-tree 

(git-write-tree told us the sha1sum of the created tree objact.)

Then, We committed the tree, without specifying parent commits...

$ echo "Imported project foo" | git commit-tree $TREE 

(git-commit-tree told us the sha1sum of the created commit object.)

... and created a new branch that points to our newly created commit.

$ git update-ref refs/heads/other-branch $COMMIT 

Finally, we returned to the master branch to continue work there.

$ git checkout -f master 

This seems to have worked as planned. But this is clearly not the kind of procedure I would recommend to someone who is just getting started using git, to put it mildly. Is there an easier way of creating a new branch that is entirely unrelated to everything that has happened in the repository so far?

While helping a friend with a git problem today, I had to introduce a branch that needed to be totally separate from the master branch. The contents of this branch really had a different origin from what had been developed on the master branch, but they were going to be merged into the master branch at a later time.

I remembered from reading John Wiegley's Git from the bottom up how branches are essentially a label to a commit that follows a certain convention and how a commit is tied to a tree of files and, optionally to parent commits. We went to create a parentless commit to the existing repository using git's plumbing:

So we got rid of all files in the index ...

$ git rm -rf . 

... extracted directories and files from a tarball, added those to the index ...

$ git add . 

... and created a tree object ...

$ git write-tree 

(git-write-tree told us the sha1sum of the created tree object.)

Then, We committed the tree, without specifying parent commits...

$ echo "Imported project foo" | git commit-tree $TREE 

(git-commit-tree told us the sha1sum of the created commit object.)

... and created a new branch that points to our newly created commit.

$ git update-ref refs/heads/other-branch $COMMIT 

Finally, we returned to the master branch to continue work there.

$ git checkout -f master 

This seems to have worked as planned. But this is clearly not the kind of procedure I would recommend to someone who is just getting started using git, to put it mildly. Is there an easier way of creating a new branch that is entirely unrelated to everything that has happened in the repository so far?

Source Link
hillu
  • 9.7k
  • 4
  • 28
  • 31

In git, is there a simple way of introducing an unrelated branch to a repository?

While helping a friend with a git problem today, I had to introduce a branch that needed to be totally separate from the master branch. The contents of this branch really had a different origin from what had been developed on the master branch, but they were going to be merged into the master branch at a later time.

I remembered from reading John Wiegley's Git from the bottom up how branches are essentially a label to a commit that follows a certain convention and how a commit is tied to a tree of files and, optionally to parent commits. We went to create a parentless commit to the existing repository using git's plumbing:

So we got rid of all files in the index ...

$ git rm -rf . 

... extracted directories and files from a tarball, added those to the index ...

$ git add . 

... and created a tree object ...

$ git write-tree 

(git-write-tree told us the sha1sum of the created tree objact.)

Then, We committed the tree, without specifying parent commits...

$ echo "Imported project foo" | git commit-tree $TREE 

(git-commit-tree told us the sha1sum of the created commit object.)

... and created a new branch that points to our newly created commit.

$ git update-ref refs/heads/other-branch $COMMIT 

Finally, we returned to the master branch to continue work there.

$ git checkout -f master 

This seems to have worked as planned. But this is clearly not the kind of procedure I would recommend to someone who is just getting started using git, to put it mildly. Is there an easier way of creating a new branch that is entirely unrelated to everything that has happened in the repository so far?