[Bug] Fix removal of unstaged changes on branch change

[MercuricChloride]

I came across what I think to be a bug, or at the very least a non obvious interaction when using the git interface.

When a repository has unstaged changes, and we create a new branch, or switch to another branch, all unstaged changes are reverted.

While we can fix this by going into the code changes and reverting, I think the default functionality should be closer to how git normally works, which is that checking out a new branch should not remove unstaged changes, unless a force flag is passed.

This is the default behaviour of the morphic git interface in pharo as well.

Let me know what you think!

[hellerve]

Let’s add an example and then we’re good to go!

[hellerve]

While I’m not opposed to the changes in this file, they seem unrelated. I don’t necessarily think we need to remove them, but wanted to point them out.

[MercuricChloride]

Yeah, this actually was from a monkey patch that I added to my personal config. The bigger inlays match the styling of other dropdown menus. But we don't have to include it since it isn't relevant to the actual fix i'm changing.

[hellerve]

We can keep this in, it doesn’t really change the intent of the change.

[hellerve]

This seems to work well! Can we add an example for it? GtGitElementExamples>>#scripterOnExpandedElementWithEditedBranch could be a starting point for how it can be done.

If you need help or guidance, let me know!

[MercuricChloride]

So when adding the example, should I invoke this example in another example for using the changes?

So invoke self scripterOnExpandedElementWithEditedBranch, then checkout to a new branch to show the changes persist?

[hellerve]

Hello, apologies for the delayed answer. I think that’s the way to go, yes. Change the branch (with some changes), assert that the changes are still there.