rebase hint unmerged file removed

Sometimes during rebase -i, it stopped with an unmerged file but that file did not have any sections of conflict marked. ls-files showed it had :1: and :2: but no :3: I suspected that file was git-rm in that commit. Will it be possible for git status or rebase to give hint that unmerged file was actually removed?

On Mon, Aug 24, 2009 at 10:05:49PM +0800, bill lam wrote:

The version of "git status" in next (and presumably what will be in v1.6.5) shows unmerged paths with more information. In this case, you would see something like:

  $ echo content >foo && git add foo && git commit -m 'base foo'
  $ echo changes >>foo && git add foo && git commit -m 'change foo'
  $ git checkout -b other HEAD^
  $ git rm foo && git commit -m 'remove foo'
  $ git rebase master
  $ git status
  # Unmerged paths:
  #   (use "git reset HEAD <file>..." to unstage)
  #   (use "git add <file>..." to mark resolution)
  #
  #       deleted by them:    foo
  #

-Peff

On Mon, 24 Aug 2009, Jeff King wrote:

Thanks, Jeff, Johannes,

I'll wait to see.

bill lam schrieb:

Rebase -i emitted used to write merge-recursive's conflict hints that said "modify/delete", "modify/rename", "content", etc. I think that's what you were looking for. But these hints have vanished since quite some time now. I haven't taken the time, yet, to track down when this happened and why.

-- Hannes

Johannes Sixt schrieb:

Ok, I bisected it to 6eb1b437 (cherry-pick/revert: make direct internal call to merge_tree(), 2008-09-02), which is part of a series around merge-recursive: 1ad6d46..ed520a8

The commit message says: "One regression is that the status message is lost as there is no way to flush them from outside the refactored library code yet." But is it intentional that these messages were never recovered?

BTW, I miss the messages a lot, too, but I'm unfamiliar with the code in question to try to do something about it.

-- Hannes

On Tue, Aug 25, 2009 at 09:35:49AM +0200, Johannes Sixt <j.sixt@viscovery.net> wrote:

I do not remember too much about this. The point of the commit was to avoid fork()ing a new merge-recursive process, that's for sure. I tried to search back the archive to see what was the interdiff between my patch and Junio's fixup, but I haven't found my patch.

I think it's possible that I was not aware of this limitation at all and just Junio added it as a note to the commit message, but I'm not 100% sure.

I also think that it's possible to modify the library code to be able to flush the status message outside the library, but I can't really send a patch that implements this right now, due to lack of time.

Sorry,

Miklos