CODEWITHSUNDEEP
git
superphonic
superphonic

Reputation: 8074

Keep unstaged changes excluding deletes?

Branch: Feature

I had quite a few changes and new functions created etc... I committed these changes and switched back to the Master branch

Branch: Master

Refreshed my IDE so the open files reverted back to those on the Master and then did some security fixes on master. I committed these changes and then switched back to the Feature Branch.

Branch: Feature

I DID NOT refresh my IDE to get the current state of files from the Feature branch, the files in my IDE were still as they were from Master. I then went happily ahead making a LOT more changes to these files and saving them. Obviously this deleted all the changes I made originally to the Feature branch.

I have not committed any of the changes I made in my second visit to the Feature branch, they are all unstaged, so if I do a diff on a file, I can see all the nice stuff I created in my first visit to the Feature branch deleted.

So what I would like is the changes I committed in the first visit to the feature branch, and the additions I made during my second visit merged together but without the deletes??!? If that makes sense.

I thought I might be able to commit these second lot of changes, and then merge the first commit on top(obviously with conflicts) to get both set of changes together that I can then manually fix? Is that possible?

Is there an obvious solution I am missing?

Upvotes: 1

Views: 31

Answers (1)

Mark Adelsberger
Mark Adelsberger

Reputation: 45679

I'm not sure how your tools are set up, or what procedure you're using to switch between branches, but when you say it's obvious that you lost the changes from your first visit to the feature branch, as a result of not "refreshing the IDE" on the second trip to feature branch... No, it's not. And if your tool setup and workflow are such that this is a thing that happens, I'd call that the root problem.

Now mostly that's a separate issue, so we should move on to the question of how to recover. But there's a problem: understanding why your tools behave as they do is key to working out a safe procedure to recover.

The normal way to change branches is to checkout the new branch. Assuming you have a clean working tree when you do this, your index and working tree should be updated to reflect the new branch. So to get the symptom you describe, either:

1) You're doing something different to switch branches, such that your working tree is not updated, OR

2) You have another working copy of the files in your IDE, apart from the git work tree

If you understand and can reliably reproduce the behavior of your IDE copy of the files staying unchanged when you switch branches, then you can fix this by

1) switching back to master

2) creating a new temporary branch at master

3) committing your changes

4) rebasing the temporary branch to feature

5) merging the temporary branch into feature

6) deleting the temporary branch

The point is, you have changes you want to capture, but they're relative to master. So commit them relative to master, then rebase them - which will (essentially) apply the same changes to feature as you had applied relative to master.

Upvotes: 1

Related Questions