Git development
 help / color / mirror / Atom feed
From: Junio C Hamano <gitster@pobox.com>
To: "Torsten Bögershausen" <tboegi@web.de>
Cc: git@vger.kernel.org
Subject: Re: [PATCH] Add ls-files --eol-staged, --eol-worktree
Date: Sun, 18 Oct 2015 12:00:57 -0700	[thread overview]
Message-ID: <xmqq4mhoatna.fsf@gitster.mtv.corp.google.com> (raw)
In-Reply-To: <D68CC6D0-3FD5-4423-A9E2-905DF18E893F@web.de> ("Torsten Bögershausen"'s message of "Sat, 17 Oct 2015 22:18:06 +0200")

Torsten Bögershausen <tboegi@web.de> writes:

> Make it possible to show the line endings of files.
> Files which are staged and/or files in the working tree:
>
> git ls-files --eol-staged
> git ls-files --eol-worktree

Two unrelated (to the issues raised in other review responses)
issues in the UI:

 - While I can see how the new feature would be useful, I am not
   convinced that it is a good idea to add it to ls-files.  Does the
   option work well with other existing options like -s, -t, etc?
   Does it make sense to combine it with other options like -m, -d,
   etc?  I have this suspicion that "check-attr", "check-ignore",
   etc.  may give a better model that fits this feature better,
   i.e. "git check-eol".

 - When you have an operation that works on contents in the working
   tree, the established command line convention to alter the
   operation to work on contents in the index is with "--cached",
   and the operation by default would work on the contents in the
   working tee without "--worktree".  See gitcli(7).

   If I were doing this as part of "ls-files", I would add a new
   "--get-eol" option that inspects the working tree, and make
   "--get-eol --cached" do the same for the contents in the index,
   for consistency.  If I were doing "git check-eol", then the
   default mode of the operation would read from the working tree,
   and "git check-eol --cached" would read from the index.

   If the operation can work on both the contents in the index and
   in the working tree at the same time, we use "--index" instead of
   "--cached", but I do not think it applies here (only a small
   number of commands work on both to begin with, e.g. "apply").

  parent reply	other threads:[~2015-10-18 19:01 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-17 20:18 [PATCH] Add ls-files --eol-staged, --eol-worktree Torsten Bögershausen
2015-10-18  1:10 ` Eric Sunshine
2015-10-18 10:03 ` Philip Oakley
2015-10-18 17:35 ` Junio C Hamano
2015-10-18 18:32   ` Junio C Hamano
2015-10-18 19:00 ` Junio C Hamano [this message]
2015-10-19  5:23   ` Torsten Bögershausen
2015-10-19  6:32     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=xmqq4mhoatna.fsf@gitster.mtv.corp.google.com \
    --to=gitster@pobox.com \
    --cc=git@vger.kernel.org \
    --cc=tboegi@web.de \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox