How can I copy my old commits to new commits that achieve the same result, after someone backed out all my work?

Question

Supplementary question with: Git merge removed the latest code after merging the origin branch

Branch: feature-1
You can see there are many commits in it.
But when I generate a merge request, it doesn't show my all commits. Basically doesn't display commits before 13th Sept in Merge Request commits tab.
So in which case the above will happen, there are other devs who are also working in the same branch due to the same functionality if that matters.

Side question: Doesn't GitLab checks all files difference during MR (Merge request)? Or just shows the diff. of files which in commit list?

Update

22159e61

b0204dee

Answer 1

Based on the discussion in the comments, it seems that your earlier commits were already merged. It's just the case that the person who made that merge undid your changes.

What this means is simple: you cannot use the original commits any more. They're already in the repository, followed by a subsequent commit that undid your work. You must now redo your work in new commits.

In other words, I think the question is now "How can I copy my old commits to new commits that achieve the same result, after someone backed out all my work?" That makes this a question about Git, rather than about GitLab.

Fortunately, it's easy to do, using either git cherry pick—this is the manual method—or git rebase, which automates cherry-picking. It's probably easier with git cherry-pick, even though this is the manual method, because git rebase itself is too clever. It may, depending on circumstances and invocation, notice that the commits are already there, and thus choose not to copy them.

So, let's look at how you copy commits that someone wrecked and then undid. Note that we do not do this in some fancy GUI, or in a web browser. We need command line Git, preferably with a sensible shell like bash, although it can be done in horrible CLIs like CMD.EXE. (I'm sure it can be done in PowerShell too, but PowerShell tends to be of the opinion that everything Microsoft does, like using UTF-16-LE, is good, and in fact that's not good. So I'll use bash and $ prompts here. Hah, I see TTT already made a similar comment. )

The first step is to figure out which commits you want to copy. You can use git log, e.g.:

$ git log --all --decorate --oneline --graph

or you can use any of the methods shown in Pretty Git branch graphs, but remember that the goal here is to get the commit hash IDs so that you can cut and paste them with your mouse, into a file.

Next, cut and paste each of the desired commit hash IDs into a file. Use whatever editor you prefer to create a simple text file, grab each hash ID (and perhaps the --oneline text here as well) and copy it to this file. Save the file, in case things go wrong or get interrupted.

Now, in another window—so that you can keep the editor open on this file—start up another shell and maneuver into the repository where you'll be working. Run git fetch to get your own repository up to date with the remote repository on GitLab. Then check out a new branch based on the remote's master or main or whatever branch you intend to merge into. (You might need to clean up any unfinished work first.) I'll assume you'll be merging into master here:

• git fetch: to fetch new commits from origin
• git status: to make sure everything is clean and ready to begin work
• git switch -c new-foo-feature-123 origin/master: to create a new branch named new-foo-feature-123 starting from the correct commit

Plug in a better name than new-foo-feature-123, of course.

Now, using the hash IDs saved in the other editor window, copy the hash ID of the first commit to copy. Then, in the bash window, type in:

$ git cherry-pick ☐

(note that there is a space after the word cherry-pick here; that's why the little box ☐ is there, to show the blank) and then paste in the hash ID from the editor window. If that hash ID is abc1234 you'll now have:

$ git cherry-pick abc1234

Press the RETURN or ENTER key to run this cherry-pick command now. If it succeeds, great! If it has a merge conflict, solve the merge conflict, add files as needed, and run git cherry-pick --continue to finish the operation. In any case, mark, in the editor window, that this commit is now done, once it's done—this keeps track of your progress.

Now cherry-pick the second commit to copy in exactly the same way. Mark the commit "done" in the editor window, once it's done.

Repeat for each commit you need to copy. When all commits are copied successfully, you now have a new branch you can use with git push:

git push origin new-foo-feature-123

(using your Better Branch Name of course).

You can now make a new merge request with the new branch. Close out the old one as superseded by the new one.