Is your feature request related to a problem? Please describe.
Implement a mechanism which helps in resolving rename conflicts during rebase, where one of the branches changes some root subdirectory, and the rebased branch patches files inside of that directory.
Currently, if main branch moves backend/ to apps/backend/ and my feature branch has many commits modifying files in the original backend/ directory, a standard rebase often results in conflicts for every single commit where the source and target of files differ for base branch and rebased branch. Git's internal directory rename detection simply compares the two paths and doesn't understand that parent directory moves can "propagate" to every commit in the rebased feature branch.
This could be a very nice feature for core git itself, but it could be implemented in lazygit first for a demo to see if it is even viable.
I wrote a detailed question regarding the process on StackOverflow already.
The greates benefit of that would be a lot easier work related to housekeeping projects.
Describe the solution you'd like
A "Rebase with Directory Mapping" option. When a rebase starts and lazygit detects (or the user knows) that a directory present in the feature branch was moved in the upstream, it should allow providing a mapping (e.g., backend/ -> apps/backend/).
Lazygit could then automate a "patch-rewrite" workflow:
- Export the commits of the current branch as patches (
git format-patch).
- Perform a regex replacement on the patch headers (e.g.,
--- a/backend/ to --- a/apps/backend/) to align them with the new structure.
- Apply the modified patches onto the upstream branch using
git am.
This would ideally be an interactive prompt or a specific rebase mode that "pre-aligns" the patch paths before they hit the new tree.
Describe alternatives you've considered
- Manual
git mv: Moving the directory on the feature branch before rebasing. This is tedious and often results in conflicts anyway if the upstream also touched those files.
git rebase -X find-renames: This is the default and it doesn't handle parent path renames
- Custom Scripts: I have a WIP bash script that uses
sed to rewrite patch file headers (targeting diff --git, --- a/, +++ b/, and rename from/to lines), however it is pretty gnarly and doesn't yet work fully. I can implement a proof of concept tool and later submit it to the lazygit repo.
- Report that to git core repo — For the time being it looks like their development process is too much for me to get into with the mailing lists and all, so this may be the easiest place to contribute that functionality to.
Additional context
The core logic involves updating the patch headers while leaving the code hunks untouched. It would need to have several safeguards to make sure the renames are valid. For example all of the hunks we want to edit this way would have to have a common ancestor which is no higher in the file tree than the requested path.
Example transformation required:
- diff --git a/backend/file.js b/backend/file.js
- --- a/backend/file.js
- +++ b/backend/file.js
+ diff --git a/apps/backend/file.js b/apps/backend/file.js
+ --- a/apps/backend/file.js
+ +++ b/apps/backend/file.js
Is your feature request related to a problem? Please describe.
Implement a mechanism which helps in resolving rename conflicts during rebase, where one of the branches changes some root subdirectory, and the rebased branch patches files inside of that directory.
Currently, if
mainbranch movesbackend/toapps/backend/and myfeaturebranch has many commits modifying files in the originalbackend/directory, a standard rebase often results in conflicts for every single commit where the source and target of files differ for base branch and rebased branch. Git's internal directory rename detection simply compares the two paths and doesn't understand that parent directory moves can "propagate" to every commit in the rebased feature branch.This could be a very nice feature for core git itself, but it could be implemented in lazygit first for a demo to see if it is even viable.
I wrote a detailed question regarding the process on StackOverflow already.
The greates benefit of that would be a lot easier work related to housekeeping projects.
Describe the solution you'd like
A "Rebase with Directory Mapping" option. When a rebase starts and lazygit detects (or the user knows) that a directory present in the feature branch was moved in the upstream, it should allow providing a mapping (e.g.,
backend/->apps/backend/).Lazygit could then automate a "patch-rewrite" workflow:
git format-patch).--- a/backend/to--- a/apps/backend/) to align them with the new structure.git am.This would ideally be an interactive prompt or a specific rebase mode that "pre-aligns" the patch paths before they hit the new tree.
Describe alternatives you've considered
git mv: Moving the directory on the feature branch before rebasing. This is tedious and often results in conflicts anyway if the upstream also touched those files.git rebase -X find-renames: This is the default and it doesn't handle parent path renamessedto rewrite patch file headers (targetingdiff --git,--- a/,+++ b/, andrename from/tolines), however it is pretty gnarly and doesn't yet work fully. I can implement a proof of concept tool and later submit it to the lazygit repo.Additional context
The core logic involves updating the patch headers while leaving the code hunks untouched. It would need to have several safeguards to make sure the renames are valid. For example all of the hunks we want to edit this way would have to have a common ancestor which is no higher in the file tree than the requested path.
Example transformation required: