Ignore dirty submodule states during stash
PATCH 1/1 Ignore dirty submodule states during stash
Do not save states of submodules as stash should ignore it.
--- git-stash.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)
git-stash.sh +1 -1
@@ -116,7 +116,7 @@ create_stash () { git read-tree --index-output="$TMPindex" -m $i_tree && GIT_INDEX_FILE="$TMPindex" && export GIT_INDEX_FILE && - git diff --name-only -z HEAD -- >"$TMP-stagenames" && + git diff --name-only --ignore-submodules -z HEAD -- >"$TMP-stagenames" && git update-index -z --add --remove --stdin <"$TMP-stagenames" && git write-tree && rm -f "$TMPindex"
Signature · 1 line
2.1.4
Quoted 1 line · Vasily Titskiy
Do not save states of submodules as stash should ignore it.
Can you explain why this is a good idea?
(It is not obvious to me either way.)
Do we need a test/documentation updates for this?
Quoted 26 lines
Signed-off-by Vasily Titskiy <[email protected]>--- git-stash.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)git-stash.sh +1
-2@@ -116,7 +116,7 @@ create_stash () { git read-tree --index-output="$TMPindex" -m $i_tree && GIT_INDEX_FILE="$TMPindex" && export GIT_INDEX_FILE && - git diff --name-only -z HEAD -- >"$TMP-stagenames" && + git diff --name-only --ignore-submodules -z HEAD -- >"$TMP-stagenames" && git update-index -z --add --remove --stdin <"$TMP-stagenames" && git write-tree && rm -f "$TMPindex" --2.1.4
--
To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Stefan,
Quoted 5 lines · Stefan Beller
Quoted 1 line · Vasily Titskiy
Do not save states of submodules as stash should ignore it.
Can you explain why this is a good idea?
(It is not obvious to me either way.)
Actually, submodules are already ignored by stash, but not fully (it was introduced in commit 6848d58). Current behavior is counter-intuitive, for example (if one has a project with a submodule):
$ cd sub1 $ edit .. commit .. edit .. commit. Alternatively, just checkout some other commit $ cd .. # back to main project $ git stash save No local changes to save $ # so, stash declares there are no changes $ edit main.cpp $ # For example, I need to update my working tree to latest master $ git stash save # save local changes of 'main.cpp'... $ git pull --recurse-submodules && git submodule update --recursive # update to latest $ git stash pop # I expect to get stashed changes for 'main.cpp', but... warning: Failed to merge submodule sub1 (commits don't follow merge-base) Auto-merging sub1 CONFLICT (submodule): Merge conflict in sub1
So, this is the issue. Instead of getting my local changes, I got a conflict (and stash is not poped out). The root cause is the 'stash' command does not know how to deal with submodules, but currently it tries to save the state of submodules, and even tries to re-apply the state (and it fails of course). The proposed solution fixes this behaviour.
All internal tests work fine with the change.
Quoted 2 lines
Do we need a test/documentation updates for this?
I don't think so, 'stash' have never claimed submodule support.
Quoted 27 lines
Quoted 27 lines
Signed-off-by Vasily Titskiy <[email protected]>--- git-stash.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)git-stash.sh +1
-2@@ -116,7 +116,7 @@ create_stash () { git read-tree --index-output="$TMPindex" -m $i_tree && GIT_INDEX_FILE="$TMPindex" && export GIT_INDEX_FILE && - git diff --name-only -z HEAD -- >"$TMP-stagenames" && + git diff --name-only --ignore-submodules -z HEAD -- >"$TMP-stagenames" && git update-index -z --add --remove --stdin <"$TMP-stagenames" && git write-tree && rm -f "$TMPindex" --2.1.4
--
To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Quoted 25 lines · Vasily Titskiy
Hi Stefan,
Quoted 5 lines · Stefan Beller
Quoted 1 line · Vasily Titskiy
Do not save states of submodules as stash should ignore it.
Can you explain why this is a good idea?
(It is not obvious to me either way.)Actually, submodules are already ignored by stash, but not fully (it was introduced in commit 6848d58). Current behavior is counter-intuitive, for example (if one has a project with a submodule):
$ cd sub1 $ edit .. commit .. edit .. commit. Alternatively, just checkout some other commit $ cd .. # back to main project $ git stash save No local changes to save $ # so, stash declares there are no changes $ edit main.cpp $ # For example, I need to update my working tree to latest master $ git stash save # save local changes of 'main.cpp'... $ git pull --recurse-submodules && git submodule update --recursive # update to latest $ git stash pop # I expect to get stashed changes for 'main.cpp', but... warning: Failed to merge submodule sub1 (commits don't follow merge-base) Auto-merging sub1 CONFLICT (submodule): Merge conflict in sub1
Quoted 6 lines
So, this is the issue. Instead of getting my local changes, I got a conflict (and stash is not poped out). The root cause is the 'stash' command does not know how to deal with submodules, but currently it tries to save the state of submodules, and even tries to re-apply the state (and it fails of course). The proposed solution fixes this behaviour.
All internal tests work fine with the change.
I think you could take the example as above and make it into a test? Showing that this change actually fixes a bug.
Looking for a good place, I would have expected t/t3906-stash-submodule.sh would be a good place to put your code, but I am not sure how to properly integrate that test there.
Maybe we can put the test in t3903 instead?
Quoted 5 lines
Quoted 4 lines
Do we need a test/documentation updates for this?
I don't think so, 'stash' have never claimed submodule support.
But it also never explicitly claimed it doesn't support it.
Maybe we want to squash in something like
(with better wording):
Documentation/git-stash.txt +2 -0
@@ -41,6 +41,8 @@ the usual reflog syntax (e.g. `stash@{0}` is the most recently created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}` is also possible). +Stashing ignores submodule operations completely. + OPTIONS -------
Thanks,
Stefan
Quoted 28 lines
Quoted 28 lines
Quoted 28 lines
Signed-off-by Vasily Titskiy <[email protected]>--- git-stash.sh | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)git-stash.sh +1
-2@@ -116,7 +116,7 @@ create_stash () { git read-tree --index-output="$TMPindex" -m $i_tree && GIT_INDEX_FILE="$TMPindex" && export GIT_INDEX_FILE && - git diff --name-only -z HEAD -- >"$TMP-stagenames" && + git diff --name-only --ignore-submodules -z HEAD -- >"$TMP-stagenames" && git update-index -z --add --remove --stdin <"$TMP-stagenames" && git write-tree && rm -f "$TMPindex" --2.1.4
--
To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Hi Stefan,
Quoted 7 lines
Quoted 6 lines
So, this is the issue. Instead of getting my local changes, I got a conflict (and stash is not poped out). The root cause is the 'stash' command does not know how to deal with submodules, but currently it tries to save the state of submodules, and even tries to re-apply the state (and it fails of course). The proposed solution fixes this behaviour.
All internal tests work fine with the change.
Quoted 8 lines
I think you could take the example as above and make it into a test? Showing that this change actually fixes a bug.
Looking for a good place, I would have expected
t/t3906-stash-submodule.shwould be a good place to put your code, but I am not sure how to properly integrate that test there.Maybe we can put the test in t3903 instead?
t3903 is better, as t3906 creates its submodule with forced 'ignore' option. It's not a default parameter and it actually hides the issue. I'll send the patches soon.
Quoted 13 lines
Quoted 2 lines
Quoted 1 line
Do we need a test/documentation updates for this?
I don't think so, 'stash' have never claimed submodule support.
But it also never explicitly claimed it doesn't support it.
Maybe we want to squash in something like
(with better wording):Documentation/git-stash.txt +0
-0
Documentation/git-stash.txt the usual reflog syntax (e.g. `stash@{0}` is the most recently · line 47
Quoted 7 lines
Documentation/git-stash.txt +2
-0@@ -41,6 +41,8 @@ the usual reflog syntax (e.g. `stash@{0}` is the most recently created stash, `stash@{1}` is the one before it, `stash@{2.hours.ago}` is also possible). +Stashing ignores submodule operations completely. + OPTIONS -------
Looks perfect to me.
--
Vasily
Hi Vasily,
Quoted 12 lines · Vasily Titskiy
Quoted 5 lines · Stefan Beller
Quoted 1 line · Vasily Titskiy
Do not save states of submodules as stash should ignore it.
Can you explain why this is a good idea?
(It is not obvious to me either way.)Actually, submodules are already ignored by stash, but not fully (it was introduced in commit 6848d58).
Current behavior is counter-intuitive, for example (if one has a project with a submodule):
[...]
Quoted 6 lines
So, this is the issue. Instead of getting my local changes, I got a conflict (and stash is not poped out). The root cause is the 'stash' command does not know how to deal with submodules, but currently it tries to save the state of submodules, and even tries to re-apply the state (and it fails of course). The proposed solution fixes this behaviour.
Please make it a habit to put such information into the commit message. I have to admit that I was as puzzled as Stefan by the proposed patch. Such problems, and tedious back-and-forth discussion, can be easily avoided by providing additional background in the commit message. We even ask in our Documentation/SubmittingPatches explicitly to do that:
Quoted 9 lines
The body should provide a meaningful commit message, which:
. explains the problem the change tries to solve, iow, what is wrong
with the current code without the change.. justifies the way the change solves the problem, iow, why the
result with the change is better.. alternate solutions considered but discarded, if any.
BTW this is not something we ask to make contributors' lives harder. In fact it helps everybody, including the contributors themselves. Just imagine what kind of kick-ass commit message you would want to read in six months when you stumble over your very own commit and want to know what the heck it was about.
Ciao,
Johannes