TL;DR: When got merge can fast-forward, should it still check for local
changes / staged files? got rebase does.


Consider the following short history from newest to oldest:

o [main] Another commit
|
o [br] A commit

If you do the following:

1. got update -b main
2. echo 'some new text' >> ./some_tracked_file
3. got rebase br

got will complain:

	got: work tree contains local changes; these changes must be committed or reverted first

Arguably, "got rebase" could have proceeded anyway, since there's
nothing to do except update a reference.

I have some WIP* on making "got merge" fast-forward when possible. My
question is, should "got merge" be as strict as "got rebase" is in the
fast-forwarding case?

One argument for refusing is that fast-forwarding when there are local
changes could cause confusion. If there are conflicts updating the
changed files, you get a message like:

	Files with new merge conflicts: 1

This seems potentially confusing, since the word "merge" refers both to
the process of creating a merge commit and the process of reconciling
changes.

On the other hand, skipping the check could save a bit of time for users
who know what they're doing.

I don't know which I prefer. Leaning toward refusing, like got rebase
does.

(Returning to the rebase example, note that if you try to rebase "main"
onto "br" instead, the check gets skipped; that feels a tiny bit
inconsistent.)

*The WIP is just new tests and an update to the man page. No code
changes yet. Happy to share what I have.

-- 
James