Git将母版合并到无提交历史的孤儿中

Question

Given an orphan branch without history, how would I incorporate changes done on master branch, since the moment of creation of the orphan, without copying all commits history when pushing the orphan remotely.

A <- B <- C <- D  

        orphan(created from state B) <-X <- Y

I would like to bring c and d to the orphan branch and then x and y to master.

If I do checkout orphan, merge master or rebase master orphan gets the commits, but also all history tree. such as when I push orphan to a remote server, everybody will be able to see all master's history as well.

Also later I would like to merge orphan back into master, bringing commits x and y there.

Edit:

Now merging orphan into master works ok with git merge

A <- B <- C <- D <------X <- Y
                       /  
        orphan <-X <- Y 

But, merging master back into orphan either puts the entire master history into orphan (such as becomes X preceded by B ) or with cherry picking, but than I need to skip the merge-commits and also get a lot more conflicts

Answer 1

Grafts are built for exactly this.

root=$(git rev-list my-orphan-branch --max-parents=0)  # get the orphaned-branch root
echo $(git rev-parse $root B) >.git/info/grafts        # locally remember its real parent

and now all the local commands will know about the ancestry but it will remain repo-local, push and fetch won't export it.

Answer 2

Based on the comments and what you are intending, I'm going to suggest an alternate workflow/design to avoid the need to do super-ordinary Git things.

It sounds like there are some special config files or settings with passwords or similar sensitive information that you don't want to pass back to the remote, that are baked into your compiled files in the repo. Why not separate those out from the baked in code? If these files are already separate, then you can just .gitignore them. Regardless, it's better to have both a standard default that is compiled in or a default config file that gets distributed with the repo (and/or the application itself), and then have the code check for the presence of a custom config file, which is saved outside the repo or ignored with .gitignore .

Without knowing more about your setup (linux/PC/Mac, programming language, frameworks, etc.) it's difficult to give further guidance - for example, with Visual Studio development for C#, there is a Properties.Settings file that can be setup. The defaults become a part of the compiled code, but a class gets auto-generated that will save out any changes to a user-specific file and reload it when the application launches, but this is in the user home directory, and not in the development folders. Another method would be having the file locally, and using .gitignore to have Git not transfer it between repos.

I think this method will be better for you long-term, though might incur a short-term cost to update your design for better config management. My concern is that if you need some non-standard Git wizardry every time you need to push changes will cause times where someone forgets to take the extra steps and pushes the sensitive info up to the remote.

Answer 3

Try this:

git checkout orphan
git merge --no-commit --squash master
git commit