+3

Quick way to show the files that are being worked on in this branch

omegatron 8 years ago updated by Marc Strapetz 5 years ago 13

I asked if we could open files from the log, but that's apparently not possible because they might have been moved since that commit, etc. we can only copy "relative path".


Then I thought I could sort by "Last Changed On", but that's the filesystem modification date, not the last time it was changed in the git history. If you check out a different branch, all files changed in that branch are marked with the current datestamp, rather than the last time they were modified in the history.


If you could show the last time they were modified as a column in the Files view, that would work.

Missing Git feature

How do you define "in this branch"?

The branch that is currently checked out

Well, the repository window shows all files that are changed and not yet committed. The Journal also shows very clear the last commits in the current branch, but to see the committed files, you would have to use the Log and compare the HEAD with the commit of your choice. This won't work for uncommitted changes (ATM).

Showing files not yet committed doesn't help: I want to see files that were recently committed.

Log doesn't help because I can't open files from the Log.

A column of "last committed date" would help, because I could sort by that column and the most recently edited files (in this branch) would be listed at the top, and then I can drag the ones I want into an IDE. Switching to another branch that modifies all the files and switching back wouldn't change this column, because it's based on commit history, not on filesystem dates.

Kind of like the right-hand side of Github's display: https://github.com/scipy/scipy/tree/master/scipy


I want to open a branch, immediately see the 3 files (out of thousands) that I was working on in this branch, and open them in an editor.


Currently I have to checkout a branch, go to the log, search through it to see which files I modified, copy their relative path, open IDE, File -> Open, try to find the root folder that the relative path is based on, paste in the rest of the relative path, etc. etc. or manually type in their names to the main file search box and hope that there aren't other files with the same name in other folders (which there often are), etc.

What I don't fully understand is why you want to open the 3 files in your IDE. Just to find the files easier where you were working on the task and now have to continue, or to undo some irrelevant changes? What if you deleted a few files in your branch - should they also be shown for editing (or just those available in the working copy)? Do you need to see the changes made in your branch or just the files (that were changed in your branch) in its current working tree state?

"Just to find the files easier where you were working on the task and now have to continue"


Yes


"What if you deleted a few files in your branch - should they also be shown for editing (or just those available in the working copy)?"


Just those files that currently exist, like it currently shows.


"Do you need to see the changes made in your branch or just the files (that were changed in your branch) in its current working tree state?"


Just the files. In the main Files pane, have a column for "Latest commit" or something that shows the date of the most recent commit that affected that file.

+1

This is a very valid request and omegatron describes it perfectly. Too bad nobody seems to care...

Of course, this is a valid request, but we have no good idea how to implement it. With SmartGit 18.2 the options might change, too. Good suggestions are appreciated.

I gave a good suggestion on how to implement it.  Add a column to the main window (hidden by default if you want), that shows the date of the last commit for each existing file, so they can be sorted by date of last edit.

This is hard to implement. Any alternative suggestions?

Well I don't know what makes things hard to implement.  I would think it just an extension of the blame functionality, but I don't know.

Basically, what you are suggesting requires a Log (most likely of the entire repository) for every refresh. That will be too expensive.

+1

I think the issue with userecho is that good ideas get buried over time and never gets a chance for people to vote on.  If only there's an AI algo to randomly bump up old ideas to the top to get some visibility.