Merge conflicts in fsproj files #2297
Comments
|
We tried to that. It broke vs auto restore
Am 27.04.2017 7:49 nachm. schrieb "Matthias Dittrich" <
[email protected]>:
… In my FAKE branch I'm in the sad position that I need to merge back and
forth. And one thing slowly driving me insane are the merge conflicts in
the automatically generated choose nodes in the fsproj files.
We should have extracted them into target files from the beginning. This
way I could ignore them on merge conflicts (or gitignore them when paket
creates them on restore).
Is Visual Studio supporting that currently?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2297>, or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADgNJAtIO2cmrin6tO8u4MDS33wbTTHks5r0NU6gaJpZM4NKjZu>
.
|
|
We always knew there was a price when doing it this way. But I feel like the price is just too high now with netstandard and all those small libraries.
The promise of paket was always that we solve/review conflicts in paket.lock file, but we actually need to review every file now (fsproj, app.config, and sometimes even code...) Maybe we should just push the ecosystem into the new netcore world and find a nice integration path there and use that for full net compilation as fast as possible... |
|
They are rolling this madness back. In vnext there won't be many small
packages anymore
Am 27.04.2017 20:38 schrieb "Matthias Dittrich" <[email protected]>:
… We always knew there was a price when doing it this way. But I feel like
the price is just too high now with netstandard and all those small
libraries.
- Diffs are never usable when doing any paket commands
- Merging has become way too complicated now
- Paket is no longer (I feel like it stopped a long time ago)
delivering on the promise of "stable files"
The promise of paket was always that we solve/review conflicts in
paket.lock file, but we actually need to review every file now (fsproj,
app.config, and sometimes even code...)
It really has a hard time at the moment :/. Sorry its just my frustration
speaking right now ...
Maybe we should just push the ecosystem into the new netcore world and
find a nice integration path there and use that for full net compilation as
fast as possible...
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#2297 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AADgNI61judDqobfNCtMWF46vATJbjgnks5r0OCWgaJpZM4NKjZu>
.
|
|
What do you think about adding something similar like #2234 to the assembly references? That means in most cases, a big choose block is replaced with a single Reference. |
|
@0x53A to be really honest I don't think it would improve much. First we introduce another set of large changes and second we still have more than enough lines (lets say we can improve from 5000 to 1000 lines that's already quite a lot, but it doesn't solve the problem here) |
|
@forki I thought we were told that the splitting as a separate file should have been possible? |
|
No that's only for MSBuild 15 - and there we load it in memory. |
|
Previous attempt: #447 |
In my FAKE branch I'm in the sad position that I need to merge back and forth. And one thing slowly driving me insane are the merge conflicts in the automatically generated choose nodes in the
fsprojfiles.We should have extracted them into target files from the beginning. This way I could ignore them on merge conflicts (or gitignore them when paket creates them on restore).
Is Visual Studio supporting that currently?
The text was updated successfully, but these errors were encountered: