[go: up one dir, main page]

Skip to content

Allow web IDE / suggested changes to amend existing commits

Everyone can contribute. Help move this issue forward while earning points, leveling up and collecting rewards.

Release notes

When adding changes through the web IDE or by accepting suggested changes, the user can choose to amend an existing commit in the MR instead of creating a new one.

Problem to solve

As a developer I want to be able to amend existing commits in the web IDE, in order to keep my commits atomic.

Intended users

Developers

User experience goal

Many developers work with atomic commits, which is to say they keep changes related to each other in the same, small commit (as opposed to checkpoint commits, creating new commits any time they've changed code). For more information as to why people keep their commits atomic as a best practice, please see the linked blog post.

Currently, when a suggested change is accepted or when a change is made in the web IDE, it's only possible to create a new commit with these changes. However, it's likely that a developer working with atomic commits will want to amend the appropriate commits in the MR instead. For that reason there's not much use for the suggested changes/web IDE features for developers using atomic commits.

Proposal

  • A user accepts suggested changes, or decides to commit changes they made in the web IDE
  • They're offered a list of commits in their MR
  • User chooses one of these commits
  • The changes are added to that commit, as opposed to a new commit being created.

Further details

This would be a typical workflow for someone working with atomic commits:

  • Dev 1 starts fixing a bug,
  • Fixes the bug and writes a test,
  • Creates a commit "fix bug X",
  • Sees a bloated method and extracts it
  • Creates a separate commit "extract bloated method",
  • Creates MR.
  • Dev 2 notices a missing test case, requests changes
  • Dev 1 adds the test case,
  • Adds it to the commit "fix bug X", instead of creating a new commit.

This results in only 2 commits, with appropriate commit message and all the changes appropriately committed together. Were Dev 2 to write the missing test case in a suggested changes comment, there is no way for Dev 1 to add those changes to the appropriate commit.

Dev 1 would then have to:

  • Accept the changes
  • Fetch and pull the commit
  • Interactively rebase
  • Squash the new commit into the old one
  • Force push.

Allowing for the changes to be accepted directly into an existing commit would make it a more useful feature.

Permissions and Security

Permissions would mirror current permissions of the web IDE / accept suggested changes features.

Documentation

Availability & Testing

Available Tier

What does success look like, and how can we measure that?

What is the type of buyer?

Is this a cross-stage feature?

Links / references

Edited by 🤖 GitLab Bot 🤖