Commit f88d9f2
committed
fix: use the *last* rebase list, instead of the first
a) if the was only 1 rebase, nothing changes
b) in other cases i've encountered,
using the last rebase always proved better
than the 1st one:
1st one would error oftenly; succeeded rarily
last one would work just fine
but, there's still a lot of testing to do.
especially for >2 rebases, since i've only encountered 2.
it's a bit dangerous because if we pick the wrong rebase,
then we could lose commits / their content.
now, picking just 1 rebase is still incomplete --
this fix is just a (seemingly) better heuristic,
(!) but eventually we'll need to
take into account all of the rebases.
there might be ways to eliminate this need,
e.g. auto-calling `git-stacked-rebase --apply`
in the `post-rewrite` script in the background,
but at least for now, don't want to mess with it
and would prefer to avoid, until i have done
more dog-fooding & encounter more edge-cases
& maybe potential solutions/invariants as well.
Signed-off-by: Kipras Melnikovas <kipras@kipras.org>1 parent 8e0baee commit f88d9f2
1 file changed
+6
-2
lines changed| Original file line number | Diff line number | Diff line change | |
|---|---|---|---|
| |||
307 | 307 | | |
308 | 308 | | |
309 | 309 | | |
310 | | - | |
| 310 | + | |
| 311 | + | |
| 312 | + | |
| 313 | + | |
| 314 | + | |
311 | 315 | | |
312 | 316 | | |
313 | 317 | | |
| |||
317 | 321 | | |
318 | 322 | | |
319 | 323 | | |
320 | | - | |
| 324 | + | |
321 | 325 | | |
322 | 326 | | |
323 | 327 | | |
| |||
0 commit comments