Changing the eko argument in evolve_grid

[andreab1997]

We want to pass the eko object rather than the path to evolve_grid

[andreab1997]

@felixhekhorn I am not sure but maybe it is better to merge this to #24 rather than to main. Am I wrong?

[codecov]

Codecov Report

Merging #28 (5a2f9ce) into main (aa1a068) will increase coverage by 0.11%.
The diff coverage is 50.00%.

@@            Coverage Diff             @@
##             main      #28      +/-   ##
==========================================
+ Coverage   40.75%   40.86%   +0.11%     
==========================================
  Files          15       15              
  Lines         530      531       +1     
==========================================
+ Hits          216      217       +1     
  Misses        314      314              

Flag	Coverage Δ
unittests	40.86% <50.00%> (+0.11%)	⬆️

Flags with carried forward coverage won't be shown. Click here to find out more.

Impacted Files	Coverage Δ
src/pineko/evolve.py	30.61% <ø> (+0.61%)	⬆️
src/pineko/theory.py	19.87% <ø> (ø)
src/pineko/cli/convolute.py	75.00% <50.00%> (-2.28%)	⬇️

[felixhekhorn]

Can this then be merged? or we wait for #24 to be merged first?

[alecandido]

Before rebase, please

[andreab1997]

Before rebase, please

on which branch?

[andreab1997]

Before rebase, please

on which branch?

to main I guess

[felixhekhorn]

Before rebase, please

as you know, I don't like this "rewriting history" business 🙃 so I started to reread the reason why people are doing this and the ("simple") rule seems to be "You can get the best of both worlds: rebase local changes before pushing to clean up your work, but never rebase anything that you’ve pushed somewhere." aka "only rebase branches you, and only you, are working on."

so I'd say there should not be a rebase visible on github - hence you can just merge sv_check here (and before merge master on sv_check)

[alecandido]

to main I guess

On the one your conflicting with, i.e. the one on which the PR is based:

I'd say sv_check then.

[andreab1997]

Can this then be merged? or we wait for #24 to be merged first?

I believe we can merge now, I solved the conflicts

[alecandido]

so I'd say there should not be a rebase visible on github - hence you can just merge sv_check here (and before merge master on sv_check)

I'm not saying you should do what I wish, if you do not agree with me, do whatever you wish. But I'll keep doing as well :)

The points are the following:

1. linear histories are simpler: when you want to explore when changes entered, there is a before and an after; at the time you merge your main was arrived at some point, so the commit you're inserting are arriving afterwards - this is simple, we solve only at merge time
2. if you do locally, then you never do: we always push everything, just to keep other collaborators updated, so it's always remote

Baseline: I will keep rebasing, feel free to do whatever you think it's best :)

[andreab1997]

So at the end I am a bit confused, what do we want to do with this?

[alecandido]

So at the end I am a bit confused, what do we want to do with this?

I have an opinion, @felixhekhorn has the opposite. Pick your favorite for your own reasons :)

(However, either merge or rebased, but something has to be done, on this we agree)

[andreab1997]

Is everything ok with this?