Hi On Thursday, March 19, 2020 at 5:14:40 PM UTC, Alexander Mills wrote: > > I am praying for a good answer to this question on SO: > > https://stackoverflow.com/q/60761947/12211419 > > many upvotes promised. >
It is better to include the original question. Most readers won't follow the link... "I have used git rebase a few times and I am still confused about how it actually works. With git-merge it seems simple - resolve the diff between the tip of your branch and the tip of the other branch. However with git-rebase often times we are resolving multiple diffs when doing the rebase. I believe the number of resolved diffs is "how many commits my branch has that the other branch doesnt have" is that correct? but still why do need to resolve all the diffs, why not just the diff for the most recent commit on my branch? alternatively, doing git-rebase could mean resolving all the diffs for "all the commits from the other branch that my branch doesn't have"! i haven't figured out which is which. Can anyone explain how this works?" Answer: <https://stackoverflow.com/posts/60762420/timeline> A rebase is a request to move a series of *patches* from one place in your commit hierarchy to another place in your hierarchy. It is just like a series of 'cherry-pick's (yes, it really is ;-) So first you need to identify the correct list of commits, treated as patches, that you want to move. Beware of misunderstandings about some of the revision range options (some do not work. They don't even say what you thought). Beware of your "Upstream" - it may not be what you think, so Git may think the patch has already been applied to the "upstream". Having got your series of patches (range of commits), those patches need to be applied, one by one, to the new destination. You are doing this because it is a better place and usually already has some fixes already applied. The first patch (diff) is applied, there was some minor conflict, say the new ('upstream') place had renamed a variable, while you edited the formula. It will be a conflict (two changes to the same place, or adjacent lines). So you fix the first patch conflicts. Now the second patch hits the same awkward spot. Its a dumb diff. It knows not enough of the rename and line fixes and so can't find the right exact starting point, so you have to resolve it again. Cue third patch, and the same style of problem recurs. This is especially bad if your commits are not atomic (i.e. each really small!). and without the semantic (renames etc) changes. So, rebase quite often if you have a fast moving upstream (i.e. keep up), or do it very occasionally (i.e. do one big fix-it session). Also, use the "ReReRe" facility. This is the 'Reuse Recorded Resolution' capability of Git. You need to enable it. It will remember each of your 'fixes', and then if it needs doing again, it can reuse it. So you can practice the fixes, forget the bad ones, and re-run the rebase (use the --onto option for the temporary attempts). The rerere documentation isn't great but there are a few web articles. <https://stackoverflow.com/a/60762420/717355> <https://stackoverflow.com/users/717355/philip-oakley> Philip Oakley <https://stackoverflow.com/users/717355/philip-oakley> -- You received this message because you are subscribed to the Google Groups "Git for human beings" group. To unsubscribe from this group and stop receiving emails from it, send an email to git-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/git-users/18496d98-2d9b-4d26-98fe-a056beeae605%40googlegroups.com.
