Re: Bogus error: Untracked working tree file '....' would be overwritten by merge. Aborting

On Wed, Nov 17, 2010 at 09:37, demerphq <demerphq@gmail.com> wrote:

I don't think it should be dismissed, but it's interesting to look forward a bit and think how clever we really want to be.

E.g. if I have a tracked file "tracked" in my repository and do:

    echo Uncommited >>tracked &&
    git rebase -i HEAD~3

We'll error out with:

    tracked: needs update
    Working tree is dirty

Although we could be smarter and scan HEAD~3..HEAD and figure out that none of them changes "tracked" and go ahead with the rebase.

But arguably it would be more user friendly in the long term to lead users in the direction of always having clean working trees before they do operations like these. E.g. that users would turn your original example into:

    git status &&                      # reports no changes / modified files
    git tag before-reset-and-merge &&  # for ease of getting back / safe from gc
    git reset --hard HEAD^ &&          # no untracked files with --hard
    git merge some-branch              # clean merge

In which case the user would be accustomed to a workflow where he's guaranteed not to lose data, because Git is always tracking it.

But maybe we should just allow users to be more clever, and try really hard to find out if they can be clever without screwing up their working tree.