Re: conflict status

From: Jakub Narebski <jnareb@gmail.com>
Date: Aug 4, 2009, 07:19 UTC
Message-ID: <m34osoqc5p.fsf@localhost.localdomain>
In-Reply-To: <4F52523A-2CEA-4CD3-A094-A2627E2A4403@users.sourceforge.net>

Michael Wild <themiwi@users.sourceforge.net> writes:

Show 29 quoted lines

> On 3. Aug, 2009, at 20:35, Junio C Hamano wrote:
>> Thomas Rast <trast@student.ethz.ch> writes:
>>
>>> That only shows 'unmerged: foo' for me...
>>>
>>> The closest to porcelain I can get while still having all the
>>> information is
>>>
>>>  $ git ls-files -s foo
>>>  100644 e69de29bb2d1d6434b8b29ae775ad8c2e48c5391 1       foo
>>>  100644 d00491fd7e5bb6fa28c517a0bb32b8b506539d4d 2       foo
>>>
>>> In other words, not porcelain at all.
>>
>> "git ls-files -u" would be what you want.  It shows all the paths with
>> conflicts in the index, and omits paths without conflicts in the
>> index.
>>
>> And the object names allow you to inspect the individual stages.
>>
> 
> 
> I found out about that one too (by having a look at git-mergetool),
> and came up with the following quick hack (doesn't take any arguments/
> options, is very rough and slow for a large number of conflicts). For
> each unmerged file it displays the file name, prefixed with the local
> and remote state. Possible states are "c" for created, "m" for
> modified and "d" for deleted. Probably there are other cases I'm not
> aware of and require special handling.

If you don't need SHA-1s, why not use -t or -v option of git-ls-files, e.g.:

  $ git ls-files -v -u

-- 
Jakub Narebski
Poland
ShadeHawk on #git