git-ls-files --unmerged implies --stages: ?

git-ls-files --unmerged implies --stages: ?

[Matthias Urlichs]

Hi,

I wonder why git-ls-files --unmerged implies --stages. One nice use case
for this command is to edit all the conflicting files after a failed
merge, i.e.

$ vi $(git-ls-files --unmerged)

except I need a pipe to throw out all the cruft in there.

Does anybody depend on that implication, or do I need to add a "no-stages"
option, or am I blind and there's a better way to do this?

-- 
Matthias Urlichs

Re: git-ls-files --unmerged implies --stages: ?

[Junio C Hamano]

Matthias Urlichs <smurf@smurf.noris.de> writes:

> I wonder why git-ls-files --unmerged implies --stages. One nice use case
> for this command is to edit all the conflicting files after a failed
> merge, i.e.
>
> $ vi $(git-ls-files --unmerged)
>
> except I need a pipe to throw out all the cruft in there.

I typically use git diff --name-only for this (yes I probably
need to uniq them out), but you can certainly talk me into
introducing --unmerged --name-only.  If nobody objects, even
making --unmerged independent from --stages might be a sensible
thing to do -- if we do so you would need --unmerged --stages to
get the current behaviour.