Menu
In a .NET C# project which uses GIT for source control, I keep getting malformed csproj files after rebasing to get the most recently commited code. This is my process:
Here's the output on the rebase:
D:\GitHub\AwesomeProject>git rebase master
First, rewinding head to replay your work on top of it...
Applying: added getstatus call
Using index info to reconstruct a base tree...
M Host/Host.csproj
M Host/packages.config
M Trees/Trees.csproj
M Trees/packages.config
M UnitTests/UnitTests.csproj
<stdin>:1229: trailing whitespace.
<!-- To modify your build process, add your task inside one of the targets bel
ow and uncomment it.
warning: 1 line adds whitespace errors.
Falling back to patching base and 3-way merge...
Auto-merging UnitTests/UnitTests.csproj
Auto-merging Trees/packages.config
CONFLICT (content): Merge conflict in Trees/packages.config
Auto-merging Trees/Trees.csproj
Auto-merging Host/packages.config
CONFLICT (content): Merge conflict in Host/packages.config
Auto-merging Host/Host.csproj
Failed to merge in the changes.
Patch failed at 0001 added getstatus call
When you have resolved this problem run "git rebase --continue".
If you would prefer to skip this patch, instead run "git rebase --skip".
To check out the original branch and stop rebasing run "git rebase --abort".
There are conflicts, but as you can see it auto-merged the csproj files, and it did it incorrectly!! The XML of the csprojfile is not valid and the project doesn't load. Here's a stripped down verstion of what it looks like:
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
... most of one version the project file
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
<?xml version="1.0" encoding="utf-8"?>
<Project ToolsVersion="4.0" DefaultTargets="Build" xmlns="http://schemas.microsoft.com/developer/msbuild/2003">
... most of the other version the project file
<Import Project="$(SolutionDir)\.nuget\nuget.targets" />
</Project>
Why is this happening? And how can I improve my process to deal with it?
276
The golden rule of git rebase is to never use it on public branches. The rebase moves all of the commits in main onto the tip of feature . The problem is that this only happened in your repository. All of the other developers are still working with the original main .
Rebasing can be dangerous! Rewriting history of shared branches is prone to team work breakage. This can be mitigated by doing the rebase/squash on a copy of the feature branch, but rebase carries the implication that competence and carefulness must be employed.
After issuing git rebase --continue , a commit is made, you will have to inspect that commit. Or, you can issue git status before issuing git rebase --continue to see all those files. But after you've rebased, they're now part of the repository history.
After starting a rebase, Git creates an anonymous branch and starts applying commits to it. Since ours means "keep changes from the current branch", that current branch will be HEAD , which contains upstream and any changes already applied by rebase .
You may want to use a .gitattributes file to use a slightly different merge driver. I have found that this has helped with mine:
*.csproj -text merge=union
*.sln -text merge=union
You can read more about it here to see if there are options you like better.
You can also tell git to take a little longer thinking about its merges with the patience option like this: (read more here)
git rebase -s recursive -X patience
The only other thing that I can think of is to make sure that you pull code often so that the merges git has to do are smaller.
FYI, if you want you can do a rebase on the same line at the same time that you do a pull like this: (and you can still pass in the recursive and patience options the same)
git pull --rebase origin master
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
