0

I want to insert a commit on my master branch that precedes my whole history. I have this software stack that I changed and commited the changed version as the initial commit. I realized my mistake way to late when I was trying to see what I changed initially and noticed that I did not commit the original stack first. So I'm trying to squeeze it in before anything else...

I found this very similar question and thought it to be straightforward to just add the original versions of certain files and commit.

But the rebasing starts to complain about every file with :

CONFLICT (add/add): Merge conflict in XXXX

When I merge the files to and try to rebase --continue it still keeps failing with:

Applying: first version
No changes - did you forget to use 'git add'?
If there is nothing left to stage, chances are that something else
already introduced the same changes; you might want to skip this patch.

When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To restore the original branch and stop rebasing run "git rebase --abort".

Whereas first version is the first commit on my master branch.

Is what I'm trying to do even possible?

Community
  • 1
  • 1
wmoors
  • 43
  • 4

3 Answers3

0

if you don't mind to erase all the changes you have made, you could return to the first commit version of your project with

git revert $id

$id is the id of the commit that you can find with the git log command

and then you could modify with the version that you want

nevertheless, be careful with it and think twice before doing it

Tynamo
  • 149
  • 10
0

What the problem is is that the first commit it's trying to apply is a bunch of file adds rather than file changes as it would normally store a commit as so your initial commit adds a bunch of files and so does the commit you're trying to rebase on.

I'm not 100% sure this is the best way of doing it but it should work

make the orphan branch make a commit such that your codebase becomes becomes identical to your initial commit rebase your 2nd commit onto that new commit.

because your second commit actually contains changes it shouldn't conflict.

if that wont do what I think you want then I dont think I'm understanding your question properly.

command wise it should be:

# first you need a new empty branch; let's call it `newroot`
git checkout --orphan newroot
git rm -rf .
#add all files you want
git commit -am 'initial commit'
git checkout 1st_commit
git merge -s ours newroot
git rebase --onto newroot --root 2nd commit
git branch -d newroot
Stephan
  • 426
  • 5
  • 13
  • That sounds like it could work. I'll try it on a foo repo. What do you suggest then to do with the first (obsolete) commit on the master branch? – wmoors May 15 '13 at 15:24
  • Nothing, it'll be in the repo but wont be associated with anything. – Stephan May 15 '13 at 15:29
0

You can expect load and loads of conflicts between the 'original stack' and the 'changed version'. That is, when you make 'original stack' the first commit (on some branch) and then go to merge in the 'changed version' of stack, then everything will conflict. But, what you know is that the 'changed version' is the correct version so you do not have to resolve each conflict one by one. Instead you'll use:

git checkout --ours -- <files that conflict>       # see note below
git add -- <files that conflict>
git commit -m 'Resolved with --ours'

Note: sometimes --ours is correct; sometimes --theirs is correct and it can depend on whether your are merging or rebasing. Choose one, use it, check if you got the right file, use the other one if you didn't.

GoZoner
  • 67,920
  • 20
  • 95
  • 145