-1

Right now I have a very large repository with the following commits:

  1. Latest commit
  2. A lot of commits here
  3. First commit

What I want to do is to squash commits 2 and 3 into a single one. I tried interactive rebase, but there are many conflicts and it would take unreasonable amount of time to fix those. And it doesn't make any sense to resolve those conflicts since eventually they will become one commit.

The result would look like this:

  1. Latest commit
  2. Initial commit (includes 2 and 3)
Dan
  • 1,274
  • 2
  • 15
  • 32
  • Why do you see conflicts during rebase? I might be missing something, but I haven't seen any conflicts when I tried to squash up to 100 commits – Konstantin Oct 10 '17 at 14:08
  • Why do you want to do this? Most of the power of Git and other version control systems comes from keeping the old versions around. I can’t count how many times I’ve gone back to look at why changes are made, and just today I need to resurrect something that got deleted a year ago. – Daniel H Oct 10 '17 at 14:08
  • If the history is linear, there can't be any conflicts. Is it a merge of some sort ? – sylvain.joyeux Oct 10 '17 at 14:08
  • @sylvain.joyeux I guess you are right. OP might have merges with conflicts in their history. – Konstantin Oct 10 '17 at 14:10
  • 1
    @DanielH there are a lot of reasons why someone would like to do that. A bunch of "add missing comma" or "forgot the return" commits are just making it harder to use the history to understand the code's intent. There are a lot of "styles" of usage for Git, and one common usage is "commit small and often, rewrite history before you push". But, then, if one does this, one shouldn't use merges in the middle. – sylvain.joyeux Oct 10 '17 at 14:35
  • @sylvain.joyeux Yes, I agree that common git styles require a clean history. I don’t like all the definitions of “clean” or the lengths some people go to to achieve them, but they’re common styles. This looks like wanting to take *all* the commits from the beginning of time and squash them together, which is different. That’s why I’m asking what the motivation is; it might be an X/Y problem and the correct answer is “do a shallow clone but keep the full history on the server” or something. – Daniel H Oct 10 '17 at 14:39
  • @DanielH I'm using the repository for a different project. Originally, there was a lot of shared code, but now most of the code is completely different, so I don't need old commits. I want to have a fresh start for the repository, but there are already commits on top of the old repo that I want to keep. – Dan Oct 10 '17 at 14:56

2 Answers2

0

I solved the problem using grafts.

To squash using grafts

Add a file .git/info/grafts, put there the commit hash you want to become your root

git log will now start from that commit

To make it 'real' run git filter-branch

original answer

Dan
  • 1,274
  • 2
  • 15
  • 32
-1

How were you doing an interactive rebase?

If you're dealing with squashing a single branch you shouldn't have conflicts like that.

git rebase -i HEAD~3

Then in vim/editor

pick commit 3
pick commit 2
pick commit 1

Change that to 

pick commit 3
squash commit 2
pick commit 1

With 3 being the oldest and 1 being the most recent

WakeskaterX
  • 1,408
  • 9
  • 21