Re: [filter-repo] How to reorder commits
- From
Konstantin Ryabitsev <konstantin@linuxfoundation.org>
- Date
- Jul 25, 2022, 21:17 UTC
- Message-ID
- <20220725211726.tkmpvgetsh4fdfdv@meerkat.local>
- In-Reply-To
- <CABPp-BE2391i7syZJUK1Nqjk9VZhSxqto0pb7xBLDZR_fY3FXA@mail.gmail.com>
On Fri, Jul 22, 2022 at 04:18:48PM -0700, Elijah Newren wrote:
Show 23 quoted lines
> > - keep the cover letter at the start of the series in order to cleanly > > delineate where their work starts (and thus avoid potential problems with > > rebases and finding fork-points with base branches, which tends to give > > newbies trouble) > > - when the author is ready to submit their work, move the cover letter to the > > tip of the branch and tag it as "foo-bar-v1" > > - when the author is ready to work on their changes, they run --reroll and we > > move the cover letter back to the start of the series, adding any necessary > > template "changes in vX" entries to it > > > > (or maybe it will go completely differently -- it's all very fluid right now) > > > > Basically, is git-filter-repo the right tool to reorder commits, or is it best > > to go directly with fast-export/fast-import? > > > > Thanks in advance, > > Konstantin > > Generally, it makes no sense to reorder commits in filter-repo, nor > does it make sense to do so using fast-export/fast-import directly. > fast-export/fast-import don't "apply a diff" to get a new tree, they > say "Make these files have these exact contents". Perhaps an example > would help to explain what I mean...
Thank you for the detailed reply, Elijah. You did convince that filter-repo is not the right tool for this case, so I went with cherry-pick instead. Since my case is very straightforward with simple ranges and a guarantee of no conflicts, it's the most straightforward solution.
Cheers, Konstantin