Jeff King p...@peff.net writes:
Right, I am suggesting that latter: that stash should abort if the index
has modified entries. The abort for modified working tree files is done
by git-merge, which can be selective about which entries will be changed
(since it knows which ones need written).
On Wed, Apr 22, 2015 at 10:41:04AM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Right, I am suggesting that latter: that stash should abort if the index
has modified entries. The abort for modified working tree files is done
by git-merge, which can be selective about
On Wed, Apr 22, 2015 at 02:35:40PM -0400, Jeff King wrote:
Ironically, the message before e0e2a9c actually recommends staging
changes before applying the stash, which would lead to this exact
situation! So I think the most trivial patch is:
diff --git a/git-stash.sh b/git-stash.sh
index
Jeff King p...@peff.net writes:
Ironically, the message before e0e2a9c actually recommends staging
changes before applying the stash, which would lead to this exact
situation!
The ancient history is hazy to me, but did we fall back to three-way
merge in old days (or did anything to the index
On Wed, Apr 22, 2015 at 12:45:21PM -0700, Junio C Hamano wrote:
Jeff King p...@peff.net writes:
Ironically, the message before e0e2a9c actually recommends staging
changes before applying the stash, which would lead to this exact
situation!
The ancient history is hazy to me, but did we
On 04/22/2015 12:29 AM, Jeff King wrote:
Hmm, interestingly, if you do _not_ stage the changes (i.e., drop the
final git add there), you get:
$ git stash pop
error: Your local changes to the following files would be overwritten by
merge:
test
Please, commit your changes or
On Wed, Apr 22, 2015 at 01:35:05AM +0300, Dmitry Gutov wrote:
But we seem to skip that safety valve when the content has been staged,
which seems questionable to me (technically we are slightly better off
than the protected case because b was written to a git blob
object, so you can
On Tue, Apr 21, 2015 at 01:54:56AM +0300, Dmitry Gutov wrote:
I'm not really sure what higher stage entries are, but this scenario seems
to be a counter-example:
git init
echo a test
git add test
git commit -m first
echo aaa test
git stash save
echo b test
git add test
git
On 04/21/2015 12:11 AM, Junio C Hamano wrote:
But the said file, if it had conflicted, would have had only the
conflicted higher stage entries in the index, no? That is, the
failed merge wouldn't have touched the index for the path if it
already had changes there in the first place.
I'm not
Dmitry Gutov dgu...@yandex.ru writes:
Either will reset already-staged changes from the said file, which is
an irreversible operation.
But the said file, if it had conflicted, would have had only the
conflicted higher stage entries in the index, no? That is, the
failed merge wouldn't have
10 matches
Mail list logo
