# Git deletes files when rebasing an amended merge-commit.

2 messages from 2015-10-08 to 2015-10-08. Participants: Hans Weltar, Junio C Hamano.
Thread: https://gitlist.dev/t/40518

## Hans Weltar, 2015-10-08 12:56

Subject: Git deletes files when rebasing an amended merge-commit.
Message-ID: <CAJqY2NUHg-7ghiNA7m+Q36LPhgG6tC6QDg2BP6f52fvDv6uAWQ@mail.gmail.com>
URL: https://gitlist.dev/e/CAJqY2NUHg-7ghiNA7m%2BQ36LPhgG6tC6QDg2BP6f52fvDv6uAWQ%40mail.gmail.com

```
When you have a fast-forwardable merge commit, you can amend this
commit to hold additional changes.
When you now do a rebase, git will believe this merge-commit is
fast-forwardable, and will delete all amended changes.
I believe when you amend a merge-commit it should become non-fastforwardable.

As rebase often needs to be applied (eg rebase -i; pull --rebase) this
is a rather insidious way to loose files without warning.

Here's a small testcase that creates a ff merge commit holding files
f1, f2 and f3. When you execute the last rebase command, the f3 file
will disappear from the filesystem.

git init
touch f1; git add f1; git commit -m "add f1"
git checkout -b mybranch
touch f2; git add f2; git commit -m "add f2"
git checkout master
git merge mybranch --no-ff -m "Merge mybranch"
touch f3; git add f3
git commit --amend -m "Add f2 and f3" # Amend merge
git rebase HEAD^ # f3 will sneakily be deleted, breaking the build and
giving you CI duty :)

kind regards
Hans

```

## Junio C Hamano, 2015-10-08 16:06

Subject: Re: Git deletes files when rebasing an amended merge-commit.
Message-ID: <xmqqegh5s5u8.fsf@gitster.mtv.corp.google.com>
URL: https://gitlist.dev/e/xmqqegh5s5u8.fsf%40gitster.mtv.corp.google.com
In-Reply-To: <CAJqY2NUHg-7ghiNA7m+Q36LPhgG6tC6QDg2BP6f52fvDv6uAWQ@mail.gmail.com>

```
Hans Weltar <hansweltar@gmail.com> writes:

> When you have a fast-forwardable merge commit, you can amend this
> commit to hold additional changes.

The real issue may be that there is a difference between "you can"
and "it is a good idea to", though ;-)

I think the fast-forwardable-ness is a red herring in your example;
rebase by default replays the patches commit by commit to flatten
the history, and evil merges where your result does not match a
mechanical merge result will be lost, and that is true even if you
were dealing with a real merge.

I'd imagine that you would need something like

http://thread.gmane.org/gmane.comp.version-control.git/198125/focus=198516

where it proposes a mode of rebase that picks the change in the
first parent chain.

Thanks.

```