Re: git-rebase skips automatically no more needed commits

From: Martin von Zweigbergk <martin.von.zweigbergk@gmail.com>
Date: Sep 20, 2011, 20:45 UTC
Message-ID: <alpine.DEB.2.00.1109201254020.12564@debian>
In-Reply-To: <alpine.DEB.2.00.1109151956040.12564@debian>

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