3

I want to create an orphan branch that copies all the commits across.

Basically I need to end up with master and dev, both orphans but both identical (until I make further commits).

I have created the orphan master (empty) and have the dev with all my commits. How do I copy all these commits to master?

nneonneo
  • 171,345
  • 36
  • 312
  • 383
user28209
  • 59
  • 1
  • 4
  • 1
    Why do you want an orphan branch with all your commits? If I understand you correctly, you want a second branch with all-new commits (i.e. not the same SHAs). This will be nontrivial to create if your `dev` history is not a straight line, because merge commits &c will be very tricky to recreate. Maybe it would help if you described what you need this for. – nneonneo Aug 03 '13 at 10:39
  • Because DEV will be the rolling dev, and master will be the most current stable code, while ill then have other orphan branches for the versions. If you look at jQuery here in github they have it setup as I describe. Master = https://github.com/jquery/jquery/commits/master?page=5 , "dev" = https://github.com/jquery/jquery/commits/1.9-stable . Both have the same commits for March 26 2013 etc – user28209 Aug 03 '13 at 11:11
  • 2
    Don't use orphan branches. Just use regular branches. Orphan branches will preclude clean merging, which defeats the point of having branches in the first place. Also, use tags for versions, not branches. – nneonneo Aug 03 '13 at 11:13
  • Okay. How do I do tags for versions? And why is what you suggest better than jQuery's and others setup? Also thinking out what you say, means I can't have a generic dev branch, it would have to be named for the proposed version and then how do you know its dev and not stable? – user28209 Aug 03 '13 at 11:14
  • 1
    jQuery is NOT using orphan branches. They are using regular branches. The SHA1 of the branches diverged due to different merge patterns, but they share a common development history. – nneonneo Aug 03 '13 at 11:18
  • They are also using branches for major versions that are being maintained in parallel. These are "version branches" -- think branches for 1.8.x, 1.9.x, 2.0.x, etc. Multiple releases may be made off a single version branch. But, specific versions (e.g. 1.9.1) are tagged because no further development occurs for a released version. – nneonneo Aug 03 '13 at 11:19
  • Also, I never said you couldn't have a generic dev branch. You can have a dev branch, easy: `git checkout -b dev master`, and then you can make changes specifically on the dev branch, merging them back to master when appropriate. – nneonneo Aug 03 '13 at 11:21
  • @nneonneo - I may not be explaining it right as I am new to git. Would that command make dev an orphan branch? – user28209 Aug 03 '13 at 11:23
  • 1
    No...that makes a *regular* branch. `git checkout --orphan dev` would make an orphan branch. But, in your situation (new to git), I'd stay the hell away from orphan branches. That's mainly aimed at power users who need totally disconnected development histories for special uses. – nneonneo Aug 03 '13 at 11:25
  • I see your point but feel it will become too messy. Much cleaner to have a orphan dev and orphan master. And have the commits copied over including the log of them. I already have made the orphan master (dev currently has all the code and commits). – user28209 Aug 03 '13 at 11:29
  • So you want to just manually copy commits back and forth? I think this would very much negate 99% of the utility of `git` (pretty much every tool that works across branches expects to see regular branches, not orphan branches). But hey, it's your repo, not mine. If you want to make it a bunch of orphan branches, then it's your decision. – nneonneo Aug 03 '13 at 11:34
  • @nneonneo I just dont see how you would keep the repo clean. Is there a repo you can link me to that shows nicely exactly the type of implementation you think I should go for? – user28209 Aug 03 '13 at 11:36
  • Here's what jQuery is actually doing, because I think you misunderstand their development process. This page shows a bunch of merge commits: https://github.com/jquery/jquery/commits/master?page=10. This is from them merging in several feature branches which were independently developed, to make a mainline 2.0 branch. – nneonneo Aug 03 '13 at 11:37
  • By the way, the normal workflow for most projects is that `master` (and most of the feature branches) are unstable, by virtue of being actively developed upon. Version branches are expected to be more stable, and the most stable code is obtained from tagged releases. The master is thus usually considered the generic "dev" branch. – nneonneo Aug 03 '13 at 11:40
  • @nneonneo Ok so if we say master is where the work is going on. Then the orphan branch is the version with all the commits? or you saying branch it out into a sub-branch? – user28209 Aug 03 '13 at 11:41
  • Seriously, stop talking about orphan branches. What the heck do you mean by "all the commits"? – nneonneo Aug 03 '13 at 11:45
  • Ok. They are dead. So you are saying this .... User master to develop on. Then "git branch v1" to make a version branch and then keep coding in the master until v2 is needed? – user28209 Aug 03 '13 at 11:46
  • http://git-scm.com/book/en/Git-Branching-Basic-Branching-and-Merging – nneonneo Aug 03 '13 at 11:48
  • But basically, if you're making **versions** of your software, you use tags (tag a released version). A **version branch** is a parallel track of development to support specific version lines, and you only see those on big projects with many versions concurrently supported. – nneonneo Aug 03 '13 at 11:49
  • @nneonneo - all understood. Now how do I back date a tag so all my current commits are tagged to it? – user28209 Aug 03 '13 at 11:56
  • $ git tag -a v1.2 -m 'version 1.2' 9fceb02 ?? – user28209 Aug 03 '13 at 12:00
  • @nneonneo above code tag didnt seem to work – user28209 Aug 03 '13 at 12:10
  • Just `git tag v1.2 [commit-id]` will suffice. – nneonneo Aug 03 '13 at 12:32
  • @nneonneo - notice that tags auto create release I can then modify in github :/ Thats not so good. – user28209 Aug 03 '13 at 12:43
  • @nneonneo also when i merge my dev branch into master the commit log will get added to master? – user28209 Aug 03 '13 at 12:47
  • Yes, merging will bring all the commits from the dev branch into master (`git log` will show both). Better yet, `git log --graph` will show a history of merges, so you can have a good idea of what your development schedule is like. – nneonneo Aug 03 '13 at 13:10

1 Answers1

0

(Not judgin if orphan branch is the right solution here, just trying to answer the initial question which was about duplicating history.
As nneonneo comments regular branches are probably fine)

The problem is that if the SHA1 are the same between the two branches, the second branch will always be a simple pointer to a commit of the first branch.

What could work is:

That would looks like:

cd /original/repo
git fetch /path/to/clone master:dev

And that would create an orphan branch dev, with all the (same) commits than master (on top of an empty one)

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250