Hi Philippe, > You may, but I might not answer, or even receive your email. It is always > a better idea to write to the mailing list, and CC people that you want to > be made aware of your message :) I was fighting inside my company to get people to realize how most of the programmers try to stay away from git. They still work with our old versioning system. And only clone a git workspace right before committing. It's a bit sad. But all our git-experts kept telling me I was wrong. They expect everyone to become a git-expert from day 1. > > 6) PROBLEM: the stash is not automatically popped. > Yes, that's the correct behaviour. If there are conflicts in the rebase, we do not apply the stash, > since it could make the situation even worse if the modifications in the stash also conflict with > the same lines as the rebase conflict. That fact, I realize, is missing from the documentation [1]. Maybe when there are problems with the rebase. But not when applying the stash back to your workspace. I've tried 2.34, and there git works exactly like I expect! Even if there are conflicts with the stash, they get applied (with the <<<< and >>>>). > So, the stash does not apply automatically, there are conflicts. As noted in [2], this is > the correct behaviour for 'git stash drop' [2]. OK. It's fine that when there are conflicts the stash is applied and then kept. But what happened before 2.34 was that the stash wasn't even applied. Now it is. So my problem is solved. > What you describe is working as it should, I think. Well, it changed in 2.34 to behaviour that I expect. I've had some discussion with our internal git-experts. And they all told me different things. And when I asked very explicit things, like "what is the correct behaviour", they all admitted that they didn't know. :) No problem, but it drove me a bit mad. That's why I wanted to ask someone outside my company. But now I have the answer. I was not crazy. And what I expect (apply the stash, even when there are conflicts), is what should have happened. > > Is this related to the issue you point out on the git mailing-list? > No, I was describing a case where the stash should have been applied automatically, > but it was not. This bug was fixed in Git 2.33.0 [3]. Understood. The behaviour was changed again in 2.34. > As I wrote above, the behaviour you are seeing is not a bug. When applying the stash would fail > due to conflicts, Git tells you about it: > > Applying autostash resulted in conflicts. > Your changes are safe in the stash. > You can run "git stash pop" or "git stash drop" at any time. > > So it's up to you to remember to do it :) Yep. But in 2.34 that changed again. Now the stash always gets applied. > If you want to have an "always-on" reminder that you have something stashed, you could use > 'git-prompt.sh' [4], and set GIT_PS1_SHOWSTASHSTATE in your shell environment [5]. Thanks for the suggestion, I'll have a look at that. > > So my question again: "is git rebase --autostash" supposed to always pop the stash or not? > > If it is, is the current git behaviour a bug? > > It's not, not when the rebase has conflicts, or when applying the stash results in conflicts. Well, in 2.34, git thinks differently. :) Anyway, thanks very much for your reply. In 2.34, git behaves like I want. This is behaviour I can tell my colleagues about (the ones who are not git-experts, like me). "git fetch && git rebase --autostash" is now an easy and reliable way to update our workspaces. That's all we need. I'm happy. Have a nice day, henk.
