Re: git-rebase skips automatically no more needed commits

From: Junio C Hamano <gitster@pobox.com>
Date: Sep 15, 2011, 03:41 UTC
Message-ID: <7vwrdaqxpk.fsf@alter.siamese.dyndns.org>
In-Reply-To: <alpine.DEB.2.00.1109122139110.12564@debian>

Martin von Zweigbergk <martin.von.zweigbergk@gmail.com> writes:

Show 6 quoted lines

>  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.