How do I remove a tracked file from merge request

user_278910 0
Viewed 5031

I have committed and pushed some files to remote feature branch and created a merge request. I used

git commit -a -m "blah blah"
git push

So it pushed all the modified files. One of the files (which is an existing file in in the master) was not supposed to be pushed (like for e.g. executables). How do I remove this file from the merge request, so that when the MR is merged into master, the unwanted file is not merged (as if it was never there in the MR). I found this page mentioning the following commands

git rm {filename} --cached
git commit -m "[...]"
git push

I tried the commands, but do not see the file removed in the merge request in Gitlab. Is this the right way to do it?

Update1:

With the above commands, I could see the file mentioned as deleted in the above commit. But then when I merge the updated MR into master, the file is deleted from master too.

Update2:

Removed sentences causing confusion and updated the title

gitlab git
2 Answers

What version of Gitlab are you using?

Just tested with latest version (14.5.2):

git checkout -b feature-123
git add package.json package-lock.json
git commit -m 'Commit with extra file.'
git push --set-upstream origin feature-123

Created MR, it shows two files changed

Now, from the same branch:

git rm --cached package-lock.json
git commit -m 'Removing extra file.'
git push

MR now shows only one modified file.

But if this MR is accepted without squash, the git history will contain adding and removing an extra file.

If you have committed a very large file, it may be better to ask the maintainer to squash your changes before merging. Or delete MR and create a new one with a single commit.

user_8751760

Update: from the updated question we now know that you are trying to undo a modification you made to an already tracked file in the commit. Note your statement about .gitignore is misleading, since .gitignore is for untracked files. Once you are tracking it, you cannot ignore it by using the .gitignore file.

One way to achieve your goal is to simply undo the change to the file. If the most recent commit on your branch is the one you need to change, then just amend it. If it isn't, then create a new commit with your change which undoes the previous change, and then interactive rebase your branch and squash this new commit into the previous one. This is described in more detail here. If you've never used it, interactive rebase is a fantastic feature of Git, which I recommend everyone learn, even though it is a little daunting at first.

Original Answer (mostly geared towards how to undo a newly added file, which is no longer relevant after the question update):

A Merge Request (also called a Pull Request in other SCM tools) is a formal way to code review and merge changes from a source branch (yours) into a target branch (usually a shared branch such as main, master, develop, etc.)

Given that, there are multiple ways to remove a file from a Merge Request, such as:

  1. As you proposed, you can add a new commit to your source branch which effectively undoes the changes to the files you no longer wish to include. This could mean undoing the changes to existing tracked files, or deleting untracked files. The downside of adding an additional commit to remove the file(s), as pointed out in xy2's answer, is unless you squash when you complete the MR, the unwanted files will remain in the history.
  2. Typically the better way is to remove the file from the commit(s) that contained them. This is described in great detail in this question: Remove files from Git commit. After re-writing the commits on your local branch to no longer include the files you wish to remove, you will need to force push your branch again: git push --force-with-lease. (Note --force-with-lease is usually a good default to use over --force.) After pushing your branch your MR should be automatically updated with the latest version of your branch which excludes the files.

Side Note: Even though I would personally lean towards option #2, your described attempt at option #1 should have worked, conceptually. I suspect you didn't do exactly what you think you did to your branch.

user_1845460
Related