On Wed, Dec 09, 2009 at 09:47:56AM +0100, Peter Krefting wrote: > Junio C Hamano: > >> Many people wanted to have "pick many commits onto the current HEAD" >> and I think it would be a natural, uncontroversial and welcome addition >> to allow "git cherry-pick A..B". > > Or even "git cherry-pick branch", as I naïvely tried doing before I > understood what it did. This is definitely a feature that would help me. > > The question of where it goes is actually a bit difficult, it is the same > mode of operation as "git rebase", only the other way around. It is the > same as "git cherry-pick", but called multiple times. And it is the same > as "git merge --squash", but without squashing the commits into one. > > So does this new mode go into rebase, cherry-pick or merge, or into all > three? No matter which, proper documentation is needed. > > > Maybe this could also be used to implement a "git merge --squash A..B", > a.k.a a "partial merge". What exactly should it do? > (And if it could be implemented to allow a "git > merge A..B" and later do a "git merge B" to merge the rest of the > side-branch, that would be interesting). rebase already tries to detect previously applied commits. Maybe we can teach it to use more heuristics. > -- > \\// Peter - http://www.softwolves.pp.se/ -- 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