Please follow CONTRIBUTING.md and manual#submitting-changes-making-patches and squash the fix-up commits.

This can be done without git rebase -i by doing:

git reset HEAD~1                    # move fix-up commits into unstaged
git add -- pkgs/                    # move changes into staged
git commit --amend --no-edit        # add changes to previous commit
git push ... ... --force            # modify current PR branch

However, git rebase -i is a more powerful alternative, I created a small video demonstrating it's use here. A more indepth text tutorial can be found here

Please follow CONTRIBUTING.md and manual#submitting-changes-making-patches and squash the fix-up commits.

This can be done without git rebase -i by doing:

git reset HEAD~1                    # move fix-up commits into unstaged
git add -- pkgs/                    # move changes into staged
git commit --amend --no-edit        # add changes to previous commit
git push ... ... --force            # modify current PR branch

However, git rebase -i is a more powerful alternative, I created a small video demonstrating it's use here. A more indepth text tutorial can be found here

Done.

I was not aware of which was the proper procedure for nixpkgs. Some projects prefer to keep the commits separate while reviewing and squashing them during the merge.

I was not aware of which was the proper procedure for nixpkgs. Some projects prefer to keep the commits separate while reviewing and squashing them during the merge.

In general, you can think of it as, "If there was a regression, can we use git bisect to pinpoint it without too much trouble?".

I was not aware of which was the proper procedure for nixpkgs. Some projects prefer to keep the commits separate while reviewing and squashing them during the merge.

In general, you can think of it as, "If there was a regression, can we use git bisect to pinpoint it without too much trouble?".

I was referring to using the github feature to do the squash when you merge, which means that the commits can be kept separate while reviewing, but appearing as a single commit when pushed to master. This way git bisect will still work as expected.

ah, when the PR only has 1 commit, sure that can be used. But often PRs have many significant commits that shouldn't be squashed.

Also it puts the burden of git history of the committer.