Feature requests and suggestions

[ganapativs]

Feature requests and suggestions

[benawad]

We are using git mv, so I think that should prevent any merge conflicts related to the file being moved/renamed. Haven't tested that yet though, so not 100% sure.

[waynevanson]

Love what you have here.

My two cents on watch mode: I feel like this package should be part of a git workflow and not watch mode at all.

I would personally use this package only after my tree is clean and I'm about to push. Similar to how yarn publish will auto commit the bump of a version number in package.json.

Config files are gross, but what other options are there? We could just put them inline as CLI args in package.json. So destiny --arg-one value --arg-2-as-boolean

[sQVe]

@waynevanson I agree and think one of the major issues we need to solve is how to use destiny in a project using git or any other version control solution. Moving and renaming files can be such a hassle for merge conflicts.

I do not really envision destiny to be a tool that should run automatically but rather a tool that you run at specific times when you and your team members are all in sync.

[waynevanson]

@sQVe I just added to my comment if you'd like to see more.

Moving and renaming files can be such a hassle for merge conflicts.

Yeah that looks like a huge pain. I wonder what will be the solution.

In teams, it would be harder to use on an automatic basis. I agree with you.

[ganapativs]

We are using git mv, so I think that should prevent any merge conflicts related to the file being moved/renamed. Haven't tested that yet though, so not 100% sure.

There will be conflicts if the team/individual use squash and merge when merging. This should be added to FAQ probably.

Watch mode?

Also, I completely agree that probably there should not be a watch mode. Watch mode complicates things a lot and might not really be useful in most of the cases.

[benawad]

@ganapativs What would be the sequence of steps to replicate the conflict? Are you thinking:
User 1 git move a file
User 2 make a change in that file then squash, then pull User 1 changes

[ganapativs]

This probably should work(Needs testing)

User 1 git moves the file(say in fresh branch-1 from the master)
User 2 edits the same file(in fresh branch-2 from the master, may be just editing the imports in the
same file should work)
User 2 squashes and merges his changes to master
User 1 takes the pull(should probably get the conflict as User 2 changes history is lost when squashed)

Optionally, User 2 should get conflicts if User 1 changes are squashed and merged first.

This happened to me many times in large PRs, I expect it to happen here also.

[sQVe]

@ganapativs Squashing is not relevant in your example. Squashing problems will occur when you branch from a commit that later in time gets squashes - for example a feature branch that is based on another feature branch. What your example is explaining is just a simple merge conflict due to two parts changing the same thing. This is nothing that we'll be able to solve and will have to be handled manually.

What we do is make the merge conflicts easier by marking moved files as moved in Git.