0

A local project is ready to be pushed to a GitHub repository. The GitHub repository was initialized WITHOUT README and license.

From commit C1 to Cn - C1 is the first/initial commit, and Cn is the n-th/latest commit -, the local project contains sensitive. But from the commit Cn+1 onwards the sensitive data is masked.

For example, C1..Cn+3 is my currently local git repository:

C1 < C2 < C3 < .. < Cn < Cn+1 < Cn+2 < Cn+3

I want to push the commit Cn+1 and onwards. So, the remote repository should have C1'..C3'

C1 < C2 < C3 < .. < Cn < Cn+1 < Cn+2 < Cn+3
                         C1' < C2' < C3'

Where C1' in the remote repository is Cn+1 in my local repository.

How to add the local project to GitHub starting at the commit Cn+1? The following push should ignore the commits C1..Cn.

I've already tried git push origin <sha>:<branch> but it push the whole project. Rebase didn't quite fit for me either.

  • 1
    Is there a reason you want to preserve the sensitive data in the history locally? It's possible to edit those commits. – Isaac van Bakel Jun 26 '17 at 15:56
  • @IsaacvanBakel Not really, but I would like to have the "original" history preserved. Some commits have tag and are signed. I could create another local repo and copy the latest commit from the old to the new, but I think working in the same repo is nice in case I need to consult or dff something. –  Jun 26 '17 at 16:22
  • In my view, your signed and tagged commits won't mean much if you can't share them with anyone. If the history is for your personal use, signing and tagging won't really matter - and if the history is for sharing, you won't be able to do that with sensitive info. Do you want to keep the original progression or the actual commits themselves? – Isaac van Bakel Jun 26 '17 at 16:40
  • Signed and tagged commits are just an extra way to check the integrity of the files because I like it. I want to share the latests commit and following ones. What is the difference of original progression and actual commits? –  Jun 26 '17 at 16:43
  • What I mean is: Do you want to have "I changed file A, then file B, then file C", with all the sensitive content scrubbed out, or do you want the actual commits made? Generally, what you're asking for sounds impossible, since git uses a system which relies on knowing all history. I'm just trying to understand what the reason for not fixing the history is. – Isaac van Bakel Jun 26 '17 at 16:56
  • I don't want to have **"I changed file A, then file B, then file C", with all the sensitive content scrubbed out** because of the sensitive data, and that is why I want to push the latest commit which does not contain the sensitive data. Let me edit the question with an example of what I want. –  Jun 26 '17 at 17:13

1 Answers1

0

There are a few ways to do what you want, but the most important point is this: you won't be able to use the Github repo seamlessly. So if your intention is to use it as a way to share new commits or fetch contributions from other people and then put them back on your original history, that's not going to be possible in the traditional way.

Making a new repository

The simplest way is to just copy your working tree with all your files in it, in the repository state you want, init that as a new git repo, make a single initial commit, and then push everything to Github.

You'll be able to use the new repo as normal, and nothing of the original history will be shared or preserved.

Making a public branch

Another option is to make a new branch on the current repo as an orphan i.e. a branch with a no root, and do the same thing as making a new repo above - copy files, make a new starting commit, and push this branch to Github.

You'll then be able to share and fetch changes made on the public repository, but getting them back onto your main branch will be more difficult - you can use one-way merges into the private branch, and make all edits on the public branch only, which will keep your history without sharing it.

You'll need to be very careful with merge direction if you want to take this approach, though. If you push a merge in the wrong direction, the history will become public.

For more info, see this question: Push a branch of a git repo to a new remote (github), hiding its history

Addendum: why isn't this possible?

Ben Jackson explains it in the answers to the above question: a commit's hash is partly based on every commit preceding it in the repo. Since what you want to do would publicly create a new commit (without a parent), git will refuse to treat it as though it was really your old commit, because the hashes won't match.

Isaac van Bakel
  • 1,772
  • 10
  • 22
  • Well, an orphan branch is the go. I didn't know the hash includes the parent and the tree, so I see your point about 'git depends on history' now. –  Jun 26 '17 at 17:45