Thank you for the explanation. I think in this case, what happened was I created the branch without doing a git push - and so local and remote were not in sync. when I created the feature branch. Then when I went to put the feature branch on to main it complained about the merge because two lines on main were different. Does that make any sense? Regards, Al On Mon, Jan 20, 2025 at 2:32 PM brian m. carlson <sandals@xxxxxxxxxxxxxxxxxxxx> wrote: > > On 2025-01-19 at 20:39:13, Al Grant wrote: > > Yes. But I'm keen to understand how to deal with a merge conflict. > > > > My IDE is VSCode and when I run the merge I get this image: > > > > https://imgur.com/a/vynTxaj > > > > Which highlights this code: > > > > 255: <<<<<<< HEAD > > 256: samples = signal.convolve(samples, [1]*189, 'same')/189 > > 257: > > 258: #for testing - log to file > > 259: #self.f.write(samples.astype(np.float32).tobytes()) > > 260: > > 261:======= > > 262: samples = signal.convolve(samples, [1] * 10, "same") / 189 > > 263: > > 264: # for testing - log to file > > 265: # self.f.write(samples.astype(np.float32).tobytes()) > > 266: > > 267:>>>>>>> 1f893dc (Make project runnable on Linux) > > > > Now I would assume that samples = .... from ln 256 abd 262 are the > > differences between MAIN and FEATURE? > > > > But when I search main (at least I think its main - my IDE doesnt tell > > me mid rebase process) for ` samples = signal.convolve(samples, > > [1]*189, 'same')/189` AND `samples = signal.convolve(samples, [1] * > > 10, "same") / 189` - those lines do not exists anywhere in MAIN??? > > > > So what is going on???? > > First, I recommend that you set the `merge.conflictStyle` setting to > `diff3` so that you get the contents of the merge base as well. That > can be illustrative when you have conflicts. > > It's important to note that a rebase involves replaying individual > commits from one branch on top of another, usually using a merge > algorithm. That means that it isn't necessarily the case during a > rebase that one side is the complete base branch, but rather one side is > the base branch _with all of the previous commits you've rebased on top > of it_. > > So if you have this: > > A - B - C - D - E - F (main) > \ > - G - H - I - J (feature) > > and you rebase `feature` on to `main`, you're going to replay G, H, I, > and J (in that order) on top of F. So it might not be that the code > exists in `main`, but that it comes from one of those intermediate > commits. > > In this case, the conflict should be trivial to fix up in that the code > appears (at least to a first glance) to be logically equivalent. I > would personally resolve this conflict in favour of the version with a > little more whitespace, since that seems nicer to read. > -- > brian m. carlson (they/them or he/him) > Toronto, Ontario, CA -- "Beat it punk!" - Clint Eastwood
