0

When I do git rebase <base-commit>, I see the directory .git/rebase-apply is created containing the files onto, orig-head, and original-commit, referencing <base-commit>, head, and the current commit being applied respectively.

When I do git rebase -i <base-commit>, instead I see the directory .git/rebase-merge containing the files onto, orig-head, and stopped-sha, where stopped-sha seems equivilent to original-commit.

My question is why the discrepancy of file & dir naming between interactive and non-interactive rebase? And is my understanding of the files correct?

junvar
  • 11,151
  • 2
  • 30
  • 46
  • 1
    For people using git these are consequence-free implementation details. If you're curious anyway rebase is a script in libexec/git-core, if you want to try reimplementing it maybe that'll explain why it's done as it is. – jthill Oct 17 '18 at 15:31
  • 1
    @jthill: rebase *was* a script. Now it's mostly C code. The C code mostly does what the script used to do, but that's a lot of "mostly"... (In this particular case, the difference between `git-rebase--am` and `git-rebase--interactive` is preserved, but the scripts are starting to lose some of their relevance.) – torek Oct 17 '18 at 15:47
  • @jthill: these details r actually important to me, because i rely on these files for my own script (to print a log of commits between `base` and `head` and highlight the `current-commit`. Can i assume these file structures will most likely stay stable? – junvar Oct 17 '18 at 16:15

1 Answers1

2

You have come across the difference between a git format-patch | git am style rebase and a git cherry-pick style rebase. As jthill noted in a comment, these are not intended to be different in most cases for most users. They were originally separated into two different back ends, spelled git-rebase--am and git-rebase--interactive. (They still are, but the distinction is being weakened.)

There is one important difference between the two, having to do with file-rename detection. Since the cherry-pick rebase literally uses the git cherry-pick machinery, which uses the underlying merge machinery, this enables rename detection. Since the format-patch rebase does not, it does not. Rename detection is slow, so if there are no renames, sometimes the format-patch variety goes faster.

You can force git rebase to use the cherry-pick mode without going to interactive rebase by adding -m or -s <strategy> or -X <extended-strategy-option> arguments to any rebase.

torek
  • 448,244
  • 59
  • 642
  • 775