Martin von Zweigbergk <martin.von.zweigbergk@xxxxxxxxx> writes:
> 2. Somehow modify git-rebase--am.sh not to depend on format-patch. In
> [1], Junio mentions rewriting git-rebase--am.sh "to have
> format-patch avoid the cost of actually generating the patch text"
> and "when using "am" for rebasing we do not really care anything
> but the commit object names". If all we need is the commit name,
> why would we not use cherry-pick/sequencer instead of git-am?
What I said is "all 'am' need to use from its input while rebasing is the
commit object name"; that is very different from "we have only commit
object name so we must use cherry-pick" or "because we have commit object
name, we can afford to use cherry-pick".
Look for $rebasing in git-am.sh and notice that:
- We run get-author-ident-from-commit on $commit to keep the authorship
information in $dotest/author-script for later use, instead of letting
them read from $dotest/info prepared by "mailinfo".
- My "fixing it would be just the matter of doing this" patch in a
separate thread we had recently ("mailinfo" would obviously have
trouble telling where the message ends whilerebasing a change with
patch text in the commit log message) adds a similar logic to extract
the patch text out of $commit in the same place as above, to override
what "mailinfo" prepares in $dotest/patch.
- Even with the above two differences from the normal "separate the
metainfo and patch from the mailbox, and use them" codepath, $rebasing
codepath uses the same "git apply && git write-tree && git commit-tree"
flow.
Use of "apply && write-tree && commit-tree" is to avoid the merge overhead
of using cherry-pick, and historically, it used to matter a lot, because
starting merge-recursive was very slow (it was a Python script). Even
though we have merge-recursive rewritten in C these days, it probably
still matters, especially for large-ish projects, because merge will trash
the cached-tree information in the index, making write-tree inefficient.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html