threads / discuss / 15685

status letters consistency in log and ls-files

Subject: status letters consistency in log and ls-files

## tl;dr

4 messages between Sep 26, 2008 and Sep 27, 2008.

replies: 3people: 2as markdown or json

Leo Razoumov· Sep 26, 2008, 18:28 UTC · lore

Hi Everyone, I am new yo git and there are few things I find quite odd. For example,

command "git log --name-status" uses the following letters to indicate file's status A -- Added B -- have had their pairing Broken C -- Copied D -- Deleted M -- Modified R -- Renamed T -- Type changed (mode, time stamp) U -- Unmerged X -- Unknown

At the same time command "git ls-files -v" use different letters to indicate the same H -- cached M -- unmerged R -- removed/deleted C -- modified/changed K -- to be killed ? -- other

So, depending on which of the commands above are used status "R" could mean either Renamed or Removed, "M" is either Modified or unMerged, "C" is either Copied or Changed.

Is it possible to make it consistent across related commands?
--Leo--
Jeff King· Sep 26, 2008, 22:45 UTC · re: Leo Razoumov · lore

Re: status letters consistency in log and ls-files

On Fri, Sep 26, 2008 at 02:28:50PM -0400, Leo Razoumov wrote:
Show 5 quoted lines
> So, depending on which of the commands above are used status "R" could
> mean either Renamed or Removed, "M" is either Modified or unMerged,
> "C" is either Copied or Changed.
> 
> Is it possible to make it consistent across related commands?

I think this is rooted in historical reasons. Unfortunately, I don't think it is possible to reconcile the two outputs at this point, as we would be breaking any scripts which use the tools.

Out of curiosity, is there a script you are writing or some workflow you have where you see the output of both? Or did you just notice this while exploring git?

I ask because there may be a way to alter your workflow to always use one tool.

-Peff
Leo Razoumov· Sep 27, 2008, 03:20 UTC · lore

Re: status letters consistency in log and ls-files

On 9/26/08, Jeff King <peff@peff.net> wrote:
Show 20 quoted lines
> On Fri, Sep 26, 2008 at 07:24:11PM -0400, Leo Razoumov wrote:
>
>  > Another script takes output of
>  >   git ls-files -v -c -d -m -o -k
>  > and for each file pulls together all the file status letters in one record.
>
>
> OK. I was thinking I could suggest just using "git diff" here instead.
>  E.g.,:
>
>   git diff --name-status
>
>  will show you the modified and deleted files. But since you are using
>  "-c" to show _all_ cached files, I think only ls-files can do that
>  (since diff is, obviously, about files with differences).
>
>  So I'm not sure there is a straight-forward solution short of
>  translating the status codes.
>
>  -Peff

Moreover, git diff would not show untracked files while git ls-files will include them and label '?'

--Leo--
Jeff King· Sep 27, 2008, 03:30 UTC · re: Leo Razoumov · lore

Re: status letters consistency in log and ls-files

On Fri, Sep 26, 2008 at 11:20:03PM -0400, Leo Razoumov wrote:
Show 8 quoted lines
> >   git diff --name-status
> >
> >  will show you the modified and deleted files. But since you are using
> >  "-c" to show _all_ cached files, I think only ls-files can do that
> >  (since diff is, obviously, about files with differences).
> 
> Moreover, git diff would not show untracked files while git ls-files
> will include them and label '?'

Yes, but that is somewhat simpler to fix, since we know that they cannot be part of the "git diff" output. That is, you can just append the "git ls-files -v -o" output. Actually, since cached files use the 'H' tag which doesn't conflict with git-diff, and since your goal was to combine the multiple output anyway, I wonder if something like this would make you happy:

  (
    git ls-files --exclude-standard -v -c -o &&
    git diff --name-status --cached
  ) |
  perl -e '
    my %h;
    while(<>) {
      chomp;
      my ($status, $name) = split / /, $_, 2;
      $h{$name} .= $status;
    }
    print "$h{$_} $_\n" foreach sort keys(%h);
  '
?

Personally, I find listing every cached file makes the output hard to read, since any modified ones will be lost in the noise. But that is what you said you wanted...

-Peff

← back to recent threads