CODEWITHSUNDEEP
gitmergerebase
Chad Stewart
Chad Stewart

Reputation: 484

What to do when new commits happen after a git rebase?

I just got done with a particularly hairy rebase (someone worked for weeks on a branch without ever rebasing.) It took me about two or three hours because the "human readable" format that I was using is just a bunch of IDs and references.

While I was doing this rebase, two more commits showed up on the branch before I had the chance to git push the result of the rebase.

Is there a best practice for getting those new commits without re-doing the rebase or resorting to a merge? My initial thought was that I could git cherry-pick those new commits and git push -f, but would that be unsavory?

Upvotes: 1

Views: 415

Answers (2)

VonC
VonC

Reputation: 1324507

You should be able to rebase your commits again.

The only issue is that you will have to remake your conflict resolutions, because you did not activate git rerere.

Well,... you don't have to, with the rerere-train.sh script.
See "Do you even rerere?" by Tristan Roussel:

In this simplest form, the script starts from the commit you specified and go through every parent commit to look for conflicts.

That will allow you to record those past conflict resolutions, and rebase again without having to do them again.

With Git 2.36 (Q2 2022), the rerere-train script (in contrib/) is improved.

See commit 2587df6 (27 Feb 2022) by Junio C Hamano (gitster).
(Merged by Junio C Hamano -- gitster -- in commit 50e0dd8, 06 Mar 2022)

rerere-train: two fixes to the use of "git show -s"

The script uses "git show -s"(man) to display the title of the merge commit being studied, without explicitly disabling the pager, which is not a safe thing to do in a script.

For example, when the pager is set to "less" with "-SF" options (-S tells the pager not to fold lines but allow horizontal scrolling to show the overly long lines, -F tells the pager not to wait if the output in its entirety is shown on a single page), and the title of the merge commit is longer than the width of the terminal, the pager will wait until the end-user tells it to quit after showing the single line.

Explicitly disable the pager with this "git show"(man) invocation to fix this.

The command uses the "--pretty=format:..." format, which adds LF in between each pair of commits it outputs, which means that the label for the merge being learned from will be followed by the next message on the same line.
"--pretty=tformat:..." is what we should instead, which adds LF after each commit, or a more modern way to spell it, i.e.
"--format=...".
This existing breakage becomes easier to see, now we no longer use the pager.

Upvotes: 2

Muhammed Imran Hussain
Muhammed Imran Hussain

Reputation: 2125

cherry-pick for just merging specific commits but if your branch contains many commits that needs to be merged then better to rebase it.

Different people may have different best practices. I follow followings:

  1. git pull --rebase so that I can ensure my branch is up to date from the remote branch it was created.
  2. git push origin :feature_branch this will delete remove remote feature branch. Though I know I can simply do git push -force feature_branch but I want to be confirm that git will not mess up anything :) :) :)
  3. finally git push origin feature_branch

I will be glad to know your practice or suggest me something better.

Upvotes: -1

Related Questions