-1

I have a "long lived feature" branch that i have been working for last 2 months. It has 211 commits that i want to squash into single commit before this "long lived feature branch" can be merged with "origin master". When i run "git rebase -i HEAD~210" it kicks off a conflict resolution process of more than 500 conflicts.

What's the best way to squash commits and complete rebase ?

When i do:

git rerere
git rebase -i HEAD~210
# change all "pick" with "squash" and save and exit followed by single
# commit message

It will then present me with 500 or so conflicts to be resolved which is my problem. i.e. is there any way i can get away with it?

There are only 4 files that keep repeating and git rerere hasnt been of much help.

My other confusion is why i get more than 500 conflicts to be resolved when the commits are 211?

I have been reading on merge vs rebase and the difference seems to be only retaining history or not but in effect processes are quite different. merge works fine but rebase creates a lot of trouble. I have been thinking of creating another feature branch and run git merge --squash to get rid of commits but my colleagues have already committed on a PR based on my "long lived feature branch" and i would prefer a way to sort out this issue without creating another branch

LeGEC
  • 46,477
  • 5
  • 57
  • 104
ASy_Dev
  • 1
  • 1
  • Try to first "squash" all the commits in your feature branch into a single one - then try to merge it into upstream. That might make it easier. – Martin Baulig May 07 '23 at 17:22
  • The term "conflict" refers to an invididual chunk in some file - a single commit can have multiple files with conflicts in them. – Martin Baulig May 07 '23 at 17:22
  • This is really your same question https://stackoverflow.com/questions/76194673/git-rebase-infinite-loop-with-several-hundred-commits-and-never-up-to-date only very slightly mutated. – matt May 07 '23 at 17:27
  • Hi, welcome to SO. One point that makes your question hard to answer is that, as it is currently worded, there are several questions in it. It looks like the initial thing you tried to achieve was to turn a long lived branch into a branch with a single commit, is that correct ? – LeGEC May 07 '23 at 17:43
  • @LeGEC. Sorry if question wasn't clear. But answer is No. I dont want to turn a long live branch into a branch with single commit. I want to squash commits in my long live branch so i can merge it to origin master with only 1 commit. – ASy_Dev May 07 '23 at 18:13
  • @MartinBaulig I want to squash commits in feature branch into a single one but when i run "git rebase -i HEAD~210" it asks me to go through more than 500 conflicts and that's the problem – ASy_Dev May 07 '23 at 18:15
  • @MartinBaulig you are right my other question was similar but last comment from matt was suggestive of creating a new ticket – ASy_Dev May 07 '23 at 18:18
  • and does that long lived branch include merge commits ? possibly commits where, from that feature branch, you ran `git merge master` to bring in changes from master at several points during the history of that branch ? – LeGEC May 07 '23 at 18:41

2 Answers2

1

Here is a recipe to create a branch which groups all the changes brought by your feature branch squashed in one single commit:

# from your feature branch:
git switch my-long-lived-branch

# create a working branch:
git switch -c my-squashed-branch

# bring all changes together, on top of the last sync point with master:
git reset --soft $(git merge-base HEAD master)
# and commit:
git commit   # all changes in one commit

You now have my-squashed-branch, which introduces the exact same changes as your initial branch, with only one commit. That commit is based on the last point in master where you synced master with your branch.

You may open a pull request directly from that squashed branch, or run git fetch; git rebase origin/master to rebase it on the latest version of master before opening that pull request.

Should there be conflicts in that last rebase, at least they will be contained to one single commit.

note: if the branch modifies 500 files, and that out of bad luck these same 500 files have also been modified on master, you may have 500 conflicts even though there is one single commit.

The number of conflicts is bound by the number of individual file changes (if you have 200 commits, you would have to sum the number of file changes in each commit), not by the number of commits alone.

LeGEC
  • 46,477
  • 5
  • 57
  • 104
  • Thanks. "git reset --soft $(git merge-base HEAD master)" and "git merge --squash" same thing? – ASy_Dev May 07 '23 at 19:38
  • no, they're not the same. Run the recipe above (note that you can always return to your existing branch, it hasn't been changed), then run `git log --graph --oneline origin/master my-squashed-branch`. You should have a better understanding of what it does. – LeGEC May 07 '23 at 21:10
1

If in the end you want to have a single commit to then merge into the main branch, then you can just as well merge with main branch and then do a soft reset.... "tomato/tomato", "potato/potato".

git checkout my-long-branch
git merge main-branch
# get that merge finished if there are conflicts....
# when the merge commit is finished:
git reset--soft main-branch
git commit -m "a single commit for my long branch"
# now if you try to merge that ibto main branch, it should be fine
eftshift0
  • 26,375
  • 3
  • 36
  • 60