* Re: [filter-repo] How to reorder commits
2022-07-21 15:19 [filter-repo] How to reorder commits Konstantin Ryabitsev
@ 2022-07-22 23:18 ` Elijah Newren
2022-07-25 21:17 ` Konstantin Ryabitsev
0 siblings, 1 reply; 3+ messages in thread
From: Elijah Newren @ 2022-07-22 23:18 UTC (permalink / raw)
To: Konstantin Ryabitsev; +Cc: Git Mailing List
On Thu, Jul 21, 2022 at 8:19 AM Konstantin Ryabitsev
<konstantin@linuxfoundation.org> wrote:
>
> Elijah:
>
> It seems filter-repo can be used to easily reorder commits, but I'm not able
> to quite figure out how to do it with callbacks. My goal is:
>
> - 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...
Let's say you have a repository where some commit has a file
consisting of the numbers 2-9 on separate lines. Then you had two
more commits after this one: Commit A has numbers 1-9 (i.e. inserting
a new first line with a "1"), and commit B has numbers 1-10 (i.e.
adding "10" to the last line of the file). If you reverse those two
commits in the fast-export/fast-import stream, then B will still have
the numbers 1-10 and A will still have the numbers 1-9 in the file.
That makes it look like B added both lines, and then A removed the
final line, and the end result is a file with one less line than you
had before you reversed the commits.
So, generally, I think you should use a rebase-like tool for
reordering commits rather than anything based on
fast-export/fast-import.
Now, with an empty commit you wouldn't run into these issues and so
you could get away with reordering. But there is another issue: in
the fast-import stream, you have to list all ancestors of a commit
before you list the commit. And git-filter-repo parses commits as it
goes. So you'd have to cache a commit or range of commits without
outputting them, and then later dump them once the new parents have
been output first. I think a rebase-like tool would probably be
better for this job, but if you really want to, you could probably get
this working in filter-repo with a script similar to the ones in
contrib/filter-repo-demos, but making sure to use steps something like
the following:
* Avoid commits getting dumped by setting "commit.dumped = 1" (a
"lie" which prevents git-filter-repo from immediately outputting the
commit after your callback)
* Save the commits in a list somewhere
* As you are processing the commit(s) that need to be moved earlier
modify the parents of these commit(s) (i.e. the commit.parents field)
appropriately
* After you've output the commit(s) that needed to be moved earlier,
iterate through the saved commit(s) and modify their parents and call
commit.dump() on them.
^ permalink raw reply [flat|nested] 3+ messages in thread