search

prati0100 / git-gui

Tcl/Tk based UI for Git. I am currently acting as the project's maintainer.
160 stars 87 forks source link

Add ability to stash outstanding uncommitted changes to allow testing of current worktree #60

Open PhilipOakley opened 3 years ago

PhilipOakley commented 3 years ago

In a recent discussion on the Git mailing list, a user of jupyter notebooks noted the need to test partial commits during a 'merge' of the notebook's changes.

This requires that the worktree reflects the state of staging area with no uncommitted files (I'm assuming a suitable .gitignore file here..). This would need a type git stash of the remaining work (those in the unstaged changes pane), retaining the staged files so as to test the updated notebook for functionality. essentially we have a temporary commit of the staged changes, and a stash of the unstaged changes. (I don't use stash much myself so this is conceptual..)

Is that a reasonable request, and what concerns should be included in any design.

prati0100 commented 3 years ago

To clarify, do you want the ability to stash just the unstaged changes, leaving the staged changes as they are? If so, I think this is a useful feature. I have used it once or twice in Magit (Git client for Emacs) to make partial stashes.

PhilipOakley commented 3 years ago

the ability to stash just the unstaged changes, leaving the staged changes as they are?

(been off-line 2 wks) Yes {qualified}.

After the notional git stash --unstaged-only the user would have a pseudo clean tree (clean relative to their currently staged changes). At that point they could build and test their staged changes.

They could even create a (temporary) 'WIP' commit if they wanted extra security (e.g. the build is ok but the testing isn't and they go down a rabbit hole..).

Once the staged files pass what ever checks they need to do, then they can unstash the remaining changes without conflict relative to the staged changes (hence the potential that there is a tree for the staged changes)

Thinking some more, and trying to decrypt the stash man page example about it being actually two commits, it maybe that the problem not only be in the stash save step, but also in the stash pop step, where all we want to just (user viewpoint) pop the unstaged changes without conflict (given that the staged changes should still be present).

Unfortunately I don't know much about the stash code.