Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Open
PhilipOakley opened this issue May 24, 2021 · 2 comments

Comments

@PhilipOakley
Copy link

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
Copy link
Owner

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
Copy link
Author

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants