From: Junio C Hamano Date: Tue, 06 Nov 2007 11:08:53 GMT Subject: Re: [PATCH] git-revert is one of the most misunderstood command in git, help users out. Message-ID: <7vk5oviqbe.fsf@gitster.siamese.dyndns.org> In-Reply-To: <7vsl3kjdct.fsf@gitster.siamese.dyndns.org> Junio C Hamano writes: > Johannes Schindelin writes: > >> In the same way, I would expect "git revert -- file" to undo the >> changes in that commit to _that_ file (something like "git merge-file >> file :file ^: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 -- " 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 [--] ", 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 -- " should do. My current thinking is that it would not make any sense at all.