Log, Files view: allow to compare modified working tree against arbitrary commit

TortoiseGit has this useful feature: https://tortoisegit.org/docs/tortoisegit/tgit-dug-diff.html

>If you want to see the difference between a particular revision and your working tree, use the Log dialog, select the revision >of interest, then select Compare with working tree from the context menu (cf. the section called “Log Dialog”).

Hello @Marc

Now I become a paying user. I working at Camtek ltd, and we purchase 5 licenses because of me. We willing to buy more if you can improve your amazing app.

As my last topic that decline: #1179

I want to add as you requested more info about: 'Editing the working tree when diffing against an arbitrary commit'

One use case is you want to add a specific things from the arbitrary commit. and not bring all changes from that commit like git cherry pick.
Go over file by file and add the specific things.

I also ask from my colleges that will comment here, and explain in their words why it important feature for us. 

Thank you.

> One use case is you want to add a specific things from the arbitrary commit. and not bring all changes from that commit like git cherry pick. Go over file by file and add the specific things.

In general this won't work well with a Working Tree - Commit comparison because this diff will include all changes between Working Tree and the commit and not only the commit's changes as patch, rewritten to the working tree, i.e. what a cherry-pick will do. It will be easier and safer to cherry-pick the corresponding commit without committing the cherry-pick, then use e.g. the Index Editor to unstage unwanted changes.

When I am doing it, the working tree is empty.
Second, in the same file I don't want all the changes. Not sure how to do it with cherry pick like you say.
Also more easy and intuitive to allow to diff commit with working tree that i can edit like other git clients that do that.
I already use this feature many time in git extension. But I would really love to see it in smartgit. 

Since some SmartGit versions it is possible to cherry-pick individual files from a commit. And even longer there is a Compare with Working Tree feature. Both are available in the context menu of commit files.

Hello, I would really like to have this functionality. Are you already developing it? Thank you

This feature will be useful for thefollowing use case:

I have branched from a remote repository and made 10 changes and committed them locally. But then I decided to commit a set of changes that partially reverts some of the previous 10 commits. And before making that 11 th commit, I want to compare it to the branch that I started with. And if it's OK, I will commit it.

Hi, any news on this functionality? it would be really useful!!!!

Did you try Compare with Working Tree from the context menu of a commit's file?

Thank you, it works!

Why choosing in the log window the row "Working Tree" and another commit the difference is not between the Working Tree and that commit? Working Tree means Working Tree or am i missing something about the english language? I lost a lot of hours for this critical bug and i had to use git from the Dos Prompt in the end. I think at least 90% of people doing source code differences need that feature versus the working tree. I think Syntevo developers are not using their own tool, otherwise they should have missed this feature.

in fact I just learned that it's only compared to the index...which explains why I am wondering from time to time why I didn't see that particular difference, now I know.

Like Leonardo said it's the logical thing to do.
A Working Tree is a working tree and not the index.
The object I see is the one to operate on.

It's an everyday use case.

For example:
Someone has committed something which should really be two or even more commits.
This may be lazyness, or working on several things at once, or correcting spelling or translation errors while working on something.
Now I want to import only a certain part of it (lets say I'm working on other spelling errors or translation).
It's easily done for a single file, just do "Compare with Working Tree" (as Thomas keeps mentioning).
But if the changes are distributed over several files, I am not even able to find these.
It's only possible by first staging my own changes. But I may already have staged something while the rest should be kept unstaged.
I could stash my changes, but I may have done a similar change.

Which is the next use case.
I have changes and some incoming branch has also changes in the same area.
Now I want to see, if I have to bother with conflicts with these changes or if I can borrow something to ease the merge.
All before the more expensive operations.
It's simply more convenient to do it live than to start committing my changes, then do a compare and then split or something to get it together. Most operations don't like local changes. Stash etc. all lead to conflict situations.
Directly comparing with and editing the working tree is a lean operation like a shortcut. And the natural thing to do.

Well, it's often used in teams that are very cooperative.
In fact sometimes a co-developer at the other end of the world says, look at this, could it be useful to you (knowing what I am working at)?

At the end, if it's useful for one file, it's also useful for a whole commit.

> Someone has committed something which should really be two or even more commits.

For that usecase SmartGit offers the Split Commit command.

I also really would want this feature.
I do a lot of single commits and often want to see the summary of these commits.
Also I use a external Diff tool and therefore I want to have the {rightLocalFile} in the right window to be able to direct modify the file on the filesystem. This allows me to be able to fix some things from the last commits, because the sum of all changes has to be correct and coherent.
Workaround as for now:
- Stage all files, so index is more or less the working tree
- Create a batch script which checks if a right file to compare is a file from the index and then instead of using {rightFile} use the {rightLocalFile} for the external diff tool (open the diff tool in the batch file)

Sadly this workflow is not as good as with tortoise git...