[Feature Request] - Show Uncommitted Changes in Commit History

[cwhenderson20]

I'm loving Fork so far! One feature that I do miss (coming from SourceTree) is the ability to see current uncommitted changes within the history view:

For me, it makes more sense than separating out changes into their own section because ultimately, those changes will become part of the history once they're committed. It also reduces the amount of context switching as I can see past commit messages when I'm ready to commit changes.

I'm sure not everyone agrees though, so some kind of preference such as "Show uncommitted changes with history" would be a great compromise.

Thanks for a great product!

[bwl21]

I repeat my comment to #107 in order to second this ..

Very cool. Now we can see that we are on a detached head. I am afraid I propose to do more:

Here is a situation in fork,

• love the idea to visualize the stashes in the history tree.
• I would also like to see the HEAD visualized in the history tree
• I would also like the "uncommitted changes" in the history tree

Here is what I expected (Sorry Atlassian, I shameless copy Sourcetree's beahavior). But this visualization is the coolest approach I have seen for this.

[DanPristupov]

What should be shown in details view when the 'uncommitted changes' item is selected? That is my biggest concern in this feature.

[bwl21]

It should be the same content shown by Fork when I click on "changes" in the sidebar. This is what sourcetree does.

[DanPristupov]

I think it will be very confusing to show the changes in two views, but allow to commit only in one.

[bwl21]

If you show the contents of "changes" in the details view and allow to state, unstage, commit as you do in the "changes" view. It is not that confusing.

you could even switch to "changes" if user clicks on "uncommitted changes". The primary reason for the request is that I can see in the timeline if anything is committed properly. As the number of uncommitted changes-Tag on "changes" is not reliable, I always have to click on "changes" to check the status of all files.

[omarn3tworkcom]

I'm glad this is currently a thing, I love the idea of "Uncommitted changes" or "Working copy changes" as the top item in the graph. Several git clients do it and it just feels right.

This way, the Changes section can be included in that top item when selected in the graph and the Changes section can be removed all together.

So, it's just a matter of moving the section to another place, not duplicating it.

[omarn3tworkcom]

Here is an example of how the two views would look: History.png Commit.png

[maksimovic]

Maybe it's just a relic from SourceTree's habits, and a bit too much to expect the flow to be replicated 1:1 in Fork. I've used SourceTree for years, then switched to Fork and I must admit that I did miss its "uncommited changes" a bit. However, as soon as I figured out that CMD+1 shows exactly that, it became natural to toggle between the history view (CMD+2) and uncommitted changes by keyboard.

[omarn3tworkcom]

There is no problem in usability however, it's a matter of less keys/clicks as much as possible without losing track of all the information.

[dalewking]

Having another screen to see changes is not equivalent functionality. In the history view I can select 2 commits and see the difference between those commits. In SourceTree I can also select the uncommitted changes and another commit and see the difference between my current workspace and some arbitrary commit. No way to do that in Fork. That is a feature I have used often in SourceTree. I can tell you that feature is somewhat buggy in SourceTree in that if you go edit the files and then go back to sourcetree it will not update the diff automatically and you have to go select them again to see the updated diff, but I live with that minor annoyance as this feature is so useful.

The question of what to show when selecting it is simple it just shows the difference between your workspace and the last commit, just like what git diff would show.

[dalewking]

Actually what ST shows at the bottom is mostly the same view that is under File status (which is the same as your Changes page) just without the controls for doing a commit. So it has Unstaged changes list, Staged changes list, and diff, but not the commit message, etc.

[ibushong]

+1

I just switched over to Fork and I wish it had this feature too (I used this all the time in ST). Maybe I just need to get used to a different workflow, but I still see an argument for adding this in.

[bwl21]

To be honest, I now got used to it and no longer request it urgently. It seems that newbies want it - and I am no longer a newbie :-)

[maksimovic]

Come on, Cmd+1 is way faster than hunting the top row in the commit history 😼

[dalewking]

To be honest, I now got used to it and no longer request it urgently. It seems that newbies want it - and I am no longer a newbie :-)

To be honest, I could never get used to it and no longer request it urgently. It seems that users want it - and I am no longer a user

[omarn3tworkcom]

I'm no longer a user Made me laugh

Come on, Cmd+1 is way faster than hunting the top row in the commit history 😼 No need for a shortcut is even faster you know

[brechtm]

It would be useful to have the uncommited changes show up in the commit history* to be able to diff between e.g. an arbitrary commit/stash entry and the uncommitted changes. Or his this already possible in another way?

* perhaps even showing staged/non-staged changes as separate entries

[bwl21]

u can stash the current changes. then they show up in the commit history and you can compare them

[brechtm]

u can stash the current changes. then they show up in the commit history and you can compare them

True, but that requires an extra step and makes you loose staged changes (or rather the distinction between staged/unstaged changes).

[bwl21]

loose staged changes (or rather the distinction between staged/unstaged changes).

agree, for this reason, I have the same request. My proposal is a workaround - better than nothing

[r-owen]

I think it will be very confusing to show the changes in two views, but allow to commit only in one.

I think you should try SourceTree before dismissing this suggestion. I have never found it confusing, and I find it very useful to be able to compare the current state of a file (local changes) to older commits. The lack of this feature in Fork is the main reason I still use SourceTree instead of Fork (the other being the slightly-to-small font).

[DanPristupov]

@r-owen

I think you should try SourceTree before dismissing this suggestion.

About 7 years ago I was looking for a git client for Mac. I tried ST, couldn't figure out how to work with it and in desperation I decided to make Fork.

I find it very useful to be able to compare the current state of a file (local changes) to older commits.

Right click on a commit -> Compare to Local Changes

[icezohu]

@r-owen

I think you should try SourceTree before dismissing this suggestion.

About 7 years ago I was looking for a git client for Mac. I tried ST, couldn't figure out how to work with it and in desperation I decided to make Fork.

I find it very useful to be able to compare the current state of a file (local changes) to older commits.

Right click on a commit -> Compare to Local Changes

wow, it's useful, didn't find this option before.

[timmb]

This is my most requested feature. I like it also because it makes it much clearer that the working tree is dirty when looking at the view. I've been using Fork a while now but I still find myself losing time by making changes without realising I had unstaged work left over from a previously interrupted task.

And as mentioned, the workflow to compare local changes to an earlier revision is the same as comparing two revisions.