Re: Rebase

>
> 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