5 ms·

I would like a ui that can show me what conflicts are about to happen before I do a merge or rebase. Trying to resolve a conflict after it's already happened is

I would like a ui that can show me what conflicts are about to happen before I do a merge or rebase. Trying to resolve a conflict after it's already happened is much harder then if I knew what files and lines are about to blow up on me. Even better start warning me about which files I've been editing are going to conflict with origin once I eventually have to sync up

Izkata 4y ago
Merge and rebase both have "--abort", which undoes the change if you're in the middle of a conflict.
- seanalltogether 4y ago
  To be clear, I'd like to see the future conflict while my files remain in a clean state, so that I reconsider my own changes or work around the conflict before it happens
  - krupan 4y ago
    After you do --abort you are back in time before the conflict happened. This is literally what you are asking for
okl 4y ago
You can abort a merge or rebase with `git merge --abort` and `git rebase --abort` respectively.
arxanas 4y ago
Yep, most tools are deficient in this area, as per the table. My linked git-branchless tool will tell you before a merge conflict occurs, so that you don't have to abort it, although it could produce more information about the impending merge conflict.
aequitas 4y ago
This is one of those cases where the solution seems difficult, but the difficulty is in the problem itself, not the solution. The source of the conflicts is the fact that you work with multiple people, in a distributed way on the same codebase. Those conflicts are going to arise one way or another. Git could tell them to you beforehand, but that would be just the same as rebasing and then aborting. The conflicts stay the same, no matter how you slice them. In my experience best is to coordinate with other about code changes to avoid conflicts altogether or to fetch and rebase often to keep conflict scope to a minimum so they are more manageable. Also keeping commits focussed on single features/changes instead of spreading out the feature over multiple work in progress like commits so they can be applied as a standalone change helps. I really learned this when working in Gerrit Review for a while. Where there is no one pull request for a branch full of commits, but each commit is a change applied to master on its own and has to be reviewed/tested as such. Git is not a magical tool that solves all collaborative coding problems, but more a toolset that helps you manages code changes. You definitely need to put some effort into the mental model of how to manage changes before you can use the toolkit to its full potential.
brunobrito 4y ago
Tower offers an "Instant Conflict Detection" feature that should be right up your alley (I work at Tower, a Git client for Mac and Windows). It will let you know in advance if conflicts will occur when merging another branch or revision (by merging, rebasing, or pulling). Here's an example: https://imgur.com/a/VCkqrBI https://imgur.com/a/VCkqrBI You can learn more about Tower's Merge Improvements here https://www.git-tower.com/blog/tower-mac-9/#1-merge-improvements https://www.git-tower.com/blog/tower-mac-9/#1-merge-improvem... I hope you give Tower a try!

Izkata 4y ago

Merge and rebase both have "--abort", which undoes the change if you're in the middle of a conflict.

seanalltogether 4y ago
To be clear, I'd like to see the future conflict while my files remain in a clean state, so that I reconsider my own changes or work around the conflict before it happens
- krupan 4y ago
  After you do --abort you are back in time before the conflict happened. This is literally what you are asking for

okl 4y ago

You can abort a merge or rebase with `git merge --abort` and `git rebase --abort` respectively.

arxanas 4y ago

Yep, most tools are deficient in this area, as per the table. My linked git-branchless tool will tell you before a merge conflict occurs, so that you don't have to abort it, although it could produce more information about the impending merge conflict.

aequitas 4y ago

This is one of those cases where the solution seems difficult, but the difficulty is in the problem itself, not the solution. The source of the conflicts is the fact that you work with multiple people, in a distributed way on the same codebase. Those conflicts are going to arise one way or another. Git could tell them to you beforehand, but that would be just the same as rebasing and then aborting. The conflicts stay the same, no matter how you slice them. In my experience best is to coordinate with other about code changes to avoid conflicts altogether or to fetch and rebase often to keep conflict scope to a minimum so they are more manageable. Also keeping commits focussed on single features/changes instead of spreading out the feature over multiple work in progress like commits so they can be applied as a standalone change helps. I really learned this when working in Gerrit Review for a while. Where there is no one pull request for a branch full of commits, but each commit is a change applied to master on its own and has to be reviewed/tested as such. Git is not a magical tool that solves all collaborative coding problems, but more a toolset that helps you manages code changes. You definitely need to put some effort into the mental model of how to manage changes before you can use the toolkit to its full potential.

brunobrito 4y ago

Tower offers an "Instant Conflict Detection" feature that should be right up your alley (I work at Tower, a Git client for Mac and Windows). It will let you know in advance if conflicts will occur when merging another branch or revision (by merging, rebasing, or pulling). Here's an example: https://imgur.com/a/VCkqrBI https://imgur.com/a/VCkqrBI You can learn more about Tower's Merge Improvements here https://www.git-tower.com/blog/tower-mac-9/#1-merge-improvements https://www.git-tower.com/blog/tower-mac-9/#1-merge-improvem... I hope you give Tower a try!