I'm still fairly new to git (coming from svn) and have found `git stash` to be really useful for storing in-progress work to resume later, as one might otherwise do with diff/patch files. (With the git tools I use, I find `git stash pop` to be more convenient and reliable than creating and applying diffs, partially because the changes remained tied to my repository and easily accessible.)
Since `git stash` defaults to stashing ALL local modifications, I'd like to request there be an easy way to stash *only* the changes I've already staged in the index. (The reason I suggested --cached is due to the similarity with `git diff --cached`, but I don't doubt there would be a better name for this option.)
I tried staging everything *except* what I want to stash and using `git stash save --keep-index <message>`, but it isn't intended to support this case, and doesn't work when I have new untracked files. Instead, it stashes *all* local (tracked) changes — both staged and unstaged — but leaves the staged changes intact in the index.
I understand that git's branching model is powerful and flexible, and that an experienced git user would generally create a private branch and commit to that, then merge the changes to mainline sometime later. However, for those like me for whom having many branches is generally more confusing than helpful, it would be fantastic to have more flexibility with `git stash`.
Thanks in advance for considering my request.
Regards,
- Quinn
Quinn:
On Mon, Apr 13, 2015 at 5:24 PM, Quinn Taylor [off-list ref] wrote:
I'm still fairly new to git (coming from svn) and have found `git stash` to be really useful for storing in-progress work to resume later, as one might otherwise do with diff/patch files. (With the git tools I use, I find `git stash pop` to be more convenient and reliable than creating and applying diffs, partially because the changes remained tied to my repository and easily accessible.)
Since `git stash` defaults to stashing ALL local modifications, I'd like to request there be an easy way to stash *only* the changes I've already staged in the index. (The reason I suggested --cached is due to the similarity with `git diff --cached`, but I don't doubt there would be a better name for this option.)
I tried staging everything *except* what I want to stash and using `git stash save --keep-index <message>`, but it isn't intended to support this case, and doesn't work when I have new untracked files. Instead, it stashes *all* local (tracked) changes — both staged and unstaged — but leaves the staged changes intact in the index.
I understand that git's branching model is powerful and flexible, and that an experienced git user would generally create a private branch and commit to that, then merge the changes to mainline sometime later. However, for those like me for whom having many branches is generally more confusing than helpful, it would be fantastic to have more flexibility with `git stash`.
I know that git-stash feels like a suitable solution for this, but it
really doesn't seem to have been built for it. Especially when you get
a little bit more experienced with Git and start experimenting with
branching more you will find that stashes quickly become difficult to
maintain. Branches are easier to manage, and they come with the full
power of Git for free. It just doesn't make sense to create a separate
system to manage this when it's precisely what Git does so well
already. That's my two cents.
Note that you don't have to merge these "branches". You can rebase as
you please to formulate the history exactly as you want if you want.
You'll find that if you try you can more easily keep track of
branches. It helps to formulate a workflow for yourself. You can even
use "namespaces" in your branch names to keep them separate. For
example, instead of creating a branch with your "stash" changes called
"foobar", you could create one called "stash/foobar". It would help
you to differentiate between other branches, but you still have the
full power of Git. You can rebase the branch onto other history, or
you can merge if you so desire. It's easier to keep track of where the
work began and where it was first applied. There are just so many
advantages. The stash can be useful to quickly tuck a dirty tree away
while you do something else. Even so, often committing it is
sufficient. You can often just work around that commit and edit it
later if necessary.
I'm not a developer so I can't say that your suggestion isn't useful.
I know that I have had the same desire in the past. For example,
wanting git stash save --interactive or git stash save --patch (i.e.,
see git-add flags). Of course, Git already has stable code to do this
and it doesn't require introducing parallel APIs for the same exact
thing. If you give it a shot you may find that branches solve your
problem sufficiently.
Regards,
--
Brandon McCaig [off-list ref] [off-list ref]
Castopulence Software <https://www.castopulence.org/>
Blog <http://www.bambams.ca/>
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
On Mon, Apr 13, 2015 at 02:24:04PM -0700, Quinn Taylor wrote:
I'm still fairly new to git (coming from svn) and have found `git stash` to be really useful for storing in-progress work to resume later, as one might otherwise do with diff/patch files. (With the git tools I use, I find `git stash pop` to be more convenient and reliable than creating and applying diffs, partially because the changes remained tied to my repository and easily accessible.)
Since `git stash` defaults to stashing ALL local modifications, I'd like to request there be an easy way to stash *only* the changes I've already staged in the index. (The reason I suggested --cached is due to the similarity with `git diff --cached`, but I don't doubt there would be a better name for this option.)
Ok, so this git stash --cached will save the state of the index in the
stash, and reset the index to the state in HEAD. What happens to the
working tree?
I tried staging everything *except* what I want to stash and using `git stash save --keep-index <message>`, but it isn't intended to support this case, and doesn't work when I have new untracked files. Instead, it stashes *all* local (tracked) changes — both staged and unstaged — but leaves the staged changes intact in the index.
What do you want this new command to do with untracked files?
I would expect the answers to be it sets the working directories state
to the state in HEAD, and leaves untracked files alone. If that's what
you want you can do git commit -m <message>; git reset --hard; git reset
--soft; git stash save to get the effect you want I believe. That said
it seems like a kind of odd thing to want to do, what are you actually
trying to do?
Trev
I understand that git's branching model is powerful and flexible, and that an experienced git user would generally create a private branch and commit to that, then merge the changes to mainline sometime later. However, for those like me for whom having many branches is generally more confusing than helpful, it would be fantastic to have more flexibility with `git stash`.
Thanks in advance for considering my request.
Regards,
- Quinn
Trevor:
On Mon, Apr 13, 2015 at 9:44 PM, Trevor Saunders [off-list ref] wrote:
I would expect the answers to be it sets the working directories state
to the state in HEAD, and leaves untracked files alone. If that's what
you want you can do git commit -m <message>; git reset --hard; git reset
--soft; git stash save to get the effect you want I believe. That said
it seems like a kind of odd thing to want to do, what are you actually
trying to do?
That looks like a bad solution. git reset --hard is going to throw
away any remaining changes to the working tree. The previous commit
would have committed the staged changes, albeit, you should connect
the commands with && instead of ; to account for errors. After a `git
reset --hard' there's no point in doing a `git reset --soft' because
hard does *everything*. --soft would try to reset the HEAD without
touching the index or working tree, but both have already been reset
with --hard.
The motivation is most likely stashing a few changes away so that you
can commit others that are ready to be committed while keeping others
around to continue working on them. This too is a good observation. It
could mean that the OP is inexperienced with a commit-often workflow.
You can use git -add -i or -p to commit the good stuff and keep the
bad stuff out to work on it more. The great thing about Git is that
the history is very malleable. You can also commit the bad and fix it
after, rebase the history to clean it up, and end up with perfect
history while still keeping your changes safely in history.
The OP should experiment with workflows because Git is already very
good at this. Stash isn't really needed. That said, I had forgotten
that --patch was added to stash some time ago so if that is what you
want then it already exists. It's not quite as easy as --cached, but
it still gives you some control. It's still not nearly as good as
using the full power of Git with a regular commit on a branch though.
Regards,
--
Brandon McCaig [off-list ref] [off-list ref]
Castopulence Software <https://www.castopulence.org/>
Blog <http://www.bambams.ca/>
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
On Mon, Apr 13, 2015 at 10:05:02PM -0400, Brandon McCaig wrote:
Trevor:
On Mon, Apr 13, 2015 at 9:44 PM, Trevor Saunders [off-list ref] wrote:
quoted
I would expect the answers to be it sets the working directories state
to the state in HEAD, and leaves untracked files alone. If that's what
you want you can do git commit -m <message>; git reset --hard; git reset
--soft; git stash save to get the effect you want I believe. That said
it seems like a kind of odd thing to want to do, what are you actually
trying to do?
That looks like a bad solution. git reset --hard is going to throw
away any remaining changes to the working tree. The previous commit
git reset --hard is there to do *exactly* that, which I'm assuming is
the desired thing for a hypothetical git stash save --cached to do
because its consistant with what git stash save does.
would have committed the staged changes, albeit, you should connect
the commands with && instead of ; to account for errors. After a `git
it should be clear this is not actual code to run exactly as written.
reset --hard' there's no point in doing a `git reset --soft' because
hard does *everything*. --soft would try to reset the HEAD without
touching the index or working tree, but both have already been reset
with --hard.
yes, that was supposed to be git reset --soft HEAD~ in which case it
does do something, and it is there exactly to just reset HEAD so that
git stash can then pick up the changes from the temporary commit.
The motivation is most likely stashing a few changes away so that you
can commit others that are ready to be committed while keeping others
around to continue working on them. This too is a good observation. It
yes, it could be they are looking for something like git stash --patch,
but maybe not we don't know.
could mean that the OP is inexperienced with a commit-often workflow.
You can use git -add -i or -p to commit the good stuff and keep the
bad stuff out to work on it more. The great thing about Git is that
the history is very malleable. You can also commit the bad and fix it
after, rebase the history to clean it up, and end up with perfect
history while still keeping your changes safely in history.
git stash also stores changes in the git database. However if you
really like the stack / queue type workflow you might want to consider
stgit or stacked git or something (I personally really dislike that work
flow so I'm not really familiar with those tools).
The OP should experiment with workflows because Git is already very
good at this. Stash isn't really needed. That said, I had forgotten
that --patch was added to stash some time ago so if that is what you
want then it already exists. It's not quite as easy as --cached, but
it still gives you some control. It's still not nearly as good as
using the full power of Git with a regular commit on a branch though.
good is subjective and depends on what you need to do. There are
certainly times where the stash is a good way to solve problems, and if
people have ideas for things they think it can do better that's great.
Trev
Regards,
--
Brandon McCaig [off-list ref] [off-list ref]
Castopulence Software <https://www.castopulence.org/>
Blog <http://www.bambams.ca/>
perl -E '$_=q{V zrna gur orfg jvgu jung V fnl. }.
q{Vg qbrfa'\''g nyjnlf fbhaq gung jnl.};
tr/A-Ma-mN-Zn-z/N-Zn-zA-Ma-m/;say'
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html