# git-ls-files --unmerged implies --stages: ? 2 messages from 2006-03-09 to 2006-03-09. Participants: Matthias Urlichs, Junio C Hamano. Thread: https://gitlist.dev/t/3611 ## Matthias Urlichs, 2006-03-09 15:19 Subject: git-ls-files --unmerged implies --stages: ? Message-ID: URL: https://gitlist.dev/e/pan.2006.03.09.15.19.03.286472%40smurf.noris.de ``` 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, 2006-03-09 18:50 Subject: Re: git-ls-files --unmerged implies --stages: ? Message-ID: <7vslpr4fll.fsf@assigned-by-dhcp.cox.net> URL: https://gitlist.dev/e/7vslpr4fll.fsf%40assigned-by-dhcp.cox.net In-Reply-To: ``` Matthias Urlichs 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. ```