Junio C Hamano <gitster@xxxxxxxxx> writes: > Johannes Schindelin <Johannes.Schindelin@xxxxxx> writes: > >> In the same way, I would expect "git revert <commit> -- file" to undo the >> changes in that commit to _that_ file (something like "git merge-file >> file <commit>:file <commit>^:file"), but this time commit it, since it >> was committed at one stage. > > Allowing people to revert or cherry pick partially by using > paths limiter is a very good idea; ... As Pierre said earlier, a partial revert via "revert <commit> -- <paths>" and a partial cherry-pick would make quite a lot of sense, and in addition, it should not be too hard to add. Reusing the 'merge-recursive' part should be almost trivial. The only tricky part is coming up with a fake tree using base and next commit in revert_or_cherry_pick() for this purpose. When replaying the change from A->B (when cherry-picking, A is the parent and B is what was named from the command line; when reverting, they are the other way around), instead of doing the three-way merge using: merge-recursive A HEAD B you would first come up with a modified tree B' that has the identical contents to A _except_ the parts the path limiters specify which are taken from B. Then running merge-recursive A HEAD B' would replay the revert or cherry-pick of change from A->B, limited by the path, on top of the current HEAD. As to "reverting to the index" case, if somebody is interested in doing a builtin-checkout.c, please keep in mind that major parts of that work should be made available to the implementation of "git revert [--] <paths>", as it appears that it will be exactly the same as "git checkout" with the same set of options. I am wondering what "git cherry-pick -- <paths>" should do. My current thinking is that it would not make any sense at all. - 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
