2

I have forked a quick-start repo and built an app on top of it. The quick-start repo contained ~30 commits. The last commit of their repo is, say, abcde and first commit of mine is, say, fghij. How can I squash all of the commits, from first to abcde, so that there is only one, big commit before fghij.

Could you please explain it line by line. I don't understand other answers under similar topics.

Example history tree of commits now:

klmno - Currently newest commit
.
.
.
fghij - Initial commit of mine
abcde - Last commit made by them
.
.
vwxyz - Initial commit of theirs

Example history tree of commits expected:

klmno - Currently newest commit
.
.
.
fghij - Initial commit of mine
prstu - Fresh X installation
Robin Green
  • 32,079
  • 16
  • 104
  • 187
dczajkowski
  • 163
  • 2
  • 11
  • When you say "forked", do you intend to keep pulling from the upstream repository? What about pull requests back, do you intend to do that? – Lasse V. Karlsen May 25 '18 at 18:24
  • No. I wrongly worded what I've done. I have cloned a repo locally and then changed the origin to be my repo. I will not pull from upstream (or the cloned repo, rather) and I won't be making any PRs – dczajkowski May 25 '18 at 19:28
  • OK, then the answer provided by @RobinGreen should work just fine, let him know if you need more details about the process but interactive rebase is the way to go. – Lasse V. Karlsen May 26 '18 at 11:17
  • I will give it a try, but I am waiting for all PRs to be merged at my repo. Hopefully tomorrow I'll be able to test it. Thanks ;) – dczajkowski May 26 '18 at 18:17

1 Answers1

1

First enter git's interactive rebase mode - note that in this special case, you have to specify the special option --root to edit the root (first) commit, which is usually not allowed with the git rebase command:

git rebase -i --root

If you have not configured the EDITOR environment variable, you will be taken into git's default text editor, which I think is always vi. If you don't understand vi, type :q to exit and start the process again - this time, setting EDITOR to the name of a text editor you do know how to use.

In the interactive rebase file that git gives you to edit, change all the lines for the commits from the second commit to abcde to start with the word fixup instead of pick. Leave the lines for your commits, and the line for the very first commit, unchanged.

Save the file and exit the text editor. git will now perform the squashing of the original repository's commits into one commit.

Robin Green
  • 32,079
  • 16
  • 104
  • 187
  • Thank you for your answer. It is what I was lookin for, however I have encountered an error along the way: "error: could not apply a2e009e... update readme with links to more guides and examples When you have resolved this problem, run "git rebase --continue". If you prefer to skip this patch, run "git rebase --skip" instead. To check out the original branch and stop rebasing, run "git rebase --abort". Could not apply a2e009e5c1488c758e1a87410910c2daa03a88b5... update readme with links to more guides and examples" – dczajkowski May 29 '18 at 19:57
  • I did not realise there were PRs to your repo - so the history is non-linear? Can you share a link to your fork so I can have a look at it? – Robin Green May 29 '18 at 21:54
  • First commit is here: https://github.com/quickwords/quickwords/commits/master?after=3800eac6aa7d243e398c9712c611c2cb53368850+279 It's the "Added package-lock file" with 98e576449c7293a3eecf0c91d0940426c1400647 hash – dczajkowski May 30 '18 at 18:43
  • OK, makes sense. If you want to preserve the merges, do `git rebase --abort` and then try again by adding `--preserve-merges` to the command I gave in my answer. However, either way, you may encounter conflicts because git doesn't, by default, remember the solutions to merge conflicts when rebasing. So you'll most likely have to re-solve merge conflicts that you solved before. – Robin Green May 30 '18 at 20:41
  • It seems like it doesn't really work. Am I wrong, or should it be way easier for Git? I mean, it knows how files should look like in the end, so it shouldn't be that hard, right? Anyway, if you know how to fix that, it would be awesome. I have marked your answer as the best, with big thank you message attached. ;) – dczajkowski May 30 '18 at 23:45
  • I agree, it should be easier for git. I suggest you ask a new question, similar to this one, that makes it clear that your repository contains many merges, and that this solution didn't work very well. I will then attempt to answer that question. – Robin Green May 31 '18 at 21:27