git cherry-pick feature request

Junio,

I have added a feature on the "new" branch of gitk which allows the user to cherry-pick commits on to the head of the current branch. Currently I am using 'sh -c "git cherry-pick -r $id 2>&1"' for this.

The reason for the "2>&1" is that git cherry-pick writes stuff to stderr even when there is no error, and the Tcl exec command assumes that if the command writes to stderr that it failed somehow.

Also, if the merge fails, git cherry-pick leaves the commit partially merged rather than restoring the original state.

Could I have a flag to git cherry-pick (-q for quiet, maybe) that tells it not to print anything if the command succeeds? Could I also have a flag that tells it to clean up if the merge fails and leave the tree in its previous state?

Or is there some other git command that already does all this that I should use instead?

Thanks, Paul.

Paul Mackerras <paulus@samba.org> writes:

Quiet sounds sane.

Reverting to its "previous state" I am not quite sure if it is worth making it an option and run it as part of cherry-pick.

Junio C Hamano writes:

OK. If the git cherry-pick terminates with an error I'll get gitk to show the error message (if any) it printed along with a warning that the working directory might need to be cleaned up. I don't really want to do a git reset automagically since the user might have local modifications that they want to preserve.

While I'm asking for features, another one that would be really useful for another tool I'm writing is a 3-way diff for a file between the working directory, the index, and the current head commit, something like what git diff-tree -c does for merges. That is, it would have two columns of +/-/space characters, one for the current head and one for the index. A '-' would indicate that the line appears in the current head or the index but not in the version of the file in the working directory. A '+' would indicate that the line appears in the working directory version.

How hard would it be to adapt the git diff-tree -c mechanism to work on two blobs plus the file from the working directory?

Thanks, Paul.

On Wed, Aug 23, 2006 at 11:07:33PM +1000, Paul Mackerras wrote:

Theoretically I'm working on this, but I haven't really had time to get started on it yet this week. If you have patience, I'll get to it. If not, then somebody else is welcome to take a crack at it.

-Peff

Jeff King <peff@peff.net> writes:

It is not entirely related, but I've restarted looking into a parallel tree walker again and will push something in "pu" tonight.

It will probably be quite a while until it becomes useful, though. I suspect your approach of internally running run_diff_files() and run_diff_index() and consolidating the result, while it might feel hackish, would be easier at least in the short term.

Paul Mackerras <paulus@samba.org> writes:

The combined diff (-c and --cc) comparison works by comparing a single post-image (merge result) with multiple pre-images, so I think it is reasonable to compare the working tree files as the post-image and cached and HEAD-tree versions as the preimages.

I am not sure how useful this would be though -- I am guessing that in most people's workflow the index and the HEAD would exactly match most of the time, since that is the way Linus encourages (and I follow that myself). So for that extreme use case, the difference between "diff-index HEAD" and the proposed command (I am thinking about calling it git-diff-status) would be that the latter always has two plus or minus signs instead of one, and lines with a single plus or minus would be an indication that HEAD and index have drifted. In other words, the largest benefit of "combined diff" which is to simplify trivial "The result took this one not that one wholesale" differences would not be felt.

I have to visualize the result a bit before coding this.

Junio C Hamano writes:

Yes, I think that is probably the most useful way around.

The tool I am writing knows whether the index matches the HEAD or the working directory, and uses a simple git diff-index -p in those cases. The only time when the 3-way diff would be needed is when the user wants to commit a subset of the changes in the working version, because then the index (== changes to be committed) would be different from both the HEAD and the working directory.

I could just do the two diffs and combine them in Tcl; I have done that sort of thing in dirdiff. It gets a bit complicated though, and given that we already have C code for an N-way diff, I thought it made sense to reuse it.

Thanks, Paul.