From: Ramkumar Ramachandra <artagnon@gmail.com>
Date: Sat, 24 Sep 2011 09:12:15 GMT
Subject: Re: git-rebase skips automatically no more needed commits
Message-ID: <CALkWK0mggSNoxxqzUaGp1-AxGWSpCb0HnRmBxSkcVrHnhwMr1Q@mail.gmail.com>
In-Reply-To: <alpine.DEB.2.00.1109201254020.12564@debian>

Hi Martin,

Martin von Zweigbergk writes:
> 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

Ah, nice :)

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

Using git-format-patch for anything except emailing patches to the
maintainer/ list is a mistake imo.

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

Either this, or we have to write another wrapper around git-patch-id.

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

Yeah, in the wake of scripts already doing "apply && write-tree &&
commit-tree" by hand, I think this proposal for git-cherry-pick makes
a lot of sense.  I'm not sure if the option should be called '-2'
though.

Thanks.

-- Ram