Re: [PATCH 00/19] Add git-list-files
On Tue, Dec 2, 2014 at 3:02 AM, Junio C Hamano gits...@pobox.com wrote: Does this contain a lot of borrowed code or something? The style violation in the patches are unusually high, even compared with your other series. The first one is from coreutils, but I reformatted (and trimmed) to fit Git. I recall you had a script to spot style violation, right? Where can I find the script? Else I'll reread CodingGuidlines again and go through the patch. I've tried to fix it up and will push out the result on 'pu' if things work OK, but this does not even have tests, so it is unlikely that it would break anything but itself ;-) Heh.. ;) Next version will come with tests. Thanks for the reminder. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] Add git-list-files
On Tue, Dec 2, 2014 at 12:42 PM, Jeff King p...@peff.net wrote: On Sun, Nov 30, 2014 at 03:55:48PM +0700, Nguyễn Thái Ngọc Duy wrote: This is something else that's been sitting in my tree for a while now. It adds git list-files, intended to be aliased as ls with your favourite display options. When I read the subject, I thought why isn't this called git-ls?. Then when I read this paragraph, I thought if the point is for everybody to make their own ls alias, why do we need list-files at all, instead of just adding options to ls-files? I'll let you decide which (if any) you'd like to answer. :) My guesses: 1. If it were git-ls, it would stomp on existing aliases people have constructed. Yes, Matthew Moy (I think) at least had this git-ls alias and he did complain. Also we could not agree on what should be the good defaults for git-ls if it's built in. 2. If it is a wrapper around ls-files, then the options may be constrained; ls-files already squats on useful options like -d (which, if we are matching traditional ls, is more like our -t). Also right. I want to keep option names close to GNU ls. As a side note, I wonder if it would be sensible to whitelist some commands as porcelain, and allow aliases to override them (either entirely, or just to add-in some options). Agreed. Maybe not all porcelain (some like git-branch almost functions like plumbing). We also need away to stop alias (e.g. in scripts). In scripts I can specify full path to a command to make sure I won't hit an alias. I guess we can't do the same here. The closet to full path is git-cmd form, as opposed to git cmd form) but I think we don't want to bring back git-cmd. Maybe just a git --no-alias cmd and GIT_NO_ALIAS.. And if people now can override standard commands, I think it makes sense to ship a default alias set (with lower priority than user-defined aliases). After all people need to check twice if the command they type really means what they think it is.. -- Duy -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] Add git-list-files
Jeff King schrieb am 02.12.2014 um 06:42: On Sun, Nov 30, 2014 at 03:55:48PM +0700, Nguyễn Thái Ngọc Duy wrote: This is something else that's been sitting in my tree for a while now. It adds git list-files, intended to be aliased as ls with your favourite display options. When I read the subject, I thought why isn't this called git-ls?. Then when I read this paragraph, I thought if the point is for everybody to make their own ls alias, why do we need list-files at all, instead of just adding options to ls-files? I'll let you decide which (if any) you'd like to answer. :) My guesses: 1. If it were git-ls, it would stomp on existing aliases people have constructed. 2. If it is a wrapper around ls-files, then the options may be constrained; ls-files already squats on useful options like -d (which, if we are matching traditional ls, is more like our -t). I somewhat feel like (1) can be mitigated by the fact that your command is what people were probably trying to approximate with their aliases, and that as porcelain it should be very configurable (so they should be able to accomplish the same things as their aliases). But I dunno. I do not have an ls alias, so I am biased. :) As a side note, I wonder if it would be sensible to whitelist some commands as porcelain, and allow aliases to override them (either entirely, or just to add-in some options). -Peff I'd like to second all that (+1, like). User friendly listing of files in the git repo is dearly needed, and following names and default behaviour of mv/cp/ls is a way to follow the principle of least surprise. While ls might be an alias for many, I'm sure stage was for quite a few people, too. We should be able to take any new name for new command, regardless of aliases people may be using. Allowing to alias at least porcelain commands, at least to the extent of adding default options, is something we've talked about before and which would have prevented us from the increasing bloat by the default changing config knobs. git -c ... somehow took us down the other road. I'm still dreaming of a git future where either git foo --bar=baz is equivalent to git -c foo.bar=baz foo (i.e. unify the naming), or we are simply able to alias foo to foo --bar=baz if that is what we like as default (i.e. get rid of many of the special config knobs). Right now, we have two sets of options with often differing names. Also, we could ship a few commonly used aliases (such as co=checkout, ci=commit, st=status) which could be overriden easily. Michael -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] Add git-list-files
On Tue, Dec 02, 2014 at 06:45:52PM +0700, Duy Nguyen wrote: As a side note, I wonder if it would be sensible to whitelist some commands as porcelain, and allow aliases to override them (either entirely, or just to add-in some options). Agreed. Maybe not all porcelain (some like git-branch almost functions like plumbing). Yeah, many things straddle the plumbing/porcelain line (e.g., commit is porcelain, but it's basically the only sane way for scripts to make a commit, so many use it). So I'd pick just a few things that should be safe to override. We also need away to stop alias (e.g. in scripts). Do we? I think the point of allowing this only for porcelain is that you do not have to care about scripts. That is, a script running git ls would get whatever the user's preferences are for ls output. A script parsing the output of ls deserves whatever crap it gets. In scripts I can specify full path to a command to make sure I won't hit an alias. I guess we can't do the same here. The closet to full path is git-cmd form, as opposed to git cmd form) but I think we don't want to bring back git-cmd. Maybe just a git --no-alias cmd and GIT_NO_ALIAS.. Yeah, I think --no-alias/GIT_NO_ALIAS would work. But the problem is one of compatibility. Scripts are not written to specify no-alias, so you cannot just turn on the override-commands-with-aliases feature immediately (and likewise, scripts have little incentive to bother annotating their calls if it the override feature is not enabled). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] Add git-list-files
Does this contain a lot of borrowed code or something? The style violation in the patches are unusually high, even compared with your other series. I've tried to fix it up and will push out the result on 'pu' if things work OK, but this does not even have tests, so it is unlikely that it would break anything but itself ;-) -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: [PATCH 00/19] Add git-list-files
On Sun, Nov 30, 2014 at 03:55:48PM +0700, Nguyễn Thái Ngọc Duy wrote: This is something else that's been sitting in my tree for a while now. It adds git list-files, intended to be aliased as ls with your favourite display options. When I read the subject, I thought why isn't this called git-ls?. Then when I read this paragraph, I thought if the point is for everybody to make their own ls alias, why do we need list-files at all, instead of just adding options to ls-files? I'll let you decide which (if any) you'd like to answer. :) My guesses: 1. If it were git-ls, it would stomp on existing aliases people have constructed. 2. If it is a wrapper around ls-files, then the options may be constrained; ls-files already squats on useful options like -d (which, if we are matching traditional ls, is more like our -t). I somewhat feel like (1) can be mitigated by the fact that your command is what people were probably trying to approximate with their aliases, and that as porcelain it should be very configurable (so they should be able to accomplish the same things as their aliases). But I dunno. I do not have an ls alias, so I am biased. :) As a side note, I wonder if it would be sensible to whitelist some commands as porcelain, and allow aliases to override them (either entirely, or just to add-in some options). -Peff -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
[PATCH 00/19] Add git-list-files
This is something else that's been sitting in my tree for a while now. It adds git list-files, intended to be aliased as ls with your favourite display options. As you can guess it's a friendlier version (and pretty close to GNU ls) of ls-files. On one hand, I think this is a nice addition. On the other hand, code bloat. Last version on the list is http://thread.gmane.org/gmane.comp.version-control.git/244530/focus=245464 Nguyễn Thái Ngọc Duy (19): ls_colors.c: add $LS_COLORS parsing code ls_colors.c: parse color.ls.* from config file ls_colors.c: add a function to color a file name ls_colors.c: highlight submodules like directories ls-files: buffer full item in strbuf before printing ls-files: add --color to highlight file names ls-files: add --column ls-files: support --max-depth Add git-list-files, a user friendly version of ls-files and more list-files: -u does not imply showing stages list-files: add -R/--recursive short for --max-depth=-1 list-files: add -1 short for --no-column list-files: add -t back list-files: sort output and remove duplicates list-files: do not show duplicate cached entries list-files: show directories as well as files list-files: add -F/--classify list-files -F: show submodules with the new indicator '' list-files: -M aka diff-cached .gitignore | 1 + Documentation/config.txt | 22 ++ Documentation/git-list-files.txt (new) | 99 +++ Documentation/git-ls-files.txt | 20 ++ Makefile | 2 + builtin/ls-files.c | 415 --- color.h| 10 + command-list.txt | 1 + git.c | 1 + ls_colors.c (new) | 496 + 10 files changed, 1034 insertions(+), 33 deletions(-) create mode 100644 Documentation/git-list-files.txt create mode 100644 ls_colors.c -- 2.2.0.60.gb7b3c64 -- To unsubscribe from this list: send the line unsubscribe git in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
