Re: git-rebase skips automatically no more needed commits

[Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>]

On Thu, 15 Sep 2011, Martin von Zweigbergk wrote:

[CC'ing Ramkunar regarding the footnote]

> [...] With your
> patch, we would also get the patch body from the commit. The only
> thing remaining after that is the commit log message, correct?

It turns out the commit log message have been taken from the commit
for ages. Sorry about not checking the code first.

I have started implementing the changes to git-am.sh now. I have made
it not use mailinfo when in $rebasing mode, as you suggested. So now
git-am works even if only a list of

  From $sha1 Mon Sep 17 00:00:00 2001

lines are fed to it. Since only the $sha1 is needed, we should
probably make --rebasing imply a patch-format is just a simple list of
revisions. Since the --rebasing flag is only for internal use, this
should be safe when it comes to backwards compatibility. [1]

Now the question is how to generate such lines, without the overhead
of a full format-patch call. We still want the --ignore-if-in-upstream
functionality, so we can not use plain rev-list. We also want it to
work with --root, so we can not use git-cherry. Finally, we can not
use 'git rev-list --cherry-pick --right-only' since it seems to be
inherently for symmetric ranges and therefore does not support
git-cherry's <limit> parameter.

If I'm not mistaken, we would have to teach some new option to some
command, but which one?

It doesn't feel right to teach format-patch a --commit-name-only,
simply because it would then no longer be a patch.

It's probably easiest to teach git-cherry a --root flag. Does that
sound like the right solution to people? I think it makes sense for
such an option to exist.

More involved would be to teach rev-list --cherry-pick also for
asymmetric ranges. I would imagine that "--cherry-pick $branch --not
$newbase $oldbase" could be defined as "all commits in $branch that
are not patch-equivalent to any commits in $newbase or $oldbase". Just
s/patch-equivalent/identical/ and you have the regular definition of
the rev-list, right? There is of course no need to actually calculate
the patch-id for any commits are not in "$branch --not $newbase
$oldbase" (identical => patch-equivalent).

I would go for teaching git-cherry --root, unless the "rev-list
--cherry-pick for asymmetric ranges" option would be useful
elsewhere. Either way, teaching git-cherry --root would not be a bad
thing, I think.


Martin


 [1] Long term, would it make sense to teach 'git cherry-pick' a '-2'
     option instead of using the '-3' option to 'git am'? (Where 'git
     cherry-pick -2' would try "apply && write-tree && commit-tree"
     before falling back to merging.)