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

Matthias Urlichs· Mar 9, 2006, 15:19 UTC · lore

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

Junio C Hamano· Mar 9, 2006, 18:50 UTC · re: Matthias Urlichs · lore

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

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

Show 7 quoted lines

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