Re: git-rebase skips automatically no more needed commits

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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


[Index of Archives]     [Linux Kernel Development]     [Gcc Help]     [IETF Annouce]     [DCCP]     [Netdev]     [Networking]     [Security]     [V4L]     [Bugtraq]     [Yosemite]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux RAID]     [Linux SCSI]     [Fedora Users]