Question - Git complaining about uncommitted changes

[Drallin]

The best answer is probably "be more lazy and use VV instead of building your own," but I'm apparently a bit masochistic and for now I'm pretending that doing stuff myself, at least for a while, is an achievement or something.

When I go to update after patches, git complains that I have uncommitted changes.

Is that because of copying in the .sln that includes plugins is a "new" file, or does copying my config files / macros into the build area? Something else during compile process?

Do people that compile their own usually run macroquest out of the build tree, or have a separate run directory with softlinks to the build tree to avoid upsetting git? I don't see discussion of this on the main macroquest site.

(Historically I've done a full pull and complete rebuild after patches... but that's a bit slow.)

 

[vx2s]

The best answer is probably "be more lazy and use VV instead of building your own," but I'm apparently a bit masochistic and for now I'm pretending that doing stuff myself, at least for a while, is an achievement or something.

Nothing wrong with challenging yourself and gaining some knowledge and experience .

When I go to update after patches, git complains that I have uncommitted changes.

Is that because of copying in the .sln that includes plugins is a "new" file, or does copying my config files / macros into the build area? Something else during compile process?

What problem are you having? git pull fails due to uncommitted changes?

Anything under the \build\ folder should be in .gitignore, so they shouldn't cause an issue.
If you modified the .sln, then yes, this is an uncommited change.

Not sure how familiar you are with git commands. I assume you've just done git pull in the past?

Git should tell you what has been modified. You can see this with

1. git status This will show a list of all files that have been modified (staged and unstaged)

Assuming you want to keep your modifications, you can

• git add . This will stage changes for commit
• git commit -m "Sln Changes" This will commit the changes to your local repository with a commit message of "Sln Changes"
• git pull --rebase This will pull the changes and rebase your changes onto the changes you pulled from remote

If there are no merge conflicts with the sln change, that should be enough.

if you don't want to keep your changes

• git reset --hard This will reset any local changes. Only use this if you are sure you don't want to keep your changes
• git pull --rebase Rebase may not be necessary. Depends on if you have any other local commits.

Do people that compile their own usually run macroquest out of the build tree, or have a separate run directory with softlinks to the build tree to avoid upsetting git? I don't see discussion of this on the main macroquest site.

I run it out of my repo folder. As mentioned, anything under \build\ will be ignored.
I also have .sln changes due to including a custom plugin within the solution.

(Historically I've done a full pull and complete rebuild after patches... but that's a bit slow.)

I just do the full build even though I don't use most of the plugins. It usually takes me less than 5 mins.

Hope this helps.

 

[brainiac]

The best answer is probably "be more lazy and use VV instead of building your own," but I'm apparently a bit masochistic and for now I'm pretending that doing stuff myself, at least for a while, is an achievement or something.

When I go to update after patches, git complains that I have uncommitted changes.

Is that because of copying in the .sln that includes plugins is a "new" file, or does copying my config files / macros into the build area? Something else during compile process?

Do people that compile their own usually run macroquest out of the build tree, or have a separate run directory with softlinks to the build tree to avoid upsetting git? I don't see discussion of this on the main macroquest site.

(Historically I've done a full pull and complete rebuild after patches... but that's a bit slow.)

Rename the .sln file to something else so that you're not modifying a file thats part of the git repository.

Its designed to be ran directly from the build folder.

 

[Sic]

Rename the .sln file to something else so that you're not modifying a file thats part of the git repository.

Its designed to be ran directly from the build folder.

This is exactly how I have my build sln