rebase hint unmerged file removed

rebase hint unmerged file removed

[bill lam]

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?

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3

Re: rebase hint unmerged file removed

[Jeff King]

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

> 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?

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

Re: rebase hint unmerged file removed

[bill lam]

On Mon, 24 Aug 2009, Jeff King 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,

Thanks, Jeff, Johannes,

I'll wait to see.

-- 
regards,
====================================================
GPG key 1024D/4434BAB3 2008-08-24
gpg --keyserver subkeys.pgp.net --recv-keys 4434BAB3

Re: rebase hint unmerged file removed

[Johannes Sixt]

bill lam schrieb:
> 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?

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

Re: rebase hint unmerged file removed

[Johannes Sixt]

Johannes Sixt 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.

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

Re: rebase hint unmerged file removed

[Miklos Vajna]

[-- Attachment #1: Type: text/plain, Size: 1282 bytes --]

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

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

[-- Attachment #2: Type: application/pgp-signature, Size: 197 bytes --]